Key Management / Key Hierarchy · MY Academy Comic Classroom
Start with a research device
MY has finished an experiment and wants to keep the results on the device for tomorrow's analysis. The research has not been published. Installing a program on the device should not automatically give that program access to the dataset.
Following the PUF lesson, the data is encrypted before it is stored in the SoC's storage area. An isolated service inside the chip manages the keys. For now, think of that service as a program responsible for keys and cryptographic operations. Other programs can request work without receiving the key material themselves.
Two programs have different jobs. The analysis app needs the measurements to plot curves and compare experiments. The diagnostic tool only needs device status, such as temperature or available storage. Reading unpublished research is not part of its job, so MY does not intend to authorize it.
This is a fictional teaching scenario. The curves and logs are illustrations, not real research data or a report about a particular product's vulnerability.
01 | Export denied. Why did the data get out?
MY opens the diagnostic tool and finds the experiment's complete curve on its screen. Something has crossed the intended boundary: a program that should only inspect device status has read the research. Suspecting a stolen key is reasonable. Anyone holding the corresponding key and ciphertext may be able to decrypt the data elsewhere. But that is a hypothesis, not yet the result of an investigation.
The robot finds two service records. A request to export the key was denied. A request to decrypt data succeeded. Export requests key material; decryption can ask the service to use a key internally and return a result. These operations need not have the same permission. The PSA Crypto API defines separate export and decrypt usage flags.[1]
Encrypted storage still needs a usable read path. Otherwise, tomorrow's analysis cannot happen. A service supplied for that legitimate work can also become a route out for plaintext if it accepts the wrong request. That is the path we will investigate. A success status alone does not establish which caller, object, or output buffer was involved.
Nor does a single denied export establish that a key has never leaked. A real investigation must check the integrity of the logs, correlate the requests, and look for other copies or exposure routes. To isolate this lesson's problem, assume the attacker has not obtained key material or gained control inside the secure service. The attacker controls the diagnostic tool, can read ordinary storage, and can submit requests.
We also assume the diagnostic tool and analysis app are separate, isolated callers and that the underlying identity mechanism remains trustworthy. A plug-in running inside the analysis process may share its identity; we will change that assumption in the final chapter. For now, follow the diagnostic request: which data did it name, how was its caller identified, and where should permission have been checked?
02 | Who decrypted it for the diagnostic tool?
MY lists the request fields: the tool selected Project A's object and asked for decryption. It did not necessarily submit a key. An application can use an identifier that lets the service locate the relevant key. A numbered storage compartment is a useful analogy: the number tells you which compartment, not whether you may open it.
Inside the service, the data and key were found and decryption completed. The missing decision was whether this caller could read Project A. The key stayed within the service, but the plaintext was delivered to the diagnostic tool. Both opening records can therefore be true without the cipher being broken.
There are two policy layers here. One restricts what a key may do, such as decrypt, sign, or export. Another decides whether this caller may request that operation on this object. Allowing decryption with a DEK is not blanket permission for every app to decrypt every file. PSA specifies key-usage flags; TF-M's service design also handles caller identity and key ownership.[1][2]
Our example isolates a missing object-access check and assumes trusted request transport and identity. A real design must also prevent an identifier from being swapped for another object, a request from selecting the wrong key, or an output from reaching someone else's buffer. Find out which operation the service performed for which caller before deciding where to repair it.
03 | Which key protects the research data?
Before fixing the entrance, MY draws the file's protection structure. The key used directly on the research data is the Data Encryption Key, or DEK. This lesson has the secure service generate it using a cryptographic random-number generator. Ordinary storage can hold the resulting ciphertext, but should not leave the unprotected DEK beside it where the same read exposes both.
A Key Encryption Key, or KEK, protects the DEK. A suitable wrapping operation takes key material as the protected input and produces a wrapper that can be stored. The operation must conceal the DEK and detect unacceptable modification. NIST's key-wrapping publication treats these operations explicitly rather than using an unexplained generic lock symbol.[7]
When the analysis app reads the file, the secure service uses the KEK to unwrap the DEK and then uses the DEK to decrypt the data. Key material can remain inside the service boundary throughout. The app receives the result it is permitted to obtain. Drawing the intermediate DEK does not require a hardware implementation to copy it into ordinary CPU-readable memory.
Other architectures may derive a data key from a root or use hardware key slots. We chose a random DEK plus wrapping so that later rotation and recovery are easy to trace, not because it is the only possible SoC design. Data encryption still requires a suitable mode and correct handling of nonces, authentication tags, and object metadata. Those requirements do not disappear behind a key icon.
04 | One key for Project B too?
The device begins handling another research project. Reusing the original DEK would reduce bookkeeping, but one exposed key could then unlock both projects' copied ciphertext. MY gives Project B its own DEK. There is another key record and wrapper to manage, but the exposure scope is clearer: obtaining DEK-A does not by itself disclose DEK-B.
Where does the KEK come from? The HUK is a device-root role. A PUF-backed design is one possible source; other secure establishment and storage methods are possible. In this example, the HUK and an explicitly encoded storage context feed a Key Derivation Function, or KDF, to produce the storage KEK. The root is not used directly on every research file.
Context encoding needs to be stable and unambiguous. Storage and another service must not accidentally supply identical information. HKDF's info field can bind an application and context.[5] The service must still check who may request each purpose. Allowing any app to obtain arbitrary root-derived secrets defeats access isolation, regardless of the branch names.
Hierarchy also does not make every compromise independent. Separate DEKs limit the effect of one DEK's exposure. A shared KEK or HUK may affect lower-level keys through the wrappers it opens or the values it derives. Communication keys need their own explanation: TLS 1.3 derives traffic keys through its handshake key schedule. Do not hang every session key beneath the HUK simply to make a tidy tree.[6]
05 | Who may use which key?
MY now replays the same Read A request from both applications. The object and operation can be identical, so the service also needs to know who sent the request. That identity cannot be merely a caller-supplied sentence saying, "I am the analysis app." The diagnostic tool could change a string just as easily.
Our scenario trusts the operating system and isolation mechanism to bind requests to distinct callers. The service compares that identity with Object A, its associated key, the permitted operation, and current state. Only an authorized request reaches decryption; a rejected request receives no plaintext. TF-M's caller and key-owner design offers a concrete implementation example, while the actual isolation guarantee still depends on the platform and integration.[2]
The object-to-key binding matters as well. Letting an app combine A's permission with B's key may produce the wrong operation despite a legitimate account. The service needs to own or validate these relationships, parameters, output destinations, and metadata. A decrypt usage flag does not supply the missing application policy.
After the repair, analysis can still read A, diagnostic reads of A are denied, and diagnostic status checks still work. That supports a bounded conclusion: this unauthorized read path is restricted. It does not prove the analysis app can never be compromised or that the service has no other vulnerabilities. Acceptance criteria must preserve that distinction.
06 | Rotate the KEK—or rewrite all the data?
The storage KEK is due for scheduled replacement. Rewriting a large research archive every time could consume substantial time and storage writes. But look at the roles: the KEK protects a DEK wrapper, while the DEK encrypts the data. If the DEK stays the same, the existing data ciphertext does not necessarily need to change.
Inside a trusted service, KEK-v1 opens the old wrapper. The same DEK is then wrapped using KEK-v2. This is rewrapping. It replaces protection at the wrapping layer without pretending that the data key itself has become a different secret. Keeping the layers explicit helps an operator determine what must be migrated.[3]
The transition is more than overwriting a file. Create the new wrapper, verify that it opens and reads the corresponding data, switch the active version, and handle old wrappers according to policy. A power failure must leave a recoverable state rather than an archive with no usable key. Temporary dual-version support trades availability against exposure and needs a defined end.
Do not apply this conclusion unchanged when the old KEK was stolen. If the attacker also copied wrappers that it opens, their DEKs may be affected. Removing a local old wrapper does not remove an attacker's copy. Routine rotation manages continued operation; compromise recovery must assess how far the secret exposure extends.
07 | A leaked DEK: is a new wrapper enough?
This time, the investigation confirms that DEK-A was obtained. The team suggests a quick response: replace the KEK and rewrap the DEK. But the attacker already has the data key and does not need to unwrap anything. The old DEK still opens its corresponding old ciphertext, regardless of the new wrapper.
MY must first address the intrusion or leakage path and create the replacement DEK in a trustworthy environment. If the attacker still controls where the new secret appears, repeated replacement may simply expose more keys. Stop using the affected DEK to encrypt new data, then plan re-encryption, verification, and version switching for current data that still requires protection.[3]
Migration may require reading old data, so the old key might remain available under controlled conditions for recovery or decryption. That is different from continuing to protect new data with it. Nor should the team ignore the possibility of modified data. Records should distinguish controlled legacy reads from new encryption rather than collapsing every state into one active/inactive label.
The new DEK can protect future data and newly migrated copies. It cannot take back plaintext already stolen. If an attacker retains old ciphertext and its old DEK, that pair remains usable after the local switch. An incident report should separately state the path closed, the range replaced, and the data whose confidentiality has already been lost.
08 | The collaborator left. Can access be removed?
When the collaboration ends, MY removes the collaborator's read permission. If access was only through the service and the collaborator never obtained usable key copies, rejecting new requests from that identity is an important way to end further online access. One departing account does not automatically require replacing every device key without an exposure assessment.
If the collaborator held a shared DEK or a secret that unwraps it, disabling the account cannot constrain independent use of existing copies. Sharing and subsequent key replacement need a separate decision. Revoking an identity changes who may enter; disabling a version changes which key the service accepts; replacing a secret changes cryptographic material. These actions may happen together, but they do different jobs.[3]
There is another question: what if someone restores an old policy snapshot from when the collaboration was active? The snapshot may have a valid authentication tag because it was once legitimate. Detecting modification does not establish freshness. Where rollback matters, the trusted version state cannot roll back together with the policy being checked.
Possible mechanisms depend on the platform, including trusted state or consultation with an authoritative service. This lesson identifies the requirement rather than presenting one counter as a universal answer. Data legitimately downloaded during the collaboration also remains outside what a new service denial can erase; retention and use need their own controls.
09 | Can the data survive a broken chip?
The original SoC stops working. MY still has all the ciphertext and its device-bound DEK wrapper and expects to resume analysis on a replacement. But that wrapper depends on the original device's KEK. The replacement has a different root. Without another path, the backup may be intact down to its last bit and still impossible to open.
Encryption has not failed. The original device-only restriction continues to apply after the device fails. The design question should have been whether the research must survive loss of that chip. If it must, suitable recovery material and procedures need to exist while the data is still accessible. They cannot be created from nothing after the only secret is lost.[3]
One option in this example is a second wrapper of the same DEK under an independently managed recovery KEK. An authorized recovery service opens it in a controlled environment and creates protection suitable for the replacement device. The HUK need not be exported. This does create another sensitive access route: recovery-key custody, approval, execution, and auditing all become part of the trust boundary.
Not every dataset must be recoverable, and not every kind of key should be backed up. MY needs a documented availability choice: accept losing the data with the chip, or retain a controlled alternative. Both choices have consequences. A recovery design cannot also promise that the original chip is the only possible decryption route under every circumstance.
10 | Key deleted. Safe to retire the device?
Years later, the research device is being retired. MY deletes its key and receives a success response. The robot produces the recovery wrapper prepared earlier. What was actually removed: a lookup identifier, one local key object, or every route that can reconstruct decryption? Those are different claims and require different evidence.
If the goal is to keep the retired device from leaking, the team may still need an official research backup. Acceptance then concerns the equipment being released and its residual data; it should not claim that the dataset is gone everywhere. If the goal is erasure of the whole research dataset, external ciphertext, keys, recovery wrappers, and plaintext copies must be included in the scope decision.
Cryptographic erase relies on suitable encryption and key sanitization to make decryption of the target ciphertext infeasible under specified conditions. It depends on copies and implementation behavior, not merely whether an API can still find an ID. NIST SP 800-88 Revision 2 explicitly discusses backups, escrow, and key-sanitization conditions.[4]
Reconstruction paths matter too. If a retained root and public label can re-derive a DEK, deleting the current DEK object may be insufficient. Erasing keys does nothing to an existing plaintext cache. In our random-DEK design, inventory device and recovery wrappers, their unlocking keys, and any copies that were made. The resulting record should state scope, action, verification, and limitations instead of just displaying a green check.
11 | How do we verify that the original path is blocked?
MY replays the original diagnostic Read A request against vulnerable and repaired service models. The first returns plaintext; the second rejects it at authorization. The legitimate analysis identity still reads the same object successfully. Together these tests show that the unwanted path is restricted without breaking necessary work.
Export tests remain useful, but they cannot be the only evidence. Export was denied before the repair, so another denied export does not distinguish the vulnerable design from the fixed one. The differentiating test asks whether the diagnostic tool can obtain data through another permitted cryptographic operation. Select tests for the claim being made, not merely for an operation that already passed.
Change conditions as well. Have the diagnostic tool claim an analysis identity and verify that the service does not trust that statement. Ask an A-only caller for B. Try a revoked identity, modified object metadata, and an old policy. Record enough context to distinguish authorization, integrity, and version failures without writing keys or research plaintext into ordinary logs.
The supplied model uses synthetic data and cryptography in an ordinary program. It is not a TEE, PUF, or tamper-resistant device and does not validate physical attacks, side channels, or platform isolation. Its purpose is to make these causal relationships reproducible. A product team must carry the same questions back to its actual hardware, software, and operating conditions.
12 | What if the authorized analysis app is compromised?
The diagnostic tool initially had no right to read A, so reliable identity and object checks could restrict that path. Now the attacker controls the analysis app itself. Its request may carry the correct identity, object, and permitted operation, so the service still returns plaintext. The permission table has not necessarily malfunctioned. A previously trusted recipient no longer deserves the same trust.
If analysis requires complete plaintext in that process, the process and components that can inspect its memory belong in the relevant trust boundary. If the task only needs a particular result, consider keeping sensitive computation inside a suitable trusted environment and exposing a narrower operation. This adds implementation and verification work and may reduce flexibility; a secure-box drawing does not make the trade-off disappear.
Narrower output also needs an information-leakage assessment. Returning only an average or statistic is not automatically safe. Repeated queries or attacker-selected subsets may reveal protected details. Object access, operations, query conditions, and output policy must be designed together. Keeping keys inside the chip still reduces direct key exposure, but cannot replace these controls on data use.
The device can now be described precisely. DEKs protect research data, KEKs protect DEKs, and a HUK can support purpose-specific roots of protection. The service controls who may operate on which object. Rotation, revocation, recovery, and retirement address different moments. The opening failure was decryption for an unauthorized diagnostic caller; the repaired policy restricts that path. A compromised authorized app changes the problem and requires a new assessment of trust and output.
Further question: if code accepted by Secure Boot is later compromised at runtime, which protections can the boot-time check replace, and which can it not? Start by drawing assets, requests, and trust boundaries before choosing another mechanism.
Executable teaching model: actual results
These are actual results from a synthetic-data teaching model, not chip security certification. Identity issuance, isolation and trusted version state are harness assumptions. No real malware or production data is used.
26/26 PASS · 2026-10-05 · Download rebuilt from the original lesson’s 26 cases and rerun; these are new results, not a recovered historical record.
Full results and limitations · Teaching-model source
Show all tests
P01Export was denied even before the fix — PASSP02Missing object authorization exposes plaintext to diagnostics — PASSP03The fixed service rejects the diagnostic read — PASSP04Authorized analysis remains functional — PASSP05Diagnostic status queries still work — PASSP06A claimed analysis identity does not grant rights — PASSP07An unissued session is rejected — PASSP08An A-only principal cannot read B — PASSP09Revocation rejects subsequent requests — PASSP10Export remains denied after the fix — PASSP11DEK-A does not open B ciphertext — PASSP12Purpose separation produces different derived keys — PASSP13Routine rewrapping preserves the DEK and data ciphertext — PASSP14Changing authenticated wrapper metadata fails verification — PASSP15Changing the authenticated object label fails verification — PASSP16Tampered ciphertext does not produce an authenticated result — PASSP17An exposed DEK still opens the old copied ciphertext — PASSP18The old DEK cannot open ciphertext protected by the new DEK — PASSP19Knowing the parent allows recomputation with a new public label — PASSP20A new chip root does not open the original device wrapper — PASSP21A pre-existing recovery path can migrate to a new device — PASSP22Deleting a local reference does not remove retained recovery capability — PASSP23An authentic old policy is rejected by trusted version state — PASSP24A compromised authorized app can still exercise its existing rights — PASSP25Permission to read A does not allow selecting B’s key — PASSP26Rewrapping does not invalidate a stolen old KEK and copied wrapper — PASS
Run locally: node proof.mjs
Engineer extensions
1. At what level is caller identity trustworthy?
The story uses distinct isolated callers and trusted identity transport. A platform that distinguishes only secure from non-secure execution, while treating all non-secure apps as one caller, cannot directly enforce our per-application policy. Check how principals are created, how identity travels, and whether a less-trusted component can forge it.
TF-M includes caller and key-owner handling, but reliable separation of non-secure clients remains an integration issue.[2] In-process plug-ins, a compromised kernel, and DMA-accessible buffers can change the assumption. Capability-based handles need their own treatment of forgery, delegation, revocation, and scope. Our ordinary identifier example does not say that every handle architecture has identical security semantics.
2. Key establishment and metadata need protection too
Keys may be securely generated, provisioned, or derived. Each choice must identify trusted sources, places where secrets appear, and the scope of compromise. KDF purpose and version encodings must be unambiguous. Changing a public label does not provide forward secrecy after root compromise when an attacker can recompute the output.[5]
Wrapping and data encryption also need metadata binding. With AEAD, object identity, purpose, and version can be authenticated without being hidden; specify exactly which fields are bound. Nonce handling must meet the selected algorithm's requirements, and failed authentication must not release intermediate plaintext. Our model uses AES-GCM to demonstrate binding; it does not claim to implement AES-KW or AES-KWP.[8]
3. Rotation and revocation need recoverable state transitions
Creating a new wrapper, verifying it, switching, and cleaning up are distinct states with defined retry behavior after interruption. Before switching, confirm that data and wrappers agree. Before cleanup, confirm that required reads no longer depend on the old version. Retaining old state helps availability but also extends exposure, so it needs a policy rather than indefinite retention.
A valid authentication check does not establish that state is current. Where rollback resistance is required, trusted version state must not roll back with the storage snapshot. Conversely, changing a version name or rewrapping an unchanged DEK cannot remove the power of already-copied old keys. Assess derivation, unwrapping, and copied material when planning replacement after compromise.[3]
4. Use the recovery inventory to begin the retirement review
A recovery design records the wrappers, custodians, devices, and services that can recover a DEK. That inventory helps identify routes that must not remain when erasing an entire dataset. Retiring a device and deleting all copies are different scopes; retaining a usable research backup while claiming universal unrecoverability would make the records contradict each other.
An ordinary JavaScript process cannot prove that every memory copy has been zeroized. Garbage collection, copying, swap, debugging, and backups limit such a claim. The model therefore demonstrates the counterexample that a retained recovery path still permits decryption. It does not treat deleting an object as proof of cryptographic erase. Real sanitization depends on platform capabilities, retention policy, and verification procedures.[4]
Five understanding checks
1. Export was denied but decryption succeeded. What should you inspect first?
Trace the caller, object, service authorization, and plaintext destination. Do not infer a broken cipher from the outcome or complete absence of key leakage from one denied export.
2. Why is rewrapping not enough for both routine KEK rotation and a leaked DEK?
Routine rotation can replace the wrapper while leaving the DEK and data ciphertext unchanged. Someone holding a leaked DEK does not need the new wrapper to read old ciphertext. Address the exposed DEK and current data that needs protection; copied old material cannot be recalled.
3. Does a ciphertext backup guarantee recovery after chip failure?
No. A usable key or predesigned controlled recovery route is also required. A replacement chip has a different root and does not automatically open the original wrapper. Lost secrets cannot be reconstructed from nothing after failure.
4. Does deleting a local key ID establish whole-dataset erasure?
No. Define the scope and account for key copies, wrappers, recovery, re-derivation, and plaintext. A device-retirement job may retain controlled backups; an entire-dataset erasure job cannot ignore them.
5. Must reliable identity checks reject a compromised analysis app?
Not necessarily. The app may still use its authorized identity and operation. Reassess its objects, plaintext access, computation boundary, and output leakage. An ACL does not automatically recognize malicious intent behind a permitted request.
Terms and reading path
| Term | Role in this example |
|---|---|
| DEK | Data Encryption Key; directly protects the research data. |
| KEK | Key Encryption Key; protects the DEK wrapper. |
| HUK | Hardware Unique Key; a device-root role used here for purpose-specific derivation. |
| KDF | Derives key material from an input secret and context. |
| Rewrap | Replaces a key wrapper; the wrapped DEK may remain unchanged. |
| Authorization | Determines which principal may perform which operation on which object. |
| Cryptographic erase | Makes target-ciphertext decryption infeasible under appropriate encryption and key-sanitization conditions. |
Revisit PUF for the DEK/HUK roles and TLS for communication keys. The next design question is how to keep limiting authorized software after boot.
#HardwareSecurity #KeyManagement #KeyHierarchy #HUK #PUF #SecureStorage
References
These sources support mechanisms and terminology. The story, dialogue, and teaching model are original educational material. Checked September 9, 2026.
- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management, Sections 5.5, 8.2–8.3 and Appendix B.
- NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, Section 3.2.
- RFC 5869, HKDF, Sections 2–3.
- RFC 8446, TLS 1.3, Sections 7.1–7.3.
Does KEK rotation fix a leaked DEK?
Track two AES-GCM wrappers around one DEK and check that the data ciphertext hash stays identical. Select the diagnostic caller or project-B: a decrypt-capable key still does not authorize the object. Finally inspect why someone holding the DEK can still decrypt the old ciphertext.
Web Crypto encrypts data, wraps and unwraps twice, and decrypts with the old DEK, using fresh random nonces. The root is public and fixed; the DEK is classroom material. Raw DEK bytes exist inside the page, so this proves neither non-exportable hardware nor zeroization. Caller, object, usage and revocation are separate policy checks; they cannot detect malicious intent in an authorized program.
Learning guide
How Trust Is Built Inside a Chip
Open the course outline → · Progress counts published lessons only
Prerequisites
- PUF and basic data encryption
What I learned
- Separate key export from authorized key use
- Explain DEK, KEK, and HUK roles
- Plan key rotation, revocation, recovery, and erasure