An update path that signs packages but trusts the delivery, or verifies at download but not at install, turns a maintenance feature into an attack path. The mechanism is privileged by design: it writes code that will execute with full device authority.
The most dangerous divergence sits between the normal path and the recovery path. The normal updater enforces signature checks and version policy. The recovery updater, built for field failures, not for attackers, accepts an older, validly signed image so a technician can revive a bricked device. That is exactly the property an attacker needs: a rollback path to a version with a known vulnerability, signed by the manufacturer, trusted by the bootloader.
Verification order matters as much as verification presence. If the version check runs after installation, an attacker who can trigger a recovery install has already downgraded the device before policy applies. Each of these failures is invisible in a checklist that only asks "is the firmware signed?"
The update property depends on several technical assumptions.
- Signature verification Is every package verified before any part of it is trusted, and is the verification logic itself correct?
- Version policy Is the version checked before installation, not after, and does the check survive the recovery path?
- Rollback protection Are older, validly signed images rejected everywhere, including fallback and factory images?
- Recovery paths Does recovery enforce the same signature and version policy as the normal updater, or weaker rules?
- Slot handling In A/B designs, which slot boots next, who decides, and can a stale slot survive a security fix?
- Key handling Where do verification keys live, how are they rotated, and can an old key still authorize new installs?
- Delivery integrity Is the transport authenticated, and does the device verify the package again at install time?
Signed correctly, and still a downgrade.
The updater verifies signatures before installation. The version policy is enforced, on the normal path. A recovery trigger accepts an older, validly signed image to enable field repair. The downgrade never meets the policy check, because policy applies after the image is already accepted.
The mechanism looked safe in isolation: every visible path was signed. The failure lives in the transition between two paths that were never reviewed against each other.
Test the update mechanism as an attack path.
We map the complete update topology, normal, recovery, fallback, factory, and compare the policy enforced on each branch. Then we test the transitions: crafted and downgraded packages, recovery triggers, slot manipulation and interrupted updates, each against the assumption that the device only accepts approved firmware.
- New OTA or firmware-update mechanism
- Recovery or fallback path added or changed
- Anti-rollback behavior needs verification before release
- Signing-key migration planned
- Device moving from development to production lifecycle
- A reported downgrade or update vulnerability needs assessment
- Regulatory requirements demand evidence of secure update