idnits 2.17.1 draft-ietf-suit-architecture-12.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 (September 17, 2020) is 1311 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-suit-manifest' is defined on line 1263, but no explicit reference was found in the text == 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: March 21, 2021 D. Brown 6 Linaro 7 M. Meriac 8 Consultant 9 September 17, 2020 11 A Firmware Update Architecture for Internet of Things 12 draft-ietf-suit-architecture-12 14 Abstract 16 Vulnerabilities with Internet of Things (IoT) devices have raised the 17 need for a solid and secure firmware update mechanism that is also 18 suitable for constrained devices. Incorporating such update 19 mechanism to fix vulnerabilities, to update configuration settings as 20 well as adding new functionality is recommended by security experts. 22 This document lists requirements and describes an architecture for a 23 firmware update mechanism suitable for IoT devices. The architecture 24 is agnostic to the transport of the firmware images and associated 25 meta-data. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 21, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. Agnostic to how firmware images are distributed . . . . . 7 65 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 8 66 3.3. Use state-of-the-art security mechanisms . . . . . . . . 8 67 3.4. Rollback attacks must be prevented . . . . . . . . . . . 9 68 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 9 69 3.6. Operate with a small bootloader . . . . . . . . . . . . . 9 70 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10 71 3.8. Minimal impact on existing firmware formats . . . . . . . 10 72 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10 73 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 11 74 3.11. Suitability to software and personalization data . . . . 13 75 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Communication Architecture . . . . . . . . . . . . . . . . . 14 77 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 19 79 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 19 80 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 19 81 7.3. Symmetric Multiple CPUs . . . . . . . . . . . . . . . . . 19 82 7.4. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 20 83 7.5. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 20 84 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 89 13. Informative References . . . . . . . . . . . . . . . . . . . 28 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 92 1. Introduction 94 When developing Internet of Things (IoT) devices, one of the most 95 difficult problems to solve is how to update firmware on the device. 96 Once the device is deployed, firmware updates play a critical part in 97 its lifetime, particularly when devices have a long lifetime, are 98 deployed in remote or inaccessible areas where manual intervention is 99 cost prohibitive or otherwise difficult. Updates to the firmware of 100 an IoT device are done to fix bugs in software, to add new 101 functionality, and to re-configure the device to work in new 102 environments or to behave differently in an already deployed context. 104 The firmware update process, among other goals, has to ensure that 106 - The firmware image is authenticated and integrity protected. 107 Attempts to flash a modified firmware image or an image from an 108 unknown source are prevented. 110 - The firmware image can be confidentiality protected so that 111 attempts by an adversary to recover the plaintext binary can be 112 prevented. Obtaining the firmware is often one of the first steps 113 to mount an attack since it gives the adversary valuable insights 114 into used software libraries, configuration settings and generic 115 functionality (even though reverse engineering the binary can be a 116 tedious process). 118 This version of the document assumes asymmetric cryptography and a 119 public key infrastructure. Future versions may also describe a 120 symmetric key approach for very constrained devices. 122 While the standardization work has been informed by and optimised for 123 firmware update use cases of Class 1 devices (according to the device 124 class definitions in RFC 7228 [RFC7228]) devices, there is nothing in 125 the architecture that restricts its use to only these constrained IoT 126 devices. Moreover, this architecture is not limited to managing 127 software updates, but can also be applied to managing the delivery of 128 arbitrary data, such as configuration information and keys. 130 More details about the security goals are discussed in Section 5 and 131 requirements are described in Section 3. 133 2. Conventions and Terminology 135 This document uses the following terms: 137 - Manifest: The manifest contains meta-data about the firmware 138 image. The manifest is protected against modification and 139 provides information about the author. 141 - Firmware Image: The firmware image, or image, is a binary that may 142 contain the complete software of a device or a subset of it. The 143 firmware image may consist of multiple images, if the device 144 contains more than one microcontroller. Often it is also a 145 compressed archive that contains code, configuration data, and 146 even the entire file system. The image may consist of a 147 differential update for performance reasons. Firmware is the more 148 universal term. The terms, firmware image, firmware, and image, 149 are used in this document and are interchangeable. 151 - Software: The terms "software" and "firmware" are used 152 interchangeably. 154 - Bootloader: A bootloader is a piece of software that is executed 155 once a microcontroller has been reset. It is responsible for 156 deciding whether to boot a firmware image that is present or 157 whether to obtain and verify a new firmware image. Since the 158 bootloader is a security critical component its functionality may 159 be split into separate stages. Such a multi-stage bootloader may 160 offer very basic functionality in the first stage and resides in 161 ROM whereas the second stage may implement more complex 162 functionality and resides in flash memory so that it can be 163 updated in the future (in case bugs have been found). The exact 164 split of components into the different stages, the number of 165 firmware images stored by an IoT device, and the detailed 166 functionality varies throughout different implementations. A more 167 detailed discussion is provided in Section 8. 169 - Microcontroller (MCU for microcontroller unit): An MCU is a 170 compact integrated circuit designed for use in embedded systems. 171 A typical microcontroller includes a processor, memory (RAM and 172 flash), input/output (I/O) ports and other features connected via 173 some bus on a single chip. The term 'system on chip (SoC)' is 174 often used for these types of devices. 176 - System on Chip (SoC): An SoC is an integrated circuit that 177 integrates all components of a computer, such as CPU, memory, 178 input/output ports, secondary storage, etc. 180 - Homogeneous Storage Architecture (HoSA): A device that stores all 181 firmware components in the same way, for example in a file system 182 or in flash memory. 184 - Heterogeneous Storage Architecture (HeSA): A device that stores at 185 least one firmware component differently from the rest, for 186 example a device with an external, updatable radio, or a device 187 with internal and external flash memory. 189 - Trusted Execution Environments (TEEs): An execution environment 190 that runs alongside of, but is isolated from, an REE. 192 - Rich Execution Environment (REE): An environment that is provided 193 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 194 potentially in conjunction with other supporting operating systems 195 and hypervisors; it is outside of the TEE. This environment and 196 applications running on it are considered un-trusted. 198 - Trusted applications (TAs): An application component that runs in 199 a TEE. 201 For more information about TEEs see [I-D.ietf-teep-architecture]. 202 TEEP requires the use of SUIT for delivering TAs. 204 The following entities are used: 206 - Author: The author is the entity that creates the firmware image. 207 There may be multiple authors in a system either when a device 208 consists of multiple micro-controllers or when the the final 209 firmware image consists of software components from multiple 210 companies. 212 - Firmware Consumer: The firmware consumer is the recipient of the 213 firmware image and the manifest. It is responsible for parsing 214 and verifying the received manifest and for storing the obtained 215 firmware image. The firmware consumer plays the role of the 216 update component on the IoT device typically running in the 217 application firmware. It interacts with the firmware server and 218 with the status tracker, if present. 220 - (IoT) Device: A device refers to the entire IoT product, which 221 consists of one or many MCUs, sensors and/or actuators. Many IoT 222 devices sold today contain multiple MCUs and therefore a single 223 device may need to obtain more than one firmware image and 224 manifest to succesfully perform an update. The terms device and 225 firmware consumer are used interchangably since the firmware 226 consumer is one software component running on an MCU on the 227 device. 229 - Status Tracker: The status tracker offers device management 230 functionality to retrieve information about the installed firmware 231 on a device and other device characteristics (including free 232 memory and hardware components), to obtain the state of the 233 firmware update cycle the device is currently in, and to trigger 234 the update process. The deployment of status trackers is flexible 235 and they may be used as cloud-based servers, on-premise servers, 236 embedded in edge computing device (such as Internet access 237 gateways or protocol translation gateways), or even in smart 238 phones and tablets. IoT devices that self-initiate updates may 239 run a status tracker. Similarly, IoT devices that act as a proxy 240 for other IoT devices in a protocol translation or edge computing 241 device node may also run a status tracker. However, if the device 242 contains multiple MCUs, the main MCU may act as a limited status 243 tracker towards the other MCUs if updates are to be synchronized 244 across MCUs. How much functionality a status tracker includes 245 depends on the selected configuration of the device management 246 functionality and the communication environment it is used in. In 247 a generic networking environment the protocol used between the 248 client and the server-side of the status tracker need to deal with 249 Internet communication challenges involving firewall and NAT 250 traversal. In other cases, the communication interaction may be 251 rather simple. This architecture document does not impose 252 requirements on the status tracker. 254 - Firmware Server: The firmware server stores firmware images and 255 manifests and distributes them to IoT devices. Some deployments 256 may require a store-and-forward concept, which requires storing 257 the firmware images/manifests on more than one entity before 258 they reach the device. There is typically some interaction 259 between the firmware server and the status tracker but those 260 entities are often physically separated on different devices for 261 scalability reasons. 263 - Device Operator: The actor responsible for the day-to-day 264 operation of a fleet of IoT devices. 266 - Network Operator: The actor responsible for the operation of a 267 network to which IoT devices connect. 269 - Claim: A piece of information asserted about a recipient or 270 payload. 272 In addition to the entities in the list above there is an orthogonal 273 infrastructure with a Trust Provisioning Authority (TPA) distributing 274 trust anchors and authorization permissions to various entities in 275 the system. The TPA may also delegate rights to install, update, 276 enhance, or delete trust anchors and authorization permissions to 277 other parties in the system. This infrastructure overlaps the 278 communication architecture and different deployments may empower 279 certain entities while other deployments may not. For example, in 280 some cases, the Original Design Manufacturer (ODM), which is a 281 company that designs and manufactures a product, may act as a TPA and 282 may decide to remain in full control over the firmware update process 283 of their products. 285 The terms 'trust anchor' and 'trust anchor store' are defined in 286 [RFC6024]: 288 - "A trust anchor represents an authoritative entity via a public 289 key and associated data. The public key is used to verify digital 290 signatures, and the associated data is used to constrain the types 291 of information for which the trust anchor is authoritative." 293 - "A trust anchor store is a set of one or more trust anchors stored 294 in a device. A device may have more than one trust anchor store, 295 each of which may be used by one or more applications." A trust 296 anchor store must resist modification against unauthorized 297 insertion, deletion, and modification. 299 3. Requirements 301 The firmware update mechanism described in this specification was 302 designed with the following requirements in mind: 304 - Agnostic to how firmware images are distributed 306 - Friendly to broadcast delivery 308 - Use state-of-the-art security mechanisms 310 - Rollback attacks must be prevented 312 - High reliability 314 - Operate with a small bootloader 316 - Small Parsers 318 - Minimal impact on existing firmware formats 320 - Robust permissions 322 - Diverse modes of operation 324 - Suitability to software and personalization data 326 3.1. Agnostic to how firmware images are distributed 328 Firmware images can be conveyed to devices in a variety of ways, 329 including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and 330 use different protocols (e.g., CoAP, HTTP). The specified mechanism 331 needs to be agnostic to the distribution of the firmware images and 332 manifests. 334 3.2. Friendly to broadcast delivery 336 This architecture does not specify any specific broadcast protocol. 337 However, given that broadcast may be desirable for some networks, 338 updates must cause the least disruption possible both in metadata and 339 firmware transmission. 341 For an update to be broadcast friendly, it cannot rely on link layer, 342 network layer, or transport layer security. A solution has to rely 343 on security protection applied to the manifest and firmware image 344 instead. In addition, the same manifest must be deliverable to many 345 devices, both those to which it applies and those to which it does 346 not, without a chance that the wrong device will accept the update. 347 Considerations that apply to network broadcasts apply equally to the 348 use of third-party content distribution networks for payload 349 distribution. 351 3.3. Use state-of-the-art security mechanisms 353 End-to-end security between the author and the device is shown in 354 Section 5. 356 Authentication ensures that the device can cryptographically identify 357 the author(s) creating firmware images and manifests. Authenticated 358 identities may be used as input to the authorization process. 360 Integrity protection ensures that no third party can modify the 361 manifest or the firmware image. 363 For confidentiality protection of the firmware image, it must be done 364 in such a way that every intended recipient can decrypt it. The 365 information that is encrypted individually for each device must 366 maintain friendliness to Content Distribution Networks, bulk storage, 367 and broadcast protocols. 369 A manifest specification must support different cryptographic 370 algorithms and algorithm extensibility. Due of the nature of 371 unchangeable code in ROM for use with bootloaders the use of post- 372 quantum secure signature mechanisms, such as hash-based signatures 373 [RFC8778], are attractive. These algorithms maintain security in 374 presence of quantum computers. 376 A mandatory-to-implement set of algorithms will be specified in the 377 manifest specification [I-D.ietf-suit-manifest]}. 379 3.4. Rollback attacks must be prevented 381 A device presented with an old, but valid manifest and firmware must 382 not be tricked into installing such firmware since a vulnerability in 383 the old firmware image may allow an attacker to gain control of the 384 device. 386 3.5. High reliability 388 A power failure at any time must not cause a failure of the device. 389 Equally, adverse network conditions during an update must not cause 390 the failure of the device. A failure to validate any part of an 391 update must not cause a failure of the device. One way to achieve 392 this functionality is to provide a minimum of two storage locations 393 for firmware and one bootable location for firmware. An alternative 394 approach is to use a 2nd stage bootloader with build-in full featured 395 firmware update functionality such that it is possible to return to 396 the update process after power down. 398 Note: This is an implementation requirement rather than a requirement 399 on the manifest format. 401 3.6. Operate with a small bootloader 403 Throughout this document we assume that the bootloader itself is 404 distinct from the role of the firmware consumer and therefore does 405 not manage the firmware update process. This may give the impression 406 that the bootloader itself is a completely separate component, which 407 is mainly responsible for selecting a firmware image to boot. 409 The overlap between the firmware update process and the bootloader 410 functionality comes in two forms, namely 412 - First, a bootloader must verify the firmware image it boots as 413 part of the secure boot process. Doing so requires meta-data to 414 be stored alongside the firmware image so that the bootloader can 415 cryptographically verify the firmware image before booting it to 416 ensure it has not been tampered with or replaced. This meta-data 417 used by the bootloader may well be the same manifest obtained with 418 the firmware image during the update process (with the severable 419 fields stripped off). 421 - Second, an IoT device needs a recovery strategy in case the 422 firmware update / boot process fails. The recovery strategy may 423 include storing two or more firmware images on the device or 424 offering the ability to have a second stage bootloader perform the 425 firmware update process again using firmware updates over serial, 426 USB or even wireless connectivity like a limited version of 427 Bluetooth Smart. In the latter case the firmware consumer 428 functionality is contained in the second stage bootloader and 429 requires the necessary functionality for executing the firmware 430 update process, including manifest parsing. 432 In general, it is assumed that the bootloader itself, or a minimal 433 part of it, will not be updated since a failed update of the 434 bootloader poses a risk in reliability. 436 All information necessary for a device to make a decision about the 437 installation of a firmware update must fit into the available RAM of 438 a constrained IoT device. This prevents flash write exhaustion. 439 This is typically not a difficult requirement to accomplish because 440 there are not other task/processing running while the bootloader is 441 active (unlike it may be the case when running the application 442 firmware). 444 Note: This is an implementation requirement. 446 3.7. Small Parsers 448 Since parsers are known sources of bugs, any parsers used to process 449 the manifest must be minimal. Additionally, it must be easy to parse 450 only those fields that are required to validate at least one 451 signature or MAC with minimal exposure. 453 3.8. Minimal impact on existing firmware formats 455 The design of the firmware update mechanism must not require changes 456 to existing firmware formats. 458 3.9. Robust permissions 460 When a device obtains a monolithic firmware image from a single 461 author without any additional approval steps then the authorization 462 flow is relatively simple. There are, however, other cases where 463 more complex policy decisions need to be made before updating a 464 device. 466 In this architecture the authorization policy is separated from the 467 underlying communication architecture. This is accomplished by 468 separating the entities from their permissions. For example, an 469 author may not have the authority to install a firmware image on a 470 device in critical infrastructure without the authorization of a 471 device operator. In this case, the device may be programmed to 472 reject firmware updates unless they are signed both by the firmware 473 author and by the device operator. 475 Alternatively, a device may trust precisely one entity, which does 476 all permission management and coordination. This entity allows the 477 device to offload complex permissions calculations for the device. 479 3.10. Operating modes 481 There are three broad classifications of update operating modes. 483 - Client-initiated Update 485 - Server-initiated Update 487 - Hybrid Update 489 Client-initiated updates take the form of a firmware consumer on a 490 device proactively checking (polling) for new firmware images. 492 Server-initiated updates are important to consider because timing of 493 updates may need to be tightly controlled in some high- reliability 494 environments. In this case the status tracker determines what 495 devices qualify for a firmware update. Once those devices have been 496 selected the firmware server distributes updates to the firmware 497 consumers. 499 Note: This assumes that the status tracker is able to reach the 500 device, which may require devices to keep reachability information at 501 the status tracker up-to-date. This may also require keeping state 502 at NATs and stateful packet filtering firewalls alive. 504 Hybrid updates are those that require an interaction between the 505 firmware consumer and the status tracker. The status tracker pushes 506 notifications of availability of an update to the firmware consumer, 507 and it then downloads the image from a firmware server as soon as 508 possible. 510 While these broad classifications encompass the majority of operating 511 modes, some may not be covered in these classifications. By 512 reinterpreting these modes as a set of operations performed by the 513 system as a whole, all operating modes can be represented. 515 The steps performed in the course of an update by the system 516 containing an updatable device are: 518 - Notification 520 - Pre-authorisation 522 - Dependency resolution 523 - Download 525 - Installation 527 This is a coarse-grained high level view of steps required to install 528 a new firmware. By considering where in the system each of these 529 steps is performed, each operating mode can be represented. Each of 530 these steps is broken down into smaller constituent parts. Section 5 531 defines the steps taken from the perspective of the communication 532 between actors in the system. Section 8 describes some additional 533 steps that a bootloader takes in addition to those described here. 534 Section 9 shows an example of the steps undertaken by each party in 535 the course of an update. 537 The notification step consists of the status tracker informing the 538 firmware consumer that an update is available. This can be 539 accomplished via polling (client-initiated), push notifications 540 (server-initiated), or more complex mechanisms. 542 The pre-authorisation step involves verifying whether the entity 543 signing the manifest is indeed authorized to perform an update. The 544 firmware consumer must also determine whether it should fetch and 545 process a firmware image, which is referenced in a manifest. 547 A dependency resolution phase is needed when more than one component 548 can be updated or when a differential update is used. The necessary 549 dependencies must be available prior to installation. 551 The download step is the process of acquiring a local copy of the 552 firmware image. When the download is client-initiated, this means 553 that the firmware consumer chooses when a download occurs and 554 initiates the download process. When a download is server-initiated, 555 this means that the status tracker tells the device when to download 556 or that it initiates the transfer directly to the firmware consumer. 557 For example, a download from an HTTP-based firmware server is client- 558 initiated. Pushing a manifest and firmware image to the transfer to 559 the Package resource of the LwM2M Firmware Update object [LwM2M] is 560 server-initiated. 562 If the firmware consumer has downloaded a new firmware image and is 563 ready to install it, it may need to wait for a trigger from the 564 status tracker to initiate the installation, may trigger the update 565 automatically, or may go through a more complex decision making 566 process to determine the appropriate timing for an update (such as 567 delaying the update process to a later time when end users are less 568 impacted by the update process). 570 Installation is the act of processing the payload into a format that 571 the IoT device can recognise and the bootloader is responsible for 572 then booting from the newly installed firmware image. 574 Each of these steps may require different permissions. 576 3.11. Suitability to software and personalization data 578 The work on a standardized manifest format initially focused on the 579 most constrained IoT devices and those devices contain code put 580 together by a single author (although that author may obtain code 581 from other developers, some of it only in binary form). 583 Later it turns out that other use cases may benefit from a 584 standardized manifest format also for conveying software and even 585 personalization data alongside software. Trusted Execution 586 Environments (TEEs), for example, greatly benefit from a protocol for 587 managing the lifecycle of trusted applications (TAs) running inside a 588 TEE. TEEs may obtain TAs from different authors and those TAs may 589 require personalization data, such as payment information, to be 590 securely conveyed to the TEE. 592 To support this wider range of use cases the manifest format should 593 therefore be extensible to convey other forms of payloads as well. 595 4. Claims 597 The information conveyed from an Author to a Firmware Consumer can be 598 considered to be Claims as described in [RFC7519] and [RFC8392]. The 599 same security considerations apply to the Claims expressed in the 600 manifest. The chief difference between manifest Claims and CWT or 601 JWT claims is that a manifest has multiple subjects. The manifest 602 contains: 604 1. Claims about the Firmware, including its dependencies 606 2. Claims about the Firmware Consumer's physical or software 607 properties 609 3. Claims about the Author, or the Author's delegate 611 The credential used to authenticate these Claims must be directly or 612 indirectly related to the trust anchor installed at the device by the 613 Trust Provisioning Authority. 615 The baseline claims for all manifests are described in 616 [I-D.ietf-suit-information-model]. 618 5. Communication Architecture 620 Figure 1 shows the communication architecture where a firmware image 621 is created by an author, and uploaded to a firmware server. The 622 firmware image/manifest is distributed to the device either in a push 623 or pull manner using the firmware consumer residing on the device. 624 The device operator keeps track of the process using the status 625 tracker. This allows the device operator to know and control what 626 devices have received an update and which of them are still pending 627 an update. 629 Firmware + +----------+ Firmware + +-----------+ 630 Manifest | |-+ Manifest | |-+ 631 +--------->| Firmware | |<---------------| | | 632 | | Server | | | Author | | 633 | | | | | | | 634 | +----------+ | +-----------+ | 635 | +----------+ +-----------+ 636 | 637 | 638 | 639 -+-- ------ 640 ---- | ---- ---- ---- 641 // | \\ // \\ 642 / | \ / \ 643 / | \ / \ 644 / | \ / \ 645 / | \ / \ 646 | v | | | 647 | +------------+ | 648 | | Firmware | | | | 649 | | Consumer | | Device | +--------+ | 650 | +------------+ | Management| | | | 651 | | |<------------------------->| Status | | 652 | | Device | | | | Tracker| | 653 | +------------+ | || | | | 654 | | || +--------+ | 655 | | | | 656 | | \ / 657 \ / \ / 658 \ / \ Device / 659 \ Network / \ Operator / 660 \ Operator / \\ // 661 \\ // ---- ---- 662 ---- ---- ------ 663 ----- 665 Figure 1: Architecture. 667 End-to-end security mechanisms are used to protect the firmware image 668 and the manifest although Figure 2 does not show the manifest itself 669 since it may be distributed independently. 671 +-----------+ 672 +--------+ | | +--------+ 673 | | Firmware Image | Firmware | Firmware Image | | 674 | Device |<-----------------| Server |<------------------| Author | 675 | | | | | | 676 +--------+ +-----------+ +--------+ 677 ^ * 678 * * 679 ************************************************************ 680 End-to-End Security 682 Figure 2: End-to-End Security. 684 Whether the firmware image and the manifest is pushed to the device 685 or fetched by the device is a deployment specific decision. 687 The following assumptions are made to allow the firmware consumer to 688 verify the received firmware image and manifest before updating 689 software: 691 - To accept an update, a device needs to verify the signature 692 covering the manifest. There may be one or multiple manifests 693 that need to be validated, potentially signed by different 694 parties. The device needs to be in possession of the trust 695 anchors to verify those signatures. Installing trust anchors to 696 devices via the Trust Provisioning Authority happens in an out-of- 697 band fashion prior to the firmware update process. 699 - Not all entities creating and signing manifests have the same 700 permissions. A device needs to determine whether the requested 701 action is indeed covered by the permission of the party that 702 signed the manifest. Informing the device about the permissions 703 of the different parties also happens in an out-of-band fashion 704 and is also a duty of the Trust Provisioning Authority. 706 - For confidentiality protection of firmware images the author needs 707 to be in possession of the certificate/public key or a pre-shared 708 key of a device. The use of confidentiality protection of 709 firmware images is deployment specific. 711 There are different types of delivery modes, which are illustrated 712 based on examples below. 714 There is an option for embedding a firmware image into a manifest. 715 This is a useful approach for deployments where devices are not 716 connected to the Internet and cannot contact a dedicated firmware 717 server for the firmware download. It is also applicable when the 718 firmware update happens via a USB stick or via Bluetooth Smart. 719 Figure 3 shows this delivery mode graphically. 721 /------------\ /------------\ 722 /Manifest with \ /Manifest with \ 723 |attached | |attached | 724 \firmware image/ \firmware image/ 725 \------------/ +-----------+ \------------/ 726 +--------+ | | +--------+ 727 | |<.................| Firmware |<................| | 728 | Device | | Server | | Author | 729 | | | | | | 730 +--------+ +-----------+ +--------+ 732 Figure 3: Manifest with attached firmware. 734 Figure 4 shows an option for remotely updating a device where the 735 device fetches the firmware image from some file server. The 736 manifest itself is delivered independently and provides information 737 about the firmware image(s) to download. 739 /--------\ /--------\ 740 / \ / \ 741 | Manifest | | Manifest | 742 \ / \ / 743 \--------/ \--------/ 744 +-----------+ 745 +--------+ | | +--------+ 746 | |<.................| Status |................>| | 747 | Device | | Tracker | -- | Author | 748 | |<- | | --- | | 749 +--------+ -- +-----------+ --- +--------+ 750 -- --- 751 --- --- 752 -- +-----------+ -- 753 -- | | -- 754 /------------\ -- | Firmware |<- /------------\ 755 / \ -- | Server | / \ 756 | Firmware | | | | Firmware | 757 \ / +-----------+ \ / 758 \------------/ \------------/ 760 Figure 4: Independent retrieval of the firmware image. 762 This architecture does not mandate a specific delivery mode but a 763 solution must support both types. 765 6. Manifest 767 In order for a device to apply an update, it has to make several 768 decisions about the update: 770 - Does it trust the author of the update? 772 - Has the firmware been corrupted? 774 - Does the firmware update apply to this device? 776 - Is the update older than the active firmware? 778 - When should the device apply the update? 780 - How should the device apply the update? 782 - What kind of firmware binary is it? 784 - Where should the update be obtained? 786 - Where should the firmware be stored? 788 The manifest encodes the information that devices need in order to 789 make these decisions. It is a data structure that contains the 790 following information: 792 - information about the device(s) the firmware image is intended to 793 be applied to, 795 - information about when the firmware update has to be applied, 797 - information about when the manifest was created, 799 - dependencies on other manifests, 801 - pointers to the firmware image and information about the format, 803 - information about where to store the firmware image, 805 - cryptographic information, such as digital signatures or message 806 authentication codes (MACs). 808 The manifest information model is described in 809 [I-D.ietf-suit-information-model]. 811 7. Device Firmware Update Examples 813 Although these documents attempt to define a firmware update 814 architecture that is applicable to both existing systems, as well as 815 yet-to-be-conceived systems; it is still helpful to consider existing 816 architectures. 818 7.1. Single CPU SoC 820 The simplest, and currently most common, architecture consists of a 821 single MCU along with its own peripherals. These SoCs generally 822 contain some amount of flash memory for code and fixed data, as well 823 as RAM for working storage. These systems either have a single 824 firmware image, or an immutable bootloader that runs a single image. 825 A notable characteristic of these SoCs is that the primary code is 826 generally execute in place (XIP). Combined with the non-relocatable 827 nature of the code, firmware updates need to be done in place. 829 7.2. Single CPU with Secure - Normal Mode Partitioning 831 Another configuration consists of a similar architecture to the 832 previous, with a single CPU. However, this CPU supports a security 833 partitioning scheme that allows memory (in addition to other things) 834 to be divided into secure and normal mode. There will generally be 835 two images, one for secure mode, and one for normal mode. In this 836 configuration, firmware upgrades will generally be done by the CPU in 837 secure mode, which is able to write to both areas of the flash 838 device. In addition, there are requirements to be able to update 839 either image independently, as well as to update them together 840 atomically, as specified in the associated manifests. 842 7.3. Symmetric Multiple CPUs 844 In more complex SoCs with symmetric multi-processing support, 845 advanced operating systems, such as Linux, are often used. These 846 SoCs frequently use an external storage medium such as raw NAND flash 847 or eMMC. Due to the higher quantity of resources, these devices are 848 often capable of storing multiple copies of their firmware images and 849 selecting the most appropriate one to boot. Many SoCs also support 850 bootloaders that are capable of updating the firmware image, however 851 this is typically a last resort because it requires the device to be 852 held in the bootloader while the new firmware is downloaded and 853 installed, which results in down-time for the device. Firmware 854 updates in this class of device are typically not done in-place. 856 7.4. Dual CPU, shared memory 858 This configuration has two or more heterogeneous CPUs in a single SoC 859 that share memory (flash and RAM). Generally, they will be a 860 protection mechanism to prevent one CPU from accessing the other's 861 memory. Upgrades in this case will typically be done by one of the 862 CPUs, and is similar to the single CPU with secure mode. 864 7.5. Dual CPU, other bus 866 This configuration has two or more heterogeneous CPUs, each having 867 their own memory. There will be a communication channel between 868 them, but it will be used as a peripheral, not via shared memory. In 869 this case, each CPU will have to be responsible for its own firmware 870 upgrade. It is likely that one of the CPUs will be considered the 871 primary CPU, and will direct the other CPU to do the upgrade. This 872 configuration is commonly used to offload specific work to other 873 CPUs. Firmware dependencies are similar to the other solutions 874 above, sometimes allowing only one image to be upgraded, other times 875 requiring several to be upgraded atomically. Because the updates are 876 happening on multiple CPUs, upgrading the two images atomically is 877 challenging. 879 8. Bootloader 881 More devices today than ever before are being connected to the 882 Internet, which drives the need for firmware updates to be provided 883 over the Internet rather than through traditional interfaces, such as 884 USB or RS232. Updating a device over the Internet requires the 885 device to fetch not only the firmware image but also the manifest. 886 Hence, the following building blocks are necessary for a firmware 887 update solution: 889 - the Internet protocol stack for firmware downloads (*), 891 - the capability to write the received firmware image to persistent 892 storage (most likely flash memory) prior to performing the update, 894 - the ability to unpack, decompress or otherwise process the 895 received firmware image, 897 - the features to verify an image and a manifest, including digital 898 signature verification or checking a message authentication code, 900 - a manifest parsing library, and 902 - integration of the device into a device management server to 903 perform automatic firmware updates and to track their progress. 905 (*) Because firmware images are often multiple kilobytes, sometimes 906 exceeding one hundred kilobytes, in size for low end IoT devices and 907 even several megabytes large for IoT devices running full-fledged 908 operating systems like Linux, the protocol mechanism for retrieving 909 these images needs to offer features like congestion control, flow 910 control, fragmentation and reassembly, and mechanisms to resume 911 interrupted or corrupted transfers. 913 All these features are most likely offered by the application, i.e. 914 firmware consumer, running on the device (except for basic security 915 algorithms that may run either on a trusted execution environment or 916 on a separate hardware security MCU/module) rather than by the 917 bootloader itself. 919 Once manifests have been processed and firmware images successfully 920 downloaded and verified the device needs to hand control over to the 921 bootloader. In most cases this requires the MCU to restart. Once 922 the MCU has initiated a restart, the bootloader takes over control 923 and determines whether the newly downloaded firmware image should be 924 executed. 926 The boot process is security sensitive because the firmware images 927 may, for example, be stored in off-chip flash memory giving attackers 928 easy access to the image for reverse engineering and potentially also 929 for modifying the binary. The bootloader will therefore have to 930 perform security checks on the firmware image before it can be 931 booted. These security checks by the bootloader happen in addition 932 to the security checks that happened when the firmware image and the 933 manifest were downloaded. 935 The manifest may have been stored alongside the firmware image to 936 allow re-verification of the firmware image during every boot 937 attempt. Alternatively, secure boot-specific meta-data may have been 938 created by the application after a successful firmware download and 939 verification process. Whether to re-use the standardized manifest 940 format that was used during the initial firmware retrieval process or 941 whether it is better to use a different format for the secure boot- 942 specific meta-data depends on the system design. The manifest format 943 does, however, have the capability to serve also as a building block 944 for secure boot with its severable elements that allow shrinking the 945 size of the manifest by stripping elements that are no longer needed. 947 In order to satisfy the reliability requirements defined in 948 Section 3.5, devices must always be able to return to a working 949 firmware image. This has implications for the design of the 950 bootloader: If the firmware image contains the firmware consumer 951 functionality, as described above, then the bootloader must be able 952 to roll back to a working firmware image. Alternatively, the 953 bootloader may have enough functionality to fetch a firmware image 954 plus manifest from a firmware server over the Internet. A multi- 955 stage bootloader may soften this requirement at the expense of a more 956 sophisticated boot process. 958 For a bootloader to offer a secure boot mechanism it needs to provide 959 the following features: 961 - ability to access security algorithms, such as SHA-256 to compute 962 a fingerprint over the firmware image and a digital signature 963 algorithm. 965 - access keying material directly or indirectly to utilize the 966 digital signature. The device needs to have a trust anchor store. 968 - ability to expose boot process-related data to the application 969 firmware (such as to the device management software). This allows 970 a device management server to determine whether the firmware 971 update has been successful and, if not, what errors occurred. 973 - to (optionally) offer attestation information (such as 974 measurements). 976 While the software architecture of the bootloader and its security 977 mechanisms are implementation-specific, the manifest can be used to 978 control the firmware download from the Internet in addition to 979 augmenting secure boot process. These building blocks are highly 980 relevant for the design of the manifest. 982 9. Example 984 Figure 5 illustrates an example message flow for distributing a 985 firmware image to a device starting with an author uploading the new 986 firmware to firmware server and creating a manifest. The firmware 987 and manifest are stored on the same firmware server. This setup does 988 not use a status tracker and the firmware consumer component is 989 therefore responsible for periodically checking whether a new 990 firmware image is available for download. 992 +--------+ +-----------------+ +------------+ +----------+ 993 | | | | | Firmware | | | 994 | Author | | Firmware Server | | Consumer | |Bootloader| 995 +--------+ +-----------------+ +------------+ +----------+ 996 | | | + 997 | Create Firmware | | | 998 |--------------+ | | | 999 | | | | | 1000 |<-------------+ | | | 1001 | | | | 1002 | Upload Firmware | | | 1003 |------------------>| | | 1004 | | | | 1005 | Create Manifest | | | 1006 |---------------+ | | | 1007 | | | | | 1008 |<--------------+ | | | 1009 | | | | 1010 | Sign Manifest | | | 1011 |-------------+ | | | 1012 | | | | | 1013 |<------------+ | | | 1014 | | | | 1015 | Upload Manifest | | | 1016 |------------------>| | | 1017 | | | | 1018 | | Query Manifest | | 1019 | |<--------------------| | 1020 | | | | 1021 | | Send Manifest | | 1022 | |-------------------->| | 1023 | | | Validate | 1024 | | | Manifest | 1025 | | |---------+ | 1026 | | | | | 1027 | | |<--------+ | 1028 | | | | 1029 | | Request Firmware | | 1030 | |<--------------------| | 1031 | | | | 1032 | | Send Firmware | | 1033 | |-------------------->| | 1034 | | | Verify | 1035 | | | Firmware | 1036 | | |--------------+ | 1037 | | | | | 1038 | | |<-------------+ | 1039 | | | | 1040 | | | Store | 1041 | | | Firmware | 1042 | | |-------------+ | 1043 | | | | | 1044 | | |<------------+ | 1045 | | | | 1046 | | | | 1047 | | | Trigger Reboot | 1048 | | |--------------->| 1049 | | | | 1050 | | | | 1051 | | +---+----------------+--+ 1052 | | S| | | | 1053 | | E| | Verify | | 1054 | | C| | Firmware | | 1055 | | U| | +--------------| | 1056 | | R| | | | | 1057 | | E| | +------------->| | 1058 | | | | | | 1059 | | B| | Activate new | | 1060 | | O| | Firmware | | 1061 | | O| | +--------------| | 1062 | | T| | | | | 1063 | | | | +------------->| | 1064 | | P| | | | 1065 | | R| | Boot new | | 1066 | | O| | Firmware | | 1067 | | C| | +--------------| | 1068 | | E| | | | | 1069 | | S| | +------------->| | 1070 | | S| | | | 1071 | | +---+----------------+--+ 1072 | | | | 1074 Figure 5: First Example Flow for a Firmware Upate. 1076 Figure 6 shows an example follow with the device using a status 1077 tracker. For editorial reasons the author publishing the manifest at 1078 the status tracker and the firmware image at the firmware server is 1079 not shown. Also omitted is the secure boot process following the 1080 successful firmware update process. 1082 The exchange starts with the device interacting with the status 1083 tracker; the details of such exchange will vary with the different 1084 device management systems being used. In any case, the status 1085 tracker learns about the firmware version of the devices it manages. 1086 In our example, the device under management is using firmware version 1087 A.B.C. At a later point in time the author uploads a new firmware 1088 along with the manifest to the firmware server and the status 1089 tracker, respectively. While there is no need to store the manifest 1090 and the firmware on different servers this example shows a common 1091 pattern used in the industry. The status tracker may then 1092 automatically, based on human intervention or based on a more complex 1093 policy decide to inform the device about the newly available firmware 1094 image. In our example, it does so by pushing the manifest to the 1095 firmware consumer. The firmware consumer downloads the firmware 1096 image with the newer version X.Y.Z after successful validation of the 1097 manifest. Subsequently, a reboot is initiated and the secure boot 1098 process starts. 1100 +---------+ +-----------------+ +-----------------------------+ 1101 | Status | | | | +------------+ +----------+ | 1102 | Tracker | | Firmware Server | | | Firmware | |Bootloader| | 1103 | | | | | | Consumer | | | | 1104 +---------+ +-----------------+ | +------------+ +----------+ | 1105 | | | | IoT Device | | 1106 | | `'''''''''''''''''''''''''''' 1107 | | | | 1108 | Query Firmware Version | | 1109 |------------------------------------->| | 1110 | Firmware Version A.B.C | | 1111 |<-------------------------------------| | 1112 | | | | 1113 | <> | | 1114 | | | | 1115 _,...._ _,...._ | | 1116 ,' `. ,' `. | | 1117 | New | | New | | | 1118 \ Manifest / \ Firmware / | | 1119 `.._ _,,' `.._ _,,' | | 1120 `'' `'' | | 1121 | Push manifest | | 1122 |----------------+-------------------->| | 1123 | | | | 1124 | ' | ' 1125 | | | Validate | 1126 | | | Manifest | 1127 | | |---------+ | 1128 | | | | | 1129 | | |<--------+ | 1130 | | Request firmware | | 1131 | | X.Y.Z | | 1132 | |<--------------------| | 1133 | | | | 1134 | | Firmware X.Y.Z | | 1135 | |-------------------->| | 1136 | | | | 1137 | | | Verify | 1138 | | | Firmware | 1139 | | |--------------+ | 1140 | | | | | 1141 | | |<-------------+ | 1142 | | | | 1143 | | | Store | 1144 | | | Firmware | 1145 | | |-------------+ | 1146 | | | | | 1147 | | |<------------+ | 1148 | | | | 1149 | | | | 1150 | | | Trigger Reboot | 1151 | | |--------------->| 1152 | | | | 1153 | | | | 1154 | | | __..-------..._' 1155 | | ,-' `-. 1156 | | | Secure Boot | 1157 | | `-. _/ 1158 | | |`--..._____,,.,-' 1159 | | | | 1161 Figure 6: Second Example Flow for a Firmware Upate. 1163 10. IANA Considerations 1165 This document does not require any actions by IANA. 1167 11. Security Considerations 1169 Firmware updates fix security vulnerabilities and are considered to 1170 be an important building block in securing IoT devices. Due to the 1171 importance of firmware updates for IoT devices the Internet 1172 Architecture Board (IAB) organized a 'Workshop on Internet of Things 1173 (IoT) Software Update (IOTSU)', which took place at Trinity College 1174 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 1175 the big picture. A report about this workshop can be found at 1176 [RFC8240]. A standardized firmware manifest format providing end-to- 1177 end security from the author to the device will be specified in a 1178 separate document. 1180 There are, however, many other considerations raised during the 1181 workshop. Many of them are outside the scope of standardization 1182 organizations since they fall into the realm of product engineering, 1183 regulatory frameworks, and business models. The following 1184 considerations are outside the scope of this document, namely 1186 - installing firmware updates in a robust fashion so that the update 1187 does not break the device functionality of the environment this 1188 device operates in. 1190 - installing firmware updates in a timely fashion considering the 1191 complexity of the decision making process of updating devices, 1192 potential re-certification requirements, and the need for user 1193 consent to install updates. 1195 - the distribution of the actual firmware update, potentially in an 1196 efficient manner to a large number of devices without human 1197 involvement. 1199 - energy efficiency and battery lifetime considerations. 1201 - key management required for verifying the digital signature 1202 protecting the manifest. 1204 - incentives for manufacturers to offer a firmware update mechanism 1205 as part of their IoT products. 1207 12. Acknowledgements 1209 We would like to thank the following persons for their feedback: 1211 - Geraint Luff 1213 - Amyas Phillips 1215 - Dan Ros 1217 - Thomas Eichinger 1219 - Michael Richardson 1221 - Emmanuel Baccelli 1223 - Ned Smith 1225 - Jim Schaad 1227 - Carsten Bormann 1229 - Cullen Jennings 1231 - Olaf Bergmann 1233 - Suhas Nandakumar 1235 - Phillip Hallam-Baker 1237 - Marti Bolivar 1239 - Andrzej Puzdrowski 1240 - Markus Gueller 1242 - Henk Birkholz 1244 - Jintao Zhu 1246 - Takeshi Takahashi 1248 - Jacob Beningo 1250 - Kathleen Moriarty 1252 We would also like to thank the WG chairs, Russ Housley, David 1253 Waltermire, Dave Thaler for their support and their reviews. 1255 13. Informative References 1257 [I-D.ietf-suit-information-model] 1258 Moran, B., Tschofenig, H., and H. Birkholz, "An 1259 Information Model for Firmware Updates in IoT Devices", 1260 draft-ietf-suit-information-model-07 (work in progress), 1261 June 2020. 1263 [I-D.ietf-suit-manifest] 1264 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1265 "A Concise Binary Object Representation (CBOR)-based 1266 Serialization Format for the Software Updates for Internet 1267 of Things (SUIT) Manifest", draft-ietf-suit-manifest-09 1268 (work in progress), July 2020. 1270 [I-D.ietf-teep-architecture] 1271 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1272 "Trusted Execution Environment Provisioning (TEEP) 1273 Architecture", draft-ietf-teep-architecture-12 (work in 1274 progress), July 2020. 1276 [LwM2M] OMA, ., "Lightweight Machine to Machine Technical 1277 Specification, Version 1.0.2", February 2018, 1278 . 1282 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1283 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1284 2010, . 1286 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1287 Constrained-Node Networks", RFC 7228, 1288 DOI 10.17487/RFC7228, May 2014, 1289 . 1291 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1292 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1293 . 1295 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 1296 of Things Software Update (IoTSU) Workshop 2016", 1297 RFC 8240, DOI 10.17487/RFC8240, September 2017, 1298 . 1300 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1301 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1302 May 2018, . 1304 [RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature 1305 Algorithm with CBOR Object Signing and Encryption (COSE)", 1306 RFC 8778, DOI 10.17487/RFC8778, April 2020, 1307 . 1309 Authors' Addresses 1311 Brendan Moran 1312 Arm Limited 1314 EMail: Brendan.Moran@arm.com 1316 Hannes Tschofenig 1317 Arm Limited 1319 EMail: hannes.tschofenig@arm.com 1321 David Brown 1322 Linaro 1324 EMail: david.brown@linaro.org 1326 Milosch Meriac 1327 Consultant 1329 EMail: milosch@meriac.com