Secure Boot

Each firmware binary—from the Platform Key (PK) through the Key Exchange Key (KEK) to the bootloader and OS kernel—is hashed and verified against a trusted certificate store. The UEFI firmware checks the signature against the Signature Database (db) before allowing execution. If a hash is not authorized or a certificate is revoked in the Forbidden Signature Database (dbx), the component is blocked. This prevents rootkits and bootkits from injecting malicious code during the pre-OS phase.

The verification chain is anchored in immutable hardware, typically the UEFI firmware stored in SPI flash, which contains the initial Platform Key. This creates an unbroken Chain of Trust where:

• Stage 0: Hardware initializes and loads UEFI firmware
• Stage 1: UEFI verifies the bootloader's signature
• Stage 2: Bootloader verifies the OS kernel
• Stage 3: OS kernel can extend verification to drivers

Without a hardware anchor, software-only verification can be bypassed by replacing the initial verification code itself.

Secure Boot uses a hierarchical key infrastructure defined by the UEFI specification:

• Platform Key (PK): The top-level key, owned by the platform owner. Controls access to the KEK.
• Key Exchange Key (KEK): Held by OS vendors and device manufacturers. Updates the signature databases.
• Signature Database (db): Whitelist of authorized certificates and hashes.
• Forbidden Signature Database (dbx): Blacklist of revoked certificates and known-bad hashes.

This hierarchy allows the platform owner to delegate update authority while maintaining ultimate control over which keys are trusted.

Secure Boot integrates with hardware-backed anti-rollback protection to prevent attackers from downgrading firmware to a vulnerable, previously-signed version. The system maintains a monotonic version counter in non-volatile storage. During the update process:

• The new firmware image must have a version number greater than the current counter
• The counter is incremented only after successful signature verification
• Any attempt to flash an older, signed image is rejected

This closes the attack vector where a validly-signed but vulnerable bootloader is reintroduced to exploit known CVEs.

Enterprise and sovereign deployments can replace the default Microsoft or OEM keys with their own custom PK and KEK certificates. This enables:

• Full control over which operating systems and bootloaders are authorized
• Air-gapped systems to operate without any third-party certificate authority dependency
• Supply chain integrity by ensuring only internally-signed firmware executes

Platforms can be provisioned in Setup Mode where no PK is enrolled, allowing a first-boot enrollment of custom keys. Once the PK is written, the platform exits Setup Mode and enforces signature verification permanently.

Secure Boot verifies signatures; Measured Boot records what executed. Together they provide both enforcement and auditability. During a measured Secure Boot:

• Each component's hash is extended into a TPM Platform Configuration Register (PCR)
• The TPM records the exact firmware versions loaded
• A Remote Attestation server can later verify the boot log against the PCR values

This pairing ensures that a system not only booted securely but can prove its integrity state to a remote verifier—critical for zero-trust network access policies where device health determines access rights.