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