Don't Panic: Embedded Secure Boot and Chain of Trust

A device starts with a rather awkward problem: before it can trust software, it has to run some software. Secure boot solves the part it can solve by starting in code and key material that ordinary firmware updates cannot replace. That first stage checks the next image before letting it run. Each checked stage can then check the one after it. There is your chain of trust, with considerably less ceremony than the name suggests.

The catch is at the beginning. If the first bootloader lives in writable flash and nothing checks it, an attacker can replace the referee. A perfectly signed application below it becomes a decorative feature. The root of trust is the protected starting point: often boot ROM or write-protected code plus a public key or key hash. The private signing key lives outside the device. The device needs to recognize authorized signatures, not produce them.

A signature is a permission slip for the covered bytes under a particular key. It is not a claim that the code is bug-free. It also is not a freshness stamp. An old image with a valid signature can be dangerous if that release has a known flaw. A security counter, stored where normal firmware cannot reset it, can set the oldest acceptable generation. This sounds tidy until a failed update needs the previous image and that image is now below the floor. Recovery and counter advancement need to be planned together.

Updates introduce another pair of jobs that look alike from a distance. The updater places a candidate in storage; the bootloader decides if it may execute. A second slot can preserve a previous image while the candidate starts. The candidate may need to confirm that it actually works. That confirmation helps availability. It does not make an old signed image safe against downgrade. The recovery image needs its own signature and policy check, because recovery code is still code.

On one board the chain might be ROM, bootloader, application. On another it might extend through a Linux kernel, device tree, and root filesystem. The names vary, but one question travels well: which protected stage checked this image before execution? If the answer disappears at any handoff, so does the chain.

For the compact map, open Slides. Use the Cheatsheet when you need the stage inventory and failure matrix. The Practice Reference turns that map into questions for a real board, and the Reference links take you to the platform-specific rules. Start with the board's own boot ROM and key-provisioning manual before touching irreversible device state.