idnits 2.17.1 draft-ietf-suit-architecture-15.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 18, 2021) is 1184 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-suit-manifest' is defined on line 1227, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-suit-information-model-08 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-11 == Outdated reference: A later version (-19) 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 22, 2021 D. Brown 6 Linaro 7 M. Meriac 8 Consultant 9 January 18, 2021 11 A Firmware Update Architecture for Internet of Things 12 draft-ietf-suit-architecture-15 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 July 22, 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 . . . . . . . . . . . . . 7 66 3.3. Use state-of-the-art security mechanisms . . . . . . . . 8 67 3.4. Rollback attacks must be prevented . . . . . . . . . . . 8 68 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 10 74 3.11. Suitability to software and personalization data . . . . 12 75 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Communication Architecture . . . . . . . . . . . . . . . . . 13 77 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 18 79 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 18 80 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 18 81 7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 18 82 7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 18 83 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 88 13. Informative References . . . . . . . . . . . . . . . . . . . 27 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 91 1. Introduction 93 When developing Internet of Things (IoT) devices, one of the most 94 difficult problems to solve is how to update firmware on the device. 95 Once the device is deployed, firmware updates play a critical part in 96 its lifetime, particularly when devices have a long lifetime, are 97 deployed in remote or inaccessible areas where manual intervention is 98 cost prohibitive or otherwise difficult. Updates to the firmware of 99 an IoT device are done to fix bugs in software, to add new 100 functionality, and to re-configure the device to work in new 101 environments or to behave differently in an already deployed context. 103 The firmware update process, among other goals, has to ensure that 105 - The firmware image is authenticated and integrity protected. 106 Attempts to flash a modified firmware image or an image from an 107 unknown source are prevented. 109 - The firmware image can be confidentiality protected so that 110 attempts by an adversary to recover the plaintext binary can be 111 prevented. Obtaining the firmware is often one of the first steps 112 to mount an attack since it gives the adversary valuable insights 113 into used software libraries, configuration settings and generic 114 functionality (even though reverse engineering the binary can be a 115 tedious process). 117 This version of the document assumes asymmetric cryptography and a 118 public key infrastructure. Future versions may also describe a 119 symmetric key approach for very constrained devices. 121 While the standardization work has been informed by and optimised for 122 firmware update use cases of Class 1 devices (according to the device 123 class definitions in RFC 7228 [RFC7228]), there is nothing in the 124 architecture that restricts its use to only these constrained IoT 125 devices. Software update and delivery of arbitrary data, such as 126 configuration information and keys, can equally be managed by 127 manifests. 129 More details about the security goals are discussed in Section 5 and 130 requirements are described in Section 3. 132 2. Conventions and Terminology 134 This document uses the following terms: 136 - Manifest: The manifest contains meta-data about the firmware 137 image. The manifest is protected against modification and 138 provides information about the author. 140 - Firmware Image: The firmware image, or image, is a binary that may 141 contain the complete software of a device or a subset of it. The 142 firmware image may consist of multiple images, if the device 143 contains more than one microcontroller. Often it is also a 144 compressed archive that contains code, configuration data, and 145 even the entire file system. The image may consist of a 146 differential update for performance reasons. Firmware is the more 147 universal term. The terms, firmware image, firmware, and image, 148 are used in this document and are interchangeable. 150 - Software: The terms "software" and "firmware" are used 151 interchangeably. 153 - Bootloader: A bootloader is a piece of software that is executed 154 once a microcontroller has been reset. It is responsible for 155 deciding whether to boot a firmware image that is present or 156 whether to obtain and verify a new firmware image. Since the 157 bootloader is a security critical component its functionality may 158 be split into separate stages. Such a multi-stage bootloader may 159 offer very basic functionality in the first stage and resides in 160 ROM whereas the second stage may implement more complex 161 functionality and resides in flash memory so that it can be 162 updated in the future (in case bugs have been found). The exact 163 split of components into the different stages, the number of 164 firmware images stored by an IoT device, and the detailed 165 functionality varies throughout different implementations. A more 166 detailed discussion is provided in Section 8. 168 - Microcontroller (MCU for microcontroller unit): An MCU is a 169 compact integrated circuit designed for use in embedded systems. 170 A typical microcontroller includes a processor, memory (RAM and 171 flash), input/output (I/O) ports and other features connected via 172 some bus on a single chip. The term 'system on chip (SoC)' is 173 often used for these types of devices. 175 - System on Chip (SoC): An SoC is an integrated circuit that 176 integrates all components of a computer, such as CPU, memory, 177 input/output ports, secondary storage, etc. 179 - Homogeneous Storage Architecture (HoSA): A device that stores all 180 firmware components in the same way, for example in a file system 181 or in flash memory. 183 - Heterogeneous Storage Architecture (HeSA): A device that stores at 184 least one firmware component differently from the rest, for 185 example a device with an external, updatable radio, or a device 186 with internal and external flash memory. 188 - Trusted Execution Environments (TEEs): An execution environment 189 that runs alongside of, but is isolated from, an REE. 191 - Rich Execution Environment (REE): An environment that is provided 192 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 193 potentially in conjunction with other supporting operating systems 194 and hypervisors; it is outside of the TEE. This environment and 195 applications running on it are considered un-trusted. 197 - Trusted applications (TAs): An application component that runs in 198 a TEE. 200 For more information about TEEs see [I-D.ietf-teep-architecture]. 202 The following entities are used: 204 - Author: The author is the entity that creates the firmware image. 205 There may be multiple authors in a system either when a device 206 consists of multiple micro-controllers or when the the final 207 firmware image consists of software components from multiple 208 companies. 210 - Firmware Consumer: The firmware consumer is the recipient of the 211 firmware image and the manifest. It is responsible for parsing 212 and verifying the received manifest and for storing the obtained 213 firmware image. The firmware consumer plays the role of the 214 update component on the IoT device typically running in the 215 application firmware. It interacts with the firmware server and 216 with the status tracker, if present. 218 - (IoT) Device: A device refers to the entire IoT product, which 219 consists of one or many MCUs, sensors and/or actuators. Many IoT 220 devices sold today contain multiple MCUs and therefore a single 221 device may need to obtain more than one firmware image and 222 manifest to succesfully perform an update. The terms device and 223 firmware consumer are used interchangably since the firmware 224 consumer is one software component running on an MCU on the 225 device. 227 - Status Tracker: The status tracker offers device management 228 functionality to retrieve information about the installed firmware 229 on a device and other device characteristics (including free 230 memory and hardware components), to obtain the state of the 231 firmware update cycle the device is currently in, and to trigger 232 the update process. The deployment of status trackers is flexible 233 and they may be used as cloud-based servers, on-premise servers, 234 embedded in edge computing device (such as Internet access 235 gateways or protocol translation gateways), or even in smart 236 phones and tablets. While the IoT device itself runs the client- 237 side of the status tracker it will most likely not run a status 238 tracker itself unless it acts as a proxy for other IoT devices in 239 a protocol translation or edge computing device node. How much 240 functionality a status tracker includes depends on the selected 241 configuration of the device management functionality and the 242 communication environment it is used in. In a generic networking 243 environment the protocol used between the client and the server- 244 side of the status tracker need to deal with Internet 245 communication challenges involving firewall and NAT traversal. In 246 other cases, the communication interaction may be rather simple. 247 This architecture document does not impose requirements on the 248 status tracker. 250 - Firmware Server: The firmware server stores firmware images and 251 manifests and distributes them to IoT devices. Some deployments 252 may require a store-and-forward concept, which requires storing 253 the firmware images/manifests on more than one entity before 254 they reach the device. There is typically some interaction 255 between the firmware server and the status tracker but those 256 entities are often physically separated on different devices for 257 scalability reasons. 259 - Device Operator: The actor responsible for the day-to-day 260 operation of a fleet of IoT devices. 262 - Network Operator: The actor responsible for the operation of a 263 network to which IoT devices connect. 265 In addition to the entities in the list above there is an orthogonal 266 infrastructure with a Trust Provisioning Authority (TPA) distributing 267 trust anchors and authorization permissions to various entities in 268 the system. The TPA may also delegate rights to install, update, 269 enhance, or delete trust anchors and authorization permissions to 270 other parties in the system. This infrastructure overlaps the 271 communication architecture and different deployments may empower 272 certain entities while other deployments may not. For example, in 273 some cases, the Original Design Manufacturer (ODM), which is a 274 company that designs and manufactures a product, may act as a TPA and 275 may decide to remain in full control over the firmware update process 276 of their products. 278 The terms 'trust anchor' and 'trust anchor store' are defined in 279 [RFC6024]: 281 - "A trust anchor represents an authoritative entity via a public 282 key and associated data. The public key is used to verify digital 283 signatures, and the associated data is used to constrain the types 284 of information for which the trust anchor is authoritative." 286 - "A trust anchor store is a set of one or more trust anchors stored 287 in a device. A device may have more than one trust anchor store, 288 each of which may be used by one or more applications." A trust 289 anchor store must resist modification against unauthorized 290 insertion, deletion, and modification. 292 3. Requirements 294 The firmware update mechanism described in this specification was 295 designed with the following requirements in mind: 297 - Agnostic to how firmware images are distributed 299 - Friendly to broadcast delivery 301 - Use state-of-the-art security mechanisms 303 - Rollback attacks must be prevented 305 - High reliability 307 - Operate with a small bootloader 309 - Small Parsers 311 - Minimal impact on existing firmware formats 313 - Robust permissions 315 - Diverse modes of operation 317 - Suitability to software and personalization data 319 3.1. Agnostic to how firmware images are distributed 321 Firmware images can be conveyed to devices in a variety of ways, 322 including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and 323 use different protocols (e.g., CoAP, HTTP). The specified mechanism 324 needs to be agnostic to the distribution of the firmware images and 325 manifests. 327 3.2. Friendly to broadcast delivery 329 This architecture does not specify any specific broadcast protocol. 330 However, given that broadcast may be desirable for some networks, 331 updates must cause the least disruption possible both in metadata and 332 firmware transmission. 334 For an update to be broadcast friendly, it cannot rely on link layer, 335 network layer, or transport layer security. A solution has to rely 336 on security protection applied to the manifest and firmware image 337 instead. In addition, the same manifest must be deliverable to many 338 devices, both those to which it applies and those to which it does 339 not, without a chance that the wrong device will accept the update. 340 Considerations that apply to network broadcasts apply equally to the 341 use of third-party content distribution networks for payload 342 distribution. 344 3.3. Use state-of-the-art security mechanisms 346 End-to-end security between the author and the device is shown in 347 Section 5. 349 Authentication ensures that the device can cryptographically identify 350 the author(s) creating firmware images and manifests. Authenticated 351 identities may be used as input to the authorization process. 353 Integrity protection ensures that no third party can modify the 354 manifest or the firmware image. 356 For confidentiality protection of the firmware image, it must be done 357 in such a way that every intended recipient can decrypt it. The 358 information that is encrypted individually for each device must 359 maintain friendliness to Content Distribution Networks, bulk storage, 360 and broadcast protocols. 362 A manifest specification must support different cryptographic 363 algorithms and algorithm extensibility. Due of the nature of 364 unchangeable code in ROM for use with bootloaders the use of post- 365 quantum secure signature mechanisms, such as hash-based signatures 366 [RFC8778], are attractive. These algorithms maintain security in 367 presence of quantum computers. 369 A mandatory-to-implement set of algorithms will be specified in the 370 manifest specification [I-D.ietf-suit-manifest]}. 372 3.4. Rollback attacks must be prevented 374 A device presented with an old, but valid manifest and firmware must 375 not be tricked into installing such firmware since a vulnerability in 376 the old firmware image may allow an attacker to gain control of the 377 device. 379 3.5. High reliability 381 A power failure at any time must not cause a failure of the device. 382 A failure to validate any part of an update must not cause a failure 383 of the device. One way to achieve this functionality is to provide a 384 minimum of two storage locations for firmware and one bootable 385 location for firmware. An alternative approach is to use a 2nd stage 386 bootloader with build-in full featured firmware update functionality 387 such that it is possible to return to the update process after power 388 down. 390 Note: This is an implementation requirement rather than a requirement 391 on the manifest format. 393 3.6. Operate with a small bootloader 395 Throughout this document we assume that the bootloader itself is 396 distinct from the role of the firmware consumer and therefore does 397 not manage the firmware update process. This may give the impression 398 that the bootloader itself is a completely separate component, which 399 is mainly responsible for selecting a firmware image to boot. 401 The overlap between the firmware update process and the bootloader 402 functionality comes in two forms, namely 404 - First, a bootloader must verify the firmware image it boots as 405 part of the secure boot process. Doing so requires meta-data to 406 be stored alongside the firmware image so that the bootloader can 407 cryptographically verify the firmware image before booting it to 408 ensure it has not been tampered with or replaced. This meta-data 409 used by the bootloader may well be the same manifest obtained with 410 the firmware image during the update process (with the severable 411 fields stripped off). 413 - Second, an IoT device needs a recovery strategy in case the 414 firmware update / boot process fails. The recovery strategy may 415 include storing two or more firmware images on the device or 416 offering the ability to have a second stage bootloader perform the 417 firmware update process again using firmware updates over serial, 418 USB or even wireless connectivity like a limited version of 419 Bluetooth Smart. In the latter case the firmware consumer 420 functionality is contained in the second stage bootloader and 421 requires the necessary functionality for executing the firmware 422 update process, including manifest parsing. 424 In general, it is assumed that the bootloader itself, or a minimal 425 part of it, will not be updated since a failed update of the 426 bootloader poses a risk in reliability. 428 All information necessary for a device to make a decision about the 429 installation of a firmware update must fit into the available RAM of 430 a constrained IoT device. This prevents flash write exhaustion. 431 This is typically not a difficult requirement to accomplish because 432 there are not other task/processing running while the bootloader is 433 active (unlike it may be the case when running the application 434 firmware). 436 Note: This is an implementation requirement. 438 3.7. Small Parsers 440 Since parsers are known sources of bugs they must be minimal. 441 Additionally, it must be easy to parse only those fields that are 442 required to validate at least one signature or MAC with minimal 443 exposure. 445 3.8. Minimal impact on existing firmware formats 447 The design of the firmware update mechanism must not require changes 448 to existing firmware formats. 450 3.9. Robust permissions 452 When a device obtains a monolithic firmware image from a single 453 author without any additional approval steps then the authorization 454 flow is relatively simple. There are, however, other cases where 455 more complex policy decisions need to be made before updating a 456 device. 458 In this architecture the authorization policy is separated from the 459 underlying communication architecture. This is accomplished by 460 separating the entities from their permissions. For example, an 461 author may not have the authority to install a firmware image on a 462 device in critical infrastructure without the authorization of a 463 device operator. In this case, the device may be programmed to 464 reject firmware updates unless they are signed both by the firmware 465 author and by the device operator. 467 Alternatively, a device may trust precisely one entity, which does 468 all permission management and coordination. This entity allows the 469 device to offload complex permissions calculations for the device. 471 3.10. Operating modes 473 There are three broad classifications of update operating modes. 475 - Client-initiated Update 477 - Server-initiated Update 479 - Hybrid Update 480 Client-initiated updates take the form of a firmware consumer on a 481 device proactively checking (polling) for new firmware images. 483 Server-initiated updates are important to consider because timing of 484 updates may need to be tightly controlled in some high- reliability 485 environments. In this case the status tracker determines what 486 devices qualify for a firmware update. Once those devices have been 487 selected the firmware server distributes updates to the firmware 488 consumers. 490 Note: This assumes that the status tracker is able to reach the 491 device, which may require devices to keep reachability information at 492 the status tracker up-to-date. This may also require keeping state 493 at NATs and stateful packet filtering firewalls alive. 495 Hybrid updates are those that require an interaction between the 496 firmware consumer and the status tracker. The status tracker pushes 497 notifications of availability of an update to the firmware consumer, 498 and it then downloads the image from a firmware server as soon as 499 possible. 501 An alternative view to the operating modes is to consider the steps a 502 device has to go through in the course of an update: 504 - Notification 506 - Pre-authorisation 508 - Dependency resolution 510 - Download 512 - Installation 514 The notification step consists of the status tracker informing the 515 firmware consumer that an update is available. This can be 516 accomplished via polling (client-initiated), push notifications 517 (server-initiated), or more complex mechanisms. 519 The pre-authorisation step involves verifying whether the entity 520 signing the manifest is indeed authorized to perform an update. The 521 firmware consumer must also determine whether it should fetch and 522 process a firmware image, which is referenced in a manifest. 524 A dependency resolution phase is needed when more than one component 525 can be updated or when a differential update is used. The necessary 526 dependencies must be available prior to installation. 528 The download step is the process of acquiring a local copy of the 529 firmware image. When the download is client-initiated, this means 530 that the firmware consumer chooses when a download occurs and 531 initiates the download process. When a download is server-initiated, 532 this means that the status tracker tells the device when to download 533 or that it initiates the transfer directly to the firmware consumer. 534 For example, a download from an HTTP-based firmware server is client- 535 initiated. Pushing a manifest and firmware image to the transfer to 536 the Package resource of the LwM2M Firmware Update object [LwM2M] is 537 server-initiated. 539 If the firmware consumer has downloaded a new firmware image and is 540 ready to install it, it may need to wait for a trigger from the 541 status tracker to initiate the installation, may trigger the update 542 automatically, or may go through a more complex decision making 543 process to determine the appropriate timing for an update (such as 544 delaying the update process to a later time when end users are less 545 impacted by the update process). 547 Installation is the act of processing the payload into a format that 548 the IoT device can recognise and the bootloader is responsible for 549 then booting from the newly installed firmware image. 551 Each of these steps may require different permissions. 553 3.11. Suitability to software and personalization data 555 The work on a standardized manifest format initially focused on the 556 most constrained IoT devices and those devices contain code put 557 together by a single author (although that author may obtain code 558 from other developers, some of it only in binary form). 560 Later it turns out that other use cases may benefit from a 561 standardized manifest format also for conveying software and even 562 personalization data alongside software. Trusted Execution 563 Environments (TEEs), for example, greatly benefit from a protocol for 564 managing the lifecycle of trusted applications (TAs) running inside a 565 TEE. TEEs may obtain TAs from different authors and those TAs may 566 require personalization data, such as payment information, to be 567 securely conveyed to the TEE. 569 To support this wider range of use cases the manifest format should 570 therefore be extensible to convey other forms of payloads as well. 572 4. Claims 574 Claims in the manifest offer a way to convey instructions to a device 575 that impact the firmware update process. To have any value the 576 manifest containing those claims must be authenticated and integrity 577 protected. The credential used must be directly or indirectly 578 related to the trust anchor installed at the device by the Trust 579 Provisioning Authority. 581 The baseline claims for all manifests are described in 582 [I-D.ietf-suit-information-model]. For example, there are: 584 - Do not install firmware with earlier metadata than the current 585 metadata. 587 - Only install firmware with a matching vendor, model, hardware 588 revision, software version, etc. 590 - Only install firmware that is before its best-before timestamp. 592 - Only allow a firmware installation if dependencies have been met. 594 - Choose the mechanism to install the firmware, based on the type of 595 firmware it is. 597 5. Communication Architecture 599 Figure 1 shows the communication architecture where a firmware image 600 is created by an author, and uploaded to a firmware server. The 601 firmware image/manifest is distributed to the device either in a push 602 or pull manner using the firmware consumer residing on the device. 603 The device operator keeps track of the process using the status 604 tracker. This allows the device operator to know and control what 605 devices have received an update and which of them are still pending 606 an update. 608 Firmware + +----------+ Firmware + +-----------+ 609 Manifest | |-+ Manifest | |-+ 610 +--------->| Firmware | |<---------------| | | 611 | | Server | | | Author | | 612 | | | | | | | 613 | +----------+ | +-----------+ | 614 | +----------+ +-----------+ 615 | 616 | 617 | 618 -+-- ------ 619 ---- | ---- ---- ---- 620 // | \\ // \\ 621 / | \ / \ 622 / | \ / \ 623 / | \ / \ 624 / | \ / \ 625 | v | | | 626 | +------------+ | 627 | | Firmware | | | | 628 | | Consumer | | Device | +--------+ | 629 | +------------+ | Management| | | | 630 | | |<------------------------->| Status | | 631 | | Device | | | | Tracker| | 632 | +------------+ | || | | | 633 | | || +--------+ | 634 | | | | 635 | | \ / 636 \ / \ / 637 \ / \ Device / 638 \ Network / \ Operator / 639 \ Operator / \\ // 640 \\ // ---- ---- 641 ---- ---- ------ 642 ----- 644 Figure 1: Architecture. 646 End-to-end security mechanisms are used to protect the firmware image 647 and the manifest although Figure 2 does not show the manifest itself 648 since it may be distributed independently. 650 +-----------+ 651 +--------+ | | +--------+ 652 | | Firmware Image | Firmware | Firmware Image | | 653 | Device |<-----------------| Server |<------------------| Author | 654 | | | | | | 655 +--------+ +-----------+ +--------+ 656 ^ * 657 * * 658 ************************************************************ 659 End-to-End Security 661 Figure 2: End-to-End Security. 663 Whether the firmware image and the manifest is pushed to the device 664 or fetched by the device is a deployment specific decision. 666 The following assumptions are made to allow the firmware consumer to 667 verify the received firmware image and manifest before updating 668 software: 670 - To accept an update, a device needs to verify the signature 671 covering the manifest. There may be one or multiple manifests 672 that need to be validated, potentially signed by different 673 parties. The device needs to be in possession of the trust 674 anchors to verify those signatures. Installing trust anchors to 675 devices via the Trust Provisioning Authority happens in an out-of- 676 band fashion prior to the firmware update process. 678 - Not all entities creating and signing manifests have the same 679 permissions. A device needs to determine whether the requested 680 action is indeed covered by the permission of the party that 681 signed the manifest. Informing the device about the permissions 682 of the different parties also happens in an out-of-band fashion 683 and is also a duty of the Trust Provisioning Authority. 685 - For confidentiality protection of firmware images the author needs 686 to be in possession of the certificate/public key or a pre-shared 687 key of a device. The use of confidentiality protection of 688 firmware images is deployment specific. 690 There are different types of delivery modes, which are illustrated 691 based on examples below. 693 There is an option for embedding a firmware image into a manifest. 694 This is a useful approach for deployments where devices are not 695 connected to the Internet and cannot contact a dedicated firmware 696 server for the firmware download. It is also applicable when the 697 firmware update happens via a USB stick or via Bluetooth Smart. 698 Figure 3 shows this delivery mode graphically. 700 /------------\ /------------\ 701 /Manifest with \ /Manifest with \ 702 |attached | |attached | 703 \firmware image/ \firmware image/ 704 \------------/ +-----------+ \------------/ 705 +--------+ | | +--------+ 706 | |<.................| Firmware |<................| | 707 | Device | | Server | | Author | 708 | | | | | | 709 +--------+ +-----------+ +--------+ 711 Figure 3: Manifest with attached firmware. 713 Figure 4 shows an option for remotely updating a device where the 714 device fetches the firmware image from some file server. The 715 manifest itself is delivered independently and provides information 716 about the firmware image(s) to download. 718 /--------\ /--------\ 719 / \ / \ 720 | Manifest | | Manifest | 721 \ / \ / 722 \--------/ \--------/ 723 +-----------+ 724 +--------+ | | +--------+ 725 | |<.................| Status |................>| | 726 | Device | | Tracker | -- | Author | 727 | |<- | | --- | | 728 +--------+ -- +-----------+ --- +--------+ 729 -- --- 730 --- --- 731 -- +-----------+ -- 732 -- | | -- 733 /------------\ -- | Firmware |<- /------------\ 734 / \ -- | Server | / \ 735 | Firmware | | | | Firmware | 736 \ / +-----------+ \ / 737 \------------/ \------------/ 739 Figure 4: Independent retrieval of the firmware image. 741 This architecture does not mandate a specific delivery mode but a 742 solution must support both types. 744 6. Manifest 746 In order for a device to apply an update, it has to make several 747 decisions about the update: 749 - Does it trust the author of the update? 751 - Has the firmware been corrupted? 753 - Does the firmware update apply to this device? 755 - Is the update older than the active firmware? 757 - When should the device apply the update? 759 - How should the device apply the update? 761 - What kind of firmware binary is it? 763 - Where should the update be obtained? 765 - Where should the firmware be stored? 767 The manifest encodes the information that devices need in order to 768 make these decisions. It is a data structure that contains the 769 following information: 771 - information about the device(s) the firmware image is intended to 772 be applied to, 774 - information about when the firmware update has to be applied, 776 - information about when the manifest was created, 778 - dependencies on other manifests, 780 - pointers to the firmware image and information about the format, 782 - information about where to store the firmware image, 784 - cryptographic information, such as digital signatures or message 785 authentication codes (MACs). 787 The manifest information model is described in 788 [I-D.ietf-suit-information-model]. 790 7. Device Firmware Update Examples 792 Although these documents attempt to define a firmware update 793 architecture that is applicable to both existing systems, as well as 794 yet-to-be-conceived systems; it is still helpful to consider existing 795 architectures. 797 7.1. Single CPU SoC 799 The simplest, and currently most common, architecture consists of a 800 single MCU along with its own peripherals. These SoCs generally 801 contain some amount of flash memory for code and fixed data, as well 802 as RAM for working storage. These systems either have a single 803 firmware image, or an immutable bootloader that runs a single image. 804 A notable characteristic of these SoCs is that the primary code is 805 generally execute in place (XIP). Combined with the non-relocatable 806 nature of the code, firmware updates need to be done in place. 808 7.2. Single CPU with Secure - Normal Mode Partitioning 810 Another configuration consists of a similar architecture to the 811 previous, with a single CPU. However, this CPU supports a security 812 partitioning scheme that allows memory (in addition to other things) 813 to be divided into secure and normal mode. There will generally be 814 two images, one for secure mode, and one for normal mode. In this 815 configuration, firmware upgrades will generally be done by the CPU in 816 secure mode, which is able to write to both areas of the flash 817 device. In addition, there are requirements to be able to update 818 either image independently, as well as to update them together 819 atomically, as specified in the associated manifests. 821 7.3. Dual CPU, shared memory 823 This configuration has two or more CPUs in a single SoC that share 824 memory (flash and RAM). Generally, they will be a protection 825 mechanism to prevent one CPU from accessing the other's memory. 826 Upgrades in this case will typically be done by one of the CPUs, and 827 is similar to the single CPU with secure mode. 829 7.4. Dual CPU, other bus 831 This configuration has two or more CPUs, each having their own 832 memory. There will be a communication channel between them, but it 833 will be used as a peripheral, not via shared memory. In this case, 834 each CPU will have to be responsible for its own firmware upgrade. 835 It is likely that one of the CPUs will be considered a master, and 836 will direct the other CPU to do the upgrade. This configuration is 837 commonly used to offload specific work to other CPUs. Firmware 838 dependencies are similar to the other solutions above, sometimes 839 allowing only one image to be upgraded, other times requiring several 840 to be upgraded atomically. Because the updates are happening on 841 multiple CPUs, upgrading the two images atomically is challenging. 843 8. Bootloader 845 More devices today than ever before are being connected to the 846 Internet, which drives the need for firmware updates to be provided 847 over the Internet rather than through traditional interfaces, such as 848 USB or RS232. Updating a device over the Internet requires the 849 device to fetch not only the firmware image but also the manifest. 850 Hence, the following building blocks are necessary for a firmware 851 update solution: 853 - the Internet protocol stack for firmware downloads (*), 855 - the capability to write the received firmware image to persistent 856 storage (most likely flash memory) prior to performing the update, 858 - the ability to unpack, decompress or otherwise process the 859 received firmware image, 861 - the features to verify an image and a manifest, including digital 862 signature verification or checking a message authentication code, 864 - a manifest parsing library, and 866 - integration of the device into a device management server to 867 perform automatic firmware updates and to track their progress. 869 (*) Because firmware images are often multiple kilobytes, sometimes 870 exceeding one hundred kilobytes, in size for low end IoT devices and 871 even several megabytes large for IoT devices running full-fledged 872 operating systems like Linux, the protocol mechanism for retrieving 873 these images needs to offer features like congestion control, flow 874 control, fragmentation and reassembly, and mechanisms to resume 875 interrupted or corrupted transfers. 877 All these features are most likely offered by the application, i.e. 878 firmware consumer, running on the device (except for basic security 879 algorithms that may run either on a trusted execution environment or 880 on a separate hardware security MCU/module) rather than by the 881 bootloader itself. 883 Once manifests have been processed and firmware images successfully 884 downloaded and verified the device needs to hand control over to the 885 bootloader. In most cases this requires the MCU to restart. Once 886 the MCU has initiated a restart, the bootloader takes over control 887 and determines whether the newly downloaded firmware image should be 888 executed. 890 The boot process is security sensitive because the firmware images 891 may, for example, be stored in off-chip flash memory giving attackers 892 easy access to the image for reverse engineering and potentially also 893 for modifying the binary. The bootloader will therefore have to 894 perform security checks on the firmware image before it can be 895 booted. These security checks by the bootloader happen in addition 896 to the security checks that happened when the firmware image and the 897 manifest were downloaded. 899 The manifest may have been stored alongside the firmware image to 900 allow re-verification of the firmware image during every boot 901 attempt. Alternatively, secure boot-specific meta-data may have been 902 created by the application after a successful firmware download and 903 verification process. Whether to re-use the standardized manifest 904 format that was used during the initial firmware retrieval process or 905 whether it is better to use a different format for the secure boot- 906 specific meta-data depends on the system design. The manifest format 907 does, however, have the capability to serve also as a building block 908 for secure boot with its severable elements that allow shrinking the 909 size of the manifest by stripping elements that are no longer needed. 911 If the application image contains the firmware consumer 912 functionality, as described above, then it is necessary that a 913 working image is left on the device. This allows the bootloader to 914 roll back to a working firmware image to execute a firmware download 915 if the bootloader itself does not have enough functionality to fetch 916 a firmware image plus manifest from a firmware server over the 917 Internet. A multi-stage bootloader may soften this requirement at 918 the expense of a more sophisticated boot process. 920 For a bootloader to offer a secure boot mechanism it needs to provide 921 the following features: 923 - ability to access security algorithms, such as SHA-256 to compute 924 a fingerprint over the firmware image and a digital signature 925 algorithm. 927 - access keying material directly or indirectly to utilize the 928 digital signature. The device needs to have a trust anchor store. 930 - ability to expose boot process-related data to the application 931 firmware (such as to the device management software). This allows 932 a device management server to determine whether the firmware 933 update has been successful and, if not, what errors occurred. 935 - to (optionally) offer attestation information (such as 936 measurements). 938 While the software architecture of the bootloader and its security 939 mechanisms are implementation-specific, the manifest can be used to 940 control the firmware download from the Internet in addition to 941 augmenting secure boot process. These building blocks are highly 942 relevant for the design of the manifest. 944 9. Example 946 Figure 5 illustrates an example message flow for distributing a 947 firmware image to a device starting with an author uploading the new 948 firmware to firmware server and creating a manifest. The firmware 949 and manifest are stored on the same firmware server. This setup does 950 not use a status tracker and the firmware consumer component is 951 therefore responsible for periodically checking whether a new 952 firmware image is available for download. 954 +--------+ +-----------------+ +------------+ +----------+ 955 | | | | | Firmware | | | 956 | Author | | Firmware Server | | Consumer | |Bootloader| 957 +--------+ +-----------------+ +------------+ +----------+ 958 | | | + 959 | Create Firmware | | | 960 |--------------+ | | | 961 | | | | | 962 |<-------------+ | | | 963 | | | | 964 | Upload Firmware | | | 965 |------------------>| | | 966 | | | | 967 | Create Manifest | | | 968 |---------------+ | | | 969 | | | | | 970 |<--------------+ | | | 971 | | | | 972 | Sign Manifest | | | 973 |-------------+ | | | 974 | | | | | 975 |<------------+ | | | 976 | | | | 977 | Upload Manifest | | | 978 |------------------>| | | 979 | | | | 980 | | Query Manifest | | 981 | |<--------------------| | 982 | | | | 983 | | Send Manifest | | 984 | |-------------------->| | 985 | | | Validate | 986 | | | Manifest | 987 | | |---------+ | 988 | | | | | 989 | | |<--------+ | 990 | | | | 991 | | Request Firmware | | 992 | |<--------------------| | 993 | | | | 994 | | Send Firmware | | 995 | |-------------------->| | 996 | | | Verify | 997 | | | Firmware | 998 | | |--------------+ | 999 | | | | | 1000 | | |<-------------+ | 1001 | | | | 1002 | | | Store | 1003 | | | Firmware | 1004 | | |-------------+ | 1005 | | | | | 1006 | | |<------------+ | 1007 | | | | 1008 | | | | 1009 | | | Trigger Reboot | 1010 | | |--------------->| 1011 | | | | 1012 | | | | 1013 | | +---+----------------+--+ 1014 | | S| | | | 1015 | | E| | Verify | | 1016 | | C| | Firmware | | 1017 | | U| | +--------------| | 1018 | | R| | | | | 1019 | | E| | +------------->| | 1020 | | | | | | 1021 | | B| | Activate new | | 1022 | | O| | Firmware | | 1023 | | O| | +--------------| | 1024 | | T| | | | | 1025 | | | | +------------->| | 1026 | | P| | | | 1027 | | R| | Boot new | | 1028 | | O| | Firmware | | 1029 | | C| | +--------------| | 1030 | | E| | | | | 1031 | | S| | +------------->| | 1032 | | S| | | | 1033 | | +---+----------------+--+ 1034 | | | | 1036 Figure 5: First Example Flow for a Firmware Upate. 1038 Figure 6 shows an example follow with the device using a status 1039 tracker. For editorial reasons the author publishing the manifest at 1040 the status tracker and the firmware image at the firmware server is 1041 not shown. Also omitted is the secure boot process following the 1042 successful firmware update process. 1044 The exchange starts with the device interacting with the status 1045 tracker; the details of such exchange will vary with the different 1046 device management systems being used. In any case, the status 1047 tracker learns about the firmware version of the devices it manages. 1048 In our example, the device under management is using firmware version 1049 A.B.C. At a later point in time the author uploads a new firmware 1050 along with the manifest to the firmware server and the status 1051 tracker, respectively. While there is no need to store the manifest 1052 and the firmware on different servers this example shows a common 1053 pattern used in the industry. The status tracker may then 1054 automatically, based on human intervention or based on a more complex 1055 policy decide to inform the device about the newly available firmware 1056 image. In our example, it does so by pushing the manifest to the 1057 firmware consumer. The firmware consumer downloads the firmware 1058 image with the newer version X.Y.Z after successful validation of the 1059 manifest. Subsequently, a reboot is initiated and the secure boot 1060 process starts. 1062 +---------+ +-----------------+ +-----------------------------+ 1063 | Status | | | | +------------+ +----------+ | 1064 | Tracker | | Firmware Server | | | Firmware | |Bootloader| | 1065 | | | | | | Consumer | | | | 1066 +---------+ +-----------------+ | +------------+ +----------+ | 1067 | | | | IoT Device | | 1068 | | `'''''''''''''''''''''''''''' 1069 | | | | 1070 | Query Firmware Version | | 1071 |------------------------------------->| | 1072 | Firmware Version A.B.C | | 1073 |<-------------------------------------| | 1074 | | | | 1075 | <> | | 1076 | | | | 1077 _,...._ _,...._ | | 1078 ,' `. ,' `. | | 1080 | New | | New | | | 1081 \ Manifest / \ Firmware / | | 1082 `.._ _,,' `.._ _,,' | | 1083 `'' `'' | | 1084 | Push manifest | | 1085 |----------------+-------------------->| | 1086 | | | | 1087 | ' | ' 1088 | | | Validate | 1089 | | | Manifest | 1090 | | |---------+ | 1091 | | | | | 1092 | | |<--------+ | 1093 | | Request firmware | | 1094 | | X.Y.Z | | 1095 | |<--------------------| | 1096 | | | | 1097 | | Firmware X.Y.Z | | 1098 | |-------------------->| | 1099 | | | | 1100 | | | Verify | 1101 | | | Firmware | 1102 | | |--------------+ | 1103 | | | | | 1104 | | |<-------------+ | 1105 | | | | 1106 | | | Store | 1107 | | | Firmware | 1108 | | |-------------+ | 1109 | | | | | 1110 | | |<------------+ | 1111 | | | | 1112 | | | | 1113 | | | Trigger Reboot | 1114 | | |--------------->| 1115 | | | | 1116 | | | | 1117 | | | __..-------..._' 1118 | | ,-' `-. 1119 | | | Secure Boot | 1120 | | `-. _/ 1121 | | |`--..._____,,.,-' 1122 | | | | 1124 Figure 6: Second Example Flow for a Firmware Upate. 1126 10. IANA Considerations 1128 This document does not require any actions by IANA. 1130 11. Security Considerations 1132 Firmware updates fix security vulnerabilities and are considered to 1133 be an important building block in securing IoT devices. Due to the 1134 importance of firmware updates for IoT devices the Internet 1135 Architecture Board (IAB) organized a 'Workshop on Internet of Things 1136 (IoT) Software Update (IOTSU)', which took place at Trinity College 1137 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 1138 the big picture. A report about this workshop can be found at 1139 [RFC8240]. A standardized firmware manifest format providing end-to- 1140 end security from the author to the device will be specified in a 1141 separate document. 1143 There are, however, many other considerations raised during the 1144 workshop. Many of them are outside the scope of standardization 1145 organizations since they fall into the realm of product engineering, 1146 regulatory frameworks, and business models. The following 1147 considerations are outside the scope of this document, namely 1149 - installing firmware updates in a robust fashion so that the update 1150 does not break the device functionality of the environment this 1151 device operates in. 1153 - installing firmware updates in a timely fashion considering the 1154 complexity of the decision making process of updating devices, 1155 potential re-certification requirements, and the need for user 1156 consent to install updates. 1158 - the distribution of the actual firmware update, potentially in an 1159 efficient manner to a large number of devices without human 1160 involvement. 1162 - energy efficiency and battery lifetime considerations. 1164 - key management required for verifying the digital signature 1165 protecting the manifest. 1167 - incentives for manufacturers to offer a firmware update mechanism 1168 as part of their IoT products. 1170 12. Acknowledgements 1172 We would like to thank the following persons for their feedback: 1174 - Geraint Luff 1176 - Amyas Phillips 1178 - Dan Ros 1180 - Thomas Eichinger 1182 - Michael Richardson 1184 - Emmanuel Baccelli 1186 - Ned Smith 1188 - Jim Schaad 1190 - Carsten Bormann 1192 - Cullen Jennings 1194 - Olaf Bergmann 1196 - Suhas Nandakumar 1198 - Phillip Hallam-Baker 1200 - Marti Bolivar 1202 - Andrzej Puzdrowski 1204 - Markus Gueller 1206 - Henk Birkholz 1208 - Jintao Zhu 1210 - Takeshi Takahashi 1212 - Jacob Beningo 1214 - Kathleen Moriarty 1216 We would also like to thank the WG chairs, Russ Housley, David 1217 Waltermire, Dave Thaler for their support and their reviews. 1219 13. Informative References 1221 [I-D.ietf-suit-information-model] 1222 Moran, B., Tschofenig, H., and H. Birkholz, "An 1223 Information Model for Firmware Updates in IoT Devices", 1224 draft-ietf-suit-information-model-08 (work in progress), 1225 October 2020. 1227 [I-D.ietf-suit-manifest] 1228 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1229 "A Concise Binary Object Representation (CBOR)-based 1230 Serialization Format for the Software Updates for Internet 1231 of Things (SUIT) Manifest", draft-ietf-suit-manifest-11 1232 (work in progress), December 2020. 1234 [I-D.ietf-teep-architecture] 1235 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1236 "Trusted Execution Environment Provisioning (TEEP) 1237 Architecture", draft-ietf-teep-architecture-13 (work in 1238 progress), November 2020. 1240 [LwM2M] OMA, ., "Lightweight Machine to Machine Technical 1241 Specification, Version 1.0.2", February 2018, 1242 . 1246 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1247 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1248 2010, . 1250 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1251 Constrained-Node Networks", RFC 7228, 1252 DOI 10.17487/RFC7228, May 2014, 1253 . 1255 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 1256 of Things Software Update (IoTSU) Workshop 2016", 1257 RFC 8240, DOI 10.17487/RFC8240, September 2017, 1258 . 1260 [RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature 1261 Algorithm with CBOR Object Signing and Encryption (COSE)", 1262 RFC 8778, DOI 10.17487/RFC8778, April 2020, 1263 . 1265 Authors' Addresses 1267 Brendan Moran 1268 Arm Limited 1270 EMail: Brendan.Moran@arm.com 1272 Hannes Tschofenig 1273 Arm Limited 1275 EMail: hannes.tschofenig@arm.com 1277 David Brown 1278 Linaro 1280 EMail: david.brown@linaro.org 1282 Milosch Meriac 1283 Consultant 1285 EMail: milosch@meriac.com