More devices than ever before are connected to the Internet, which drives the need for firmware updates to be provided over the Internet rather than through traditional interfaces, such as USB or RS-232. Sending updates over the Internet requires the device to fetch the new firmware image as well as the manifest.
Hence, the following components are necessary on a device for a firmware update solution:
The Internet protocol stack for firmware downloads. Firmware images are often multiple kilobytes, sometimes exceeding one hundred kilobytes, for low-end IoT devices and can even be several megabytes for IoT devices running full-fledged operating systems like Linux. The protocol mechanism for retrieving these images needs to offer features like congestion control, flow control, fragmentation and reassembly, and mechanisms to resume interrupted or corrupted transfers.
The capability to write the received firmware image to persistent storage (most likely flash memory).
A manifest parser with code to verify a digital signature or a message authentication code (MAC).
The ability to unpack, decompress, and/or decrypt the received firmware image.
A status tracker.
The features listed above are most likely provided by code in the application firmware image running on the device rather than by the bootloader itself. Note that cryptographic algorithms will likely run in a trusted execution environment on a separate MCU in a hardware security module or in a secure element rather than in the same context as the application code.
shows the architecture where a firmware image is created by an author and made available to a firmware server. For security reasons, the author will not have the permissions to upload firmware images to the firmware server and to initiate an update directly. Instead, authors will make firmware images available to the device operators. Note that there may be a longer supply chain involved to pass software updates from the author all the way to the authorizing party, which can then finally make a decision to deploy it with IoT devices.
As a first step in the firmware update process, the status tracker server needs to inform the status tracker client that a new firmware update is available. This can be accomplished via polling (client initiated), push notifications (server initiated), or more complex mechanisms (such as a hybrid approach):
Client-initiated updates take the form of a status tracker client proactively checking (polling) for updates.
With server-initiated updates, the server-side component of the status tracker learns about a new firmware version and determines which devices qualify for a firmware update. Once the relevant devices have been selected, the status tracker informs these devices, and the firmware consumers obtain those images and manifests. Server-initiated updates are important because they allow a quick response time. Note that in this mode, the client-side status tracker needs to be reachable by the server-side component. This may require devices to keep reachability information on the server side up to date and the state at NATs and stateful packet filtering firewalls alive.
Using a hybrid approach, the server side of the status tracker pushes update availability notifications to the client side and requests that the firmware consumer pull the manifest and the firmware image from the firmware server.
Once the device operator triggers an update via the status tracker, it will keep track of the update process on the device. This allows the device operator to know what devices have received an update and which of them are still pending an update.
Firmware images can be conveyed to devices in a variety of ways, including USB, Universal Asynchronous Receiver Transmitter (UART), WiFi, Bluetooth Low Energy (BLE), low-power WAN technologies, mesh networks and many more. At the application layer, a variety of protocols are also available: Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and HTTP are the most popular application-layer protocols used by IoT devices. This architecture does not make assumptions about how the firmware images are distributed to the devices and therefore aims to support all these technologies.
In some cases, it may be desirable to distribute firmware images using a multicast or broadcast protocol. This architecture does not make recommendations for any such protocol. However, given that broadcast may be desirable for some networks, updates must cause the least disruption possible both in the metadata and firmware transmission. For an update to be broadcast friendly, it cannot rely on link-layer, network-layer, or transport-layer security. A solution has to rely on security protection applied to the manifest and firmware image instead. In addition, the same manifest must be deliverable to many devices, both those to which it applies and those to which it does not, without a chance that the wrong device will accept the update. Considerations that apply to network broadcasts apply equally to the use of third-party content distribution networks for payload distribution.
| Author |
Firmware + Manifest |
+----------------------------------+ | Firmware +
| | | Manifest
| ---+------- |
| ---- | --|-
| //+----------+ | \\
-+-- // | | | \
----/ | ---- |/ | Firmware |<-+ | \
// | \\ | | Server | | | \
/ | \ / | | + + \
/ | \ / +----------+ \ / |
/ +--------+--------+ \ / | |
/ | v | \ / v |
| | +------------+ | | | +----------------+ |
| | | Firmware | | | | | Device | |
| | | Consumer | | | | | Management | |
| | +------------+ | | | | | |
| | +------------+ | | | | +--------+ | |
| | | Status |<-+--------------------+-> | | | |
| | | Tracker | | | | | | Status | | |
| | | Client | | | | | | Tracker| | |
| | +------------+ | | | | | Server | | |
| | Device | | | | +--------+ | |
| +-----------------+ | \ | | /
\ / \ +----------------+ /
\ Network / \ /
\ Operator / \ Device Operator /
\\ // \\ //
---- ---- ---- ----
Firmware images and manifests may be conveyed as a bundle or detached. The manifest format must support both approaches.
For distribution as a bundle, the firmware image is embedded into the manifest. This is a useful approach for deployments where devices are not connected to the Internet and cannot contact a dedicated firmware server for the firmware download. It is also applicable when the firmware update happens via USB sticks or short-range radio technologies (such as Bluetooth Smart).
Alternatively, the manifest is distributed detached from the firmware image. Using this approach, the firmware consumer is presented with the manifest first and then needs to obtain one or more firmware images as dictated in the manifest.
The pre-authorization step involves verifying whether the entity signing the manifest is indeed authorized to perform an update. The firmware consumer must also determine whether it should fetch and process a firmware image, which is referenced in a manifest.
A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation.
The download step is the process of acquiring a local copy of the firmware image. When the download is client initiated, this means that the firmware consumer chooses when a download occurs and initiates the download process. When a download is server initiated, this means that the status tracker tells the device when to download or that it initiates the transfer directly to the firmware consumer. For example, a download from an HTTP/1.1-based firmware server is client initiated. Pushing a manifest and firmware image to the Package Resource of the LwM2M Firmware Update Object [LwM2M
] is a server-initiated update.
If the firmware consumer has downloaded a new firmware image and is ready to install it, to initiate the installation, it may
need to wait for a trigger from the status tracker,
trigger the update automatically, or
go through a more complex decision-making process to determine the appropriate timing for an update.
Sometimes the final decision may require confirmation of the user of the device for safety reasons.
Installation is the act of processing the payload into a format that the IoT device can recognize, and the bootloader is responsible for then booting from the newly installed firmware image. This process is different when a bootloader is not involved. For example, when an application is updated in a full-featured OS, the updater may halt and restart the application in isolation. Devices must not fail when a disruption, such as a power failure or network interruption, occurs during the update process.