Secure Boot and the Embedded Chain of Trust
Secure boot is the mechanism that decides whether a device will run only the firmware you signed, or anything an attacker hands it. Done right, it is the single control that makes most firmware attacks pointless. Done almost right, it is theater. Here is how the chain of trust works, how to prove it actually catches tampering, and the three ways it quietly fails.
What Secure Boot Actually Promises
Secure boot promises one thing: that every piece of code which runs on the device was signed by a key you control. It does this as a chain. Immutable code in ROM verifies the bootloader, the bootloader verifies the kernel, the kernel verifies the filesystem. Break any link and everything after it runs unchecked, which is why a chain of trust with one unsigned stage provides no protection at all.
Step 1: Anchor Trust in ROM
The root of trust has to be something an attacker cannot rewrite. That means boot code in mask ROM and a public key, or a hash of one, burned into one-time-programmable fuses. If the root key lives in rewritable flash, an attacker simply replaces it with their own and signs whatever they like. The anchor must be immutable, or it is not an anchor.
Step 2: Each Stage Verifies the Next
At every handoff, the current stage checks a signature over the next one before jumping to it. That check is an asymmetric signature verification, the same primitive you can run by hand:
openssl dgst -sha256 -verify pub.pem -signature fw.sig fw.bin
Verified OK
Verified OK means the image matches the signature made with the matching private key. The bootloader does exactly this, and refuses to boot anything that does not pass.
Proving It Catches Tampering
The test that matters is the negative one. Flip a single byte in the image and the verification has to fail, or the signature is not actually protecting anything:
# corrupt one byte, then re-verify
printf '\xff' | dd of=fw.bin bs=1 seek=1024 count=1 conv=notrunc
openssl dgst -sha256 -verify pub.pem -signature fw.sig fw.bin
Verification Failure
One byte changed, and the check rejects the image. That is the whole point of secure boot, and it is exactly the behavior to confirm on real hardware rather than assume from a datasheet.
Where Secure Boot Breaks
In practice the cryptography is rarely the problem. The failures are in how the chain is assembled:
Rollback Protection Is Not Optional
Even a perfect signature check is defeated if an attacker can install an older, still-signed firmware with a known vulnerability. Rollback protection closes this by recording a minimum version in fuses or a monotonic counter and refusing anything older. Without it, every bug you ever patched is one downgrade away from coming back.
Where This Fits
Reviewing the chain of trust, confirming the root is truly immutable, and proving that tampering and downgrades are actually rejected is core to both a product security assessment and a penetration test. That verification is the kind of work we do at Berkner Tech.