Secure boot: a chain of signatures from the first instruction to the OS

Antivirus, EDR, disk encryption, and the kernel's own security checks all run inside the operating system. Code that runs before the OS (a modified bootloader, a firmware implant, a 'bootkit') can patch the kernel as it loads and hide from all of them. Reinstalling the OS doesn't remove an implant that lives in the boot partition or firmware.

Secure boot answers this with a chain of trust: every stage of the boot process verifies the signature of the next stage before running it. If each link checks the next, the whole chain is only as trustworthy as its first link, which is why that first link has to be something an attacker can't rewrite.

The chain has to start somewhere that isn't itself verified. On phones, embedded devices, and most modern SoCs, that is a small boot ROM baked into the silicon plus the hash of the manufacturer's public key burned into one-time-programmable fuses at the factory. The ROM loads the first mutable stage, checks that its public key hashes to the fused value, verifies the stage's signature, and only then jumps to it. Because neither the ROM nor the fuses can be changed after manufacture, malware can't substitute its own key.

On PCs the hardware root (vendor features such as boot guards) verifies the platform firmware, and UEFI Secure Boot then takes over for everything the firmware loads. NIST SP 800-193 describes the full goal as three properties: protect firmware from unauthorized change, detect when it has changed anyway, and recover to a known-good state.

UEFI Secure Boot keeps four variables in firmware storage. The Platform Key (PK), normally the device manufacturer's, is the owner: it authorizes changes to the KEK list. Key Exchange Keys (KEK) authorize changes to the two signature databases. The allowed database (db) holds certificates and hashes of code permitted to run; the forbidden database (dbx) holds revoked hashes and certificates, and always wins over db. Before running any UEFI executable (a bootloader, an option ROM on a graphics card), the firmware checks its Authenticode signature against db and its hash against dbx.

Nearly every PC ships with Microsoft's KEK and two Microsoft certificates in db: one for Windows' own boot manager and one, the 'UEFI CA', for third-party code. Linux distributions boot through a small first-stage loader called shim, which Microsoft signs under that third-party CA; shim carries the distribution's own certificate and verifies GRUB and the kernel against it, with a Machine Owner Key (MOK) list for keys the owner enrolls.

Verified boot (Secure Boot) is a gate: a stage that fails its signature check doesn't run. Measured boot is a record: each stage hashes the next before running it and 'extends' that measurement into a Platform Configuration Register (PCR) in the TPM. A PCR can't be written directly, only extended, so its final value commits to the exact sequence of everything that was measured, in order.

That record is useful in two ways. A remote verifier can ask the TPM for a signed quote of its PCRs (attestation) and decide whether the device booted known-good software. And the TPM can seal a secret to PCR values, releasing it only when they match: this is how TPM-based disk encryption unlocks automatically on an unmodified machine and refuses after a bootloader change. The two mechanisms complement each other: verified boot blocks unsigned code, while measured boot also catches signed-but-unexpected code, such as an old vulnerable bootloader.

Signatures stop unsigned code, but they do nothing about old signed code with a known bug. If an attacker can boot a validly signed but vulnerable bootloader, Secure Boot happily runs it. BootHole (CVE-2020-10713, 2020) was a buffer overflow in GRUB2's configuration parser; fixing it meant revoking a long list of signed shims and GRUB builds through dbx, which strained the limited firmware storage dbx lives in. Shim responded with SBAT, which revokes by component generation number instead of by individual hash.

BlackLotus (2023), the first publicly analyzed in-the-wild UEFI bootkit able to bypass Secure Boot on fully patched Windows, exploited exactly this gap: it brought along an older, legitimately signed Windows boot manager vulnerable to CVE-2022-21894. Fully blocking that path meant distrusting the certificate that signed years of Windows boot media, which Microsoft staged over several years (CVE-2023-24932) because doing it at once would have left machines and recovery media unbootable. Embedded platforms handle the same problem with anti-rollback counters: each image carries a security version, and the device refuses anything below a minimum stored in fuses or protected storage.