idnits 2.17.1 draft-moran-suit-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 (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 514 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: May 3, 2018 ARM Limited 6 October 30, 2017 8 A Firmware Update Architecture for Internet of Things Devices 9 draft-moran-suit-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 May 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 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: 107 - Fixes to bugs in software can be applied to the device with a 108 firmware update. 110 - New functionality can be added to the device with a firmware 111 update. 113 The firmware update process has to ensure that 115 - The firmware is authenticated (attempts to flash a malicious 116 firmware are prevented). 118 - The firmware can be confidentiality protected (attempts by an 119 adversary to recover the plaintext binary can be prevented). 121 2. Conventions and Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in RFC 126 2119 [RFC2119]. 128 This document uses the following entities: 130 - Author: The author is the entity that creates the firmware image, 131 signs and/or encrypts it and attaches a manifest to it. The 132 author is most likely a developer using a set of tools. 134 - Device: The device is the recipient of the firmware image and the 135 manifest. The goal is to update the firmware of the device. 137 - Untrusted Storage: Firmware images and manifests are stored on 138 untrusted fileservers or cloud storage infrastructure. Some 139 deployments may require storage of the firmware images/manifests 140 to be stored on various entities before they reach the device. 142 Additionally, the following terms are defined: 144 - Manifest: The manifest contains meta-data about the firmware image 145 and is protected against modification. 147 - Firmware Image: The firmware image is a binary that may contain 148 the complete software of a device or a subset of it. The firmware 149 image may consist of multiple images, if the device contains more 150 than one microcontroller. The image may consist of a differential 151 update for performance reasons. 153 3. Requirements 155 The firmware update mechanism described in this specification was 156 designed with the following requirements in mind: 158 - Agnostic to how firmware images are distributed 160 - Friendly to broadcast delivery 162 - Uses state-of-the-art security mechanisms 164 - Operates with a small bootloader 166 - Minimal impact on existing firmware formats 168 - Robust permissions 170 3.1. Agnostic to how firmware images are distributed 172 Firmware images can be conveyed to devices in a variety of ways, 173 including USB, UART, WiFi, BLE, low-power WAN technologies, etc and 174 use different protocol mechanisms (e.g., CoAP, HTTP). The specified 175 mechanism needs to be agnostic to the distribution of the firmware 176 images/manifests. 178 3.2. Friendly to broadcast delivery 180 For an update to be broadcast friendly, it must not rely on any 181 transport security. In addition, the same message must be 182 deliverable to many devices; both those to which it applies and those 183 to which it does not without a chance that the wrong device will 184 accept the update. Considerations that apply to network broadcasts 185 apply equally to the use of third-party content distribution networks 186 for payload distribution. 188 3.3. Uses state-of-the-art security mechanisms 190 End-to-end security between the author and the device, as shown in 191 Section 4, is used to ensure that the device can verify firmware 192 images and manifests produced by authorized authors. 194 If the update payload is to be encrypted, it must be done in such a 195 way that every intended recipient can decrypt it. The information 196 that is encrypted individually for each device must be an absolute 197 minimum. 199 Rollback attacks must be prevented. 201 All information necessary for a device to make a decision about the 202 installation of an update must fit into the available RAM of a 203 constrained IoT device. This prevents flash write exhaustion. 205 Since parsers are known sources of bugs it must be easy to parse only 206 those fields which are required to validate at least one signature 207 with minimal exposure. 209 3.4. High reliability 211 A power failure at any time must not cause a failure of the device. 212 A failure to validate any part of an update must not cause a failure 213 of the device. To achieve this, the device is required to provide a 214 minimum of two storage locations for firmware and one bootable 215 location for firmware. Note: This is an implementation requirement 216 rather than a requirement on the manifest format. 218 3.5. Minimal bootloader 220 The bootloader must be minimal, containing only the flash and 221 cryptographic primitives necessary to read the stored firmware, 222 validate the received firmware, and write the bootable firmware. The 223 bootloader should not require updating, since a failed update poses a 224 risk in reliability. If more functionality is required in the 225 bootloader, it must use a two-stage bootloader, with the first stage 226 comprising the functionality defined above. 228 3.6. Minimal impact on existing firmware formats 230 The firmware update must not require changes to existing firmware 231 formats. 233 3.7. Robust permissions 235 A device may have many modules that require updating individually. 236 It may also need to trust several different actors in order to 237 authorize an update. For example, a firmware author may not have the 238 authority to install firmware on a device in critical infrastructure 239 without the authorization of a device operator. In this case, the 240 device should reject firmware updates unless they are signed both by 241 the firmware author and by the device operator. 243 To facilitate complex use-cases such as this, updates require several 244 permissions: 246 - Author 248 - Store 250 - Apply 252 - Approve 254 - Qualify 256 4. Architecture 258 The architecture graphically shown below illustrates that an author 259 creates a firmware image and a manifest. The firmware image may be 260 encrypted and will be integrity protected. The meta-data is 261 integrity protected. When the author is ready to distribute the 262 firmware image it conveys it using his or her favorite communication 263 channel to the device, which will typically involve the use of 264 untrusted storage, like a file server. Whether the firmware image 265 and the manifest is pushed to the device or fetched by the device is 266 outside the scope of this work and existing device management 267 protocols can be used for efficiently distributing this information. 269 The following assumptions are made to allow the device to verify the 270 received firmware image and manifest before updating software: 272 - To accept an update, a device needs to decide whether the author 273 signing the firmware image and the manifest is authorized to make 274 the updates. We use public key cryptography to accomplish this. 275 The device verifies the signature covering the manifest using a 276 digital signature algorithm. The device is provisioned with a 277 trust anchor that is used to validate the digital signature 278 produced by the author. This trust anchor is potentially 279 different from the trust anchor used to validate the digital 280 signature produced for other protocols (such as device management 281 protocols). This trust anchor may be provisioned to the device 282 during manufacturing. 284 - For confidentiality protection of firmware imagines the author 285 needs to be in possession of the certificate/public key of a 286 device. 288 +-----------+ 289 +--------+ Firmware Image | | Firmware Image +--------+ 290 | | + Manifest | Untrusted | + Manifest | | 291 | Device |<-----------------| Storage |<------------------| Author | 292 | | | | | | 293 +--------+ +-----------+ +--------+ 294 ^ * 295 * * 296 ************************************************************ 297 End-to-End Security 299 5. Manifest 301 In order for a device to apply an update, it has to make several 302 decisions about the update: 304 - Does it trust the author of the update? 306 - Has the firmware been corrupted? 308 - Does the firmware update apply to this device? 310 - Is the update older than the active firmware? 312 - When should the device apply the update? 314 - How should the device apply the update? 316 - What kind of firmware binary is it? 318 - Where should the update be obtained? 320 - Where should the firmware be stored? 322 The manifest format encodes the information that devices need in 323 order to make these decisions. 325 6. Manifest 327 The manifest is a data structure that contains the following 328 information: 330 - information about the device(s) the firmware image is intented to 331 be applied to, 333 - information about when the firmware update has to be applied, 335 - information about when the manifest was created, 337 - dependencies to other manifests, 339 - pointers to the firmware image and information about the format, 341 - information about where to store the firmware image, 343 - cryptographic information, such as digital signatures. 345 The manifest structure is described in a companion document. 347 7. Example Flow 349 The following example message flow illustrates the interaction for 350 distributing a firmware image to a device starting with an author 351 uploading the new firmware to untrusted storage and creating a 352 manifest. 354 +--------+ +-----------------+ +------+ 355 | Author | |Untrusted Storage| |Device| 356 +--------+ +-----------------+ +------+ 357 | | | 358 | Create Firmware | | 359 |--------------- | | 360 | | | | 361 |<-------------- | | 362 | | | 363 | Upload Firmware | | 364 |------------------>| | 365 | | | 366 | Create Manifest | | 367 |---------------- | | 368 | | | | 369 |<--------------- | | 370 | | | 371 | Sign Manifest | | 372 |-------------- | | 373 | | | | 374 |<------------- | | 375 | | | 376 | Upload Manifest | | 377 |------------------>| | 378 | | | 379 | | Query Manifest | 380 | |<--------------------| 381 | | | 382 | | Send Manifest | 383 | |-------------------->| 384 | | | 385 | | | Validate Manifest 386 | | |------------------ 387 | | | | 388 | | |<----------------- 389 | | | 390 | | Request Firmware | 391 | |<--------------------| 392 | | | 393 | | Send Firmware | 394 | |-------------------->| 395 | | | 396 | | | Verify Firmware 397 | | |--------------- 398 | | | | 399 | | |<-------------- 400 | | | 401 | | | Store Firmware 402 | | |-------------- 403 | | | | 404 | | |<------------- 405 | | | 406 | | | Reboot 407 | | |------- 408 | | | | 409 | | |<------ 410 | | | 411 | | | Bootloader validates 412 | | | Firmware 413 | | |---------------------- 414 | | | | 415 | | |<--------------------- 416 | | | 417 | | | Bootloader activates 418 | | | Firmware 419 | | |---------------------- 420 | | | | 421 | | |<--------------------- 422 | | | 423 | | | Bootloader transfers 424 | | | control to new Firmware 425 | | |---------------------- 426 | | | | 427 | | |<--------------------- 428 | | | 430 8. IANA Considerations 432 This document does not require any actions by IANA. 434 9. Security Considerations 436 Firmware updates fix security vulnerabilities and are considered to 437 be an important building block in securing IoT devices. Due to the 438 importance of firmware updates for IoT devices the Internet 439 Architecture Board (IAB) organized a 'Workshop on Internet of Things 440 (IoT) Software Update (IOTSU)' which took place at Trinity College 441 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 442 the big picture. A report about this workshop can be found at 443 [I-D.iab-iotsu-workshop]. This document (and associated 444 specifications) offer a standardized firmware manifest format and an 445 approach for offering end-to-end security from the author to the 446 device. 448 There are, however, many other considerations raised during the 449 workshop. Many of them are outside the scope of standardization 450 organizations since they fall into the realm of product engineering, 451 regulatory frameworks, and business models. The following 452 considerations are outside the scope of this document, namely 454 - installing firmware updates in a robust fashion so that the update 455 does not break the device functionality of the environment this 456 device operates in. 458 - installing firmware updates in a timely fashion considering the 459 complexity of the decision making process of updating devices, 460 potential re-certification requirements, and the need for user's 461 consent to install updates. 463 - the distribution of the actual firmware update, potentially in an 464 efficient manner to a large number of devices without human 465 involvement. 467 - energy efficiency and battery lifetime considerations. 469 - key management required for verifying the digitial signature 470 protecting the manifest. 472 - incentives for manufacturers to offer a firmware update mechanism 473 as part of their IoT products. 475 10. Mailing List Information 477 The discussion list for this document is located at the e-mail 478 address suit@ietf.org [1]. Information on the group and information 479 on how to subscribe to the list is at 480 https://www1.ietf.org/mailman/listinfo/suit 482 Archives of the list can be found at: https://www.ietf.org/mail- 483 archive/web/suit/current/index.html 485 11. Acknowledgements 487 We would like the following persons for their feedback: 489 - Geraint Luff 491 - Amyas Phillips 493 - Dan Ros 495 12. References 497 12.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, 501 DOI 10.17487/RFC2119, March 1997, . 504 12.2. Informative References 506 [I-D.iab-iotsu-workshop] 507 Tschofenig, H. and S. Farrell, "Report from the Internet 508 of Things (IoT) Software Update (IoTSU) Workshop 2016", 509 draft-iab-iotsu-workshop-01 (work in progress), February 510 2017. 512 12.3. URIs 514 [1] mailto:suit@ietf.org 516 Authors' Addresses 518 Brendan Moran 519 ARM Limited 521 EMail: Brendan.Moran@arm.com 523 Milosch Meriac 524 ARM Limited 526 EMail: Milosch.Meriac@arm.com 528 Hannes Tschofenig 529 ARM Limited 531 EMail: hannes.tschofenig@gmx.net