idnits 2.17.1 draft-moran-fud-architecture-00.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 (July 18, 2017) is 2474 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 511 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Moran 3 Internet-Draft M. Meriac 4 Intended status: Informational H. Tschofenig 5 Expires: January 19, 2018 ARM Limited 6 July 18, 2017 8 A Firmware Update Architecture for Internet of Things Devices 9 draft-moran-fud-architecture-00 11 Abstract 13 Vulnerabilities with IoT devices have raised the need for a solid and 14 secure firmware update mechanism that is also suitable for 15 constrained devices. Incorporating such update mechanism to fix 16 vulnerabilities, to update configuration settings as well as adding 17 new functionality is recommended by security experts. 19 This document specifies requires and an architecture for a firmware 20 update mechanism aimed for Internet of Things (IoT) devices. The 21 architecture is agnostic to the transport of the firmware images and 22 associated 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 January 19, 2018. 45 Copyright Notice 47 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 76 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. Agnostic to how firmware images are distributed . . . . . 4 78 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 4 79 3.3. Uses state-of-the-art security mechanisms . . . . . . . . 5 80 3.4. High reliability . . . . . . . . . . . . . . . . . . . . 5 81 3.5. Minimal bootloader . . . . . . . . . . . . . . . . . . . 5 82 3.6. Minimal impact on existing firmware formats . . . . . . . 5 83 3.7. Robust permissions . . . . . . . . . . . . . . . . . . . 6 84 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 85 5. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 7. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 8 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 10. Mailing List Information . . . . . . . . . . . . . . . . . . 11 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 12.2. Informative References . . . . . . . . . . . . . . . . . 11 95 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 When developing IoT devices, one of the most difficult problems to 101 solve is how to update the firmware on the device. Once the device 102 is deployed, firmware updates play a critical part in its lifetime, 103 particularly when devices have a long lifetime, are deployed in 104 remote or inaccessible areas or where manual intervention is cost 105 prohibitive or otherwise difficult: - Fixes to bugs in software can 106 be applied to the device with a firmware update. - New functionality 107 can be added to the device with a firmware update. 109 The firmware update process has to ensure that - The firmware is 110 authenticated (attempts to flash a malicious firmware are prevented). 111 - The firmware can be confidentiality protected (attempts by an 112 adversary to recover the plaintext binary can be prevented). 114 2. Conventions and Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in RFC 119 2119 [RFC2119]. 121 This document uses the following entities: 123 - Author: The author is the entity that creates the firmware image, 124 signs and/or encrypts it and attaches a manifest to it. The 125 author is most likely a developer using a set of tools. In some 126 deployments the author only triggers the signing/encryption but 127 the actual cryptographic operation are executed by a service or by 128 a party on behalf of the developer. 130 - Device: The device is the recipient of the firmware image and the 131 manifest. The goal is to update the firmware of the device. 133 - Untrusted Storage: Firmware images and manifests are stored on 134 untrusted fileservers or cloud storage infrastructure. Some 135 deployments may require storage of the firmware images/manifests 136 to be stored on various entities before they reach the device. 138 Additionally, the following terms are defined: 140 - Manifest: The manifest contains meta-data about the firmware image 141 and is protected against modification. 143 - Firmware Image: The firmware image is a binary that may contain 144 the complete software of a device or a subset of it. The firmware 145 image may consist of multiple images, if the device contains more 146 than one microcontroller. The image may consist of a differential 147 update for performance reasons. 149 3. Requirements 151 The firmware update mechanism described in this specification was 152 designed with the following requirements in mind: 154 - Agnostic to how firmware images are distributed 156 - Friendly to broadcast delivery 158 - Uses state-of-the-art security mechanisms 160 - Operates with a small bootloader 162 - Minimal impact on existing firmware formats 164 - Robust permissions 166 3.1. Agnostic to how firmware images are distributed 168 Firmware images can be conveyed to devices in a variety of ways, 169 including USB, UART, WiFi, BLE, low-power WAN technologies, etc and 170 use different protocol mechanisms (e.g., CoAP, HTTP). The specified 171 mechanism needs to be agnostic to the distribution of the firmware 172 images/manifests. 174 3.2. Friendly to broadcast delivery 176 For an update to be broadcast friendly, it must not rely on any 177 transport security. In addition, the same message must be 178 deliverable to many devices; both those to which it applies and those 179 to which it does not without a chance that the wrong device will 180 accept the update. Considerations that apply to network broadcasts 181 apply equally to the use of third-party content distribution networks 182 for payload distribution. 184 3.3. Uses state-of-the-art security mechanisms 186 End-to-end security between the author and the device, as shown in 187 Section 4, is used to ensure that the device can verify firmware 188 images and manifests produced by authorized authors. 190 If the update payload is to be encrypted, it must be done in such a 191 way that every intended recipient can decrypt it. The information 192 that is encrypted individually for each device must be an absolute 193 minimum. 195 Rollback attacks must be prevented. 197 All information necessary for a device to make a decision about the 198 installation of an update must fit into the available RAM of a 199 constrained IoT device. This prevents flash write exhaustion. 201 Since parsers are known sources of bugs it must be easy to parse only 202 those fields which are required to validate at least one signature 203 with minimal exposure. 205 3.4. High reliability 207 A power failure at any time must not cause a failure of the device. 208 A failure to validate any part of an update must not cause a failure 209 of the device. To achieve this, the device is required to provide a 210 minimum of two storage locations for firmware and one bootable 211 location for firmware. Note: This is an implementation requirement 212 rather than a requirement on the manifest format. 214 3.5. Minimal bootloader 216 The bootloader must be minimal, containing only the flash and 217 cryptographic primitives necessary to read the stored firmware, 218 validate the received firmware, and write the bootable firmware. The 219 bootloader should not require updating, since a failed update poses a 220 risk in reliability. If more functionality is required in the 221 bootloader, it must use a two-stage bootloader, with the first stage 222 comprising the functionality defined above. 224 3.6. Minimal impact on existing firmware formats 226 The firmware update must not require changes to existing firmware 227 formats. 229 3.7. Robust permissions 231 A device may have many modules that require updating individually. 232 It may also need to trust several different actors in order to 233 authorize an update. For example, a firmware author may not have the 234 authority to install firmware on a device in critical infrastructure 235 without the authorization of a device operator. In this case, the 236 device should reject firmware updates unless they are signed both by 237 the firmware author and by the device operator. 239 To facilitate complex use-cases such as this, updates require several 240 permissions: 242 - Author 244 - Store 246 - Apply 248 - Approve 250 - Qualify 252 4. Architecture 254 The architecture graphically shown below illustrates that an author 255 creates a firmware image and a manifest. The firmware image may be 256 encrypted and will be integrity protected. The meta-data is 257 integrity protected. When the author is ready to distribute the 258 firmware image it conveys it using his or her favorite communication 259 channel to the device, which will typically involve the use of 260 untrusted storage, like a file server. Whether the firmware image 261 and the manifest is pushed to the device or fetched by the device is 262 outside the scope of this work and existing device management 263 protocols can be used for efficiently distributing this information. 265 The following assumptions are made to allow the device to verify the 266 received firmware image and manifest before updating software: 268 - To accept an update, a device needs to decide whether the author 269 signing the firmware image and the manifest is authorized to make 270 the updates. We use public key cryptography to accomplish this. 271 The device verifies the signature covering the manifest using a 272 digital signature algorithm. The device is provisioned with a 273 trust anchor that is used to validate the digital signature 274 produced by the author. This trust anchor is potentially 275 different from the trust anchor used to validate the digital 276 signature produced for other protocols (such as device management 277 protocols). This trust anchor may be provisioned to the device 278 during manufacturing. 280 - For confidentiality protection of firmware imagines the author 281 needs to be in possession of the certificate/public key of a 282 device. 284 +-----------+ 285 +--------+ Firmware Image | | Firmware Image +--------+ 286 | | + Manifest | Untrusted | + Manifest | | 287 | Device |<-----------------| Storage |<------------------| Author | 288 | | | | | | 289 +--------+ +-----------+ +--------+ 290 ^ * 291 * * 292 ************************************************************ 293 End-to-End Security 295 5. Manifest 297 In order for a device to apply an update, it has to make several 298 decisions about the update: 300 - Does it trust the author of the update? 302 - Has the firmware been corrupted? 304 - Does the firmware update apply to this device? 306 - Is the update older than the active firmware? 308 - When should the device apply the update? 310 - How should the device apply the update? 312 - What kind of firmware binary is it? 314 - Where should the update be obtained? 316 - Where should the firmware be stored? 318 The manifest format encodes the information that devices need in 319 order to make these decisions. 321 6. Manifest 323 The manifest is a data structure that contains the following 324 information: 326 - information about the device(s) the firmware image is intented to 327 be applied to, 329 - information about when the firmware update has to be applied, 331 - information about when the manifest was created, 333 - dependencies to other manifests, 335 - pointers to the firmware image and information about the format, 337 - information about where to store the firmware image, 339 - cryptographic information, such as digital signatures. 341 The manifest structure is described in a companion document. 343 7. Example Flow 345 The following example message flow illustrates the interaction for 346 distributing a firmware image to a device starting with an author 347 uploading the new firmware to untrusted storage and creating a 348 manifest. 350 +--------+ +-----------------+ +------+ 351 | Author | |Untrusted Storage| |Device| 352 +--------+ +-----------------+ +------+ 353 | | | 354 | Create Firmware | | 355 |--------------- | | 356 | | | | 357 |<-------------- | | 358 | | | 359 | Upload Firmware | | 360 |------------------>| | 361 | | | 362 | Create Manifest | | 363 |---------------- | | 364 | | | | 365 |<--------------- | | 366 | | | 367 | Sign Manifest | | 368 |-------------- | | 369 | | | | 370 |<------------- | | 371 | | | 372 | Upload Manifest | | 373 |------------------>| | 374 | | | 375 | | Query Manifest | 376 | |<--------------------| 377 | | | 378 | | Send Manifest | 379 | |-------------------->| 380 | | | 381 | | | Validate Manifest 382 | | |------------------ 383 | | | | 384 | | |<----------------- 385 | | | 386 | | Request Firmware | 387 | |<--------------------| 388 | | | 389 | | Send Firmware | 390 | |-------------------->| 391 | | | 392 | | | Verify Firmware 393 | | |--------------- 394 | | | | 395 | | |<-------------- 396 | | | 397 | | | Store Firmware 398 | | |-------------- 399 | | | | 400 | | |<------------- 401 | | | 402 | | | Reboot 403 | | |------- 404 | | | | 405 | | |<------ 406 | | | 407 | | | Bootloader validates 408 | | | Firmware 409 | | |---------------------- 410 | | | | 411 | | |<--------------------- 412 | | | 413 | | | Bootloader activates 414 | | | Firmware 415 | | |---------------------- 416 | | | | 417 | | |<--------------------- 418 | | | 419 | | | Bootloader transfers 420 | | | control to new Firmware 421 | | |---------------------- 422 | | | | 423 | | |<--------------------- 424 | | | 426 8. IANA Considerations 428 This document does not require any actions by IANA. 430 9. Security Considerations 432 Firmware updates fix security vulnerabilities and are considered to 433 be an important building block in securing IoT devices. Due to the 434 importance of firmware updates for IoT devices the Internet 435 Architecture Board (IAB) organized a 'Workshop on Internet of Things 436 (IoT) Software Update (IOTSU)' which took place at Trinity College 437 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 438 the big picture. A report about this workshop can be found at 439 [I-D.iab-iotsu-workshop]. This document (and associated 440 specifications) offer a standardized firmware manifest format and an 441 approach for offering end-to-end security from the author to the 442 device. 444 There are, however, many other considerations raised during the 445 workshop. Many of them are outside the scope of standardization 446 organizations since they fall into the realm of product engineering, 447 regulatory frameworks, and business models. The following 448 considerations are outside the scope of this document, namely 450 - installing firmware updates in a robust fashion so that the update 451 does not break the device functionality of the environment this 452 device operates in. 454 - installing firmware updates in a timely fashion considering the 455 complexity of the decision making process of updating devices, 456 potential re-certification requirements, and the need for user's 457 consent to install updates. 459 - the distribution of the actual firmware update, potentially in an 460 efficient manner to a large number of devices without human 461 involvement. 463 - energy efficiency and battery lifetime considerations. 465 - key management required for verifying the digitial signature 466 protecting the manifest. 468 - incentives for manufacturers to offer a firmware update mechanism 469 as part of their IoT products. 471 10. Mailing List Information 473 The discussion list for this document is located at the e-mail 474 address fud@ietf.org [1]. Information on the group and information 475 on how to subscribe to the list is at 476 https://www1.ietf.org/mailman/listinfo/fud 478 Archives of the list can be found at: https://www.ietf.org/mail- 479 archive/web/fud/current/index.html 481 11. Acknowledgements 483 We would like the following persons for their support in designing 484 this mechanism 486 - Geraint Luff 488 - Amyas Phillips 490 - Dan Ros 492 12. References 494 12.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 12.2. Informative References 503 [I-D.iab-iotsu-workshop] 504 Tschofenig, H. and S. Farrell, "Report from the Internet 505 of Things (IoT) Software Update (IoTSU) Workshop 2016", 506 draft-iab-iotsu-workshop-01 (work in progress), February 507 2017. 509 12.3. URIs 511 [1] mailto:fud@ietf.org 513 Authors' Addresses 515 Brendan Moran 516 ARM Limited 518 EMail: Brendan.Moran@arm.com 520 Milosch Meriac 521 ARM Limited 523 EMail: Milosch.Meriac@arm.com 525 Hannes Tschofenig 526 ARM Limited 528 EMail: hannes.tschofenig@gmx.net