Secure Boot and Root of Trust
Verifying each stage of startup against a trusted anchor ensures a device runs only genuine, unaltered software from the moment it powers on.
Trust Has to Start Somewhere
Every security check must ultimately rest on something trusted without being checked, a root of trust. In a device, this is typically a small piece of immutable code or hardware, established at manufacture, that cannot be altered. From that anchor, trust is extended outward: each stage of startup verifies the next before handing off control, so the whole system boots from a foundation that cannot lie about itself.
The Chain of Trust at Boot
- The root of trust verifies the first-stage bootloader's signature
- That bootloader verifies the next stage before running it
- Each stage measures and verifies the following one
- Only genuine, signed code executes at each step; a failed check halts or recovers
Secure Boot vs Measured Boot
Secure boot enforces: if a component's signature does not verify, it does not run. Measured boot records: each stage's hash is logged into protected hardware (such as a TPM), producing evidence of exactly what booted, which a remote party can later check through attestation. The two are complementary, one prevents, the other proves.
Why It Matters
Without a verified boot, malware that installs below the operating system, in the bootloader or firmware, can hide from every defense that runs later, because it controls the environment those defenses run in. Secure boot closes this by refusing to run tampered low-level code in the first place.
Fusion Context
Controllers in the Hyperion breeder and burner designs verify their firmware and software against a hardware root of trust at startup, refusing to run anything unsigned or altered. Combined with signing keys held in hardware security modules and the fail-safe stance on failure, this ensures a device that cannot verify its software moves toward a safe state rather than executing untrusted code.