Wiki / Concepts

OTA Update

Shipping new firmware to a deployed device over the network. The mechanism that keeps a fleet patchable is also the most direct path to running your own code on every unit.

How an OTA update normally works
1 Check for update
2 Fetch manifest
3 Download image
4 Verify hash & signature
5 Mark slot bootable, reboot
6 Confirm, or roll back
The image lands in the inactive A/B slot and is only trusted after its hash and signature verify; the new slot must actively confirm itself after reboot or the bootloader falls back to the working image.

OTA update is the delivery of new firmware to a device already in the field, over whatever network it has. It is the only realistic way to fix a bug in a fleet of a hundred thousand units, and it is simultaneously the most valuable target on the device: whoever controls the update channel controls the firmware, permanently, on every unit that listens.

How it normally works

1. Check      device asks a server "is there a newer version?"
2. Manifest   server answers with version, download URL, size, hash, signature
3. Download   device fetches the image, usually into a spare partition
4. Verify     hash and signature checked before anything is trusted
5. Apply      mark the new slot bootable, reboot into it
6. Confirm    new firmware proves it works, or the bootloader rolls back

Most modern designs use A/B partitions: two full firmware slots plus a small state area recording which is active and which is being trialled. The running image writes the update into the inactive slot, so a failed download or a power cut halfway through leaves the working image untouched. After reboot the new image must actively confirm itself; if it crashes or never confirms, the bootloader falls back. ESP-IDF calls the state esp_ota_mark_app_valid_cancel_rollback; other stacks use the same idea under different names.

What has to be true for it to be safe

Every one of these is a step that gets skipped in the field:

  • The image is signed, and the signature is checked before use. Not a checksum. A CRC or SHA-256 alone proves the download was not corrupted, not that the vendor produced it.
  • The verification happens before the image is trusted, not after it boots. Verifying in the new firmware itself is circular.
  • The transport is authenticated. Plain HTTP for the manifest or the image means any network position rewrites both. TLS with proper certificate validation, and ideally pinning, closes it.
  • Downgrade is refused. Serving a genuine, correctly signed, but old and vulnerable image is a valid attack. Rollback protection compares a monotonic version counter (often burned into fuses) and refuses to go backwards.
  • The manifest itself is signed. A signed image behind an unsigned manifest still lets an attacker choose which signed image you get, which is the downgrade attack again.

How it gets broken

  • Plain HTTP. Still extremely common on consumer IoT. A machine in the path substitutes the manifest, points the URL at its own server, and the device installs anything.
  • Signature checked but the key is on the device. A symmetric MAC or a shared secret means the "verification" key can be extracted from any single unit and used to sign firmware for the whole fleet. Signing must be asymmetric: only the public key belongs on the device.
  • Verification that can be skipped. A single conditional branch in the bootloader, patchable if flash is writable and the boot chain is not itself verified.
  • No downgrade protection. The easiest and quietest attack, because every artifact involved is genuine.
  • Hash checked, signature not. The hash comes from the manifest, and the manifest came over the same channel as the image.

On ESP32 specifically

esptool writes images, the partition table declares the OTA slots plus the otadata state partition, and secure boot signs the bootloader and application so an unsigned image will not run at all. Flash encryption is orthogonal: it protects confidentiality at rest and does not by itself authenticate an update.

Pitfalls

  • An update path that works is a liability; an update path that does not work is a bigger one. Devices with no OTA at all are the ones still running the 2016 firmware.
  • Rollback protection and field recovery are in tension. Burning a version counter into fuses is irreversible, and a bad release can permanently strand a fleet.
  • Testing the update mechanism only on the happy path. Power loss mid-write, a truncated download and a corrupted slot are the cases that decide whether you brick devices.

What it pairs with

secure-boot establishes the trust the update chain relies on, tls protects the transport, and firmware covers what is actually being shipped.

Further reading