Cryptography · Study deck

Key Renewal and Rotation (E5)

Picture a water meter that wakes only once a month.

Shield Shelly is your guide for this deck.

key-renewalkey-rotationforward-secrecy

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: A cryptoperiod written in a document means nothing if the device and service do not actually track key version, activation time, expiry, and revocation state and act on them.
Explain: Long-lived keys accumulate risk, so renewal bounds the data and time under any one key and provides a path to retire trust after ownership changes, repairs, or incidents.
Explain: Rotation Versus Forward Secrecy: Future Risk and Past Traffic These are often confused, and the difference is exactly what an attacker who records traffic cares about.
Explain: The advanced question is what a future compromise can reveal.

E5 keeps three jobs separate: long-lived identity authenticates the peer, ephemeral key establishment creates fresh input, and the context-bound KDF feeds the symmetric traffic keys for E1 to E4.

Major section

Keys Age, So Renewal Is Part of the Design · Run the Renewal Flow and Its Gates

Its owner changes while it is asleep, and the old service key should no longer be trusted.

A new key is useful only if the meter receives it safely and the old one is retired without locking out a valid device.
A protected update path is separate from proof that the new key took effect.

E5 renewal moves from a policy or event trigger through fresh material, scoped derivation, finite overlap, retirement, and secret-free audit.

Major section

Forward Secrecy, Overlap, and Issuer Rollover

The deeper layer explains the mechanism behind the sharpest E5 distinction, rotation versus forward secrecy, and the engineering of overlap windows and certificate rollover that keep renewal from becoming an availability or trust failure.

The advanced question is what a future compromise can reveal.
The new version then becomes active.
The lower row shows how to control that change.

A finite overlap lets offline devices rotate before old trust closes, while telemetry, revocation, and recovery handle exceptions.

Major section

Forward Secrecy, Overlap, and Issuer Rollover (continued)

Rotation limits how long one key remains useful, but forward secrecy is what protects old recorded traffic after a later long-term key leak.

Rotation Versus Forward Secrecy: Future Risk and Past TrafficThese are often confused, and the difference is exactly what an attacker who records traffic cares about.
Rotation periodically replaces a key, which limits how much future data any one compromised key can cover.
Straggler data finds devices that have not moved.

Major section

Forward Secrecy, Overlap, and Issuer Rollover (continued)

That binding is what stops a key derived for one role from being accepted in another.

The rule that matters for review is that the trigger must be enforceable by the system.
At the end of the window the old key is disabled or destroyed.
A revocation check blocks trust that has been withdrawn.

Major section

Forward Secrecy, Overlap, and Issuer Rollover (continued)

An intermediate issuer rollover must accept old and new chains during migration, then remove trust for the old issuer at a planned cutover.

A cryptoperiod written in a document means nothing if the device and service do not actually track key version, activation time, expiry, and revocation state and act on them.
If the old key is suspected compromised, revoke it immediately and use a separate recovery path.
Disabled trust cannot obtain fresh key material.

Major section

Forward Secrecy, Overlap, and Issuer Rollover (continued)

KDF Context Is a Security Boundary: Bind Each Key to a JobAfter establishment, the shared secret is never used directly as a traffic key.

A good release gate can simulate offline devices, delayed messages, duplicate renewal commands, stale versions, and a revoked device attempting renewal.
Both work only during a short grace window, after which the old key is disabled and destroyed.
Keys are actually renewed, not just scheduled on paper.

Major section

Forward Secrecy, Overlap, and Issuer Rollover (continued)

A device certificate should be renewed before expiry and bound to the same registry identity and authorization.

Both depend on a working revocation path so devices and services can reject revoked certificates, disabled issuers, and blocked key versions.
Key transport alone gives no forward secrecy; a later leak exposes recorded renewals.
A document-only cryptoperiod leaves stale keys live indefinitely.
Each derived key is distinct and cannot cross roles.

Major section

Summary · Key Takeaway

Key renewal should be automatic, observable, and recoverable.

E5 is the renewal level that refreshes the symmetric keys E1 to E4 depend on; it does not mean using public-key cryptography for every message.
Long-lived keys accumulate risk, so renewal bounds the data and time under any one key and provides a path to retire trust after ownership changes, repairs, or incidents.
Rotation that can strand devices or silently fail is an availability risk, not a security gain.

Deck summary

Key takeaways

Its owner changes while it is asleep, and the old service key should no longer be trusted.

The deeper layer explains the mechanism behind the sharpest E5 distinction, rotation versus forward secrecy, and the engineering of overlap windows and certificate rollover that keep renewal from becoming an availability or trust failure.
Rotation limits how long one key remains useful, but forward secrecy is what protects old recorded traffic after a later long-term key leak.
That binding is what stops a key derived for one role from being accepted in another.
A device certificate should be renewed before expiry and bound to the same registry identity and authorization.

Retrieval practice

Recall check 1 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q1A device gets a replacement traffic key. What makes the rekey step reviewable and safe?

AKeep old and new traffic keys valid indefinitely after rekeying.

BAccept any replacement key carried on an encrypted link.

CDerive traffic and signing keys with the same empty context.

DAuthenticate rekeying, bind role and context, and track key version.

Show answer

Answer: D Those checks prevent an untrusted or wrong-purpose key from silently taking over.

Retrieval practice

Recall check 2 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q2Why should a long-lived symmetric key be renewed even when it uses a strong, unbroken cipher?

ABecause cipher strength decays mathematically with key age.

BBecause one key accumulates risk as data, ownership and repairs change.

CBecause public-key encryption removes the need for any symmetric telemetry key.

DBecause a 256-bit symmetric key can never need renewal.

Show answer

Answer: B Key management, not cipher strength, is the issue.

Retrieval practice

Recall check 3 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q3A team adds a yearly job that sends each device a new symmetric key, but the renewal message has no replay protection and the old key stays valid forever. What is the main review finding?

AThe schedule is sufficient because it limits how long devices encrypt new traffic with one key

BThe main problem is the yearly interval; shortening it would reduce exposure between renewals

CRenewal reduces exposure but fails E5 because replay and unbounded old-key validity remain.

DPublic-key telemetry would remove all key-distribution and replay issues.

Show answer

Answer: C Sending a replacement key is not renewal.

Retrieval practice

Recall check 4 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q4A fleet rotates its symmetric keys yearly by encrypting each new key to the device's long-term public key (key transport), and assumes recorded past traffic is safe if a key later leaks. An attacker records months of traffic, then steals the device's long-term private key. What happens?

ARecorded traffic stays protected because retired symmetric keys are no longer in active use.

BOnly traffic after the theft is at risk; everything before it is protected by rotation

CA longer symmetric key would prevent the exposure after long-term key theft.

DRecorded key transports can reveal past traffic keys, exposing the captured traffic.

Show answer

Answer: D Rotation limits future exposure but does not protect the past.

Print reference

Answers

Answer key.

D · Those checks prevent an untrusted or wrong-purpose key from silently taking over.
B · Key management, not cipher strength, is the issue.
C · Sending a replacement key is not renewal.
D · Rotation limits future exposure but does not protect the past.