diff options
Diffstat (limited to 'doc/rfc/rfc9019.txt')
| -rw-r--r-- | doc/rfc/rfc9019.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc9019.txt b/doc/rfc/rfc9019.txt new file mode 100644 index 0000000..4e85786 --- /dev/null +++ b/doc/rfc/rfc9019.txt @@ -0,0 +1,1291 @@ + + + + +Internet Engineering Task Force (IETF) B. Moran +Request for Comments: 9019 H. Tschofenig +Category: Informational Arm Limited +ISSN: 2070-1721 D. Brown + Linaro + M. Meriac + Consultant + April 2021 + + + A Firmware Update Architecture for Internet of Things + +Abstract + + Vulnerabilities in Internet of Things (IoT) devices have raised the + need for a reliable and secure firmware update mechanism suitable for + devices with resource constraints. Incorporating such an update + mechanism is a fundamental requirement for fixing vulnerabilities, + but it also enables other important capabilities such as updating + configuration settings and adding new functionality. + + In addition to the definition of terminology and an architecture, + this document provides the motivation for the standardization of a + manifest format as a transport-agnostic means for describing and + protecting firmware updates. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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' Addresses + +1. Introduction + + Firmware updates can help to fix security vulnerabilities, and + performing updates is an important building block in securing IoT + devices. Due to rising concerns about insecure IoT devices, the + Internet Architecture Board (IAB) organized the Internet of Things + Software Update (IoTSU) Workshop [RFC8240] to take a look at the + bigger picture. The workshop revealed a number of challenges for + developers and led to the formation of 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 requires skillful engineers. Once devices + are deployed, firmware updates play a critical part in their life- + cycle management, particularly when devices have a long lifetime or + are deployed in remote or inaccessible areas where manual + intervention is cost prohibitive or otherwise difficult. Firmware + updates for IoT devices are expected to work automatically, i.e., + without user involvement. Conversely, non-IoT devices are expected + to account for user preferences and consent when scheduling updates. + Automatic updates that do not require human intervention are key to a + scalable solution for fixing software vulnerabilities. + + Firmware updates are done not only to fix bugs but also to add new + functionality and to reconfigure the device to work in new + environments or to behave differently in an already-deployed context. + + 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 examples because it is + the preferred approach by many IoT deployments. The use of + symmetric credentials is also supported and can be used by very + constrained IoT devices. + + * The firmware image can be confidentiality protected so that + attempts by an adversary to recover the plaintext binary can be + mitigated or at least made more difficult. Obtaining the firmware + is often one of the first steps to mounting an attack since it + gives the adversary valuable insights into the software libraries + used, configuration settings, and generic functionality. Even + though reverse engineering the binary can be a tedious process, + modern reverse engineering frameworks have made this task a lot + easier. + + Authentication and integrity protection of firmware images must be + used in a deployment, but the confidential protection of firmware is + optional. + + While the standardization work has been informed by and optimized for + firmware update use cases of Class 1 devices (according to the device + class definitions in RFC 7228 [RFC7228]), there is nothing in the + architecture that restricts its use to only these constrained IoT + devices. Moreover, this architecture is not limited to managing + firmware and software updates but can also be applied to managing the + delivery of arbitrary data, such as configuration information and + keys. Unlike higher-end devices, like laptops and desktop PCs, many + IoT devices do not have user interfaces; therefore, support for + unattended updates is essential for the design of a practical + solution. Constrained IoT devices often use a software engineering + model where a developer is responsible for creating and compiling all + software running on the device into a single, monolithic firmware + image. On higher-end devices, application software is, on the other + hand, often downloaded separately and even obtained from developers + different from the developers of the lower-level software. The + details for how to obtain those application-layer software binaries + then depend heavily on the platform, the programming language used, + and the sandbox in which the software is executed. + + While the IETF standardization work has been focused on the manifest + format, a fully interoperable solution needs more than a standardized + manifest. For example, protocols for transferring firmware images + and manifests to the device need to be available, as well as the + status tracker functionality. Devices also require a mechanism to + discover the status tracker(s) and/or firmware servers, for example, + using preconfigured hostnames or DNS-based Service Discovery (DNS-SD) + [RFC6763]. These building blocks have been developed by various + organizations under the umbrella of an IoT device management + solution. The Lightweight Machine-to-Machine (LwM2M) protocol + [LwM2M] is one IoT device management protocol. + + However, there are several areas that (partially) fall outside the + scope of the IETF and other standards organizations but need to be + considered by firmware authors as well as device and network + operators. Here are some of them, as highlighted during the IoTSU + workshop: + + * Installing firmware updates in a robust fashion so that the update + does not break the device functionality of the environment in + which this device operates. This requires proper testing and + offering of recovery strategies when a firmware update is + unsuccessful. + + * Making firmware updates available in a timely fashion considering + the complexity of the decision-making process for updating + devices, potential recertification requirements, the length of a + supply chain an update needs to go through before it reaches the + end customer, and the need for user consent to install updates. + + * Ensuring an energy-efficient design of a battery-powered IoT + device; a firmware update, particularly radio communication and + writing the firmware image to flash, is an energy-intensive task + for a device. + + * Creating incentives for device operators to use a firmware update + mechanism and to require its integration from IoT device vendors. + + * Ensuring that firmware updates addressing critical flaws can be + obtained even after a product is discontinued or a vendor goes out + of business. + + This document starts with a terminology list followed by a + description of the architecture. We then explain the bootloader and + how it integrates with the firmware update mechanism. Subsequently, + we offer a categorization of IoT devices in terms of their hardware + capabilities relevant for firmware updates. Next, we talk about the + manifest structure and how to use it to secure firmware updates. We + conclude with a more detailed example of a message flow for + distributing a firmware image to a device. + +2. Conventions and Terminology + +2.1. Terms + + 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. + + 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 + + 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 + + (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: + + 1. It communicates the availability of a new firmware version. + This information will flow from the server to the client. + + 2. It conveys information about the software and hardware + characteristics of the device. The information flow is from + the client to the server. + + 3. 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 + + 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. + + Figure 1 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 / + \\ // \\ // + ---- ---- ---- ---- + ----- ----------- + + Figure 1: Architecture + + 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. + +4. Invoking the Firmware + + Section 3 describes the steps for getting the firmware image and the + manifest from the author to the firmware consumer on the IoT device. + Once the firmware consumer has retrieved and successfully processed + the manifest and the firmware image, it needs to invoke the new + firmware image. This is managed in many different ways depending on + the type of device, but it typically involves halting the current + version of the firmware, handing over control to firmware with a + higher privilege or trust level (the firmware verifier), verifying + the new firmware's authenticity and integrity, and then invoking it. + + In an execute-in-place microcontroller, this is often done by + rebooting into a bootloader (simultaneously halting the application + and handing over control to the higher privilege level) then + executing 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 implicitly + involves the kernel verifying the code signatures on the new + applications. + + The invocation process is security sensitive. An attacker will + typically try to retrieve a firmware image from the device for + reverse engineering or will try to get the firmware verifier to + execute an attacker-modified firmware image. Therefore, firmware + verifier will have to perform security checks on the firmware image + before it can be invoked. These security checks by the firmware + verifier happen in addition to the security checks that took place + when the firmware image and the manifest were downloaded by the + firmware consumer. + + The overlap between the firmware consumer and the firmware verifier + functionality comes in two forms, namely: + + * A firmware verifier must verify the firmware image it boots as + part of the secure boot process. Doing so requires metadata to be + stored alongside the firmware image so that the firmware verifier + can cryptographically verify the firmware image before booting it + to ensure it has not been tampered with or replaced. This + metadata used by the firmware verifier 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/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 to + perform the firmware update process again using firmware updates + over serial, USB, or even wireless connectivity like Bluetooth + Smart. In the latter case, the firmware consumer functionality is + contained in the recovery image and requires the necessary + functionality for executing the firmware update process, including + manifest parsing. + + While this document assumes that the firmware verifier itself is + distinct from the role of the firmware consumer and therefore does + not manage the firmware update process, this is not a requirement, + and these roles may be combined in practice. + + Using a bootloader as the firmware verifier requires some special + considerations, particularly when the bootloader implements the + robustness requirements identified by the IoTSU workshop [RFC8240]. + +4.1. The Bootloader + + In most cases, the MCU must restart in order to hand over control to + the bootloader. Once the MCU has initiated a restart, the bootloader + determines whether a newly available firmware image should be + executed. If the bootloader concludes that the newly available + firmware 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 of these approaches + have implications for the architecture of the update system. + + Assuming the first approach, there are (at least) three firmware + images available on the device: + + * First, the bootloader is also firmware. If a bootloader is + updatable, then its firmware image is treated like any other + application firmware image. + + * Second, the firmware image that has to be replaced is still + available on the device as a backup in case the freshly downloaded + firmware image does not boot or operate correctly. + + * Third, there is the newly downloaded firmware image. + + Therefore, the firmware consumer must know where to store the new + firmware. In some cases, this may be implicit (for example, + replacing the least recently used firmware image). In other cases, + the storage location of the new firmware must be explicit, for + example, when a device has one or more application firmware images + and a recovery image with limited functionality, sufficient only to + perform an update. + + Since many low-end IoT devices do not use position-independent code, + either the bootloader needs to copy the newly downloaded application + firmware image into the location of the old application firmware + image and vice versa or multiple versions of the firmware need to be + prepared for different locations. + + In general, it is assumed that the bootloader itself, or a minimal + part of it, will not be updated since a failed update of the + bootloader poses a reliability risk. + + For a bootloader to offer a secure boot functionality, it needs to + implement the following functionality: + + * 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 to have 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 and + 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 used in devices produced by a large + number of silicon manufacturers. While MCUs can vary significantly + in their characteristics, there are a number of similarities that + allow us to categorize them into groups. + + The firmware update architecture, and the manifest format in + particular, needs to offer enough flexibility to cover these common + deployment cases. + +5.1. Single MCU + + The simplest and currently most common architecture consists of a + single MCU along with its own peripherals. These SoCs generally + contain some amount of flash memory for code and fixed data, as well + as RAM for working storage. A notable characteristic of these SoCs + is that the primary code is generally execute in place (XIP). Due to + the non-relocatable nature of the code, the firmware image needs to + be placed in a specific location in flash memory since the code + cannot be executed from an arbitrary location therein. Hence, when + the firmware image is updated, it is necessary to swap the old and + the new image. + +5.2. Single CPU with Partitioning between Secure Mode and Normal Mode + + Another configuration consists of a similar architecture to the one + previously discussed: it contains a single CPU. However, this CPU + supports a security partitioning scheme that allows memory and other + system components to be divided into secure and normal mode. There + will generally be two images: one for secure mode and one for normal + mode. In this configuration, firmware upgrades will generally be + done by the CPU in secure mode, which is able to write to both areas + of the flash device. In addition, there are requirements to be able + to update either image independently as well as 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, such as Linux, are often used. These SoCs + frequently use an external storage medium, such as raw NAND flash or + an embedded Multimedia Card (eMMC). Due to the higher quantity of + resources, these devices are often capable of storing multiple copies + of their firmware images and selecting the most appropriate one to + boot. Many SoCs also support bootloaders that are capable of + updating the firmware image; however, this is typically a last resort + because it requires the device to be held in the bootloader while the + new firmware is downloaded and installed, which results in downtime + for the device. 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 will be a + mechanism to prevent one CPU from unintentionally accessing memory + currently allocated to the other. Upgrades in this case will + typically be done by one of the CPUs and is similar to the single CPU + with secure mode. + +5.5. Dual CPU, Other Bus + + This configuration has two or more heterogeneous CPUs, each having + their own memory. There will be a communication channel between + them, but it will be used as a peripheral, not via shared memory. In + this case, each CPU will have to be responsible for its own firmware + upgrade. It is 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 allowing only one image to be upgraded, other times + requiring several to be upgraded atomically. Because the updates are + happening on multiple CPUs, upgrading the two images atomically is + challenging. + +6. Manifests + + In order for a firmware consumer to apply an update, it has to make + several decisions using manifest-provided information and data + available on the device itself. For more detailed information and a + longer list of information elements in the manifest, consult the + information model specification [SUIT-INFO-MODEL], which offers + justifications for each element, and the manifest specification + [SUIT-MANIFEST] for details about how this information is included in + the manifest. + + +==========================+=====================================+ + | 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): A device presented with an old but valid manifest and firmware + must not be tricked into installing such firmware since a + vulnerability in the old firmware image may allow an attacker + to gain control of the device. + + Keeping the code size and complexity of a manifest parser small is + important for constrained IoT devices. Since the manifest parsing + code may also be used by the bootloader, it can be part of the + trusted computing base. + + A manifest may be used to protect not only firmware images but also + configuration data such as network credentials or personalization + data related to the firmware or software. Personalization data + demonstrates the need for confidentiality to be maintained between + two or more stakeholders that deliver images to the same device. + Personalization data is 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 require + personalization data, such as payment information, to be 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. The user does not + want to expose the payment information to any other stakeholder or + third party. + +7. Securing Firmware Updates + + Using firmware updates to fix vulnerabilities in devices is + important, but securing this update mechanism is equally important + since security problems are exacerbated by the update mechanism. An + update is essentially authorized remote code execution, so any + security problems in the update process expose that remote code + execution system. Failure to secure the firmware update process will + help attackers take control of devices. + + End-to-end security mechanisms are used to protect the firmware image + and the manifest. The following assumptions are made to allow the + firmware consumer to 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. 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 is 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 that is encrypted individually for each device/ + recipient must be done in a way that is 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. Moreover, 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 the time horizon to key extraction with quantum + acceleration is approximately 2030, based on current research + [quantum-factorization]. + + When a device obtains a monolithic firmware image from a single + author without any additional approval steps, the authorization flow + is relatively simple. However, 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 this 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 allows the + device to offload complex permissions calculations for the device. + +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. + + +--------+ +-----------------+ +-----------------------------+ + | | | Firmware Server | | IoT Device | + | Author | | Status Tracker | | +------------+ +----------+ | + +--------+ | Server | | | Firmware | |Bootloader| | + | +-----------------+ | | Consumer | | | | + | | | +------------+ +----------+ | + | | | | | | + | | | +-----------------------+ | + | Create Firmware | | | 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 + + Figure 3 shows an exchange that starts with the status tracker + querying the device for its current firmware version. Later, a new + firmware version becomes available, and since this device is running + an older version, the status tracker server interacts with the device + to initiate an update. + + The manifest and the firmware are stored on different servers in this + example. When the device processes the manifest, it learns where to + download the new firmware version. The firmware consumer downloads + the firmware image with the newer version X.Y.Z after successful + validation of the manifest. Subsequently, a reboot is initiated, and + the secure boot process starts. Finally, the device reports the + successful boot of the new firmware version. + + +---------+ +-----------------+ +-----------------------------+ + | Status | | Firmware Server | | +------------+ +----------+ | + | Tracker | | Status Tracker | | | Firmware | |Bootloader| | + | Server | | Server | | | Consumer | | | | + +---------+ +-----------------+ | | +Status | +----------+ | + | | | | Tracker | | | + | | | | Client | | | + | | | +------------+ | | + | | | | IoT Device | | + | | `'''''''''''''''''''''''''''' + | | | | + | Query Firmware Version | | + |------------------------------------->| | + | Firmware Version A.B.C | | + |<-------------------------------------| | + | | | | + | <<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. + +10. Security Considerations + + This document describes the terminology, requirements, and an + architecture for firmware updates of IoT devices. The content of the + document is thereby focused on improving the security of IoT devices + via firmware update mechanisms and informs the standardization of a + manifest format. + + An in-depth examination of the security considerations of the + architecture is presented in [SUIT-INFO-MODEL]. + +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 + + We would like to thank the following individuals 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 + + We would also like to thank 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 |