Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 8240 S. Farrell
Category: Informational September 2017
ISSN: 2070-1721
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 8240 S. Farrell
Category: Informational September 2017
ISSN: 2070-1721
Report from the Internet of Things Software Update (IoTSU) Workshop 2016
2016年物联网软件更新（IoTSU）研讨会报告
Abstract
摘要
This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.
本文件概述了2016年6月13日和14日在爱尔兰都柏林三一学院举行的物联网软件更新（IoTSU）研讨会。研讨会的主要目标是促进对物联网设备软件和固件更新的需求、挑战和解决方案的讨论。本报告总结了讨论情况，并列出了对标准团体的建议。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
请注意，本文件是研讨会会议记录的报告。本报告中记录的观点和立场是研讨会参与者的观点和立场，不一定反映IAB的观点和立场。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8240.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8240.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Questions Raised . . . . . . . . . . . . . . 6
4. Authorizing a Software/Firmware Update . . . . . . . . . . . 12
5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 13
6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15
8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16
9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 17
10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17
11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 24
Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 24
Appendix C. List of Participants . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Questions Raised . . . . . . . . . . . . . . 6
4. Authorizing a Software/Firmware Update . . . . . . . . . . . 12
5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 13
6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15
8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16
9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 17
10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17
11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 24
Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 24
Appendix C. List of Participants . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop [IoTSU] that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices.
本文件概述了2016年6月13日和14日在爱尔兰都柏林三一学院举行的物联网软件更新（IoTSU）研讨会[IoTSU]。研讨会的主要目标是促进对物联网设备软件和固件更新的需求、挑战和解决方案的讨论。
The views and positions in this report are those of the workshop participants and do not necessarily reflect those of their employers/ sponsors, the authors of this memo, nor the Internet Architecture Board (IAB), under whose auspices the workshop was held.
本报告中的观点和立场是研讨会参与者的观点和立场，不一定反映他们的雇主/赞助者、本备忘录的作者，也不一定反映研讨会主持下的互联网架构委员会（IAB）的观点和立场。
The IAB holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. The topics investigated often require coordinated efforts of different organizations and industry bodies to improve an identified problem. One of the goals of such workshops is to assist with communication between relevant organizations, companies, and universities, especially when the topics are partly out of the scope for the Internet Engineering Task Force (IETF). This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF.
IAB举办临时研讨会，旨在考虑互联网的长期问题和策略，并提出未来的互联网架构方向。调查的主题通常需要不同组织和行业机构的协调努力，以改进已确定的问题。此类研讨会的目标之一是协助相关组织、公司和大学之间的沟通，尤其是当主题部分超出互联网工程任务组（IETF）的范围时。IAB的长期规划职能是对IETF工作组正在进行的工程工作的补充。
In his essay "The Internet of Things Is Wildly Insecure -- And Often Unpatchable" [BS14], Bruce Schneier expressed concerns about the status of software/firmware updates for IoT devices. IoT devices, which have a reputation for being insecure from the time they are manufactured, are often expected to stay active in the field for 10 or more years and to operate unattended with Internet connectivity.
布鲁斯·施奈尔（Bruce Schneier）在其论文《物联网非常不安全——而且常常无法修补》[BS14]中表达了对物联网设备软件/固件更新状态的担忧。物联网设备自生产之日起就因不安全而闻名，人们通常期望其在该领域保持活跃10年或更长时间，并通过互联网连接无人值守运行。
Incorporating a software update mechanism to fix vulnerabilities, to update configuration settings and, to add new functionality as well, is recommended by security experts. However, there are challenges when using software updates, as documented in the United States Federal Trade Commission (FTC) report titled "internet of things: Privacy & Security in a Connected World" [FTC] and in the Article 29 Data Protection Working Party document "Opinion 8/2014 on the on [sic] Recent Developments on the Internet of Things"[WP29].
安全专家建议采用软件更新机制来修复漏洞、更新配置设置和添加新功能。然而，正如美国联邦贸易委员会（FTC）题为“物联网：互联世界中的隐私与安全”的报告[FTC]和第29条数据保护工作组文件“2014年8月关于物联网最新发展的意见”中所述，使用软件更新时存在挑战[WP29]。
Among the challenges in designing a basic software/firmware update function are:
设计基本软件/固件更新功能的挑战包括：
- Implementations of software update mechanisms may incorporate vulnerabilities, becoming an attractive attack target. See, for example, [OS14].
- 软件更新机制的实现可能包含漏洞，成为一个有吸引力的攻击目标。例如，参见[OS14]。
- Operational challenges, such as the case of an expired certificate in a hub device [BB14].
- 操作挑战，例如集线器设备中的证书过期[BB14]。
- Privacy issues if devices "call home" often to check for updates.
- 如果设备经常“呼叫总部”检查更新，则会出现隐私问题。
- A lack of incentives to distribute software updates along the value chain.
- 缺乏沿价值链分发软件更新的激励。
- Questions such as the following. Who should be able to update device software after normal support stops? When should an alternate source of software updates take over?
- 问题如下。正常支持停止后，谁应该能够更新设备软件？软件更新的替代来源应在何时接管？
There are various (often proprietary) software update mechanisms in use today, and the functionality of those varies significantly with the envisioned use of the IoT devices. More powerful IoT devices, such as those running general purpose operating systems (like Linux), can make use of sophisticated software update mechanisms known from the desktop and the mobile world. This workshop focused on more constrained IoT devices that often run dedicated real-time operating systems or potentially no operating system at all.
目前有各种（通常是专有的）软件更新机制在使用，这些机制的功能随着物联网设备的预期使用而显著不同。更强大的物联网设备，如运行通用操作系统（如Linux）的设备，可以利用桌面和移动世界中已知的复杂软件更新机制。本次研讨会的重点是更受限制的物联网设备，这些设备通常运行专用实时操作系统，或者根本没有操作系统。
There is a real risk that many IoT devices will continue to be shipped without a solid software/firmware update mechanism in place. Ideally, IoT software developers and product designers should be able to integrate standardized mechanisms that have experienced substantial review and where the documentation is available to the public.
许多物联网设备在没有可靠的软件/固件更新机制的情况下仍将继续装运，这是一个真正的风险。理想情况下，物联网软件开发人员和产品设计师应能够集成经过实质性审查的标准化机制，并在这些机制中向公众提供文档。
Hence, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state of the art and to identify requirements and gaps. In particular, the call for position papers asked for:
因此，IAB决定组织一次研讨会，接触相关利益相关者，探索最新技术，并确定需求和差距。特别是，要求提供立场文件的呼吁要求：
- Protocol mechanisms for distributing software updates.
- 用于分发软件更新的协议机制。
- Mechanisms for securing software updates.
- 保护软件更新的机制。
- Metadata about software/firmware packages.
- 关于软件/固件包的元数据。
- Implications of operating system and hardware design on the software update mechanisms.
- 操作系统和硬件设计对软件更新机制的影响。
- Installation of software updates (in context of software and hardware security of IoT devices).
- 安装软件更新（在物联网设备的软件和硬件安全方面）。
- Privacy implications of software update mechanisms.
- 软件更新机制的隐私影响。
- Implications of device ownership and control for software update.
- 设备所有权和控制对软件更新的影响。
The rest of the document is organized as follows: basic terminology is provided in Section 2, followed by a longer section discussing requirements. Subsequent sections explore selected topics, such as incentives and measurements in more detail. Most of the write-up does raise more questions than it answers. Nevertheless, we tried to synthesize possible conclusions and offer a few next steps.
本文件的其余部分组织如下：第2节提供了基本术语，随后是讨论需求的较长章节。后续章节将更详细地探讨选定的主题，如激励和衡量。大部分的评论确实提出了比回答更多的问题。然而，我们试图综合可能的结论，并提出一些后续步骤。
As is typical with people from different backgrounds, workshop participants started the workshop with a discussions of terminology. This section is more intended to reflect those discussions than to present canonical definitions of terms.
与来自不同背景的人一样，研讨会参与者在研讨会开始时讨论了术语。本节更多的是反映这些讨论，而不是给出术语的规范定义。
Device Classes: IoT devices come in various "sizes" (such as size of RAM or size of flash memory). With these configurations, devices are limited in what they can support in terms of operating-system features, cryptographic algorithms, and protocol stacks. For this reason, the group differentiated two types of classes, namely ARM Cortex A-class/Intel Atom and Cortex M-class/Intel Quark types of devices. A-class devices are equipped with powerful processors typically found in set-top boxes and home routers. The Raspberry Pi is an example of an A-class device that is capable of running a regular desktop operating system, such as Linux. There are differences between the Intel and the ARM-based CPUs in terms of architecture, microcode, and who is allowed to update a Basic Input/Output System (BIOS) (if available). A detailed discussion of these hardware architectural differences were, however, outside the scope of the workshop. The implication is that lower-end microcontrollers have constraints that put restrictions on the amount of software that can be put on them. While it is easy to require support of a wide range of features, those may not necessarily fit on these devices.
设备类别：物联网设备有各种“大小”（如RAM大小或闪存大小）。通过这些配置，设备在操作系统功能、加密算法和协议栈方面的支持受到限制。因此，该小组区分了两种类型的设备，即ARM Cortex A-class/Intel Atom和Cortex M-class/Intel Quark类型的设备。A级设备配备了功能强大的处理器，这些处理器通常出现在机顶盒和家庭路由器中。Raspberry Pi是能够运行常规桌面操作系统（如Linux）的A级设备的一个示例。Intel和基于ARM的CPU在体系结构、微码以及允许谁更新基本输入/输出系统（BIOS）（如果可用）方面存在差异。然而，对这些硬件架构差异的详细讨论超出了研讨会的范围。这意味着，低端微控制器有一些限制，限制了可安装在其上的软件的数量。虽然很容易要求支持广泛的功能，但这些功能不一定适合这些设备。
Software Update and Firmware Update: Based on the device classes, it was observed that regular operating systems come with sophisticated software update mechanisms (such as Red Hat Package Manager (RPM) [RPM] or pacman [PACMAN]) that make use of the operating system to install and run each application in a compartmentalized fashion. Firmware updates typically do not provide such a fine-grained granularity for software updates and instead distribute the entire binary image, which consists of the (often minimalistic) operating system and all applications. While the distinction between the mechanisms that A-class and M-class devices will typically use may get more fuzzy over time, most M-class devices use firmware updates while A-class devices use a combination of firmware and software updates (with firmware updates being less frequent operations).
软件更新和固件更新：根据设备类别，观察到常规操作系统具有复杂的软件更新机制（如Red Hat Package Manager（RPM）[RPM]或pacman[pacman]），这些机制利用操作系统以分区方式安装和运行每个应用程序。固件更新通常不会为软件更新提供如此细粒度的粒度，而是分发整个二进制映像，其中包括（通常是最低限度的）操作系统和所有应用程序。虽然A-class和M-class设备通常使用的机制之间的区别随着时间的推移可能变得更加模糊，但大多数M-class设备使用固件更新，而A-class设备使用固件和软件更新的组合（固件更新的操作频率较低）。
Hitless Update: A hitless update implies that the user experience is not "hit", i.e., it is not impacted. It is possible to impact the user experience when applying an update even when the device does not reboot (to obtain or apply said update). If the update is applied when a user is not using a product and their service is not impacted, the update is "hitless".
无故障更新：无故障更新意味着用户体验没有“命中”，即没有受到影响。即使设备没有重新启动（获取或应用所述更新），应用更新时也可能影响用户体验。如果在用户未使用产品且其服务未受影响时应用更新，则更新为“无故障”。
Workshop participants discussed requirements and several of these raised further questions. As with the previous section, we aim to present the discussion as it was.
讲习班与会者讨论了要求，其中一些提出了进一步的问题。与上一节一样，我们的目的是按原样进行讨论。
- There may be a need to be support partial (differential) updates that do not require the entire firmware image to be sent. This may mean that techniques like bsdiff [BSDIFF] and courgette [COURGETTE] are used but might also mean devices supporting the download of applications and libraries alone. The latter feature may require dynamic linking and position independent code. It was unclear whether position independent code should be recommended for low-end IoT devices.
- 可能需要支持不需要发送整个固件映像的部分（差异）更新。这可能意味着使用诸如bsdiff[bsdiff]和小胡瓜[courgette]之类的技术，但也可能意味着仅支持下载应用程序和库的设备。后一种功能可能需要动态链接和位置独立代码。目前尚不清楚是否应为低端物联网设备推荐位置独立代码。
- The relative importance of dynamic linkers for low-end IoT devices is unclear. Some operating systems used with M-class devices, such as Contiki, provide support for a dynamic linker according to [OS-Support]. This could help to minimize the amount of data transmitted during updates since only the modified application or library needs to be transmitted.
- 低端物联网设备的动态连接器的相对重要性尚不清楚。一些与M类设备一起使用的操作系统，如Contiki，根据[OS support]提供对动态链接器的支持。这有助于将更新期间传输的数据量降至最低，因为只需要传输修改后的应用程序或库。
- How should dependencies among various software updates be handled? These dependencies may include information about the hardware platform and configuration as well as other software components running on a system. For firmware updates, the problem of dependencies are often solved by the manufacturer or Original Equipment Manufacturer (OEM) rather than on the device itself.
- 如何处理各种软件更新之间的依赖关系？这些依赖关系可能包括有关硬件平台和配置以及系统上运行的其他软件组件的信息。对于固件更新，依赖性问题通常由制造商或原始设备制造商（OEM）解决，而不是由设备本身解决。
- Support for devices with multiple microcontrollers may require an architecture where one microcontroller is responsible for interacting with the update service and then dispatching software images to the attached microcontrollers within its local realm. The alternative of letting each microcontroller interact with an update service appeared less practical.
- 对具有多个微控制器的设备的支持可能需要一个体系结构，其中一个微控制器负责与更新服务交互，然后将软件映像发送到其本地域内连接的微控制器。让每个微控制器与更新服务交互的替代方案似乎不太实际。
- Support may be required for devices with multiple owners/ stakeholders where the question arises about who is authorized to push a firmware/software update.
- 可能需要对具有多个所有者/利益相关者的设备提供支持，其中出现了关于谁有权推动固件/软件更新的问题。
- Data origin authentication (DAO) was agreed to be required for software updates. Without DAO, updates simply become a perfect vulnerability. It is, however, nontrivial to ensure that the actual trust relationships that exist are modeled by the DAO mechanism. For some devices and deployment scenarios, any DAO mechanism is onerous, possibly to the point where it may be hard to convince a device maker to include the functionality.
- 同意软件更新需要数据源身份验证（DAO）。没有DAO，更新只会成为一个完美的漏洞。然而，确保实际存在的信任关系由DAO机制建模是非常重要的。对于某些设备和部署场景，任何DAO机制都是繁重的，可能很难说服设备制造商包含该功能。
- Should digital signatures and encryption for software updates be recommended as a best current practice? This question particularly raises the question about the use of symmetric key cryptography since not all low-end IoT devices are currently using asymmetric crypto.
- 是否应建议将软件更新的数字签名和加密作为当前最佳做法？这个问题特别提出了使用对称密钥加密的问题，因为目前并非所有低端物联网设备都使用非对称加密。
- DAO is most commonly provided via digital signature mechanisms, but symmetric schemes could also be developed, though IETF discussion of such mechanisms (for purposes less sensitive than software update) has proved significantly controversial. The main problem seems to be that simple symmetric schemes only ensure that the sender is a member of a group, and they do not fully authenticate a specific sender. And with a software update, we do not want any (possibly compromised) device to be able to authenticate new software for all other similar devices.
- DAO通常通过数字签名机制提供，但也可以开发对称方案，尽管IETF对此类机制的讨论（目的不如软件更新敏感）已证明存在重大争议。主要的问题似乎是简单的对称方案只能确保发送者是组的成员，并且不能完全验证特定的发送者。通过软件更新，我们不希望任何（可能受损的）设备能够为所有其他类似设备验证新软件。
- What are the firmware update signing key requirements? Since devices have a rather long lifetime, there has to be a way to change the signing key during the lifetime of the device.
- 固件更新签名密钥要求是什么？由于设备的生命周期较长，因此必须有一种方法在设备的生命周期内更改签名密钥。
- Should a firmware update mechanism support multiple signatures of firmware images? Multiple signatures can come in two different flavors, namely:
- 固件更新机制是否应支持固件映像的多个签名？多个签名可以有两种不同的风格，即：
A single firmware image may be signed by multiple different parties. In this case, one could imagine an environment where an OEM signs the software it creates, but then the software is again signed by the enterprise that approves the distribution within the company. Other examples include regulatory signatures where the software for a medical device may be signed as approved by a certification body.
单个固件映像可以由多个不同的方签名。在这种情况下，可以想象这样一种环境：OEM对其创建的软件进行签名，但随后该软件再次由批准公司内部发行的企业进行签名。其他示例包括监管签名，其中医疗设备的软件可以按照认证机构的批准进行签名。
A software image may contain libraries that are each signed by their developers.
软件映像可能包含由其开发人员签名的库。
Is a device expected to verify the different types of signatures or is this a service provided by some unconstrained device? This raises questions about who the IoT device should trust for what and whether transitive trust is acceptable for some types of devices.
设备是否需要验证不同类型的签名，或者这是由某个不受约束的设备提供的服务？这就提出了物联网设备应该信任谁以及某些类型的设备是否可以接受可传递信任的问题。
- Are applications from a range of sources allowed to run on a device or only those from the OEM? If the device is a "closed" device that only supports/runs software from the OEM, then a single signature may be sufficient. In a system that is more "open", third-party applications may require support of multiple signatures.
- 是否允许来自一系列来源的应用程序在设备上运行，还是仅允许来自OEM的应用程序运行？如果设备为“封闭”设备，仅支持/运行OEM软件，则单个签名就足够了。在更“开放”的系统中，第三方应用程序可能需要支持多个签名。
- There is a need for some form of secure storage, at least for those IoT devices that are exposed to physical attacks. This includes at least the need to protect the integrity of the public key of the update service on the device (if signature-based DAO is in use). The use of symmetric key cryptography requires improved confidentiality protection (in addition to integrity protection).
- 需要某种形式的安全存储，至少对于那些暴露于物理攻击的物联网设备是如此。这至少包括需要保护设备上更新服务的公钥的完整性（如果使用基于签名的DAO）。使用对称密钥加密需要改进的机密性保护（除了完整性保护）。
- Is there a need to allow the update infrastructure side to authenticate the IoT device before distributing an update? Questions about the identifier used for such an authentication action were raised. The idea of reusing Media Access Control (MAC) addresses lead to concerns about the significant privacy implications of such identifier reuse.
- 是否需要允许更新基础设施方在分发更新之前对物联网设备进行身份验证？有人提出了关于用于这种认证行动的标识符的问题。重用媒体访问控制（MAC）地址的想法引起了对这种标识符重用的重大隐私影响的关注。
- It is important to minimize device/service downtime due to update processing and to minimize user interaction (e.g., car should not distract the driver) (see "Hitless Update" in Section 2). While it may not be possible to avoid all downtime, there was agreement that one ought to strive for "no inappropriate" device downtime. This means minimal downtime impacting the user/operation of the device. The definition of "downtime" also depends on the use case, with a smart light bulb, the device could be "up" if the light is still on, even if some advanced services are unavailable for a short time. Whether an update can be done without rebooting the device depends on the software being installed, on the OS architecture, and potentially even on the hardware architecture. The cost/benefit ratio also plays a role.
- 重要的是尽量减少由于更新处理而导致的设备/服务停机时间，并尽量减少用户交互（例如，汽车不应分散驾驶员的注意力）（参见第2节中的“无故障更新”）。虽然不可能避免所有的停机时间，但大家一致认为应该努力做到“没有不适当的”设备停机时间。这意味着将影响设备用户/操作的停机时间降至最低。“停机时间”的定义还取决于使用情况，使用智能灯泡，即使某些高级服务在短时间内不可用，如果灯仍然亮着，设备也可能“启动”。是否可以在不重新启动设备的情况下进行更新取决于所安装的软件、操作系统体系结构，甚至可能取决于硬件体系结构。成本效益比也起到了一定的作用。
- It is desirable to minimize the time taken from the start of the update to when it is finished. In some systems with many devices (e.g., industrial lighting), this can be a challenge if updates need to be unicasted.
- 最好尽量减少从更新开始到更新完成所花费的时间。在一些具有许多设备（如工业照明）的系统中，如果更新需要单播，这可能是一个挑战。
- In some systems with multiple devices, it can be a challenge to ensure that all devices are at the same release level, especially if some devices are sleepy. There are some systems where ensuring all relevant devices are at the same release level is a hard requirement. In other cases, it is acceptable if devices converge much more slowly to the current release level.
- 在一些具有多个设备的系统中，确保所有设备处于相同的发布级别可能是一个挑战，特别是当一些设备处于休眠状态时。在某些系统中，确保所有相关设备处于相同的发布级别是一项困难的要求。在其他情况下，如果设备收敛到当前发布级别的速度慢得多，这是可以接受的。
- It ought not be possible for a factory worker to compromise the update process (e.g., copy signing keys and install unauthorized public keys/trust anchors) during the manufacturing process. There are typically two factories involved: the first factory produces microcontrollers and other components and the second factory produces the complete product, such as a fridge. This fridge contains many of the components previously manufactured. Hence, the firmware of components produced in the first stage may be six months old when the fridge leaves the factory. One does not want to install a firmware update when the fridge boots the first time. For that time, the firmware update happens already at the end of the manufacturing process.
- 在制造过程中，工厂工人不可能破坏更新过程（例如，复制签名密钥和安装未经授权的公钥/信任锚）。通常涉及两个工厂：第一个工厂生产微控制器和其他组件，第二个工厂生产完整的产品，如冰箱。这台冰箱包含许多以前制造的部件。因此，当冰箱出厂时，第一阶段生产的部件固件可能已使用六个月。当冰箱第一次启动时，不希望安装固件更新。此时，固件更新已在制造过程结束时进行。
- Should devices have a recovery procedure when the device gets compromised? How is the compromise detected?
- 当设备受到损害时，设备是否应该有恢复程序？如何检测妥协？
- There was a bit of discussion about the importance for IoT devices to know the current time for the purpose of checking certificate validity. For example, what does "real-time clock" (RTC) actually mean? And what constitutes "good enough" time? There are, however, cost, power, size, and environmental constraints that can make the addition of a real-time clock to an IoT device complex:
- 对于物联网设备了解当前时间以检查证书有效性的重要性进行了一些讨论。例如，“实时时钟”（RTC）实际上是什么意思？什么构成“足够好”的时间？然而，成本、功率、尺寸和环境限制可能会导致在物联网设备复合体中增加实时时钟：
o Cost: Battery- or supercap-backed RTC modules might be several times the cost of the rest of the bill of materials.
o 成本：电池或超级电容支持的RTC模块的成本可能是物料清单其余部分的几倍。
o Size: The battery and other components are often several times larger than the rest of the material.
o 尺寸：电池和其他组件通常比其他材料大几倍。
o Manufacturing: Some modules require an extra assembly step, because the battery could be damaged or explode at high temperatures during the reflow process.
o 制造：某些模块需要额外的组装步骤，因为在回流过程中，电池可能在高温下损坏或爆炸。
o Supply chain: Devices containing fitted batteries need additional supply-chain management to account for storage temperature and to avoid shipping aged devices.
o 供应链：装有电池的设备需要额外的供应链管理，以考虑存储温度并避免运输老化设备。
o Environmental: Real-time-clock modules are typically not rated at industrial temperature ranges. Those that are have extremely reduced lifetime at high temperatures.
o 环境：实时时钟模块通常不在工业温度范围内额定。这些材料在高温下的使用寿命极为缩短。
o Lifetime: Some of these modules last only a few years at the top of their environmental range.
o 寿命：这些模块中的一些在其环境范围的顶部只能使用几年。
While a good solution is needed, it is not clear whether there is one true solution. A recent proposal from Google called "Roughtime" [RT] may be worthwhile to explore.
虽然需要一个好的解决方案，但不清楚是否有一个真正的解决方案。谷歌最近提出的一个名为“粗糙时间”[RT]的提议可能值得探索。
- How do devices learn about a firmware update? Push or Pull? What should be required functionality for a firmware update protocol?
- 设备如何了解固件更新？推还是拉？固件更新协议需要什么功能？
- There is a need to find out whether a software update was successful. In one discussed solution, the bootloader analyzes the performance of the running image to determine which image to run (rather than just verifying the integrity of the received image). One of the key criteria is that the updated system is able to make a connection to the device management/software update infrastructure. As long as it is able to talk to the update infrastructure, it can receive another update. As an alternative perspective, the argument was made that one needs to have a way to update the system without having the full system running.
- 需要查明软件更新是否成功。在讨论的一个解决方案中，引导加载程序分析正在运行的映像的性能，以确定要运行的映像（而不仅仅是验证所接收映像的完整性）。关键标准之一是更新后的系统能够连接到设备管理/软件更新基础设施。只要它能够与更新基础设施对话，它就可以接收另一个更新。作为另一种观点，有人提出需要有一种方法来更新系统，而不必运行整个系统。
- Gateway requirements. In some deployments, gateways terminate the IP-based protocol communication and use non-IP mechanisms to communicate with other microcontrollers, for example, within a car. The gateway in such a system is the endpoint of the IP communication. The group had mixed feelings about the use of gateways versus the use of IP communication to every microcontroller. Participants argued that there is a lack of awareness of IPv6 header compression (with the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) standards) and of the possible benefits of IPv6 in those environments in terms of lowering the complexity of the overall system.
- 网关要求。在一些部署中，网关终止基于IP的协议通信，并使用非IP机制与其他微控制器通信，例如在汽车内。这种系统中的网关是IP通信的端点。该小组对网关的使用与每个微控制器的IP通信的使用有着复杂的感觉。与会者认为，对于IPv6报头压缩（采用低功耗无线个人区域网（6LoWPAN）标准）以及IPv6在这些环境中降低整个系统复杂性的可能好处缺乏认识。
- The amount of energy consumed due to software update needs to be minimized. For example, awakening a sleepy device regularly only to check for new software would seem wasteful if the device cannot feasibly be exploited while asleep. However, the trade-off is that once the device awakens with old software, there may be a window of vulnerability if some relevant exploit has been discovered.
- 由于软件更新而消耗的能量需要最小化。例如，如果设备在睡眠时不可能被利用，那么定期唤醒一个昏昏欲睡的设备只是为了检查新的软件似乎是浪费。然而，折衷的办法是，一旦设备使用旧软件唤醒，如果发现相关漏洞，可能会出现漏洞窗口。
- The amount of storage required for update ought to be minimized and can sometimes be significant. However, there are also benefits to schemes that store two or three different software images for robustness, e.g., if one has space for separate current last-known-good and being-updated images, then devices can better survive the buggy occasional updates that are also inevitable.
- 更新所需的存储量应该最小化，有时可能会很大。然而，存储两个或三个不同的软件映像以增强健壮性的方案也有好处，例如，如果其中一个有空间存储单独的当前最后一个已知产品和正在更新的映像，那么设备可以更好地在不可避免的错误偶尔更新中生存。
Which of the features discussed in the list above are nice to have? Which are required? Not all of these are required to achieve improvement. Which are most important?
上面列表中讨论的哪些功能很好？哪些是必需的？并非所有这些都是实现改进所必需的。哪些是最重要的？
Among the participants, there was consensus that supporting signatures (for integrity and authentication) of the firmware image itself and the need for partial updates were seen as important.
与会者一致认为，支持固件映像本身的签名（用于完整性和身份验证）以及部分更新的需要非常重要。
However, there were also concerns regarding the performance implications, since certain device categories may not utilize public key cryptography at all; hence, only a symmetric key approach seems viable, unless some other scheme such as a hash-based signature became practical (they currently aren't, due to signature size). This aspect raised concerns and triggered a discussion around the use of device management infrastructure, similar to Kerberos, that manages keys and distributes them to the appropriate parties. As such, in this setup, there could be a unique key shared with the key distribution center; but for use with specific services (such as a software update service), a fresh and unique secret would be distributed.
然而，由于某些设备类别可能根本不使用公钥密码，因此也存在对性能影响的担忧；因此，只有对称密钥方法似乎是可行的，除非其他一些方案，如基于散列的签名成为现实（由于签名的大小，它们目前不可行）。这一方面引起了关注，并引发了关于使用类似于Kerberos的设备管理基础设施的讨论，该基础设施管理密钥并将密钥分发给适当的各方。因此，在此设置中，可能存在与密钥分发中心共享的唯一密钥；但对于与特定服务（如软件更新服务）一起使用，将分发一个新的、唯一的秘密。
In addition to the requirements for the end devices, there are also infrastructure-related requirements. The infrastructure may consist of servers in the local network and/or various servers deployed on the Internet. It may also consist of some application-layer gateways. The potential benefits of having such a local server might include:
除了对终端设备的要求外，还有与基础设施相关的要求。基础设施可能包括本地网络中的服务器和/或部署在Internet上的各种服务器。它也可能由一些应用层网关组成。拥有此类本地服务器的潜在好处可能包括：
- The local server acting for neighboring nodes. For example, in a vehicle one microcontroller can process all firmware updates and redistribute the relevant parts of those to interconnected microcontrollers.
- 代理相邻节点的本地服务器。例如，在车辆中，一个微控制器可以处理所有固件更新，并将这些固件的相关部分重新分配给互连的微控制器。
- Local infrastructure could perform some digital signature checks on behalf of the devices, e.g., certificate-revocation checking.
- 本地基础设施可以代表设备执行一些数字签名检查，例如证书撤销检查。
- Local multicast can enable transmission of the same update to many devices.
- 本地多播可以将相同的更新传输到许多设备。
- Local servers can hide complexity associated with Network Address Translation (NAT) and firewalls from the device.
- 本地服务器可以对设备隐藏与网络地址转换（NAT）和防火墙相关的复杂性。
Another point related to local infrastructure is that since many IoT devices will not be (directly) connected to the Internet, but only through a gateway, there may in any case be a need to develop a software/firmware update mechanism that works in environments where no end-to-end Internet connectivity exists.
与本地基础设施相关的另一点是，由于许多物联网设备不会（直接）连接到互联网，而只能通过网关连接，因此在任何情况下都可能需要开发一种软件/固件更新机制，该机制在不存在端到端互联网连接的环境中工作。
Some current firmware update schemes need to identify devices. Different design approaches are possible.
某些当前固件更新方案需要识别设备。不同的设计方法是可能的。
- In an extreme form in one case, the decision about updating a device is made by the infrastructure based on the unique device identification. The operator of the firmware update infrastructure knows about the hardware and software requirements for the IoT devices, knows about the policy for updating the
- 在一种极端情况下，关于更新设备的决定是由基础设施基于唯一的设备标识做出的。固件更新基础设施的运营商了解物联网设备的硬件和软件要求，了解更新设备的策略
device, etc. The device itself is provisioned with credentials so that it can verify a firmware update coming from an authorized device.
设备等。设备本身配置了凭据，以便它可以验证来自授权设备的固件更新。
- In another extreme, the device has knowledge about the software and hardware configuration and possible dependencies. It consults software repositories to obtain those software packages that are most appropriate. Verifying the authenticity of the software packages/firmware images will still be required.
- 在另一个极端中，设备了解软件和硬件配置以及可能的依赖关系。它咨询软件存储库以获得最合适的软件包。仍然需要验证软件包/固件映像的真实性。
Hence, in some deployed software update mechanisms there is no desire for the device to be identified beyond the need to exchange information about the most recent software versions. For other devices, it is seen as important to identify the device itself in order to provide the appropriate firmware image/software packages.
因此，在一些已部署的软件更新机制中，除了需要交换有关最新软件版本的信息外，不需要识别设备。对于其他设备，识别设备本身以提供适当的固件映像/软件包非常重要。
Related to device identification, various privacy concerns arise, such as the need to determine what information is provided to whom and the uses to which this information is put. For IoT devices where there is a close relationship to an individual (see [RFC6973]), privacy concerns are likely higher than for devices where such a relationship does not exist (e.g., a sensor measuring concrete). The software/firmware update mechanism should, however, not make the privacy situation of IoT devices worse. The proposal from the group was to introduce a minimal requirement of not sending any new identifiers over an unencrypted channel as part of an update protocol.
与设备识别相关，出现了各种隐私问题，例如需要确定向谁提供哪些信息以及这些信息的用途。对于与个人有密切关系的物联网设备（见[RFC6973]），隐私问题可能高于不存在这种关系的设备（例如，传感器）。然而，软件/固件更新机制不应使物联网设备的隐私状况恶化。该小组的建议是引入一项最低要求，即作为更新协议的一部分，不通过未加密的通道发送任何新的标识符。
However, software updates will provide yet another venue in which the tension between those advocating better privacy and those seeking to monetize information will play out. It is in the nature of software update that it requires devices to sometimes "call home" and such interactions provide fertile ground for monetization.
然而，软件更新将提供另一个平台，在这个平台上，那些提倡更好的隐私的人和那些寻求信息货币化的人之间的紧张关系将得到缓解。软件更新的本质要求设备有时“呼叫总部”，而这种交互为货币化提供了肥沃的土壤。
There were quite a few points revolving around authorization:
围绕授权有很多要点：
- Who can accept or reject an update? Is it the owner of the device, the user, or both? The user may not necessarily be the owner.
- 谁可以接受或拒绝更新？它是设备的所有者、用户还是两者都是？用户不一定是所有者。
- With products that fall under a regulatory structure, such as healthcare, you don't want firmware other than what has been accredited.
- 对于属于监管结构的产品，如医疗保健，您不需要已认证的固件以外的其他固件。
- In some cases, it will be very difficult for a firmware update system to communicate to users that an update is available. Doing so may require tracking the device and its status with regard to the installed firmware/software, with all the privacy downsides if such tracking is badly done.
- 在某些情况下，固件更新系统将很难与用户通信更新可用。这样做可能需要跟踪设备及其有关已安装固件/软件的状态，如果这种跟踪做得不好，则会带来所有隐私方面的负面影响。
- Not all updates are the same. Security updates are often treated differently compared to feature updates, and the authorization for these may differ.
- 并非所有更新都相同。与功能更新相比，安全更新的处理方式通常有所不同，对这些更新的授权也可能有所不同。
- Some people may choose to decline updates, often on the basis that their system is currently stable, but also possibly due to concerns about unwanted changes, such as the HP printer firmware update pushed in March 2016 [HP-Firmware] that turned off features that end users liked.
- 有些人可能会选择拒绝更新，通常是因为他们的系统目前稳定，但也可能是因为担心不必要的更改，例如2016年3月推出的HP打印机固件更新[HP固件]，关闭了最终用户喜欢的功能。
There was quite a bit of discussion about end-of-support for products/devices and how to handle that.
关于产品/设备支持的结束以及如何处理这一问题，有很多讨论。
- How should end-of-support or end-of-features be treated? Devices are often deployed for 10+ years (or even longer in some verticals). Device makers may not want or be able to support software and services for such an extended period of time. Will these devices stop working after a certain, previously unannounced period of time, such as Eye-Fi cards [EYEFI]?
- 应如何处理支持结束或功能结束？设备通常部署10年以上（在某些垂直领域甚至更长）。设备制造商可能不希望或无法在如此长的时间内支持软件和服务。这些设备是否会在一段之前未宣布的特定时间后停止工作，例如Eye-Fi卡[EYEFI]？
- There will be a broad range of device makers involved in IoT, who may differ substantially in terms of how well they can handle the full device life cycle. Some will be large commercial enterprises that are used to dealing with long device lifetimes, whereas others may be very small commercial entities where the device lifetime may be longer than the company lifetime. Yet other devices may be the result of open-source activities that prosper or flounder. The problem of end-of-support arises in all these cases, though feasible solutions for software update may substantially differ. In some cases, device makers may not be willing to continue to update devices, for example, due to a change in business strategies caused by a merger. In yet other cases, a company may have gone bankrupt.
- IoT将涉及范围广泛的设备制造商，他们在如何处理整个设备生命周期方面可能存在很大差异。一些是大型商业企业，习惯于处理较长的设备寿命，而另一些可能是非常小的商业实体，设备寿命可能比公司寿命长。然而，其他设备可能是繁荣或挣扎的开源活动的结果。在所有这些情况下都会出现支持终止的问题，尽管软件更新的可行解决方案可能会有很大的不同。在某些情况下，设备制造商可能不愿意继续更新设备，例如，由于合并导致的业务战略变化。在其他情况下，公司可能已经破产。
- While there are many legal, ethical, and business-related questions, can we technically enable transfer of device service to another provider? Could there even be business models for entities that take over device updates for original device makers that no longer wish to handle software update?
- 虽然存在许多法律、道德和业务相关的问题，但我们能否从技术上允许将设备服务转移到另一个提供商？对于不再希望处理软件更新的原始设备制造商来说，接管设备更新的实体是否还会有商业模式？
- The release of code, as it was done with the Little Printer manufactured and developed by a company called "Berg" [LittlePrinter], could provide a useful example. While the community took over the support in that case, this can hardly be assumed in all cases. Just releasing the source code for a device will not necessarily motivate others to work on the code, to fix bugs, or to maintain a service. Nevertheless, escrowing code so that the community can take it over if a company fails is one possible option.
- 代码的发布，就像一家名为“Berg”[LittlePrinter]的公司制造和开发的小型打印机一样，可以提供一个有用的例子。虽然社区在这种情况下接管了支持，但很难在所有情况下都假定这一点。仅仅发布设备的源代码并不一定会激励其他人编写代码、修复bug或维护服务。尽管如此，托管代码是一种可能的选择，这样当一家公司倒闭时，社区可以接管它。
- The situation gets more complex when the device has security mechanisms to ensure that only selected parties are allowed to update the device (which is really a basic requirement for any secure software update). In this case, private signing keys (or similar) may need to be made available as well, which could introduce security problems for already-deployed software. In the best case, it changes assumptions made about the trust model and about who can submit updates.
- 当设备具有安全机制以确保仅允许选定方更新设备时（这实际上是任何安全软件更新的基本要求），情况会变得更加复杂。在这种情况下，可能还需要提供私有签名密钥（或类似密钥），这可能会给已经部署的软件带来安全问题。在最好的情况下，它会改变关于信任模型和谁可以提交更新的假设。
- How should deployed devices behave when they are end-of-support and support ends? Many of them may still function normally, but others may fail due to the absence of cloud infrastructure services. Some products are probably expected to fail safely, similarly to a smoke alarm that makes a loud noise when the battery becomes empty. Cell phones without a contract can, in some countries, still be used for emergency services (although at the expense of society due to untraceable hoax calls), as discussed in RFC 7406 [RFC7406].
- 当部署的设备处于支持端和支持端时，它们应该如何工作？它们中的许多可能仍能正常运行，但其他可能会由于缺少云基础设施服务而失败。有些产品可能会出现安全故障，类似于电池耗尽时发出巨大噪音的烟雾报警器。如RFC 7406[RFC7406]所述，在某些国家，未签订合同的手机仍可以用于紧急服务（尽管由于无法追踪的恶作剧电话而导致社会损失）。
The recommendation that can be provided to device makers and users is to think about the end-of-support and end-of-support scenarios ahead of time and plan for those. While device makers rarely want to consider what happens if their business fails, it is definitely legitimate to consider scenarios where they are hugely successful and want to evolve a product line instead of supporting previously sold products forever. Maybe there is also value in subscription-based models where product and device support is only provided as long as the subscription is paid. Without a subscription, the product is deactivated and cannot pose a threat to the Internet at large.
可以向设备制造商和用户提供的建议是提前考虑支持结束和支持结束场景，并为这些场景制定计划。虽然设备制造商很少想考虑如果他们的业务失败了，但考虑到它们非常成功的情况，并希望开发一条产品线，而不是永远支持先前销售的产品，这是绝对合法的。在基于订阅的模式中，产品和设备支持只在订阅付费的情况下提供，这可能也有价值。如果没有订阅，该产品将被停用，不能对整个互联网构成威胁。
Workshop participants also discussed how to create incentives for companies to ship software updates, which is particularly important for products that will be deployed in the market for a long time. It is also further complicated by complex value chains.
研讨会参与者还讨论了如何激励公司发布软件更新，这对于将在市场上长期部署的产品尤为重要。它还因复杂的价值链而变得更加复杂。
- Companies shipping software updates benefit from improved security. Their devices are less likely to be abused as a vector to launch other attacks, whether on their own networks or (as part of a botnet) on other Internet hosts. This clearly creates an incentive to support and use software updates.
- 提供软件更新的公司受益于改进的安全性。他们的设备不太可能被滥用作为发动其他攻击的媒介，无论是在他们自己的网络上还是在其他互联网主机上（作为僵尸网络的一部分）。这显然会鼓励支持和使用软件更新。
- On the other hand, updates can also break things. The negative customer experience can be due to service interruptions during or after the update process but can also result from bad experience from deliberate changes introduced as part of an update -- such as a feature that is not available anymore, or a "bug" that another service has relied upon being fixed.
- 另一方面，更新也会破坏事物。负面的客户体验可能是由于更新过程中或之后的服务中断造成的，但也可能是由于作为更新的一部分而引入的故意更改造成的不良体验造成的，例如不再可用的功能，或者其他服务依赖于修复的“bug”。
- For most classes of device, there does not seem to be a regulatory requirement to report or fix vulnerabilities, similar to data-breach-notification laws.
- 对于大多数类别的设备，似乎没有报告或修复漏洞的监管要求，类似于数据泄露通知法。
- Subscription models for device management were suggested so that companies providing the service have an economic interest in keeping devices online (and updated for that).
- 提出了设备管理的订阅模式，以便提供服务的公司在保持设备在线（并为此进行更新）方面具有经济利益。
From a security point of view, it is important to know what devices are out there and what version of software they run. One workshop paper [PLONKA] reported measurements that were initially done on buggy devices first distributed in 2003, and that were still detectable in significant numbers just before the workshop 13 years later. As such, in addition to the firmware update mechanism, companies have been offering device management solutions that allow OEMs to keep track of their devices. Tracking these devices and their status is still challenging since some devices are only connected irregularly or are only turned on when needed (such as a hockey alarm that is only turned on before a match).
从安全的角度来看，了解哪些设备以及它们运行的软件版本很重要。一份研讨会论文[PLONKA]报告了最初在2003年首次发布的有轨设备上进行的测量，在13年后的研讨会召开之前，仍有大量的测量结果被检测出来。因此，除了固件更新机制外，公司还提供了设备管理解决方案，允许OEM跟踪其设备。跟踪这些设备及其状态仍然具有挑战性，因为有些设备只是不规则地连接，或者只有在需要时才打开（例如曲棍球报警器，只有在比赛前才打开）。
Various stakeholders have a justified interest in knowing something about deployed devices. For example:
不同的利益相关者对了解已部署设备有着合理的兴趣。例如：
- Manufacturers and other players in the supply chain are interested to know what devices are out there, how many have been sold, and what devices are out there but have not been sold. This could help to understand which firmware versions to support and for how long.
- 制造商和供应链中的其他参与者很想知道哪些设备已经上市，有多少已经售出，还有哪些设备已经上市但尚未售出。这有助于了解支持哪些固件版本以及支持多长时间。
- Device users, owners, and customers like these may want to know what devices are installed over a longer period of time, what software/firmware version is the device running, what is the uptime of each of these devices, what types of faults have occurred, etc. Forgotten devices may pose problems, particularly if they (have the potential to) behave badly.
- 此类设备用户、所有者和客户可能希望了解在较长时间内安装了哪些设备、设备运行的软件/固件版本、每个设备的正常运行时间、发生了哪些类型的故障等。被遗忘的设备可能会带来问题，尤其是如果它们（有可能）表现不好。
- To an extent, network operators offering services to device owners and other actors may also need similar information, for example, to control botnets.
- 在某种程度上，向设备所有者和其他参与者提供服务的网络运营商也可能需要类似的信息，例如，控制僵尸网络。
- Researchers doing analysis on the state of the Internet ecosystem (such as what protocols are being used, how much data IoT devices generate, etc.,) need measurements for their work.
- 对互联网生态系统的状态进行分析的研究人员（如正在使用的协议、物联网设备产生的数据量等）需要对其工作进行测量。
There can easily be some invasiveness in approaches to acquiring such measurements. The challenge was put forward to find ways to create measurement infrastructures that are privacy preserving. Arnar Birgisson noted that there are privacy-preserving statistical techniques, such as RAPPOR [RAPPOR], and Ned Smith added that techniques like Intel's Enhanced Privacy ID (EPID) may play a role in maintaining some level of anonymity for the IoT device (owners) while also enabling measurement. It seemed clear that naive approaches to measurement (e.g., where devices are willing to expose a unique identifier to anyone on request) are unlikely to prove sufficient.
在获取此类测量的方法中很容易存在一些侵入性。提出的挑战是如何创建保护隐私的测量基础设施。Arnar Birgisson指出，有一些保护隐私的统计技术，如RAPPOR[RAPPOR]，Ned Smith补充说，Intel的增强隐私ID（EPID）等技术可能会在保持物联网设备（所有者）某种程度的匿名性的同时实现测量。显然，天真的测量方法（例如，设备愿意根据请求向任何人公开唯一标识符）不太可能被证明是足够的。
There was some discussion of the requirements for mesh-based networks, mainly relating to industrial lighting. In these networks, software update can impose unacceptable performance burdens, especially if there are many devices, some of which may be sleepy.
会议讨论了主要与工业照明有关的基于网格的网络的要求。在这些网络中，软件更新可能会带来不可接受的性能负担，特别是如果有许多设备，其中一些设备可能处于休眠状态。
The workshop discussed whether some forms of multicast (perhaps not IP multicast) would be needed to provide acceptable solutions for software update in such cases. It was not clear at which layer a multicast solution might be effective in such cases, though there did not seem to be any clearly applicable standards-based approach that was available at the time of the workshop.
研讨会讨论了是否需要某些形式的多播（可能不是IP多播）来为此类情况下的软件更新提供可接受的解决方案。在这种情况下，不清楚在哪一层多播解决方案可能有效，尽管在研讨会期间似乎没有任何明确适用的基于标准的方法。
There was recognition that there are, and perhaps always will be, large numbers of devices that can be, or have been, compromised. While updating these can mitigate problems, there will always be new devices added to networks that cannot be updated (for various reasons); so the question of what, if anything, to do about compromised devices was discussed.
人们认识到，现在有，也许永远会有，大量的设备可能会或已经被破坏。虽然更新这些设备可以缓解问题，但总会有新设备添加到无法更新的网络中（出于各种原因）；因此，我们讨论了如何处理受损设备的问题。
- There may be value if it were possible to single out a device that shows faulty behavior or has been compromised, and to shut it down in some sense.
- 如果能够挑出一个表现出错误行为或已被破坏的设备，并在某种意义上将其关闭，那么这可能是有价值的。
- Prior work in the IETF on Network Endpoint Assessment (NEA) [NEA] allowed assessing the "posture" of devices. Posture refers to the hardware or software configuration of a device and may include knowledge that the software installed is up to date. The obtained information can then be used by some network infrastructure to create a quarantined region network around the device.
- IETF先前关于网络端点评估（NEA）[NEA]的工作允许评估设备的“姿态”。姿态是指设备的硬件或软件配置，可能包括安装的软件是最新的。然后，某些网络基础设施可以使用获得的信息在设备周围创建隔离区域网络。
- RFC 6561 [RFC6561] describes one scheme for an ISP to send "signals" to customers about hosts (usually those that are part of a botnet or generating spam) in their home network.
- RFC 6561[RFC6561]描述了一种ISP向客户发送有关其家庭网络中主机（通常是僵尸网络的一部分或产生垃圾邮件的主机）的“信号”的方案。
- Neither RFC 6561 nor NEA has found widespread deployment. Whether such mechanisms can be more successful in the IoT environment has yet to be studied.
- RFC 6561和NEA均未发现广泛部署。这些机制在物联网环境中是否更为成功还有待研究。
The conclusion of the discussion at the workshop itself was that there is some interest in identifying and stopping misbehaving devices, but the actual solution mechanisms are unclear.
研讨会本身讨论的结论是，人们对识别和停止行为不端的设备有一些兴趣，但实际的解决机制尚不清楚。
There were a number of points discussed at the workshop that don't neatly fit under the above headings but that are worth recording. Those include:
研讨会上讨论的许多要点并不完全符合上述标题，但值得记录。这些措施包括：
- Complex questions can arise when considering the impact of the lack of updates on other devices, other persons, or the public in general. If I don't update my device, and it is used to attack a random host on the Internet, but at no apparent cost to me, then what incentive do I have to do updates that would have protected that random host? What incentive has my device's vendor to have provided those updates in advance? An example of such a case can be found in DDoS attacks from IoT devices, such as printers [SNMP-DDOS] and cameras [DDOS-KREBS].
- 当考虑到缺乏更新对其他设备、其他人或公众的影响时，可能会出现复杂的问题。如果我不更新我的设备，并且它被用来攻击互联网上的一个随机主机，但对我来说没有明显的成本，那么我有什么动机去做更新来保护这个随机主机呢？我的设备供应商提前提供这些更新有什么动机？这种情况的一个例子是来自物联网设备的DDoS攻击，如打印机[SNMP-DDoS]和摄像头[DDoS-KREBS]。
- With some IoT devices, there are many stakeholders contributing to the end product (e.g., contributing different subsystems). Ensuring that vulnerabilities are fixed and software/firmware updates are communicated through the value chain is known to be difficult, as demonstrated in [OS14].
- 对于某些物联网设备，有许多利益相关者为最终产品做出贡献（例如，贡献不同的子系统）。如[OS14]所示，确保漏洞得到修复，并且通过价值链传达软件/固件更新，这是众所周知的困难。
- What about forgotten devices? There are many such, and there will be more. Even though they are forgotten, such devices may be useless consumers of electricity, or they may be part of some critical system.
- 被遗忘的设备呢？这样的事情很多，将来还会更多。尽管这些设备被遗忘了，但它们可能是无用的电力消费者，或者它们可能是某些关键系统的一部分。
- Can we determine whether an update impacts other devices in the Internet? Updates to one device can have unintended impact on other devices that depend on it. This can have cascading effects if we are not careful. Changing the format of the output of a sensor could have cascading impacts, e.g., if some actuator reacts to the presence/absence of that sensor's data.
- 我们能否确定更新是否会影响Internet上的其他设备？对一个设备的更新可能会对依赖它的其他设备产生意外影响。如果我们不小心，这可能会产生级联效应。更改传感器输出的格式可能会产生级联影响，例如，如果某些执行器对传感器数据的存在/不存在作出反应。
- How should a device behave when it is running out-of-date software? The example of a smoke alarm was mentioned. We don't want 100 devices in a living room to start beeping when their batteries run low or when they cannot communicate with the cloud. But are devices supposed to simply stop working?
- 当设备运行过时的软件时，它应该如何运行？提到了烟雾报警器的例子。我们不希望客厅里的100台设备在电池电量不足或无法与云通信时发出嘟嘟声。但是，这些设备应该只是停止工作吗？
- The IETF has published a specification that uses the Cryptographic Message Syntax (CMS) to protect firmware packages, as described in RFC 4108 [RFC4108], which also contains metadata to describe the firmware image itself. During the workshop, the question was raised whether a solution will, in the future, be needed that is post-quantum secure. A post-quantum cryptosystem is a system that is secure against quantum computers that have more than a trivial number of quantum bits. It is open to conjecture whether it is feasible to build such a machine, but current signature algorithms are known not to be post-quantum secure. This would require introducing technologies like the Hash-based Merkle Tree Signature (MTS) [HOUSLEY], which was presented and discussed at the workshop. The downsides of such solutions are their novelty and, for these use cases, the fairly large signature or key sizes involved; e.g., depending on the parameters, a signature could easily have a size of 5-10 KiB [HASHSIG] [XMSS]. While it is likely that post-quantum secure signature algorithms will be needed for software updates at some point in time, it may be the case that such algorithms will be needed sooner for services requiring long-term confidentiality, (e.g., using Transport Layer Security (TLS)), so it was not clear that this application would be a first-mover in terms of post-quantum security.
- IETF发布了一项规范，该规范使用加密消息语法（CMS）保护固件包，如RFC 4108[RFC4108]所述，其中还包含描述固件映像本身的元数据。在研讨会期间，有人提出了一个问题，即未来是否需要一种后量子安全的解决方案。后量子密码系统是一种针对量子计算机的安全系统，量子计算机拥有的量子比特数超过了微不足道的数量。人们可以猜测建立这样一台机器是否可行，但目前的签名算法并不具备后量子安全性。这需要引入一些技术，如研讨会上介绍和讨论的基于散列的Merkle树签名（MTS）[HOUSLEY]。这种解决方案的缺点是其新颖性，对于这些用例，涉及的签名或密钥大小相当大；e、 例如，根据参数，签名的大小可能很容易达到5-10 KiB[HASHSIG][XMSS]。虽然在某个时间点软件更新可能需要后量子安全签名算法，但对于需要长期保密的服务（例如，使用传输层安全性（TLS）），可能需要更快地使用此类算法，因此，目前尚不清楚该应用程序是否会成为后量子安全领域的先行者。
- Many devices that use certificates do not check the revocation status of certificates, even though extensions like Online Certificate Status Protocol (OCSP) stapling exists [RFC6961] and is increasingly deployed with Web browsers. The workshop participants did not reach a conclusion regarding the recommendations of certificate revocation checking, although the importance has been recognized. The reluctance regarding deploying certificate revocation deserves further investigation.
- 许多使用证书的设备不检查证书的吊销状态，即使存在诸如在线证书状态协议（OCSP）装订之类的扩展[RFC6961]，并且越来越多地部署在Web浏览器中。研讨会参与者没有就证书撤销检查的建议得出结论，尽管其重要性已得到承认。关于部署证书撤销的不情愿值得进一步调查。
The workshop participants discussed some tentative conclusions and possible next steps:
讲习班与会者讨论了一些初步结论和可能的下一步行动：
- There was strong agreement that having some standardized secure (authorized and authenticated) software update would be an improvement over having none.
- 大家一致认为，有一些标准化的安全（授权和认证）软件更新将比没有软件更新更好。
- It would be valuable to find agreement on the right scope for a standardized software/firmware update mechanism. It is not clear that an entire update system can or should be standardized, but there may be some aspects of such solutions where standards would be beneficial, e.g., (meta-)data formats and/or protocols for distributing firmware updates. More discussion is needed to identify which parts of the problem space could benefit from standardization.
- 就标准化软件/固件更新机制的正确范围达成一致意见是很有价值的。整个更新系统是否可以或是否应该标准化尚不清楚，但此类解决方案的某些方面可能有利于标准化，例如，（元数据）数据格式和/或用于分发固件更新的协议。需要进行更多的讨论，以确定问题空间的哪些部分可以从标准化中受益。
- It will be useful to investigate solutions to install updates with no operational interruption as well as ways to distribute software updates without disrupting network operations (specifically, in low-power wireless networks), including the development of a multicast transfer mechanism (with appropriate security).
- 研究在不中断操作的情况下安装更新的解决方案，以及在不中断网络操作（特别是在低功率无线网络中）的情况下分发软件更新的方法，包括开发多播传输机制（具有适当的安全性），将是非常有用的。
- There will almost certainly be a need for a way to transfer authority/responsibility for updates, particularly considering end-of-support cases. This is very close to calling for a standard way to "root" devices as a feature of all devices.
- 几乎肯定需要一种方法来转移更新的权限/责任，特别是考虑到支持案例的结束。这非常接近于要求将“根”设备作为所有设备的一项功能的标准方式。
- We would benefit from documentation of proofs-of-concept of software/firmware updates for constrained devices on different operating system architectures. The IETF Light-Weight Implementation Guidance (lwig) Working Group may be a good venue for such documents.
- 对于不同操作系统架构上受限设备的软件/固件更新概念证明文件，我们将从中受益。IETF轻型实施指南（lwig）工作组可能是编写此类文件的良好场所。
This document summarizes an IAB workshop on software/firmware updates and the entire content is, therefore, security related. Standardizing and deploying a software/firmware update mechanism for use with IoT devices could help fix security vulnerabilities faster and, in some cases, be the only via to get vulnerability patched at all.
本文档总结了IAB关于软件/固件更新的研讨会，因此，整个内容与安全相关。标准化和部署用于物联网设备的软件/固件更新机制有助于更快地修复安全漏洞，在某些情况下，这是修补漏洞的唯一途径。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[BB14] Barrett, B., "Winks Outage Shows Us How Frustrating Smart Homes Could Be", April 2014, <http://www.wired.com/2015/04/smart-home-headaches/>.
[BB14]Barrett，B.，“Winks停电向我们展示了智能家庭可能会多么令人沮丧”，2014年4月<http://www.wired.com/2015/04/smart-home-headaches/>.
[BS14] Schneier, B., "The Internet of Things Is Wildly Insecure -- And Often Unpatchable", January 2014, <https://www.schneier.com/essays/archives/2014/01/ the_internet_of_thin.html>.
[BS14]Schneier，B.，“物联网非常不安全，而且常常无法修补”，2014年1月<https://www.schneier.com/essays/archives/2014/01/ _thin.html>的互联网。
[BSDIFF] Percival, C., "Matching with Mismatches and Assorted Applications", September 2016, <https://ora.ox.ac.uk/objects/ uuid:4f0d53cc-fb9f-4246-a835-3c8734eba735/datastreams/ THESIS01>.
[BSDIFF]Percival，C.，“匹配不匹配和分类应用”，2016年9月<https://ora.ox.ac.uk/objects/ uuid:4f0d53cc-fb9f-4246-a835-3c8734eba735/datastreams/THESIS01>。
[COURGETTE] Google, "Software Updates: Courgette", September 2016, <https://www.chromium.org/developers/design-documents/ software-updates-courgette>.
[西葫芦]谷歌，“软件更新：西葫芦”，2016年9月<https://www.chromium.org/developers/design-documents/ 软件更新小胡瓜>。
[DDOS-KREBS] Goodin, D., "Record-breaking DDoS reportedly delivered by >145k hacked cameras", September 2016, <http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[DDOS-KREBS]Goodin，D.，“据报道，超过145k台被黑客攻击的摄像机造成了创纪录的DDOS”，2016年9月<http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[EYEFI] Aldred, J., "Eye-Fi to Drop Suport for Some Cards. They Will 'Magically' Stop Working on September 16, 2016", June 2016, <http://www.diyphotography.net/eyefi-drop-support-cards-will-magically-stop-working-september-16-2016/>.
[EYEFI]Aldred，J.，“Eye-Fi放弃对一些卡片的支持。它们将在2016年9月16日“神奇地”停止工作”，2016年6月<http://www.diyphotography.net/eyefi-drop-support-cards-will-magically-stop-working-september-16-2016/>.
[FTC] Federal Trade Commission, "FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks", January 2015, <https://www.ftc.gov/system/files/documents/reports/ federal-trade-commission-staff-report-november-2013- workshop-entitled-internet-things-privacy/150127iotrpt.pdf>.
[FTC]联邦贸易委员会，“FTC关于物联网的报告敦促公司采取最佳做法解决消费者隐私和安全风险”，2015年1月<https://www.ftc.gov/system/files/documents/reports/ 联邦-trade-commission-staff-report-2013-11-题为“互联网隐私”的研讨会/150127iotrpt.pdf>。
[HASHSIG] Langley, A., "Hash based signatures", July 2013, <https://www.imperialviolet.org/2013/07/18/hashsig.html>.
[HASHSIG]Langley，A.，“基于哈希的签名”，2013年7月<https://www.imperialviolet.org/2013/07/18/hashsig.html>.
[HOUSLEY] Housley, R., "Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, draft-housley-cms-mts-hash-sig-07, June 2017.
[HOUSLEY]HOUSLEY，R.，“在加密消息语法（CMS）中使用基于散列的Merkle树签名（MTS）算法”，正在进行的工作，草稿-HOUSLEY-CMS-MTS-Hash-sig-072017年6月。
[HP-Firmware] BoingBoing, "HP detonates its timebomb: printers stop accepting third party ink en masse", September 2016, <http://boingboing.net/2016/09/19/ hp-detonates-its-timebomb-pri.html>.
[HP固件]BoingBoing，“HP引爆定时炸弹：打印机停止接受第三方墨水”，2016年9月<http://boingboing.net/2016/09/19/ 惠普引爆了它的定时炸弹pri.html>。
[IoTSU] IAB, "Internet of Things Software Update Workshop (IoTSU) 2016", June 2016, <https://www.iab.org/activities/workshops/iotsu/>.
[IoTSU]IAB，“2016年物联网软件更新研讨会（IoTSU）”，2016年6月<https://www.iab.org/activities/workshops/iotsu/>.
[LittlePrinter] Berg, "The future of Little Printer", September 2014, <http://littleprinterblog.tumblr.com/post/97047976103/ the-future-of-little-printer>.
[LittlePrinter]Berg，“小打印机的未来”，2014年9月<http://littleprinterblog.tumblr.com/post/97047976103/ 小打印机的未来>。
[NEA] IETF, "Network Endpoint Assessment (nea) Concluded WG", October 2016, <https://datatracker.ietf.org/wg/nea/charter/>.
[NEA]IETF，“网络端点评估（NEA）工作组结束”，2016年10月<https://datatracker.ietf.org/wg/nea/charter/>.
[OS-Support] Dong, W., Chen, C., Liu, X., and J. Bu, "Providing OS Support for Wireless Sensor Networks: Challenges and Approaches", DOI 10.1109/SURV.2010.032610.00045, May 2010, <http://ieeexplore.ieee.org/stamp/ stamp.jsp?arnumber=5462978>.
[OS Support]Dong，W.，Chen，C.，Liu，X.，和J.Bu，“为无线传感器网络提供OS支持：挑战和方法”，DOI 10.1109/SURV.2010.032610.000452010年5月<http://ieeexplore.ieee.org/stamp/ stamp.jsp？arnumber=5462978>。
[OS14] Oppenheim, L. and S. Tal, "Too Many Cooks: Exploiting the Internet of TR-069 Things", December 2014, <http://mis.fortunecook.ie/ too-many-cooks-exploiting-tr069_tal-oppenheim_31c3.pdf>.
[OS14]Oppenheim，L.和S.Tal，“厨师太多：利用TR-069物联网”，2014年12月<http://mis.fortunecook.ie/ 太多的厨师在利用tr069\u tal-oppenheim\u 31c3.pdf>。
[PACMAN] "pacman", 2016, <https://www.archlinux.org/pacman/>.
[吃豆人]“吃豆人”，2016年<https://www.archlinux.org/pacman/>.
[PLONKA] Plonka, D. and E. Boschi, "The Internet of Things Old and Unmanaged", June 2016, <https://down.dsg.cs.tcd.ie/iotsu/subs/ IoTSU_2016_paper_25.pdf>.
[PLONKA]PLONKA，D.和E.Boschi，“旧的和未管理的物联网”，2016年6月<https://down.dsg.cs.tcd.ie/iotsu/subs/ IoTSU_2016_paper_25.pdf>。
[RAPPOR] Erlingsson, U., Pihur, V., and A. Korolova, "RAPPOR", DOI 10.1145/2660267.2660348, July 2014, <http://dl.acm.org/citation.cfm?doid=2660267.2660348>.
[RAPPOR]Erlingsson，U.，Pihur，V.，和A.Korolova，“RAPPOR”，DOI 10.1145/2660267.26603482014年7月<http://dl.acm.org/citation.cfm?doid=2660267.2660348>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.
[RFC4108]Housley，R.“使用加密消息语法（CMS）保护固件包”，RFC 4108，DOI 10.17487/RFC4108，2005年8月<https://www.rfc-editor.org/info/rfc4108>.
[RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, "Recommendations for the Remediation of Bots in ISP Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, <https://www.rfc-editor.org/info/rfc6561>.
[RFC6561]Livingood，J.，Mody，N.，和M.O'Reirdan，“ISP网络中机器人修复的建议”，RFC 6561，DOI 10.17487/RFC65612012年3月<https://www.rfc-editor.org/info/rfc6561>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961]Pettersen，Y，“传输层安全性（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC69611913年6月<https://www.rfc-editor.org/info/rfc6961>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<https://www.rfc-editor.org/info/rfc6973>.
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., and D. Kroeselberg, "Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, December 2014, <https://www.rfc-editor.org/info/rfc7406>.
[RFC7406]Schulzrinne，H.，McCann，S.，Bajko，G.，Tschofenig，H.，和D.Kroeselberg，“处理未经验证和未经授权设备的应急服务架构扩展”，RFC 7406，DOI 10.17487/RFC7406，2014年12月<https://www.rfc-editor.org/info/rfc7406>.
[RPM] "Red Hat Package Manager (RPM)", 2016, <http://rpm.org/>.
[RPM]“红帽包装经理（RPM）”，2016年<http://rpm.org/>.
[RT] Google, "Roughtime", September 2016, <https://roughtime.googlesource.com/roughtime>.
[RT]谷歌，“艰苦时光”，2016年9月<https://roughtime.googlesource.com/roughtime>.
[SNMP-DDOS] BITAG, "SNMP Reflected Amplification DDoS Attack Mitigation", August 2012, <https://www.bitag.org/documents/ SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf>.
[SNMP-DDOS]BITAG，“SNMP-DDOS攻击缓解”，2012年8月<https://www.bitag.org/documents/ SNMP DDoS攻击缓解。pdf>。
[WP29] Article 29 Data Protection Working Party, "Opinion 8/2014 on the on Recent Developments on the Internet of Things", 14/EN, WP 223, September 2014, <http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/ wp223_en.pdf>.
[WP29]第29条数据保护工作组，“关于物联网最新发展的意见8/2014”，14/EN，WP 223，2014年9月<http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/ wp223_en.pdf>。
[XMSS] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. Mohaisen, "XMSS: Extended Hash-Based Signatures", Work in Progress, draft-irtf-cfrg-xmss-hash-based-signatures-10, July 2017.
[XMSS]Huelsing，A.，Butin，D.，Gazdag，S.，Rijneveld，J.，和A.Mohaisen，“XMSS:扩展的基于散列的签名”，正在进行的工作，草稿-irtf-cfrg-XMSS-Hash-Based-Signatures-102017年7月。
The following individuals helped to organize the workshop: Jari Arkko, Arnar Birgisson, Carsten Bormann, Stephen Farrell, Russ Housley, Ned Smith, Robert Sparks, and Hannes Tschofenig.
以下个人帮助组织了研讨会：贾里·阿尔科、阿纳尔·比吉斯森、卡斯滕·鲍曼、斯蒂芬·法雷尔、罗斯·霍斯利、内德·史密斯、罗伯特·斯帕克斯和汉内斯·茨霍芬尼。
The list of accepted position papers is below. Links to these, and to the workshop agenda and raw minutes are accessible at: <https://down.dsg.cs.tcd.ie/iotsu/>.
接受的职位论文清单如下。可通过以下网址访问这些内容、研讨会议程和原始会议记录的链接：<https://down.dsg.cs.tcd.ie/iotsu/>.
- R. Housley, "Position Paper for Internet of Things Software Update Workshop (IoTSU)"
- R.Housley，“物联网软件更新研讨会（IoTSU）的立场文件”
- D. Thomas and A. Beresford, "Incentivising software updates"
- D.Thomas和A.Beresford，“激励软件更新”
- L. Zappaterra and E. Dijk, "Software Updates for Wireless Connected Lighting Systems: requirements, challenges and recommendations"
- L.Zappatera和E.Dijk，“无线连接照明系统的软件更新：要求、挑战和建议”
- M. Orehek and A. Zugenmaier, "Updates in IoT are more than just one iota"
- M.Orehek和A.Zugenmaier，“物联网中的更新不仅仅是一个物联网”
- D. Plonka and E. Boschi, "The Internet of Things Old and Unmanaged"
- D.Plonka和E.Boschi，“旧的、未管理的物联网”
- D. Bosschaert, "Using OSGi for an extensible, updatable and future proof IoT"
- D.Bosschaert，“将OSGi用于可扩展、可更新和经得起未来考验的物联网”
- A. Padilla, E. Baccelli, T. Eichinger, and K. Schleiser, "The Future of IoT Software Must be Updated"
- A.Padilla、E.Baccelli、T.Eichinger和K.Schleiser，“物联网软件的未来必须更新”
- T. Hardie, "Software Update in a multi-system Internet of Things"
- T.Hardie，“多系统物联网中的软件更新”
- R. Sparks and B. Campbell, "Avoiding the Obsolete-Thing Event Horizon"
- R.Sparks和B.Campbell，“避免过时的事件视界”
- J. Karkov, "SW update for Long lived products"
- J.Karkov，“长寿命产品的软件更新”
- S. Farrell, "Some Software Update Requirements"
- S.Farrell，“一些软件更新要求”
- S. Chakrabarti, "Internet Of Things Software Update Challenges: Ownership, Software Security & Services"
- S.Chakrabarti，“物联网软件更新挑战：所有权、软件安全和服务”
- M. Kovatsch, A. Scholz, and J. Hund, "Why Software Updates Are More Than a Security Issue: Challenges for IETF CoRE and the W3C Web of Things"
- M.Kovatsch、A.Scholz和J.Hund，“为什么软件更新不仅仅是一个安全问题：IETF核心和W3C物联网面临的挑战”
- A. Grau, "Secure Software Updates for IoT Devices"
- A.Grau，“物联网设备的安全软件更新”
- Birr-Pixton, "Electric Imp's experiences of upgrading half a million embedded devices"
- Birr Pixton，“Electric Imp升级50万台嵌入式设备的经验”
- Y. Zhang, J. Yin, C. Groves, and M. Patel, "oneM2M device management and software/firmware update"
- 张勇，尹俊杰，C.格罗夫斯和M.帕特尔，“oneM2M设备管理和软件/固件更新”
- E. Smith, M. Stitt, R. Ensink, and K. Jager, "User Experience (UX) Centric IoT Software Update"
- E.Smith、M.Stitt、R.Ensink和K.Jager，“以用户体验（UX）为中心的物联网软件更新”
- J.-P. Fassino, E.A. Moktad, and J.-M. Brun, "Secure Firmware Update in Schneider Electric IOT-enabled offers"
- J.-P.Fassino、E.A.Moktad和J.-M.Brun，“施耐德电气物联网支持产品中的安全固件更新”
- M. Orehek, "Summary of existing firmware update strategies for deeply embedded systems"
- M.Orehk，“深度嵌入式系统现有固件更新策略总结”
- N. Smith, "Toward A Common Modeling Standard for Software Update and IoT Objects"
- N.Smith，“迈向软件更新和物联网对象的通用建模标准”
- S. Schmidt, M. Tausig, M. Hudler, and G. Simhandl, "Secure Firmware Update Over the Air in the Internet of Things Focusing on Flexibility and Feasibility"
- S.Schmidt、M.Tausig、M.Hudler和G.Simhandl，“物联网空中安全固件更新注重灵活性和可行性”
- A. Adomnicai, J. Fournier, L. Masson, and A. Tria, "How careful should we be when implementing cryptography for software update mechanisms in the IoT?"
- A.Adomnicai、J.Fournier、L.Masson和A.Tria，“在物联网中为软件更新机制实施加密时，我们应该多小心？”
- V. Prevelakis and H. Hamad, "Controlling Change via Policy Contracts"
- V.Prevelakis和H.Hamad，“通过政策合同控制变化”
- H. Birkholz, N. Cam-Winget, and C. Bormann, "IoT Software Updates need Security Automation"
- H.Birkholz，N.Cam Winget和C.Bormann，“物联网软件更新需要安全自动化”
- R. Bisewski, "Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of Things"
- R.Bisewski，“分布式存储库更新方法的比较分析，以及类似CoAP的更新方法如何缓解构成物联网的设备的互联网压力”
- J. Arrko, "Architectural Considerations with Smart Objects and Software Updates"
- J.Arrko，“智能对象和软件更新的架构考虑”
- J. Jimenez and M. Ocak, "Software Update Experiences for IoT"
- J.Jimenez和M.Ocak，“物联网的软件更新体验”
- H. Tschofenig, "Software and Firmware Updates with the OMA LWM2M Protocol"
- H.Tschofenig，“OMA LWM2M协议的软件和固件更新”
- Arnar Birgisson, Google
- 阿纳尔·比吉斯森，谷歌
- Alan Grau, IconLabs
- 艾伦·格劳，我是伊康拉布
- Alexandre Adomnicai, Trusted Objects
- Alexandre Adomnicai，受信任对象
- Alf Zugenmaier, Munich University of Applied Science
- Alf Zugenmaier，慕尼黑应用科学大学
- Ben Campbell, Oracle
- 本·坎贝尔，甲骨文
- Carsten Bormann, TZI University Bremen
- Carsten Bormann，不来梅TZI大学
- Daniel Thomas, University of Cambridge
- 丹尼尔·托马斯，剑桥大学
- David Bosschaert, Adobe
- 大卫·博斯切特，Adobe
- David Malone, Maynooth University
- 大卫·马龙，梅努斯大学
- David Plonka, Akamai
- David Plonka，Akamai
- Doug Leith, Trinity College Dublin
- 都柏林三一学院Doug Leith
- Emmanuel Baccelli, Inria
- 伊曼纽尔·巴切利，因里亚
- Eric Smith, SpinDance
- 埃里克·史密斯，自旋舞
- Jean-Philippe Fassino, Schneider Electric
- 施耐德电气公司Jean-Philippe Fassino
- Joergen Karkov, Grundfos
- 杰尔根·卡尔科夫，格兰富
- Jonathon Dukes, Trinity College Dublin
- 乔纳森·杜克斯，都柏林三一学院
- Joseph Birr-Pixton, Electric Imp
- 约瑟夫·比尔·皮克斯顿，电子小鬼
- Kaspar Schleiser, Freie Universitaet Berlin
- Kaspar Schleiser，柏林弗雷大学
- Luca Zappaterra, Philips Lighting Research
- Luca Zappatera，飞利浦照明研究公司
- Martin Orehek, Munich University of Applied Science
- Martin Orehek，慕尼黑应用科学大学
- Mathias Tausig, FH Campus Wien
- Mathias Tausig，佛罗里达大学维也纳校区
- Matthias Kovatsch, Siemens
- Matthias Kovatsch，西门子
- Milan Patel, Huawei
- 米兰帕特尔，华为
- Ned Smith, Intel
- 内德·史密斯，英特尔公司
- Robert Ensink, SpinDance
- 罗伯特·恩辛克，自旋舞
- Robert Sparks, Oracle
- 罗伯特·斯帕克斯，甲骨文
- Russ Housley, Vigil Security
- Russ Housley，守夜保安
- Samita Chakrabarti, Ericsson
- Samita Chakrabarti，爱立信
- Stephen Farrell, Trinity College Dublin
- 斯蒂芬·法雷尔，都柏林三一学院
- Vassilis Prevelakis, TU Braunschweig
- 瓦西里斯·普雷维拉基斯，图布伦瑞克
- Hannes Tschofenig, ARM Ltd.
- 汉内斯·茨霍芬尼，ARM有限公司。
Acknowledgements
致谢
We would like to thank all paper authors and participants for their contributions. The IoTSU workshop is co-sponsored by the Internet Architecture Board and the Science Foundation Ireland funded CONNECT Centre for future networks and communications. The program committee would like to express their thanks to Comcast for sponsoring the social event.
我们要感谢所有论文作者和参与者的贡献。IOTSU研讨会是由互联网架构委员会和科学基金会为未来的网络和通信提供的Connect Connect中心共同赞助的。节目委员会感谢康卡斯特赞助此次社交活动。
Authors' Addresses
作者地址
Hannes Tschofenig ARM Limited
汉内斯特绍菲尼集团有限公司
Email: hannes.tschofenig@gmx.net
Email: hannes.tschofenig@gmx.net
Stephen Farrell Trinity College Dublin Dublin 2 Ireland
斯蒂芬·法雷尔三一学院都柏林爱尔兰都柏林2
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie