How do you update firmware without internet?

A connected device can fetch an update from a known server over an encrypted connection. Without internet, the image may pass through a technician’s phone, a USB stick or several neighbouring devices before it arrives. None of those can be trusted to keep it intact.

RFC 9019, the IETF architecture for firmware updates on IoT devices, plans for this. It does not assume how images reach devices, and for updates that are broadcast or pass through third parties it says a solution “cannot rely on link-layer, network-layer, or transport-layer security”. The protection is applied to the update itself: a signed description of the image, called a manifest, and the image it describes. The RFC requires the image to be authenticated and integrity protected, and makes confidentiality optional.

RFC 9124, the companion manifest model, puts the stakes plainly: a firmware update “is, by definition, remote code execution”. A device runs whatever its trusted signer approves, and if that signer is compromised, the RFC notes, the possibilities for defence are limited.

RFC 9019 allows the manifest and image to travel as one bundle, which it describes as useful when devices are not connected to the internet and cannot contact a firmware server, including updates by USB stick or short-range radio such as Bluetooth. Common paths:

• A phone over Bluetooth LE. Zephyr’s device management protocol, SMP, has transports for Bluetooth LE and for UART or serial links. ESP-IDF, Espressif’s framework, describes over-the-air updates as data received while normal firmware runs, for example over Wi-Fi, Bluetooth or Ethernet.
• A cable or removable media. RFC 9019 describes a recovery image that can rerun the update over serial, USB or Bluetooth when a normal update fails.
• Across a mesh. The Bluetooth SIG’s Mesh Device Firmware Update feature sends firmware to many nodes with multicast, with parameters to control the cadence and size of messages so the transfer runs in the background, and lets the update be applied on all nodes at a planned time. The Bluetooth SIG notes that an update means transferring a large amount of data to every node, so the problem resembles moving a large file across a mesh.
• Carried by someone. A phone that picks up an update where there is coverage and hands it over later is a form of data muling.

RFC 9124 lists the information a manifest carries. These elements matter most when the device cannot check with a server:

• Signature. The foundation of all the manifest’s security properties.
• Payload digest. Ties the manifest to one exact image.
• Vendor ID and class ID. Let the same manifest reach many devices without the wrong kind of device accepting it.
• Monotonic sequence number. Required, must never wrap around, and stops anyone reinstalling an older update against the vendor’s policy.
• Expiration time. Optional, and only useful where the device has a secure source of time.

RFC 9124 names a threat specific to disconnected devices. A device that has been offline for a long time runs old firmware and does not know newer releases exist. An attacker hands it an old but validly signed update that is newer than what it runs but older than the latest, carrying a known vulnerability. The sequence number check passes, because the device has never seen anything newer. The RFC says the right mitigation depends on where the threat comes from; against a network attacker, showing an expiration date and asking a user to confirm can help.

Some bootloaders anchor the version rule in hardware. MCUboot’s hardware-based downgrade prevention compares an image’s security counter with a value stored in a non-volatile, trusted part of the device. ESP-IDF’s anti-rollback refuses an application whose security version is lower than the one programmed into the chip’s eFuse. The bootloader also needs a trust anchor store holding the key it verifies against, RFC 9019 notes, and a secure element is one way to protect keys on a device someone can open.

RFC 9019 says devices must not fail when a disruption such as a power failure occurs during an update. Bootloaders handle this by keeping the old image until the new one proves itself:

• MCUboot keeps a primary and a secondary slot. In a test swap it boots the new image, and unless that image marks itself as good, it swaps back on the next reset, so a device that crashes on bad firmware returns to the working version.
• ESP-IDF needs at least two OTA app slots. With app rollback enabled, a new application must confirm it works on first boot or the bootloader returns to the previous one. Its documentation recommends running the self-test quickly, so a power loss during it does not trigger a rollback.

NIST SP 800-193 frames the same goals for platform firmware as protection against unauthorised changes, detection of changes that occur, and recovery. For a device with no network, recovery has to work locally, because nobody can push a fix to a device that cannot boot.