Persistent anti-rollback in industrial firmware: why it matters

Picture this scenario, common enough by now to show up in incident-report templates: an industrial device runs firmware v1.07, with three public CVEs fixed since v1.04. The attacker reaches the maintenance network — leaked VPN credential, distracted technician, forgotten USB stick — and triggers an update. The payload is v1.04 straight from the vendor, digitally signed with the legitimate key of that era. The bootloader verifies the signature, confirms the binary is authentic, and installs it. The device comes back online with the three CVEs reopened. No signature was forged. That is a downgrade attack, blocked by exactly one defense: a persistent anti-rollback counter.

What a downgrade attack is

A downgrade attack forces a system to accept an older — and legitimate — version of software because that version carries a known vulnerability the attacker intends to exploit. Unlike an "update", a downgrade moves in the opposite direction, designed by adversaries to reopen holes the engineering team had already closed.

The cleanest historical example is LogJam (CVE-2015-4000), from 2015, where a network attacker forced TLS clients and servers to negotiate DHE_EXPORT ciphers — 512-bit Diffie-Hellman groups, inherited from 1990s US export rules. Browsers and servers had to coordinate a patch to remove the vulnerable ciphers.

In industrial firmware, the pattern repeats. Several CVEs documented in OT equipment — the family around CVE-2018-10628 in SCADA devices, where older firmware accepted commands without authentication — remain exploitable as long as a path exists to reinstall the vulnerable version. From the bootloader, the difference between update and downgrade is numeric: is the version received greater or less than the minimum accepted?

Why a digital signature alone is not enough

This is the point that confuses readers who learned industrial cybersecurity from vendor slides. A digital signature (Ed25519, RSA, ECDSA) proves authorship and integrity: it guarantees the binary was produced by whoever holds the private key, and that no bit was altered afterward. It does not prove that the binary is the latest version.

An old binary signed in 2022 with the same key that signed a 2026 binary still has a valid signature — the math does not see time. If the release scheme uses key rotation, the bootloader stores older key slots to keep the fleet bootable; even very old binaries pass the signature check.

The missing defense is the persistent anti-rollback counter. The device keeps, in storage that survives reset and power loss, a number representing the lowest version it will accept. Every update declares its own "anti-rollback version" in a header field: if it is greater than or equal to the counter, the update is considered; if lower, rejected. The counter is monotonically increasing — once it advances, it never moves backward in normal operation.

Classical mechanisms

Embedded practice offers four main families for the persistent counter.

Dedicated flash page. Reserved sector for the counter. Simple and cheap, but flash has limited endurance (10,000 to 100,000 cycles per page); if the counter writes on every boot, the page burns out in months. Requires wear-leveling.

OTP fuses. Instead of incrementing, blows a fuse per released version. Irreversible. Downside: finite count (typically 32, 64, or 128); exhaustion is permanent. Used in high-value silicon (Apple Secure Enclave, consoles).

RTC counter with battery. Counter in an RTC register with a backup domain powered by a coin-cell battery. Survives reset and loss of primary power. Depends on the battery being alive.

TAMP backup registers. Modern version of the previous mechanism in STM32 and equivalents. Tamper-protected registers in the battery domain, zeroable if a tamper pin is triggered. This is what the AEM-60DC8 uses.

Robust systems place the counter on the device, in hardware that the application firmware cannot lower — a counter in RAM persisted by software is fragile, a counter on a central server depends on channel availability.

TAMP counters with battery backup

STM32 microcontrollers in the G0/G4/L4/H7 families offer the TAMP peripheral (Tamper and backup registers), with 32-bit registers in the RTC backup domain. The domain is powered by the VBAT pin — typically a CR2032 or supercapacitor — and keeps its content during reset, deep sleep, and complete absence of main power.

In practice, a 32-bit TAMP register accommodates a uint32_t counter. Saturation at 4,294,967,295 — unreachable: at one update per month for 100 years, that is 1,200 increments. With uint16_t, the ceiling drops to 65,535, still ample.

The AEM-60DC8 keeps the exact bit width, register layout, and increment transition rule as a subject for technical validation under NDA, aligned with the posture of not publishing details that would erode defense in depth. In homologation conducted by the customer, those details are documented in technical evidence under confidentiality.

The CR2032 battery is field-replaceable. Replacement must be authenticated and logged so it does not become a downgrade path — edge case below.

Versioning policy

The anti-rollback rule only works with a clear policy about what the "version" is and when the minimum rises.

The AEM-60DC8 uses major.minor.patch (industrial SemVer). The version visible to the operator (currently v1.03) is the textual representation; internally, the update header carries a 32-bit integer packing the three fields, plus a dedicated anti_rollback_version, independent of SemVer.

