idnits 2.17.1 draft-ietf-suit-architecture-14.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 21, 2020) is 1284 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-06 == Outdated reference: A later version (-13) exists of draft-ietf-suit-information-model-07 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-09 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-12 Summary: 0 errors (**), 0 flaws (~~), 5 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 24, 2021 D. Brown 6 Linaro 7 M. Meriac 8 Consultant 9 October 21, 2020 11 A Firmware Update Architecture for Internet of Things 12 draft-ietf-suit-architecture-14 14 Abstract 16 Vulnerabilities in 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 24, 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 . . . . . . . . . . . . . . . . . . . . . . . 27 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. Conversely, IoT devices are expected to account for 107 user preferences and consent when scheduling updates. Automatic 108 updates that do not require human intervention are key to a scalable 109 solution for fixing software vulnerabilities. 111 Firmware updates are not only done to fix bugs, but they can also add 112 new functionality, and re-configure the device to work in new 113 environments or to behave differently in an already deployed context. 115 The firmware update process has to ensure that 117 - The firmware image is authenticated and integrity protected. 118 Attempts to flash a maliciously modified firmware image or an 119 image from an unknown, untrusted source must be prevented. In 120 examples this document uses asymmetric cryptography because it is 121 the preferred approach by many IoT deployments. The use of 122 symmetric credentials is also supported and can be used by very 123 constrained IoT devices. 125 - The firmware image can be confidentiality protected so that 126 attempts by an adversary to recover the plaintext binary can be 127 mitigated or at least made more difficult. Obtaining the firmware 128 is often one of the first steps to mount an attack since it gives 129 the adversary valuable insights into the software libraries used, 130 configuration settings and generic functionality. Even though 131 reverse engineering the binary can be a tedious process modern 132 reverse engineering frameworks have made this task a lot easier. 134 While the standardization work has been informed by and optimized for 135 firmware update use cases of Class 1 devices (according to the device 136 class definitions in RFC 7228 [RFC7228]) devices, there is nothing in 137 the architecture that restricts its use to only these constrained IoT 138 devices. Moreover, this architecture is not limited to managing 139 firmware and software updates, but can also be applied to managing 140 the delivery of arbitrary data, such as configuration information and 141 keys. Unlike higher end devices, like laptops and desktop PCs, many 142 IoT devices do not have user interfaces and support for unattended 143 updates is, therefore, essential for the design of a practical 144 solution. Constrained IoT devices often use a software engineering 145 model where a developer is responsible for creating and compiling all 146 software running on the device into a single, monolithic firmware 147 image. On higher end devices application software is, on the other 148 hand, often downloaded separately and even obtained from developers 149 different to the developers of the lower level software. The details 150 for how to obtain those application layer software binaries then 151 depends heavily on the platform, programming language used and the 152 sandbox in which the software is executed. 154 While the IETF standardization work has been focused on the manifest 155 format, a fully interoperable solution needs more than a standardized 156 manifest. For example, protocols for transferring firmware images 157 and manifests to the device need to be available as well as the 158 status tracker functionality. Devices also require a mechanism to 159 discover the status tracker(s) and/or firmware servers, for example 160 using pre-configured hostnames or [RFC6763] DNS-SD. These building 161 blocks have been developed by various organizations under the 162 umbrella of an IoT device management solution. The LwM2M protocol is 163 one IoT device management protocol. 165 There are, however, several areas that (partially) fall outside the 166 scope of the IETF and other standards organizations but need to be 167 considered by firmware authors, as well as device and network 168 operators. Here are some of them, as highlighted during the IOTSU 169 workshop: 171 - Installing firmware updates in a robust fashion so that the update 172 does not break the device functionality of the environment this 173 device operates in. This requires proper testing and offering 174 recovery strategies when a firmware update is unsuccessful. 176 - Making firmware updates available in a timely fashion considering 177 the complexity of the decision making process for updating 178 devices, potential re-certification requirements, the length of a 179 supply chain an update needs to go through before it reaches the 180 end customer, and the need for user consent to install updates. 182 - Ensuring an energy efficient design of a battery-powered IoT 183 device because a firmware update, particularly radio communication 184 and writing the firmware image to flash, is an energy-intensive 185 task for a device. 187 - Creating incentives for device operators to use a firmware update 188 mechanism and to demand the integration of it from IoT device 189 vendors. 191 - Ensuring that firmware updates addressing critical flaws can be 192 obtained even after a product is discontinued or a vendor goes out 193 of business. 195 This document starts with a terminology followed by the description 196 of the architecture. We then explain the bootloader and how it 197 integrates with the firmware update mechanism. Subsequently, we 198 offer a categorization of IoT devices in terms of their hardware 199 capabilities relevant for firmware updates. Next, we talk about the 200 manifest structure and how to use it to secure firmware updates. We 201 conclude with a more detailed example. 203 2. Conventions and Terminology 205 2.1. Terms 207 This document uses the following terms: 209 - Firmware Image: The firmware image, or image, is a binary that may 210 contain the complete software of a device or a subset of it. The 211 firmware image may consist of multiple images, if the device 212 contains more than one microcontroller. Often it is also a 213 compressed archive that contains code, configuration data, and 214 even the entire file system. The image may consist of a 215 differential update for performance reasons. 217 The terms, firmware image, firmware, and image, are used in this 218 document and are interchangeable. We use the term application 219 firmware image to differentiate it from a firmware image that 220 contains the bootloader. An application firmware image, as the 221 name indicates, contains the application program often including 222 all the necessary code to run it (such as protocol stacks, and 223 embedded operating system). 225 - Manifest: The manifest contains meta-data about the firmware 226 image. The manifest is protected against modification and 227 provides information about the author. 229 - Microcontroller (MCU for microcontroller unit): An MCU is a 230 compact integrated circuit designed for use in embedded systems. 231 A typical microcontroller includes a processor, memory (RAM and 232 flash), input/output (I/O) ports and other features connected via 233 some bus on a single chip. The term 'system on chip (SoC)' is 234 often used interchangeably with MCU, but MCU tends to imply more 235 limited peripheral functions. 237 - Rich Execution Environment (REE): An environment that is provided 238 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 239 potentially in conjunction with other supporting operating systems 240 and hypervisors; it is outside of the TEE. This environment and 241 applications running on it are considered un-trusted. 243 - Software: Similar to firmware, but typically dynamically loaded by 244 an Operating System. Used interchangeably with firmware in this 245 document. 247 - System on Chip (SoC): An SoC is an integrated circuit that 248 contains all components of a computer, such as CPU, memory, input/ 249 output ports, secondary storage, a bus to connect the components, 250 and other hardware blocks of logic. 252 - Trust Anchor: A trust anchor, as defined in [RFC6024], represents 253 an authoritative entity via a public key and associated data. The 254 public key is used to verify digital signatures, and the 255 associated data is used to constrain the types of information for 256 which the trust anchor is authoritative." 258 - Trust Anchor Store: A trust anchor store, as defined in [RFC6024], 259 is a set of one or more trust anchors stored in a device. A 260 device may have more than one trust anchor store, each of which 261 may be used by one or more applications. A trust anchor store 262 must resist modification against unauthorized insertion, deletion, 263 and modification. 265 - Trusted Applications (TAs): An application component that runs in 266 a TEE. 268 - Trusted Execution Environments (TEEs): An execution environment 269 that runs alongside of, but is isolated from, an REE. For more 270 information about TEEs see [I-D.ietf-teep-architecture]. 272 2.2. Stakeholders 274 The following stakeholders are used in this document: 276 - Author: The author is the entity that creates the firmware image. 277 There may be multiple authors involved in producing firmware 278 running on an IoT device. Section 5 talks about those IoT device 279 deployment cases. 281 - Device Operator: The device operator is responsible for the day- 282 to-day operation of a fleet of IoT devices. Customers of IoT 283 devices, as the owners of IoT devices - such as enterprise 284 customers or end users, interact with their IoT devices indirectly 285 through the device operator via web or smart phone apps. 287 - Network Operator: The network operator is responsible for the 288 operation of a network to which IoT devices connect. 290 - Trust Provisioning Authority (TPA): The TPA distributes trust 291 anchors and authorization policies to devices and various 292 stakeholders. The TPA may also delegate rights to stakeholders. 293 Typically, the Original Equipment Manufacturer (OEM) or Original 294 Design Manufacturer (ODM) will act as a TPA, however complex 295 supply chains may require a different design. In some cases, the 296 TPA may decide to remain in full control over the firmware update 297 process of their products. 299 - User: The end-user of a device. The user may interact with 300 devices via web or smart phone apps, as well as through direct 301 user interfaces. 303 2.3. Functions 305 - (IoT) Device: A device refers to the entire IoT product, which 306 consists of one or many MCUs, sensors and/or actuators. Many IoT 307 devices sold today contain multiple MCUs and therefore a single 308 device may need to obtain more than one firmware image and 309 manifest to successfully perform an update. 311 - Status Tracker: The status tracker has a client and a server 312 component and performs three tasks: 1) It communicates the 313 availability of a new firmware version. This information will 314 flow from the server to the client. 315 2) It conveys information about software and hardware 316 characteristics of the device. The information flow is from the 317 client to the server. 318 3) It can remotely trigger the firmware update process. The 319 information flow is from the server to the client. 321 For example, a device operator may want to read the installed 322 firmware version number running on the device and information 323 about available flash memory. Once an update has been triggered, 324 the device operator may want to obtain information about the state 325 of the firmware update. If errors occurred, the device operator 326 may want to troubleshoot problems by first obtaining diagnostic 327 information (typically using a device management protocol). 329 We make no assumptions about where the server-side component is 330 deployed. The deployment of status trackers is flexible and may 331 be found at 332 cloud-based servers, on-premise servers, or may be embedded in 333 edge computing devices. A status tracker server component may 334 even be deployed on an IoT device. For example, if the IoT device 335 contains multiple MCUs, then the main MCU may act as a status 336 tracker towards the other MCUs. Such deployment is useful when 337 updates have to be synchronized across MCUs. 339 The status tracker may be operated by any suitable stakeholder; 340 typically the Author, Device Operator, or Network Operator. 342 - Firmware Consumer: The firmware consumer is the recipient of the 343 firmware image and the manifest. It is responsible for parsing 344 and verifying the received manifest and for storing the obtained 345 firmware image. The firmware consumer plays the role of the 346 update component on the IoT device typically running in the 347 application firmware. It interacts with the firmware server and 348 with the status tracker client (locally). 350 - Firmware Server: The firmware server stores firmware images and 351 manifests and distributes them to IoT devices. Some deployments 352 may require a store-and-forward concept, which requires storing 353 the firmware images/manifests on more than one entity before 354 they reach the device. There is typically some interaction 355 between the firmware server and the status tracker and these two 356 entities are often physically separated on different devices for 357 scalability reasons. 359 - Bootloader: A bootloader is a piece of software that is executed 360 once a microcontroller has been reset. It is responsible for 361 deciding what code to execute. 363 3. Architecture 365 More devices today than ever before are connected to the Internet, 366 which drives the need for firmware updates to be provided over the 367 Internet rather than through traditional interfaces, such as USB or 368 RS-232. Sending updates over the Internet requires the device to 369 fetch the new firmware image as well as the manifest. 371 Hence, the following components are necessary on a device for a 372 firmware update solution: 374 - the Internet protocol stack for firmware downloads. Because 375 firmware images are often multiple kilobytes, sometimes exceeding 376 one hundred kilobytes, in size for low end IoT devices and even 377 several megabytes large for IoT devices running full-fledged 378 operating systems like Linux, the protocol mechanism for 379 retrieving these images needs to offer features like congestion 380 control, flow control, fragmentation and reassembly, and 381 mechanisms to resume interrupted or corrupted transfers. 383 - the capability to write the received firmware image to persistent 384 storage (most likely flash memory). 386 - a manifest parser with code to verify a digital signature or a 387 message authentication code. 389 - the ability to unpack, to decompress and/or to decrypt the 390 received firmware image. 392 - a status tracker. 394 The features listed above are most likely offered by code in the 395 application firmware image running on the device rather than by the 396 bootloader itself. Note that cryptographic algorithms will likely 397 run in a trusted execution environment, on a separate MCU, in a 398 hardware security module, or in a secure element rather than in the 399 same context with the application code. 401 Figure 1 shows the architecture where a firmware image is created by 402 an author, and made available to a firmware server. For security 403 reasons, the author will not have the permissions to upload firmware 404 images to the firmware server and to initiate an update him- or 405 herself. Instead, authors will make firmware images available to the 406 device operators. Note that there may be a longer supply chain 407 involved to pass software updates from the author all the way to the 408 party that can then finally make a decision to deploy it with IoT 409 devices. 411 As a first step in the firmware update process, the status tracker 412 client needs to be made aware of the availability of a new firmware 413 update by the status tracker server. This can be accomplished via 414 polling (client-initiated), push notifications (server-initiated), or 415 more complex mechanisms (such as a hybrid approach): 417 - Client-initiated updates take the form of a status tracker client 418 proactively checking (polling) for updates. 420 - With Server-initiated updates the server-side component of the 421 status tracker learns about a new firmware version and determines 422 which devices qualify for a firmware update. Once the relevant 423 devices have been selected, the status tracker informs these 424 devices and the firmware consumers obtain those images and 425 manifests. Server-initiated updates are important because they 426 allow a quick response time. Note that the client-side status 427 tracker needs to be reachable by the server-side component. This 428 may require devices to keep reachability information on the 429 server-side up-to-date and state at NATs and stateful packet 430 filtering firewalls alive. 432 - Using a hybrid approach the server-side of the status tracker 433 pushes notifications of availability of an update to the client 434 side and requests the firmware consumer to pull the manifest and 435 the firmware image from the firmware server. 437 Once the device operator triggers update via the status tracker, it 438 will keep track of the update process on the device. This allows the 439 device operator to know what devices have received an update and 440 which of them are still pending an update. 442 Firmware images can be conveyed to devices in a variety of ways, 443 including USB, UART, WiFi, BLE, low-power WAN technologies, mesh 444 networks and many more. At the application layer a variety of 445 protocols are also available: MQTT, CoAP, and HTTP are the most 446 popular application layer protocols used by IoT devices. This 447 architecture does not make assumptions about how the firmware images 448 are distributed to the devices and therefore aims to support all 449 these technologies. 451 In some cases it may be desirable to distribute firmware images using 452 a multicast or broadcast protocol. This architecture does not make 453 recommendations for any such protocol. However, given that broadcast 454 may be desirable for some networks, updates must cause the least 455 disruption possible both in metadata and firmware transmission. For 456 an update to be broadcast friendly, it cannot rely on link layer, 457 network layer, or transport layer security. A solution has to rely 458 on security protection applied to the manifest and firmware image 459 instead. In addition, the same manifest must be deliverable to many 460 devices, both those to which it applies and those to which it does 461 not, without a chance that the wrong device will accept the update. 462 Considerations that apply to network broadcasts apply equally to the 463 use of third-party content distribution networks for payload 464 distribution. 466 +----------+ 467 | | 468 | Author | 469 | | 470 +----------+ 471 Firmware + Manifest | 472 +----------------------------------+ | Firmware + 473 | | | Manifest 474 | ---+------- | 475 | ---- | --|- 476 | //+----------+ | \\ 477 -+-- // | | | \ 478 ----/ | ---- |/ | Firmware |<-+ | \ 479 // | \\ | | Server | | | \ 480 / | \ / | | + + \ 481 / | \ / +----------+ \ / | 482 / +--------+--------+ \ / | | 483 / | v | \ / v | 484 | | +------------+ | | | +----------------+ | 485 | | | Firmware | | | Device | | 486 | | | Consumer | | | | | Management | | 487 | | +------------+ | | | | | | 488 | | +------------+ | | | | +--------+ | | 489 | | | Status |<-+--------------------+-> | | | | 490 | | | Tracker | | | | | | Status | | | 491 | | | Client | | | | | | Tracker| | | 492 | | +------------+ | | | | | Server | | | 493 | | Device | | | | +--------+ | | 494 | +-----------------+ | \ | | / 495 \ / \ +----------------+ / 496 \ Network / \ / 497 \ Operator / \ Device Operator / 498 \\ // \ \ // 499 ---- ---- ---- ---- 500 ----- ----------- 502 Figure 1: Architecture. 504 Firmware images and manifests may be conveyed as a bundle or 505 detached. The manifest must support both approaches. 507 For distribution as a bundle, the firmware image is embedded into the 508 manifest. This is a useful approach for deployments where devices 509 are not connected to the Internet and cannot contact a dedicated 510 firmware server for the firmware download. It is also applicable 511 when the firmware update happens via a USB sticks or short range 512 radio technologies (such as Bluetooth Smart). 514 Alternatively, the manifest is distributed detached from the firmware 515 image. Using this approach, the firmware consumer is presented with 516 the manifest first and then needs to obtain one or more firmware 517 images as dictated in the manifest. 519 The pre-authorisation step involves verifying whether the entity 520 signing the manifest is indeed authorized to perform an update. The 521 firmware consumer must also determine whether it should fetch and 522 process a firmware image, which is referenced in a manifest. 524 A dependency resolution phase is needed when more than one component 525 can be updated or when a differential update is used. The necessary 526 dependencies must be available prior to installation. 528 The download step is the process of acquiring a local copy of the 529 firmware image. When the download is client-initiated, this means 530 that the firmware consumer chooses when a download occurs and 531 initiates the download process. When a download is server-initiated, 532 this means that the status tracker tells the device when to download 533 or that it initiates the transfer directly to the firmware consumer. 534 For example, a download from an HTTP/1.1-based firmware server is 535 client-initiated. Pushing a manifest and firmware image to the 536 Package resource of the LwM2M Firmware Update object [LwM2M] is 537 server-initiated update. 539 If the firmware consumer has downloaded a new firmware image and is 540 ready to install it, to initiate the installation, it may - either 541 need to wait for a trigger from the status tracker, - or trigger the 542 update automatically, - or go through a more complex decision making 543 process to determine the appropriate timing for an update. Sometimes 544 the final decision may require confirmation of the user of the device 545 for safety reasons. 547 Installation is the act of processing the payload into a format that 548 the IoT device can recognize and the bootloader is responsible for 549 then booting from the newly installed firmware image. This process 550 is different when a bootloader is not involved. For example, when an 551 application is updated in a full-featured operating system, the 552 updater may halt and restart the application in isolation. Devices 553 must not fail when a disruption occurs during the update process. 554 For example, a power failure or network disruption during the update 555 process must not cause the device to fail. 557 4. Invoking the Firmware 559 Section 3 describes the steps for getting the firmware image and the 560 manifest from the author to the firmware consumer on the IoT device. 561 Once the firmware consumer has retrieved and successfully processed 562 the manifest and the firmware image it needs to invoke the new 563 firmware image. This is managed in many different ways, depending on 564 the type of device, but it typically involves halting the current 565 version of the firmware, handing control over to a firmware with a 566 higher privilege/trust level (the firmware verifier) verifying the 567 new firmware's authenticity & integrity, and then invoking it. 569 In an execute-in-place microcontroller, this is often done by 570 rebooting into a bootloader (simultaneously halting the application & 571 handing over to the higher privilege level) then executing a secure 572 boot process (verifying and invoking the new image). 574 In a rich OS, this may be done by halting one or more processes, then 575 invoking new applications. In some OSs, this implicitly involves the 576 kernel verifying the code signatures on the new applications. 578 The invocation process is security sensitive. An attacker will 579 typically try to retrieve a firmware image from the device for 580 reverse engineering or will try to get the firmware verifier to 581 execute an attacker-modified firmware image. The firmware verifier 582 will therefore have to perform security checks on the firmware image 583 before it can be invoked. These security checks by the firmware 584 verifier happen in addition to the security checks that took place 585 when the firmware image and the manifest were downloaded by the 586 firmware consumer. 588 The overlap between the firmware consumer and the firmware verifier 589 functionality comes in two forms, namely 591 - A firmware verifier must verify the firmware image it boots as 592 part of the secure boot process. Doing so requires meta-data to 593 be stored alongside the firmware image so that the firmware 594 verifier can cryptographically verify the firmware image before 595 booting it to ensure it has not been tampered with or replaced. 596 This meta-data used by the firmware verifier may well be the same 597 manifest obtained with the firmware image during the update 598 process. 600 - An IoT device needs a recovery strategy in case the firmware 601 update / invocation process fails. The recovery strategy may 602 include storing two or more application firmware images on the 603 device or offering the ability to invoke a recovery image to 604 perform the firmware update process again using firmware updates 605 over serial, USB or even wireless connectivity like Bluetooth 606 Smart. In the latter case the firmware consumer functionality is 607 contained in the recovery image and requires the necessary 608 functionality for executing the firmware update process, including 609 manifest parsing. 611 While this document assumes that the firmware verifier itself is 612 distinct from the role of the firmware consumer and therefore does 613 not manage the firmware update process, this is not a requirement and 614 these roles may be combined in practice. 616 Using a bootloader as the firmware verifier requires some special 617 considerations, particularly when the bootloader implements the 618 robustness requirements identified by the IOTSU workshop [RFC8240]. 620 4.1. The Bootloader 622 In most cases the MCU must restart in order to hand over control to 623 the bootloader. Once the MCU has initiated a restart, the bootloader 624 determines whether a newly available firmware image should be 625 executed. If the bootloader concludes that the newly available 626 firmware image is invalid, a recovery strategy is necessary. There 627 are only two approaches for recovering from an invalid firmware: 628 either the bootloader must be able to select a different, valid 629 firmware, or it must be able to obtain a new, valid firmware. Both 630 of these approaches have implications for the architecture of the 631 update system. 633 Assuming the first approach, there are (at least) three firmware 634 images available on the device: 636 - First, the bootloader is also firmware. If a bootloader is 637 updatable then its firmware image is treated like any other 638 application firmware image. 640 - Second, the firmware image that has to be replaced is still 641 available on the device as a backup in case the freshly downloaded 642 firmware image does not boot or operate correctly. 644 - Third, there is the newly downloaded firmware image. 646 Therefore, the firmware consumer must know where to store the new 647 firmware. In some cases, this may be implicit, for example replacing 648 the least-recently-used firmware image. In other cases, the storage 649 location of the new firmware must be explicit, for example when a 650 device has one or more application firmware images and a recovery 651 image with limited functionality, sufficient only to perform an 652 update. 654 Since many low end IoT devices do not use position-independent code, 655 either the bootloader needs to copy the newly downloaded application 656 firmware image into the location of the old application firmware 657 image and vice versa or multiple versions of the firmware need to be 658 prepared for different locations. 660 In general, it is assumed that the bootloader itself, or a minimal 661 part of it, will not be updated since a failed update of the 662 bootloader poses a reliability risk. 664 For a bootloader to offer a secure boot functionality it needs to 665 implement the following functionality: 667 - The bootloader needs to fetch the manifest (or manifest-alike 668 headers) from nonvolatile storage and parse its contents for 669 subsequent cryptographic verification. 671 - Cryptographic libraries with hash functions, digital signatures 672 (for asymmetric crypto), message authentication codes (for 673 symmetric crypto) need to be accessible. 675 - The device needs to have a trust anchor store to verify the 676 digital signature. (Alternatively, access to a key store for use 677 with the message authentication code.) 679 - Ability to expose boot process-related data to the application 680 firmware (such as to the status tracker). This allows to share 681 information about the current firmware version, and the status of 682 the firmware update process and whether errors have occurred. 684 - Produce boot measurements as part of an attestation solution. See 685 [I-D.ietf-rats-architecture] for more information. (optional) 687 - Ability to decrypt firmware images, in case confidentiality 688 protection was applied. This requires a solution for key 689 management. (optional) 691 5. Types of IoT Devices 693 There are billions of MCUs used in devices today produced by a large 694 number of silicon manufacturers. While MCUs can vary significantly 695 in their characteristics, there are a number of similiaries allowing 696 us to categorize in groups. 698 The firmware update architecture, and the manifest format in 699 particular, needs to offer enough flexibility to cover these common 700 deployment cases. 702 5.1. Single MCU 704 The simplest, and currently most common, architecture consists of a 705 single MCU along with its own peripherals. These SoCs generally 706 contain some amount of flash memory for code and fixed data, as well 707 as RAM for working storage. A notable characteristic of these SoCs 708 is that the primary code is generally execute in place (XIP). Due to 709 the non-relocatable nature of the code, the firmware image needs to 710 be placed in a specific location in flash since the code cannot be 711 executed from an arbitrary location in flash. Hence, when the 712 firmware image is updated it is necessary to swap the old and the new 713 image. 715 5.2. Single CPU with Secure - Normal Mode Partitioning 717 Another configuration consists of a similar architecture to the 718 previous, with a single CPU. However, this CPU supports a security 719 partitioning scheme that allows memory (in addition to other things) 720 to be divided into secure and normal mode. There will generally be 721 two images, one for secure mode, and one for normal mode. In this 722 configuration, firmware upgrades will generally be done by the CPU in 723 secure mode, which is able to write to both areas of the flash 724 device. In addition, there are requirements to be able to update 725 either image independently, as well as to update them together 726 atomically, as specified in the associated manifests. 728 5.3. Symmetric Multiple CPUs 730 In more complex SoCs with symmetric multi-processing support, 731 advanced operating systems, such as Linux, are often used. These 732 SoCs frequently use an external storage medium, such as raw NAND 733 flash or eMMC. Due to the higher quantity of resources, these 734 devices are often capable of storing multiple copies of their 735 firmware images and selecting the most appropriate one to boot. Many 736 SoCs also support bootloaders that are capable of updating the 737 firmware image, however this is typically a last resort because it 738 requires the device to be held in the bootloader while the new 739 firmware is downloaded and installed, which results in down-time for 740 the device. Firmware updates in this class of device are typically 741 not done in-place. 743 5.4. Dual CPU, shared memory 745 This configuration has two or more heterogeneous CPUs in a single SoC 746 that share memory (flash and RAM). Generally, there will be a 747 mechanism to prevent one CPU from unintentionally accessing memory 748 currently allocated to the other. Upgrades in this case will 749 typically be done by one of the CPUs, and is similar to the single 750 CPU with secure mode. 752 5.5. Dual CPU, other bus 754 This configuration has two or more heterogeneous CPUs, each having 755 their own memory. There will be a communication channel between 756 them, but it will be used as a peripheral, not via shared memory. In 757 this case, each CPU will have to be responsible for its own firmware 758 upgrade. It is likely that one of the CPUs will be considered the 759 primary CPU, and will direct the other CPU to do the upgrade. This 760 configuration is commonly used to offload specific work to other 761 CPUs. Firmware dependencies are similar to the other solutions 762 above, sometimes allowing only one image to be upgraded, other times 763 requiring several to be upgraded atomically. Because the updates are 764 happening on multiple CPUs, upgrading the two images atomically is 765 challenging. 767 6. Manifests 769 In order for a firmware consumer to apply an update, it has to make 770 several decisions using manifest-provided information and data 771 available on the device itself. For more detailed information and a 772 longer list of information elements in the manifest consult the 773 information model specification [I-D.ietf-suit-information-model], 774 which offers justifications for each element, and the manifest, see 775 [I-D.ietf-suit-manifest], for details about how this information is 776 included in the manifest. 778 Table 1 provides examples of decisions to be made. 780 +----------------------------+--------------------------------------+ 781 | Decision | Information Elements | 782 +----------------------------+--------------------------------------+ 783 | Should I trust the author | Trust anchors and authorization | 784 | of the firmware? | policies on the device | 785 | | | 786 | Has the firmware been | Digital signature and MAC covering | 787 | corrupted? | the firmware image | 788 | | | 789 | Does the firmware update | Conditions with Vendor ID, Class ID | 790 | apply to this device? | and Device ID | 791 | | | 792 | Is the update older than | Sequence number in the manifest (1) | 793 | the active firmware? | | 794 | | | 795 | When should the device | Wait directive | 796 | apply the update? | | 797 | | | 798 | How should the device | Manifest commands | 799 | apply the update? | | 800 | | | 801 | What kind of firmware | Unpack algorithms to interpret a | 802 | binary is it? | format. | 803 | | | 804 | Where should the update be | Dependencies on other manifests and | 805 | obtained? | firmware image URI in Manifest | 806 | | | 807 | Where should the firmware | Storage Location and Component | 808 | be stored? | Identifier | 809 +----------------------------+--------------------------------------+ 811 Table 1: Firmware Update Decisions. 813 (1): A device presented with an old, but valid manifest and firmware 814 must not be tricked into installing such firmware since a 815 vulnerability in the old firmware image may allow an attacker to gain 816 control of the device. 818 Keeping the code size and complexity of a manifest parsers small is 819 important for constrained IoT devices. Since the manifest parsing 820 code may also be used by the bootloader it is part of the trusted 821 computing base. 823 A manifest may not only be used to protect firmware images but also 824 configuration data such as network credentials or personalization 825 data related to firmware or software. Personalization data 826 demonstrates the need for confidentiality to be maintained between 827 two or more stakeholders that both deliver images to the same device. 829 Personalization data is used with Trusted Execution Environments 830 (TEEs), which benefit from a protocol for managing the lifecycle of 831 trusted applications (TAs) running inside a TEE. TEEs may obtain TAs 832 from different authors and those TAs may require personalization 833 data, such as payment information, to be securely conveyed to the 834 TEE. The TA's author does not want to expose the TA's code to any 835 other stakeholder or third party. The user does not want to expose 836 the payment information to any other stakeholder or third party. 838 7. Securing Firmware Updates 840 Using firmware updates to fix vulnerabilities in devices is important 841 but securing this update mechanism is equally important since 842 security problems are exacerbated by the update mechanism: update is 843 essentially authorized remote code execution, so any security 844 problems in the update process expose that remote code execution 845 system. Failure to secure the firmware update process will help 846 attackers to take control over devices. 848 End-to-end security mechanisms are used to protect the firmware image 849 and the manifest. The following assumptions are made to allow the 850 firmware consumer to verify the received firmware image and manifest 851 before updating software: 853 - Authentication ensures that the device can cryptographically 854 identify the author(s) creating firmware images and manifests. 855 Authenticated identities may be used as input to the authorization 856 process. Not all entities creating and signing manifests have the 857 same permissions. A device needs to determine whether the 858 requested action is indeed covered by the permission of the party 859 that signed the manifest. Informing the device about the 860 permissions of the different parties also happens in an out-of- 861 band fashion and is also a duty of the Trust Provisioning 862 Authority. 864 - Integrity protection ensures that no third party can modify the 865 manifest or the firmware image. To accept an update, a device 866 needs to verify the signature covering the manifest. There may be 867 one or multiple manifests that need to be validated, potentially 868 signed by different parties. The device needs to be in possession 869 of the trust anchors to verify those signatures. Installing trust 870 anchors to devices via the Trust Provisioning Authority happens in 871 an out-of-band fashion prior to the firmware update process. 873 - For confidentiality protection of the firmware image, it must be 874 done in such a way that the intended firmware consumer(s), other 875 authorized parties, and no one else can decrypt it. The 876 information that is encrypted individually for each device/ 877 recipient must maintain friendliness to Content Distribution 878 Networks, bulk storage, and broadcast protocols. For 879 confidentiality protection of firmware images the author needs to 880 be in possession of the certificate/public key or a pre-shared key 881 of a device. The use of confidentiality protection of firmware 882 images is optional. 884 A manifest specification must support different cryptographic 885 algorithms and algorithm extensibility. Moreover, since RSA- and 886 ECC-based signature schemes may become vulnerable to quantum- 887 accelerated key extraction in the future, unchangeable bootloader 888 code in ROM is recommended to use post-quantum secure signature 889 schemes such as hash-based signatures [RFC8778]. A bootloader author 890 must carefully consider the service lifetime of their product and the 891 time horizon for quantum-accelerated key extraction. The worst-case 892 estimate, at time of writing, for the time horizon to key extraction 893 with quantum acceleration is approximately 2030, based on current 894 research [quantum-factorization]. 896 When a device obtains a monolithic firmware image from a single 897 author without any additional approval steps then the authorization 898 flow is relatively simple. There are, however, other cases where 899 more complex policy decisions need to be made before updating a 900 device. 902 In this architecture the authorization policy is separated from the 903 underlying communication architecture. This is accomplished by 904 separating the entities from their permissions. For example, an 905 author may not have the authority to install a firmware image on a 906 device in critical infrastructure without the authorization of a 907 device operator. In this case, the device may be programmed to 908 reject firmware updates unless they are signed both by the firmware 909 author and by the device operator. 911 Alternatively, a device may trust precisely one entity, which does 912 all permission management and coordination. This entity allows the 913 device to offload complex permissions calculations for the device. 915 8. Example 917 Figure 2 illustrates an example message flow for distributing a 918 firmware image to a device. The firmware and manifest are stored on 919 the same firmware server and distributed in a detached manner. 921 +--------+ +-----------------+ +-----------------------------+ 922 | | | Firmware Server | | IoT Device | 923 | Author | | Status Tracker | | +------------+ +----------+ | 924 +--------+ | Server | | | Firmware | |Bootloader| | 925 | +-----------------+ | | Consumer | | | | 926 | | | +------------+ +----------+ | 927 | | | | | | 928 | | | +-----------------------+ | 929 | Create Firmware | | | Status Tracker Client | | 930 |--------------+ | | +-----------------------+ | 931 | | | `'''''''''''''''''''''''''''' 932 |<-------------+ | | | | 933 | | | | | 934 | Upload Firmware | | | | 935 |------------------>| | | | 936 | | | | | 937 | Create Manifest | | | | 938 |---------------+ | | | | 939 | | | | | | 940 |<--------------+ | | | | 941 | | | | | 942 | Sign Manifest | | | | 943 |-------------+ | | | | 944 | | | | | | 945 |<------------+ | | | | 946 | | | | | 947 | Upload Manifest | | | | 948 |------------------>| Notification of | | | 949 | | new firmware image | | | 950 | |----------------------------->| | 951 | | | | | 952 | | |Initiate| | 953 | | | Update | | 954 | | |<-------| | 955 | | | | | 956 | | Query Manifest | | | 957 | |<--------------------| . | 958 | | | . | 959 | | Send Manifest | . | 960 | |-------------------->| . | 961 | | | Validate | 962 | | | Manifest | 963 | | |--------+ | 964 | | | | | 965 | | |<-------+ | 966 | | | . | 967 | | Request Firmware | . | 968 | |<--------------------| . | 969 | | | . | 970 | | Send Firmware | . | 971 | |-------------------->| . | 972 | | | Verify . | 973 | | | Firmware | 974 | | |--------+ | 975 | | | | | 976 | | |<-------+ | 977 | | | . | 978 | | | Store . | 979 | | | Firmware | 980 | | |--------+ | 981 | | | | | 982 | | |<-------+ | 983 | | | . | 984 | | | . | 985 | | | . | 986 | | | | | 987 | | | Update | | 988 | | |Complete| | 989 | | |------->| | 990 | | | | 991 | | Firmware Update Completed | | 992 | |<-----------------------------| | 993 | | | | 994 | | Reboot | | 995 | |----------------------------->| | 996 | | | | | 997 | | | | | 998 | | |Reboot | 999 | | | |------>| 1000 | | | | | 1001 | | | . | 1002 | | +---+----------------+--+ 1003 | | S| | | | 1004 | | E| | Verify | | 1005 | | C| | Firmware | | 1006 | | U| | +--------------| | 1007 | | R| | | | | 1008 | | E| | +------------->| | 1009 | | | | | | 1010 | | B| | Activate new | | 1011 | | O| | Firmware | | 1012 | | O| | +--------------| | 1013 | | T| | | | | 1014 | | | | +------------->| | 1015 | | P| | | | 1016 | | R| | Boot new | | 1017 | | O| | Firmware | | 1018 | | C| | +--------------| | 1019 | | E| | | | | 1020 | | S| | +------------->| | 1021 | | S| | | | 1022 | | +---+----------------+--+ 1023 | | | . | 1024 | | | | | 1025 | | . | | 1026 | | Device running new firmware | | 1027 | |<-----------------------------| | 1028 | | . | | 1029 | | | | 1031 Figure 2: First Example Flow for a Firmware Update. 1033 Figure 3 shows an exchange that starts with the status tracker 1034 querying the device for its current firmware version. Later, a new 1035 firmware version becomes available and since this device is running 1036 an older version the status tracker server interacts with the device 1037 to initiate an update. 1039 The manifest and the firmware are stored on different servers in this 1040 example. When the device processes the manifest it learns where to 1041 download the new firmware version. The firmware consumer downloads 1042 the firmware image with the newer version X.Y.Z after successful 1043 validation of the manifest. Subsequently, a reboot is initiated and 1044 the secure boot process starts. Finally, the device reports the 1045 successful boot of the new firmware version. 1047 +---------+ +-----------------+ +-----------------------------+ 1048 | Status | | Firmware Server | | +------------+ +----------+ | 1049 | Tracker | | Status Tracker | | | Firmware | |Bootloader| | 1050 | Server | | Server | | | Consumer | | | | 1051 +---------+ +-----------------+ | | +Status | +----------+ | 1052 | | | | Tracker | | | 1053 | | | | Client | | | 1054 | | | +------------+ | | 1055 | | | | IoT Device | | 1056 | | `'''''''''''''''''''''''''''' 1057 | | | | 1058 | Query Firmware Version | | 1059 |------------------------------------->| | 1060 | Firmware Version A.B.C | | 1061 |<-------------------------------------| | 1062 | | | | 1063 | <> | | 1064 | | | | 1065 _,...._ _,...._ | | 1066 ,' `. ,' `. | | 1067 | New | | New | | | 1068 \ Manifest / \ Firmware / | | 1069 `.._ _,,' `.._ _,,' | | 1070 `'' `'' | | 1071 | Push manifest | | 1072 |----------------+-------------------->| | 1073 | | | | 1074 | ' | ' 1075 | | | Validate | 1076 | | | Manifest | 1077 | | |---------+ | 1078 | | | | | 1079 | | |<--------+ | 1080 | | Request firmware | | 1081 | | X.Y.Z | | 1082 | |<--------------------| | 1083 | | | | 1084 | | Firmware X.Y.Z | | 1085 | |-------------------->| | 1086 | | | | 1087 | | | Verify | 1088 | | | Firmware | 1089 | | |--------------+ | 1090 | | | | | 1091 | | |<-------------+ | 1092 | | | | 1093 | | | Store | 1094 | | | Firmware | 1095 | | |-------------+ | 1096 | | | | | 1097 | | |<------------+ | 1098 | | | | 1099 | | | | 1100 | | | Trigger Reboot | 1101 | | |--------------->| 1102 | | | | 1103 | | | | 1104 | | | __..-------..._' 1105 | | ,-' `-. 1106 | | | Secure Boot | 1107 | | `-. _/ 1108 | | |`--..._____,,.,-' 1109 | | | | 1110 | Device running firmware X.Y.Z | | 1111 |<-------------------------------------| | 1112 | | | | 1113 | | | | 1115 Figure 3: Second Example Flow for a Firmware Update. 1117 9. IANA Considerations 1119 This document does not require any actions by IANA. 1121 10. Security Considerations 1123 This document describes terminology, requirements and an architecture 1124 for firmware updates of IoT devices. The content of the document is 1125 thereby focused on improving security of IoT devices via firmware 1126 update mechanisms and informs the standardization of a manifest 1127 format. 1129 An in-depth examination of the security considerations of the 1130 architecture is presented in [I-D.ietf-suit-information-model]. 1132 11. Acknowledgements 1134 We would like to thank the following persons for their feedback: 1136 - Geraint Luff 1138 - Amyas Phillips 1140 - Dan Ros 1142 - Thomas Eichinger 1144 - Michael Richardson 1146 - Emmanuel Baccelli 1148 - Ned Smith 1150 - Jim Schaad 1152 - Carsten Bormann 1154 - Cullen Jennings 1156 - Olaf Bergmann 1158 - Suhas Nandakumar 1160 - Phillip Hallam-Baker 1162 - Marti Bolivar 1164 - Andrzej Puzdrowski 1165 - Markus Gueller 1167 - Henk Birkholz 1169 - Jintao Zhu 1171 - Takeshi Takahashi 1173 - Jacob Beningo 1175 - Kathleen Moriarty 1177 - Bob Briscoe 1179 - Roman Danyliw 1181 - Brian Carpenter 1183 - Theresa Enghardt 1185 - Rich Salz 1187 - Mohit Sethi 1189 We would also like to thank the WG chairs, Russ Housley, David 1190 Waltermire, Dave Thaler for their support and their reviews. 1192 12. Informative References 1194 [I-D.ietf-rats-architecture] 1195 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1196 W. Pan, "Remote Attestation Procedures Architecture", 1197 draft-ietf-rats-architecture-06 (work in progress), 1198 September 2020. 1200 [I-D.ietf-suit-information-model] 1201 Moran, B., Tschofenig, H., and H. Birkholz, "An 1202 Information Model for Firmware Updates in IoT Devices", 1203 draft-ietf-suit-information-model-07 (work in progress), 1204 June 2020. 1206 [I-D.ietf-suit-manifest] 1207 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1208 "A Concise Binary Object Representation (CBOR)-based 1209 Serialization Format for the Software Updates for Internet 1210 of Things (SUIT) Manifest", draft-ietf-suit-manifest-09 1211 (work in progress), July 2020. 1213 [I-D.ietf-teep-architecture] 1214 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1215 "Trusted Execution Environment Provisioning (TEEP) 1216 Architecture", draft-ietf-teep-architecture-12 (work in 1217 progress), July 2020. 1219 [LwM2M] OMA, ., "Lightweight Machine to Machine Technical 1220 Specification, Version 1.0.2", February 2018, 1221 . 1225 [quantum-factorization] 1226 Jiang, S., Britt, K., McCaskey, A., Humble, T., and S. 1227 Kais, "Quantum Annealing for Prime Factorization", 1228 December 2018, 1229 . 1231 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1232 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1233 2010, . 1235 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1236 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1237 . 1239 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1240 Constrained-Node Networks", RFC 7228, 1241 DOI 10.17487/RFC7228, May 2014, 1242 . 1244 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 1245 of Things Software Update (IoTSU) Workshop 2016", 1246 RFC 8240, DOI 10.17487/RFC8240, September 2017, 1247 . 1249 [RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature 1250 Algorithm with CBOR Object Signing and Encryption (COSE)", 1251 RFC 8778, DOI 10.17487/RFC8778, April 2020, 1252 . 1254 Authors' Addresses 1256 Brendan Moran 1257 Arm Limited 1259 EMail: Brendan.Moran@arm.com 1260 Hannes Tschofenig 1261 Arm Limited 1263 EMail: hannes.tschofenig@arm.com 1265 David Brown 1266 Linaro 1268 EMail: david.brown@linaro.org 1270 Milosch Meriac 1271 Consultant 1273 EMail: milosch@meriac.com