RFC 9019
A Firmware Update Architecture for Internet of Things
Abstract 💖
Okay bestie, IoT devices have had a LOT of security holes 😭, so we need a firmware update system that's reliable AND secure, even for tiny devices with very few resources. Updating is how you patch those holes, but it's also how you tweak settings and add new features 🎀.
This doc sets the scene with some terminology and an architecture, and it explains why we need a standardized manifest format. The manifest is a transport-agnostic way to describe and protect firmware updates, so it doesn't care how the update gets delivered ✨.
Status of This Memo 📝
Heads up, this one is not an Internet Standards Track spec. It's published just for information 🧚.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓.
For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9019 🔗.
Copyright Notice 💜
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 👀. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
Table of Contents 🍓
1. Introduction
2. Conventions and Terminology
2.1. Terms
2.2. Stakeholders
2.3. Functions
3. Architecture
4. Invoking the Firmware
4.1. The Bootloader
5. Types of IoT Devices
5.1. Single MCU
5.2. Single CPU with Partitioning between Secure Mode and Normal
Mode
5.3. Symmetric Multiple CPUs
5.4. Dual CPU, Shared Memory
5.5. Dual CPU, Other Bus
6. Manifests
7. Securing Firmware Updates
8. Example
9. IANA Considerations
10. Security Considerations
11. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
Firmware updates can fix security vulnerabilities, so doing updates is a big building block for securing IoT devices 🔐. Because people got really worried about insecure IoT devices, the Internet Architecture Board (IAB) organized the Internet of Things Software Update (IoTSU) Workshop [RFC8240] to look at the bigger picture 👀. The workshop uncovered a bunch of challenges for developers and ended up forming the IETF Software Updates for Internet of Things (SUIT) Working Group 🫶.
Developing secure IoT devices is not an easy task 😤, and supporting a firmware update solution takes skilled engineers. Once devices are out in the world, updates are a huge part of their life-cycle management 🔄. This matters most when devices have a long lifetime or are deployed somewhere remote or hard to reach, where sending someone out to fix them by hand costs too much or is just difficult 🏔️. IoT firmware updates are expected to work automatically, meaning without any user involvement 🤖. Non-IoT devices, on the other hand, are expected to respect user preferences and consent when scheduling updates 💅. Automatic updates that don't need a human are the key to a scalable way of fixing software vulnerabilities, and that's the whole point 💖.
Firmware updates aren't just for bug fixes either 🐛. They also add new functionality, and they reconfigure the device so it can work in new environments or behave differently once it's already out in the field ✨.
The manifest specification has to allow the following:
- The firmware image is authenticated and integrity protected. Attempts to flash a maliciously modified firmware image, or an image from an unknown, untrusted source, must be prevented 🚫. This document uses asymmetric cryptography in its examples because many IoT deployments prefer it 🔑. Symmetric credentials are also supported and can be used by very constrained IoT devices 🧚.
- The firmware image can be confidentiality protected, so an adversary's attempts to recover the plaintext binary can be mitigated, or at least made harder 🕵️. Getting the firmware is often one of the first steps in an attack, because it reveals the software libraries in use, the configuration settings, and the general functionality 😳. Reverse engineering a binary is tedious, but modern reverse engineering frameworks have made it a lot easier 🥲.
Authentication and integrity protection of firmware images must be used in a deployment, but the confidential protection of firmware is optional 🫧.
The standardization work was informed by and optimized for firmware update use cases on Class 1 devices (using the device class definitions in RFC 7228 [RFC7228]) 🎀. Nothing in the architecture limits it to only those constrained IoT devices, though 🙌. It's also not limited to firmware and software updates. It can handle delivering arbitrary data too, like configuration information and keys 🗝️. Lots of IoT devices don't have user interfaces, unlike laptops and desktop PCs 📵, so unattended updates are essential for a practical solution 💯. Constrained IoT devices usually follow a software engineering model where one developer creates and compiles all the software on the device into a single, monolithic firmware image 🧱. Higher-end devices are different: application software is often downloaded separately and can even come from developers who aren't the ones who wrote the lower-level software 🧩. How you get those application-layer software binaries depends a lot on the platform, the programming language, and the sandbox the software runs in 🏖️.
The IETF has focused on the manifest format, but a fully interoperable solution needs more than a standardized manifest 🥹. For example, protocols for transferring firmware images and manifests to the device need to exist, and so does the status tracker functionality 📡. Devices also need a way to find the status tracker(s) and/or firmware servers. That could be preconfigured hostnames or DNS-based Service Discovery (DNS-SD) [RFC6763] 🔍. These building blocks have been developed by different organizations under the umbrella of an IoT device management solution 🌸. The Lightweight Machine-to-Machine (LwM2M) protocol [LwM2M] is one IoT device management protocol 💜.
There are also several areas that (partially) fall outside the scope of the IETF and other standards organizations, but firmware authors, device operators, and network operators still need to think about them 🧐. The IoTSU workshop highlighted a few of these:
- Installing firmware updates robustly, so the update doesn't break the device's functionality in the environment it operates in 🛠️. This takes proper testing and recovery strategies for when a firmware update fails 🔁.
- Making firmware updates available in a timely fashion. That's tricky because of how complicated the decision-making is for updating devices, possible recertification requirements, how long the supply chain is before an update reaches the end customer, and the need for user consent to install updates ⏳.
- Designing battery-powered IoT devices to be energy efficient 🔋. Firmware updates are energy-intensive, especially the radio communication and writing the firmware image to flash ⚡.
- Giving device operators incentives to use a firmware update mechanism, and getting IoT device vendors to require its integration 🤝.
- Making sure firmware updates that fix critical flaws can still be obtained after a product is discontinued or a vendor goes out of business 🪦.
Here's the roadmap 🗺️. This document starts with a terminology list, then describes the architecture. Next, we explain the bootloader and how it integrates with the firmware update mechanism 🥾. After that, we categorize IoT devices by the hardware capabilities that matter for firmware updates 🧠. Then we talk about the manifest structure and how to use it to secure firmware updates 🔒. We wrap up with a more detailed example of a message flow for distributing a firmware image to a device 🎬.
2. Conventions and Terminology 🎀
To be continued in part 2, bestie 💅🌈
2.1. Terms ✨
okay so first we need the vocab list, bestie 📖💅 this is the glossary and everything later depends on it, so pay attention!!
This document uses the following terms:
Firmware Image: 🧚 The firmware image, or simply the "image", is a binary that may contain the complete software of a device or a subset of it. The firmware image may consist of multiple images if the device contains more than one microcontroller. Often, it is also a compressed archive that contains code, configuration data, and even the entire file system. The image may consist of a differential update for performance reasons.
The terms "firmware image", "firmware", and "image" are used in this document and are interchangeable. We use the term "application firmware image" to differentiate it from a firmware image that contains the bootloader. An application firmware image, as the name indicates, contains the application program, often including all the necessary code to run it (such as protocol stacks and an embedded operating system (OS)). 💖
Manifest: 📜 The manifest contains metadata about the firmware image. The manifest is protected against modification and provides information about the author. 🔒
Microcontroller: 🔌 A microcontroller unit (MCU) is a compact integrated circuit designed for use in embedded systems. A typical microcontroller includes a processor, memory (RAM and flash), input/output (I/O) ports, and other features connected via some bus on a single chip. The term "system on chip" (SoC) is often used interchangeably with MCU, but MCU tends to imply more limited peripheral functions. 🫶
Rich Execution Environment (REE): 🌈 An environment that is provided and governed by a typical OS (e.g., Linux, Windows, Android, iOS), potentially in conjunction with other supporting operating systems and hypervisors. It is outside of the Trusted Execution Environment (TEE). This environment and the applications running on it are considered untrusted. 👀
Software: 💻 Similar to firmware but typically dynamically loaded by an OS. Used interchangeably with firmware in this document.
System on Chip (SoC): 🍓 An SoC is an integrated circuit that contains all components of a computer, such as the CPU, memory, I/O ports, secondary storage, a bus to connect the components, and other hardware blocks of logic. ✨
Trust Anchor: 🦋 A trust anchor, as defined in RFC 6024 [RFC6024], represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. 👑
Trust Anchor Store: 🏰 A trust anchor store, as defined in [RFC6024], is a set of one or more trust anchors stored in a device. A device may have more than one trust anchor store, each of which may be used by one or more applications. A trust anchor store must resist modification against unauthorized insertion, deletion, and modification. No cap, that last part is serious 🚨
Trusted Applications (TAs): 🛡️ An application component that runs in a TEE. 💜
Trusted Execution Environments (TEEs): 🔐 An execution environment that runs alongside of, but is isolated from, an REE. For more information about TEEs, see [TEEP-ARCH]. 🌸
2.2. Stakeholders 🎀
okay now the cast of characters!! the stakeholders are the people and orgs who show up in this doc, so here they are 🫶
The following stakeholders are used in this document:
Author: ✍️ The author is the entity that creates the firmware image. There may be multiple authors involved in producing firmware running on an IoT device. Section 5 talks about those IoT device deployment cases. 🧩
Device Operator: 🎛️ The device operator is responsible for the day-to-day operation of a fleet of IoT devices. Customers of IoT devices, as the owners of IoT devices (such as enterprise customers or end users), interact with their IoT devices indirectly through the device operator via the Web or smartphone apps. 📱
Network Operator: 📡 The network operator is responsible for the operation of a network to which IoT devices connect. 🌐
Trust Provisioning Authority (TPA): 🗝️ The TPA distributes trust anchors and authorization policies to devices and various stakeholders. The TPA may also delegate rights to stakeholders. Typically, the original equipment manufacturer (OEM) or original design manufacturer (ODM) will act as a TPA; however, complex supply chains may require a different design. In some cases, the TPA may decide to remain in full control over the firmware update process of their products. 👑✨
User: 🙋 The end user of a device. The user may interact with devices via the Web or smartphone apps, as well as through direct user interfaces. 💅
2.3. Functions 🧠
now the jobs each piece does!! this is where it gets really fun, the components actually work together so pay attention 🚀
(IoT) Device: 🤖 A device refers to the entire IoT product, which consists of one or many MCUs, sensors, and/or actuators. Many IoT devices sold today contain multiple MCUs; therefore, a single device may need to obtain more than one firmware image and manifest to successfully perform an update. 🌈
Status Tracker: 📊 The status tracker has a client and a server component and performs three tasks:
- It communicates the availability of a new firmware version. This information will flow from the server to the client.
- It conveys information about the software and hardware characteristics of the device. The information flow is from the client to the server.
- It can remotely trigger the firmware update process. The information flow is from the server to the client.
For example, a device operator may want to read the installed firmware version number running on the device and information about available flash memory. Once an update has been triggered, the device operator may want to obtain information about the state of the firmware update. If errors occurred, the device operator may want to troubleshoot problems by first obtaining diagnostic information (typically using a device management protocol). 🔍
We make no assumptions about where the server-side component is deployed. The deployment of status trackers is flexible: they may be found at cloud-based servers or on-premise servers, or they may be embedded in edge computing devices. A status tracker server component may even be deployed on an IoT device. For example, if the IoT device contains multiple MCUs, then the main MCU may act as a status tracker towards the other MCUs. Such deployment is useful when updates have to be synchronized across MCUs. 🧚✨
The status tracker may be operated by any suitable stakeholder, typically the author, device operator, or network operator. 🫧
Firmware Consumer: 📥 The firmware consumer is the recipient of the firmware image and the manifest. It is responsible for parsing and verifying the received manifest and for storing the obtained firmware image. The firmware consumer plays the role of the update component on the IoT device, typically running in the application firmware. It interacts with the firmware server and the status tracker client (locally). 💖
Firmware Server: 🗄️ The firmware server stores firmware images and manifests and distributes them to IoT devices. Some deployments may require a store-and-forward concept, which requires storing the firmware images and/or manifests on more than one entity before they reach the device. There is typically some interaction between the firmware server and the status tracker, and these two entities are often physically separated on different devices for scalability reasons. 🚚
Bootloader: 🥾 A bootloader is a piece of software that is executed once a microcontroller has been reset. It is responsible for deciding what code to execute. 🌟
3. Architecture ✨
okay so more devices than EVER are on the Internet now 😭 which means firmware updates have to come over the Internet instead of through the old-school stuff like USB or RS-232. and sending updates over the Internet means the device has to fetch the new firmware image AND the manifest. that's a lot of fetching, bestie 🫶
so a device needs these components 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, not by the bootloader itself. also, cryptographic algorithms will likely run in a trusted execution environment on a separate MCU in a hardware security module or in a secure element, NOT in the same context as the application code. that's the way to keep the secrets secret 🤫🧚
Figure 1 shows the architecture where an author makes a firmware image and it gets made available to a firmware server. for security reasons, the author does NOT get permission to upload firmware images to the firmware server and start an update directly 🙅♀️ instead, authors make firmware images available to the device operators. there may be a longer supply chain to pass software updates from the author all the way to the authorizing party, who can then finally decide to deploy it to IoT devices. it's giving bureaucracy but it's giving safety too 💅
as a first step in the firmware update process, the status tracker server needs to tell the status tracker client that a new firmware update is available. this can happen via polling (client initiated), push notifications (server initiated), or more complex mechanisms (like 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 figures out 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 keep the state at NATs and stateful packet filtering firewalls alive. main character energy for the server, not so much for the NAT 😭
- 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, the tracker keeps track of the update process on the device. this lets the device operator see which devices have received an update and which ones are still pending. iconic for accountability 👑
firmware images can be conveyed to devices in a bunch 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, there are also a variety of protocols: 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 firmware images get distributed to devices, so it aims to support all of these technologies 🦋
sometimes 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, since broadcast may be desirable for some networks, updates must cause the least disruption possible in both 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 🔒 also, the same manifest must be deliverable to many devices, both the ones it applies to and the ones it doesn't, without any chance that the wrong device accepts the update. considerations that apply to network broadcasts apply equally to using third-party content distribution networks for payload distribution. it's the same energy, ngl 🙈
+----------+
| |
| Author |
| |
+----------+
Firmware + Manifest |
+----------------------------------+ | Firmware +
| | | Manifest
| ---+------- |
| ---- | --|-
| //+----------+ | \\
-+-- // | | | \
----/ | ---- |/ | Firmware |<-+ | \
// | \\ | | Server | | | \
/ | \ / | | + + \
/ | \ / +----------+ \ / |
/ +--------+--------+ \ / | |
/ | v | \ / v |
| | +------------+ | | | +----------------+ |
| | | Firmware | | | | | Device | |
| | | Consumer | | | | | Management | |
| | +------------+ | | | | | |
| | +------------+ | | | | +--------+ | |
| | | Status |<-+--------------------+-> | | | |
| | | Tracker | | | | | | Status | | |
| | | Client | | | | | | Tracker| | |
| | +------------+ | | | | | Server | | |
| | Device | | | | +--------+ | |
| +-----------------+ | \ | | /
\ / \ +----------------+ /
\ Network / \ /
\ Operator / \ Device Operator /
\\ // \\ //
---- ---- ---- ----
----- -----------
Figure 1: Architecturefirmware 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 aren't connected to the Internet and can't contact a dedicated firmware server for the download. it's also applicable when the firmware update happens via USB sticks or short-range radio technologies (like Bluetooth Smart) 🍓
alternatively, the manifest is distributed detached from the firmware image. with this approach, the firmware consumer gets the manifest first, and then needs to obtain one or more firmware images as the manifest dictates 📜
the pre-authorization step involves checking whether the entity signing the manifest is actually authorized to perform an update. the firmware consumer must also determine whether it should fetch and process a firmware image 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 before installation 🧩
the download step is the process of acquiring a local copy of the firmware image. when the download is client initiated, the firmware consumer chooses when a download happens and starts the download process. when a download is server initiated, the status tracker tells the device when to download, or it starts 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, then to start 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 pick the right timing for an update.
sometimes the final decision may need confirmation from the device's user, for safety reasons 🫶
installation is the act of processing the payload into a format 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 isn't involved. for example, when an application is updated in a full-featured OS, the updater may halt and restart the application in isolation. and devices must not fail when a disruption, like a power failure or network interruption, happens during the update process. that's the whole vibe, periodt 🌈✨
4. Invoking the Firmware ✨
Okay bestie, so Section 3 covers how the firmware image and the manifest get from the author to the firmware consumer on the IoT device 📦. Once the firmware consumer has retrieved and successfully processed both the manifest and the firmware image, it needs to invoke the new firmware image 🚀. How that works depends on the type of device, but it typically looks like this: halt the current firmware, hand control over to firmware with a higher privilege or trust level (the firmware verifier), verify the new firmware's authenticity and integrity, and then invoke it 💅.
In an execute-in-place microcontroller, this is often done by rebooting into a bootloader (which halts the application and hands control to the higher privilege level at the same time 🔥), and then running a secure boot process (verifying and invoking the new image) 🧚.
In a rich OS, this may be done by halting one or more processes and then invoking new applications 🌸. In some OSes, this happens implicitly, because the kernel verifies the code signatures on the new applications 🫶.
The invocation process is seriously security sensitive 😭. An attacker will typically try to pull a firmware image off the device for reverse engineering, or try to trick the firmware verifier into executing an attacker-modified firmware image 💀. So the firmware verifier has to perform security checks on the firmware image before it can be invoked 🙈. These checks happen in addition to the security checks that already took place when the firmware image and the manifest were downloaded by the firmware consumer. Two layers of protection, no cap 🛡️✨.
There's an overlap between the firmware consumer and the firmware verifier functionality, and it shows up in two forms 🦋:
- A firmware verifier must verify the firmware image it boots as part of the secure boot process. To do that, metadata has to be stored alongside the firmware image so the firmware verifier can cryptographically verify it before booting, making sure it hasn't been tampered with or replaced 🔐. This metadata may well be the same manifest obtained with the firmware image during the update process 💜.
- An IoT device needs a recovery strategy in case the firmware update or invocation process fails 🩹. The recovery strategy may include storing two or more application firmware images on the device, or offering the ability to invoke a recovery image that performs the firmware update process again, using firmware updates over serial, USB, or even wireless connectivity like Bluetooth Smart 📡. In that last case, the firmware consumer functionality lives inside the recovery image and needs the necessary functionality for executing the firmware update process, including manifest parsing 🎀.
This document assumes the firmware verifier is distinct from the firmware consumer and therefore doesn't manage the firmware update process. That's not a hard requirement though, and in practice these roles may be combined 🤷♀️✨.
Using a bootloader as the firmware verifier needs some special considerations 🧸, especially when the bootloader implements the robustness requirements identified by the IoTSU workshop [RFC8240] 💪.
4.1. The Bootloader
In most cases, the MCU has to restart in order to hand control over to the bootloader 🔄. Once the MCU starts a restart, the bootloader figures out whether a newly available firmware image should be executed 👀. If the bootloader decides the new image is invalid, a recovery strategy is necessary 🆘. There are only two approaches for recovering from invalid firmware: either the bootloader must be able to select different, valid firmware, or it must be able to obtain new, valid firmware 🙅♀️. Both approaches have implications for the architecture of the update system 🏗️.
Assuming the first approach, there are (at least) three firmware images on the device 💖:
- First, the bootloader is also firmware. If a bootloader is updatable, its firmware image is treated like any other application firmware image 🥰.
- Second, the firmware image that's getting replaced is still on the device as a backup, in case the freshly downloaded image doesn't boot or operate correctly 🛟.
- Third, there's the newly downloaded firmware image 🍓.
So the firmware consumer has to know where to store the new firmware 📍. Sometimes that's implicit (for example, replacing the least recently used firmware image) ⏳. Other times the storage location has to be explicit, like when a device has one or more application firmware images plus a recovery image with limited functionality, enough only to perform an update 🧩.
Since lots of low-end IoT devices don't use position-independent code 🙃, either the bootloader needs to copy the newly downloaded application firmware image into the location of the old one (and vice versa), or multiple versions of the firmware need to be prepared for different locations 🗺️.
In general, it's assumed that the bootloader itself, or a minimal part of it, won't be updated, because a failed update of the bootloader poses a reliability risk 😬.
For a bootloader to offer secure boot functionality, it needs to implement the following 🔑:
- The bootloader needs to fetch the manifest from nonvolatile storage and parse its contents for subsequent cryptographic verification 📜.
- Cryptographic libraries with hash functions, digital signatures (for asymmetric crypto), and message authentication codes (for symmetric crypto) need to be accessible 🧁.
- The device needs a trust anchor store to verify the digital signature. Alternatively, access to a key store for use with the message authentication code may be used 🗝️.
- There must be an ability to expose boot-process-related data to the application firmware (such as the status tracker) 📣. This allows information sharing about the current firmware version, the status of the firmware update process, and whether errors have occurred 📊.
- Produce boot measurements as part of an attestation solution; see [RATS-ARCH] for more information (optional) 📸.
- The bootloader must be able to decrypt firmware images in case confidentiality protection was applied. This requires a solution for key management (optional) 🔓.
5. Types of IoT Devices 🌈
Today there are billions of MCUs in devices made by a huge number of silicon manufacturers 🤯. MCUs can vary a lot in their characteristics, but there are a bunch of similarities that let us sort them into groups 🗂️.
The firmware update architecture, and the manifest format in particular, needs enough flexibility to cover these common deployment cases 🦄.
5.1. Single MCU
The simplest and most common architecture (currently) is a single MCU with its own peripherals 🌱. These SoCs generally have some flash memory for code and fixed data, plus RAM for working storage 💾. A notable thing about these SoCs is that the primary code is generally execute in place (XIP) 🧠. Because the code isn't relocatable, the firmware image has to sit in a specific spot in flash memory, since the code can't run from just any location in there 📍. So when the firmware image gets updated, the old and new images have to be swapped 🔁.
5.2. Single CPU with Partitioning between Secure Mode and Normal Mode
Another setup is pretty similar to the one we just covered: it has a single CPU 🖥️. The difference is that this CPU supports a security partitioning scheme, so memory and other system components can be split into secure and normal mode 🔐. There will generally be two images, one for secure mode and one for normal mode 👯. Firmware upgrades are generally done by the CPU in secure mode, which can write to both areas of the flash device 💪. There are also requirements to update either image independently, and to update them together atomically, as specified in the associated manifests ⚛️.
5.3. Symmetric Multiple CPUs
In more complex SoCs with symmetric multiprocessing support, advanced operating systems like Linux are often used 🐧. These SoCs frequently use an external storage medium, such as raw NAND flash or an embedded Multimedia Card (eMMC) 💿. Because they have more resources, these devices can often store multiple copies of their firmware images and pick the most appropriate one to boot 🎯. Lots of SoCs also support bootloaders that can update the firmware image, but that's typically a last resort 🆘, because the device has to be held in the bootloader while the new firmware gets downloaded and installed, which means downtime ⏸️. Firmware updates in this class of device are typically not done in place 🙅♀️.
5.4. Dual CPU, Shared Memory
This configuration has two or more heterogeneous CPUs in a single SoC that share memory (flash and RAM) 👭. Generally, there's a mechanism to stop one CPU from accidentally accessing memory currently allocated to the other 🚧. Upgrades in this case are typically done by one of the CPUs, and it's similar to the single CPU with secure mode setup 💅.
5.5. Dual CPU, Other Bus
This configuration has two or more heterogeneous CPUs, each with their own memory 🧩. There's a communication channel between them, but it's used as a peripheral, not through shared memory 📡. In this case, each CPU has to be responsible for its own firmware upgrade 🙋♀️. It's likely that one of the CPUs will be considered the primary CPU and will direct the other CPU to do the upgrade 👑. This configuration is commonly used to offload specific work to other CPUs 🧚. Firmware dependencies are similar to the other solutions above: sometimes only one image can be upgraded, and other times several have to be upgraded atomically 🎀. Because the updates happen on multiple CPUs, upgrading the two images atomically is challenging 😵💫💜.
6. Manifests ✨
okay bestie, so when a firmware consumer wants to apply an update, it has to make a bunch of decisions using info from the manifest AND stuff already sitting on the device 🧚 for the full list of manifest info elements, check the information model spec [SUIT-INFO-MODEL] (it explains why each one is there 💅) and the manifest spec [SUIT-MANIFEST] for how it all gets packed in 🎀
+==========================+=====================================+
| Decision | Information Elements |
+==========================+=====================================+
| Should I trust the | Trust anchors and authorization |
| author of the firmware? | policies on the device |
+--------------------------+-------------------------------------+
| Has the firmware been | Digital signature and MAC covering |
| corrupted? | the firmware image |
+--------------------------+-------------------------------------+
| Does the firmware update | Conditions with Vendor ID, Class |
| apply to this device? | ID, and Device ID |
+--------------------------+-------------------------------------+
| Is the update older than | Sequence number in the manifest (1) |
| the active firmware? | |
+--------------------------+-------------------------------------+
| When should the device | Wait directive |
| apply the update? | |
+--------------------------+-------------------------------------+
| How should the device | Manifest commands |
| apply the update? | |
+--------------------------+-------------------------------------+
| What kind of firmware | Unpack algorithms to interpret a |
| binary is it? | format |
+--------------------------+-------------------------------------+
| Where should the update | Dependencies on other manifests and |
| be obtained? | firmware image URI in the manifest |
+--------------------------+-------------------------------------+
| Where should the | Storage location and component |
| firmware be stored? | identifier |
+--------------------------+-------------------------------------+
Table 1: Example Firmware Update Decisions(1): ngl this one's serious 😭 a device that gets handed an old-but-valid manifest and firmware must not be tricked into installing it, because a vulnerability in that old firmware image may let an attacker take control of the device 💀
keeping the code size and complexity of a manifest parser small is super important for constrained IoT devices 🌸 and since the manifest parsing code may also be used by the bootloader, it can be part of the trusted computing base ✨
a manifest can protect more than just firmware images 💖 it can also cover config data like network credentials or personalization data related to the firmware or software. personalization data is the reason confidentiality has to hold between two or more stakeholders who deliver images to the same device 👀 it's used with TEEs, which benefit from a protocol for managing the life cycle of TAs running inside a TEE. TEEs may obtain TAs from different authors, and those TAs may need personalization data, like payment information, securely conveyed to the TEE. the TA's author does not want to expose the TA's code to any other stakeholder or third party, and the user does not want to expose the payment information to any other stakeholder or third party. main character energy for privacy 🦋
7. Securing Firmware Updates 🔐
using firmware updates to fix vulnerabilities is important, but securing the update mechanism is equally important 😤 security problems get exacerbated by the update mechanism itself. an update is essentially authorized remote code execution, so any security problems in the update process expose that remote code execution system. failing to secure the firmware update process will help attackers take control of devices 💀
end-to-end security mechanisms protect the firmware image and the manifest 🫶 the following assumptions let the firmware consumer verify the received firmware image and manifest before updating the software:
- Authentication ensures that the device can cryptographically identify the author(s) creating firmware images and manifests 🪪 authenticated identities may be used as input to the authorization process. not all entities creating and signing manifests have the same permissions, so a device needs to determine whether the requested action is indeed covered by the permission of the party that signed the manifest. informing the device about the permissions of the different parties also happens in an out-of-band fashion, and that's a duty of the Trust Provisioning Authority 👑
- Integrity protection ensures that no third party can modify the manifest or the firmware image 🔒 to accept an update, a device needs to verify the signature covering the manifest. there may be one or multiple manifests that need to be validated, potentially signed by different parties. the device needs to be in possession of the trust anchors to verify those signatures. installing trust anchors to devices via the Trust Provisioning Authority happens in an out-of-band fashion prior to the firmware update process 🌈
- Confidentiality protection of the firmware image must be done in such a way that no one aside from the intended firmware consumer(s) and other authorized parties can decrypt it 🤫 the information encrypted individually for each device/recipient must be usable with Content Distribution Networks (CDNs), bulk storage, and broadcast protocols 📦 for confidentiality protection of firmware images, the author needs to be in possession of the certificate/public key or a pre-shared key of a device. the use of confidentiality protection of firmware images is optional 🎀
a manifest specification must support different cryptographic algorithms and algorithm extensibility 🧚 and since signature schemes based on RSA and Elliptic Curve Cryptography (ECC) may become vulnerable to quantum-accelerated key extraction in the future, unchangeable bootloader code in ROM is recommended to use post-quantum secure signature schemes such as hash-based signatures [RFC8778] 🔮 a bootloader author must carefully consider the service lifetime of their product and the time horizon for quantum-accelerated key extraction. at the time of writing, the worst-case estimate for that time horizon is approximately 2030, based on current research [quantum-factorization] ⏳ so plan ahead, bestie 😭
when a device obtains a monolithic firmware image from a single author with no additional approval steps, the authorization flow is relatively simple 😌 but there are other cases where more complex policy decisions need to be made before updating a device 🧩
in this architecture, the authorization policy is separated from the underlying communication architecture 🍓 this is accomplished by separating the entities from their permissions. for example, an author may not have the authority to install a firmware image on a device in critical infrastructure without the authorization of a device operator. in that case, the device may be programmed to reject firmware updates unless they are signed both by the firmware author and by the device operator 🏭
alternatively, a device may trust precisely one entity that does all permission management and coordination 🧚♀️ this entity lets the device offload complex permissions calculations. it's giving delegation, iykyk 💅
8. Example 🎬
Figure 2 illustrates an example message flow for distributing a firmware image to a device 📨 the firmware and manifest are stored on the same firmware server and distributed in a detached manner ✨
Okay bestie, this is the big sequence diagram 🦋 Figure 2 walks through the whole update, from the author making the firmware all the way to the device running it. Read it top to bottom and you'll see the manifest and firmware bounce between the server and the device, then the device checks everything before it boots 💅
+--------+ +-----------------+ +-----------------------------+
| | | Firmware Server | | IoT Device |
| Author | | Status Tracker | | +------------+ +----------+ |
+--------+ | Server | | | Firmware | |Bootloader| |
| +-----------------+ | | Consumer | | | |
| | | +------------+ +----------+ |
| | | | | |
| | | +-----------------------+ |
| | | | Status Tracker Client | |
|--------------+ | | +-----------------------+ |
| | | `''''''''''''''''''''''''''''
|<-------------+ | | | |
| | | | |
| Upload Firmware | | | |
|------------------>| | | |
| | | | |
| Create Manifest | | | |
|---------------+ | | | |
| | | | | |
|<--------------+ | | | |
| | | | |
| Sign Manifest | | | |
|-------------+ | | | |
| | | | | |
|<------------+ | | | |
| | | | |
| Upload Manifest | | | |
|------------------>| Notification of | | |
| | new firmware image | | |
| |----------------------------->| |
| | | | |
| | |Initiate| |
| | | Update | |
| | |<-------| |
| | | | |
| | Query Manifest | | |
| |<--------------------| . |
| | | . |
| | Send Manifest | . |
| |-------------------->| . |
| | | Validate |
| | | Manifest |
| | |--------+ |
| | | | |
| | |<-------+ |
| | | . |
| | Request Firmware | . |
| |<--------------------| . |
| | | . |
| | Send Firmware | . |
| |-------------------->| . |
| | | Verify . |
| | | Firmware |
| | |--------+ |
| | | | |
| | |<-------+ |
| | | . |
| | | Store . |
| | | Firmware |
| | |--------+ |
| | | | |
| | |<-------+ |
| | | . |
| | | . |
| | | . |
| | | | |
| | | Update | |
| | |Complete| |
| | |------->| |
| | | |
| | Firmware Update Completed | |
| |<-----------------------------| |
| | | |
| | Reboot | |
| |----------------------------->| |
| | | | |
| | | | |
| | | |Reboot |
| | | |------>|
| | | | |
| | | . |
| | +---+----------------+--+
| | S| | | |
| | E| | Verify | |
| | C| | Firmware | |
| | U| | +--------------| |
| | R| | | | |
| | E| | +------------->| |
| | | | | |
| | B| | Activate new | |
| | O| | Firmware | |
| | O| | +--------------| |
| | T| | | | |
| | | | +------------->| |
| | P| | | |
| | R| | Boot new | |
| | O| | Firmware | |
| | C| | +--------------| |
| | E| | | | |
| | S| | +------------->| |
| | S| | | |
| | +---+----------------+--+
| | | . |
| | | | |
| | . | |
| | Device running new firmware | |
| |<-----------------------------| |
| | . | |
| | | |Figure 2: First Example Flow for a Firmware Update
Now for Figure 3 🎀 this one is a different vibe. It starts with the status tracker server asking the device what firmware version it's currently running 🧚 Then, later, a shiny new firmware version drops ✨ and since this device is still on an older version, the status tracker server reaches out to the device to kick off an update 🔥
Okay so the manifest and the firmware live on different servers in this example 💜 When the device processes the manifest, it finds out where to download the new firmware version from 🦋 The firmware consumer then grabs the firmware image with the newer version X.Y.Z, but only after the manifest has been validated successfully 🫶
Next up, a reboot gets initiated, and the secure boot process kicks in 🌈 Finally, the device reports back that the new firmware version booted successfully 💖 Iconic, honestly 👑
Okay bestie, the figure picks up right where we left off 🦋
| | | |
| Query Firmware Version | |Wait, that's not it. Here's the continuation from the actual flow:
| | | |
| <<some time later>> | |
| | | |
_,...._ _,...._ | |
,' `. ,' `. | |
| New | | New | | |
\ Manifest / \ Firmware / | |
`.._ _,,' `.._ _,,' | |
`'' `'' | |
| Push manifest | |
|----------------+-------------------->| |
| | | |
| ' | '
| | | Validate |
| | | Manifest |
| | |---------+ |
| | | | |
| | |<--------+ |
| | Request firmware | |
| | X.Y.Z | |
| |<--------------------| |
| | | |
| | Firmware X.Y.Z | |
| |-------------------->| |
| | | |
| | | Verify |
| | | Firmware |
| | |--------------+ |
| | | | |
| | |<-------------+ |
| | | |
| | | Store |
| | | Firmware |
| | |-------------+ |
| | | | |
| | |<------------+ |
| | | |
| | | |
| | | Trigger Reboot |
| | |--------------->|
| | | |
| | | |
| | | __..-------..._'
| | ,-' `-.
| | | Secure Boot |
| | `-. _/
| | |`--..._____,,.,-'
| | | |
| Device running firmware X.Y.Z | |
|<-------------------------------------| |
| | | |
| | | |Figure 3: Second Example Flow for a Firmware Update ✨
9. IANA Considerations 🌸
This document has no IANA actions. Nothing to register, nothing to tick off in a registry, just vibes 💅
10. Security Considerations 🔥
This document is all about the terminology, the requirements, and an architecture for firmware updates of IoT devices. The whole point is to make IoT devices more secure through firmware update mechanisms, and it helps shape the standardization of a manifest format. Security is literally the main character here 👑
An in-depth examination of the security considerations of the architecture is presented in [SUIT-INFO-MODEL]. Go read that one too, it's the deep dive 🙈
11. Informative References 🧚
[LwM2M]Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification", Version 1.0.2, February 2018,<http://www.openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf>.[quantum-factorization]Jiang, S., Britt, K.A., McCaskey, A.J., Humble, T.S., and S. Kais, "Quantum Annealing for Prime Factorization", Scientific Reports 8, December 2018,<https://www.nature.com/articles/s41598-018-36058-z>.[RATS-ARCH]Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture-12, 23 April 2021,<https://tools.ietf.org/html/draft-ietf-rats-architecture-12>.[RFC6024]Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010,<https://www.rfc-editor.org/info/rfc6024>.[RFC6763]Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,<https://www.rfc-editor.org/info/rfc6763>.[RFC7228]Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014,<https://www.rfc-editor.org/info/rfc7228>.[RFC8240]Tschofenig, H. and S. Farrell, "Report from the Internet of Things Software Update (IoTSU) Workshop 2016", RFC 8240, DOI 10.17487/RFC8240, September 2017,<https://www.rfc-editor.org/info/rfc8240>.[RFC8778]Housley, R., "Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)", RFC 8778, DOI 10.17487/RFC8778, April 2020,<https://www.rfc-editor.org/info/rfc8778>.[SUIT-INFO-MODEL]Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest Information Model for Firmware Updates in IoT Devices", Work in Progress, Internet-Draft, draft-ietf-suit-information-model-11, 6 April 2021,<https://tools.ietf.org/html/draft-ietf-suit-information-model-11>.[SUIT-MANIFEST]Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-12, 22 February 2021,<https://tools.ietf.org/html/draft-ietf-suit-manifest-12>.[TEEP-ARCH]Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, "Trusted Execution Environment Provisioning (TEEP) Architecture", Work in Progress, Internet-Draft, draft-ietf-teep-architecture-14, 22 February 2021,<https://tools.ietf.org/html/draft-ietf-teep-architecture-14>.
Acknowledgements 🫶
Huge thank-you to these amazing people for their feedback:
- Geraint Luff
- Amyas Phillips
- Dan Ros
- Thomas Eichinger
- Michael Richardson
- Emmanuel Baccelli
- Ned Smith
- Jim Schaad
- Carsten Bormann
- Cullen Jennings
- Olaf Bergmann
- Suhas Nandakumar
- Phillip Hallam-Baker
- Marti Bolivar
- Andrzej Puzdrowski
- Markus Gueller
- Henk Birkholz
- Jintao Zhu
- Takeshi Takahashi
- Jacob Beningo
- Kathleen Moriarty
- Bob Briscoe
- Roman Danyliw
- Brian Carpenter
- Theresa Enghardt
- Rich Salz
- Mohit Sethi
- Éric Vyncke
- Alvaro Retana
- Barry Leiba
- Benjamin Kaduk
- Martin Duke
- Robert Wilton
Also a shoutout to the WG chairs, Russ Housley, David Waltermire, and Dave Thaler, for their support and review 👑
Authors' Addresses 🦋
Brendan Moran Arm Limited
Email: Brendan.Moran@arm.com
Hannes Tschofenig Arm Limited
Email: hannes.tschofenig@arm.com
David Brown Linaro
Email: david.brown@linaro.org
Milosch Meriac Consultant
Email: milosch@meriac.com
📦 where this page comes from
- ietf: rfc9019 2021-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms