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