Demo Architecture: End-to-End Secure Boot Design

Reference architecture: secure boot for embedded Linux IoT device

Target profile:

• ARM SoC with immutable ROM and OTP/eFuses
• U-Boot as second-stage bootloader
• Signed kernel + DTB (+ optional initramfs) via FIT
• dm-verity protected rootfs (A/B update)
• TPM for measured boot and attestation

Boot sequence and trust anchors

1. ROM verifies FSBL using fused root key hash.
2. FSBL verifies U-Boot and enforces anti-rollback counter.
3. U-Boot verifies FIT signature (kernel, DTB, initramfs).
4. U-Boot extends measurements to TPM PCRs.
5. Kernel boots and mounts verity-protected rootfs.
6. User-space agent reports measurements / attestation evidence.

Key placement

• Root of trust: OTP/eFuse hash
• Boot verification public keys: embedded in boot chain policy
• Release signing private keys: off-device signer service/HSM
• Device identity/sealed secrets: TPM NV / sealed blobs

Verification checkpoints

• Checkpoint A: ROM -> FSBL signature + version
• Checkpoint B: FSBL -> U-Boot signature + version
• Checkpoint C: U-Boot -> kernel/DTB/initramfs FIT signature
• Checkpoint D: Kernel -> rootfs integrity (dm-verity)
• Checkpoint E: Runtime -> attested measured state

Failure response behavior

• Signature fail at any checkpoint: halt + explicit code + optional fallback slot
• Rollback violation: refuse older image even if correctly signed
• Rootfs integrity fail: mount denied, fallback/recovery policy engaged

Manufacturing provisioning (optional flow)

1. Program OTP root key hash
2. Lock lifecycle to production profile
3. Verify lock + key readback
4. Install initial signed image set
5. Run secure boot self-test and record proof

Lightweight pseudo-demo walk-through

1. Build and sign FIT (kernel + dtb).
2. Boot once successfully with valid signature.
3. Modify DTB byte to simulate tamper.
4. Reboot and observe U-Boot signature failure.
5. Show fallback slot behavior or controlled halt.

Practical takeaway

A secure boot design is only complete when boot, provisioning, and update/recovery paths all enforce the same trust policy.

Misconception to correct

"Verified boot alone covers the whole product."
You still need provisioning controls, measured evidence, and robust update/recovery behavior.