Before a smart device flashes new firmware, its bootloader must cryptographically prove the image came from the real manufacturer and was not modified in transit. This simulator models a simplified RSA-style signature check:
verify(m, s): s^e mod n == H(m) ?
m = firmware image bytes
H = hash digest of m (toy checksum here)
s = signature the vendor computed as s = H(m)^d mod n
e,n = device's public verification key (fixed)
d = vendor's private signing key (never leaves the vendor)
Only someone holding the private exponent d can produce an s that satisfies the equation for a given hash, because modular exponentiation with a fresh key pair is not invertible without it. The device only ever needs the public (e, n) to check the equality — it never sees d.
- Legitimate update — the vendor signs the real image; s^e mod n matches H(m) exactly, the gate turns green, the device boots the new firmware.
- Tampered payload — a single byte of the firmware is flipped after signing; H(m) changes but s does not, so the equality fails and the image is quarantined before it ever runs.
- Forged signature — an attacker without the private key guesses an s; it verifies against essentially none of the possible hash values, so the check fails just as reliably.
- Rollback attack — a validly-signed but older firmware image (with a known, already-patched vulnerability) is replayed. Anti-rollback protection keeps a monotonic version floor in one-time-programmable fuses on the device; even a perfectly valid signature is rejected if its version is below that floor. Turn the toggle off to see why rollback protection matters — the same old image is then silently accepted.
This chain-of-trust plus anti-rollback counter is the real mechanism behind secure boot and OTA updates on modern smart-home hubs, routers and IoT controllers (e.g. ARM PSA / TrustZone, Google's Android Verified Boot, and vendor-specific secure-OTA stacks).