idnits 2.17.00 (12 Aug 2021) /tmp/idnits36654/draft-ietf-suit-architecture-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2020) is 581 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7519' is defined on line 1229, but no explicit reference was found in the text == Unused Reference: 'RFC8392' is defined on line 1238, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rats-architecture-06 == Outdated reference: draft-ietf-suit-information-model has been published as RFC 9124 == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-09 == Outdated reference: A later version (-17) exists of draft-ietf-teep-architecture-12 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft H. Tschofenig 4 Intended status: Informational Arm Limited 5 Expires: April 19, 2021 D. Brown 6 Linaro 7 M. Meriac 8 Consultant 9 October 16, 2020 11 A Firmware Update Architecture for Internet of Things 12 draft-ietf-suit-architecture-13 14 Abstract 16 Vulnerabilities with Internet of Things (IoT) devices have raised the 17 need for a reliable and secure firmware update mechanism suitable for 18 devices with resource constraints. Incorporating such an update 19 mechanism is a fundamental requirement for fixing vulnerabilities but 20 it also enables other important capabilities such as updating 21 configuration settings as well as adding new functionality. 23 In addition to the definition of terminology and an architecture this 24 document motivates the standardization of a manifest format as a 25 transport-agnostic means for describing and protecting firmware 26 updates. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 19, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 64 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Stakeholders . . . . . . . . . . . . . . . . . . . . . . 6 66 2.3. Functions . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Invoking the Firmware . . . . . . . . . . . . . . . . . . . . 12 69 4.1. The Bootloader . . . . . . . . . . . . . . . . . . . . . 14 70 5. Types of IoT Devices . . . . . . . . . . . . . . . . . . . . 15 71 5.1. Single MCU . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.2. Single CPU with Secure - Normal Mode Partitioning . . . . 16 73 5.3. Symmetric Multiple CPUs . . . . . . . . . . . . . . . . . 16 74 5.4. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 16 75 5.5. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17 76 6. Manifests . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 7. Securing Firmware Updates . . . . . . . . . . . . . . . . . . 19 78 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 82 12. Informative References . . . . . . . . . . . . . . . . . . . 26 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 85 1. Introduction 87 Firmware updates can help to fix security vulnerabilities and are 88 considered to be an important building block in securing IoT devices. 89 Due to rising concerns about insecure IoT devices the Internet 90 Architecture Board (IAB) organized a 'Workshop on Internet of Things 91 (IoT) Software Update (IOTSU)', which took place at Trinity College 92 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 93 the bigger picture. A report about this workshop can be found at 94 [RFC8240]. The workshop revealed a number of challenges for 95 developers and led to the formation of the IETF Software Updates for 96 Internet of Things (SUIT) working group. 98 Developing secure Internet of Things (IoT) devices is not an easy 99 task and supporting a firmware update solution requires skillful 100 engineers. Once devices are deployed, firmware updates play a 101 critical part in their lifecycle management, particularly when 102 devices have a long lifetime, or are deployed in remote or 103 inaccessible areas where manual intervention is cost prohibitive or 104 otherwise difficult. Firmware updates 105 for IoT devices are expected to work automatically, i.e. without user 106 involvement. Automatic updates that do not require human 107 intervention are key to a scalable solution for fixing software 108 vulnerabilities. 110 Firmware updates are not only done to fix bugs, but they can also add 111 new functionality, and re-configure the device to work in new 112 environments or to behave differently in an already deployed context. 114 The firmware update process has to ensure that 116 - The firmware image is authenticated and integrity protected. 117 Attempts to flash a maliciously modified firmware image or an 118 image from an unknown, untrusted source must be prevented. In 119 examples this document uses asymmetric cryptography because it is 120 the preferred approach by many IoT deployments. The use of 121 symmetric credentials is also supported and can be used by very 122 constrained IoT devices. 124 - The firmware image can be confidentiality protected so that 125 attempts by an adversary to recover the plaintext binary can be 126 mitigated or at least made more difficult. Obtaining the firmware 127 is often one of the first steps to mount an attack since it gives 128 the adversary valuable insights into the software libraries used, 129 configuration settings and generic functionality. Even though 130 reverse engineering the binary can be a tedious process modern 131 reverse engineering frameworks have made this task a lot easier. 133 While the standardization work has been informed by and optimized for 134 firmware update use cases of Class 1 devices (according to the device 135 class definitions in RFC 7228 [RFC7228]) devices, there is nothing in 136 the architecture that restricts its use to only these constrained IoT 137 devices. Moreover, this architecture is not limited to managing 138 software updates, but can also be applied to managing the delivery of 139 arbitrary data, such as configuration information and keys. Unlike 140 higher end devices, like laptops and desktop PCs, many IoT devices do 141 not have user interfaces and support for unattended updates is, 142 therefore, essential for the design of a practical solution. 143 Constrained IoT devices often use a software engineering model where 144 a developer is responsible for creating and compiling all software 145 running on the device into a single, monolithic firmware image. On 146 higher end devices application software is, on the other hand, often 147 downloaded separately and even obtained from developers different to 148 the developers of the lower level software. The details for how to 149 obtain those application layer software binaries then depends heavily 150 on the platform, programming language uses and the sandbox the 151 software is executed in. 153 While the IETF standardization work has been focused on the manifest 154 format, a fully interoperable solution needs more than a standardized 155 manifest. For example, protocols for transferring firmware images 156 and manifests to the device need to be available as well as the 157 status tracker functionality. Devices also require a mechanism to 158 discover the status tracker(s) and/or firmware servers. These 159 building blocks have been developed by various organizations under 160 the umbrella of an IoT device management solution. The LwM2M 161 protocol is one IoT device management protocol. 163 There are, however, several areas that (partially) fall outside the 164 scope of the IETF and other standards organizations but need to be 165 considered by firmware authors, as well as device and network 166 operators. Here are some of them, as highlighted during the IOTSU 167 workshop: 169 - Installing firmware updates in a robust fashion so that the update 170 does not break the device functionality of the environment this 171 device operates in. This requires proper testing and offering 172 recovery strategies when a firmware update is unsuccessful. 174 - Making firmware updates available in a timely fashion considering 175 the complexity of the decision making process for updating 176 devices, potential re-certification requirements, the length of a 177 supply chain an update needs to go through before it reaches the 178 end customer, and the need for user consent to install updates. 180 - Ensuring an energy efficient design of a battery-powered IoT 181 devices because a firmware update, particularly writing the 182 firmware image to flash, is a heavy task for a device. 184 - Creating incentives for device operators to use a firmware update 185 mechanism and to demand the integration of it from IoT device 186 vendors. 188 - Ensuring that firmware updates addressing critical flaws can be 189 obtained even after a product is discontinued or a vendor goes out 190 of business. 192 This document starts with a terminology followed by the description 193 of the architecture. We then explain the bootloader and how it 194 integrates with the firmware update mechanism. Subsequently, we 195 offer a categorization of IoT devices in terms of their hardware 196 capabilities relevant for firmware updates. Next, we talk about the 197 manifest structure and how to use it to secure firmware updates. We 198 conclude with a more detailed example. 200 2. Conventions and Terminology 202 2.1. Terms 204 This document uses the following terms: 206 - Firmware Image: The firmware image, or image, is a binary that may 207 contain the complete software of a device or a subset of it. The 208 firmware image may consist of multiple images, if the device 209 contains more than one microcontroller. Often it is also a 210 compressed archive that contains code, configuration data, and 211 even the entire file system. The image may consist of a 212 differential update for performance reasons. 214 The terms, firmware image, firmware, and image, are used in this 215 document and are interchangeable. We use the term application 216 firmware image to differentiate it from a firmware image that 217 contains the bootloader. An application firmware image, as the 218 name indicates, contains the application program often including 219 all the necessary code to run it (such as protocol stacks, and 220 embedded operating system). 222 - Manifest: The manifest contains meta-data about the firmware 223 image. The manifest is protected against modification and 224 provides information about the author. 226 - Microcontroller (MCU for microcontroller unit): An MCU is a 227 compact integrated circuit designed for use in embedded systems. 228 A typical microcontroller includes a processor, memory (RAM and 229 flash), input/output (I/O) ports and other features connected via 230 some bus on a single chip. The term 'system on chip (SoC)' is 231 often used interchangeably with MCU, but MCU tends to imply more 232 limited peripheral functions. 234 - Rich Execution Environment (REE): An environment that is provided 235 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 236 potentially in conjunction with other supporting operating systems 237 and hypervisors; it is outside of the TEE. This environment and 238 applications running on it are considered un-trusted. 240 - System on Chip (SoC): An SoC is an integrated circuit that 241 contains all components of a computer, such as CPU, memory, input/ 242 output ports, secondary storage, a bus to connect the components, 243 and other hardware blocks of logic. 245 - Trust Anchor: A trust anchor, as defined in [RFC6024], represents 246 an authoritative entity via a public key and associated data. The 247 public key is used to verify digital signatures, and the 248 associated data is used to constrain the types of information for 249 which the trust anchor is authoritative." 251 - Trust Anchor Store: A trust anchor store, as defined in [RFC6024], 252 is a set of one or more trust anchors stored in a device. A 253 device may have more than one trust anchor store, each of which 254 may be used by one or more applications. A trust anchor store 255 must resist modification against unauthorized insertion, deletion, 256 and modification. 258 - Trusted Applications (TAs): An application component that runs in 259 a TEE. 261 - Trusted Execution Environments (TEEs): An execution environment 262 that runs alongside of, but is isolated from, an REE. For more 263 information about TEEs see [I-D.ietf-teep-architecture]. 265 2.2. Stakeholders 267 The following stakeholders are used in this document: 269 - Author: The author is the entity that creates the firmware image. 270 There may be multiple authors involved in producing firmware 271 running on an IoT device. Section 5 talks about those IoT device 272 deployment cases. 274 - Device Operator: The device operator is responsible for the day- 275 to-day operation of a fleet of IoT devices. Customers of IoT 276 devices, as the owners of IoT devices - such as enterprise 277 customers or end users, interact with their IoT devices indirectly 278 through the device operator via web or smart phone apps. 280 - Network Operator: The network operator is responsible for the 281 operation of a network to which IoT devices connect. 283 - Trust Provisioning Authority (TPA): The TPA distributes trust 284 anchors and authorization policies to various stakeholders. The 285 TPA may also delegate rights to stakeholders. For example, in 286 some cases, the Original Design Manufacturer (ODM), which is a 287 company that designs and manufactures a product, may act as a TPA 288 and may decide to remain in full control over the firmware update 289 process of their products. 291 2.3. Functions 293 - (IoT) Device: A device refers to the entire IoT product, which 294 consists of one or many MCUs, sensors and/or actuators. Many IoT 295 devices sold today contain multiple MCUs and therefore a single 296 device may need to obtain more than one firmware image and 297 manifest to successfully perform an update. 299 - Status Tracker: The status tracker has a client and a server 300 component and performs three tasks: 1) It communicates the 301 availability of a new firmware version. This information will 302 flow from the server to the client. 303 2) It conveys information about software and hardware 304 characteristics of the device. The information flow is from the 305 client to the server. 306 3) It can remotely trigger the firmware update process. The 307 information flow is from the server to the client. 309 For example, a device operator may want to read the installed 310 firmware version number running on the device and information 311 about available flash memory. Once an update has been triggered, 312 the device operator may want to obtain information about the state 313 of the firmware update. If errors occurred, the device operator 314 may want to troubleshoot problems by first obtaining diagnostic 315 information (typically using a device management protocol). 317 We make no assumptions about where the server-side component is 318 deployed. The deployment of status trackers is flexible and may 319 be found at 320 cloud-based servers, on-premise servers, or may be embedded in 321 edge computing device. A status tracker server component may even 322 be deployed on an IoT device. For example, if the IoT device 323 contains multiple MCUs, then the main MCU may act as a status 324 tracker towards the other MCUs. Such deployment is useful when 325 updates have to be synchronized across MCUs. 327 The status tracker may be operated by any suitable stakeholder; 328 typically the Author, Device Operator, or Network Operator. 330 - Firmware Consumer: The firmware consumer is the recipient of the 331 firmware image and the manifest. It is responsible for parsing 332 and verifying the received manifest and for storing the obtained 333 firmware image. The firmware consumer plays the role of the 334 update component on the IoT device typically running in the 335 application firmware. It interacts with the firmware server and 336 with the status tracker client (locally). 338 - Firmware Server: The firmware server stores firmware images and 339 manifests and distributes them to IoT devices. Some deployments 340 may require a store-and-forward concept, which requires storing 341 the firmware images/manifests on more than one entity before 342 they reach the device. There is typically some interaction 343 between the firmware server and the status tracker and these two 344 entities are often physically separated on different devices for 345 scalability reasons. 347 - Bootloader: A bootloader is a piece of software that is executed 348 once a microcontroller has been reset. It is responsible for 349 deciding what code to execute. 351 3. Architecture 353 More devices today than ever before are connected to the Internet, 354 which drives the need for firmware updates to be provided over the 355 Internet rather than through traditional interfaces, such as USB or 356 RS-232. Updating updates over the Internet requires the device to 357 fetch the new firmware image as well as the manifest. 359 Hence, the following components are necessary on a device for a 360 firmware update solution: 362 - the Internet protocol stack for firmware downloads. Because 363 firmware images are often multiple kilobytes, sometimes exceeding 364 one hundred kilobytes, in size for low end IoT devices and even 365 several megabytes large for IoT devices running full-fledged 366 operating systems like Linux, the protocol mechanism for 367 retrieving these images needs to offer features like congestion 368 control, flow control, fragmentation and reassembly, and 369 mechanisms to resume interrupted or corrupted transfers. 371 - the capability to write the received firmware image to persistent 372 storage (most likely flash memory). 374 - a manifest parser with code to verify a digital signature or a 375 message authentication code. 377 - the ability to unpack, to decompress and/or to decrypt the 378 received firmware image. 380 - (optionally) a status tracker. 382 The features listed above are most likely offered by code in the 383 application firmware image running on the device rather than by the 384 bootloader itself. Note that cryptographic algorithms will likely 385 run in a trusted execution environment, on a separate MCU, in a 386 hardware security module, or in a secure element rather than in the 387 same context with the application code. 389 Figure 1 shows the architecture where a firmware image is created by 390 an author, and made available to a firmware server. For security 391 reasons, the author will not have the permissions to upload firmware 392 images to the firmware server and to initiate an update him- or 393 herself. Instead, authors will make firmware images available to the 394 device operators. Note that there may be a longer supply chain 395 involved to pass software updates from the author all the way to the 396 party that can then finally make a decision to deploy it with IoT 397 devices. 399 As a first step in the firmware update process, the status tracker 400 client need to be made aware of the availability of a new firmware 401 update by the status tracker server. This can be accomplished via 402 polling (client-initiated), push notifications (server-initiated), or 403 more complex mechanisms (such as a hybrid approach): 405 - Client-initiated updates take the form of a status tracker client 406 proactively checking (polling) for updates. 408 - With Server-initiated updates the server-side component of the 409 status tracker learns about a new firmware version and determines 410 what devices qualify for a firmware update. Once the relevant 411 devices have been selected, the status tracker informs these 412 devices and the firmware consumers obtain those images and 413 manifests. Server-initiated updates are important because they 414 allow a quick response time. Note that the client-side status 415 tracker needs to be reachable by the server-side component. This 416 may require devices to keep reachability information on the 417 server-side up-to-date and state at NATs and stateful packet 418 filtering firewalls alive. 420 - Using a hybrid approach the server-side of the status tracker 421 pushes notifications of availability of an update to the client 422 side and requests the firmware consumer to pull the manifest and 423 the firmware image from the firmware server. 425 Once the device operator triggers update via the status tracker, it 426 will keep track of the update process on the device. This allows the 427 device operator to know what devices have received an update and 428 which of them are still pending an update. 430 Firmware images can be conveyed to devices in a variety of ways, 431 including USB, UART, WiFi, BLE, low-power WAN technologies, mesh 432 networks and many more. At the application layer a variety of 433 protocols are also available: MQTT, CoAP, and HTTP are the most 434 popular application layer protocols used by IoT devices. This 435 architecture does not make assumptions about how the firmware images 436 are distributed to the devices and therefore aims to support all 437 these technologies. 439 In some cases it may be desirable to distribute firmware images using 440 a multicast or broadcast protocol. This architecture does not make 441 recommendations for any such protocol. However, given that broadcast 442 may be desirable for some networks, updates must cause the least 443 disruption possible both in metadata and firmware transmission. For 444 an update to be broadcast friendly, it cannot rely on link layer, 445 network layer, or transport layer security. A solution has to rely 446 on security protection applied to the manifest and firmware image 447 instead. In addition, the same manifest must be deliverable to many 448 devices, both those to which it applies and those to which it does 449 not, without a chance that the wrong device will accept the update. 450 Considerations that apply to network broadcasts apply equally to the 451 use of third-party content distribution networks for payload 452 distribution. 454 +----------+ 455 | | 456 | Author | 457 | | 458 +----------+ 459 Firmware + Manifest | 460 +----------------------------------+ | Firmware + 461 | | | Manifest 462 | ---+------- | 463 | ---- | --|- 464 | //+----------+ | \\ 465 -+-- // | | | \ 466 ----/ | ---- |/ | Firmware |<-+ | \ 467 // | \\ | | Server | | | \ 468 / | \ / | | + + \ 469 / | \ / +----------+ \ / | 470 / +--------+--------+ \ / | | 471 / | v | \ / v | 472 | | +------------+ | | | +----------------+ | 473 | | | Firmware | | | Device | | 474 | | | Consumer | | | | | Management | | 475 | | +------------+ | | | | | | 476 | | +------------+ | | | | +--------+ | | 477 | | | Status |<-+--------------------+-> | | | | 478 | | | Tracker | | | | | | Status | | | 479 | | | Client | | | | | | Tracker| | | 480 | | +------------+ | | | | | Server | | | 481 | | Device | | | | +--------+ | | 482 | +-----------------+ | \ | | / 483 \ / \ +----------------+ / 484 \ Network / \ / 485 \ Operator / \ Device Operator / 486 \\ // \ \ // 487 ---- ---- ---- ---- 488 ----- ----------- 490 Figure 1: Architecture. 492 Firmware images and manifests may be conveyed as a bundle or 493 detached. The manifest must support both approaches. 495 For distribution as a bundle, the firmware image is embedded into the 496 manifest. This is a useful approach for deployments where devices 497 are not connected to the Internet and cannot contact a dedicated 498 firmware server for the firmware download. It is also applicable 499 when the firmware update happens via a USB sticks or short range 500 radio technologies (such as Bluetooth Smart). 502 Alternatively, the manifest is distributed detached from the firmware 503 image. Using this approach, the firmware consumer is presented with 504 the manifest first and then needs to obtain one or more firmware 505 images as dictated in the manifest. 507 The pre-authorisation step involves verifying whether the entity 508 signing the manifest is indeed authorized to perform an update. The 509 firmware consumer must also determine whether it should fetch and 510 process a firmware image, which is referenced in a manifest. 512 A dependency resolution phase is needed when more than one component 513 can be updated or when a differential update is used. The necessary 514 dependencies must be available prior to installation. 516 The download step is the process of acquiring a local copy of the 517 firmware image. When the download is client-initiated, this means 518 that the firmware consumer chooses when a download occurs and 519 initiates the download process. When a download is server-initiated, 520 this means that the status tracker tells the device when to download 521 or that it initiates the transfer directly to the firmware consumer. 522 For example, a download from an HTTP/1.1-based firmware server is 523 client-initiated. Pushing a manifest and firmware image to the 524 Package resource of the LwM2M Firmware Update object [LwM2M] is 525 server-initiated update. 527 If the firmware consumer has downloaded a new firmware image and is 528 ready to install it, to initiate the installation, it may - either 529 need to wait for a trigger from the status tracker, - or trigger the 530 update automatically, - or go through a more complex decision making 531 process to determine the appropriate timing for an update. Sometimes 532 the final decision may require confirmation of the user of the device 533 for safety reasons. 535 Installation is the act of processing the payload into a format that 536 the IoT device can recognize and the bootloader is responsible for 537 then booting from the newly installed firmware image. This process 538 is different when a bootloader is not involved. For example, when an 539 application is updated in a full-featured operating system, the 540 updater may halt and restart the application in isolation. Devices 541 must not fail when a disruption occurs during the update process. 542 For example, a power failure or network disruption during the update 543 process must not cause the device to fail. 545 4. Invoking the Firmware 547 Section 3 describes the steps for getting the firmware image and the 548 manifest from the author to the firmware consumer on the IoT device. 549 Once the firmware consumer has retrieved and successfully processed 550 the manifest and the firmware image it needs to invoke the new 551 firmware image. This is managed in many different ways, depending on 552 the type of device, but it typically involves halting the current 553 version of the firmware, handing control over to a firmware with a 554 higher privilege/trust level (the firmware verifier) verifying the 555 new firmware's authenticity & integrity, and then invoking it. 557 In an execute-in-place microcontroller, this is often done by 558 rebooting into a bootloader (simultaneously halting the application & 559 handing over to the higher privilege level) then executing a secure 560 boot process (verifying and invoking the new image). 562 In a rich OS, this may be done by halting one or more processes, then 563 invoking new applications. In some OSs, this implicitly involves the 564 kernel verifying the code signatures on the new applications. 566 The invocation process is security sensitive. An attacker will 567 typically try to retrieve a firmware image from the device for 568 reverse engineering or will try to get the firmware verifier to 569 execute an attacker-modified firmware image. The firmware verifier 570 will therefore have to perform security checks on the firmware image 571 before it can be invoked. These security checks by the firmware 572 verifier happen in addition to the security checks that took place 573 when the firmware image and the manifest were downloaded by the 574 firmware consumer. 576 The overlap between the firmware consumer and the firmware verifier 577 functionality comes in two forms, namely 579 - A firmware verifier must verify the firmware image it boots as 580 part of the secure boot process. Doing so requires meta-data to 581 be stored alongside the firmware image so that the firmware 582 verifier can cryptographically verify the firmware image before 583 booting it to ensure it has not been tampered with or replaced. 584 This meta-data used by the firmware verifier may well be the same 585 manifest obtained with the firmware image during the update 586 process. 588 - An IoT device needs a recovery strategy in case the firmware 589 update / invocation process fails. The recovery strategy may 590 include storing two or more application firmware images on the 591 device or offering the ability to invoke a recovery image to 592 perform the firmware update process again using firmware updates 593 over serial, USB or even wireless connectivity like Bluetooth 594 Smart. In the latter case the firmware consumer functionality is 595 contained in the recovery image and requires the necessary 596 functionality for executing the firmware update process, including 597 manifest parsing. 599 While this document assumes that the firmware verifier itself is 600 distinct from the role of the firmware consumer and therefore does 601 not manage the firmware update process, this is not a requirement and 602 these roles may be combined in practice. 604 Using a bootloader as the firmware verifier requires some special 605 considerations, particularly when the bootloader implements the 606 robustness requirements identified by the IOTSU workshop [RFC8240]. 608 4.1. The Bootloader 610 In most cases the MCU must restart in order to hand over control to 611 the bootloader. Once the MCU has initiated a restart, the bootloader 612 determines whether a newly available firmware image should be 613 executed. If the bootloader concludes that the newly available 614 firmware image is invalid, a recovery strategy is necessary. There 615 are only two approaches recovering from an invalid firmware: either 616 the bootloader must be able to select a different, valid firmware, or 617 it must be able to obtain a new, valid firmware. Both of these 618 approaches have implications for the architecture of the update 619 system. 621 Assuming the first approach, there are (at least) three firmware 622 images available on the device: 624 - First, the bootloader is also firmware. If a bootloader is 625 updatable then its firmware image is treated like any other 626 application firmware image. 628 - Second, the firmware image that has to be replaced is still 629 available on the device as a backup in case the freshly downloaded 630 firmware image does not boot or operate correctly. 632 - Third, there is the newly downloaded firmware image. 634 Therefore, the firmware consumer must know where to store the new 635 firmware. In some cases, this may be implicit, for example replacing 636 the least-recently-used firmware image. In other cases, the storage 637 location of the new firmware must be explicit, for example when a 638 device has one or more application firmware images and a recovery 639 image with limited functionality, sufficient only to perform an 640 update. 642 Since many low end IoT devices use non-relocatable code, either the 643 bootloader needs to copy the newly downloaded application firmware 644 image into the location of the old application firmware image and 645 vice versa or multiple versions of the firmware need to be prepared 646 for different locations. 648 In general, it is assumed that the bootloader itself, or a minimal 649 part of it, will not be updated since a failed update of the 650 bootloader poses a reliability risk. 652 For a bootloader to offer a secure boot functionality it needs to 653 implement the following functionality: 655 - The bootloader needs to fetch the manifest (or manifest-alike 656 headers) from nonvolatile storage and parse its contents for 657 subsequent cryptographic verification. 659 - Cryptographic libraries with hash functions, digital signatures 660 (for asymmetric crypto), keyed message digests (for symmetric 661 crypto) need to be accessible. 663 - The device needs to have a trust anchor store to verify the 664 digital signature. (Alternatively, access to a key store for use 665 with the keyed message digest.) 667 - Ability to expose boot process-related data to the application 668 firmware (such as to the status tracker). This allows to share 669 information about the current firmware version, and the status of 670 the firmware update process and whether errors have occurred. 672 - Produce boot measurements as part of an attestation solution. See 673 [I-D.ietf-rats-architecture] for more information. (optional) 675 - Ability to decrypt firmware images, in case confidentiality 676 protection was applied). This requires a solution for key 677 management. (optional) 679 5. Types of IoT Devices 681 There are billions of MCUs used in devices today produced by a large 682 number of silicon manufacturers. While MCUs can vary significantly 683 in their characteristics, there are a number of similiaries allowing 684 us to categorize in groups. 686 The firmware update architecture, and the manifest format in 687 particular, needs to offer enough flexibility to cover these common 688 deployment cases. 690 5.1. Single MCU 692 The simplest, and currently most common, architecture consists of a 693 single MCU along with its own peripherals. These SoCs generally 694 contain some amount of flash memory for code and fixed data, as well 695 as RAM for working storage. A notable characteristic of these SoCs 696 is that the primary code is generally execute in place (XIP). Due to 697 the non-relocatable nature of the code, the firmware image needs to 698 be placed in a specific location in flash since the code cannot be 699 executed from an arbitrary location in flash. Hence, then the 700 firmware image is updated it is necessary to swap the old and the new 701 image. 703 5.2. Single CPU with Secure - Normal Mode Partitioning 705 Another configuration consists of a similar architecture to the 706 previous, with a single CPU. However, this CPU supports a security 707 partitioning scheme that allows memory (in addition to other things) 708 to be divided into secure and normal mode. There will generally be 709 two images, one for secure mode, and one for normal mode. In this 710 configuration, firmware upgrades will generally be done by the CPU in 711 secure mode, which is able to write to both areas of the flash 712 device. In addition, there are requirements to be able to update 713 either image independently, as well as to update them together 714 atomically, as specified in the associated manifests. 716 5.3. Symmetric Multiple CPUs 718 In more complex SoCs with symmetric multi-processing support, 719 advanced operating systems, such as Linux, are often used. These 720 SoCs frequently use an external storage medium, such as raw NAND 721 flash or eMMC. Due to the higher quantity of resources, these 722 devices are often capable of storing multiple copies of their 723 firmware images and selecting the most appropriate one to boot. Many 724 SoCs also support bootloaders that are capable of updating the 725 firmware image, however this is typically a last resort because it 726 requires the device to be held in the bootloader while the new 727 firmware is downloaded and installed, which results in down-time for 728 the device. Firmware updates in this class of device are typically 729 not done in-place. 731 5.4. Dual CPU, shared memory 733 This configuration has two or more heterogeneous CPUs in a single SoC 734 that share memory (flash and RAM). Generally, there will be a 735 mechanism to prevent one CPU from unintentionally accessing memory 736 currently allocated to the other. Upgrades in this case will 737 typically be done by one of the CPUs, and is similar to the single 738 CPU with secure mode. 740 5.5. Dual CPU, other bus 742 This configuration has two or more heterogeneous CPUs, each having 743 their own memory. There will be a communication channel between 744 them, but it will be used as a peripheral, not via shared memory. In 745 this case, each CPU will have to be responsible for its own firmware 746 upgrade. It is likely that one of the CPUs will be considered the 747 primary CPU, and will direct the other CPU to do the upgrade. This 748 configuration is commonly used to offload specific work to other 749 CPUs. Firmware dependencies are similar to the other solutions 750 above, sometimes allowing only one image to be upgraded, other times 751 requiring several to be upgraded atomically. Because the updates are 752 happening on multiple CPUs, upgrading the two images atomically is 753 challenging. 755 6. Manifests 757 In order for a firmware consumer to apply an update, it has to make 758 several decisions using manifest-provided information and data 759 available on the device itself. For more detailed information and a 760 longer list of information elements in the manifest consult the 761 information model specification [I-D.ietf-suit-information-model], 762 which offers justifications for each element, and the manifest, see 763 [I-D.ietf-suit-manifest], for details about how this information is 764 included in the manifest. 766 Table 1 provides examples of decisions to be made. 768 +----------------------------+--------------------------------------+ 769 | Decision | Information Elements | 770 +----------------------------+--------------------------------------+ 771 | Should I trust the author | Trust anchors and authorization | 772 | of the firmware? | policies on the device | 773 | | | 774 | Has the firmware been | Digital signature and MAC covering | 775 | corrupted? | the firmware image | 776 | | | 777 | Does the firmware update | Conditions with Vendor ID, Class ID | 778 | apply to this device? | and Device ID | 779 | | | 780 | Is the update older than | Sequence number in the manifest (1) | 781 | the active firmware? | | 782 | | | 783 | When should the device | Wait directive | 784 | apply the update? | | 785 | | | 786 | How should the device | Manifest commands | 787 | apply the update? | | 788 | | | 789 | What kind of firmware | Unpack algorithms to interpret a | 790 | binary is it? | format. | 791 | | | 792 | Where should the update be | Dependencies on other manifests and | 793 | obtained? | firmware image URI in Manifest | 794 | | | 795 | Where should the firmware | Storage Location and Component | 796 | be stored? | Identifier | 797 +----------------------------+--------------------------------------+ 799 Table 1: Firmware Update Decisions. 801 (1): A device presented with an old, but valid manifest and firmware 802 must not be tricked into installing such firmware since a 803 vulnerability in the old firmware image may allow an attacker to gain 804 control of the device. 806 Keeping the code size and complexity of a manifest parsers small is 807 important for constrained IoT devices. Since the manifest parsing 808 code may also be used by the bootloader it is part of the trusted 809 computing base. 811 A manifest may not only be used to protect firmware images but also 812 configuration data such as network credentials or personalization 813 data related to firmware or software. Personalization data 814 demonstrates the need for mutually-distrustful delivery of two or 815 more images into a device. Personalization data is used with Trusted 816 Execution Environments (TEEs), which benefit from a protocol for 817 managing the lifecycle of trusted applications (TAs) running inside a 818 TEE. TEEs may obtain TAs from different authors and those TAs may 819 require personalization data, such as payment information, to be 820 securely conveyed to the TEE. The TA's author does not want to 821 expose the TA to the user, and the user does not want to expose the 822 payment information to the TA's author. 824 7. Securing Firmware Updates 826 Using firmware updates to fix vulnerabilities in devices is important 827 but securing this update mechanism is equally important since 828 security problems are exacerbated by the update mechanism: update is 829 essentially authorized remote code execution, so any security 830 problems in the update process expose that remote code execution 831 system. Failure to secure the firmware update process will help 832 attackers to take control over devices. 834 End-to-end security mechanisms are used to protect the firmware image 835 and the manifest. The following assumptions are made to allow the 836 firmware consumer to verify the received firmware image and manifest 837 before updating software: 839 - Authentication ensures that the device can cryptographically 840 identify the author(s) creating firmware images and manifests. 841 Authenticated identities may be used as input to the authorization 842 process. Not all entities creating and signing manifests have the 843 same permissions. A device needs to determine whether the 844 requested action is indeed covered by the permission of the party 845 that signed the manifest. Informing the device about the 846 permissions of the different parties also happens in an out-of- 847 band fashion and is also a duty of the Trust Provisioning 848 Authority. 850 - Integrity protection ensures that no third party can modify the 851 manifest or the firmware image. To accept an update, a device 852 needs to verify the signature covering the manifest. There may be 853 one or multiple manifests that need to be validated, potentially 854 signed by different parties. The device needs to be in possession 855 of the trust anchors to verify those signatures. Installing trust 856 anchors to devices via the Trust Provisioning Authority happens in 857 an out-of-band fashion prior to the firmware update process. 859 - For confidentiality protection of the firmware image, it must be 860 done in such a way that the intended firmware consumer(s), other 861 authorized parties, and no one else can decrypt it. The 862 information that is encrypted individually for each device/ 863 recipient must maintain friendliness to Content Distribution 864 Networks, bulk storage, and broadcast protocols. For 865 confidentiality protection of firmware images the author needs to 866 be in possession of the certificate/public key or a pre-shared key 867 of a device. The use of confidentiality protection of firmware 868 images is optional. 870 A manifest specification must support different cryptographic 871 algorithms and algorithm extensibility. Moreover, since RSA- and 872 ECC-based signature schemes may become vulnerable to quantum- 873 accelerated key extraction in the future, unchangeable bootloader 874 code in ROM is recommended to use post-quantum secure signature 875 schemes such as hash-based signatures [RFC8778]. A bootloader author 876 must carefully consider the service lifetime of their product and the 877 time horizon for quantum-accelerated key extraction. The worst-case 878 estimate, at time of writing, for the time horizon to key extraction 879 with quantum acceleration is approximately 2030, based on current 880 research [quantum-factorization]. 882 When a device obtains a monolithic firmware image from a single 883 author without any additional approval steps then the authorization 884 flow is relatively simple. There are, however, other cases where 885 more complex policy decisions need to be made before updating a 886 device. 888 In this architecture the authorization policy is separated from the 889 underlying communication architecture. This is accomplished by 890 separating the entities from their permissions. For example, an 891 author may not have the authority to install a firmware image on a 892 device in critical infrastructure without the authorization of a 893 device operator. In this case, the device may be programmed to 894 reject firmware updates unless they are signed both by the firmware 895 author and by the device operator. 897 Alternatively, a device may trust precisely one entity, which does 898 all permission management and coordination. This entity allows the 899 device to offload complex permissions calculations for the device. 901 8. Example 903 Figure 2 illustrates an example message flow for distributing a 904 firmware image to a device. The firmware and manifest are stored on 905 the same firmware server and distributed in a detached manner. 907 +--------+ +-----------------+ +-----------------------------+ 908 | | | Firmware Server | | IoT Device | 909 | Author | | Status Tracker | | +------------+ +----------+ | 910 +--------+ | Server | | | Firmware | |Bootloader| | 911 | +-----------------+ | | Consumer | | | | 912 | | | +------------+ +----------+ | 913 | | | | | | 914 | | | +-----------------------+ | 915 | Create Firmware | | | Status Tracker Client | | 916 |--------------+ | | +-----------------------+ | 917 | | | `'''''''''''''''''''''''''''' 918 |<-------------+ | | | | 919 | | | | | 920 | Upload Firmware | | | | 921 |------------------>| | | | 922 | | | | | 923 | Create Manifest | | | | 924 |---------------+ | | | | 925 | | | | | | 926 |<--------------+ | | | | 927 | | | | | 928 | Sign Manifest | | | | 929 |-------------+ | | | | 930 | | | | | | 931 |<------------+ | | | | 932 | | | | | 933 | Upload Manifest | | | | 934 |------------------>| Notification of | | | 935 | | new firmware image | | | 936 | |----------------------------->| | 937 | | | | | 938 | | |Initiate| | 939 | | | Update | | 940 | | |<-------| | 941 | | | | | 942 | | Query Manifest | | | 943 | |<--------------------| . | 944 | | | . | 945 | | Send Manifest | . | 946 | |-------------------->| . | 947 | | | Validate | 948 | | | Manifest | 949 | | |--------+ | 950 | | | | | 951 | | |<-------+ | 952 | | | . | 953 | | Request Firmware | . | 954 | |<--------------------| . | 955 | | | . | 956 | | Send Firmware | . | 957 | |-------------------->| . | 958 | | | Verify . | 959 | | | Firmware | 960 | | |--------+ | 961 | | | | | 962 | | |<-------+ | 963 | | | . | 964 | | | Store . | 965 | | | Firmware | 966 | | |--------+ | 967 | | | | | 968 | | |<-------+ | 969 | | | . | 970 | | | . | 971 | | | . | 972 | | | | | 973 | | | Update | | 974 | | |Complete| | 975 | | |------->| | 976 | | | | 977 | | Firmware Update Completed | | 978 | |<-----------------------------| | 979 | | | | 980 | | Reboot | | 981 | |----------------------------->| | 982 | | | | | 983 | | | | | 984 | | |Reboot | 985 | | | |------>| 986 | | | | | 987 | | | . | 988 | | +---+----------------+--+ 989 | | S| | | | 990 | | E| | Verify | | 991 | | C| | Firmware | | 992 | | U| | +--------------| | 993 | | R| | | | | 994 | | E| | +------------->| | 995 | | | | | | 996 | | B| | Activate new | | 997 | | O| | Firmware | | 998 | | O| | +--------------| | 999 | | T| | | | | 1000 | | | | +------------->| | 1001 | | P| | | | 1002 | | R| | Boot new | | 1003 | | O| | Firmware | | 1004 | | C| | +--------------| | 1005 | | E| | | | | 1006 | | S| | +------------->| | 1007 | | S| | | | 1008 | | +---+----------------+--+ 1009 | | | . | 1010 | | | | | 1011 | | . | | 1012 | | Device running new firmware | | 1013 | |<-----------------------------| | 1014 | | . | | 1015 | | | | 1017 Figure 2: First Example Flow for a Firmware Update. 1019 Figure 3 shows an exchange that starts with the status tracker 1020 querying the device for its current firmware version. Later, a new 1021 firmware version becomes available and since this device is running 1022 an older version the status tracker server interacts with the device 1023 to initiate an update. 1025 The manifest and the firmware are stored on different servers in this 1026 example. When the device processes the manifest it learns where to 1027 download the new firmware version. The firmware consumer downloads 1028 the firmware image with the newer version X.Y.Z after successful 1029 validation of the manifest. Subsequently, a reboot is initiated and 1030 the secure boot process starts. Finally, the device reports the 1031 successful boot of the new firmware version. 1033 +---------+ +-----------------+ +-----------------------------+ 1034 | Status | | Firmware Server | | +------------+ +----------+ | 1035 | Tracker | | Status Tracker | | | Firmware | |Bootloader| | 1036 | Server | | Server | | | Consumer | | | | 1037 +---------+ +-----------------+ | | +Status | +----------+ | 1038 | | | | Tracker | | | 1039 | | | | Client | | | 1040 | | | +------------+ | | 1041 | | | | IoT Device | | 1042 | | `'''''''''''''''''''''''''''' 1043 | | | | 1044 | Query Firmware Version | | 1045 |------------------------------------->| | 1046 | Firmware Version A.B.C | | 1047 |<-------------------------------------| | 1048 | | | | 1049 | <> | | 1050 | | | | 1051 _,...._ _,...._ | | 1052 ,' `. ,' `. | | 1053 | New | | New | | | 1054 \ Manifest / \ Firmware / | | 1055 `.._ _,,' `.._ _,,' | | 1056 `'' `'' | | 1057 | Push manifest | | 1058 |----------------+-------------------->| | 1059 | | | | 1060 | ' | ' 1061 | | | Validate | 1062 | | | Manifest | 1063 | | |---------+ | 1064 | | | | | 1065 | | |<--------+ | 1066 | | Request firmware | | 1067 | | X.Y.Z | | 1068 | |<--------------------| | 1069 | | | | 1070 | | Firmware X.Y.Z | | 1071 | |-------------------->| | 1072 | | | | 1073 | | | Verify | 1074 | | | Firmware | 1075 | | |--------------+ | 1076 | | | | | 1077 | | |<-------------+ | 1078 | | | | 1079 | | | Store | 1080 | | | Firmware | 1081 | | |-------------+ | 1082 | | | | | 1083 | | |<------------+ | 1084 | | | | 1085 | | | | 1086 | | | Trigger Reboot | 1087 | | |--------------->| 1088 | | | | 1089 | | | | 1090 | | | __..-------..._' 1091 | | ,-' `-. 1092 | | | Secure Boot | 1093 | | `-. _/ 1094 | | |`--..._____,,.,-' 1095 | | | | 1096 | Device running firmware X.Y.Z | | 1097 |<-------------------------------------| | 1098 | | | | 1099 | | | | 1101 Figure 3: Second Example Flow for a Firmware Update. 1103 9. IANA Considerations 1105 This document does not require any actions by IANA. 1107 10. Security Considerations 1109 This document describes terminology, requirements and an architecture 1110 for firmware updates of IoT devices. The content of the document is 1111 thereby focused on improving security of IoT devices via firmware 1112 update mechanisms and informs the standardization of a manifest 1113 format. 1115 An in-depth examination of the security considerations of the 1116 architecture is presented in [I-D.ietf-suit-information-model]. 1118 11. Acknowledgements 1120 We would like to thank the following persons for their feedback: 1122 - Geraint Luff 1124 - Amyas Phillips 1126 - Dan Ros 1128 - Thomas Eichinger 1130 - Michael Richardson 1132 - Emmanuel Baccelli 1134 - Ned Smith 1136 - Jim Schaad 1138 - Carsten Bormann 1140 - Cullen Jennings 1142 - Olaf Bergmann 1144 - Suhas Nandakumar 1146 - Phillip Hallam-Baker 1148 - Marti Bolivar 1150 - Andrzej Puzdrowski 1151 - Markus Gueller 1153 - Henk Birkholz 1155 - Jintao Zhu 1157 - Takeshi Takahashi 1159 - Jacob Beningo 1161 - Kathleen Moriarty 1163 - Bob Briscoe 1165 - Roman Danyliw 1167 - Brian Carpenter 1169 - Theresa Enghardt 1171 - Rich Salz 1173 We would also like to thank the WG chairs, Russ Housley, David 1174 Waltermire, Dave Thaler for their support and their reviews. 1176 12. Informative References 1178 [I-D.ietf-rats-architecture] 1179 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1180 W. Pan, "Remote Attestation Procedures Architecture", 1181 draft-ietf-rats-architecture-06 (work in progress), 1182 September 2020. 1184 [I-D.ietf-suit-information-model] 1185 Moran, B., Tschofenig, H., and H. Birkholz, "An 1186 Information Model for Firmware Updates in IoT Devices", 1187 draft-ietf-suit-information-model-07 (work in progress), 1188 June 2020. 1190 [I-D.ietf-suit-manifest] 1191 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1192 "A Concise Binary Object Representation (CBOR)-based 1193 Serialization Format for the Software Updates for Internet 1194 of Things (SUIT) Manifest", draft-ietf-suit-manifest-09 1195 (work in progress), July 2020. 1197 [I-D.ietf-teep-architecture] 1198 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1199 "Trusted Execution Environment Provisioning (TEEP) 1200 Architecture", draft-ietf-teep-architecture-12 (work in 1201 progress), July 2020. 1203 [LwM2M] OMA, ., "Lightweight Machine to Machine Technical 1204 Specification, Version 1.0.2", February 2018, 1205 . 1209 [quantum-factorization] 1210 Department of Computer Science, Purdue University, ., 1211 Quantum Computing Institute, Oak Ridge National 1212 Laboratory, ., Quantum Computing Institute, Oak Ridge 1213 National Laboratory, ., Quantum Computing Institute, Oak 1214 Ridge National Laboratory, ., and . Department of 1215 Chemistry, Physics and Birck Nanotechnology Center, Purdue 1216 University, "Quantum Annealing for Prime Factorization", 1217 n.d., 1218 . 1220 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1221 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1222 2010, . 1224 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1225 Constrained-Node Networks", RFC 7228, 1226 DOI 10.17487/RFC7228, May 2014, 1227 . 1229 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1230 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1231 . 1233 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 1234 of Things Software Update (IoTSU) Workshop 2016", 1235 RFC 8240, DOI 10.17487/RFC8240, September 2017, 1236 . 1238 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1239 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1240 May 2018, . 1242 [RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature 1243 Algorithm with CBOR Object Signing and Encryption (COSE)", 1244 RFC 8778, DOI 10.17487/RFC8778, April 2020, 1245 . 1247 Authors' Addresses 1249 Brendan Moran 1250 Arm Limited 1252 EMail: Brendan.Moran@arm.com 1254 Hannes Tschofenig 1255 Arm Limited 1257 EMail: hannes.tschofenig@arm.com 1259 David Brown 1260 Linaro 1262 EMail: david.brown@linaro.org 1264 Milosch Meriac 1265 Consultant 1267 EMail: milosch@meriac.com