Secure Boot
Each boot stage cryptographically verifies the next before running it, anchored in an immutable root of trust, so only vendor-signed firmware runs.
Secure Boot is a mechanism where each stage of the boot chain verifies the digital signature of the next stage before executing it, anchored in an immutable root of trust burned into the silicon.
What it is
Secure Boot turns the boot chain into a chain of trust. An unchangeable first link (mask ROM plus a key committed to one-time-programmable eFuses) checks the signature of the second-stage bootloader; the verified bootloader checks the signature of the application or kernel; and so on. Because the root is fixed in hardware, the attacker cannot simply replace the key, and because each stage refuses to run an unsigned or tampered next stage, a single trusted starting point extends trust across the whole boot.
Why it matters
Without Secure Boot, anyone who can write flash can replace the firmware with their own, which means a persistent implant survives every reboot and factory reset, and any offline modification runs on next boot. Secure Boot is the countermeasure: it ensures only vendor-signed images execute, so writing flash is no longer enough. It is normally deployed alongside Flash Encryption, and the pair is complementary: encryption stops the offline read, Secure Boot stops the offline write.
How it works
The ROM holds, or holds the hash of, a public key burned into eFuses. On ESP32 Secure Boot v2 verifies an RSA-3072 (or ECDSA on newer parts) signature at each stage; the public-key digest lives in an eFuse block and cannot be changed once burned. The signature is checked before control transfers, so a modified bootloader or app is rejected before it ever runs.
How to inspect or attack it
First, read whether it is actually enabled. On ESP32 the security eFuses tell you.
espefuse.py -p /dev/ttyUSB0 summary # look for SECURE_BOOT_EN, ABS_DONE, key digest
Secure Boot raises the bar but is not absolute. The productive angles are:
- Stages that are not actually verified: an OTA payload, a config partition, or a plugin loaded without a signature check.
- Downgrade or rollback to an older signed image with a known bug (unless anti-rollback fuses are burned).
- Debug or Secure Boot eFuses left un-burned in production, or a development-mode configuration that still allows re-flashing.
- ROM or bootloader implementation bugs: buffer overflows in the parser, or voltage/clock glitching (fault injection) to skip the signature comparison entirely.
Pitfalls
- Enabled is not the same as enforced. Confirm the fuses are actually burned, not just that the feature exists in the SDK.
- The signature only covers what the signer chose to sign. Everything outside that boundary (user data, some OTA metadata) is still attacker-controlled.
- Glitching against a real, burned Secure Boot is slow and probabilistic, but a single successful skip of the check is a full bypass. Do not assume a burned fuse closes the door completely.