idnits 2.17.1 draft-iab-iotsu-workshop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2017) is 2639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft ARM Limited 4 Intended status: Informational S. Farrell 5 Expires: August 7, 2017 Trinity College Dublin 6 February 3, 2017 8 Report from the Internet of Things (IoT) Software Update (IoTSU) 9 Workshop 2016 10 draft-iab-iotsu-workshop-01.txt 12 Abstract 14 This document provides a summary of the 'Workshop on Internet of 15 Things (IoT) Software Update (IOTSU)' which took place at Trinity 16 College Dublin, Ireland on the 13th and 14th of June, 2016. The main 17 goal of the workshop was to foster a discussion on requirements, 18 challenges and solutions for bringing software and firmware updates 19 to IoT devices. This report summarizes the discussions and lists 20 recommendations to the standards community. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 7, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Requirements and Questions Arising . . . . . . . . . . . . . 5 59 4. Authorizing a Software / Firmware Update . . . . . . . . . . 12 60 5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 12 61 6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15 63 8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16 64 9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 16 65 10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17 66 11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 18 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 70 15. Appendix A: Program Committee . . . . . . . . . . . . . . . . 19 71 16. Appendix B: Accepted Position Papers . . . . . . . . . . . . 19 72 17. Appendix C: List of Participants . . . . . . . . . . . . . . 21 73 18. Informative References . . . . . . . . . . . . . . . . . . . 23 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 76 1. Introduction 78 This document provides a summary of the 'Workshop on Internet of 79 Things (IoT) Software Update (IOTSU)' [IoTSU], which took place at 80 Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. 81 The main goal of the workshop was to foster a discussion on 82 requirements, challenges and solutions for bringing software and 83 firmware updates to IoT devices. 85 The views and positions in this report are those of the workshop 86 participants and do not necessarily reflect those of their employers/ 87 sponsors, the authors of this memo nor the Internet Architecture 88 Board (IAB), under whose auspices the workshop was held. 90 The IAB holds occasional workshops designed to consider long-term 91 issues and strategies for the Internet, and to suggest future 92 directions for the Internet architecture. The topics investigated 93 often require coordinated efforts of different organizations and 94 industry bodies to improve an identified problem. One of the goals 95 of such workshops is to assist with communication between relevant 96 organisations, companies and universities, specially when the topics 97 are partly out of the scope for the Internet Engineering Task Force 98 (IETF). This long-term planning function of the IAB is complementary 99 to the ongoing engineering efforts performed by working groups of the 100 IETF. 102 In his essay 'The Internet of Things Is Wildly Insecure And Often 103 Unpatchable' [BS14] Bruce Schneier expressed concerns about the 104 status of software/firmware updates for Internet of Things (IoT) 105 devices. IoT devices, which have a reputation for being insecure 106 already at the time when they are manufactured, are often expected to 107 stay active in the field for 10+ years and operate unattended with 108 Internet connectivity. 110 Incorporating a software update mechanism to fix vulnerabilities, to 111 update configuration settings as well as adding new functionality is 112 recommended by security experts but there are challenges when using 113 software updates, as the United States Federal Trade Commission (FTC) 114 staff in their "Internet of Things - Privacy & Security in a 115 Connected World" [FTC] and the Article 29 Working Party Opinion 116 8/2014 on the on Recent Developments on the Internet of Things [WP29] 117 reported. 119 Amongst the challenges in designing a basic software/firmware update 120 function are: 122 - Implementations of software update mechanisms may incorporate 123 vulnerabilities becoming an attractive attack target, see for 124 example [OS14], 126 - Operational challenges such as the case of an expired certificate 127 in a hub device [BB14], 129 - Privacy issues if devices "call home" often to check for updates 131 - A lack of incentives to distribute software updates along the 132 value chain 134 - Who should be able to update device software after normal support 135 stops? When should an alternate source of software updates take 136 over? 138 There are various (often proprietary) software update mechanisms in 139 use today and the functionality of those varies significantly with 140 the envisioned use of the IoT devices. More powerful IoT devices, 141 such as those running general purpose operating systems (like Linux), 142 can make use of sophisticated software update mechanisms known from 143 the desktop and the mobile world. This workshop focused on more 144 constrained IoT devices that often run dedicated real-time operating 145 systems or potentially no operating system at all. 147 There is a real risk that many IoT devices will continue to be 148 shipped without a solid software/firmware update mechanism in place. 149 Ideally, IoT software developers and product designers should be able 150 to integrate standardized mechanisms that have experienced 151 substantial review and where the documentation is available to the 152 public. 154 Hence, the IAB decided to organize a workshop to reach out to 155 relevant stakeholders to explore the state-of-the-art and to identify 156 requirements and gaps. In particular, the call for position papers 157 asked for 159 - Protocol mechanisms for distributing software updates. 161 - Mechanisms for securing software updates. 163 - Meta-data about software / firmware packages. 165 - Implications of operating system and hardware design on the 166 software update mechanisms. 168 - Installation of software updates (in context of software and 169 hardware security of IoT devices). 171 - Privacy implications of software update mechanisms. 173 - Implications of device ownership and control for software update. 175 The rest of the document is organized as follows: Basic terminology 176 is provided in Section 2 followed by a longer section discussing 177 requirements. Subsequent sections explore selected topics, such as 178 incentives, and measurements, in more detail. Most of the writeup 179 does raise more questions than it answers. Nevertheless, we tried to 180 synthesise possible conclusions and offer a few next steps. 182 2. Terminology 184 As is typical with people from different backgrounds, workshop 185 participants started the workshop with a discussions of terminology. 186 This section is more intended to reflect those discussions than to 187 present canonical definitions of terms. 189 Device Classes: IoT devices come in various "sizes" (such as size of 190 RAM, or size of flash memory). With these configurations devices 191 are limited in what they can support in terms of operating system 192 features, cryptographic algorithms, and protocol stacks. For this 193 reason, the group differentiated two types of classes, namely ARM 194 Cortex A-class / Intel Atom and Cortex M-class / Intel Quark types 195 of devices. A-class devices are equipped with powerful processors 196 typically found in set-top boxes and home routers. The Raspberry 197 Pi is an example of a A-class device, which is capable of running 198 a regular desktop operating system, such as Linux. There are 199 differences between the Intel and the ARM-based CPUs in terms of 200 architecture, micro-code and who is allowed to update a BIOS (if 201 available) and the micro-code. A detailed discussion of these 202 hardware architectural differences were, however, outside the 203 scope of the workshop. The implication is that lower-end 204 microcontrollers have constraints that put restrictions on the 205 amount of software that can be put on them. While it is easy 206 require support of a wide range of features those may not 207 necessarily fit on these devices. 209 Software Update and Firmware Update: Based on the device classes it 210 was observed that regular operating systems come with 211 sophisticated software update mechanisms (such as RPM [rpm] or 212 Pacman [pacman]) that make use of the operating system to install 213 and run each application in a compartmentalized fashion. Firmware 214 updates typically do not provide such a fine-grained granularity 215 for software updates and instead distribute the entire binary 216 image, which consists of the (often minimalistic) operating system 217 and all applications. While the distinction between the 218 mechanisms A-class and M-class devices will typically use may get 219 more fuzzy over time, most M-class devices use firmware updates 220 and A-class devices use a combination of firmware and software 221 updates (with firmware updates being less frequent operations). 223 Hitless Update: A hitless update implies that the user experience is 224 not "hit", i.e., it is not impacted. It is possible to impact the 225 user experience when applying an update even when the device does 226 not reboot (to obtain or apply said update). If the update is 227 applied when a user is not using a product and their service is 228 not impacted, the update is "hitless". 230 3. Requirements and Questions Arising 232 Workshop participants discussed requirements and several of these 233 raised further questions. As with the previous section we aim to 234 present the discussion as it was. 236 - There may be a need to be support partial (differential) updates, 237 that do not require the entire firmware image to be sent. This 238 may mean that techniques like bsdiff [bsdiff] and courgette 239 [courgette] are used but might also mean devices supporting 240 download of applications and libraries alone. The latter feature 241 may require dynamic linking and position independent code. It was 242 unclear whether position independent code should be recommended 243 for low-end IoT devices. 245 - The relative importance of dynamic linkers for low-end IoT devices 246 is unclear. Some operating systems used with M-class devices, 247 such as Contiki, provide support for a dynamic linker according to 248 [OS-Support]. This could help to minimize the amount of data 249 transmitted during updates since only the modified application or 250 library needs to be transmitted. 252 - How should dependencies among various software updates be handled? 253 These dependencies may include information about the hardware 254 platform and configuration as well as other software components 255 running on a system. For firmware updates the problem of 256 dependencies are often solved by the manufacturer or OEM rather 257 than on the device itself. 259 - Support for devices with multiple micro-controllers may required 260 an architecture where one micro-controller is responsible for 261 interacting with the update service and then dispatching software 262 images to the attached micro-controllers within its local realm. 263 The alternative of letting each microcontroller interact with an 264 update service appeared less practical. 266 - Support may be required for devices with multiple owners/ 267 stakeholders where the question arises about who is authorized to 268 push a firmware/software update. 270 - Data origin authentication (DAO) was agreed to be required for 271 software updates. Without DAO, updates simply become a perfect 272 vulnerability. It is however non-trivial to ensure the actual 273 trust relationships that exist are modelled by the DAO mechanism. 274 For some devices and deployment scenarios, any DAO mechanism is 275 onerous, possibly to the point where it may be hard to convince a 276 device-maker to include the functionality. 278 - Should digital signatures and encryption for software updates be 279 recommended as a best current practice? This question 280 particualrly raises the question about the use of symmetric key 281 cryptography since not all low end IoT devices are currently using 282 asymmetric crypto. 284 - DAO is most commonly provided via digital signature mechanisms, 285 but symmetric schemes could also be developed, though IETF 286 discussion of such mechanisms (for purposes less sensitive than 287 software update) has proved significantly controversial. The main 288 problem seems to be that simple symmetric schemes only ensure that 289 the sender is a member of a group and do not fully authenticate a 290 specific sender. And with software update, we do not want any 291 (possibly compromised) device to be able to be authenticate new 292 software for all other similar devices. 294 - What are the firmware update signing key requirements? Since 295 devices have a rather long lifetime there has to be a way to 296 change the signing key during the lifetime of the device. 298 - Should a firmware update mechanism support multiple signatures of 299 firmware images? Multiple signatures can come in two different 300 flavours, namely 302 a single firmware image may be signed by multiple different 303 parties. In this case one could imagine an environment where 304 an Original Equipment Manufacturer (OEM) signs the software it 305 creates but then the software is again signed by the enterprise 306 that approves the distribution within the company. Other 307 examples include regulatory signatures where a the software for 308 a medical device may be signed as approved by a certification 309 body. 311 a software image may contain libraries that are each signed by 312 their developers. 314 Is a device expected to verify the different types of signatures 315 or is this rather a service provided by some non-constrained 316 device? This raises the question about who the IoT device should 317 trust for what and whether transitive trust is acceptable for some 318 types of devices? 320 - Are applications from a range of sources allowed to run on a 321 device or only those from the OEM? If the device is a "closed" 322 device that only supports/runs software from the OEM then a single 323 signature may be sufficient. In any more "open" system, 3rd party 324 applications may require support of multiple signatures. 326 - There is a need for some form of secure storage, at least for 327 those IoT devices that are exposed to physical attacks. This 328 includes at least the need to protect the integrity of the public 329 key of the update service on the device (if signature based DAO is 330 in use). The use of symmetric key cryptography requires improved 331 confidentiality protection (in addition to integrity protection). 333 - Is there a need to allow the update infrastructure-side to 334 authenticate the IoT device before distributing an update? 335 Questions about the identifier used for such an authentication 336 action were raised. The idea of re-use MAC addresses lead to 337 concerns about the significant privacy implications of such 338 identifier re-use. 340 - It is important to minimize device/service downtime due to update 341 processing, minimize user interaction (e.g., car should not 342 distract the driver) (see hitless updates). While it may not be 343 possible to avoid all downtime, there was agreement that one ought 344 strive for "no inappropriate" device downtime. This means minimal 345 downtime impacting the user/operation of the device. The 346 definition of "downtime" also depends on the use case, with a 347 smart light bulb, the device could be "up" if the light is still 348 on, even if some advanced services are unavailable for a short 349 time. Whether an update can be done without rebooting the device 350 depends on the software being installed, on the OS architecture, 351 and potentially even on the hardware architecture. The cost/ 352 benefit ratio also plays a role. 354 - It is desirable to minimise the time taken from the start of the 355 update to when it is finished. In some systems with many devices 356 (e.g., industrial lighting) this can be a challenge if updates 357 need to be unicasted. 359 - In some systems with multiple devices, it can be a challenge to 360 ensure that all devices are at the same release level, especially 361 if some devices are sleepy. There are some systems where ensuring 362 all relevant devices are at the same release level is a hard- 363 requirement. In other cases, it is acceptable if devices converge 364 much more slowly to the current release level. 366 - It ought not be possible for a factory worker to compromise the 367 update process (e.g., copy signing keys, install unauthorized 368 public keys/trust anchors) during the manufacturing process. 369 There are typically two factories involved, first the factory that 370 produces microcontrollers and other components. The second 371 factory produces the complete product, such as a fridge. This 372 fridge contains many of the components previously manufactured. 373 Hence, the firmware of components produced in the first stage may 374 be 6 month old when the fridge leaves the factory. One does not 375 want to install a firmware update when the fridge boots the first 376 time. For that time the firmware update happens already at the 377 end of the manufacturing process. 379 - Should devices have a recovery procedure when the device gets 380 compromised? How is the compromise detected? 382 - There was a bit of discussion about the importance for IoT devices 383 to know the current time for the purpose of checking certificate 384 validity. For example, what does "real-time clock" (RTC) actually 385 mean? And what constitute 'good enough' time? There are, 386 however, cost, power, size, and environmental constraints that can 387 make the addition of a real-time clock to an IoT device complex: 389 o Cost: battery- or supercap-backed RTC modules might be several 390 times the cost of the rest of the bill of materials. 392 o Size: the battery and other components are often several times 393 larger than the rest of the material. 395 o Manufacturing: some modules require an extra assembly step, 396 because the battery could be damaged/explodes at high 397 temperature during the reflow process. 399 o Supply chain: devices containing fitted batteries need 400 additional supply chain management to account for storage 401 temperature and to avoid shipping aged devices. 403 o Environmental: Real-time-clock modules are typically not rated 404 at industrial temperature ranges. Those that are have 405 extremely reduced lifetime at high temperatures. 407 o Lifetime: some of these modules last only a few years at the 408 top of their environmental range. 410 While a good solution is needed, it is not clear whether there is 411 one true solution. A recent proposal from Google called Roughtime 412 [RT] may be worthwhile to explore. 414 - How do devices learn about a firmware update? Push or Pull? What 415 should be required functionality for a firmware update protocol? 417 - There is a need to find out whether a software update was 418 successful. In one discussed solution the bootloader analyses the 419 performance of the running image to determine which image to run 420 (rather than just verifying the integrity of the received image). 421 One of the key criteria is that the updated system is able to make 422 a connection to the device management/software update 423 infrastructure. As long as it is able to talk to the update 424 infrastructure it can receive another update. As alternative 425 perspective the argument was made that one needs to have a way to 426 update the system without have the full system running. 428 - Gateway requirements. In some deployments gateways terminate the 429 IP-based protocol communication and use non-IP mechanisms to 430 communicate with other micro-controllers, for example, within a 431 car. The gateway in such a system is the end point of the IP 432 communication. The group had mixed feelings about the use of 433 gateways vs the use of IP communication to every micro-controller. 434 Participants argued that there is a lack of awareness of IPv6 435 header compression (with the 6lowpan standards) and of the 436 possible benefits of IPv6 in those environments in terms of 437 lowering the complexity of the overall system. 439 - The amount of energy consumed due to software update needs to be 440 minimized. For example, awakening a sleepy device regularly only 441 to check for new software would seem wasteful if the device cannot 442 feasibly be exploited whilst asleep. However, the trade-off is 443 that once the device awakens with old software, there may be a 444 window of vulnerability, if some relevant exploit has been 445 discovered. 447 - The amount of storage required for update ought be minimized and 448 can sometimes be significant. However, there are also benefits to 449 schemes that store two or three different software images for 450 robustness, e.g., if one has space for separate current, last- 451 known-good and being-updated images then devices can better 452 survive the buggy occasional updates that are also inevitable. 454 Which of the features discussed in the list above are nice to have? 455 Which are required? Not all of these are required to achieve 456 improvement. What are most important? 458 Among the participants there was consensus that supporting signatures 459 (for integrity and authentication) of the firmware image itself and 460 the need for partial updates was seen as important. 462 There were, however, also concerns regarding the performance 463 implications since certain device categories may not utilize public 464 key cryptography at all and hence only a symmetric key approach seems 465 viable, unless some other scheme such as hash-based signature become 466 practical (they currently aren't due to signature size). This aspect 467 raised concerns and trigger a discussions around the use of device 468 management infrastructure, similar to Kerberos, that manages keys and 469 distributes them to the appropriate parties. As such, in this set-up 470 there could be a unique key shared with the key distribution center 471 but for use with specific services (such as a software update 472 service) a fresh and unique secret would be distributed. 474 In addition to the requirements for the end devices there are also 475 infrastructure-related requirements. The infrastructure may consist 476 of servers in the local network and/or various servers deployed on 477 the Internet. It may also consist of some application layer 478 gateways. The potential benefits of having such a local server might 479 include: 481 - The local server acting for neighbouring nodes. For example, in a 482 vehicle one micro-controller can process all firmware updates and 483 redistribute the relevant parts of those to interconnected micro- 484 controllers. 486 - Local infrastructure could perform some digital signature checks 487 on behalf of the devices, e.g., certificate revocation checking. 489 - Local multicast can enable transmission of the same update to many 490 devices 492 - Local servers can hide complexity associated with NAT and 493 Firewalls from the device 495 Another point related to local infrastructure is that since many IoT 496 devices will not be (directly) connected to the Internet, but only 497 through a gateway, there may in any case be a need to develop a 498 software / firmware update mechanism that works in environments where 499 no end-to-end Internet connectivity exists. 501 Some current firmware update schemes need to identify devices. 502 Different design approaches are possible. 504 - In an extreme form in one case the decision about updating a 505 device is made by the infrastructure based on the unique device 506 identification. The operator of the firmware update 507 infrastructure knows about the hardware and software requirements 508 for the IoT devices, knows about the policy for updating the 509 device, etc. The device itself is provisioned with credentials so 510 that it can verify a firmware update coming from an authorized 511 device. 513 - In another extreme the device has knowledge about the software and 514 hardware configuration and possible dependencies. It consults 515 software repositories to obtain those software packages that are 516 most appropriate. Verifying the authenticity of the software 517 packages/firmware images will still be required. 519 Hence, in some deployed software update mechanisms there is no desire 520 for the device to be identified beyond the need to exchange 521 information about most recent software versions. For other devices, 522 it is seen as important to identify the device itself in order to 523 provide the appropriate firmware image/software packages. 525 Related to device identification various privacy concerns arise, such 526 as the need to determine what information is provided to whom and the 527 uses to which this information is put. For IoT devices where there 528 is a close relationship to an individual (see [RFC6973]) privacy 529 concerns are likely higher than for devices where such a relationship 530 does not exist (e.g., a sensor measuring concrete). The software / 531 firmware update mechanism should, however, not make the privacy 532 situation of IoT devices worse. The proposal from the group was to 533 introduce a minimal requirement of not sending any new identifiers 534 over an unencrypted channel as part of an update protocol. 536 Software update will however provide yet another venue in which the 537 tension between those advocating better privacy and those seeking to 538 monetize information will play out. It is in the nature of software 539 update that it requires devices to sometimes "call home" and such 540 interactions provide fertile ground for monetization. 542 4. Authorizing a Software / Firmware Update 544 There were quite a few points revolving around authorization. 546 - Who can accept or reject an update? Is it the owner of the 547 device, or the user or both? The user may not necessarily be the 548 owner. 550 - With products that fall under a regulatory structure, such as 551 healthcare, you don't want firmware other than what has been 552 accredited. 554 - In some cases it will be very difficult for a firmware update 555 system to communicate to users that an update is available. Doing 556 so may requires tracking the device and it's status with regards 557 to the installed firmware/software, with all the privacy downsides 558 if such tracking is badly done. 560 - Not all updates are the same. Security updates are often treated 561 differently compared to feature updates and the authorization for 562 these may differ. 564 - Some people may choose to decline updates, often on the basis that 565 their system is currently stable, but also possibly due to 566 concerns about unwanted changes, such as the HP printer firmware 567 update pushed in March 2016 [HP-Firmware] that turned off features 568 that end-users liked. 570 5. End-of-Support 572 There was quite a bit of discussion about end-of-support for 573 products/devices and how to handle that. 575 - How should end-of-support, or end-of-features be treated? Devices 576 are often deployed for 10+ years (or even longer in some 577 verticals). Device-makers may not want or be able to support 578 software and services for such an extended period of time. Will 579 these devices stop working after a certain, previously unannounced 580 period of time, such as Eye-Fi cards [eyefi]. 582 - There will be a broad range of device-makers involved in IoT, who 583 may differ substantially in terms of how well they can handle the 584 full device life-cycle. Some will be large commercial enterprises 585 who are used to dealing with long device life times, whilst others 586 may be very small commercial entities where the device lifetime 587 may be longer than the company life-time. Yet other devices may 588 be the result of open-source activities that prosper or flounder. 589 The problem of end-of-support arises in all these cases, though 590 feasible solutions for software update may substantially differ. 591 In some cases device-makers may not be willing to continue to 592 update devices, for example due to a change in business strategies 593 caused by a merger. In yet other cases a company may have gone 594 bankrupt. 596 - While there are many legal, ethical, and business related 597 questions can we technically enable transfer of device service to 598 another provider? Could there even be business models for 599 entities that take over device updates for original device-makers 600 who no longer wish to handle software update? 602 - The release of code, as it was done with the Little Printer 603 manufactured and developed by a company called Berg 604 [LittlePrinter], could provide a useful example. While the 605 community took over the support in that case, this can hardly be 606 assumed in all cases. Just releasing the source code for a device 607 will not necessarily motivate others to work on the code, to fix 608 bugs or to maintain a service. Nevertheless, escrowing code so 609 that the community can take it over if a company fails is one 610 possible option. 612 - The situation gets more complex when the device has security 613 mechanisms to ensure that only selected parties are allowed to 614 update the device (which is really a basic requirement for any 615 secure software update). In this case, private signing keys (or 616 similar) may need to be made available as well, which could 617 introduce security problems for already deployed software. In the 618 best case it changes assumptions made about the trust model and 619 about who can submit updates. 621 - How should deployed devices behave when they are end-of-support 622 and support ends? Many of them may still function normally, but 623 others may fail due to the absence of cloud infrastructure 624 services. Some products are probably expected to fail safely, 625 similarly to a smoke alarm that makes a loud noise when the 626 battery becomes empty. Cell phones without a contract can, in 627 some countries, still be used for emergency services (although at 628 the expense of the society due to untraceable hoax calls), as 629 discussed in RFC 7406 [RFC7406]. 631 The recommendation that can be provided to device-makers and users is 632 to think about the end-of-support, end-of-support scenarios ahead of 633 time and plan for those. While device-makers rarely want to consider 634 what happens if their business fails it is definitely legitimate to 635 consider scenarios where they are hugely successful and want to 636 evolve a product line instead of supporting previously sold products 637 forever. Maybe there is also a value in subscription-based models 638 where product and device support is only provided as long as the 639 subscription is paid. Without a subscription the product is 640 deactivated and cannot pose a threat to the Internet at large. 642 6. Incentives 644 Workshop participants also discussed how to create incentives for 645 companies to ship software updates, which is particularly important 646 for products that will be deployed in the market for a long time. It 647 is also further complicated by complex value chains. 649 - Companies shipping software updates benefit from improved 650 security. Their devices are less likely to be abused as a vector 651 to launch other attacks, whether on their own networks, or (as 652 part of a botnet) on other Internet hosts. This clearly creates 653 an incentive to support and use software updates. 655 - On the other hand updates can also break things. The negative 656 customer experience can be due to service interruptions during or 657 after the update process but can also result from bad experience 658 from deliberate changes introduced as part of an update - such as 659 a feature that is not available anymore, or that a "bug" that 660 another service has relied upon being fixed. 662 - For most classes of device, there does not seem to be a regulatory 663 requirement to report or fix, vulnerabilities, similar to data 664 breach notification laws. 666 - Subscription models for device management were suggested so that 667 companies providing the service have an economic interest in 668 keeping devices online (and updated for that). 670 7. Measurements and Analysis 672 From a security point of view it is important to know what devices 673 are out there and what version of software they run. One workshop 674 paper [plonka] reported measurements with initial done on buggy 675 devices first distributed in 2003 that were still detectable in 676 significant numbers just before the workshop 13 years later. As 677 such, in addition to the firmware update mechanism companies have 678 been offering device management solutions that allow OEMs to keep 679 track of their devices. Tracking these devices and their status is 680 still challenging since some devices are only connect irregularly or 681 are only turned on when needed (such as a hockey alarm that is only 682 turned on before a match). 684 Various stakeholders have a justified interest in knowing something 685 about deployed devices. For example, 687 - Manufacturers and other players in the supply chain are interested 688 to know what devices are out there, how many have been sold, what 689 devices are out there but have not been sold. This could help to 690 understand which firmware versions to support for how long. 692 - Device users, owners, and customers these may want to know what 693 devices are installed over a longer period of time, what software/ 694 firmware version is the device running, what is uptime of each of 695 these devices, what types of faults have occurred, etc. Forgotten 696 devices may pose problems, particularly if they (have the 697 potential to) behave badly. 699 - To an extent, network operators offering services to device owners 700 and other actors may also need similar information, for example to 701 control botnets. 703 - Researchers doing analysis on the state of the Internet ecosystem 704 (such as what protocols are being used, how much data IoT devices 705 generate, etc. need measurements for their work. 707 There can easily be some invasiveness in approaches to acquiring such 708 measurements. The challenge was put forward to find ways to create 709 measurement infrastructures that are privacy preserving. Arnar 710 Birgisson noted that there are privacy-preserving statistical 711 techniques, such as RAPPOR [RAPPOR], and Ned Smith added that 712 techniques like Intel's Enhanced Privacy ID (EPID) may play a role in 713 maintaining some level anonymity for the IoT device (owners) while 714 also enabling measurement. It seemed clear that naive approaches to 715 measurement (e.g., where devices are willing to expose a unique 716 identifier to anyone on request) are unlikely to prove sufficient. 718 8. Firmware Distribution in Mesh Networks 720 There was some discussion of the requirements for mesh-based 721 networks, mainly relating to industrial lighting. In these networks, 722 software update can impose unacceptable performance burdens, 723 especially if there are many devices, some of which may be are 724 sleepy. 726 The workshop discussed whether some forms of multicast (perhaps not 727 IP multicast) would be needed to provide acceptable solutions for 728 software update in such cases. It was not clear at which layer a 729 multi-cast solution might be effective in such cases, though there 730 did seem to be no clearly applicable standards-based approach that 731 was available at the time of the workshop. 733 9. Compromised Devices 735 There was a recognition that there are, and perhaps always will be, 736 large numbers of devices that can be, or have been compromised. 737 While updating these can mitigate problems, there will always be new 738 devices added to networks that cannot be updated (for various 739 reasons) so the question of what, if anything, to do about 740 compromised devices was discussed. 742 - There may be value if it were possible to single out a device, 743 which shows faulty behavior or has been compromised, and to shut 744 that down in some sense. 746 - Prior work in the IETF on Network Endpoint Assessment (NEA) [NEA] 747 allowed assessing the "posture" of devices. Posture refers to the 748 hardware or software configuration of a device and may include 749 knowledge that software installed is up-to-date. The obtained 750 information can then be used by some network infrastructure to 751 create a quarantined region network around the device. 753 - RFC 6561 [RFC6561] describes one scheme for an ISP to send 754 "signals" to customers about hosts (usually those that are part of 755 a botnets or generating spam) in their home network. 757 - Neither RFC 6561 nor NEA has found widespread deployment. Whether 758 such mechanisms can be more successful in the IoT environment has 759 yet to be studied. 761 The conclusion of the discussion at the workshop itself was that 762 there is some interest to identify and stop misbehaving devices but 763 the actual solution mechanisms are unclear. 765 10. Miscellaneous Points 767 There were a number of points discussed at the workshop that don't 768 neatly fit under the above headings but that are worth recording. 769 Those included: 771 - Complex questions can arise when considering the impact of the 772 lack of updates on other devices, other persons, or the public in 773 general. If I don't update my device and that is used to attack a 774 random host on the Internet, then what incentive do I have to do 775 updates? What incentive has my device's vendor to have done that 776 in advance? An example of such a case can be found in DDoS 777 attacks from IoT devices, such as printers [SNMP-DDOS] and cameras 778 [DDOS-KREBS]. 780 - With some IoT devices there are many stakeholders contributing to 781 the end product (e.g., contributing different subsystems) and 782 ensuring that vulnerabilities are fixed and software/firmware 783 updates are communicated through the value chain is known to be 784 difficult, as demonstrated in [OS14]. 786 - What about forgotten devices? There are many such, and will be 787 more. Even though they are forgotten, such devices may be useless 788 consumers of electricity, or may be part of some critical system. 790 - Can we determine whether an update impacts other devices in the 791 Internet? Updates to one device can have unintended impact on 792 other devices that depend on it. This can have cascading effects 793 if we are not careful. Changing the format of the output of a 794 sensor could have cascading impacts, e.g., if some actuator reacts 795 to the presence/absence of that sensor's data. 797 - How should a device behave when it is running out-of-date 798 software. The example of a smoke alarm was mentioned. We don't 799 want 100 devices in a living room to start beeping when their 800 batteries run low or when they cannot communicate with the cloud. 801 But are devices supposed to simply stop working? 803 - The IETF has published a specification that uses the Cryptographic 804 Message Syntax (CMS) to protect firmware packages, as described in 805 RFC 4108 [RFC4108], which also contains meta-data to describe the 806 firmware image itself. During the workshop the question was 807 raised whether a solution will in future be needed that is post- 808 quantum secure. A post-quantum cryptosystem is a system that is 809 secure against quantum computers that have more than a trivial 810 number of quantum bits. It is open to conjecture whether it is 811 feasible to build such a machine but current signature algorithms 812 are known to not be post-quantum secure. This would require 813 introducing technologies like the Hash-based Merkle Tree Signature 814 (MTS) [housley-cms-mts-hash-sig], which was presented and 815 discussed at the workshop. The downside of such solutions are, 816 their novelty, and for these use-cases, the fairly large signature 817 or key sizes involved, e.g., depending on the parameters a 818 signature could easily have a size of 5-10KiB [hashsig]. While it 819 is likely that post-quantum secure signature algorithms will be 820 needed for software update at some point in time, it may be the 821 case that such algorithms will be needed sooner for services 822 requiring long term confidentiality, (e.g., using TLS) so it was 823 not clear that this application would be a first-mover in terms of 824 post-quantum security. 826 - Many devices that use certificates do not check the revocation 827 status of certificates, even though extensions like OSCP stapling 828 exists [RFC6961] and is increasingly deployed with Web browsers. 829 The workshop participants were inconclusive regarding the 830 recommendations of certificate revocation checking although the 831 importance has been recognized. The reluctance of deploying 832 certificate revocation deserves further investigations. 834 11. Tentative Conclusions and Next Steps 836 The workshop participants discussed some tentative conclusions and 837 possible next steps: 839 - There was good agreement that having some standardized secure 840 (authorized and authenticated) software update would be an 841 improvement over having none. 843 - It would be valuable to find agreement on the right scope for a 844 standardized software/firmware update mechanism. It is not clear 845 that an entire update system can or should be standardised but 846 there may be some aspects of such solutions where standards would 847 be beneficial, e.g., (meta-)data formats and/or protocols for 848 distributing firmware updates. More discussion is needed to 849 identify which parts of the problem space could benefit from 850 standardisation. 852 - It will be useful to investigate solutions to install updates with 853 no operation interruption as well as ways to distribute software 854 updates without disrupting network operations (specifically in 855 low-power wireless networks), including the development of a 856 multicast transfer mechanism (with appropriate security). 858 - There will almost certainly be a need for a way to transfer 859 authority/responsibility for updates, particularly considering 860 end-of-support cases. This is very close to calling for a 861 standard way to "root" devices as a feature of all devices. 863 - We would benefit from documentation of proofs-of-concept of 864 software/firmware updates for constrained devices on different 865 operating system architectures. The IETF Light-Weight 866 Implementation Guidance (lwig) working group may be a good venue 867 for such documents. 869 12. Security Considerations 871 This document summarizes an IAB workshop on software/firmware updates 872 and the entire content is therefore security related. Standardizing 873 and deploying a software/firmware update mechanism for use with IoT 874 devices could help to fix security vulnerabilities faster and in some 875 cases the only via to get vulnerability patched at all. 877 13. IANA Considerations 879 This document does not contain any requests to IANA. 881 14. Acknowledgements 883 We would like to thank all paper authors and participants for their 884 contributions. The IoTSU workshop is co-sponsored by the Internet 885 Architecture Board and the Science Foundation Ireland funded CONNECT 886 Centre for future networks and communications. The programme 887 committee would like to express their thanks to Comcast for 888 sponsoring the social event. 890 15. Appendix A: Program Committee 892 The following individuals helped to organize the workshop: Jari 893 Arkko, Arnar Birgisson, Carsten Bormann, Stephen Farrell, Russ 894 Housley, Ned Smith, Robert Sparks, and Hannes Tschofenig. 896 16. Appendix B: Accepted Position Papers 898 The list of accepted position papers is below. Links to these, and 899 to the workshop agenda and raw minutes are accessible at: 900 . 902 - R. Housley, 'Position Paper for Internet of Things Software 903 Update Workshop (IoTSU)' 905 - D. Thomas and A. Beresford, 'Incentivising software updates' 906 - L. Zappaterra and E. Dijk, Software Updates for Wireless 907 Connected Lighting Systems: requirements, challenges and 908 recommendations' 910 - M. Orehek and A. Zugenmaier, 'Updates in IoT are more than just 911 one iota' 913 - D. Plonka and E. Boschi, 'The Internet of Things Old and 914 Unmanaged' 916 - D. Bosschaert, 'Using OSGi for an extensible, updatable and 917 future proof IoT' 919 - A. Padilla, E. Baccelli, T. Eichinger and K. Schleiser, 'The 920 Future of IoT Software Must be Updated' 922 - T. Hardie, 'Software Update in a multi-system Internet of Things' 924 - R. Sparks and B. Campbell, 'Avoiding the Obsolete-Thing Event 925 Horizon' 927 - J. Karkov, 'SW update for Long lived products' 929 - S. Farrell, 'Some Software Update Requirements' 931 - S. Chakrabarti, 'Internet Of Things Software Update Challenges: 932 Ownership, Software Security & Services' 934 - M. Kovatsch, A. Scholz, and J. Hund, 'Why Software Updates Are 935 More Than a Security Issue' 937 - A. Grau, 'Secure Software Updates for IoT Devices' 939 - Birr-Pixton, Electric Imp's experiences of upgrading half a 940 million embedded devices' 942 - Y. Zhang, J. Yin, C. Groves, and M. Patel, 'oneM2M device 943 management and software/firmware update' 945 - E. Smith, M. Stitt, R. Ensink, and K. Jager, 'User Experience 946 (UX) Centric IoT Software Update' 948 - J.-P. Fassino, E.A. Moktad, J.-M. Brun, 'Secure Firmware Update 949 in Schneider Electric IOT-enabled offers' 951 - M. Orehek, 'Summary of existing firmware update strategies for 952 deeply embedded systems' 954 - N. Smith, 'Toward A Common Modeling Standard for Software Update 955 and IoT Objects' 957 - S. Schmidt, M. Tausig, M. Hudler, and G. Simhandl, 'Secure 958 Firmware Update Over the Air in the Internet of Things Focusing on 959 Flexibility and Feasibility' 961 - A. Adomnicai, J. Fournier, L. Masson, and A. Tria, 'How 962 careful should we be when implementing cryptography for software 963 update mechanisms in the IoT?' 965 - V. Prevelakis and H. Hamad, 'Controlling Change via Policy 966 Contracts' 968 - H. Birkholz, N. Cam-Winget and C. Bormann, 'IoT Software 969 Updates need Security Automation' 971 - R. Bisewski, 'Comparative Analysis of Distributed Repository 972 Update Methodology and How CoAP-like Update Methods Could 973 Alleviate Internet Strain for Devices that Constitute the Internet 974 of Things' 976 - J. Arrko, 'Architectural Considerations with Smart Objects and 977 Software Updates' 979 - J. Jimenez and M. Ocak, 'Software Update Experiences for IoT' 981 - H. Tschofenig, 'Software and Firmware Updates with the OMA LWM2M 982 Protocol' 984 17. Appendix C: List of Participants 986 - Arnar Birgisson, Google 988 - Alan Grau, IconLabs 990 - Alexandre Adomnicai, Trusted Objects 992 - Alf Zugenmaier, Munich University of Applied Science 994 - Ben Campbell, Oracle 996 - Carsten Bormann, TZI University Bremen 998 - Daniel Thomas, University of Cambridge 1000 - David Bosschaert, Adobe 1001 - David Malone, Maynooth University 1003 - David Plonka, Akamai 1005 - Doug Leith, Trinity College Dublin 1007 - Emmanuel Baccelli, Inria 1009 - Eric Smith, SpinDance 1011 - Jean-Philippe Fassino, Schneider Electric 1013 - Joergen Karkov, Grundfos 1015 - Jonathon Dukes, Trinity College Dublin 1017 - Joseph Birr-Pixton, Electric Imp 1019 - Kaspar Schleiser, Freie Universitaet Berlin 1021 - Luca Zappaterra, Philips Lighting Research 1023 - Martin Orehek, Munich University of Applied Science 1025 - Mathias Tausig, FH Campus Wien 1027 - Matthias Kovatsch, Siemens 1029 - Milan Patel, Huawei 1031 - Ned Smith, Intel 1033 - Robert Ensink, SpinDance 1035 - Robert Sparks, Oracle 1037 - Russ Housley, Vigil Security 1039 - Samita Chakrabarti, Ericsson 1041 - Stephen Farrell, Trinity College Dublin 1043 - Vassilis Prevelakis, TU Braunschweig 1045 - Hannes Tschofenig, ARM Ltd. 1047 18. Informative References 1049 [BB14] Barrett, B., "Winks Outage Shows Us How Frustrating Smart 1050 Homes Could Be", April 2014, 1051 . 1053 [BS14] Schneier, B., "The Internet of Things Is Wildly Insecure 1054 And Often Unpatchable", January 2014, 1055 . 1058 [bsdiff] Percival, C., "Binary diff/patch utility", September 2016, 1059 . 1061 [courgette] 1062 Google, "Software Updates - Courgette", September 2016, 1063 . 1066 [DDOS-KREBS] 1067 Goodin, D., "Record-breaking DDoS reportedly delivered by 1068 >145k hacked cameras", September 2016, 1069 . 1072 [eyefi] Aldred, J., "EYEFI TO DROP SUPPORT FOR SOME CARDS. THEY 1073 WILL 'MAGICALLY' STOP WORKING ON SEPTEMBER 16, 2016", June 1074 2016, . 1077 [FTC] Federal Trade Commission, "FTC Report on Internet of 1078 Things Urges Companies to Adopt Best Practices to Address 1079 Consumer Privacy and Security Risks", January 2015, 1080 . 1084 [hashsig] Langley, A., "Hash based signatures", July 2013, 1085 . 1087 [housley-cms-mts-hash-sig] 1088 Housley, R., "Use of the Hash-based Merkle Tree Signature 1089 (MTS) Algorithm in the Cryptographic Message Syntax 1090 (CMS)", March 2016, . 1093 [HP-Firmware] 1094 BoingBoing, "HP detonates its timebomb - printers stop 1095 accepting third party ink en masse", September 2016, 1096 . 1099 [IoTSU] IAB, "Internet of Things Software Update Workshop 1100 (IoTSU)", June 2016, 1101 . 1103 [LittlePrinter] 1104 Berg, "The future of Little Printer", September 2014, 1105 . 1108 [NEA] IETF, "Network Endpoint Assessment (nea) (Concluded 1109 Working Group)", 2016, 1110 . 1112 [OS-Support] 1113 Dong, W., Chen, C., Liu, X., and J. Bu, "Providing OS 1114 Support for Wireless Sensor Networks - Challenges and 1115 Approaches", May 2010, . 1118 [OS14] Oppenheim, L. and S. Tal, "Too Many Cooks - Exploiting the 1119 Internet-of-TR-069-Things", December 2014, 1120 . 1123 [pacman] -, "Pacman", 2016, . 1125 [plonka] Plonka, D. and E. Boschi, "The Internet of Things Old and 1126 Unmanage", June 2016, 1127 . 1130 [RAPPOR] Erlingsson, U., Pihur, V., and A. Korolova, "RAPPOR", July 1131 2014, . 1133 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1134 Protect Firmware Packages", RFC 4108, 1135 DOI 10.17487/RFC4108, August 2005, 1136 . 1138 [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, 1139 "Recommendations for the Remediation of Bots in ISP 1140 Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, 1141 . 1143 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1144 Multiple Certificate Status Request Extension", RFC 6961, 1145 DOI 10.17487/RFC6961, June 2013, 1146 . 1148 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1149 Morris, J., Hansen, M., and R. Smith, "Privacy 1150 Considerations for Internet Protocols", RFC 6973, 1151 DOI 10.17487/RFC6973, July 2013, 1152 . 1154 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1155 and D. Kroeselberg, "Extensions to the Emergency Services 1156 Architecture for Dealing With Unauthenticated and 1157 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1158 December 2014, . 1160 [rpm] -, "Red Hat Package Manager (RPM)", 2016, 1161 . 1163 [RT] Google, "Roughtime", September 2016, 1164 . 1166 [SNMP-DDOS] 1167 BITAG, "SNMP Reflected Amplification DDoS Attack 1168 Mitigation", August 2012, 1169 . 1172 [WP29] Article 29 Data Protection Working Party, "Opinion 8/2014 1173 on the on Recent Developments on the Internet of Things", 1174 September 2014, . 1178 Authors' Addresses 1180 Hannes Tschofenig 1181 ARM Limited 1183 EMail: hannes.tschofenig@gmx.net 1184 Stephen Farrell 1185 Trinity College Dublin 1186 Dublin 2 1187 Ireland 1189 Phone: +353-1-896-2354 1190 EMail: stephen.farrell@cs.tcd.ie