Change:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)

Discussion:
A Firmware Update Architecture for Internet of Things Devices <del> draft-ietf-suit-architecture-00 </del> <ins> draft-ietf-suit-architecture-01 </ins> Abstract

may be to fix bugs in software, to add new functionality, or to re- configure the device. <del> The firmware update process has to ensure that </del> <ins> The firmware update process, among other goals, has to ensure that </ins> The firmware image is authenticated and attempts to flash a malicious firmware image are prevented.

The following entities are used: <del> Author: The author is the entity that creates the firmware image, signs and/or encrypts it.  The author is most likely a developer using a set of tools. </del> <ins> Author: The author is the entity that creates the firmware image. There may be multiple authors in a system either when a device consists of multiple micro-controllers or when the the final firmware image consists of software components from multiple companies. </ins> Device: The device is the recipient of the firmware image and the <del> manifest.  The goal is to update the firmware of the device. Untrusted Storage: Firmware images and manifests may be stored on untrusted fileservers or cloud storage infrastructure.  Some deployments may require storage of the firmware images/manifests to be stored on various entities before they reach the device. </del> <ins> manifest.  The goal is to update the firmware of the device.  A single device may need to obtain more than one firmware image and manifest to succesfully perform an update. Communicator: The communicator component of the device interacts with the firmware update server.  It receives firmware images and triggers an update, if needed.  The communicator either polls a firmware update server for the most recent manifest/firmware or manifests/firmware images are pushed to it.  Note that the firmware update process may involve multiple stages since one or multiple manifests may need to be downloaded before the communicator can fetch one or multiple firmware images/software components. Status Tracker: The status tracker offers device management functionality that includes keep track of the firmware update process.  This includes fine-grained monitoring of changes at the device, for example, what state of the firmware update cycle the device is currently in. Firmware Server: Entity that stores firmware images and manifests. Some deployments may require storage of the firmware images/ manifests on more than one entities before they reach the device. Device Operator: The actor responsible for the day-to-day operation of a fleet of IoT devices. Network Operator: The actor responsible for the operation of a network to which IoT devices connect. In addition to the entities in the list above there is an orthogonal infrastructure with a Trust Provisioning Authority (TPA) distributing trust anchors and authorization permissions to various entities in the system.  The TPA may also delegate rights to install, update, enhance, or delete trust anchors and authorization permissions to other parties in the system.  This infrastructure overlaps the communication architecture and different deployments may empower certain entities while other deployments may not.  For example, in some cases, the Original Design Manufacturer (ODM), which is a company that designs and manufactures a product, may act as a TPA and may decide to remain in full control over the firmware update process of their products. The terms 'trust anchor' and 'trust anchor store' are defined in RFC6024: "A trust anchor 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." "A trust anchor store 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." Furthermore, the following abbreviations are used in this document: Microcontroller (MCU for microcontroller unit) is a small computer on a single integrated circuit, which is often used for mass volumne IoT devices. System on Chip (SoC) is an integrated circuit that integrates all components of a computer, such as CPU, memory, input/output ports, secondary storage, etc. Homogeneous Storage Architecture (HoSA): A device that stores all firmware components in the same way, for example in a file system or in flash memory. Heterogeneous Storage Architecture (HeSA): A device that stores at least one firmware component differently from the rest, for example a device with an external, updatable radio, or a device with internal and external flash memory. </ins> 3.

3.1. Firmware images can be conveyed to devices in a variety of ways, <del> including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and </del> <ins> including USB, UART, WiFi, BLE, low-power WAN technologies, etc.  and </ins> use different protocols (e.g., CoAP, HTTP).  The specified mechanism needs to be agnostic to the distribution of the firmware images and manifests.

