Chain of Trust

The chain originates from a Hardware Root of Trust (HRoT) , an inherently trusted component physically embedded in silicon. This anchor, often storing a cryptographic key or hash in ROM, cannot be modified by software. Its immutability is the foundational assumption upon which all subsequent trust is built, providing a secure starting point for validation.

The boot process is a sequential, layered sequence. Each stage is responsible for measuring and verifying the next stage before passing execution control. This creates a transitive trust relationship:

• Boot ROM verifies the First-Stage Bootloader.
• First-Stage Bootloader verifies the Second-Stage Bootloader.
• Second-Stage Bootloader verifies the Operating System Kernel. A failure at any stage halts the boot process, preventing compromised code from executing.

Verification is performed by computing a cryptographic hash (e.g., SHA-256) of the next stage's code and configuration. This measurement is compared against a known-good, digitally signed value. In a Measured Boot process, these hashes are also extended into a Trusted Platform Module's (TPM) Platform Configuration Registers (PCRs) to create a tamper-evident log for later remote attestation.

Authenticity is enforced through asymmetric cryptography. The manufacturer signs a hash of the authorized firmware with a private key. The verifying stage uses the corresponding public key, often fused into the hardware, to validate the signature. This ensures the code is not only unmodified but also originated from a trusted source, preventing the execution of unauthorized third-party code.

To prevent an attacker from loading an older, vulnerable but cryptographically valid firmware version, a monotonic version counter is maintained in non-volatile, tamper-resistant hardware. Each firmware update increments this counter. The boot process verifies that the new firmware's version number is greater than or equal to the stored counter, blocking rollback attacks.

The chain does not end with the OS kernel. Modern architectures extend it into the application layer. For example, a Trusted Execution Environment (TEE) can use the established chain to verify and launch trusted applications in an isolated enclave. This ensures that sensitive workloads, like AI inference, run in a cryptographically verified environment, protected from a potentially compromised operating system.

A security standard that enforces the Chain of Trust by ensuring a device boots using only cryptographically signed software. Each stage verifies the signature of the next before execution.

• Relies on a Platform Key (PK) and Key Exchange Key (KEK) database
• Rejects unsigned or improperly signed bootloaders and OS kernels
• Prevents the execution of bootkits and low-level rootkits

A complementary process to Secure Boot that computes and records the cryptographic hash of every component loaded during boot into Platform Configuration Registers (PCRs).

• Does not halt the boot process on a mismatch; instead, it creates an immutable log
• Enables Remote Attestation to verify the boot state to a third party
• Stores measurements in a Trusted Platform Module (TPM) for tamper-proof logging

An international standard (ISO/IEC 11889) for a dedicated microcontroller that acts as a secure vault for the Chain of Trust. It stores the Root Key and the PCR hashes generated during Measured Boot.

• Performs Remote Attestation by signing PCR quotes with an Attestation Identity Key (AIK)
• Seals data to a specific platform configuration, releasing it only if PCRs match
• Provides a shielded location for cryptographic operations, isolating keys from the OS

A hardware security standard that creates a layered, compound device identity without requiring a discrete TPM. It cryptographically derives the identity of each boot layer from the previous layer's hash.

• The Unique Device Secret (UDS) is fused into the silicon and never released
• Each layer's identity is a Compound Device Identifier (CDI) derived from the UDS and the measurement of the previous layer
• Enables automatic re-encryption of secrets if a different firmware version is loaded

The mechanism by which a client proves its hardware and software configuration to a remote verifier. It is the ultimate validation that the Chain of Trust is intact.

• The client's TPM or DICE engine signs a quote of the current PCR values
• The verifier checks the signature against a known-good configuration database
• Used to grant network access or release secrets only to trusted platforms