20 Secure Boot
Root of Trust, Chain Verification, Signing, and Rollback Evidence
IoT secure boot, firmware integrity, hardware root of trust, bootloader verification, firmware signing evidence, anti-rollback protection, signing key custody
20.1 Start With the First Instruction After Reset
Picture a sensor waking after a power cut. Before it joins the network, reads a key, or starts an application, one tiny trusted part of the device decides what code is allowed to run next. If an old image, a changed bootloader, or an unsigned recovery build is present, the device needs a clear answer before it hands over control.
Start simple: name the anchor, name the next image it checks, name the signature or digest it expects, and name the failure behavior. Then follow the baton from stage to stage. Secure boot becomes understandable when each handoff has a verifier, an approved image, a rollback rule, and evidence that an unverified stage did not run.
20.2 Overview: What Secure Boot Actually Proves
Secure boot is a startup integrity control. When the device powers on, a small trusted anchor checks the next piece of code before letting it run, and each verified stage checks the stage after it. The result is a narrow but valuable claim: the device started from a code state that the release process approved.
The important idea is the size of that claim. Secure boot decides what is allowed to start. It does not prove the approved firmware is free of bugs, that runtime credentials are safe, or that the network is trustworthy. Overclaiming secure boot is a common review mistake.
A reviewer should therefore ask for a bounded claim and the evidence behind it. Useful records name the immutable anchor, the images checked before execution, the signing authority, the rollback rule, and what the device does when verification fails.
If you only need the intuition, this layer is enough: secure boot is a chain of checks that begins at an unchangeable anchor and refuses to hand control to code it cannot verify. A failed check should stop or recover, never silently continue.
Think of a relay race where each runner must show a valid wristband before taking the baton. The first official is trusted and cannot be replaced. If any runner cannot prove a valid band, the baton is not passed. Secure boot is that rule applied to boot stages: the root of trust verifies the bootloader, the bootloader verifies the firmware, and an unverifiable stage stops the race.
20.2.1 The One-Minute View
It verifies a chain
An immutable anchor checks the first mutable code; each verified stage checks the next before passing control.
It is not runtime security
Approved code can still contain defects. Memory safety, access control, and monitoring are separate controls.
Failure must be defined
On a failed check the device should halt, enter a verified recovery image, or log and alert, not fall back to unverified code.
20.2.2 Beginner Examples
- A device that refuses to run a tampered bootloader supports a startup-integrity claim, but it still needs patching for application bugs.
- A device that verifies the firmware signature but silently boots old firmware on failure has not implemented a controlled failure path.
- “Secure hardware is enabled” is not a claim. The reviewer still needs to know which anchor, which images, and what happens on failure.
20.2.3 Overview Knowledge Check
If you can state what secure boot does and does not prove, you can stop here. Continue to Practitioner to review a real boot chain and its evidence.
20.3 Practitioner: Review the Boot Chain and Its Evidence
A secure boot review should produce concrete evidence rather than a single “enabled” label. The strongest record names the trust anchor, the verified images, the signing policy, the rollback state, and the failure behavior, and it includes a deliberate failed-verification test.
20.3.1 Walkthrough: From Anchor to Accepted Code
- Name the root of trust. Identify the exact item trusted before any mutable code runs: boot ROM, a one-time-programmable key digest, or a secure element.
- List the verified images. State which bootloader, firmware, configuration block, and recovery image are checked before execution.
- Check signing and custody. Confirm the device verifies with public material and that the private signing key is held off-device.
- Check rollback state. Confirm how an older but still-signed image is rejected, and where the minimum accepted version is stored.
- Check failure behavior. Confirm what happens on a failed check: halt, verified recovery, safe mode, log, or alert.
- Record limits and retest triggers. Note what the evidence does not cover and which changes reopen the review.
20.3.2 The Secure Boot Evidence Record
20.3.3 Worked Review Record
A gateway receives signed firmware and has a documented secure boot feature. The claim under review is: the gateway only starts firmware approved by the release process.
Evidence observed
A root of trust and first bootloader check are recorded; the application image is signed; the device stores public verification material; failed application verification enters a verified recovery image.
Evidence gaps
No record shows how older signed images are rejected; signing logs do not identify the release request; retest triggers for signing-key and bootloader changes are undefined.
Conclusion
Accept only the partial claim: verified bootloader and firmware handoff with controlled failure. The rollback and custody claims stay open until the missing records are supplied.
20.3.4 Practitioner Knowledge Check
If you can review a boot chain and scope the claim to the evidence, you can stop here. Continue to Under the Hood for the verification mechanisms and failure modes.
20.4 Under the Hood: Mechanisms, Keys, and Failure Modes
The deeper layer explains how each boot-chain check works and why each is a separate guarantee. The chain is only as trustworthy as its anchor, its keys, and its failure path.
20.4.1 Root of Trust and Chain of Trust
The root of trust is the earliest element the device treats as trusted without checking it, so it must be effectively immutable. In practice this is boot ROM, a public-key hash burned into one-time-programmable (OTP) fuses, or a secure element. The root verifies the first mutable bootloader before executing it, and verification then propagates stage by stage: bootloader verifies firmware, firmware verifies the next image, and so on. This propagation is the chain of trust. A single unverified link breaks the chain even if every later stage is signed.
20.4.2 Signature Verification
Most designs use asymmetric signing. The release process signs an artifact with a private key; the device verifies the signature using the corresponding public key. Because public material cannot create valid signatures, it is safe to store on the device, often as a key or a hash of the public key in OTP. Two facts follow:
- The private signing key must stay off-device, in a hardware security module or controlled signing service. A private key on the device would let an attacker who extracts it sign images that pass the check.
- A valid signature proves only that the signing process approved the artifact. It does not prove the artifact is defect-free or that the signing key was used appropriately, which is why signing logs and key custody are part of the evidence.
20.4.3 Verified Boot Versus Measured Boot
Two related mechanisms are easy to confuse:
- Verified boot enforces a policy: if a stage fails verification, the device halts or enters recovery rather than running the stage.
- Measured boot records a measurement (for example, a hash of each stage into a protected register such as a TPM PCR) so a later attestation step can judge the state. Measurement alone does not stop unverified code; it produces evidence for a separate decision.
A design may use one or both. The review should state which guarantee is actually present, because measurement without enforcement does not block startup by itself.
20.4.4 Anti-Rollback
Rollback protection stops a device from accepting an older image that is still correctly signed but no longer acceptable, for example because it reintroduces a fixed weakness. The usual mechanism is a monotonic security version: the device stores a minimum accepted version (often in OTP or protected non-volatile memory) and rejects any image whose version is below it. Keep two cases distinct:
- Recovery revert returns to the last known-good image because a candidate failed its checks. This is allowed and desirable.
- Downgrade attack installs an older signed image to reopen a known weakness. This is what anti-rollback must block.
20.4.5 Recovery, Keys, and Failure
A recovery image is a frequent blind spot: if it is not verified by the same trust rule, it becomes an unreviewed bypass. Signing keys also need a lifecycle, since the signing key is often the most valuable operational asset in the design.
20.4.6 Common Pitfalls
- Treating secure boot as runtime security. It controls startup state, not memory safety, authentication, or monitoring.
- Signing without custody. A signature is only as strong as the control over the signing key and its audit trail.
- Forgetting the recovery path. An unverified recovery or maintenance image can bypass the whole chain.
- Ignoring rollback. Older firmware can still carry a valid signature, so anti-rollback needs its own state and test.
20.4.7 Under-the-Hood Knowledge Check
At this depth, secure boot is a chain of independent guarantees: an immutable anchor, staged verification, off-device signing custody, anti-rollback state, a verified recovery path, and a defined failure behavior. A trustworthy review records each link instead of accepting a single “secure boot enabled” label.
20.5 Summary
- Secure boot is a startup-integrity control: an immutable anchor verifies each boot stage before it runs.
- It proves which code state is allowed to start, not that the approved firmware is defect-free.
- Asymmetric signing lets the device verify with public material while the private key stays off-device.
- Verified boot enforces on failure; measured boot only records measurements for later attestation.
- Anti-rollback rejects older signed images, which is different from recovery revert to a known-good image.
- A complete review records the anchor, verified images, signing custody, rollback state, recovery handling, failure behavior, and retest triggers.
Secure boot protects device trust only when the root of trust, signing-key custody, verification stages, rollback rules, recovery handling, and failure behavior are all managed and evidenced, not when a single “enabled” flag is set.
20.6 See Also
See how signed updates deliver the firmware that secure boot later verifies at startup.
Review the physical-access assumptions behind the root of trust and key storage.
Cyber Security Defense in Depth
Place boot integrity alongside the other independent controls in a layered design.