Firmware Upgrade Trust on Android: Signing, Rollback, and Post-Update Checks

A firmware update is the most privileged thing a device accepts from outside. It replaces the code that every other security control relies on. The update path therefore has to answer three questions: is this image genuine, is it newer than what the device runs, and is the device in the expected state afterwards?

This post follows the trust chain through those three questions. It builds on the Knox and mobile payments post, which covers why hardware-backed attestation matters.

1. Is This Image Genuine?

The device should refuse any image that does not carry a valid signature from the vendor’s signing authority. The check has to happen before the image is applied, not after. An install-then-verify design lets a bad image run once.

Two points matter in practice:

• The verification key lives in a place the update path cannot change. If the same channel that delivers images can also replace the trust anchor, the signature check protects nothing.
• Failure is a refusal, not a warning. An unsigned or malformed image is discarded and the device keeps its current, known-good firmware.

2. Is It Newer?

Signature checks alone do not stop a downgrade. A genuine but older image may contain a vulnerability that has since been fixed. A device that accepts it is trustworthy only in name.

Rollback protection records the version the device has already accepted and refuses anything older. The record has to be tamper-resistant. If an attacker can roll the record back, they can roll the firmware back too.

Legitimate downgrades exist, for example when a fix is withdrawn. Those should be an explicit, authorised action, not a side effect of the normal update path.

3. Is the Device in the Expected State?

Installing a correct image does not finish the job. The device should confirm, after reboot, that it booted the image it expected and that its security state is what the policy requires.

This is where attestation fits. A remote verifier can ask the device to prove its firmware and configuration, and the verifier decides whether to trust the device for sensitive work. Samsung’s Knox documentation describes this model for enterprise devices: a device-side component produces signed measurements, and a remote service returns a verdict.

The design point is that attestation is evidence for a decision made elsewhere. The device does not decide on its own that it is safe.

Putting It Together

Stage	Question	Failure behaviour
Delivery	Is the image signed by the vendor?	Refuse, keep current firmware
Install	Is the version newer than the accepted one?	Refuse unless explicitly authorised
Post-update	Did the device boot the expected image?	Report and restrict sensitive use
Remote	Does the verifier trust this device right now?	Withhold sensitive operations

What to Take Away

• Verify before applying, never after.
• Keep the trust anchor and the rollback record out of reach of the update channel.
• Treat a failed check as a refusal, and make downgrades a deliberate act.
• Attestation tells a verifier what the device claims. It does not replace the checks on the device itself.