Secure Boot

At its core, Secure Boot validates every software component loaded during startup against a database of approved cryptographic signatures. The Platform Key (PK) establishes the root of trust, while the Key Exchange Key (KEK) database bridges the platform owner's authority to third-party signers. The Signature Database (db) contains the whitelist of authorized hashes and certificates, and the Forbidden Signature Database (dbx) explicitly revokes compromised or vulnerable bootloaders. This asymmetric cryptography ensures that only software signed with a trusted private key can execute, preventing bootkits and rootkits from embedding themselves below the operating system layer.

The chain of trust begins in immutable hardware. The Boot ROM or initial firmware is anchored in silicon, making it tamper-proof by physical design. This hardware root verifies the next stage's signature before passing execution control. Each subsequent stage—Pre-EFI Initialization (PEI), Driver Execution Environment (DXE), and finally the OS Boot Loader—is measured and verified in sequence. If any component fails verification, the boot process halts or falls back to a recovery path. This layered verification prevents firmware implants and ensures the integrity of the entire software stack from power-on.

Secure Boot enforces policy, while Measured Boot records what actually executed. Together, they provide both enforcement and auditability. During the boot sequence, cryptographic hashes of every loaded component are extended into Platform Configuration Registers (PCRs) within a Trusted Platform Module (TPM). This creates an unforgeable event log that a remote attestation service can later verify. An enterprise can enforce a policy that a device must not only pass Secure Boot verification but also present a known-good TPM quote before accessing corporate networks, enabling Zero Trust device posture assessment.

Platform owners can replace the default manufacturer keys with their own custom PK, KEK, and db entries. This Custom Secure Boot mode allows organizations to sign their own Linux kernels, custom drivers, or proprietary bootloaders. In a data center, this enables a golden image strategy where only an organization's signed OS images will boot on any server. Key management utilities allow for the secure enrollment of new keys and the revocation of old ones, ensuring that decommissioned signing keys cannot be used to authorize malicious software on production hardware.

Secure Boot extends its protection to the firmware update mechanism itself. Capsule Updates and UEFI Update Firmware protocols require that firmware payloads be cryptographically signed and verified before being written to flash memory. This prevents supply chain attacks where a compromised firmware update tool could inject malicious code. The update process typically involves a two-phase commit: the new firmware is staged, its signature is verified against the current db, and only upon successful verification is it committed, with a rollback capability if the update fails or is interrupted.

A robust Secure Boot implementation includes defined recovery paths. If the system fails to boot due to a corrupted bootloader or a revoked signature, it can enter a Recovery Mode that loads a minimal, trusted recovery image. Additionally, a Factory Reset option can restore the original manufacturer key databases, removing all custom keys. This is critical for decommissioning or repurposing hardware. The Audit Mode allows a system to boot without enforcement while logging all verification failures, enabling administrators to debug boot issues without permanently disabling security.

The unconditionally trusted hardware or firmware component that forms the first link in the boot-time security chain. It is the foundation upon which all subsequent verification steps depend.

• Hardware RoT (HRoT): Immutable logic burned into silicon (e.g., Boot ROM).
• Firmware RoT: The first mutable code executed, cryptographically verified by the HRoT.
• Key Provisioning: The RoT stores the OEM public key hash used to verify the initial firmware signature.
• Compromise Impact: If the RoT is subverted, the entire chain of trust collapses, enabling undetectable bootkits.

A process distinct from Secure Boot that records cryptographic hashes of boot components into Platform Configuration Registers (PCRs) within a Trusted Platform Module (TPM). It does not enforce a policy; it creates an audit log.

• Integrity Measurement Architecture (IMA): Extends measurement to the OS and application runtime.
• TPM Quote: A remote party can request a signed attestation of the PCR values to verify the boot state.
• Comparison: Secure Boot enforces a policy (allow/block), while Measured Boot provides a tamper-proof log for remote evaluation.

A cryptographic challenge-response protocol that allows a relying party to verify the identity and integrity of a remote platform's software stack. It relies on the hardware RoT to sign a statement about the current boot state.

• Attestation Flow: A challenger sends a nonce; the device's TEE or TPM signs the nonce along with the current PCR values.
• Trusted Execution Environment (TEE): Provides a secure enclave for performing attestation without the host OS interference.
• Agentic Relevance: In multi-agent systems, remote attestation ensures that a peer agent is running an uncompromised, expected software stack before establishing a secure channel.

The industry-standard implementation defined by the UEFI Forum. It verifies the digital signature of bootloaders and Option ROMs against a database of trusted keys before execution.

• db (Authorized Database): Contains public keys and hashes of permitted boot components.
• dbx (Forbidden Database): A revocation list of known-bad or vulnerable bootloaders.
• Machine Owner Key (MOK): Allows the device owner to enroll custom keys to sign locally compiled kernels or drivers, extending trust beyond the OEM.

A dedicated physical computing device that safeguards and manages digital keys for strong authentication. In the Secure Boot context, it protects the private signing keys used to sign boot artifacts.

• Key Generation: HSMs generate high-entropy key pairs within a tamper-resistant boundary.
• Signing Operations: The private key never leaves the HSM; the module performs the cryptographic signature internally.
• FIPS 140-2/3: HSMs are typically certified to these federal standards, ensuring physical and logical protection against extraction.

A formal, machine-readable inventory of all components, libraries, and dependencies that make up a software artifact. It is a prerequisite for verifying the integrity of a boot chain.

• SPDX/CycloneDX: Standardized formats for representing SBOM data.
• Integrity Verification: An SBOM provides the expected hashes for each component, enabling comparison against the actual measured artifacts during boot.
• Vulnerability Management: Allows automated scanning of the boot stack for known CVEs before granting attestation.