idnits 2.17.1 draft-moran-suit-architecture-03.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 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 (March 05, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 736 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft M. Meriac 4 Intended status: Informational H. Tschofenig 5 Expires: September 6, 2018 Arm Limited 6 March 05, 2018 8 A Firmware Update Architecture for Internet of Things Devices 9 draft-moran-suit-architecture-03 11 Abstract 13 Vulnerabilities with Internet of Things (IoT) devices have raised the 14 need for a solid and secure firmware update mechanism that is also 15 suitable for constrained devices. Incorporating such update 16 mechanism to fix vulnerabilities, to update configuration settings as 17 well as adding new functionality is recommended by security experts. 19 This document lists requirements and describes an architecture for a 20 firmware update mechanism suitable for IoT devices. The architecture 21 is agnostic to the transport of the firmware images and associated 22 meta-data. 24 This version of the document assumes asymmetric cryptography and a 25 public key infrastructure. Future versions may also describe a 26 symmetric key approach for very constrained devices. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 76 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Agnostic to how firmware images are distributed . . . . . 6 78 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 6 79 3.3. Uses state-of-the-art security mechanisms . . . . . . . . 6 80 3.4. Rollback attacks must be prevented . . . . . . . . . . . 6 81 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 6 82 3.6. Operates with a small bootloader . . . . . . . . . . . . 7 83 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 7 84 3.8. Minimal impact on existing firmware formats . . . . . . . 7 85 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 7 86 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 88 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 7. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 10. Mailing List Information . . . . . . . . . . . . . . . . . . 15 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 96 12.2. Informative References . . . . . . . . . . . . . . . . . 16 97 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 Appendix A. Threat Model, User Stories, Security Requirements, 99 and Usability Requirements . . . . . . . . . . . . . 17 100 A.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 101 A.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 102 A.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 17 103 A.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 18 104 A.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 18 105 A.2.4. Threat MFT4: The target device misinterprets the type 106 of payload . . . . . . . . . . . . . . . . . . . . . 18 107 A.2.5. Threat MFT5: The target device installs the payload 108 to the wrong location . . . . . . . . . . . . . . . . 19 109 A.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 19 110 A.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 19 111 A.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 19 112 A.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 20 113 A.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 20 114 A.2.11. Threat MFT11: Reverse Engineering Of Firmware Image 115 for Vulnerability Analysis . . . . . . . . . . . . . 21 116 A.3. Security Requirements . . . . . . . . . . . . . . . . . . 21 117 A.3.1. Security Requirement MFSR1: Monotonic Sequence 118 Numbers . . . . . . . . . . . . . . . . . . . . . . . 21 119 A.3.2. Security Requirement MFSR2: Vendor, Device-type 120 Identifiers . . . . . . . . . . . . . . . . . . . . . 22 121 A.3.3. Security Requirement MFSR3: Best-Before Timestamps . 22 122 A.3.4. Security Requirement MFSR4: Signed Payload Descriptor 22 123 A.3.5. Security Requirement MFSR5: Cryptographic 124 Authenticity . . . . . . . . . . . . . . . . . . . . 23 125 A.3.6. Security Requirement MFSR6: Rights Require 126 Authenticity . . . . . . . . . . . . . . . . . . . . 23 127 A.3.7. Security Requirement MFSR7: Firmware encryption . . . 23 128 A.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 23 129 A.4.1. Use Case MFUC1: Installation Instructions . . . . . . 24 130 A.4.2. Use Case MFUC2: Reuse Local Infrastructure . . . . . 24 131 A.4.3. Use Case MFUC3: Modular Update . . . . . . . . . . . 24 132 A.4.4. Use Case MFUC4: Multiple Authorisations . . . . . . . 25 133 A.4.5. Use Case MFUC5: Multiple Payload Formats . . . . . . 25 134 A.4.6. Use Case MFUC6: IP Protection . . . . . . . . . . . . 25 135 A.5. Usability Requirements . . . . . . . . . . . . . . . . . 25 136 A.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 25 137 A.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 25 138 A.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 26 139 A.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 26 140 A.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 26 142 A.6. Manifest Fields . . . . . . . . . . . . . . . . . . . . . 26 143 A.6.1. Manifest Field: Timestamp . . . . . . . . . . . . . . 27 144 A.6.2. Manifest Field: Vendor ID Condition . . . . . . . . . 27 145 A.6.3. Manifest Field: Class ID Condition . . . . . . . . . 27 146 A.6.4. Manifest Field: Precursor Image Digest Condition . . 27 147 A.6.5. Manifest Field: Best-Before timestamp condition . . . 27 148 A.6.6. Manifest Field: Payload Format . . . . . . . . . . . 28 149 A.6.7. Manifest Field: Storage Location . . . . . . . . . . 28 150 A.6.8. Manifest Field: URIs . . . . . . . . . . . . . . . . 28 151 A.6.9. Manifest Field: Digests . . . . . . . . . . . . . . . 28 152 A.6.10. Manifest Field: Size . . . . . . . . . . . . . . . . 28 153 A.6.11. Manifest Field: Signature . . . . . . . . . . . . . . 28 154 A.6.12. Manifest Field: Directives . . . . . . . . . . . . . 29 155 A.6.13. Manifest Field: Aliases . . . . . . . . . . . . . . . 29 156 A.6.14. Manifest Field: Dependencies . . . . . . . . . . . . 29 157 A.6.15. Manifest Field: Content Key Distribution Method . . . 29 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 160 1. Introduction 162 When developing IoT devices, one of the most difficult problems to 163 solve is how to update the firmware on the device. Once the device 164 is deployed, firmware updates play a critical part in its lifetime, 165 particularly when devices have a long lifetime, are deployed in 166 remote or inaccessible areas or where manual intervention is cost 167 prohibitive or otherwise difficult. The need for a firmware update 168 may be to fix bugs in software, to add new functionality, or to re- 169 configure the device. 171 The firmware update process has to ensure that 173 - The firmware image is authenticated and attempts to flash a 174 malicious firmware image are prevented. 176 - The firmware image can be confidentiality protected so that 177 attempts by an adversary to recover the plaintext binary can be 178 prevented. Obtaining the plaintext binary is often one of the 179 first steps for an attack to mount an attack. 181 2. Conventions and Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in RFC 186 2119 [RFC2119]. 188 This document uses the following terms: 190 - Manifest: The manifest contains meta-data about the firmware 191 image. The manifest is protected against modification and 192 provides information about the author. 194 - Firmware Image: The firmware image is a binary that may contain 195 the complete software of a device or a subset of it. The firmware 196 image may consist of multiple images, if the device contains more 197 than one microcontroller. The image may consist of a differential 198 update for performance reasons. Firmware is the more universal 199 term. Both terms are used in this document and are 200 interchangeable. 202 The following entities are used: 204 - Author: The author is the entity that creates the firmware image, 205 signs and/or encrypts it and attaches a manifest to it. The 206 author is most likely a developer using a set of tools. 208 - Device: The device is the recipient of the firmware image and the 209 manifest. The goal is to update the firmware of the device. 211 - Untrusted Storage: Firmware images and manifests are stored on 212 untrusted fileservers or cloud storage infrastructure. Some 213 deployments may require storage of the firmware images/manifests 214 to be stored on various entities before they reach the device. 216 3. Requirements 218 The firmware update mechanism described in this specification was 219 designed with the following requirements in mind: 221 - Agnostic to how firmware images are distributed 223 - Friendly to broadcast delivery 225 - Uses state-of-the-art security mechanisms 227 - Rollback attacks must be prevented. 229 - High reliability 231 - Operates with a small bootloader 233 - Small Parsers 235 - Minimal impact on existing firmware formats 237 - Robust permissions 239 3.1. Agnostic to how firmware images are distributed 241 Firmware images can be conveyed to devices in a variety of ways, 242 including USB, UART, WiFi, BLE, low-power WAN technologies, etc and 243 use different protocols (e.g., CoAP, HTTP). The specified mechanism 244 needs to be agnostic to the distribution of the firmware images and 245 manifests. 247 3.2. Friendly to broadcast delivery 249 For an update to be broadcast friendly, it cannot rely on link layer, 250 network layer, or transport layer security. In addition, the same 251 message must be deliverable to many devices; both those to which it 252 applies and those to which it does not without a chance that the 253 wrong device will accept the update. Considerations that apply to 254 network broadcasts apply equally to the use of third-party content 255 distribution networks for payload distribution. 257 3.3. Uses state-of-the-art security mechanisms 259 End-to-end security between the author and the device, as shown in 260 Section 5, is used to ensure that the device can verify firmware 261 images and manifests produced by authorized authors. 263 The use of post-quantum secure signature mechanisms, such as hash- 264 based signatures, should be explored. A mandatory-to-implement set 265 of algorithms has to be defined offering a key length of 112-bit 266 symmetric key or security or more, as outlined in Section 20 of RFC 267 7925. This corresponds to a 233 bit ECC key or a 2048 bit RSA key. 269 If the firmware image is to be encrypted, it must be done in such a 270 way that every intended recipient can decrypt it. The information 271 that is encrypted individually for each device must be an absolute 272 minimum. 274 3.4. Rollback attacks must be prevented 276 A device presented with an old, but valid manifest and firmware must 277 not be tricked into installing such firmware since a vulnerability in 278 the old firmware image may allow an attacker gain control of the 279 device. 281 3.5. High reliability 283 A power failure at any time must not cause a failure of the device. 284 A failure to validate any part of an update must not cause a failure 285 of the device. One way to achieve this functionality is to provide a 286 minimum of two storage locations for firmware and one bootable 287 location for firmware. An alternative approach is to use a 2nd stage 288 bootloader with build-in full featured firmware update functionality 289 such that it is possible to return to the update process after power 290 down. 292 Note: This is an implementation requirement rather than a requirement 293 on the manifest format. 295 3.6. Operates with a small bootloader 297 The bootloader must be minimal, containing only flash support, 298 cryptographic primitives and optionally a recovery mechanism. The 299 recovery mechanism is used in case the update process failed and may 300 include support for firmware updates over serial, USB or even a 301 limited version of wireless connectivity standard like a limited 302 Bluetooth Smart. Such a recovery mechanism must provide security at 303 least at the same level as the full featured firmware update 304 functionalities. 306 The bootloader needs to verify the received manifest and to install 307 the bootable firmware image. The bootloader should not require 308 updating since a failed update poses a risk in reliability. If more 309 functionality is required in the bootloader, it must use a two-stage 310 bootloader, with the first stage comprising the functionality defined 311 above. 313 All information necessary for a device to make a decision about the 314 installation of a firmware update must fit into the available RAM of 315 a constrained IoT device. This prevents flash write exhaustion. 317 Note: This is an implementation requirement. 319 3.7. Small Parsers 321 Since parsers are known sources of bugs they must be minimal. 322 Additionally, it must be easy to parse only those fields which are 323 required to validate at least one signature with minimal exposure. 325 3.8. Minimal impact on existing firmware formats 327 The design of the firmware update mechanism must not require changes 328 to existing firmware formats. 330 3.9. Robust permissions 332 A device may have many modules that require updating individually. 333 It may also need to trust several actors in order to authorize an 334 update. For example, a firmware author may not have the authority to 335 install firmware on a device in critical infrastructure without the 336 authorization of a device operator. In this case, the device should 337 reject firmware updates unless they are signed both by the firmware 338 author and by the device operator. To facilitate complex use-cases 339 such as this, updates require several permissions. 341 4. Claims 343 When a simple set of permissions fails to encapsulate the rules 344 required for a device make decisions about firmware, claims can be 345 used instead. Claims represent a form of policy. Several claims can 346 be used together, when multiple actors should have the rights to set 347 policies. 349 Some example claims are: 351 - Trust the actor identified by the referenced public key. 353 - Three actors are trusted identified by their public keys. 354 Signatures from at least two of these actors are required to trust 355 a manifest. 357 - The actor identified by the referenced public key is authorized to 358 create secondary policies 360 The baseline claims for all manifests are described in Appendix A. 361 In summary, they are: 363 - Do not install firmware with earlier metadata than the current 364 metadata. 366 - Only install firmware with a matching vendor, model, hardware 367 revision, software version, etc. 369 - Only install firmware that is before its best-before timestamp. 371 - Only install firmware with metadata signed by a trusted actor. 373 - Only allow an actor to exercise rights on the device via a 374 manifest if that actor has signed the manifest. 376 - Only allow a firmware installation if all required rights have 377 been met through signatures (one or more) or manifest dependencies 378 (one or more). 380 - Use the instructions provided by the manifest to install the 381 firmware. 383 - Any authorized actor may redirect any URI. 385 - Install any and all firmware images that are linked together with 386 manifest dependencies. 388 - Choose the mechanism to install the firmware, based on the type of 389 firmware it is. 391 5. Architecture 393 We start the architectural description with the security model. It 394 is based on end-to-end security. Figure 1 illustrates the security 395 model where a firmware image and the corresponding manifest are 396 created by an author and verified by the device. The firmware image 397 is integrity protected and may be encrypted. The manifest is 398 integrity protected and authenticated. When the author is ready to 399 distribute the firmware image it is conveyed using some communication 400 channel to the device, which will typically involve the use of 401 untrusted storage. Examples of untrusted storage are FTP servers, 402 Web servers or USB sticks. 404 +-----------+ 405 +--------+ Firmware Image | | Firmware Image +--------+ 406 | | + Manifest | Untrusted | + Manifest | | 407 | Device |<-----------------| Storage |<------------------| Author | 408 | | | | | | 409 +--------+ +-----------+ +--------+ 410 ^ * 411 * * 412 ************************************************************ 413 End-to-End Security 415 Figure 1: End-to-End Security. 417 Whether the firmware image and the manifest is pushed to the device 418 or fetched by the device is outside the scope of this work and 419 existing device management protocols can be used for efficiently 420 distributing this information. 422 The following assumptions are made to allow the device to verify the 423 received firmware image and manifest before updating software: 425 - To accept an update, a device needs to decide whether the author 426 signing the firmware image and the manifest is authorized to make 427 the updates. We use public key cryptography to accomplish this. 428 The device verifies the signature covering the manifest using a 429 digital signature algorithm. The device is provisioned with a 430 trust anchor that is used to validate the digital signature 431 produced by the author. This trust anchor is potentially 432 different from the trust anchor used to validate the digital 433 signature produced for other protocols (such as device management 434 protocols). This trust anchor may be provisioned to the device 435 during manufacturing or during commissioning. 437 - For confidentiality protection of firmware images the author needs 438 to be in possession of the certificate/public key or a pre-shared 439 key of a device. 441 There are different types of delivery modes, which are illustrates 442 based on examples below. 444 There is an option for embedding a firmware image into a manifest. 445 This is a useful approach for deployments where devices are not 446 connected to the Internet and cannot contact a dedicated server for 447 download of the firmware. It is also applicable when the firmware 448 update happens via a USB stick or via Bluetooth Smart. Figure 2 449 shows this delivery mode graphically. 451 /------------\ /------------\ 452 /Manifest with \ /Manifest with \ 453 |attached | |attached | 454 \firmware image/ \firmware image/ 455 \------------/ +-----------+ \------------/ 456 +--------+ | | +--------+ 457 | |<.................| Untrusted |<................| | 458 | Device | | Storage | | Author | 459 | | | | | | 460 +--------+ +-----------+ +--------+ 462 Figure 2: Manifest with attached firmware. 464 Figure 3 shows an option for remotely updating a device where the 465 device fetches the firmware image from some file server. The 466 manifest itself is delivery independently and provides information 467 about the firmware image(s) to download. 469 /------------\ 470 / \ 471 | Manifest | 472 \ / 473 +--------+ \------------/ +--------+ 474 | |<..............................................>| | 475 | Device | -- | Author | 476 | |<- --- | | 477 +--------+ -- --- +--------+ 478 -- --- 479 --- --- 480 -- +-----------+ -- 481 -- | | -- 482 /------------\ -- | Untrusted |<- /------------\ 483 / \ -- | Storage | / \ 484 | Firmware | | | | Firmware | 485 \ / +-----------+ \ / 486 \------------/ \------------/ 488 Figure 3: Independent retrieval of the firmware image. 490 This architecture does not mandate a specific delivery mode but a 491 solution must support both types. 493 6. Manifest 495 In order for a device to apply an update, it has to make several 496 decisions about the update: 498 - Does it trust the author of the update? 500 - Has the firmware been corrupted? 502 - Does the firmware update apply to this device? 504 - Is the update older than the active firmware? 506 - When should the device apply the update? 508 - How should the device apply the update? 510 - What kind of firmware binary is it? 512 - Where should the update be obtained? 514 - Where should the firmware be stored? 515 The manifest encodes the information that devices need in order to 516 make these decisions. It is a data structure that contains the 517 following information: 519 - information about the device(s) the firmware image is intented to 520 be applied to, 522 - information about when the firmware update has to be applied, 524 - information about when the manifest was created, 526 - dependencies to other manifests, 528 - pointers to the firmware image and information about the format, 530 - information about where to store the firmware image, 532 - cryptographic information, such as digital signatures. 534 The manifest format is described in a companion document. 536 7. Example Flow 538 The following example message flow illustrates the interaction for 539 distributing a firmware image to a device starting with an author 540 uploading the new firmware to untrusted storage and creating a 541 manifest. 543 +--------+ +-----------------+ +------+ 544 | Author | |Untrusted Storage| |Device| 545 +--------+ +-----------------+ +------+ 546 | | | 547 | Create Firmware | | 548 |--------------- | | 549 | | | | 550 |<-------------- | | 551 | | | 552 | Upload Firmware | | 553 |------------------>| | 554 | | | 555 | Create Manifest | | 556 |---------------- | | 557 | | | | 558 |<--------------- | | 559 | | | 560 | Sign Manifest | | 561 |-------------- | | 562 | | | | 563 |<------------- | | 564 | | | 565 | Upload Manifest | | 566 |------------------>| | 567 | | | 568 | | Query Manifest | 569 | |<--------------------| 570 | | | 571 | | Send Manifest | 572 | |-------------------->| 573 | | | 574 | | | Validate Manifest 575 | | |------------------ 576 | | | | 577 | | |<----------------- 578 | | | 579 | | Request Firmware | 580 | |<--------------------| 581 | | | 582 | | Send Firmware | 583 | |-------------------->| 584 | | | 585 | | | Verify Firmware 586 | | |--------------- 587 | | | | 588 | | |<-------------- 589 | | | 590 | | | Store Firmware 591 | | |-------------- 592 | | | | 593 | | |<------------- 594 | | | 595 | | | Reboot 596 | | |------- 597 | | | | 598 | | |<------ 599 | | | 600 | | | Bootloader validates 601 | | | Firmware 602 | | |---------------------- 603 | | | | 604 | | |<--------------------- 605 | | | 606 | | | Bootloader activates 607 | | | Firmware 608 | | |---------------------- 609 | | | | 610 | | |<--------------------- 611 | | | 612 | | | Bootloader transfers 613 | | | control to new Firmware 614 | | |---------------------- 615 | | | | 616 | | |<--------------------- 617 | | | 619 Figure 4: Example Flow for a Firmware Upate. 621 8. IANA Considerations 623 This document does not require any actions by IANA. 625 9. Security Considerations 627 Firmware updates fix security vulnerabilities and are considered to 628 be an important building block in securing IoT devices. Due to the 629 importance of firmware updates for IoT devices the Internet 630 Architecture Board (IAB) organized a 'Workshop on Internet of Things 631 (IoT) Software Update (IOTSU)', which took place at Trinity College 632 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 633 the big picture. A report about this workshop can be found at 634 [RFC8240]. This document (and associated specifications) offer a 635 standardized firmware manifest format providing end-to-end security 636 from the author to the device. 638 There are, however, many other considerations raised during the 639 workshop. Many of them are outside the scope of standardization 640 organizations since they fall into the realm of product engineering, 641 regulatory frameworks, and business models. The following 642 considerations are outside the scope of this document, namely 644 - installing firmware updates in a robust fashion so that the update 645 does not break the device functionality of the environment this 646 device operates in. 648 - installing firmware updates in a timely fashion considering the 649 complexity of the decision making process of updating devices, 650 potential re-certification requirements, and the need for user's 651 consent to install updates. 653 - the distribution of the actual firmware update, potentially in an 654 efficient manner to a large number of devices without human 655 involvement. 657 - energy efficiency and battery lifetime considerations. 659 - key management required for verifying the digitial signature 660 protecting the manifest. 662 - incentives for manufacturers to offer a firmware update mechanism 663 as part of their IoT products. 665 10. Mailing List Information 667 The discussion list for this document is located at the e-mail 668 address suit@ietf.org [1]. Information on the group and information 669 on how to subscribe to the list is at 670 https://www1.ietf.org/mailman/listinfo/suit 672 Archives of the list can be found at: https://www.ietf.org/mail- 673 archive/web/suit/current/index.html 675 11. Acknowledgements 677 We would like to thank the following persons for their feedback: 679 - Geraint Luff 681 - Amyas Phillips 683 - Dan Ros 685 - Thomas Eichinger 687 - Michael Richardson 689 - Emmanuel Baccelli 691 - Ned Smith 693 - David Brown 695 - Jim Schaad 697 - Carsten Bormann 699 - Cullen Jennings 701 - Olaf Bergmann 703 - Suhas Nandakumar 705 - Phillip Hallam-Baker 706 - Marti Bolivar 708 - Andrzej Puzdrowski 710 - Markus Gueller 712 We would also like to thank the WG chairs, Russ Housley, David 713 Waltermire, Dave Thaler and the responsible security area director, 714 Kathleen Moriarty, for their support and their reviews. 716 12. References 718 12.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, . 725 12.2. Informative References 727 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 728 of Things Software Update (IoTSU) Workshop 2016", 729 RFC 8240, DOI 10.17487/RFC8240, September 2017, 730 . 732 [STRIDE] Microsoft, "The STRIDE Threat Model", January 2018. 734 12.3. URIs 736 [1] mailto:suit@ietf.org 738 Appendix A. Threat Model, User Stories, Security Requirements, and 739 Usability Requirements 741 A.1. Threat Model 743 This appendix aims to provide information about the threats that were 744 considered, the security requirements that are derived from those 745 threats and the fields that permit implementation of the security 746 requirements. This model uses the S.T.R.I.D.E. [STRIDE] approach. 747 Each threat is classified according to: 749 - Spoofing Identity 751 - Tampering with data 753 - Repudiation 755 - Information disclosure 757 - Denial of service 759 - Elevation of privilege 761 This threat model only covers elements related to the transport of 762 firmware updates. It explicitly does not cover threats outside of 763 the transport of firmware updates. For example, threats to an IoT 764 device due to physical access are out of scope. 766 A.2. Threat Descriptions 768 A.2.1. Threat MFT1: Old Firmware 770 Classification: Escalation of Privilege 772 An attacker sends an old, but valid manifest with an old, but valid 773 firmware image to a device. If there is a known vulnerability in the 774 provided firmware image, this may allow an attacker to exploit the 775 vulnerability and gain control of the device. 777 Threat Escalation: If the attacker is able to exploit the known 778 vulnerability, then this threat can be escalated to ALL TYPES. 780 Mitigated by: MFSR1 782 A.2.2. Threat MFT2: Mismatched Firmware 784 Classification: Denial of Service 786 An attacker sends a valid firmware image, for the wrong type of 787 device, signed by an actor with firmware installation permission on 788 both types of device. The firmware is verified by the device 789 positively because it is signed by an actor with the appropriate 790 permission. This could have wide-ranging consequences. For devices 791 that are similar, it could cause minor breakage, or expose security 792 vulnerabilities. For devices that are very different, it is likely 793 to render devices inoperable. 795 Mitigated by: MFSR2 797 A.2.3. Threat MFT3: Offline device + Old Firmware 799 Classification: Escalation of Privilege 801 An attacker targets a device that has been offline for a long time 802 and runs an old firmware version. The attacker sends an old, but 803 valid manifest to a device with an old, but valid firmware image. 804 The attacker-provided firmware is newer than the installed one but 805 older than the most recently available firmware. If there is a known 806 vulnerability in the provided firmware image then this may allow an 807 attacker to gain control of a device. Because the device has been 808 offline for a long time, it is unaware of any new updates. As such 809 it will treat the old manifest as the most current. 811 Threat Escalation: If the attacker is able to exploit the known 812 vulnerability, then this threat can be escalated to ALL TYPES. 814 Mitigated by: MFSR3 816 A.2.4. Threat MFT4: The target device misinterprets the type of payload 818 Classification: Denial of Service 820 If a device misinterprets the type of the firmware image, it may 821 cause a device to install a firmware image incorrectly. An 822 incorrectly installed firmware image would likely cause the device to 823 stop functioning. 825 Threat Escalation: An attacker that can cause a device to 826 misinterpret the received firmware image may gain escalation of 827 privilege and potentially expand this to all types of threat. 829 Mitigated by: MFSR4 831 A.2.5. Threat MFT5: The target device installs the payload to the wrong 832 location 834 Classification: Denial of Service 836 If a device installs a firmware image to the wrong location on the 837 device, then it is likely to break. For example, a firmware image 838 installed as an application could cause a device and/or an 839 application to stop functioning. 841 Threat Escalation: An attacker that can cause a device to 842 misinterpret the received code may gain escalation of privilege and 843 potentially expand this to all types of threat. 845 Mitigated by: MFSR4 847 A.2.6. Threat MFT6: Redirection 849 Classification: Denial of Service 851 If a device does not know where to obtain the payload for an update, 852 it may be redirected to an attacker's server. This would allow an 853 attacker to provide broken payloads to devices. 855 Mitigated by: MFSR4 857 A.2.7. Threat MFT7: Payload Verification on Boot 859 Classification: All Types 861 An attacker replaces a newly downloaded firmware after a device 862 finishes verifying a manifest. This could cause the device to 863 execute the attacker's code. This attack likely requires physical 864 access to the device. However, it is possible that this attack is 865 carried out in combination with another threat that allows remote 866 execution. 868 Mitigated by: MFSR4 870 A.2.8. Threat MFT8: Unauthenticated Updates 872 Classification: All Types 874 If an attacker can install their firmware on a device, by 875 manipulating either payload or metadata, then they have complete 876 control of the device. 878 Mitigated by: MFSR5 880 A.2.9. Threat MFT9: Unexpected Precursor images 882 Classification: Denial of Service 884 An attacker sends a valid, current manifest to a device that has an 885 unexpected precursor image. If a payload format requires a precursor 886 image (for example, delta updates) and that precursor image is not 887 available on the target device, it could cause the update to break. 889 Threat Escalation: An attacker that can cause a device to install a 890 payload against the wrong precursor image could gain escalation of 891 privilege and potentially expand this to all types of threat. 893 Mitigated by: MFSR4 895 A.2.10. Threat MFT10: Unqualified Firmware 897 Classification: Denial of Service, Escalation of Privilege 899 This threat can appear in several ways, however it is ultimately 900 about interoperability of devices with other systems. The owner or 901 operator of a network needs to approve firmware for their network in 902 order to ensure interoperability with other devices on the network, 903 or the network itself. If the firmware is not qualified, it may not 904 work. Therefore, if a device installs firmware without the approval 905 of the network owner or operator, this is a threat to devices and the 906 network. 908 Example 1: We assume that OEMs expect the rights to create firmware, 909 but that Operators expect the rights to qualify firmware as fit-for- 910 purpose on their networks. 912 An attacker obtains a manifest for a device on Network A. They send 913 that manifest to a device on Network B. Because Network A and 914 Network B are different, and the firmware has not been qualified for 915 Network B, the target device is disabled by this unqualified, but 916 signed firmware. 918 This is a denial of service because it can render devices inoperable. 919 This is an escalation of privilege because it allows the attacker to 920 make installation decisions that should be made by the Operator. 922 Example 2: Multiple devices that interoperate are used on the same 923 network. Some devices are manufactured by OEM A and other devices by 924 OEM B. These devices communicate with each other. A new firmware is 925 released by OEM A that breaks compatibility with OEM B devices. An 926 attacker sends the new firmware to the OEM A devices without approval 927 of the network operator. This breaks the behaviour of the larger 928 system causing denial of service and possibly other threats. Where 929 the network is a distributed SCADA system, this could cause 930 misbehaviour of the process that is under control. 932 Threat Escalation: If the firmware expects configuration that is 933 present in Network A devices, but not Network B devices, then the 934 device may experience degraded security, leading to threats of All 935 Types. 937 Mitigated by: MFSR6 939 A.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for 940 Vulnerability Analysis 942 Classification: All Types 944 An attacker wants to mount an attack on an IoT device. To prepare 945 the attack he or she retrieves the provided firmware image and 946 performs reverse engineering of the firmware image to analyze it for 947 specific vulnerabilities. 949 Mitigated by: MFSR7 951 A.3. Security Requirements 953 The security requirements here are a set of policies that mitigate 954 the threats described in the previous section. 956 A.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers 958 Only an actor with firmware installation authority is permitted to 959 decide when device firmware can be installed. To enforce this rule, 960 Manifests MUST contain monotonically increasting sequence numbers. 961 Manifests MAY use UTC epoch timestamps to coordinate monotonically 962 increasting sequence numbers across many actors in many locations. 963 Devices MUST reject manifests with sequence numbers smaller than any 964 onboard sequence number. 966 N.B. This is not a firmware version. It is a manifest sequence 967 number. A firmware version may be rolled back by creating a new 968 manifest for the old firmware version with a later sequence number. 970 Mitigates: Threat MFT1 Implemented by: Manifest Field: Timestamp 972 A.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers 974 Devices MUST only apply firmware that is intended for them. Devices 975 MUST know with fine granularity that a given update applies to their 976 vendor, model, hardware revision, software revision. Human-readable 977 identifiers are often error-prone in this regard, so unique 978 identifiers SHOULD be used. 980 Mitigates: Threat MFT2 Implemented by: Manifest Fields: Vendor ID 981 Condition, Class ID Condition 983 A.3.3. Security Requirement MFSR3: Best-Before Timestamps 985 Firmware MAY expire after a given time. Devices MAY provide a secure 986 clock (local or remote). If a secure clock is provided and the 987 Firmware manifest has a best-before timestamp, the device MUST reject 988 the manifest if current time is larger than the best-before time. 990 Mitigates: Threat MFT3 Implemented by: Manifest Field: Best-Before 991 timestamp condition 993 A.3.4. Security Requirement MFSR4: Signed Payload Descriptor 995 All descriptive information about the payload MUST be signed. This 996 MUST include: 998 - The type of payload (which may be independent of format) 1000 - The location to store the payload 1002 - The payload digest, in each state of installation (encrypted, 1003 plaintext, installed, etc.) 1005 - The payload size 1007 - The payload format 1009 - Where to obtain the payload 1011 - All instructions or parameters for applying the payload 1013 - Any rules that identify whether or not the payload can be used on 1014 this device 1016 Mitigates: Threats MFT4, MFT5, MFT6, MFT7, MFT9 Implemented by: 1017 Manifest Fields: Vendor ID Condition, Class ID Condition, Precursor 1018 Image Digest Condition, Payload Format, Storage Location, URIs, 1019 Digests, Size 1021 A.3.5. Security Requirement MFSR5: Cryptographic Authenticity 1023 The authenticity of an update must be demonstrable. Typically, this 1024 means that updates must be digitally signed. Because the manifest 1025 contains information about how to install the update, the manifest's 1026 authenticity must also be demonstrable. To reduce the overhead 1027 required for validation, the manifest contains the digest of the 1028 firmware image, rather than a second digitial signature. The 1029 authenticity of the manifest can be verified with a digital 1030 signature, the authenticity of the firmware image is tied to the 1031 manifest by the use of a fingerprint of the firmware image. 1033 Mitigates: Threat MFT8 Implemented by: Signature 1035 A.3.6. Security Requirement MFSR6: Rights Require Authenticity 1037 If a device grants different rights to different actors, exercising 1038 those rights MUST be accompanied by proof of those rights, in the 1039 form of proof of authenticity. Authenticity mechanisms such as those 1040 required in MFSR5 are acceptable but need to follow the end-to-end 1041 security model. 1043 For example, if a device has a policy that requires that firmware 1044 have both an Authorship right and a Qualification right and if that 1045 device grants Authorship and Qualification rights to different 1046 parties, such as an OEM and an Operator, respectively, then the 1047 firmware cannot be installed without proof of rights from both the 1048 OEM and the Operator. 1050 Mitigates: MFT10 Implemented by: Signature 1052 A.3.7. Security Requirement MFSR7: Firmware encryption 1054 Firmware images must be encrypted to prevent third parties, including 1055 attackers, from reading the content of the firmware image and to 1056 reverse engineer the code. 1058 Mitigates: MFT11 Implemented by: Manifest Field: Content Key 1059 Distribution Method 1061 A.4. User Stories 1063 User stories provide expected use cases. These are used to feed into 1064 usability requirements. 1066 A.4.1. Use Case MFUC1: Installation Instructions 1068 As an OEM for IoT devices, I want to provide my devices with 1069 additional installation instructions so that I can keep process 1070 details out of my payload data. 1072 Some installation instructions might be: 1074 - Specify a package handler 1076 - Use a table of hashes to ensure that each block of the payload is 1077 validate before writing. 1079 - Run post-processing script after the update is installed 1081 - Do not report progress 1083 - Pre-cache the update, but do not install 1085 - Install the pre-cached update matching this manifest 1087 - Install this update immediately, overriding any long-running 1088 tasks. 1090 Satisfied by: MFUR1 1092 A.4.2. Use Case MFUC2: Reuse Local Infrastructure 1094 As an Operator of IoT devices, I would like to tell my devices to 1095 look at my own infrastructure for payloads so that I can manage the 1096 traffic generated by firmware updates on my network and my peers' 1097 networks. 1099 Satisfied by: MFUR2, MFUR3 1101 A.4.3. Use Case MFUC3: Modular Update 1103 As an OEM of IoT devices, I want to divide my firmware into 1104 frequently updated and infrequently updated components, so that I can 1105 reduce the size of updates and make different parties responsible for 1106 different components. 1108 Satisfied by: MFUR3 1110 A.4.4. Use Case MFUC4: Multiple Authorisations 1112 As an Operator, I want to ensure the quality of a firmware update 1113 before installing it, so that I can ensure a high standard of 1114 reliability on my network. The OEM may restrict my ability to create 1115 firmware, so I cannot be the only authority on the device. 1117 Satisfied by: MFUR4 1119 A.4.5. Use Case MFUC5: Multiple Payload Formats 1121 As a OEM or Operator of devices, I want to be able to send multiple 1122 payload formats to suit the needs of my update, so that I can 1123 optimise the bandwidth used by my devices. 1125 Satisfied by: MFUR5 1127 A.4.6. Use Case MFUC6: IP Protection 1129 As an OEM or developer for IoT devices, I want to protect the IP 1130 contained in the firmware image, such as the utilized algorithms. 1131 The need for protecting IP may have also been imposed on my due to 1132 the use of some third party code libraries. 1134 Satisfied by: MFSR7 1136 A.5. Usability Requirements 1138 The following usability requirements satisfy the user stories listed 1139 above. 1141 A.5.1. Usability Requirement MFUR1 1143 It must be possible to write additional installation instructions 1144 into the manifest. 1146 Satisfies: Use-Case MFUC1 Implemented by: Manifest Field: Directives 1148 A.5.2. Usability Requirement MFUR2 1150 It must be possible to redirect payload fetches. This applies where 1151 two manifests are used in conjunction. For example, an OEM manifest 1152 specifies a payload and signs it, and provides a URI for that 1153 payload. An Operator creates a second manifest, with a dependency on 1154 the first. They use this second manifest to override the URIs 1155 provided by the OEM, directing them into their own infrastructure 1156 instead. 1158 Satisfies: Use-Case MFUC2 Implemented by: Manifest Field: Aliases 1160 A.5.3. Usability Requirement MFUR3 1162 It MUST be possible to link multiple manifests together so that a 1163 multi-component update can be described. This allows multiple 1164 parties with different permissions to collaborate in creating a 1165 single update for the IoT device, across multiple components. 1167 Satisfies: Use-Case MFUC2, MFUC3 Implemented by: Manifest Field: 1168 Dependencies 1170 A.5.4. Usability Requirement MFUR4 1172 It MUST be possible to sign a manifest multiple times so that 1173 signatures from multiple parties with different permissions can be 1174 required in order to authorise installation of a manifest. 1176 Satisfies: Use-Case MFUC4 Implemented by: COSE Signature (or similar) 1178 A.5.5. Usability Requirement MFUR5 1180 The manifest format MUST accommodate any payload format that an 1181 operator or OEM wishes to use. Some examples of payload format would 1182 be: 1184 - Binary 1186 - Elf 1188 - Differential 1190 - Compressed 1192 - Packed configuration 1194 Satisfies: Use-Case MFUC5 Implemented by: Manifest Field: Payload 1195 Format 1197 A.6. Manifest Fields 1199 Each manifest field is anchored in a security requirement or a 1200 usability requirement. The manifest fields are described below and 1201 justified by their requirements. 1203 A.6.1. Manifest Field: Timestamp 1205 A monotonically increasing sequence number. For convenience, a 1206 timestamp implements the requirement of a monotonically increasing 1207 sequence number. This allows global synchronisation of sequence 1208 numbers without any additional management. 1210 Implements: Security Requirement MFSR1. 1212 A.6.2. Manifest Field: Vendor ID Condition 1214 Vendor IDs MUST be unique. This is to prevent similarly, or 1215 identically named entities from different geographic regions from 1216 colliding in their customer's infrastructure. Recommended practice 1217 is to use type 5 UUIDs with the vendor's domain name and the UUID DNS 1218 prefix. Other options include type 1 and type 4 UUIDs. 1220 Implements: Security Requirement MFSR2, MFSR4. 1222 A.6.3. Manifest Field: Class ID Condition 1224 Class Identifiers MUST be unique within a Vendor ID. This is to 1225 prevent similarly, or identically named devices colliding in their 1226 customer's infrastructure. Recommended practice is to use type 5 1227 UUIDs with the model, hardware revision, etc. and use the Vendor ID 1228 as the UUID prefix. Other options include type 1 and type 4 UUIDs. 1229 A device "Class" is defined as any device that can run the same 1230 firmware without modification. Classes MAY be implemented in a more 1231 granular way. Classes MUST NOT be implemented in a less granular 1232 way. Class ID can encompass model name, hardware revision, software 1233 revision. Devices MAY have multiple Class IDs. 1235 Implements: Security Requirement MFSR2, MFSR4. 1237 A.6.4. Manifest Field: Precursor Image Digest Condition 1239 When a precursor image is required by the payload format, a precursor 1240 image digest condition MUST be present in the conditions list. 1242 Implements: Security Requirement MFSR4 1244 A.6.5. Manifest Field: Best-Before timestamp condition 1246 This field tells a device the last application time. This is only 1247 usable in conjunction with a secure clock. 1249 Implements: Security Requirement MFSR3 1251 A.6.6. Manifest Field: Payload Format 1253 The format of the payload must be indicated to devices is in an 1254 unambiguous way. This field provides a mechanism to describe the 1255 payload format, within the signed metadata. 1257 Implements: Security Requirement MFSR4, Usability Requirement MFUR5 1259 A.6.7. Manifest Field: Storage Location 1261 This field tells the device which component is being updated. The 1262 device can use this to establish which permissions are necessary and 1263 the physical location to use. 1265 Implements: Security Requirement MFSR4 1267 A.6.8. Manifest Field: URIs 1269 This field is a list of weighted URIs that the device uses to select 1270 where to obtain a payload. 1272 Implements: Security Requirement MFSR4 1274 A.6.9. Manifest Field: Digests 1276 This field is a map of digests, each for a separate stage of 1277 installation. This allows the target device to ensure authenticity 1278 of the payload at every step of installation. 1280 Implements: Security Requirement MFSR4 1282 A.6.10. Manifest Field: Size 1284 The size of the payload in bytes. 1286 Implements: Security Requirement MFSR4 1288 A.6.11. Manifest Field: Signature 1290 This is not strictly a manifest field. Instead, the manifest is 1291 wrapped by a standardised authentication container, such as a COSE or 1292 CMS signature object. The authentication container MUST support 1293 multiple actors and multiple authentications. 1295 Implements: Security Requirement MFSR5, MFSR6, MFUR4 1297 A.6.12. Manifest Field: Directives 1299 A list of instructions that the device should execute, in order, when 1300 installing the payload. 1302 Implements: Usability Requirement MFUR1 1304 A.6.13. Manifest Field: Aliases 1306 A list of URI/Digest pairs. A device should build an alias table 1307 while paring a manifest tree and treat any aliases as top-ranked URIs 1308 for the corresponding digest. 1310 Implements: Usability Requirement MFUR2 1312 A.6.14. Manifest Field: Dependencies 1314 A list of URI/Digest pairs that refer to other manifests by digest. 1315 The manifests that are linked in this way must be acquired and 1316 installed simultaneously in order to form a complete update. 1318 Implements: Usability Requirement MFUR3 1320 A.6.15. Manifest Field: Content Key Distribution Method 1322 Encrypting firmware images requires symmetric content encryption 1323 keys. Since there are several methods to protect or distribute the 1324 symmetric content encryption keys, the manifest contains a field for 1325 the Content Key Distribution Method. One examples for such a Content 1326 Key Distribution Method is the usage of Key Tables, pointing to 1327 content encryption keys, which themselves are encrypted using the 1328 public keys of devices. 1330 Implements: Security Requirement MFSR7. 1332 Authors' Addresses 1334 Brendan Moran 1335 Arm Limited 1337 EMail: Brendan.Moran@arm.com 1339 Milosch Meriac 1340 Arm Limited 1342 EMail: Milosch.Meriac@arm.com 1343 Hannes Tschofenig 1344 Arm Limited 1346 EMail: hannes.tschofenig@gmx.net