idnits 2.17.1 draft-ietf-suit-architecture-05.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 09, 2019) is 1815 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1085 -- Looks like a reference, but probably isn't: '2' on line 1087 -- Looks like a reference, but probably isn't: '3' on line 1089 == Outdated reference: A later version (-13) exists of draft-ietf-suit-information-model-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft Arm Limited 4 Intended status: Informational M. Meriac 5 Expires: October 11, 2019 Consultant 6 H. Tschofenig 7 Arm Limited 8 D. Brown 9 Linaro 10 April 09, 2019 12 A Firmware Update Architecture for Internet of Things Devices 13 draft-ietf-suit-architecture-05 15 Abstract 17 Vulnerabilities with Internet of Things (IoT) devices have raised the 18 need for a solid and secure firmware update mechanism that is also 19 suitable for constrained devices. Incorporating such update 20 mechanism to fix vulnerabilities, to update configuration settings as 21 well as adding new functionality is recommended by security experts. 23 This document lists requirements and describes an architecture for a 24 firmware update mechanism suitable for IoT devices. The architecture 25 is agnostic to the transport of the firmware images and associated 26 meta-data. 28 This version of the document assumes asymmetric cryptography and a 29 public key infrastructure. Future versions may also describe a 30 symmetric key approach for very constrained devices. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 11, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 80 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.1. Agnostic to how firmware images are distributed . . . . . 7 82 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7 83 3.3. Use state-of-the-art security mechanisms . . . . . . . . 7 84 3.4. Rollback attacks must be prevented . . . . . . . . . . . 8 85 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8 86 3.6. Operate with a small bootloader . . . . . . . . . . . . . 8 87 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 9 88 3.8. Minimal impact on existing firmware formats . . . . . . . 9 89 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 9 90 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9 91 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 5. Communication Architecture . . . . . . . . . . . . . . . . . 12 93 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 17 95 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 17 96 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 17 97 7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 17 98 7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17 99 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 103 12. Mailing List Information . . . . . . . . . . . . . . . . . . 22 104 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 107 14.2. Informative References . . . . . . . . . . . . . . . . . 24 108 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 111 1. Introduction 113 When developing IoT devices, one of the most difficult problems to 114 solve is how to update the firmware on the device. Once the device 115 is deployed, firmware updates play a critical part in its lifetime, 116 particularly when devices have a long lifetime, are deployed in 117 remote or inaccessible areas where manual intervention is cost 118 prohibitive or otherwise difficult. Updates to the firmware of an 119 IoT device are done to fix bugs in software, to add new 120 functionality, and to re-configure the device to work in new 121 environments or to behave differently in an already deployed context. 123 The firmware update process, among other goals, has to ensure that 125 - The firmware image is authenticated and integrity protected. 126 Attempts to flash a modified firmware image or an image from an 127 unknown source are prevented. 129 - The firmware image can be confidentiality protected so that 130 attempts by an adversary to recover the plaintext binary can be 131 prevented. Obtaining the firmware is often one of the first steps 132 to mount an attack since it gives the adversary valuable insights 133 into used software libraries, configuration settings and generic 134 functionality (even though reverse engineering the binary can be a 135 tedious process). 137 More details about the security goals are discussed in Section 5 and 138 requirements are described in Section 3. 140 2. Conventions and Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in RFC 145 2119 [RFC2119]. 147 This document uses the following terms: 149 - Manifest: The manifest contains meta-data about the firmware 150 image. The manifest is protected against modification and 151 provides information about the author. 153 - Firmware Image: The firmware image is a binary that may contain 154 the complete software of a device or a subset of it. The firmware 155 image may consist of multiple images, if the device contains more 156 than one microcontroller. The image may consist of a differential 157 update for performance reasons. Firmware is the more universal 158 term. Both terms are used in this document and are 159 interchangeable. 161 - Bootloader: A bootloader is a piece of software that is executed 162 once a microcontroller has been reset. It is responsible for 163 deciding whether to boot a firmware image that is present or 164 whether to obtain and verify a new firmware image. Since the 165 bootloader is a security critical component its functionality may 166 be split into separate stages. Such a multi-stage bootloader may 167 offer very basic functionality in the first stage and resides in 168 ROM whereas the second stage may implement more complex 169 functionality and resides in flash memory so that it can be 170 updated in the future (in case bugs have been found). The exact 171 split of components into the different stages, the number of 172 firmware images stored by an IoT device, and the detailed 173 functionality varies throughout different implementations. A more 174 detailed discussion is provided in Section 8. 176 - Microcontroller (MCU for microcontroller unit): An MCU is a 177 compact integrated circuit designed for use in embedded systems. 178 A typical microcontroller includes a processor, memory (RAM and 179 flash), input/output (I/O) ports and other features connected via 180 some bus on a single chip. The term 'system on chip (SoC)' is 181 often used for these types of devices. 183 - System on Chip (SoC): An SoC is an integrated circuit that 184 integrates all components of a computer, such as CPU, memory, 185 input/output ports, secondary storage, etc. 187 - Homogeneous Storage Architecture (HoSA): A device that stores all 188 firmware components in the same way, for example in a file system 189 or in flash memory. 191 - Heterogeneous Storage Architecture (HeSA): A device that stores at 192 least one firmware component differently from the rest, for 193 example a device with an external, updatable radio, or a device 194 with internal and external flash memory. 196 The following entities are used: 198 - Author: The author is the entity that creates the firmware image. 199 There may be multiple authors in a system either when a device 200 consists of multiple micro-controllers or when the the final 201 firmware image consists of software components from multiple 202 companies. 204 - Firmware Consumer: The firmware consumer is the recipient of the 205 firmware image and the manifest. 207 - Device: A device refers to the entire IoT product, which consists 208 of one or many MCUs, sensors and/or actuators. Many IoT devices 209 sold today contain multiple MCUs and therefore a single device may 210 need to obtain more than one firmware image and manifest to 211 succesfully perform an update. The terms device and firmware 212 consumer are used interchangably since the firmware consumer is 213 one software component running on an MCU on the device. 215 - Status Tracker: The status tracker offers device management 216 functionality to monitor the firmware update process. A status 217 tracker may, for example, want to know what state of the firmware 218 update cycle the device is currently in. 220 - Firmware Server: The firmware server stores firmware images and 221 manifests and distributes them to IoT devices. Some deployments 222 may require a store-and-forward concept, which requires storing 223 the firmware images/manifests on more than one entity before 224 they reach the device. 226 - Device Operator: The actor responsible for the day-to-day 227 operation of a fleet of IoT devices. 229 - Network Operator: The actor responsible for the operation of a 230 network to which IoT devices connect. 232 In addition to the entities in the list above there is an orthogonal 233 infrastructure with a Trust Provisioning Authority (TPA) distributing 234 trust anchors and authorization permissions to various entities in 235 the system. The TPA may also delegate rights to install, update, 236 enhance, or delete trust anchors and authorization permissions to 237 other parties in the system. This infrastructure overlaps the 238 communication architecture and different deployments may empower 239 certain entities while other deployments may not. For example, in 240 some cases, the Original Design Manufacturer (ODM), which is a 241 company that designs and manufactures a product, may act as a TPA and 242 may decide to remain in full control over the firmware update process 243 of their products. 245 The terms 'trust anchor' and 'trust anchor store' are defined in 246 [RFC6024]: 248 - "A trust anchor represents an authoritative entity via a public 249 key and associated data. The public key is used to verify digital 250 signatures, and the associated data is used to constrain the types 251 of information for which the trust anchor is authoritative." 253 - "A trust anchor store is a set of one or more trust anchors stored 254 in a device. A device may have more than one trust anchor store, 255 each of which may be used by one or more applications." A trust 256 anchor store must resist modification against unauthorized 257 insertion, deletion, and modification. 259 3. Requirements 261 The firmware update mechanism described in this specification was 262 designed with the following requirements in mind: 264 - Agnostic to how firmware images are distributed 266 - Friendly to broadcast delivery 268 - Use state-of-the-art security mechanisms 270 - Rollback attacks must be prevented 272 - High reliability 274 - Operate with a small bootloader 276 - Small Parsers 278 - Minimal impact on existing firmware formats 280 - Robust permissions 282 - Diverse modes of operation 284 3.1. Agnostic to how firmware images are distributed 286 Firmware images can be conveyed to devices in a variety of ways, 287 including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and 288 use different protocols (e.g., CoAP, HTTP). The specified mechanism 289 needs to be agnostic to the distribution of the firmware images and 290 manifests. 292 3.2. Friendly to broadcast delivery 294 This architecture does not specify any specific broadcast protocol. 295 However, given that broadcast may be desirable for some networks, 296 updates must cause the least disruption possible both in metadata and 297 payload transmission. 299 For an update to be broadcast friendly, it cannot rely on link layer, 300 network layer, or transport layer security. In addition, the same 301 message must be deliverable to many devices, both those to which it 302 applies and those to which it does not, without a chance that the 303 wrong device will accept the update. Considerations that apply to 304 network broadcasts apply equally to the use of third-party content 305 distribution networks for payload distribution. 307 3.3. Use state-of-the-art security mechanisms 309 End-to-end security between the author and the device, as shown in 310 Section 5, is used to ensure that the device can verify firmware 311 images and manifests produced by authorized authors. 313 The use of post-quantum secure signature mechanisms, such as hash- 314 based signatures, should be explored. A migration to post-quantum 315 secure signatures would require significant effort, therefore, 316 mandatory-to-implement support for post-quantum secure signatures is 317 a goal. 319 A mandatory-to-implement set of algorithms has to be defined offering 320 a key length of 112-bit symmetric key or security or more, as 321 outlined in Section 20 of RFC 7925 [RFC7925]. This corresponds to a 322 233 bit ECC key or a 2048 bit RSA key. 324 If the firmware image is to be encrypted, it must be done in such a 325 way that every intended recipient can decrypt it. The information 326 that is encrypted individually for each device must be an absolute 327 minimum, for example AES Key Wrap [RFC5649], in order to maintain 328 friendliness to Content Distribution Networks, bulk storage, and 329 broadcast protocols. 331 3.4. Rollback attacks must be prevented 333 A device presented with an old, but valid manifest and firmware must 334 not be tricked into installing such firmware since a vulnerability in 335 the old firmware image may allow an attacker to gain control of the 336 device. 338 3.5. High reliability 340 A power failure at any time must not cause a failure of the device. 341 A failure to validate any part of an update must not cause a failure 342 of the device. One way to achieve this functionality is to provide a 343 minimum of two storage locations for firmware and one bootable 344 location for firmware. An alternative approach is to use a 2nd stage 345 bootloader with build-in full featured firmware update functionality 346 such that it is possible to return to the update process after power 347 down. 349 Note: This is an implementation requirement rather than a requirement 350 on the manifest format. 352 3.6. Operate with a small bootloader 354 The bootloader must be minimal, containing only flash support, 355 cryptographic primitives and optionally a recovery mechanism. The 356 recovery mechanism is used in case the update process failed and may 357 include support for firmware updates over serial, USB or even a 358 limited version of wireless connectivity standard like a limited 359 Bluetooth Smart. Such a recovery mechanism must provide security at 360 least at the same level as the full featured firmware update 361 functionalities. 363 The bootloader needs to verify the received manifest and to install 364 the bootable firmware image. The bootloader should not require 365 updating since a failed update poses a risk in reliability. If more 366 functionality is required in the bootloader, it must use a two-stage 367 bootloader, with the first stage comprising the functionality defined 368 above. 370 All information necessary for a device to make a decision about the 371 installation of a firmware update must fit into the available RAM of 372 a constrained IoT device. This prevents flash write exhaustion. 374 Note: This is an implementation requirement. 376 3.7. Small Parsers 378 Since parsers are known sources of bugs they must be minimal. 379 Additionally, it must be easy to parse only those fields that are 380 required to validate at least one signature or MAC with minimal 381 exposure. 383 3.8. Minimal impact on existing firmware formats 385 The design of the firmware update mechanism must not require changes 386 to existing firmware formats. 388 3.9. Robust permissions 390 When a device obtains a monolithic firmware image from a single 391 author without any additional approval steps then the authorization 392 flow is relatively simple. There are, however, other cases where 393 more complex policy decisions need to be made before updating a 394 device. 396 In this architecture the authorization policy is separated from the 397 underlying communication architecture. This is accomplished by 398 separating the entities from their permissions. For example, an 399 author may not have the authority to install a firmware image on a 400 device in critical infrastructure without the authorization of a 401 device operator. In this case, the device may be programmed to 402 reject firmware updates unless they are signed both by the firmware 403 author and by the device operator. 405 Alternatively, a device may trust precisely one entity, which does 406 all permission management and coordination. This entity allows the 407 device to offload complex permissions calculations for the device. 409 3.10. Operating modes 411 There are three broad classifications of update operating modes. 413 - Client-initiated Update 415 - Server-initiated Update 417 - Hybrid Update 419 Client-initiated updates take the form of a firmware consumer on a 420 device proactively checking (polling) for new firmware images. 422 Server-initiated updates are important to consider because timing of 423 updates may need to be tightly controlled in some high- reliability 424 environments. In this case the status tracker determines what 425 devices qualify for a firmware update. Once those devices have been 426 selected the firmware server distributes updates to the firmware 427 consumers. 429 Note: This assumes that the status tracker is able to reach the 430 device, which may require devices to keep reachability information at 431 the status tracker up-to-date. This may also require keeping state 432 at NATs and stateful packet filtering firewalls alive. 434 Hybrid updates are those that require an interaction between the 435 firmware consumer and the status tracker. The status tracker pushes 436 notifications of availability of an update to the firmware consumer, 437 and it then downloads the image from a firmware server as soon as 438 possible. 440 An alternative view to the operating modes is to consider the steps a 441 device has to go through in the course of an update: 443 - Notification 445 - Pre-authorisation 447 - Dependency resolution 449 - Download 451 - Installation 453 The notification step consists of the status tracker informing the 454 firmware consumer that an update is available. This can be 455 accomplished via polling (client-initiated), push notifications 456 (server-initiated), or more complex mechanisms. 458 The pre-authorisation step involves verifying whether the entity 459 signing the manifest is indeed authorized to perform an update. The 460 firmware consumer must also determine whether it should fetch and 461 process a firmware image, which is referenced in a manifest. 463 A dependency resolution phase is needed when more than one component 464 can be updated or when a differential update is used. The necessary 465 dependencies must be available prior to installation. 467 The download step is the process of acquiring a local copy of the 468 firmware image. When the download is client-initiated, this means 469 that the firmware consumer chooses when a download occurs and 470 initiates the download process. When a download is server-initiated, 471 this means that the status tracker tells the device when to download 472 or that it initiates the transfer directly to the firmware consumer. 473 For example, a download from an HTTP-based firmware server is client- 474 initiated. Pushing a manifest and firmware image to the transfer to 475 the Package resource of the LwM2M Firmware Update object [LwM2M] is 476 server-initiated. 478 If the firmware consumer has downloaded a new firmware image and is 479 ready to install it, it may need to wait for a trigger from the 480 status tracker to initiate the installation, may trigger the update 481 automatically, or may go through a more complex decision making 482 process to determine the appropriate timing for an update (such as 483 delaying the update process to a later time when end users are less 484 impacted by the update process). 486 Installation is the act of processing the payload into a format that 487 the IoT device can recognise and the bootloader is responsible for 488 then booting from the newly installed firmware image. 490 Each of these steps may require different permissions. 492 4. Claims 494 Claims in the manifest offer a way to convey instructions to a device 495 that impact the firmware update process. To have any value the 496 manifest containing those claims must be authenticated and integrity 497 protected. The credential used to must be directly or indirectly 498 related to the trust anchor installed at the device by the Trust 499 Provisioning Authority. 501 The baseline claims for all manifests are described in 502 [I-D.ietf-suit-information-model]. For example, there are: 504 - Do not install firmware with earlier metadata than the current 505 metadata. 507 - Only install firmware with a matching vendor, model, hardware 508 revision, software version, etc. 510 - Only install firmware that is before its best-before timestamp. 512 - Only allow a firmware installation if dependencies have been met. 514 - Choose the mechanism to install the firmware, based on the type of 515 firmware it is. 517 5. Communication Architecture 519 Figure 1 shows the communication architecture where a firmware image 520 is created by an author, and uploaded to a firmware server. The 521 firmware image/manifest is distributed to the device either in a push 522 or pull manner using the firmware consumer residing on the device. 523 The device operator keeps track of the process using the status 524 tracker. This allows the device operator to know and control what 525 devices have received an update and which of them are still pending 526 an update. 528 Firmware + +----------+ Firmware + +-----------+ 529 Manifest | |-+ Manifest | |-+ 530 +--------->| Firmware | |<---------------| | | 531 | | Server | | | Author | | 532 | | | | | | | 533 | +----------+ | +-----------+ | 534 | +----------+ +-----------+ 535 | 536 | 537 | 538 -+-- ------ 539 ---- | ---- ---- ---- 540 // | \\ // \\ 541 / | \ / \ 542 / | \ / \ 543 / | \ / \ 544 / | \ / \ 545 | v | | | 546 | +------------+ | 547 | | Firmware | | | | 548 | | Consumer | | Device | +--------+ | 549 | +------------+ | Management| | | | 550 | | |<------------------------->| Status | | 551 | | Device | | | | Tracker| | 552 | +------------+ | || | | | 553 | | || +--------+ | 554 | | | | 555 | | \ / 556 \ / \ / 557 \ / \ Device / 558 \ Network / \ Operator / 559 \ Operator / \\ // 560 \\ // ---- ---- 561 ---- ---- ------ 562 ----- 564 Figure 1: Architecture. 566 End-to-end security mechanisms are used to protect the firmware image 567 and the manifest although Figure 2 does not show the manifest itself 568 since it may be distributed independently. 570 +-----------+ 571 +--------+ | | +--------+ 572 | | Firmware Image | Firmware | Firmware Image | | 573 | Device |<-----------------| Server |<------------------| Author | 574 | | | | | | 575 +--------+ +-----------+ +--------+ 576 ^ * 577 * * 578 ************************************************************ 579 End-to-End Security 581 Figure 2: End-to-End Security. 583 Whether the firmware image and the manifest is pushed to the device 584 or fetched by the device is a deployment specific decision. 586 The following assumptions are made to allow the firmware consumer to 587 verify the received firmware image and manifest before updating 588 software: 590 - To accept an update, a device needs to verify the signature 591 covering the manifest. There may be one or multiple manifests 592 that need to be validated, potentially signed by different 593 parties. The device needs to be in possession of the trust 594 anchors to verify those signatures. Installing trust anchors to 595 devices via the Trust Provisioning Authority happens in an out-of- 596 band fashion prior to the firmware update process. 598 - Not all entities creating and signing manifests have the same 599 permissions. A device needs to determine whether the requested 600 action is indeed covered by the permission of the party that 601 signed the manifest. Informing the device about the permissions 602 of the different parties also happens in an out-of-band fashion 603 and is also a duty of the Trust Provisioning Authority. 605 - For confidentiality protection of firmware images the author needs 606 to be in possession of the certificate/public key or a pre-shared 607 key of a device. The use of confidentiality protection of 608 firmware images is deployment specific. 610 There are different types of delivery modes, which are illustrated 611 based on examples below. 613 There is an option for embedding a firmware image into a manifest. 614 This is a useful approach for deployments where devices are not 615 connected to the Internet and cannot contact a dedicated firmware 616 server for the firmware download. It is also applicable when the 617 firmware update happens via a USB stick or via Bluetooth Smart. 618 Figure 3 shows this delivery mode graphically. 620 /------------\ /------------\ 621 /Manifest with \ /Manifest with \ 622 |attached | |attached | 623 \firmware image/ \firmware image/ 624 \------------/ +-----------+ \------------/ 625 +--------+ | | +--------+ 626 | |<.................| Firmware |<................| | 627 | Device | | Server | | Author | 628 | | | | | | 629 +--------+ +-----------+ +--------+ 631 Figure 3: Manifest with attached firmware. 633 Figure 4 shows an option for remotely updating a device where the 634 device fetches the firmware image from some file server. The 635 manifest itself is delivered independently and provides information 636 about the firmware image(s) to download. 638 /------------\ 639 / \ 640 | Manifest | 641 \ / 642 +--------+ \------------/ +--------+ 643 | |<..............................................>| | 644 | Device | -- | Author | 645 | |<- --- | | 646 +--------+ -- --- +--------+ 647 -- --- 648 --- --- 649 -- +-----------+ -- 650 -- | | -- 651 /------------\ -- | Firmware |<- /------------\ 652 / \ -- | Server | / \ 653 | Firmware | | | | Firmware | 654 \ / +-----------+ \ / 655 \------------/ \------------/ 657 Figure 4: Independent retrieval of the firmware image. 659 This architecture does not mandate a specific delivery mode but a 660 solution must support both types. 662 6. Manifest 664 In order for a device to apply an update, it has to make several 665 decisions about the update: 667 - Does it trust the author of the update? 669 - Has the firmware been corrupted? 671 - Does the firmware update apply to this device? 673 - Is the update older than the active firmware? 675 - When should the device apply the update? 677 - How should the device apply the update? 679 - What kind of firmware binary is it? 681 - Where should the update be obtained? 683 - Where should the firmware be stored? 685 The manifest encodes the information that devices need in order to 686 make these decisions. It is a data structure that contains the 687 following information: 689 - information about the device(s) the firmware image is intended to 690 be applied to, 692 - information about when the firmware update has to be applied, 694 - information about when the manifest was created, 696 - dependencies on other manifests, 698 - pointers to the firmware image and information about the format, 700 - information about where to store the firmware image, 702 - cryptographic information, such as digital signatures or message 703 authentication codes (MACs). 705 The manifest information model is described in 706 [I-D.ietf-suit-information-model]. 708 7. Device Firmware Update Examples 710 Although these documents attempt to define a firmware update 711 architecture that is applicable to both existing systems, as well as 712 yet-to-be-conceived systems; it is still helpful to consider existing 713 architectures. 715 7.1. Single CPU SoC 717 The simplest, and currently most common, architecture consists of a 718 single MCU along with its own peripherals. These SoCs generally 719 contain some amount of flash memory for code and fixed data, as well 720 as RAM for working storage. These systems either have a single 721 firmware image, or an immutable bootloader that runs a single image. 722 A notable characteristic of these SoCs is that the primary code is 723 generally execute in place (XIP). Combined with the non-relocatable 724 nature of the code, firmware updates need to be done in place. 726 7.2. Single CPU with Secure - Normal Mode Partitioning 728 Another configuration consists of a similar architecture to the 729 previous, with a single CPU. However, this CPU supports a security 730 partitioning scheme that allows memory (in addition to other things) 731 to be divided into secure and normal mode. There will generally be 732 two images, one for secure mode, and one for normal mode. In this 733 configuration, firmware upgrades will generally be done by the CPU in 734 secure mode, which is able to write to both areas of the flash 735 device. In addition, there are requirements to be able to update 736 either image independently, as well as to update them together 737 atomically, as specified in the associated manifests. 739 7.3. Dual CPU, shared memory 741 This configuration has two or more CPUs in a single SoC that share 742 memory (flash and RAM). Generally, they will be a protection 743 mechanism to prevent one CPU from accessing the other's memory. 744 Upgrades in this case will typically be done by one of the CPUs, and 745 is similar to the single CPU with secure mode. 747 7.4. Dual CPU, other bus 749 This configuration has two or more CPUs, each having their own 750 memory. There will be a communication channel between them, but it 751 will be used as a peripheral, not via shared memory. In this case, 752 each CPU will have to be responsible for its own firmware upgrade. 753 It is likely that one of the CPUs will be considered a master, and 754 will direct the other CPU to do the upgrade. This configuration is 755 commonly used to offload specific work to other CPUs. Firmware 756 dependencies are similar to the other solutions above, sometimes 757 allowing only one image to be upgraded, other times requiring several 758 to be upgraded atomically. Because the updates are happening on 759 multiple CPUs, upgrading the two images atomically is challenging. 761 8. Bootloader 763 More devices today than ever before are being connected to the 764 Internet, which drives the need for firmware updates to be provided 765 over the Internet rather than through traditional interfaces, such as 766 USB or RS232. Updating a device over the Internet requires the 767 device to fetch not only the firmware image but also the manifest. 768 Hence, the following building blocks are necessary for a firmware 769 update solution: 771 - the Internet protocol stack for (possibly large) firmware 772 downloads, 774 - the capability to write the received firmware image to persistent 775 storage (most likely flash memory) prior to performing the update, 777 - the ability to unpack, decompress or otherwise process the 778 received firmware image, 780 - the features to verify an image and a manifest, including digital 781 signature verification or checking a message authentication code, 783 - a manifest parsing library, and 785 - integration of the device into a device management server to 786 perform automatic firmware updates and to track their progress. 788 All these features are most likely offered by the application, i.e. 789 firmware consumer, running on the device (except for basic security 790 algorithms that may run either on a trusted execution environment or 791 on a separate hardware security MCU/module) rather than by the 792 bootloader itself. 794 Once manifests have been processed and firmware images successfully 795 downloaded and verified the device needs to hand control over to the 796 bootloader. In most cases this requires the MCU to restart. Once 797 the MCU has initiated a restart, the bootloader takes over control 798 and determines whether the newly downloaded firmware image should be 799 executed. 801 The boot process is security sensitive because the firmware images 802 may, for example, be stored in off-chip flash memory giving attackers 803 easy access to the image for reverse engineering and potentially also 804 for modifying the binary. The bootloader will therefore have to 805 perform security checks on the firmware image before it can be 806 booted. These security checks by the bootloader happen in addition 807 to the security checks that happened when the firmware image and the 808 manifest were downloaded. 810 The manifest may have been stored alongside the firmware image to 811 allow re-verification of the firmware image during every boot 812 attempt. Alternatively, secure boot-specific meta-data may have been 813 created by the application after a successful firmware download and 814 verification process. Whether to re-use the standardized manifest 815 format that was used during the initial firmware retrieval process or 816 whether it is better to use a different format for the secure boot- 817 specific meta-data depends on the system design. The manifest format 818 does, however, have the capability to serve also as a building block 819 for secure boot with its severable elements that allow shrinking the 820 size of the manifest by stripping elements that are no longer needed. 822 If the application image contains the firmware consumer 823 functionality, as described above, then it is necessary that a 824 working image is left on the device to ensure that the bootloader can 825 roll back to a working firmware image to re-do the firmware download 826 since the bootloader itself does not have enough functionality to 827 fetch a firmware image plus manifest from a firmware server over the 828 Internet. A multi-stage bootloader may soften this requirement at 829 the expense of a more sophisticated boot process. 831 For a bootloader to offer a secure boot mechanism it needs to provide 832 the following features: 834 - ability to access security algorithms, such as SHA-256 to compute 835 a fingerprint over the firmware image and a digital signature 836 algorithm. 838 - access keying material directly or indirectly to utilize the 839 digital signature. The device needs to have a trust anchor store. 841 - ability to expose boot process-related data to the application 842 firmware (such as to the device management software). This allows 843 a device management server to determine whether the firmware 844 update has been successful and, if not, what errors occurred. 846 - to (optionally) offer attestation information (such as 847 measurements). 849 While the software architecture of the bootloader and its security 850 mechanisms are implementation-specific, the manifest can be used to 851 control the firmware download from the Internet in addition to 852 augmenting secure boot process. These building blocks are highly 853 relevant for the design of the manifest. 855 9. Example 857 The following example message flow illustrates a possible interaction 858 for distributing a firmware image to a device starting with an author 859 uploading the new firmware to firmware server and creating a 860 manifest. The firmware and manifest are stored on the same firmware 861 server. 863 +--------+ +-----------------+ +------------+ +----------+ 864 | Author | | Firmware Server | |FW Consumer | |Bootloader| 865 +--------+ +-----------------+ +------------+ +----------+ 866 | | | + 867 | Create Firmware | | | 868 |--------------- | | | 869 | | | | | 870 |<-------------- | | | 871 | | | | 872 | Upload Firmware | | | 873 |------------------>| | | 874 | | | | 875 | Create Manifest | | | 876 |---------------- | | | 877 | | | | | 878 |<--------------- | | | 879 | | | | 880 | Sign Manifest | | | 881 |-------------- | | | 882 | | | | | 883 |<------------- | | | 884 | | | | 885 | Upload Manifest | | | 886 |------------------>| | | 887 | | | | 888 | | Query Manifest | | 889 | |<--------------------| | 890 | | | | 891 | | Send Manifest | | 892 | |-------------------->| | 893 | | | Validate | 894 | | | Manifest | 895 | | |---------+ | 896 | | | | | 897 | | |<--------+ | 898 | | | | 899 | | Request Firmware | | 900 | |<--------------------| | 901 | | | | 902 | | Send Firmware | | 903 | |-------------------->| | 904 | | | Verify | 905 | | | Firmware | 906 | | |--------------- | 907 | | | | | 908 | | |<-------------- | 909 | | | | 910 | | | Store | 911 | | | Firmware | 912 | | |-------------- | 913 | | | | | 914 | | |<------------- | 915 | | | | 916 | | | | 917 | | | Reboot | 918 | | |--------------->| 919 | | | | 920 | | | Verify | 921 | | | Firmware | 922 | | | ---------------| 923 | | | | | 924 | | | -------------->| 925 | | | | 926 | | | Activate new | 927 | | | Firmware | 928 | | | ---------------| 929 | | | | | 930 | | | -------------->| 931 | | | | 932 | | | Boot new | 933 | | | Firmware | 934 | | | ---------------| 935 | | | | | 936 | | | -------------->| 937 | | | | 939 Figure 5: Example Flow for a Firmware Upate. 941 10. IANA Considerations 943 This document does not require any actions by IANA. 945 11. Security Considerations 947 Firmware updates fix security vulnerabilities and are considered to 948 be an important building block in securing IoT devices. Due to the 949 importance of firmware updates for IoT devices the Internet 950 Architecture Board (IAB) organized a 'Workshop on Internet of Things 951 (IoT) Software Update (IOTSU)', which took place at Trinity College 952 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 953 the big picture. A report about this workshop can be found at 954 [RFC8240]. A standardized firmware manifest format providing end-to- 955 end security from the author to the device will be specified in a 956 separate document. 958 There are, however, many other considerations raised during the 959 workshop. Many of them are outside the scope of standardization 960 organizations since they fall into the realm of product engineering, 961 regulatory frameworks, and business models. The following 962 considerations are outside the scope of this document, namely 964 - installing firmware updates in a robust fashion so that the update 965 does not break the device functionality of the environment this 966 device operates in. 968 - installing firmware updates in a timely fashion considering the 969 complexity of the decision making process of updating devices, 970 potential re-certification requirements, and the need for user 971 consent to install updates. 973 - the distribution of the actual firmware update, potentially in an 974 efficient manner to a large number of devices without human 975 involvement. 977 - energy efficiency and battery lifetime considerations. 979 - key management required for verifying the digital signature 980 protecting the manifest. 982 - incentives for manufacturers to offer a firmware update mechanism 983 as part of their IoT products. 985 12. Mailing List Information 987 The discussion list for this document is located at the e-mail 988 address suit@ietf.org [1]. Information on the group and information 989 on how to subscribe to the list is at 990 https://www1.ietf.org/mailman/listinfo/suit [2] 991 Archives of the list can be found at: https://www.ietf.org/mail- 992 archive/web/suit/current/index.html [3] 994 13. Acknowledgements 996 We would like to thank the following persons for their feedback: 998 - Geraint Luff 1000 - Amyas Phillips 1002 - Dan Ros 1004 - Thomas Eichinger 1006 - Michael Richardson 1008 - Emmanuel Baccelli 1010 - Ned Smith 1012 - Jim Schaad 1014 - Carsten Bormann 1016 - Cullen Jennings 1018 - Olaf Bergmann 1020 - Suhas Nandakumar 1022 - Phillip Hallam-Baker 1024 - Marti Bolivar 1026 - Andrzej Puzdrowski 1028 - Markus Gueller 1030 - Henk Birkholz 1032 - Jintao Zhu 1034 - Takeshi Takahashi 1036 - Jacob Beningo 1037 We would also like to thank the WG chairs, Russ Housley, David 1038 Waltermire, Dave Thaler for their support and their reviews. 1040 14. References 1042 14.1. Normative References 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Levels", BCP 14, RFC 2119, 1046 DOI 10.17487/RFC2119, March 1997, 1047 . 1049 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1050 Security (TLS) / Datagram Transport Layer Security (DTLS) 1051 Profiles for the Internet of Things", RFC 7925, 1052 DOI 10.17487/RFC7925, July 2016, 1053 . 1055 14.2. Informative References 1057 [I-D.ietf-suit-information-model] 1058 Moran, B., Tschofenig, H., and H. Birkholz, "Firmware 1059 Updates for Internet of Things Devices - An Information 1060 Model for Manifests", draft-ietf-suit-information-model-02 1061 (work in progress), January 2019. 1063 [LwM2M] OMA, ., "Lightweight Machine to Machine Technical 1064 Specification, Version 1.0.2", February 2018, 1065 . 1069 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1070 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1071 DOI 10.17487/RFC5649, September 2009, 1072 . 1074 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1075 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1076 2010, . 1078 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 1079 of Things Software Update (IoTSU) Workshop 2016", 1080 RFC 8240, DOI 10.17487/RFC8240, September 2017, 1081 . 1083 14.3. URIs 1085 [1] mailto:suit@ietf.org 1087 [2] https://www1.ietf.org/mailman/listinfo/suit 1089 [3] https://www.ietf.org/mail-archive/web/suit/current/index.html 1091 Authors' Addresses 1093 Brendan Moran 1094 Arm Limited 1096 EMail: Brendan.Moran@arm.com 1098 Milosch Meriac 1099 Consultant 1101 EMail: milosch@meriac.com 1103 Hannes Tschofenig 1104 Arm Limited 1106 EMail: hannes.tschofenig@arm.com 1108 David Brown 1109 Linaro 1111 EMail: david.brown@linaro.org