3.9. <del> A device may have many modules that require updating individually. It may also need to trust several actors in order to authorize an update.  These actors might include the following (this is not a comprehensive list). These actors exert their authority on the device by making claims (as in claims). </del> <ins> When a device obtains a monolithic firmware image from a single author without any additional approval steps then the authorization flow is relatively simple.  There are, however, other cases where more complex policy decisions need to be made before updating a device. </ins> <del> For example, a firmware author may not have the authority to install firmware 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.  To facilitate complex use-cases such as this, updates require several claims. </del> <ins> 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. </ins> <del> Alternatively, a device may trust precisely one authority, which does all permission management and coordination.  Effectively, the authority allows the device to offload complex permissions calculations for the device. </del> <ins> Alternatively, a device may trust precisely one entity, which does all permission management and coordination.  This entity allows the device to offload complex permissions calculations for the device. </ins> 3.10. There are three broad classifications of update operating modes. <del> Self initiated updates take the form of a proactive IoT device that checks for updates.  Third-party initiated updates are triggered by an actor other than the IoT device, be it a server, a peer, or a user.  Hybrid updates are those that require agreement from both the target IoT device and another actor. Third-party initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. An IoT device goes through several steps in the course of an update, each of which can be self-initiated or third-party initiated, or hybrid.  An IoT device may go through the following steps, though this is not a comprehensive list. The notification step consists informing an IoT device that an update is available.  This can be accomplished via polling (self-initiated), push notifications (third-party initiated), or more complex mechanisms. The pre-authorisation step involves verifying the update authority and making a determination that the device is prepared to initiate the fetching and processing of updates.  If the device has all information that is necessary to make this determination, then the pre-authorisation may be self-initiated.  However, the device can wait for instruction to begin (third-party initiated).  Hybrid approaches are possible as well. </del> <ins> Client-initiated Update Server-initiated Update Hybrid Update Client-initiated updates take the form of a communicator on a device proactively checking for new firmware imagines provided by firmware servers. Server-initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments.  In this case the communicator, potentially in coordination with the status tracker, determines what devices qualify for a firmware update.  Once those devices have been selected the firmware server distributes updates to those devices. Note: This assumes that the firmware server is able to reach the device, which may require devices to keep reachability information at the communicator and / or at the firmware server up-to-date.  This may also require keeping state at NATs and stateful packet filtering firewalls alive. Hybrid updates are those that require an interaction between the device and the firmware server / communicator.  The communicator pushes notifications of availability of an update to the device, and the device then downloads the image from the firmware server when it wants. An alternative approach is to consider the steps a device has to go through in the course of an update: Notification Pre-authorisation Dependency resolution Download Installation The notification step consists of the communicator informing the device that an update is available.  This can be accomplished via polling (client-initiated), push notifications (server-initiated), or more complex mechanisms. The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update.  The device must also determine whether it should fetching and processing of the firmware image (unless it has been attached already to the manifest itself). </ins> 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 <del> payload.  When the download is self-initiated, this means that the IoT device chooses when a download occurs and initiates the download process.  When a download is third-party initiated, this means that either the remote service tells the IoT device when to download or that it initiates the transfer directly to the IoT device.  For example, a download from an HTTP server is initiated locally.  A transfer to a LwM2M Firmware Update resource LwM2M is initiated remotely. </del> <ins> firmware image.  When the download is client-initiated, this means that the device chooses when a download occurs and initiates the download process.  When a download is server-party initiated, this means that either the communicator / firmware server tells the device when to download or that it initiates the transfer directly to the device.  For example, a download from an HTTP-based firmware server is client-initiated.  A transfer to a LwM2M Firmware Update resource LwM2M is server-initiated. If the Device has downloaded a new firmware image and is ready to install it it may need to wait for a trigger from a Communicator to install the firmware update, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update (such as delaying the update process to a later time when end users are less impacted by the update process). </ins> Installation is the act of processing the payload into a format that <del> the IoT device can recognise. </del> <ins> the IoT device can recognise and the bootloader is responsible for then booting from the newly installed firmware image. </ins> <del> Each of these steps may require different permissions expressed in claims and may be implemented in a variety of ways. </del> <ins> Each of these steps may require different permissions. </ins> 4. <del> When a simple set of permissions fails to encapsulate the rules required for a device to make decisions about firmware, claims can be used instead.  Claims represent a form of policy.  Several claims can be used together, when multiple actors should have the rights to set policies. Some example claims are: </del> <ins> Claims in the manifest offer a way to convey instructions to a device that impact the firmware update process.  To have any value the manifest containing those claims must be authenticated and integrity protected.  The credential used to must be directly or indirectly related to the trust anchor installed at the device by the Trust Provisioning Authority. </ins> <del> Trust the actor identified by the referenced public key. Trust the actor with access to the referenced shared secret (MAC). Three actors are trusted identified by their public keys. Signatures from at least two of these actors are required to trust a manifest. The actor identified by the referenced public key is authorized to create secondary policies The baseline claims for all manifests are described in SUIT-IM.  In summary, they are: </del> <ins> The baseline claims for all manifests are described in I-D.ietf-suit- information-model.  For example, there are: </ins> Do not install firmware with earlier metadata than the current metadata.