Why separate them? Because not every release should raise the floor. A v1.03.1 patch that fixes a cosmetic LCD bug need not close v1.03.0. But if v1.04 fixes a serious CVE, the policy says: upon release of v1.04, the anti_rollback_version rises, and the bootloader, upon successfully booting v1.04, advances the TAMP counter. From that point, v1.03 is banned — until an authorized reset via service mode.

Who decides? In a process aligned with IEC 62443-4-1, a release committee with representation from engineering, security, and product. Criterion: raise the floor whenever the new release closes a vulnerability that the prior one exposes. Not raising the floor is a conscious decision, justified in writing.

How the AEM-60DC8 implements it

Firmware v1.03 of the AEM-60DC8 — LRI's Industrial DC Monitoring Platform — implements persistent anti-rollback in TAMP registers of the STM32G0B0RE MCU, in the backup domain powered by a CR2032 battery. The whitepaper WP01 — Modbus RTU under Secure by Design documents the nine-stage boot validation, with the anti-rollback counter acting as version filter before Ed25519 verification.

Relevant points:

• Counter in the TAMP domain, survives reset and primary power loss while the CR2032 is alive.
• Advance after successful boot — avoids lock-out if an update aborts.
• Anti-rollback version independent of SemVer, controlled by an internal release committee.
• Documented no-regression policy available under NDA.
• IEC 62443-4-2 SL2 as a target certification in progress — the project does not claim certification completed; LRI will publish the formal status when issued by the certification body.

Anti-rollback in regulated environments

In regulated sectors, the counter becomes an auditable artifact.

IEC 62443-3-3 SR 3.4 — Software and information integrity establishes, as a system requirement, that the control system shall detect, log, report, and protect against unauthorized access to and changes of software and information during operation, commissioning, maintenance, and repair. The anti-rollback counter responds to that SR.

In the North American market, NERC CIP-010-4 requires bulk-electric-system utilities to maintain a configuration baseline — including firmware version — and to justify any change. A device that silently accepts a downgrade is incompatible: the baseline loses value if it can be reverted without trace.

Evidence typically requested by an auditor: process document describing how the counter is incremented; test report showing rejection of an image with lower anti_rollback_version; documentation of the service mode and authorization; release committee record approving the floor of each release. LRI provides this under NDA during homologation.

Edge cases that matter

Field hardware replacement. An AEM-60DC8 goes out of service; a spare is installed. The spare ships with a low initial counter. If the plant runs v1.07, the site runbook mandates installing v1.07 before production — counter advances on the new device. Care point: do not return the failed unit to stock without an authorized counter reset.

Configuration restore. Configuration (Modbus parameters, calibration, baud rate) is data, not firmware. Restore does not touch the counter. The separation between "binary" and "configuration" is deliberate: the operator can restore a six-month-old configuration without reopening any CVE.

Legitimate upgrade via authenticated service mode. Rare scenarios require lowering the counter — diagnostics, return to factory for forensic analysis, device transfer. The answer is service mode with strong authentication (physical token, factory credential, physical presence) and persistent log. Service mode is not a "bypass" — it is a documented, rare, traceable path. On the AEM-60DC8 it is documented under NDA and is not exposed over the operational Modbus RTU bus.

FAQ

1. If the attacker removes the CR2032 battery, do they zero the anti-rollback counter? Removal with the device de-energized clears the backup domain. That is why the project treats battery replacement as a controlled maintenance event, with a documented procedure and — in regulated environments — a physical log entry. The TAMP tamper detection can be configured to record the loss of backup power, generating forensic evidence.

2. Is anti-rollback really necessary if we already have an Ed25519 signature and a domain prefix? Yes. The signature proves authorship and integrity; the domain prefix proves the binary belongs to that product; none of that proves it is the correct version for the current moment. Without the counter, an old, legitimately signed binary walks in without alarm.

3. Does the anti-rollback counter ever saturate in real use? With 32 bits, no. At one update per month for a century, that is 1,200 increments — below the ceiling of 4,294,967,295.

4. Who decides to raise the anti-rollback floor from one release to the next? In a process aligned with IEC 62443-4-1, an internal release committee with engineering, security, and product. Criterion: raise whenever the new release closes a vulnerability the prior one exposes.

5. Is the AEM-60DC8 already certified under IEC 62443-4-2 SL2? The project has IEC 62443-4-2 SL2 as a certification goal. The process is in progress. LRI Engineering will publish the formal status when issued by the certification body. This post does not claim certification completed.

---