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: Secure boot is a startup integrity control.
- 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.
Major section
Overview: What Secure Boot Actually Proves
Secure boot is a startup integrity control.
- The important idea is the size of that claim.
- Secure boot decides what is allowed to start.
- Overclaiming secure boot is a common review mistake.
- A failed check should stop or recover, never silently continue.
Major section
Overview: What Secure Boot Actually Proves (continued)
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.
- 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.
- Failure must be defined.
Major section
Overview: What Secure Boot Actually Proves (continued)
On a failed check the device should halt, enter a verified recovery image, or log and alert, not fall back to unverified code.
- If any runner cannot prove a valid band, the baton is not passed.
- Approved code can still contain defects.
- Memory safety, access control, and monitoring are separate controls.
Major section
Overview: What Secure Boot Actually Proves (continued)
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.
- 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
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.
- Any validly signed image is accepted regardless of version.
Major section
Practitioner: Review the Boot Chain and Its Evidence (continued)
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.
- This interpretation keeps Walkthrough: From Anchor to Accepted Code connected to the system behavior being designed.
- 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.
Major section
Practitioner: Review the Boot Chain and Its Evidence (continued)
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.
- 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.
- The rollback and custody claims stay open until the missing records are supplied.
- If you can review a boot chain and scope the claim to the evidence, you can stop here.
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.
- Anti-rollback rejects older signed images, which is different from recovery revert to a known-good image.
Deck summary
Key takeaways
Secure boot is a startup integrity control.
- 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.
- On a failed check the device should halt, enter a verified recovery image, or log and alert, not fall back to unverified code.
- 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 secure boot review should produce concrete evidence rather than a single "enabled" label.
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 private signing key on each device so the device can re-sign images during field updates. Why is this a high-risk custody choice?
Show answer
Answer: A 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.
- A · 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.