Security: Threats & Defense · Study deck
Secure Boot
Picture a sensor waking after a power cut.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- explain what secure boot actually proves about the first instruction after reset
- review a boot chain and its supporting evidence stage by stage
- Explain: 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.
- Explain: Overclaiming secure boot is a common review mistake.
Major section
Overview: What Secure Boot Actually Proves
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.
- Secure boot is a startup integrity control.
- The important idea is the size of that claim.
- Secure boot decides what is allowed to start.
- Approved code can still contain defects.
Major section
Overview: What Secure Boot Actually Proves (continued)
Overclaiming secure boot is a common review mistake.
- 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.
- Failure must be defined.
Major section
Overview: What Secure Boot Actually Proves (continued)
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.
- Memory safety, access control, and monitoring are separate controls.
Major section
Overview: What Secure Boot Actually Proves (continued)
The reviewer still needs to know which anchor, which images, and what happens on failure.
- 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.
- A device that refuses to run a tampered bootloader supports a startup-integrity claim, but it still needs patching for application bugs.
- "Secure hardware is enabled" is not a claim.
Major section
Practitioner: Review the Boot Chain and Its Evidence
This interpretation keeps Walkthrough: From Anchor to Accepted Code connected to the system behavior being designed.
- A secure boot review should produce concrete evidence rather than a single "enabled" label.
- Any validly signed image is accepted regardless of version.
- A gateway receives signed firmware and has a documented secure boot feature.
Major section
Practitioner: Review the Boot Chain and Its Evidence (continued)
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.
- The labels expose distinct stages or roles that together show the evidence record connects the trust anchor, signing custody, image verification, rollback state, failure behavior, and retest triggers.
- The claim under review is: the gateway only starts firmware approved by the release process.
- 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.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes
This propagation is the chain of trust.
- 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.
- A single unverified link breaks the chain even if every later stage is signed.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes (continued)
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.
- Most designs use asymmetric signing.
- Unverifiable code never runs.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes (continued)
A design may use one or both.
- 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.
- Unverified recovery image becomes a trusted bypass.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes (continued)
Measurement alone does not stop unverified code; it produces evidence for a separate decision.
- Verified boot enforces a policy: if a stage fails verification, the device halts or enters recovery rather than running the stage.
- Leaked key lets an attacker sign images that pass the check.
- Silent fallback executes untrusted code.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes (continued)
Recovery image is signed and verified by the same anchor rule.
- 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.
- The review should state which guarantee is actually present, because measurement without enforcement does not block startup by itself.
- Older vulnerable signed images are refused.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes (continued)
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.
- 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.
Major section
Under the Hood: Mechanisms, Keys, and Failure Modes (continued)
Ignoring rollback: Older firmware can still carry a valid signature, so anti-rollback needs its own state and test.
- 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.
- 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.
Major section
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.
Deck summary
Key takeaways
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.
- Overclaiming secure boot is a common review mistake.
- Think of a relay race where each runner must show a valid wristband before taking the baton.
- The reviewer still needs to know which anchor, which images, and what happens on failure.
- This interpretation keeps Walkthrough: From Anchor to Accepted Code connected to the system behavior being designed.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A vendor says a device has secure boot, so the firmware must be free of vulnerabilities. What is the strongest correction?
Show answer
Answer: D Secure boot is a startup-integrity control.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A device verifies the firmware signature at startup, but the review record shows no rollback state. Which conclusion is most evidence-bound?
Show answer
Answer: A Signature verification and rollback protection are related but separate claims.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A design stores the same fleet-wide private firmware-signing key on each device so devices can re-sign images during field updates. Why is this a high-risk custody choice?
Show answer
Answer: B Devices should verify with public material only; the private key belongs off-device in a controlled signing service so a single extraction does not forge accepted firmware.
Print reference
Answers
Answer key.
- D · Secure boot is a startup-integrity control.
- A · Signature verification and rollback protection are related but separate claims.
- B · Devices should verify with public material only; the private key belongs off-device in a controlled signing service so a single extraction does not forge accepted firmware.