Where a bad update stops: update integrity for offline, regulated devices

Most update security advice assumes the device can phone home. It checks a server, pulls a manifest over TLS, and trusts the transport to carry the rest. Take the network away and that whole model falls over. The update still has to arrive, but now it arrives by hand, through people you do not control, onto a machine that has to decide alone whether what it was handed is the thing that was approved.

Regulated devices make the question sharper. It is not enough that an update came from the vendor. It has to be the exact build an independent lab tested, for the market the device is licensed in, and never older than what is already running. Every one of those is a separate check, and each one exists because the others can be satisfied by something that should still be refused.

The explainer below is the route an update travels, from build to the moment it becomes the running system. Pick a scenario and watch where it gets caught.

The scenario that separates a working design from a checkbox is the one-byte rebuild. Someone with access to the signing key, or to a pipeline that uses it, produces a binary that differs from the certified one by a single byte. The signature is perfect. A device that only checks signatures installs it.

What stops it is the second, independent fact: the hash of the exact bytes the lab certified. The device carries that list, signed by the lab rather than by the vendor, and refuses anything that is not on it. The vendor's key says who built it. The certified hash says that this particular build is the one that was examined. You need both, held by different parties, or one compromise is enough.

An older release is, by definition, a release with known problems that were fixed later. It is also validly signed, because it was a real release. Without a minimum-version rule, an attacker who can hand the device a file does not need to forge anything. They just reinstall last year's bug. The device has to remember the highest version it has accepted and refuse to go below it.

The same build can be certified for one jurisdiction and not another. Binding each approved package to the markets it is allowed in turns that rule from a paperwork obligation into something the device enforces. A valid, certified update for the wrong market is rejected exactly like a tampered one.

None of the checks above help if the install itself can leave the device half written. The update goes to an inactive slot while the current system keeps running untouched. Power can fail at any point and the device simply boots what it had. After the new slot boots, it has to prove it is healthy before it becomes the default; if it cannot, the boot loader falls back on its own. Nobody has to drive to the machine.

A stolen vendor key on its own is caught: the rebuild above is exactly that case. What gets through is a malicious build that reaches the lab and is certified anyway, or a stolen vendor key together with control of the lab's key. Those are handled upstream: keys under split custody and kept offline, reproducible builds that let a second party rebuild and compare, and a certified list signed by the lab so that no single organization can approve its own bytes.

Every check on this route also runs once, before install. Someone who can write the disk directly never meets them. That is the job of verified boot: the boot loader checks each slot at every start against a key anchored in the hardware root of trust. It is a separate layer, and this explainer does not draw it.

The point of drawing the route is that each station answers a different question, and each scenario above is one that a single, cleverer check would have let through.