eFuse
One-time-programmable bits blown into silicon. They store keys and set irreversible policy: Secure Boot, Flash Encryption, JTAG disable, download-mode locks. Reading the fuse map tells you which doors are still open.
An eFuse is a one-time-programmable (OTP) bit physically blown into silicon during manufacturing or provisioning. eFuses store keys and set irreversible security policy such as Secure Boot, Flash Encryption, and JTAG disable. Once a fuse is burned it cannot be reset, so the fuse map is the ground truth of how locked-down a chip is, and reading it tells you exactly which attack paths are still open.
What it is
A single eFuse is a microscopic structure (often a poly or metal link) that is intact from the factory and permanently altered by driving a programming current through it, flipping a bit from 0 to 1 for good. Chips group hundreds or thousands of them into named fields. On an ESP32, for example, the fuses hold the Flash Encryption and Secure Boot keys, the boot policy bits, and per-die identifiers, all in eFuse blocks. Some blocks are readable; the ones that hold secret keys have their read-back path disabled in the same silicon, so the key can be used by the hardware but never read out.
Why it matters
eFuses decide whether a device is wide open or hardened, and the decision is one-way. If JTAG_DISABLE and FLASH_ENCRYPTION are burned, the easy paths (debug port, raw flash dump) are closed and you must pivot to physical attacks. If they are un-burned, the flash is readable, the firmware is reversible, and the debug port is live. Because the fuse state is readable (on ESP32 over the serial download interface), your first move on a new target is to read it and learn the posture before spending effort on paths that may already be shut.
How it works
The security features anchor their trust in eFuses:
- Secure Boot burns a digest of the vendor's public key into a fuse block. At each boot the ROM checks the image signature against that immutable digest, so only signed firmware runs and the digest cannot be changed afterwards.
- Flash Encryption stores its AES key in a fuse block with read-back disabled. The flash controller decrypts transparently on fetch, but a raw chip dump yields only ciphertext because the key never leaves the die.
- Policy fuses are single bits: burn
JTAG_DISABLEand the hardware debug port is gone; burn the download-mode lock and the serial reflash path closes.
In practice (ESP32)
# Read the whole fuse summary over the UART download interface.
espefuse.py --port /dev/ttyUSB0 summary
# Look specifically at the security-relevant fields.
espefuse.py --port /dev/ttyUSB0 summary | grep -iE 'secure|encrypt|jtag|download'
Read the summary and decide:
- Secure Boot, Flash Encryption, and JTAG all un-burned means the board is open: dump the flash, reverse the app, patch and reflash.
- Any of them burned closes the matching offline path, and you pivot to fault injection, side-channel, or supply-chain angles.
Pitfalls
- Burning is irreversible. A fuse only goes one way. On a target you assess, never write fuses blindly; on your own lab board, understand a wrong burn can brick a path or the whole chip forever.
- Read-back disabled is not the same as absent. A key fuse can be present and in use yet unreadable. "I cannot read the key" does not mean encryption is off.
- Development vs release. A chip in a development or "reflashable encryption" mode is not fully hardened; check the exact fuse flags, not just "encryption on".
- Burned does not mean unbreakable. Fuses close the cheap logical paths; a well-resourced attacker still has glitching and invasive silicon attacks. They raise the cost, they do not make a device inviolate.