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