OS downgrade attacks on payment terminals

1. Mechanism

Each firmware release on a payment terminal carries two attestable properties: a vendor signature (proving authenticity of the image) and a rollback counter (proving recency). Rollback protection is the property that the bootloader refuses to run an image whose counter is below the floor — typically stored in Replay-Protected Memory Block (RPMB) or a dedicated tamper-evident counter region on AVB-conformant Android, and in vendor-specific tamper-evident storage on PCI PTS terminals [1]. (One-time-programmable fuses, by contrast, typically hold the root-of-trust hash and lifecycle state rather than the rollback index, since rollback indices must be incrementable.)

The boot logic is short:

1. Verify the signature on the firmware image.
2. Read the rollback counter from the image header.
3. Read the rollback floor from the rollback-counter storage.
4. If counter < floor, refuse to boot.
5. Otherwise, on slot-success commit (after the boot succeeds), increment the floor if the image carries a newer counter.

The downgrade attack succeeds when step 4 has a bypass condition. Two documented classes:

• Service mode without floor check. A factory or service bootloader path skips the rollback check on the assumption that only authorised technicians invoke it. If the path is reachable in deployed devices, the attack lands.
• Counter storage reset. On fleets where the rollback counter region is reset-vulnerable — fuses not blown on early-batch devices, RPMB key compromise, vendor-specific NVRAM that lacks tamper-evident behaviour — the floor can be rolled back, allowing an old signed image to boot.

A separate, distinct attack class — signed-malicious-firmware (also called supply-chain firmware compromise) — is sometimes mistaken for a downgrade. In that scenario an attacker with vendor signing-key compromise (or a compromised build pipeline) produces a maliciously-crafted but legitimately-signed image with a current rollback counter; the signature verifies, the counter satisfies the floor, the exploitable code runs. This is not a rollback attack — it is a key/pipeline compromise — and the operational response (rotate signing keys, recall images) is different. EEI surfaces it through the firmware-hash signal rather than the rollback-counter signal.

2. Where in the runtime it operates

The attack is at the boot chain. The relevant components:

• Boot ROM and stage-1 bootloader. Implement the rollback check. Read-only; a vulnerability here is hardware-revision scoped.
• Stage-2 bootloader. Loads the OS / firmware image. Verifies signature and rollback counter against the floor.
• Fuse / NVRAM rollback floor. The persistent state. On Android, AOSP’s AVB (Android Verified Boot) [1] documents the rollback-protection model.
• PCI PTS firmware-security requirements [2] specify the rollback-protection floor for fixed-function PTS terminals.

Once the device is running a downgraded image, the runtime is exactly the runtime of that older version — including any known vulnerabilities the older version had. Subsequent attacks can exploit those vulnerabilities directly.

3. Which checkpoints it bypasses

• Vendor signature verification. Not bypassed — the image is genuinely signed.
• Scheme terminal certification. The certified version was whatever shipped at the time of certification; a downgrade takes the device back to that version.
• Hardware attestation. On platforms that include the firmware version in the attestation chain, the chain reflects the current running version — so a downgrade is observable to a relying party that checks. Many platforms do not include the firmware version in the attestation chain.

4. Which signals make it observable

device.integrity. The Trusted Runtime Primitive observes:

• The current firmware version, as reported by the platform.
• The rollback counter from the running image’s header.
• The fuse / NVRAM rollback floor, where the platform exposes it.
• The Android Security Bulletin patch level [3] (on Android-based mPOS), against which the operator can compute a security-age delta.

5. Evidence Token shape when observed

The following example is illustrative; field names, type values, and schema are defined in YEI-001 §4 (available through the spec-access process).

{
  "ev": [{
    "ts":   "2026-06-15T10:23:14Z",
    "class": "device.integrity",
    "type":  "firmware.version",
    "data": {
      "version":          "5.5.0",
      "rollback_counter": 8,
      "rollback_floor":   12,
      "security_patch":   "2024-02-05",
      "drift_from_floor": -4
    }
  }]
}

A negative drift_from_floor means the running image’s counter is below the floor — by the boot logic in §1, that should not be possible. So a running device reporting counter=8, floor=12 is either lying about its state (in which case the field is itself an anomaly the operator should treat as evidence of compromise) or proves the floor enforcement was bypassed at boot. Either way, the value surfaces as direct evidence of a successful downgrade for Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — and the operator’s verifier reads it and decides whether to accept the device.

6. Cross-references

• Sibling articles: pos-tampering, mpos-side-loaded-apps, attestation-drift-distributed-fleets
• Theme 2: hardware-attestation
• Theme 3: run-as-exploit — adjacent vulnerability-window concept

7. External references

[1] AOSP. Verified Boot — rollback protection. source.android.com/docs/security/features/verifiedboot/avb. Cited 2026-02-25.

[2] PCI Security Standards Council. PCI PTS POI Modular Security Requirements v6.1 — Firmware Security (September 2021). www.pcisecuritystandards.org/document_library/?category=ptsdoc. Cited 2026-02-25. (Operators should verify the latest published PTS POI version against the PCI document library at the time of citation.)

[3] Google. Android Security Bulletin. source.android.com/docs/security/bulletin. Cited 2026-02-25.