Security, Bootloaders, and Updates
Firmware update design decides whether a deployed product can be improved safely or permanently broken remotely. Security starts with simple questions: what code is allowed to run, who can install it, how is failure recovered, and how are keys protected?
Learning Objectives
By the end of this lesson, you should be able to describe a secure boot chain, define bootloader responsibilities, compare update layouts, explain signing and rollback protection, and plan recovery for failed updates.
Threat Model
Start with realistic threats:
- unauthorized firmware installed over a field interface;
- corrupted image due to power loss or communication error;
- attacker downgrades firmware to a vulnerable old version;
- debug port exposes memory or keys;
- update server or package process is misused.
Security requirements should match product risk. A classroom board, medical device, payment terminal, and industrial controller do not need the same controls.
Secure Boot Chain
A secure boot process verifies the next stage before executing it. The root public key or hash must be protected from modification.
Bootloader Responsibilities
A production bootloader usually:
- initializes only hardware needed for update and validation;
- checks image header, size, version, target board, and checksum;
- verifies cryptographic signature before booting;
- manages update slots and rollback decision;
- provides recovery transport such as UART, USB, CAN, BLE, or network;
- records boot attempts and reset reasons.
Keep the bootloader small. Complex application features do not belong there.
Image Validation
Use CRC for accidental corruption and digital signatures for authenticity.
$$
CRC \rightarrow corruption\ check
$$
$$
Signature \rightarrow authenticity\ and\ integrity
$$
A typical image header includes magic value, image length, version, hardware ID, load address, entry point, hash, signature, and flags.
Update Layouts
| Layout | Benefit | Risk or cost |
|---|---|---|
| Single slot | small flash | power loss can brick without careful staging |
| Dual slot A/B | robust rollback | needs more flash |
| External download slot | flexible | external memory security needed |
| Delta update | small transfer | complex and harder to validate |
For critical products, prefer an A/B or recovery-capable layout.
Rollback and Version Policy
Rollback protection prevents installing an older vulnerable image. Store a monotonic security version in protected flash, option bytes, secure element, or trusted storage.
Be careful: blocking all downgrades can make service difficult. Separate security version from user-visible firmware version.
Key Handling
Private signing keys belong in a controlled release system, not in source code, firmware images, or developer laptops without protection. Devices usually store only public keys or certificates needed to verify signatures.
Worked Example: Failed OTA Update
A device downloads a new image into slot B, verifies hash and signature, marks slot B as pending, and reboots. The bootloader starts slot B and waits for the application to mark itself confirmed after health checks. If it resets repeatedly before confirmation, the bootloader returns to slot A and records the failure.
Common Mistakes
- Using CRC as if it proves authenticity.
- Updating in place with no recovery path.
- Keeping signing keys in the firmware repository.
- No rollback protection for known vulnerable versions.
- Enabling debug access on shipped units without controls.
Practical Checks
Test corrupted images, wrong hardware ID, old version, interrupted transfer, bad signature, full storage, repeated crash after update, and recovery mode entry. Confirm production images cannot be modified without failing verification.
Summary
Secure firmware updates require a trusted boot path, authenticated images, recovery from interruption, rollback policy, protected keys, and repeatable release tooling. The design is only credible after failure cases have been tested.
Further Reading
- MCUboot documentation and design notes.
- NIST SP 800-193 platform firmware resiliency guidance.
- Vendor secure boot and secure firmware update application notes.