Firmware Anti-Rollback: Why Signed Firmware Can Still Be Downgraded

Consider a product without an enforced minimum security version: an attacker flashes firmware version 3 onto a device running version 5. The image is old, but it is genuine, signed by the real release key, hashed correctly, packaged properly. Every signature check passes. The device boots it happily. In this example, version 3 contains vulnerabilities fixed in later releases. Accepting it restores those vulnerabilities despite its valid signature.

This is a downgrade attack, and nothing about signature verification prevents it. Signatures prove authenticity, not currency. Preventing security-relevant rollback is a separate property, a version policy, and it has to be engineered like one. Not every move to an older release violates that policy.

What a downgrade actually gives an attacker

Downgrades are attractive because they convert effort you already spent into opportunity. The old image contains known, documented vulnerabilities, ones you patched after real findings. An attacker does not need a zero-day; they need your v3 binary and a way to make the device accept it. The paths are well understood: the update interface itself (if it accepts any signed package), a recovery or field-service mode that loads images with fewer checks, or direct flash access with the case open.

There is a second, quieter variant: rolling back not the whole image but the configuration. A device that downgrades its policy settings, accepting weaker TLS, re-enabling a debug interface, relaxing a verification step, suffers the same loss of fixes without a single byte of firmware changing.

Firmware version is not security version

A firmware version identifies a release. An independent security counter records the security level assigned by the release policy. That counter need not increase for every feature update. In this illustrative example, firmware v4 and v5 both carry security counter 8; v3 carries counter 7. With a stored minimum of 8, v4 can remain eligible after v5, while v3 is rejected. A matching counter is not proof of equal security: the release process must ensure that every image assigned that value meets the intended security baseline.

This separation is an intended design in Trusted Firmware-M, not a workaround. A stricter policy that compares release versions is also possible. The product must define which policy applies and enforce it consistently.

Monotonic counters: the mechanism

In a security-counter design, the verifier compares the authenticated image counter with a protected minimum. The minimum must not be lowered by an attacker within the defined threat model. Possible building blocks include:

• eFuse / OTP bits. Irreversible changes can encode a monotonic security value. The encoding and available transitions are platform-specific and finite; a release number does not translate directly into that many consumed fuses.
• RPMB-backed storage. eMMC/UFS RPMB provides authenticated, replay-protected access using a write counter. Stored data is not inherently monotonic: trusted software must prevent the stored security minimum from decreasing and protect the authorization key. The OP-TEE storage documentation distinguishes the RPMB write counter from the data stored in its blocks.
• Trusted counters or storage services. A secure element or TEE can provide a protected minimum, depending on the actual component and integration. Its update permissions and lifecycle remain part of the review.

MCUboot, for example, can carry the image security counter in the protected TLV area. The essential property is: reject an image below the committed minimum security counter, authenticate that image counter, and prevent an attacker from lowering the stored minimum. This is not necessarily the highest release number ever started.

The counter budget problem

If the design uses finite OTP transitions, counter allocation is a release-engineering decision. Separating security updates from feature versions is a normal way to preserve that budget. The important questions are which fixes require a new security counter, how all images within one counter value are kept on the intended security baseline, and what happens when the hardware budget is exhausted. Silently assigning an old security value to an image that requires a higher minimum undermines the policy; the independent counter itself does not.

The anti-brick trade-off

A minimum raised too early can block the last working recovery image. In an A/B or trial-boot design, installation, successful health checks, confirmation and commitment of the new minimum therefore need a defined order. Power loss and failed confirmation belong in that test. The safe sequence depends on the bootloader and platform; simply recording the highest image ever attempted is not a sufficient design.

A recovery path may permit an older release that still meets the committed security minimum. It must not silently restore a known-vulnerable security level. A minimal recovery environment can have its own explicitly constrained policy, but it must preserve the intended protections and enforce the required minimum on the images it installs.

What a secure update policy needs

When we review update mechanisms, the version policy questions are fixed:

• Does the policy compare release versions or independent security counters, and which releases remain intentionally eligible?
• Where is the minimum security value stored, and what stops an attacker with flash access from lowering it?
• What happens on version comparison failure, logged, refused, or boots anyway?
• Does the policy cover configuration and policy data, or only the main image?
• Do recovery paths enforce the same minimum security level, and what explicit exceptions exist?
• Who can advance the minimum, how is that authenticated, and when is it committed relative to trial boot and confirmation?
• When the counter technology is exhausted or deprecated, what is the migration plan?

A useful test uses more than an arbitrary old image: offer one signed image below the committed security minimum and, if the policy permits it, an older release at the same security counter. The first must be refused; the second may remain eligible if it also passes signature, compatibility and all other required checks. Repeat through update and recovery paths and document the policy, platform configuration and observed decisions. That distinguishes a controlled fallback from reintroducing a vulnerability.