Cryptography · Study deck

Encryption Key Management

Start with a device that disappears from a job site.

Shield Shelly is your guide for this deck.

key-managementkey-lifecycleprovisioning

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

After studying this chapter

Learning objectives

You will be able to:

Explain: 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.
Explain: 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.
Explain: 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.

Major section

A Key Has a Whole Life, Not Just a Value

Encryption changes readable data into a form that needs a secret key.

Yet the lost device may still hold a valid key.
An encryption method can be strong while the deployed system is weak.
The gap is often key management.
The key must be created safely and held by the right owner.

Key management turns a raw secret into an auditable lifecycle asset: generated, provisioned, stored, derived, rotated or revoked, and destroyed, all tracked in a key inventory.

Major section

A Key Has a Whole Life, Not Just a Value (continued)

Key management carries a key safely through all these stages.

A cipher is a method that locks and unlocks data with a key.
It must stay out of the wrong hands and have one clear job.
A key is not a constant you set once.

Major section

A Key Has a Whole Life, Not Just a Value (continued)

Protected storage makes the key harder to copy.

The team must replace it when needed, stop trusting it after a problem, and erase it when the device leaves service.
One lost copy would then force you to change every lock.
Destruction removes it when the device leaves service.

Major section

A Key Has a Whole Life, Not Just a Value (continued)

Beginner Examples: Where Key Management Breaks These examples show how key management can expose devices or contain damage.

When someone leaves, collect or cancel their key and update the log.
The centre record keeps the owner, purpose, state, and evidence together.
A design that cannot revoke one device is not ready.

Major section

A Key Has a Whole Life, Not Just a Value (continued)

It leaves unclear where plaintext key material may exist and whether it can be exported.

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.
The One-Minute View: Three Promises One owner, one job Give each device its own key and keep separate keys for separate purposes.
It also leaves unclear what a firmware dump or crash log would reveal.
A device with a permanent embedded credential and no revocation path cannot.

Major section

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 common review failure is approving generation and storage while derivation, rotation, and revocation stay unexamined.

Provisioning evidence proves which authority created device trust, that the private secret lives only inside the device boundary, and that the registry recorded the binding without ever holding the raw secret.

Major section

Run the Lifecycle With Evidence at Each Stage (continued)

Lifecycle Review Gates: Evidence Before Trust Each stage is its own gate.

The goal is not to mandate one chip or one cloud service; it is to prove the security property at every stage.
Predictable seeds, repeated keys, test keys, and hand-chosen secrets are rejected.
Unknown, duplicated, or unregistered identity cannot authenticate.

Major section

Run the Lifecycle With Evidence at Each Stage (continued)

If you can run a fleet through every lifecycle gate and show evidence at each, you can stop here.

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.
Firmware dump, config export, crash log, or debug path does not reveal the key.
A key for one purpose cannot decrypt or verify data from another purpose.

Major section

Run the Lifecycle With Evidence at Each Stage (continued)

The authority record names serial, owner, and batch without copying raw secrets; the device boundary protects private material; and the service attaches policy and audit state to the identity.

Stale keys are rejected after the grace period and cannot silently return.
A revoked device fails authentication even while holding old key material.
A retired identity cannot reconnect or decrypt newly protected data.

Major section

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.
Each level narrows what a single compromise can reach.

Separate roots, per-device identities, purpose keys, and session keys so that revoking one identity never forces a fleet rebuild, with revocation state and audit evidence kept apart from the secrets.

Major section

Hierarchy, Derivation, and the Mechanisms Behind Each Stage (continued)

A Key Hierarchy Limits Blast Radius One Step at a Time Real systems do not use one flat secret.

The useful mental model is a tree of trust, not a box of passwords.
This hierarchy connects containment to an operable rotation and revocation decision.
Keys are unpredictable and not reproducible by an attacker.

Major section

Hierarchy, Derivation, and the Mechanisms Behind Each Stage (continued)

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.

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.
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 reviewable artifact is the set of context fields and matching test vectors, not just the function name.

Major section

Hierarchy, Derivation, and the Mechanisms Behind Each Stage (continued)

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.

Storage: At Rest, In Use, and Out of Logs "Stored securely" has to name a boundary.
Rotation, Revocation, Recovery, and Destruction: Four Different Moves These four operations are distinct and easy to conflate.
Validated entropy source, approved generator, and generation records.

Major section

Hierarchy, Derivation, and the Mechanisms Behind Each Stage (continued)

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.
One leak stays contained to one device and revocation can be surgical.
The secret cannot be read out, only used inside its boundary.

Major section

Hierarchy, Derivation, and the Mechanisms Behind Each Stage (continued)

Each purpose gets a distinct key that cannot stand in for another.

An empty or ambiguous context lets one key be reused across roles.
Trust can be replaced or withdrawn without disabling the fleet.
Overlap window, stale-key rejection test, and fail-closed revocation check.

Deck summary

Key takeaways

Encryption changes readable data into a form that needs a secret key.

Key management carries a key safely through all these stages.
Protected storage makes the key harder to copy.
Beginner Examples: Where Key Management Breaks These examples show how key management can expose devices or contain damage.
It leaves unclear where plaintext key material may exist and whether it can be exported.

Retrieval practice

Recall check 1 of 3

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

Q1A product ships with the same symmetric secret in every device. One device is physically opened and the secret is recovered. What is the strongest review conclusion?

AThe shared fleet secret means one extraction compromises every device that trusts it.

BOnly the opened device is affected, because the attacker physically touched just one unit

CThe encryption algorithm has become mathematically weaker and should be replaced

DIt is acceptable as long as the shared key is long enough

Show answer

Answer: A A shared secret removes per-device blast-radius control and makes targeted revocation impossible.

Retrieval practice

Recall check 2 of 3

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

Q2A fleet uses long-lived certificates and has no way to switch off one device's trust. A device is stolen but still holds valid key material. What is the correct review conclusion?

AFail release until per-device revocation fails closed

BIt is fine, because the certificate will eventually expire on its own

CRotating every other device's key solves the problem

DA longer key on each device would have prevented this

Show answer

Answer: A Revocation is a separate capability from rotation.

Retrieval practice

Recall check 3 of 3

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

Q3A design derives both its data-encryption key and its message-authentication key from the same secret using a KDF, but passes an empty context (info) field for both. Why is this unsafe?

AWith no distinguishing context the KDF can produce the same or interchangeable output for different purposes

BThe keys remain separate because the application stores the two KDF results in different key slots

CThe only risk is slightly slower key derivation

DUsing a longer master secret removes the need for context

Show answer

Answer: A Key separation depends on binding each derivation to explicit context such as a purpose label and identities.

Print reference

Answers

Answer key.

A · A shared secret removes per-device blast-radius control and makes targeted revocation impossible.
A · Revocation is a separate capability from rotation.
A · Key separation depends on binding each derivation to explicit context such as a purpose label and identities.