What does secure boot do, and how does its flow protect an IoT device?
It prevents compromised firmware from ever executing, by checking the integrity and authenticity of each stage of the boot process and diverting to a recovery boot if any check fails.
* Missing firmware or failed verification leads to recovery; successful verification permits execution. Recovery code must also be authenticated. *
The threat is direct: an attacker can attack the device's internal assets by modifying the firmware or the application. Protecting data inside the device therefore requires a mechanism guaranteeing that code and data are protected from unauthorised access — and the earliest possible point to enforce that is before the code runs at all.
The boot flow:
- Start
- System initialisation
- Find firmware? — if no → recovery boot
- Load firmware to SRAM — the image is copied from flash into RAM
- Verification — check integrity and authenticity of this stage
- Pass? — if no → recovery boot; if yes → firmware execution
The hardware it runs on is minimal: a host CPU that runs the firmware and applications, flash that stores the firmware image and applications, and SRAM used to load the firmware from flash.
Two details are worth dwelling on. First, verification happens after loading into SRAM but before execution — so what is checked is the image that will actually run, not the one sitting in flash. Second, the failure path is recovery boot rather than a halt: a device that bricks itself on a verification failure is as unavailable as one that was successfully attacked, so the design keeps a known-good fallback. Recovery code must also be authenticated: recovery must not bypass the trust anchor. Secure boot checks authorised code; it does not prove that signed code has no vulnerabilities.
There is also a cryptographic constraint. ECC or RSA can exceed the budget of some small devices, but are not universally unsuitable for IoT. A hash-based signature scheme is one alternative; compare its code size, latency, signature size and signing-state requirements on the actual hardware.
Tip: secure boot and signed firmware updates are two halves of one control. Signing stops a bad image being accepted; secure boot stops a bad image being run, including one written by an attacker with physical access to the flash.
Go deeper:
Wikipedia — Chain of trust — the general form of what secure boot does: each stage validated against a root trust anchor before it is allowed to run the next.