Signed OTA Firmware Rollout & Rollback Protection

Update Package

Signature verification

Anti-rollback (monotonic counter)

Wave batch size 25%

Fleet Status

On patched v2

0 / 64

Still vulnerable (v1)

64 / 64

Rejected — bad sig

Rejected — rollback

Attack surface (unpatched share)

100%

Event Log

How it works

Every real OTA update chain runs two independent checks before a device ever flashes new firmware:

verify(pkg)  = HMAC_K(payload ‖ version) == pkg.signature
accept(pkg)  = verify(pkg)
             AND (version(pkg) > counter(device))   // if anti-rollback armed
counter(dev) ← max(counter(dev), version(pkg))       // monotonic, never decreases

Signature verification — the publisher signs payload+version with a private key; the device only trusts a signature it can verify against its embedded public key. A tampered or attacker-forged package fails this check regardless of its claimed version.
Anti-rollback counter — a monotonic counter burned into secure storage (often e-fuses) remembers the highest version ever installed. Even a validly signed old package is rejected if its version isn't strictly greater — this is what stops an attacker from "downgrading" a patched device back to a build with a known CVE.
Staged rollout — the batch slider mimics canary deployment: push to a slice of the fleet first, watch for failures, then widen the wave, instead of flashing every device at once.

Try disabling each toggle separately: with signature checking off, a tampered package flashes clean; with anti-rollback off, a signed-but-old package silently reintroduces the vulnerability the update fleet had already patched.

Vulnerable (v1) Patched (v2) Rejected — signature Rejected — rollback

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.