A secure OTA update system that prevents installation of unsigned firmware has addressed only half of the firmware security problem. The other half is rollback: the ability for an attacker who has obtained a valid signed older firmware image to downgrade a device to a version containing known vulnerabilities or disabled security features. Older firmware images are validly signed, they were created by the legitimate build system and their signatures verify correctly. Signature verification alone cannot reject them. Anti-rollback protection is the specific mechanism that prevents installation of older firmware regardless of signature validity.
The Rollback Attack Scenario
Consider an embedded device that shipped with firmware v1.0 containing a buffer overflow vulnerability. The OEM patches this in v1.1 and deploys the update. An attacker who discovers the v1.0 vulnerability after the patch is deployed cannot exploit updated devices, but can attempt to roll them back to v1.0 by replaying the original update package. If the bootloader accepts any validly signed image without checking its version against a minimum threshold, the rollback succeeds. This attack is particularly relevant in automotive contexts where vehicle diagnostic interfaces provide physical OTA access to ECUs.
Monotonic Counter Design
The standard anti-rollback mechanism is the monotonic counter, a persistent counter stored in non-volatile memory tracking the minimum acceptable firmware version number that can only be incremented, never decremented. Each firmware image carries a version field in its header. The bootloader compares the image version against the stored counter before accepting a new image. If the image version is less than the counter value, the bootloader rejects the image regardless of signature validity. When new firmware is installed and confirmed, the counter increments to the new version value.
| Storage Option | Tamper Resistance | Increment Operations | Notes |
|---|---|---|---|
| OTP fuses | Very high | Limited (16-128) | Best security, limited increments |
| Secure NVM + HSM | High | Unlimited | Requires HSM or secure element |
| EEPROM + monotonic protocol | Moderate | Unlimited | Software protocol required |
| Standard flash | Low | Unlimited | Susceptible to physical manipulation |
Security Version Number Design
A practical design uses a Security Version Number (SVN) distinct from the marketing version number. The SVN increments only when a security-relevant change is included — a vulnerability fix, algorithm upgrade, or security configuration change. The anti-rollback counter tracks the SVN rather than the full version number, preserving counter increments for security-relevant changes only. This is especially important for OTP-based counters where the total number of increment operations is limited.
Firmware Authentication Beyond Signature Verification
Firmware manifest authentication extends signature coverage from the binary image to a manifest document that includes the image hash, version number, target hardware identifier, and deployment scope. Target hardware binding includes the hardware revision or part number in the signed manifest, preventing a firmware image built for one hardware variant from being installed on an incompatible variant — which signature and anti-rollback checks alone cannot prevent.
Implementing Anti-Rollback with RAPIDSEA
RAPIDSEA's bootloader implements anti-rollback protection through OTP fuse-based monotonic counters on Renesas RH850, NXP S32K3, and Infineon AURIX MCU families, as well as HSM-backed secure NVM counters where available. The bootloader configuration, managed through Flint IDE, allows specification of the SVN field position in the firmware image header, the storage mechanism for the monotonic counter, and the increment policy. Firmware image signing through the build pipeline produces signed packages including the manifest, binary, and signature bundle. The bootloader performs manifest verification, hardware target validation, version comparison, and binary signature verification as a sequential gate before any flash write begins.
Conclusion
Anti-rollback and firmware authentication close the gap between cryptographic integrity and true firmware trustworthiness. Signature verification establishes authenticity. Monotonic counters prevent version downgrade attacks. Manifest authentication binds the image to its intended target. Together they create an OTA update system that cannot be subverted by replaying validly signed older images. RAPIDSEA's bootloader delivers all three controls in a production-validated, hardware-portable implementation.
Ready to secure your OTA pipeline? Contact our team to request an evaluation build or book a technical demo.