Secure Boot Chain Animation

Trace how each trusted boot stage verifies the next before an IoT device runs code

animation
security
secure-boot
firmware
code-signing
anti-rollback
root-of-trust
iot-security
interactive
A standalone secure boot chain lab with platform, attack, trust-anchor, and fail-secure response controls; staged boot verification; synchronized SVG trust chain; signature, hash, anti-rollback, and production policy checks; technical accuracy notes; common misreads; and mobile-friendly independent learning support.
Secure boot Chain of trust Firmware integrity

Each boot stage earns the right to run.

Start from an immutable root key, verify each mutable image before control transfers, and see where tampering, rollback, revoked keys, and production-policy failures stop the boot.

Boot halted Final boot result
Kernel gate First failed check
Fail secure Device response
Production root Trust anchor

Secure boot chain controls and verification outputs

Secure Boot Chain Lab

Step through the verification boundary. The diagram, manifest, policy checks, and boot log update together so the chain-of-trust decision stays explicit.

ROM anchors the chain of trust

The first code is immutable. It holds or derives a trusted public-key hash and only transfers control to a signed first-stage bootloader.

Boot blocked
Secure boot verification chain ROM, bootloader, boot manager, operating system, application, and production policy gates form a secure boot chain. ROM immutable fused key hash BL1 first loader signature BL2 boot manager slot metadata Kernel hash + signature version check App bundle verify launch policy HALT kernel TRUST Manifest record: kernel.img, signer=OEM-prod, sec_ver=5, hash=sha256:7b4a..., sig=valid Device counter=5, debug=locked, response=halt on failed verification Control transfers only after verification passes. The private signing key is not stored on the device.
Image Manifest

The manifest binds the image hash, signer, version, and policy fields to the signature.

Imagekernel.img
SignerOEM production
Security ver.5
Hashmatches image
Verification Trace

Secure boot is a sequence of cryptographic and policy gates, not a single checksum.

1
Signature checkedPublic key validates the signed digest.
2
Rollback checkedSigned version is not below the device counter.
3
Boot blockedThe chain stops before untrusted code runs.
Boot Log

ROM verified BL1, BL1 verified BL2, BL2 detected a kernel hash mismatch and refused to transfer control.

Deviceindustrial gateway
Failurekernel gate
Responsehalt before OS
Playback

Use Play for the complete boot or Step for slow inspection of each trust boundary.

Platform

Different devices name the stages differently, but the trust-chain pattern is the same.

Device class
Injected Condition

Try the common ways a boot chain breaks.

Boot image condition
Trust Anchor

The device verifies with public keys or key hashes. Private signing keys stay off-device.

Key state
Fail-Secure Response

A recovery path is safe only if it is independently verified before execution.

Failure behavior
What To Watch
  • Trust flows forward: each verified stage checks the next image before jumping to it.
  • Hash plus signature: a modified image produces a different digest, so the signature check fails.
  • Rollback protection: an old image can still have a valid signature, so a monotonic version check is needed.
Technical Accuracy Notes
  • The public key, certificate, or key hash is used for verification; the private signing key is not stored on the device.
  • Debug lock, flash encryption, runtime memory safety, and attestation are separate controls that complement secure boot.
  • Recovery mode must verify its own image and update package, or it becomes a bypass around the secure boot chain.
Practice Prompts
  1. Select Clean boot and explain why every stage can transfer control.
  2. Select Old signed image. Identify why signature validity alone is not enough.
  3. Select Signer revoked. Decide whether this is a hash failure, key trust failure, or runtime failure.
Common Misreads

"Secure boot encrypts firmware" is not necessarily true. Secure boot verifies authenticity and integrity. Confidentiality usually comes from a separate flash-encryption feature.

"A valid signature means the newest image" is also incomplete. A stolen old image may be validly signed, so production devices commonly compare a signed security version against monotonic storage.

Related Interactive Tools

Continue with OTA Firmware Update Process, OTA Update Flow Visualizer, Replay Attack Prevention, Certificate Lifecycle, and Security Attack Visualization Suite.