9 Encryption Key Management
Generation, Provisioning, Storage, Derivation, Rotation, and Revocation
IoT key management, key lifecycle, device provisioning, key rotation, key revocation, HKDF, secure element, per-device keys
9.1 A Key Has a Whole Life, Not Just a Value
Start with a device that disappears from a job site. The scary question is not whether AES is strong; it is whether that one missing device can still impersonate the fleet tomorrow, and whether the service can remove its trust without breaking every other device.
An encryption algorithm can be strong while the deployed system is weak, and the gap between the two is almost always key management. A cipher only protects data while the key behind it is created well, held by the right owner, kept out of the wrong hands, used for one clear purpose, replaced when needed, distrusted when something goes wrong, and erased when the device leaves service. Key management is the set of practices that carries a key safely through all of those stages.
The most common mistake is to treat “we encrypt it” as the finish line and leave the key as an afterthought: the same secret baked into every device, no way to replace it, and no way to switch one device off. A key is not a constant you set once. It is an asset with a lifecycle, and the security of the whole product depends on how that lifecycle is managed.
If you only need the intuition, this layer is enough: every key should have one owner and one job, must be protected both at rest and while it is used, and must be replaceable and revocable. Give each device its own key rather than one shared fleet secret, and plan rotation and revocation before deployment, not after an incident.
Think of the keys to a large building over many years. You do not cut one master key and hand a copy to everyone, because then losing a single copy means re-keying the entire building. Instead each holder gets their own key tied to a record of who they are, spare keys stay in a locked cabinet, you can cancel one person’s key without disturbing anyone else, and when someone leaves you collect or deactivate their key and note it in the log. Cryptographic key management is that same discipline applied to digital secrets.
The One-Minute View: Three Promises
One owner, one job
Give each device its own key and keep separate keys for separate purposes. A shared fleet secret turns one extracted device into a fleet-wide compromise.
Protect at rest and in use
Keep secrets inside a defined boundary, prefer keys that are used without being exported, and never let them leak through firmware images, logs, or debug paths.
Be able to rotate and revoke
Plan how to replace a key and how to switch off one device’s trust before deployment. A design that cannot revoke one device is not ready.
Beginner Examples: Where Key Management Breaks
- A product that ships the same symmetric secret in every unit looks fine until one device is opened and the secret is read; now every device that trusts that secret is exposed, and there is no way to switch off just one.
- “The key is stored securely” is not a claim a reviewer can accept. It does not say where plaintext key material is allowed to exist, whether it can be exported, or what a firmware dump or crash log would reveal.
- A device that can be remotely re-keyed and a service that can deny one lost device contain damage. A device with a permanent embedded credential and no revocation path cannot.
Overview Knowledge Check
If you can explain why each key needs one owner and one job, and why rotation and revocation must be planned up front, you can stop here. Continue to Practitioner to walk a fleet through its key lifecycle with evidence at each stage.
9.2 Run the Lifecycle With Evidence at Each Stage
The practical job is to turn “we manage our keys” into a sequence of lifecycle stages, each with a question to answer, evidence to show, and a failure test that must pass. The goal is not to mandate one chip or one cloud service; it is to prove the security property at every stage. The common review failure is approving generation and storage while derivation, rotation, and revocation stay unexamined.
Read the lifecycle like a handoff record. At each step, the key gets a clearer owner, a narrower job, and a stronger rule for what happens when the owner, job, or trust state changes.
Walkthrough: Commissioning a Sensor Fleet From Birth to Retirement
- Generate from an approved process. Create key material with an approved random bit generator seeded from a validated entropy source. Keep the generation method and entropy evidence; reject predictable seeds, repeated keys, and hand-chosen secrets.
- Provision a unique identity. Bind each device’s public identity to a registry entry, manufacturing batch, and owner or installation record, so an unknown or duplicated identity cannot authenticate.
- Protect the private secret. Hold it inside the device’s storage boundary, disable debug extraction before shipment, and prove it is absent from firmware images, exports, and logs.
- Derive purpose-specific keys. Split telemetry protection, update verification, and onboarding into separate derived keys bound to explicit context, so one purpose cannot stand in for another.
- Rotate with a tested overlap. Replace operational keys on a trigger, accept old and new during a short overlap window, then reject the old key and record which devices moved.
- Revoke one device at a time. Make a lost, returned, or compromised device fail authentication even if it still holds old material, without disabling unrelated devices.
- Destroy on retirement. Wipe local secrets during repair or decommission, update the registry, and keep non-secret audit evidence so the unit cannot silently rejoin.
Lifecycle Review Gates: Evidence Before Trust
Each stage is its own gate. Approving the design means every gate produces evidence and passes its failure test, not that one slide says “keys are rotated” or “stored securely.”
Worked Review: Turn “Our Keys Are Stored Securely” Into Evidence
A team protects a fleet and states that keys are “generated at the factory and stored securely.” The reviewer turns that into evidence questions.
What the claim covers
It suggests generation happens before shipment and that there is some intent to protect the secret at rest, which is a reasonable starting point.
What the claim misses
It does not say whether each device has a unique key, where plaintext is allowed to live, whether the key is exportable, or whether one device can be revoked without re-keying the fleet.
Conclusion
Require per-device identity, a named storage boundary with a non-export policy, purpose-separated derived keys, and tested rotation and one-device revocation before accepting the design.
Practitioner Knowledge Check
If you can run a fleet through every lifecycle gate and show evidence at each, you can stop here. Continue to Under the Hood for the mechanisms behind generation, derivation, storage, rotation, and revocation.
9.3 Hierarchy, Derivation, and the Mechanisms Behind Each Stage
The deeper layer explains why the lifecycle separates generation, storage, derivation, rotation, and revocation into independent guarantees. A weakness in any one can undo the rest even when the others look strong, which is why a key hierarchy keeps roles, identities, and purposes apart.
The useful mental model is a tree of trust, not a box of passwords. Roots certify identities, identities derive purpose keys, purpose keys create short-lived session keys, and revocation state decides whether any branch should still be trusted.
A Key Hierarchy Limits Blast Radius One Step at a Time
Real systems do not use one flat secret. They build a hierarchy: a protected root or issuer authority signs or certifies device identities; each device holds its own identity key; purpose keys for encryption, authentication, signing, and update verification are kept separate; and short-lived session keys protect a bounded amount of traffic. Each level narrows what a single compromise can reach. The point of the hierarchy is that revoking or rotating at one level does not force a rebuild of the others, so one incident stays contained instead of becoming a fleet-wide event.
Generation and Entropy: The First Review Stop
A key is only as unguessable as the randomness behind it. Approved practice is to draw key material from a cryptographic random bit generator seeded by a validated entropy source, and to keep evidence of both. The classic IoT failure is a device that seeds its generator from a predictable value at first boot, such as a timer or serial number, so many units produce the same or related keys. Because the whole scheme assumes the key is unpredictable, weak entropy quietly undermines every later stage.
Derivation and Key Separation: Keep Jobs Apart
Key derivation lets a design expand one established secret into many purpose-specific keys instead of storing each one. A key derivation function such as HKDF works in two steps, extracting uniform key material from the input secret and then expanding it into outputs bound to context. That context is what makes derivation safe: a label for the purpose, the protocol name, the device and peer identities, the session transcript, and the output length. The sharp failure is an empty or ambiguous context field, because then a key derived for one purpose can collide with or substitute for a key meant for another, which is exactly the cross-purpose confusion separation is supposed to prevent. The reviewable artifact is the set of context fields and matching test vectors, not just the function name.
Storage: At Rest, In Use, and Out of Logs
“Stored securely” has to name a boundary. The strongest pattern is a hardware-protected store, such as a secure element, a trusted platform module, or a protected execution environment, that performs operations with the key while the key itself never leaves in plaintext, which makes it non-exportable by design. Even with such hardware, the secret must also be protected in use: least-privilege access so only the intended component can request an operation, debug and repair paths that cannot extract it, and audit logs that record the key identifier, operation, result, actor, and time but never the secret, seed, recovery value, or bearer credential.
Rotation, Revocation, Recovery, and Destruction: Four Different Moves
These four operations are distinct and easy to conflate. Rotation replaces an active key on a trigger of time, usage, policy, ownership change, or incident; a short overlap window lets old and new keys both validate during transition, after which the old key is retired and rejected, with a rollback rule and telemetry showing which devices moved. Revocation removes trust from an identity, certificate, key handle, owner, or issuer, enforced through a revocation list, an online status check, a deny list, or registry state; the critical property is that it fails closed, refusing trust when revocation evidence is unavailable rather than defaulting to accept. Recovery restores service after loss, but it must never become a universal bypass: record who may recover, what evidence is required, and what is rotated afterward. Destruction erases local secrets on repair or retirement, updates the registry, and keeps the non-secret audit trail so the unit cannot silently rejoin. Established guidance such as NIST’s key-management recommendations frames these as lifecycle states with explicit transitions rather than ad hoc events.
Mechanisms and Failure Modes: What to Inspect
Common Pitfalls: Key Lifecycles That Fail Quietly
- Hardcoded or shared secrets. A secret baked into firmware can leak through images, debug interfaces, repositories, logs, or one physical extraction, and a shared secret turns one leak into a fleet incident. Use per-device material unless a reviewed architecture justifies a group key.
- No revocation path. Long certificate lifetimes and static tokens do not remove trust from a lost or compromised device. Provide explicit per-device revocation that fails closed.
- Ambiguous derivation context. Reusing the same KDF input across purposes invites cross-protocol and cross-role confusion. Bind purpose labels, identities, and session state into every derivation.
- Secrets in logs. A useful audit trail records key identifiers, operations, versions, results, and actors; it must never record raw keys, seeds, recovery tokens, or bearer credentials.
- Recovery as a backdoor. An unrestricted recovery path is a universal bypass. Gate it with required evidence and rotate the affected keys afterward.
Under-the-Hood Knowledge Check
At this depth, key management is a hierarchy of independent guarantees: unpredictable generation, per-device identities, purpose-separated derivation bound to context, secrets that are used without being exported, and trust that can be rotated, revoked, recovered, and destroyed on demand. Get the lifecycle right and a strong cipher stays strong in the field; get it wrong and the algorithm’s strength never reaches the deployed system.
9.4 Summary
- Key management is the lifecycle discipline around cryptography: a strong algorithm protects nothing if its key is generated, stored, or retired badly.
- Keys move through generation, provisioning, storage and use, derivation, rotation, revocation, and destruction, and each stage needs its own evidence and its own failure test.
- Give each device a unique key; a shared fleet secret turns one extraction into a fleet-wide compromise and prevents revoking a single device.
- Generate keys from an approved generator and a validated entropy source, because predictable seeds produce duplicated or guessable keys.
- Derive purpose-specific keys with a KDF such as HKDF bound to explicit context; an empty or ambiguous context collapses key separation.
- Store secrets inside a named boundary, prefer non-exportable keys used in place, enforce least privilege, and keep secrets out of logs, firmware, and debug paths.
- Rotation, revocation, recovery, and destruction are distinct: plan an overlap window, a fail-closed revocation path, a gated recovery process, and a decommission wipe before deployment.
The hardest part of encryption is rarely the cipher; it is managing keys over a device’s lifetime. Give every device its own key, protect it inside a boundary that does not export it, derive purpose keys with explicit context, and build rotation and fail-closed revocation in before deployment, not after an incident.
9.5 See Also
Key Renewal and Rotation (E5)
Go deeper on renewing and rolling over keys over a long device lifetime, with overlap windows and forward secrecy.
Public Key Cryptography
See how certificates and signatures bind a device identity to a key during provisioning and trust setup.
Symmetric Encryption
Meet the per-device shared keys whose scope, distribution, and revocation this chapter manages.