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

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 a lifecycle asset with explicit ownership, purpose, state, and evidence.

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 BreaksThese 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 PromisesOne 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 TrustEach 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 · Summary

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.
This separation can contain a single device-key compromise.

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.

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 BreaksThese 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 4

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

Q1What does recovering this secret imply for the device fleet?

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

BThe encryption algorithm has become mathematically weaker and should be replaced

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

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

Show answer

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

Retrieval practice

Recall check 2 of 4

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

Q2A fleet says its keys are well managed. Which evidence best supports that claim?

ARecords and failure tests for key generation, binding, storage, rotation and revocation.

BA slide asserting key rotation works fleetwide, with no device records or failure tests.

COne encrypted test message, with no key custody or failure evidence.

DA cipher-name list for the fleet, with no key generation or revocation trace.

Show answer

Answer: A A lifecycle claim needs proof at each stage, including rejected bad cases.

Retrieval practice

Recall check 3 of 4

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

Q3A 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?

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

BFail release until per-device revocation fails closed

CRotating every other device's key solves the problem

DA longer key on each device would have prevented this

Show answer

Answer: B Revocation is a separate capability from rotation.

Retrieval practice

Recall check 4 of 4

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

Q4A design derives its data-encryption and message-authentication keys from the same secret using identical KDF salt and output length, with an empty context (info) for both. Why is this unsafe?

AUse separate storage slots because physical separation produces distinct keys from identical KDF inputs.

BEmpty KDF context can yield the same output for encryption and authentication roles.

CIdentical KDF inputs merely slow derivation; key separation remains sound.

DLonger master secret removes the need for role-specific KDF context.

Show answer

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

Print reference

Answers

Answer key.

D · A shared secret removes per-device blast-radius control and makes targeted revocation impossible.
A · A lifecycle claim needs proof at each stage, including rejected bad cases.
B · Revocation is a separate capability from rotation.
B · Key separation depends on binding each derivation to explicit context such as a purpose label and identities.