Secure boot and firmware signing: the chain of trust, link by link

“Our firmware is signed.” The sentence is reassuring, and it says almost nothing. Signed by what? Verified when? By which code, with which key, stored where? And what happens if verification fails?

A signed firmware that nobody verifies at boot provides no guarantee. It is one of the flaws we have participants work on in our trainings, because it is common and is far better understood by bypassing it yourself.

Three mechanisms not to confuse

Update signing verifies that a received firmware really comes from the manufacturer before installing it.

Secure boot verifies, at every boot, that the code about to run is authentic.

Memory encryption prevents reading the firmware stored in the device.

The first two provide authenticity. The third provides confidentiality. A product can have one without the others, and that is often where the flaw lies. An encrypted but unsigned firmware can be replaced. A signed but unencrypted firmware can be read.

The chain of trust

The principle of secure boot fits in one sentence: each boot stage verifies the next one before handing over control.

1. The root of trust. Immutable boot code, written into the microcontroller at the factory, and a public key (or its hash) burned into a one-time programmable area.
2. The bootloader. The root verifies its signature with that key. If it is valid, it runs.
3. The application. The bootloader in turn verifies the signature of the application firmware.
4. Refusal. If a verification fails, boot stops or falls back to a valid recovery image.

The strength of the whole rests on the first link. If the reference key can be modified, or if the first code executed can be replaced, everything else is decorative.

Signing relies on asymmetric cryptography. The private key signs at the manufacturer and never leaves its production environment. The public key, embedded in the product, can only verify.

The seven mistakes that break the chain

1. Verifying at update time, not at boot

The firmware is checked when it arrives over the network. But an attacker with the device in hand writes directly to memory, through a debug port or with a programmer. Without verification at boot, their version runs.

2. Confusing a checksum with a signature

A CRC or a SHA-256 hash placed at the end of the image detects accidental corruption. They provide no authenticity: whoever modifies the firmware recomputes the value.

3. Using a shared secret

Authenticating the firmware with a code computed from a symmetric key means that key is in every device. It will be extracted, and will then make it possible to produce valid firmware for the whole fleet. See Secrets in the firmware: three flaws, one root cause.

4. Poorly protecting the private key

Signing key in the code repository, on a developer’s workstation, in a continuous integration variable readable by the whole team. Or the microcontroller vendor’s test key left in production. The cryptography is intact, the trust is not.

5. Forgetting rollback

An old firmware is correctly signed, since it was released by the manufacturer. If it contains a known vulnerability, the attacker reinstalls it and then exploits it. The countermeasure is a version counter that can only increase, stored out of the firmware’s reach.

6. Signing only part of it

The application is verified, but not the bootloader, the partition table or the configuration area. Modifying an uncovered parameter (a server address, a debug mode flag) is often enough to get the desired result.

7. Leaving a side door open

A debug port left open, an unauthenticated recovery mode, a serial console that offers to load an image. Secure boot is followed to the letter, and bypassed through the path next to it.

And when everything is done right?

In all honesty, it has to be said: a correctly implemented secure boot is not unbreakable. Public research has shown that a brief power glitch, applied at the right moment, can skip the verification instruction on some microcontrollers. These fault injection attacks require equipment, time and prolonged physical access.

The conclusion is not that secure boot is useless. It turns the attack from a few minutes with an adapter into a few days in a lab. For most products, that is exactly the goal. For the most sensitive ones, it must be complemented by hardware countermeasures and by unique keys per device, so that one compromised unit reveals nothing about the others.

What the platforms offer

Implementation depends on the component. On ESP32, the vendor provides a secure boot whose key hash is written to eFuses, combined with flash encryption. On STM32, depending on the family, you rely on read protection, a write-protected bootloader and the secure boot solutions provided by the vendor. Open-source projects such as MCUboot provide a bootloader that verifies signatures and handles rollback on many architectures.

In every case, these mechanisms are enabled through irreversible operations. They must be built into the manufacturing process and tested on every unit, not added at the end of the project.

The checklist

• Is the signature verified at every boot, and not only at installation?
• Is the reference key stored in a non-modifiable area?
• Are all executable and sensitive configuration areas covered?
• Does a mechanism prevent rolling back to an earlier version?
• Is the private key in a dedicated hardware module, with logged access?
• What does the product do if verification fails?
• Are debug interfaces and recovery modes locked?
• Is there a procedure to renew the key in case of compromise?

The link with regulation

Annex I of the Cyber Resilience Act requires protecting the integrity of software and distributing updates securely. The ETSI EN 303 645 standard devotes an entire requirement to software integrity, and the EN 18031 standards assess the secure update mechanism. IEC 62443-4-2 addresses the topic in its system integrity requirements.

Practice it on the DVID board

The DVID IoT Security path includes a firmware signature bypass module. Participants discover a product that appears to verify its updates, identify what is missing from the verification, and get a modified firmware accepted. They then rebuild the correct chain.

The exercise permanently changes the way you read the sentence “our firmware is signed”.

Who is it for?

• firmware developers and embedded architects
• industrialization managers, for key management in production
• pentesters and hardware auditors
• product security managers preparing for CRA or IEC 62443-4-2 compliance

Further reading

To validate these skills, discover the DVID certification path.

Learn more: https://dvid.eu
Contact us: https://dvid.eu/#contact
Follow our news: https://www.linkedin.com/company/dvid/