Only install firmware that is before its best-before timestamp. <del> Only install firmware with metadata signed/authenticated by a trusted actor. Only allow an actor to exercise rights on the device via a manifest if that actor has signed the manifest. Only allow a firmware installation if all required rights have been met through signatures/MACs (one or more) or manifest dependencies (one or more). Use the instructions provided by the manifest to install the firmware. Install any and all firmware images that are linked together with manifest dependencies. </del> <ins> Only allow a firmware installation if dependencies have been met. </ins> Choose the mechanism to install the firmware, based on the type of firmware it is. 5. <del> We start the architectural description with the security model.  It is based on end-to-end security.  In e2e-figure a firmware image is created by an author, sent to the device and subsequently installed. When the author is ready to distribute the firmware image it is conveyed using some communication channel to the device, which will typically involve the use of untrusted storage.  Examples of untrusted storage are FTP servers, Web servers or USB sticks.  End- to-end security mechanisms are used to protect the firmware image. e2e-figure does not show the manifest itself, which provides the meta-data about the firmware image and offers the security protection.  It may bundled with the firmware image or travel as a standalone item. </del> <ins> arch-figure shows the communication architecture where a firmware image is created by an author, and uploaded to a firmware server. The firmware image/manifest is distributed to the device either in a push or pull manner using the communicator residing on the device. The device operator keeps track of the process using the status tracker.  This allows the device operator to know and control what devices have received an update and which of them are still pending an update. End-to-end security mechanisms are used to protect the firmware image and the manifest although e2e-figure does not show the manifest itself since it may be distributed independently. </ins> Whether the firmware image and the manifest is pushed to the device <del> or fetched by the device is outside the scope of this work and existing device management protocols can be used for efficiently distributing this information. </del> <ins> or fetched by the device is a deployment specific decision. </ins> The following assumptions are made to allow the device to verify the received firmware image and manifest before updating software: <del> To accept an update, a device needs to decide whether the author signing the firmware image and the manifest is authorized to make the updates.  We use public key cryptography to accomplish this. The device verifies the signature covering the manifest using a digital signature algorithm OR the device verifies the MAC covering the manifest using a MAC algorithm.  The device is provisioned with a trust anchor that is used to validate the digital signature or MAC produced by the author.  This trust anchor is potentially different from the trust anchor used to validate the digital signature produced for other protocols (such as device management protocols).  This trust anchor may be provisioned to the device during manufacturing or during commissioning. </del> <ins> 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. 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 also a duty of the Trust Provisioning Authority. </ins> For confidentiality protection of firmware images the author needs to be in possession of the certificate/public key or a pre-shared <del> key of a device. </del> <ins> key of a device.  The use of confidentiality protection of firmware images is deployment specific. </ins> There are different types of delivery modes, which are illustrated based on examples below.

cryptographic information, such as digital signatures or message authentication codes (MACs). <del> The manifest information model is described in SUIT-IM. </del> <ins> The manifest information model is described in I-D.ietf-suit- information-model. </ins> 7. <ins> Although these documents attempt to define a firmware update architecture that is applicable to both existing systems, as well as yet-to-be-conceived systems; it is still helpful to consider existing architectures. 7.1. 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.  These systems either have a single firmware image, or an immutable bootloader that runs a single image. A notable characteristic of these SoCs is that the primary code is generally execute in place (XIP).  Combined with the non-relocatable nature of the code, firmware updates need to be done in place. 7.2. Another configuration consists of a similar architecture to the previous, with a single CPU.  However, this CPU supports a security partitioning scheme that allows memory (in addition to other things) 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. 7.3. This configuration has two or more CPUs in a single SoC that share memory (flash and RAM).  Generally, they will be a protection mechanism to prevent one CPU from accessing the other's memory. Upgrades in this case will typically be done by one of the CPUs, and is similar to the single CPU with secure mode. 7.4. This configuration has two or more 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 a master, 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. 8. </ins> The following example message flow illustrates the interaction for distributing a firmware image to a device starting with an author <del> uploading the new firmware to untrusted storage and creating a manifest.  The firmware and manifest are stored on the same untrusted storage. </del> <ins> uploading the new firmware to Firmware Server and creating a manifest.  The firmware and manifest are stored on the same Firmware Server. </ins> <del> 8. </del> <ins> 9. </ins> This document does not require any actions by IANA. <del> 9. </del> <ins> 10. </ins> Firmware updates fix security vulnerabilities and are considered to be an important building block in securing IoT devices.  Due to the

incentives for manufacturers to offer a firmware update mechanism as part of their IoT products. <del> 10. </del> <ins> 11. </ins> The discussion list for this document is located at the e-mail address suit@ietf.org [1].  Information on the group and information

Archives of the list can be found at: https://www.ietf.org/mail- archive/web/suit/current/index.html [3] <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] mailto:suit@ietf.org