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