Secure Boot and the Chain of Trust
1. Overview
A. Definition
Secure Boot is a boot-security scheme in which, starting from a hardware-anchored Root of Trust (RoT), each stage from firmware → bootloader → operating-system kernel → applications cryptographically verifies (or measures) the integrity of the next stage before executing it and then hands trust forward, beginning the moment power is applied. A structure in which trust is passed stage by stage without a break is called a Chain of Trust, and UEFI Secure Boot, Measured Boot, and remote attestation are the representative technologies that implement it.
The fundamental idea of Secure Boot is to break the circular problem of "what vouches for the integrity of the security software itself?" Security solutions such as antivirus, EDR, and firewalls are ultimately code that runs on top of the operating system, so if the kernel — or the bootloader and firmware that come up even earlier — is tampered with, the system is already compromised before the security software is even loaded. In other words, if the "code that runs first" is not trusted, all security built above it is a house of cards. Secure Boot nails the starting point of trust into tamper-resistant hardware and hands trust up to the higher layers one stage at a time, "proving" each as it goes, thereby closing this gap.
The crucial point here is that trust is transitive. The RoT itself is not verified by anything external; it is an axiom that is assumed to be trusted by virtue of the hardware, and every stage after it is trusted because the immediately preceding stage verifies it. Consequently, if any single link in the chain is skipped without verification, or if the root is damaged, the trust of everything below it collapses. This is why Secure Boot design ultimately reduces to a "weakest link" problem.
B. Background and necessity
Traditional security focused on protecting the period "after" the OS has booted. However, as bootkits, rootkits, and firmware implants that establish themselves before the OS emerged, threats that OS-level security can essentially neither detect nor remove became a reality. Malware that seizes the early boot stages bypasses kernel-signature verification, disables defenses such as BitLocker, HVCI, and Defender during the boot process, and — even if the OS is reinstalled — remains outside the disk (in firmware or the ESP) to cause reinfection.
The severity of such threats was demonstrated by a real case. BlackLotus, disclosed in 2023, was the first commercial bootkit to bypass UEFI Secure Boot even on fully patched Windows 11, abusing CVE-2022-21894 (Baton Drop), which re-plants an old vulnerable bootloader, and the follow-on CVE-2023-24932. The impact was large enough that the U.S. NSA issued a dedicated mitigation guide and Microsoft had to progressively register the vulnerable bootloaders into the revocation list (dbx). This shows that the mere fact that "Secure Boot exists" is not enough; it must be accompanied by operations that revoke compromised trust elements and keep them fresh.
Secure Boot is also increasingly necessary as a foundation for supply-chain and device trust. To decide "may I trust this device?" in Zero Trust, there must be a hardware basis that the device booted in an untampered state. As supply-chain risks grow — firmware tampering of data-center servers, firmware swaps on IoT/OT devices, implants in used or imported equipment — Secure Boot and remote attestation based on its measurements are becoming not an option but a baseline requirement.
2. Overall Structure of the Chain of Trust and Core Concepts
Secure Boot should be understood as a layered structure in which trust flows one-directionally from "hardware root → higher layers." The overall structure diagram below shows the flow in which, immediately after power is applied, trust begins at an immutable RoT, each stage verifies or measures the next while handing over control, and the measurements accumulate in the TPM to be used ultimately for remote attestation.
flowchart TD
RoT["Root of Trust(RoT) - immutable Boot ROM·fuses"]
FW["platform firmware(UEFI/BIOS)"]
BL["bootloader(shim·GRUB, etc.)"]
OS["OS kernel·drivers"]
APP["applications·services"]
TPM[("TPM - PCR accumulation")]
VER["remote verification server(Attestation)"]
RoT -->|"verify, then hand over control"| FW
FW -->|"verify, then hand over control"| BL
BL -->|"verify, then hand over control"| OS
OS -->|"verify, then hand over control"| APP
RoT -.->|"measurement extend"| TPM
FW -.->|"measurement extend"| TPM
BL -.->|"measurement extend"| TPM
OS -.->|"measurement extend"| TPM
TPM -->|"submit signed PCR(Quote)"| VER
style RoT fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style TPM fill:#eafbea,stroke:#2f9e44,stroke-width:1px
style VER fill:#fef3e8,stroke:#ed8f2f,stroke-width:1px
A. Root of Trust
A chain of trust must start from "something that does not change." This starting point is the RoT, usually implemented as immutable code (immutable Boot ROM) burned into mask ROM at chip manufacture, together with one-time-programmable fuses (OTP fuses) that hold a hash of the OEM public key and cannot be rewritten. Because they cannot be replaced or modified by software, they are the hardest points for an attacker to touch, and it is precisely this property that qualifies them to be the "axiom of trust."
The RoT is divided into three kinds by function. The Root of Trust for Measurement (RTM) computes the hash of a boot element for the first time and initiates measurement of the chain of trust; the Root of Trust for Storage (RTS) safely holds keys and measurements; and the Root of Trust for Reporting (RTR) reliably attests the measurement results to the outside. Roles are divided such that the TPM handles RTS and RTR, while the CPU's earliest measurement code (CRTM) handles RTM. Defining the roots clearly by function makes it clear "what is trusted and what is attested."
An important design principle is that the root should be small and simple. If the RoT code is large and complex, a flaw within it leads directly to the collapse of all trust, so only a minimal amount of verifiable code (on the order of a few KB) is placed there and the rest is deferred to higher layers. This "Minimal TCB" principle is a lesson common not only to Secure Boot but to all trusted-computing design.
B. The principle of trust transfer (Chain of Trust)
Each link of the chain of trust repeats the same pattern. (1) The current stage loads into memory the code it will run next → (2) it verifies (or measures) that code's signature/hash → (3) it hands over control only if verification passes. Only when this "verify-then-execute" rule reaches the root without any break does the guarantee "the entire booted software stack is trustworthy" hold.
What matters here is the asymmetry that trust flows only downward. A higher layer has no choice but to trust the lower layer, but the lower layer does not trust the higher one; rather it verifies it. Therefore, if an element in the middle of the chain is vulnerable, everything below it (the subsequent stages) is contaminated, but everything above it (the preceding stages) is unaffected. The reason BlackLotus targeted the "bootloader" stage is precisely that it can seize the entire kernel and OS below it at once.
C. Verified Boot and Measured Boot
Secure Boot has two approaches of differing character, and real systems use them together. Verified Boot (Secure Boot) is a "Prevention"-centric approach that halts booting if signature verification fails, whereas Measured Boot is a "Detection"-centric approach that merely records each stage's hash into the TPM PCRs and continues booting, later allowing the state to be "attested" using those measurements. The former blocks the very execution of tampered code; the latter leaves evidence of "which state the system booted into" after the fact.
| Category | Verified Boot | Measured Boot |
|---|---|---|
| Purpose | Prevention (block unauthorized code execution) | Detection (attest boot state) |
| Behavior | Halt boot on signature-verification failure | Accumulate hash into TPM PCR, continue booting |
| Basis | db/dbx·public-key signature | PCR values + remote attestation |
| Limitation | An allowed-but-vulnerable code passes | Cannot block (the verifier decides) |
| Representative | UEFI Secure Boot | TPM-based Measured Boot |
The two approaches are complementary. Using only Verified Boot cannot stop a "validly signed but vulnerable" bootloader (e.g., an old Baton Drop binary), while using only Measured Boot detects tampered code only after it has already run. Hence, in practice, Verified Boot provides first-line blocking, and Measured Boot plus remote attestation verifies even "which of the allowed things actually came up," forming a Defense-in-Depth posture.
3. Operating Mechanism — UEFI Secure Boot, TPM Measurement, Remote Attestation
The detailed diagram below, based on the x86 platform, shows together the flow in which the UEFI firmware verifies the bootloader signature with the key hierarchy (PK·KEK·db·dbx) and, at the same time, each stage's hash accumulates into the TPM PCRs and leads to remote attestation. The key point is that verification (solid lines) and measurement (dashed lines) run in parallel during the same boot process.
sequenceDiagram
participant FW as UEFI firmware
participant KEYS as key DB(PK·KEK·db·dbx)
participant BL as bootloader
participant TPM as TPM(PCR)
participant SRV as verification server
FW->>KEYS: look up bootloader signature
KEYS-->>FW: respond whether in db(allowed)·dbx(revoked)
alt signature valid and not in dbx
FW->>TPM: extend bootloader hash(PCR)
FW->>BL: hand over control(execute)
BL->>TPM: extend kernel·config hash(PCR)
else signature mismatch or listed in dbx
FW--xBL: halt boot(verified-boot block)
end
BL->>SRV: boot complete, trigger Quote request
TPM-->>SRV: submit signed PCR values(Quote)
Note over SRV: compare with golden values to judge trust
A. The UEFI Secure Boot key hierarchy
UEFI Secure Boot manages trust with four kinds of variables. The top-level PK (Platform Key) symbolizes the authority of the platform owner (OEM) and manages the KEK. The KEK (Key Exchange Key) is the authority key that can update db and dbx. The db (Signature Database) is the "allow list" of signers/hashes permitted to boot, and the dbx (Forbidden Signature Database) is the "revocation list" that blocks binaries judged vulnerable or malicious. The firmware executes a bootloader only when its signature is in db and not in dbx.
The reason this hierarchical structure matters is revocation (dbx) and separation of authority. When a particular bootloader becomes vulnerable, its hash can be added to dbx to block it worldwide — the same principle as certificate revocation. The Linux camp places a shim bootloader signed by the Microsoft UEFI CA so that a distribution can boot its own-key-signed GRUB and kernel under Microsoft's trust, securing interoperability. However, this structure depends entirely on the premise that the PK is managed securely.
The representative case in which that very premise was broken is PKfail in 2024. Binarly revealed that a Platform Key created by American Megatrends (AMI) for testing and explicitly marked "DO NOT TRUST" was shipped unchanged into about 813 products from Acer, Dell, HP, Lenovo, Supermicro, and others (firmware released from May 2012 to June 2024) (BRLY-2024-005). An attacker holding the private key of that leaked test PK can manipulate KEK, db, and dbx to neutralize Secure Boot. This event laid bare the essence of the chain of trust: "once key management at the root of trust collapses, all verification above it loses meaning."
B. Measured Boot and TPM PCR
The heart of Measured Boot is the TPM's PCR (Platform Configuration Register) accumulation record. Each stage computes the hash of the next code before executing it and records it into a PCR — not by overwriting, but by extending (accumulating) in the form PCR_new = Hash(PCR_old ‖ measurement). This operation is irreversible, so if any single stage of the boot process changes, the final PCR value changes completely. In other words, the PCR becomes an "unforgeable fingerprint of the boot history."
For example, PCR0–7 record measurements of firmware, option ROMs, configuration, and the bootloader, while higher PCRs record the OS loader and kernel measurements separately. Separating PCRs by stage this way allows later judgment that refines the point of tampering, as in "the firmware is fine but only the bootloader changed." The measurement records are kept together with an event log outside the TPM so that a verifier can reconstruct the meaning of each measurement.
C. Remote Attestation and anti-rollback
If measurements are kept only inside the device, they amount to a self-reference of "please trust me." Therefore the TPM signs the PCR values with an attestation key (AIK/AK) (a Quote) and submits them to a remote verification server, which compares them with golden measurements obtained in advance to judge whether the device booted into a trustworthy state. This is the core of backing device trust with a hardware basis in Zero Trust, and VM attestation in confidential computing (Intel TDX, AMD SEV-SNP) uses the same principle.
Meanwhile, the chain of trust must also defend against rollback (downgrade) attacks. To prevent attacks that revert to an old version of firmware/bootloader that is validly signed but already known to be vulnerable, anti-rollback is placed to enforce a minimum allowed version via a monotonic counter or fuses. Going further, NIST SP 800-193 (Platform Firmware Resiliency) defines firmware security along the three axes of Protection, Detection, and Recovery, demanding even resiliency — automatically recovering to a trustworthy backup when tampering is detected.
4. Comparison of Platform Implementations and Cases
The principle of the chain of trust is common, but where the root is placed and how verification is done differs by platform. Servers and PCs first verify the firmware itself with Intel Boot Guard / AMD PSB, which place the root in the CPU/chipset; mobile and embedded systems use a Boot ROM inside the SoC together with the ARM TrustZone / TF-A chain; and Apple, a closed ecosystem, builds a very robust chain with an immutable Boot ROM and the Secure Enclave. These differences reflect the trade-off between "how open and replaceable" and "how controlled and robust."
| Platform | Root of Trust | Verification chain | Characteristics |
|---|---|---|---|
| x86 PC/server | Intel Boot Guard·AMD PSB(fuses) | firmware→UEFI Secure Boot→bootloader | open·interoperable(shim), dbx revocation |
| ARM mobile/embedded | SoC Boot ROM | BL1→BL2→BL31→bootloader(TF-A) | TrustZone secure-world separation |
| Apple | immutable Boot ROM·Secure Enclave | LLB→iBoot→kernel | closed·highly robust, rollback enforced |
| Android | hardware RoT | Android Verified Boot(dm-verity) | partition integrity·rollback protection |
| Chromebook | read-only firmware | RO→RW(A/B)→kernel | recovery duplication·self-repair |
As a concrete case, Google Chromebook's Verified Boot takes read-only firmware as its root and keeps two copies of read/write firmware (A/B), so that if one is corrupted it automatically recovers via the other or via recovery mode — a product-level implementation of the "recovery" that NIST SP 800-193 describes. Android's AVB (Android Verified Boot) verifies the block-level integrity of the system partition with dm-verity and holds a minimum allowed version in vbmeta to block downgrades. Apple composes a chain in which, if even one signature from the Boot ROM to the kernel is off, it falls into recovery mode — making it, in effect, among the hardest commercial devices to tamper with.
5. In-Depth — Attacks and Bypasses of the Chain of Trust, and Recent Trends
As Secure Boot became widespread, attackers evolved toward targeting the "weakest link" of the chain. The first trend is bypass by re-planting an element that is validly signed but vulnerable. A typical example is BlackLotus (2023) reusing the Baton Drop (CVE-2022-21894) old bootloader to get past the Secure Boot of patched Windows 11; this left the lesson that "verification based solely on an allow list (db) is insufficient, and revocation (dbx) must be kept fresh." However, dbx updates can inadvertently render normal devices unbootable, so Microsoft had to respond with cautious, staged rollout (KB5025885, etc.).
The second trend is collapse of root/key management itself. PKfail (2024) revealed that if a test PK is left unattended in hundreds of models, then no matter how sophisticated the higher-level verification, everything collapses once the root key is shared or leaked. This implies that the risk of Secure Boot lies not in the cryptographic algorithm but in the operational problem of key lifecycle management (generation, injection, rotation, revocation).
The third trend is extension to lightweight, TPM-less IoT environments. The TCG's DICE (Device Identifier Composition Engine), for small devices without a dedicated security chip, feeds a chip-unique secret (UDS) and each layer's measurement into a key-derivation function to derive a per-layer Compound Device Identifier (CDI), thereby providing hardware trust and a device-unique identity at once. Because each layer erases its own secret after use as it transfers to the higher layer, a chain of trust and remote attestation can be implemented even on low-cost MCUs, so adoption is increasing in Android, confidential computing, and the like.
The fourth trend is crypto agility and the post-quantum transition. As RSA and ECDSA used for boot signatures become exposed to the quantum-computing threat, discussion is under way to design firmware and key structures so that the boot-verification algorithm can be replaced with post-quantum cryptography (PQC) such as ML-DSA. Replacing the root key and signature scheme entails large-scale re-signing and revocation, so reflecting the possibility of algorithm replacement in the chain of trust in advance is becoming increasingly important.
6. Considerations and Implications
First, Secure Boot should be evaluated not by "presence of the feature" but by "operation and revocation regime." As the BlackLotus case shows, even with Secure Boot on, it is bypassed if a vulnerable element cannot be revoked (dbx). Organizations should incorporate the freshness of firmware, bootloaders, and dbx into asset and patch management, and establish pre-validation and staged-rollout procedures so that revocation distribution does not brick normal devices.
Second, key management as the root of trust must be the top priority of control. As PKfail shows, sharing or leaking the root key neutralizes all higher-level verification. OEMs and operators should codify, as supply-chain security requirements, per-device unique PK generation, blocking of test keys from entering production, HSM-based signing, and key rotation/revocation procedures, and verify these at the procurement stage.
Third, run Verified and Measured Boot together to form Defense-in-Depth, and link remote attestation with Zero Trust. Block unauthorized code execution with Verified Boot, and use Measured Boot plus remote attestation to verify even "the state actually booted among the allowed ones" and apply it to device-trust decisions. This becomes more effective when integrated with MDM, conditional access, and confidential-computing attestation.
Fourth, resiliency must be included as a design element. In line with the Protection, Detection, and Recovery principles of NIST SP 800-193, a mechanism that automatically recovers to a trustworthy golden image upon detecting firmware tampering (duplication, a recovery region) must be in place to protect availability and security at once. Recovery automation is especially essential for unattended, remotely operated servers, OT, and IoT.
Fifth, invest proactively in lightweight RoT and crypto agility. To extend trusted computing to large-scale TPM-less IoT/edge, review lightweight RoT standards such as DICE, and in the long term design the boot-signature algorithm as a replaceable structure in preparation for the PQC transition. Recognizing that Secure Boot is not a one-time build but a matter of managing a Trust Supply Chain that continuously renews, attests, and recovers trust elements is the professional-engineer-level perspective.
References
- NIST, "SP 800-193: Platform Firmware Resiliency Guidelines", https://csrc.nist.gov/publications/detail/sp/800-193/final
- NSA, "BlackLotus Mitigation Guide" (2023.06), https://media.defense.gov/2023/Jun/22/2003245723/-1/-1/0/CSI_BlackLotus_Mitigation_Guide.PDF
- Binarly, "PKfail: Untrusted Platform Keys Undermine Secure Boot" (2024), https://binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem
- Binarly Advisory BRLY-2024-005, https://binarly.io/advisories/brly-2024-005
- Android Open Source Project, "Device Identifier Composition Engine (DICE)", https://source.android.com/docs/security/features/dice
In one line: Secure Boot is a chain that, starting from a hardware Root of Trust (RoT), transfers trust via "verify-then-execute" up through firmware, bootloader, and kernel; it must run UEFI Secure Boot (verified), TPM Measured Boot, and remote attestation together while also operating dbx revocation, key management, and resiliency (NIST SP 800-193) to stop bypasses like BlackLotus and PKfail.