Start with the key someone left outside
A house can have a strong lock, alarm, and cameras while one exposed spare key defeats them all. An HRoT lesson begins by finding that shortest bypass, not by collecting acronyms.
The twelve plates move from root secrets, HUK, key storage, and KDF separation to trusted boot, secure storage, internal trust, external protocols, and the wider hardware-anchored subsystem.
Treat narrow and broad HRoT as two teaching lenses. Real standards and products divide responsibilities differently, so follow each asset, caller, operation, lifecycle, and failure path before judging a design by its label.
A strong house can still leave its key outside
Start with the key outside
Do not begin by memorizing HRoT. Picture a house with a heavy lock, alarm, and cameras—but a spare key hanging on the mailbox. A thief does not need to defeat the expensive defenses. The legitimate door has become the shortest attack path.
Find the bypass
That is the weakest-link problem. A correct AES engine, hash block, or signature checker cannot rescue a system whose root secret can be read, whose first boot code can be replaced, or whose sensitive service accepts requests from any app.
A root of trust provides an early, difficult-to-bypass basis for a particular security function. A platform may have roots for confidentiality, integrity, measurement, update authorization, identity, or recovery, and it need not implement each one as a separate block. [1]
Ask the engineering question
The first engineering question is therefore concrete: which asset or decision would make every later check meaningless if it failed? Only after answering that can we place the trust anchor in the right boundary.
The design can be public; the root secret cannot be taken
Let the design be visible
Kerckhoffs's principle tells us that an algorithm, architecture, and flow may be known without destroying security. Hiding a design can slow analysis, but it should not be the only wall. The protected key and the policy around its use carry the real burden.
Name the root material
HUK is a common name for device-unique root material that may support several services. A design may store it in OTP or eFuse, reconstruct it from a PUF with helper data, or inject it in a controlled factory. DICE gives UDS a narrower job: combine it with the first mutable-code measurement to produce the first CDI, not a general working key for ordinary software.
The word root does not grant authority by itself. Its influence comes from the services, identities, and decisions that the architecture derives from it. A HUK used only for storage protects a narrower path than one used for identity, updates, and attestation as well.
Keep the secret behind an operation
A safer interface asks the protected boundary to derive, unwrap, or perform an approved operation. The caller receives a result, not a convenient read_huk() function and a portable copy of the device's deepest secret.
Engineer extension: HUK and UDS are architectural roles, not one mandatory circuit
A product may retain its earliest secret material in OTP or eFuse, or reconstruct it from a PUF with helper data; it can then derive or wrap subordinate working keys. Review the threat model, reset behavior, test access, helper data, derivation labels, and export paths before treating two products with the same acronym as equivalent.
Key storage protects both a key and the right to use it
A vault is not enough
A glass vault can hide a key while still letting anyone press an Open button. Key confidentiality is only the first layer. The system must also decide who is asking, which asset they own, what operation they requested, and whether the current state allows it.
Identify the caller
Caller identity and access policy isolate clients. A key created for App A should not appear automatically in App B's namespace. A diagnostic operation available during manufacturing may need to disappear after the device enters production. [5]
Operation policy matters too. A key may unwrap one class of storage object but remain non-exportable. Firmware verification may use only a designated public key, while signing remains with a controlled private-key holder. Root material may feed only an approved KDF and remain unavailable as an ordinary working key.
Carry policy through the lifecycle
Time completes the picture. Debug locks, lifecycle transitions, authorized updates, revocation, and zeroization determine when a key stops being usable. Key security is a moving system, not a still photograph of a locked box.
Keep the root secret home and derive working keys
Leave the master key home
Copying the HUK into every service resembles giving the building master key to cleaners, tenants, delivery staff, and the machine room. One leak could open everything. A KDF lets the root secret stay inside while separate working keys leave to do bounded jobs.
Bind purpose and context
The KDF combines root material with an explicit label and context. Labels may name storage, device identity, or Service A. Context can bind a device, version, algorithm, or environment. Different domains should produce different keys.
Separation reduces exposure of the root and limits a compromised working key's reach. Losing a storage key should not automatically reveal the device-identity key. If the common root is exposed, however, an attacker may recompute its other derived keys. A hierarchy does not protect against compromise of its own root.
Make separation explicit
Domain separation is not a decorative prefix. It requires unambiguous encoding, stable labels, the right KDF, and matching access policy. The root can remain common while each derived key receives one clear responsibility.
An HRoT protects more than secret bytes
Protect secret assets
HUKs, private keys, and shared keys need confidentiality. Reading them can let an attacker clone identity, decrypt protected data, or imitate sensitive operations outside the device, so these assets are often non-exportable.
Protect public trust material
Public keys, certificates, and expected digests may be intentionally visible yet still require integrity and authenticity. If an attacker replaces the trusted firmware key with their own, the signature calculation may pass perfectly while trusting the wrong signer.
Mutable security state creates a third class: firmware version, rollback counters, update state, failure counts, and revocation data. These values need authorized change, integrity, and freshness so an old but once-valid snapshot cannot restore a patched vulnerability.
Allow only controlled change
Lifecycle and debug policies also need protection. A precise rule is better than 'cannot be changed': secrets resist unauthorized reading, trust material resists unauthorized replacement, and mutable state changes only through an authorized and verifiable path.
Software on the same chip is not automatically trusted
Check the data
Internal trust first asks whether the data is correct and came from the expected source. A digest can expose a change, but a replaceable digest cannot authenticate its own origin. The reference value or verification key must connect to an earlier trust anchor.
Check the caller
Next comes the caller. A modern SoC may contain a normal world, secure world, several privilege levels, DMA masters, and attached devices. Sharing a bus or memory controller does not grant equal rights; hardware identity, isolation, memory protection, and controlled APIs must identify the requester.
A valid caller still needs a valid operation. Permission to unwrap one application's storage object does not grant permission to export the underlying key. A maintenance tool that reads diagnostics should not automatically disable secure boot.
Check the lifecycle
Lifecycle adds the final condition. Manufacturing and test access can become a field backdoor if it survives production. Internal trust means right data, right caller, right operation, and right lifecycle at the same time.
Trust needs a first piece of code
Begin at reset
After reset, the processor fetches its first instruction from a reset vector. If unauthorized software can replace that starting code, it can pretend to perform every later verification. The first trusted code therefore commonly lives in immutable hardware, mask ROM, or a tightly protected Boot ROM.
Keep the first base small
That code should do only enough: initialize required resources, read protected trust material, verify the next stage, and take a safe path on failure. More parsers, drivers, mutable data, and key interfaces enlarge the trusted computing base and make review harder.
After verification, one stage extends trust to the next. That is a chain of trust. The chain breaks if a verification is skipped, its verification key can be replaced, or rollback policy accepts an older stage; a familiar version string proves nothing by itself. [2]
Inspect every handoff
NIST SP 800-193 frames platform firmware resilience around protection, detection, and recovery. Trusted boot must therefore live with authorized update and recovery design, not only a red Reject screen for bad images.
Secure storage protects more than secrecy
Secrecy is one property
Confidentiality asks whether an outsider can read the contents. It matters for keys, tokens, and private data, but it does not stop every attack. Ciphertext can be altered, substituted, assigned to the wrong owner, or replaced with an older valid copy.
Keep owners separate
Integrity and authenticity detect alteration and connect data to an expected producer. Isolation ensures that Alice's object is returned to Alice rather than Bob or Eve. That needs owner identity, namespaces, and access control in addition to encryption.
Freshness handles rollback. Suppose a device revokes an old permission and an attacker restores the earlier, valid storage snapshot. A version field inside the same MAC-protected object does not help because the attacker restores both together. A counter or replay state must live in monotonic or otherwise non-restoreable storage outside that rollback domain.
Treat storage as a service
Secure storage is therefore an end-to-end service spanning key derivation, client isolation, metadata, integrity, the storage backend, and failure handling. 'Encrypted at rest' describes one property, not the complete service. [5][6]
Engineer extension: integrity without freshness still permits rollback
A valid MAC proves that data matches a key and message, not that the message is the newest approved state. Anti-rollback needs protected version state, a monotonic counter, a hash chain, or another design that detects replay of an older authenticated snapshot.
An HRoT is not the whole network
Separate three network questions
External communication asks separate questions: is the peer really Bob, can an observer read the content, and was the message changed in transit? Authentication, encryption, and integrity answer different parts. One lock icon does not solve all three.
Give the protocol a protected endpoint
An HRoT can retain a device private key, trusted CA key, certificate, or attestation material and perform controlled cryptographic operations without handing root material to ordinary software. That gives the protocol a stronger endpoint.
It does not implement the entire relationship. Peer naming, certificate-path checks, handshake transcripts, algorithm negotiation, replay protection, errors, and session state belong to protocols and system integration. Secure hardware cannot repair a broken custom protocol by proximity.
Bound the signature claim
Signatures can provide evidence about origin and integrity, but legal non-repudiation also depends on identity proof, private-key control, audit evidence, and institutional rules. A mathematical signature alone does not settle that larger claim.
Build a full HRoT from a small trust core
Use the narrow lens first
Through a narrow teaching lens, an HRoT begins as a small core around immutable state, a HUK, key storage, and controlled operations. That picture is useful for the first intuition, but real devices also face boot, update, storage, isolation, and failure-recovery problems.
Widen to the system boundary
A wider view adds trusted code, secure execution, access control, lifecycle, cryptographic services, secure storage, and sometimes anti-tamper sensors or responses. These are not universal concentric layers, and every product need not use the same blocks.
PUF and TRNG solve different source problems. A PUF provides a device-specific physical response that can be reproduced with noise handling and helper data; a TRNG produces fresh unpredictable values from physical uncertainty. One helps re-establish device-specific material, while the other supplies new randomness now.
Connect engines into services
AES, SHA, and KDF engines become security services only when key paths, DMA, caller policy, errors, zeroization, and lifecycle remain inside a coherent boundary. Components form an HRoT when their interfaces and failure paths connect into a trustworthy system. [3][4]
Engineer extension: PUF and TRNG validation ask different questions
PUF evaluation focuses on reproducibility, inter-device separation, environmental variation, helper-data leakage, and reconstruction failure. TRNG evaluation focuses on the physical noise source, conditioning, health tests, failure behavior, and the unpredictability of fresh outputs. One block should not inherit the other's security claim by name.
Ask what each acronym is responsible for
Separate primitive, asset, and service
A PUF is a physical primitive that can help establish device-specific secret material. A HUK is the protected device-root asset. A key store retains or wraps working keys and mediates their use. They can cooperate, but they are not synonyms.
Separate code from environment
Boot ROM is a common starting point for trusted code. A TEE is an isolated execution environment for sensitive code and data. A TEE may rely on hardware roots, but merely having one does not prove that boot, root secrets, and every service are correct. [7]
Secure elements and TPMs are classes of secure components with different interface traditions and product roles. They may provide protected computation, key management, measurement, sealing, or attestation. DICE derives a CDI from its dedicated UDS and the first mutable-code measurement, then composes layered device identities from that path. [8]
Read the map as a composition
A chain of trust describes how confidence moves from one stage to the next; an HRoT is the hardware-anchored trusted subsystem providing root services. One SoC may combine these abilities in a security island, while another spreads them across ROM, controllers, and a separate secure component.
Engineer extension: the narrow and broad HRoT views are teaching lenses
Standards and vendors partition roots of trust, secure elements, TEEs, TPMs, security islands, and measured-boot services differently. This lesson moves from root secret and key storage to a wider trusted subsystem to aid understanding; it does not define universal Basic and Standard HRoT product tiers.
Diagnose the missing trust link
Diagnose authority
Case one: the HUK cannot be read, but every app can ask it to perform any operation. Key confidentiality survived; access control failed. The attacker turns the protected service into a remote signing or decryption button instead of stealing the key.
Diagnose the key path
Case two: the crypto engine is mathematically correct, but its key travels over an ordinary bus or debug interface. The missing property is the key boundary, which must cover loading, temporary use, and cleanup as well as the arithmetic block.
Case three: storage verifies every object's MAC but accepts an old valid snapshot. Integrity survived; freshness failed. Case four: the TEE is well isolated, but its first code can be replaced. Without an immutable trust anchor, malicious startup code can stage a convincing security performance.
Trace the full chain
Trace Root secret → Trusted code → Secure services → Chain of trust and ask at every step: where is the asset created, who can use it, which code decides, how may state change, and what happens on failure? Security is not a checklist. Every trust link must connect without a shortcut.
Five points to keep
- An HRoT begins with the trust anchor whose failure would make later defenses meaningless; it is not a magic label for the whole chip.
- A HUK is protected device-root material; DICE gives its UDS a dedicated CDI-derivation path. Key storage must also control the caller, allowed operation, export path, and lifecycle.
- Public keys, certificates, and digests may be public yet still require integrity; secure storage must also enforce ownership and freshness.
- Boot ROM, trusted boot, TEE, PUF, TRNG, secure elements, TPMs, DICE, and cryptographic engines serve different roles and may be composed in different ways.
- Review the complete path from root secret through trusted code and secure services to the chain of trust. One missing boundary can bypass every checked feature.
Continue with the Digital Signature classroom to see how a protected private key creates verifiable evidence and what the verifier is actually trusting.
References
- GlobalPlatform, Root of Trust Definitions and Requirements v1.1.1: Defines root-of-trust roles, functions, and requirements without reducing an RoT to one universal block.
- NIST SP 800-193, Platform Firmware Resiliency Guidelines: Frames platform firmware resilience around protection, detection, and recovery.
- PSA Certified, What Is a Root of Trust?: Introduces the PSA Root of Trust and its role in a device security foundation.
- Arm PSA Crypto API, Sample System Architecture: Shows isolated cryptographic services, clients, keys, and their architectural boundaries.
- Arm PSA Secure Storage API, Architecture: Explains client isolation, secure-storage services, and storage backends.
- Trusted Firmware-M, Protected Storage Key Management: Documents protected-storage key derivation and key-lifecycle design.
- GlobalPlatform, TEE System Architecture: Defines TEE, rich execution environment, client, and trusted-application boundaries.
- Trusted Computing Group, Hardware Requirements for DICE: Connects DICE hardware requirements with layered device identity and measurements.
Check derivation and permission separately
Compare repeated derivation with a different purpose. Change the device context and predict whether the output will match. Then remove caller authorization or request root export and inspect the policy decision.
HKDF-SHA-256 is computed with public, fixed classroom root bytes 00…1f, which provide no security. Labels and contexts use explicit JSON-array encoding. Supplied conditions model policy. Outputs are visible for comparison; there is no real HUK, hardware isolation, DICE CDI or protected read_huk interface.
Learning guide
How Trust Is Built Inside a Chip
Open the course outline → · Progress counts published lessons only
Prerequisites
- No prior hardware-security knowledge is required
What I learned
- Identify the would-be weakest bypass, then explain where a root of trust must anchor protection
- Separate root secret material from key-storage policy and derived working keys
- Trace internal trust through data, caller, operation, and lifecycle
- Explain how Boot ROM, secure storage, and a chain of trust cooperate
- Distinguish PUF, TRNG, TEE, SE, TPM, DICE, and HRoT responsibilities