Secure boot, firmware signing and secure updates

The problem secure boot solves

If a device will run any firmware it is given, then anyone who can write to its flash memory, through a debug port, a flawed update service or a stolen update file, owns it permanently. They can add a backdoor that survives reboots and factory resets. Secure boot closes that gap: the device runs only code that carries a valid digital signature from the manufacturer.

Chain of trust

Secure boot starts from a root of trust: a small piece of code in mask ROM (read-only memory set during chip manufacture) and a public key, or a hash of it, burned into one-time-programmable fuses. Because neither can be changed, an attacker cannot replace them. The ROM verifies the bootloader's signature; the bootloader verifies the firmware; the firmware may verify the application or a file system. If any check fails, the device stops or falls back to a recovery image.

Signatures use asymmetric cryptography, typically ECDSA (Elliptic Curve Digital Signature Algorithm) on P-256 or RSA-3072. The device holds only the public key, so reading it out gives an attacker nothing. The private signing key is the crown jewel and should live in an HSM (hardware security module) or a well-controlled signing service, never on a developer laptop.

Secure boot proves authenticity, not secrecy. To stop someone from reading your firmware and extracting secrets, add flash encryption, which many microcontrollers offer with a device-unique key held in fuses.

Signing and verifying firmware

The commands below show the idea using OpenSSL on your build machine. Real products use their chip vendor's tools or a bootloader such as MCUboot, but the steps are the same: generate a key pair, sign the image hash, and verify with the public key.

# create a P-256 signing key (keep it offline or in an HSM)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out signing_key.pem
openssl pkey -in signing_key.pem -pubout -out signing_pub.pem

# sign the firmware image
openssl dgst -sha256 -sign signing_key.pem -out firmware.sig firmware.bin

# verify, as the device bootloader would
openssl dgst -sha256 -verify signing_pub.pem -signature firmware.sig firmware.bin

Designing secure updates

• A/B (dual-bank) partitions. Write the new image to the inactive slot while the old one keeps running. Switch only after verification, and boot back to the old slot if the new one fails a health check.
• Anti-rollback. Store a security version counter in fuses or protected storage and refuse images older than it. Otherwise an attacker can install an old signed image that still has a known flaw.
• Signed manifests. Sign metadata that says which device type, hardware revision and version the image is for, so a valid image for one product cannot be loaded on another. The IETF SUIT work describes this approach for constrained devices.
• Delta and resumable downloads save battery and data on cellular or LPWAN links.
• Staged rollout. Release to a small percentage of the fleet first and watch for failures before going wide.

Tip: plan key compromise from day one. Support more than one trusted key or a way to revoke a key, otherwise a leaked signing key means every device must be recalled.

Common mistakes

1. Enabling secure boot in development but forgetting to burn the production fuses, so it is never actually enforced.
2. Verifying the signature, then reading the image again from flash before running it, giving an attacker a window to swap it.
3. Leaving JTAG open, which can bypass all boot checks.
4. Shipping a single shared encryption key in every device's firmware.
5. No recovery path, so a power cut during an update bricks the device.