Internet Research Task Force (IRTF) O. Garcia-Morchon
Request for Comments: 8576 Philips
Category: Informational S. Kumar
ISSN: 2070-1721 Signify
M. Sethi
Ericsson
April 2019
Internet Research Task Force (IRTF) O. Garcia-Morchon
Request for Comments: 8576 Philips
Category: Informational S. Kumar
ISSN: 2070-1721 Signify
M. Sethi
Ericsson
April 2019
Internet of Things (IoT) Security: State of the Art and Challenges
物联网安全：现状与挑战
Abstract
摘要
The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
物联网（IoT）的概念是指使用标准的互联网协议来实现人与物之间和物与物之间的通信。物联网系统的安全需求已得到充分认可，并已采取许多标准化步骤来提供安全性——例如，使用数据报传输层安全性（DTLS）保护的受限应用协议（CoAP）规范。然而，安全挑战仍然存在，这不仅是因为有些用例缺乏合适的解决方案，而且还因为许多物联网设备和系统的设计和部署的安全能力非常有限。在本文档中，我们首先讨论事物生命周期中的各个阶段。接下来，我们将记录对某事物的安全威胁，以及在防范这些威胁时可能面临的挑战。最后，我们讨论了促进安全物联网系统部署所需的后续步骤。本文件可供物联网规范的实施者和作者参考，以获取有关安全注意事项的详细信息，同时记录其特定的安全挑战、威胁模型和缓解措施。
This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).
本文件是IRTF物对物研究小组（T2TRG）的产品。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。IRSG批准发布的文件不适用于任何级别的互联网标准；见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/rfc8576.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8576.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . . . 5
3. Security Threats and Managing Risk . . . . . . . . . . . . . 8
4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 13
4.1. IP-Based IoT Protocols and Standards . . . . . . . . . . 13
4.2. Existing IP-Based Security Protocols and Solutions . . . 16
4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 18
5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 21
5.1. Constraints and Heterogeneous Communication . . . . . . . 21
5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 21
5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 22
5.1.3. End-to-End Security, Protocol Translation, and the
Role of Middleboxes . . . . . . . . . . . . . . . . . 23
5.1.4. New Network Architectures and Paradigm . . . . . . . 25
5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 25
5.3. Operational Challenges . . . . . . . . . . . . . . . . . 25
5.3.1. Group Membership and Security . . . . . . . . . . . . 26
5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 27
5.4. Secure Software Update and Cryptographic Agility . . . . 27
5.5. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Verifying Device Behavior . . . . . . . . . . . . . . . . 30
5.7. Testing: Bug Hunting and Vulnerabilities . . . . . . . . 31
5.8. Quantum-Resistance . . . . . . . . . . . . . . . . . . . 32
5.9. Privacy Protection . . . . . . . . . . . . . . . . . . . 33
5.10. Reverse-Engineering Considerations . . . . . . . . . . . 34
5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 35
6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Informative References . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . . . 5
3. Security Threats and Managing Risk . . . . . . . . . . . . . 8
4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 13
4.1. IP-Based IoT Protocols and Standards . . . . . . . . . . 13
4.2. Existing IP-Based Security Protocols and Solutions . . . 16
4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 18
5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 21
5.1. Constraints and Heterogeneous Communication . . . . . . . 21
5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 21
5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 22
5.1.3. End-to-End Security, Protocol Translation, and the
Role of Middleboxes . . . . . . . . . . . . . . . . . 23
5.1.4. New Network Architectures and Paradigm . . . . . . . 25
5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 25
5.3. Operational Challenges . . . . . . . . . . . . . . . . . 25
5.3.1. Group Membership and Security . . . . . . . . . . . . 26
5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 27
5.4. Secure Software Update and Cryptographic Agility . . . . 27
5.5. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Verifying Device Behavior . . . . . . . . . . . . . . . . 30
5.7. Testing: Bug Hunting and Vulnerabilities . . . . . . . . 31
5.8. Quantum-Resistance . . . . . . . . . . . . . . . . . . . 32
5.9. Privacy Protection . . . . . . . . . . . . . . . . . . . 33
5.10. Reverse-Engineering Considerations . . . . . . . . . . . 34
5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 35
6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Informative References . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
The Internet of Things (IoT) denotes the interconnection of highly heterogeneous networked entities and networks that follow a number of different communication patterns, such as: human-to-human (H2H), human-to-thing (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term "IoT" was first coined in 1999 by the Auto-ID center [AUTO-ID], which had envisioned a world where every physical object has a radio-frequency identification (RFID) tag with a globally unique identifier. This would not only allow tracking of objects in real time but also allow querying of data about them over the Internet. However, since then, the meaning of the Internet of Things has expanded and now encompasses a wide variety of technologies, objects, and protocols. It is not surprising that the IoT has received significant attention from the research community to (re)design, apply, and use standard Internet technology and protocols for the IoT.
物联网（IoT）表示高度异构的网络实体和网络之间的互连，这些实体和网络遵循多种不同的通信模式，例如：人对人（H2H）、人对物（H2T）、物对物（T2T）或物对物（T2T）。“物联网”一词最早于1999年由Auto-ID中心（Auto-ID）提出，该中心设想了一个世界，在这个世界中，每个物理对象都有一个具有全球唯一标识符的射频识别（RFID）标签。这不仅允许实时跟踪对象，还允许通过Internet查询有关对象的数据。然而，从那时起，物联网的含义已经扩展，现在包括了各种各样的技术、对象和协议。毫不奇怪，物联网已受到研究界的高度重视，需要（重新）设计、应用和使用物联网的标准互联网技术和协议。
The things that are part of the Internet of Things are computing devices that understand and react to the environment they reside in. These things are also often referred to as smart objects or smart devices. The introduction of IPv6 [RFC6568] and CoAP [RFC7252] as fundamental building blocks for IoT applications allows connecting IoT hosts to the Internet. This brings several advantages, including: (i) a homogeneous protocol ecosystem that allows simple integration with other Internet hosts; (ii) simplified development for devices that significantly vary in their capabilities; (iii) a unified interface for applications, removing the need for application-level proxies. These building blocks greatly simplify the deployment of the envisioned scenarios, which range from building automation to production environments and personal area networks.
物联网的一部分是能够理解并对其所处环境做出反应的计算设备。这些东西通常也被称为智能对象或智能设备。IPv6[RFC6568]和CoAP[RFC7252]作为物联网应用的基本构建块的引入允许将物联网主机连接到互联网。这带来了几个优势，包括：（i）同构协议生态系统，允许与其他互联网主机简单集成；（ii）简化设备的开发，这些设备的性能差异很大；（iii）应用程序的统一接口，无需应用程序级代理。这些构建块极大地简化了设想场景的部署，包括从楼宇自动化到生产环境和个人局域网。
This document presents an overview of important security aspects for the Internet of Things. We begin by discussing the lifecycle of a thing in Section 2. In Section 3, we discuss security threats for the IoT and methodologies for managing these threats when designing a secure system. Section 4 reviews existing IP-based (security) protocols for the IoT and briefly summarizes existing guidelines and regulations. Section 5 identifies remaining challenges for a secure IoT and discusses potential solutions. Section 6 includes final remarks and conclusions. This document can be used by IoT standards specifications as a reference for details about security considerations that apply to the specified system or protocol.
本文档概述了物联网的重要安全方面。在第2节中，我们首先讨论事物的生命周期。在第3节中，我们将讨论物联网的安全威胁以及在设计安全系统时管理这些威胁的方法。第4节回顾了现有的基于IP的物联网（安全）协议，并简要总结了现有的指南和法规。第5节确定了安全物联网的剩余挑战，并讨论了潜在的解决方案。第6节包括最后的评论和结论。IoT标准规范可将本文件用作适用于指定系统或协议的安全注意事项详情的参考。
The first draft version of this document was submitted in March 2011. Initial draft versions of this document were presented and discussed during the meetings of the Constrained RESTful Environments (CORE) Working Group at IETF 80 and later. Discussions on security
本文件的初稿于2011年3月提交。在IETF 80及更高版本的受限RESTful环境（CORE）工作组会议上，本文件的初稿被介绍和讨论。关于安全的讨论
lifecycle at IETF 92 (March 2015) evolved into more general security considerations. Thus, the draft was selected to address the T2TRG work item on the security considerations and challenges for the Internet of Things. Further updates of the draft were presented and discussed during the T2TRG meetings at IETF 96 (July 2016) and IETF 97 (November 2016) and at the joint interim meeting in Amsterdam (March 2017). This document has been reviewed by, commented on, and discussed extensively for a period of nearly six years by a vast majority of the T2TRG and related group members, the number of which certainly exceeds 100 individuals. It is the consensus of T2TRG that the security considerations described in this document should be published in the IRTF Stream of the RFC series. This document does not constitute a standard.
IETF 92（2015年3月）的生命周期演变为更一般的安全考虑。因此，草案被选为解决T2TRG关于物联网安全考虑和挑战的工作项目。在IETF 96（2016年7月）和IETF 97（2016年11月）以及阿姆斯特丹联合临时会议（2017年3月）的T2TRG会议上，提交并讨论了草案的进一步更新。在近六年的时间里，绝大多数T2TRG和相关小组成员对本文件进行了审查、评论和广泛讨论，其中肯定有超过100人。T2TRG一致认为，本文件中描述的安全注意事项应发布在RFC系列的IRTF流中。本文件不构成标准。
The lifecycle of a thing refers to the operational phases of a thing in the context of a given application or use case. Figure 1 shows the generic phases of the lifecycle of a thing. This generic lifecycle is applicable to very different IoT applications and scenarios. For instance, [RFC7744] provides an overview of relevant IoT use cases.
事物的生命周期是指在给定应用程序或用例的上下文中事物的操作阶段。图1显示了事物生命周期的一般阶段。此通用生命周期适用于非常不同的物联网应用程序和场景。例如，[RFC7744]提供了相关物联网用例的概述。
In this document, we consider a Building Automation and Control (BAC) system to illustrate the lifecycle and the meaning of these different phases. A BAC system consists of a network of interconnected nodes that performs various functions in the domains of Heating, Ventilating, and Air Conditioning (HVAC), lighting, safety, etc. The nodes vary in functionality, and a large majority of them represent resource-constrained devices such as sensors and luminaries. Some devices may be battery operated or may rely on energy harvesting. This requires us to also consider devices that sleep during their operation to save energy. In our BAC scenario, the life of a thing starts when it is manufactured. Due to the different application areas (i.e., HVAC, lighting, or safety), nodes/things are tailored to a specific task. It is therefore unlikely that one single manufacturer will create all nodes in a building. Hence, interoperability as well as trust bootstrapping between nodes of different vendors is important.
在本文中，我们考虑了建筑自动化和控制（BAC）系统来说明这些不同阶段的生命周期和意义。BAC系统由一个互连节点网络组成，这些节点在供暖、通风和空调（HVAC）、照明、安全等领域执行各种功能。这些节点的功能各不相同，其中大部分表示资源受限的设备，如传感器和灯具。一些设备可能是电池驱动的，或者可能依赖于能量收集。这就要求我们也要考虑在操作过程中睡眠以节省能量的设备。在我们的BAC场景中，一件东西的生命从它被制造时开始。由于不同的应用领域（即暖通空调、照明或安全），节点/事物可根据特定任务进行定制。因此，单个制造商不太可能创建建筑中的所有节点。因此，不同供应商的节点之间的互操作性以及信任引导非常重要。
The thing is later installed and commissioned within a network by an installer during the bootstrapping phase. Specifically, the device identity and the secret keys used during normal operation may be provided to the device during this phase. Different subcontractors may install different IoT devices for different purposes. Furthermore, the installation and bootstrapping procedures may not be a discrete event and may stretch over an extended period. After being bootstrapped, the device and the system of things are in
在引导阶段，安装程序随后会在网络中安装并调试该设备。具体地，在该阶段期间，可以向设备提供在正常操作期间使用的设备标识和密钥。不同的分包商可为不同的目的安装不同的物联网设备。此外，安装和引导过程可能不是一个离散事件，可能会延长时间。自举后，设备和系统的东西都处于启动状态
operational mode and execute the functions of the BAC system. During this operational phase, the device is under the control of the system owner and used by multiple system users. For devices with lifetimes spanning several years, occasional maintenance cycles may be required. During each maintenance phase, the software on the device can be upgraded, or applications running on the device can be reconfigured. The maintenance tasks can be performed either locally or from a backend system. Depending on the operational changes to the device, it may be required to rebootstrap at the end of a maintenance cycle. The device continues to loop through the operational phase and the eventual maintenance phases until the device is decommissioned at the end of its lifecycle. However, the end-of-life of a device does not necessarily mean that it is defective; rather, it denotes a need to replace and upgrade the network to next-generation devices for additional functionality. Therefore, the device can be removed and recommissioned to be used in a different system under a different owner, thereby starting the lifecycle all over again.
操作模式并执行BAC系统的功能。在此操作阶段，设备由系统所有者控制，并由多个系统用户使用。对于寿命跨越数年的设备，可能需要偶尔进行维护周期。在每个维护阶段，可以升级设备上的软件，或者重新配置设备上运行的应用程序。维护任务可以在本地执行，也可以从后端系统执行。根据设备的操作变化，可能需要在维护周期结束时重新引导。设备将继续循环运行阶段和最终维护阶段，直到设备在其生命周期结束时退役。然而，设备的寿命终止并不一定意味着它有缺陷；相反，它表示需要更换网络并将其升级到下一代设备以获得更多功能。因此，可以移除设备并重新调试，以便在不同所有者的不同系统中使用，从而重新开始生命周期。
We note that the presented lifecycle represents to some extent a simplified model. For instance, it is possible to argue that the lifecycle does not start when a tangible device is manufactured but rather when the oldest bit of code that ends up in the device -- maybe from an open-source project or the operating system -- was written. Similarly, the lifecycle could also include an on-the-shelf phase where the device is in the supply chain before an owner/user purchases and installs it. Another phase could involve the device being rebadged by some vendor who is not the original manufacturer. Such phases can significantly complicate other phases such as maintenance and bootstrapping. Finally, other potential end states can be, e.g., a vendor that no longer supports a device type because it is at the end of its life or a situation in which a device is simply forgotten but remains functional.
我们注意到，呈现的生命周期在某种程度上代表了一个简化的模型。例如，有人可能认为，生命周期并非始于有形设备的制造，而是始于设备中最古老的代码（可能来自开源项目或操作系统）的编写。类似地，生命周期还可以包括一个现货阶段，在该阶段中，设备在所有者/用户购买和安装之前处于供应链中。另一个阶段可能涉及由非原始制造商的供应商重新标记设备。这些阶段可能会使其他阶段（如维护和引导）变得非常复杂。最后，其他潜在的终端状态可以是，例如，由于某一设备类型已处于使用寿命的末期，或者某一设备已被遗忘但仍能正常工作，因此不再支持该设备类型的供应商。
_Manufactured _SW update _Decommissioned
/ / /
| _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced
| | _Commissioned | | | |
| | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | |
| | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>>
\/ \______________/ \/ \_____________/ \___/ time //
/ / \ \ \
Bootstrapping / Maintenance & \ Maintenance &
/ rebootstrapping \ rebootstrapping
Operational Operational
_Manufactured _SW update _Decommissioned
/ / /
| _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced
| | _Commissioned | | | |
| | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | |
| | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>>
\/ \______________/ \/ \_____________/ \___/ time //
/ / \ \ \
Bootstrapping / Maintenance & \ Maintenance &
/ rebootstrapping \ rebootstrapping
Operational Operational
Figure 1: The Lifecycle of a Thing in the Internet of Things
图1：物联网中事物的生命周期
Security is a key requirement in any communication system. However, security is an even more critical requirement in real-world IoT deployments for several reasons. First, compromised IoT systems can not only endanger the privacy and security of a user but can also cause physical harm. This is because IoT systems often comprise sensors, actuators, and other connected devices in the physical environment of the user that could adversely affect the user if they are compromised. Second, a vulnerable IoT system means that an attacker can alter the functionality of a device from a given manufacturer. This not only affects the manufacturer's brand image but can also leak information that is very valuable for the manufacturer (such as proprietary algorithms). Third, the impact of attacking an IoT system goes beyond a specific device or an isolated system, since compromised IoT systems can be misused at scale. For example, they may be used to perform a Distributed Denial of Service (DDoS) attack that limits the availability of other networks and services. The fact that many IoT systems rely on standard IP protocols allows for easier system integration, but this also makes attacks on standard IP protocols widely applicable in other environments. This results in new requirements regarding the implementation of security.
安全性是任何通信系统的关键要求。然而，出于几个原因，安全性在实际物联网部署中是一个更为关键的要求。首先，被破坏的物联网系统不仅会危及用户的隐私和安全，还会造成人身伤害。这是因为物联网系统通常包括用户物理环境中的传感器、执行器和其他连接设备，如果这些设备受损，可能会对用户产生不利影响。其次，易受攻击的物联网系统意味着攻击者可以改变给定制造商的设备功能。这不仅会影响制造商的品牌形象，还会泄露对制造商非常有价值的信息（如专有算法）。第三，攻击物联网系统的影响超出了特定设备或孤立系统的范围，因为受损的物联网系统可能被大规模滥用。例如，它们可能用于执行分布式拒绝服务（DDoS）攻击，从而限制其他网络和服务的可用性。许多物联网系统依赖于标准IP协议这一事实使得系统集成更加容易，但这也使得对标准IP协议的攻击广泛适用于其他环境。这就产生了有关安全实施的新要求。
The term "security" subsumes a wide range of primitives, protocols, and procedures. For instance, it includes services such as confidentiality, authentication, integrity, authorization, source authentication, and availability. It often also includes augmented services such as duplicate detection and detection of stale packets (timeliness). These security services can be implemented through a combination of cryptographic mechanisms such as block ciphers, hash functions, and signature algorithms, as well as noncryptographic
术语“安全性”包含了广泛的原语、协议和过程。例如，它包括保密性、身份验证、完整性、授权、源身份验证和可用性等服务。它通常还包括增强服务，如重复检测和陈旧数据包检测（及时性）。这些安全服务可以通过密码机制（如分组密码、哈希函数和签名算法）以及非密码机制的组合来实现
mechanisms that implement authorization and other aspects of security-policy enforcement. For ensuring security in IoT networks, one should not only focus on the required security services but also pay special attention to how the services are realized in the overall system.
实现授权和安全策略实施的其他方面的机制。为了确保物联网网络的安全，人们不仅应关注所需的安全服务，还应特别关注服务在整个系统中的实现方式。
Security threats in related IP protocols have been analyzed in multiple documents, including Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained Application Protocol (CoAP) [RFC7252], IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6 Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying Authentication and Network Access (PANA) [RFC4016]. In this section, we specifically discuss the threats that could compromise an individual thing or the network as a whole. Some of these threats might go beyond the scope of Internet protocols, but we gather them here for the sake of completeness. The threats in the following list are not in any particular order, and some threats might be more critical than others, depending on the deployment scenario under consideration:
相关IP协议中的安全威胁已在多份文件中进行了分析，包括传输层安全（TLS）（HTTPS）上的超文本传输协议（HTTP）[RFC2818]、受限应用协议（CoAP）[RFC7252]、低功率无线个人区域网（6LoWPAN）上的IPv6）[RFC4919]、访问节点控制协议（ANCP）[RFC5713]、域名系统（DNS）[RFC3833]、IPv6邻居发现（ND）[RFC3756]和承载身份验证和网络访问的协议（PANA）[RFC4016]。在本节中，我们专门讨论可能危害单个事物或整个网络的威胁。其中一些威胁可能超出Internet协议的范围，但为了完整性起见，我们将其收集在这里。以下列表中的威胁没有任何特定的顺序，有些威胁可能更严重itical比其他产品更具吸引力，具体取决于所考虑的部署场景：
1. Vulnerable software/code: Things in the Internet of Things rely on software that might contain severe bugs and/or bad design choices. This makes the things vulnerable to many different types of attacks, depending on the criticality of the bugs, e.g., buffer overflows or lack of authentication. This can be considered one of the most important security threats. The large-scale Distributed Denial of Service (DDoS) attack, popularly known as the Mirai botnet [Mirai], was caused by things that had well-known or easy-to-guess passwords for configuration.
1. 易受攻击的软件/代码：物联网中的东西依赖于可能包含严重错误和/或错误设计选择的软件。这使得这些东西容易受到许多不同类型的攻击，这取决于bug的严重程度，例如缓冲区溢出或缺少身份验证。这可以被认为是最重要的安全威胁之一。大规模分布式拒绝服务（DDoS）攻击，俗称Mirai僵尸网络[Mirai]，是由具有众所周知或易于猜测的配置密码的东西引起的。
2. Privacy threat: The tracking of a thing's location and usage may pose a privacy risk to people around it. For instance, an attacker can infer privacy-sensitive information from the data gathered and communicated by individual things. Such information may subsequently be sold to interested parties for marketing purposes and targeted advertising. In extreme cases, such information might be used to track dissidents in oppressive regimes. Unlawful surveillance and interception of traffic to/ from a thing by intelligence agencies is also a privacy threat.
2. 隐私威胁：跟踪物品的位置和使用情况可能会对周围的人构成隐私风险。例如，攻击者可以从个人收集和交流的数据中推断出隐私敏感信息。此类信息随后可能会出售给相关方，用于营销目的和定向广告。在极端情况下，这些信息可能被用来追踪压迫政权中的持不同政见者。情报机构非法监视和拦截进出物品的交通也是一种隐私威胁。
3. Cloning of things: During the manufacturing process of a thing, an untrusted factory can easily clone the physical characteristics, firmware/software, or security configuration of
3. 物品克隆：在物品制造过程中，不受信任的工厂可以轻松克隆物品的物理特性、固件/软件或安全配置
the thing. Deployed things might also be compromised and their software reverse engineered, allowing for cloning or software modifications. Such a cloned thing may be sold at a cheaper price in the market and yet can function normally as a genuine thing. For example, two cloned devices can still be associated and work with each other. In the worst-case scenario, a cloned device can be used to control a genuine device or perform an attack. One should note here that an untrusted factory may also change functionality of the cloned thing, resulting in degraded functionality with respect to the genuine thing (thereby inflicting potential damage to the reputation of the original thing manufacturer). Moreover, additional functionality can be introduced in the cloned thing. An example of such functionality is a backdoor.
这件事。部署的东西也可能被破坏，它们的软件可能被反向工程，从而允许克隆或软件修改。这种克隆的东西在市场上可能以更便宜的价格出售，但却可以作为真正的东西正常工作。例如，两个克隆设备仍然可以相互关联并协同工作。在最坏的情况下，克隆设备可用于控制真实设备或执行攻击。这里需要注意的是，不受信任的工厂也可能会改变克隆产品的功能，导致与真实产品相关的功能降级（从而对原始产品制造商的声誉造成潜在损害）。此外，还可以在克隆对象中引入其他功能。此类功能的一个示例是后门。
4. Malicious substitution of things: During the installation of a thing, a genuine thing may be replaced by a similar variant (of lower quality) without being detected. The main motivation may be cost savings, where the installation of lower-quality things (for example, noncertified products) may significantly reduce the installation and operational costs. The installers can subsequently resell the genuine things to gain further financial benefits. Another motivation may be to inflict damage to the reputation of a competitor's offerings.
4. 恶意替换物品：在安装物品的过程中，真实物品可能会被类似的变体（质量较低）替换，而不会被检测到。主要动机可能是节约成本，安装质量较低的产品（例如，未经认证的产品）可以显著降低安装和运营成本。安装者随后可以转售正品，以获得进一步的经济利益。另一个动机可能是损害竞争对手产品的声誉。
5. Eavesdropping attack: During the commissioning of a thing into a network, it may be susceptible to eavesdropping, especially if operational keying materials, security parameters, or configuration settings are exchanged in the clear using a wireless medium or if used cryptographic algorithms are not suitable for the envisioned lifetime of the device and the system. After obtaining the keying material, the attacker might be able to recover the secret keys established between the communicating entities, thereby compromising the authenticity and confidentiality of the communication channel, as well as the authenticity of commands and other traffic exchanged over this communication channel. When the network is in operation, T2T communication can be eavesdropped if the communication channel is not sufficiently protected or if a session key is compromised due to protocol weaknesses. An adversary may also be able to eavesdrop if keys are not renewed or updated appropriately. Lastly, messages can also be recorded and decrypted offline at a later point of time. The VENONA project [venona-project] is one such example where messages were recorded for offline decryption.
5. 窃听攻击：在将一件东西投入网络的过程中，它可能容易被窃听，特别是在操作密钥材料、安全参数、，或者使用无线介质以明文形式交换配置设置，或者如果使用的加密算法不适合设备和系统的预期寿命。在获得密钥材料后，攻击者可能能够恢复通信实体之间建立的密钥，从而损害通信信道的真实性和机密性，以及通过该通信信道交换的命令和其他通信的真实性。当网络处于运行状态时，如果通信信道没有得到充分的保护，或者如果会话密钥由于协议缺陷而被泄露，则可以窃听T2T通信。如果密钥没有适当更新或更新，敌方也可以窃听。最后，消息也可以在以后离线记录和解密。VENONA项目[VENONA project]就是这样一个例子，其中记录了用于脱机解密的消息。
6. Man-in-the-middle attack: Both the commissioning and operational phases may be vulnerable to man-in-the-middle attacks. For example, when keying material between communicating entities is exchanged in the clear, the security of the key establishment protocol depends on the tacit assumption that no third party can eavesdrop during the execution of this protocol. Additionally, device authentication or device authorization may be nontrivial or need the support of a human decision process, since things usually do not have a priori knowledge about each other and cannot always differentiate friends and foes via completely automated mechanisms.
6. 中间人攻击：调试和运行阶段都可能容易受到中间人攻击。例如，当通信实体之间的密钥材料在clear中交换时，密钥建立协议的安全性取决于默契假设，即在该协议的执行期间没有第三方可以窃听。此外，设备身份验证或设备授权可能不重要，或者需要人工决策过程的支持，因为事物通常彼此之间没有先验知识，并且不能通过完全自动化的机制始终区分朋友和敌人。
7. Firmware attacks: When a thing is in operation or maintenance phase, its firmware or software may be updated to allow for new functionality or new features. An attacker may be able to exploit such a firmware upgrade by maliciously replacing the thing's firmware, thereby influencing its operational behavior. For example, an attacker could add a piece of malicious code to the firmware that will cause it to periodically report the energy usage of the thing to a data repository for analysis. The attacker can then use this information to determine when a home or enterprise (where the thing is installed) is unoccupied and break in. Similarly, devices whose software has not been properly maintained and updated might contain vulnerabilities that might be exploited by attackers to replace the firmware on the device.
7. 固件攻击：当一件东西处于操作或维护阶段时，它的固件或软件可能会更新以允许新功能或新特性。攻击者可以通过恶意更换固件来利用此类固件升级，从而影响其操作行为。例如，攻击者可以向固件添加一段恶意代码，使其定期向数据存储库报告该设备的能源使用情况以进行分析。然后，攻击者可以使用此信息确定某个家庭或企业（安装该设备的地方）何时未被占用并闯入。类似地，软件未正确维护和更新的设备可能包含漏洞，攻击者可能会利用这些漏洞替换设备上的固件。
8. Extraction of private information: IoT devices (such as sensors, actuators, etc.) are often physically unprotected in their ambient environment, and they could easily be captured by an attacker. An attacker with physical access may then attempt to extract private information such as keys (for example, a group key or the device's private key), data from sensors (for example, healthcare status of a user), configuration parameters (for example, the Wi-Fi key), or proprietary algorithms (for example, the algorithm performing some data analytics task). Even when the data originating from a thing is encrypted, attackers can perform traffic analysis to deduce meaningful information, which might compromise the privacy of the thing's owner and/or user.
8. 私人信息提取：物联网设备（如传感器、执行器等）在其周围环境中通常没有物理保护，很容易被攻击者捕获。然后，具有物理访问权限的攻击者可能会试图提取私人信息，如密钥（例如，组密钥或设备的私钥）、传感器数据（例如，用户的医疗状态）、配置参数（例如，Wi-Fi密钥）或专有算法（例如，执行某些数据分析任务的算法）。即使源于某事物的数据被加密，攻击者也可以执行流量分析以推断有意义的信息，这可能会损害该事物所有者和/或用户的隐私。
9. Routing attack: As highlighted in [Daniel], routing information in IoT networks can be spoofed, altered, or replayed, in order to create routing loops, attract/repel network traffic, extend/ shorten source routes, etc. A nonexhaustive list of routing attacks includes:
9. 路由攻击：如[Daniel]所述，物联网网络中的路由信息可以被欺骗、篡改或重播，以创建路由环路、吸引/排斥网络流量、扩展/缩短源路由等。路由攻击的非详尽列表包括：
a. Sinkhole attack (or blackhole attack), where an attacker declares himself to have a high-quality route/path to the base station, thus allowing him to do manipulate all packets passing through it.
a. 天坑攻击（或黑洞攻击），攻击者声称自己拥有到基站的高质量路由/路径，从而允许他操纵通过它的所有数据包。
b. Selective forwarding, where an attacker may selectively forward packets or simply drop a packet.
b. 选择性转发，攻击者可以选择性转发数据包或简单地丢弃数据包。
c. Wormhole attack, where an attacker may record packets at one location in the network and tunnel them to another location, thereby influencing perceived network behavior and potentially distorting statistics, thus greatly impacting the functionality of routing.
c. 虫洞攻击，攻击者可以在网络中的一个位置记录数据包，并将数据包通过隧道传输到另一个位置，从而影响感知的网络行为并可能扭曲统计数据，从而极大地影响路由功能。
d. Sybil attack, whereby an attacker presents multiple identities to other things in the network. We refer to [Daniel] for further router attacks and a more detailed description.
d. Sybil攻击，即攻击者向网络中的其他对象显示多个身份。我们参考[Daniel]了解更多路由器攻击和更详细的描述。
10. Elevation of privilege: An attacker with low privileges can misuse additional flaws in the implemented authentication and authorization mechanisms of a thing to gain more privileged access to the thing and its data.
10. 特权提升：具有较低权限的攻击者可以滥用已实现的身份验证和授权机制中的其他缺陷，以获得对该对象及其数据的更高权限访问。
11. Denial of Service (DoS) attack: Often things have very limited memory and computation capabilities. Therefore, they are vulnerable to resource-exhaustion attack. Attackers can continuously send requests to specific things so as to deplete their resources. This is especially dangerous in the Internet of Things since an attacker might be located in the backend and target resource-constrained devices that are part of a constrained-node network [RFC7228]. A DoS attack can also be launched by physically jamming the communication channel. Network availability can also be disrupted by flooding the network with a large number of packets. On the other hand, things compromised by attackers can be used to disrupt the operation of other networks or systems by means of a Distributed DoS (DDoS) attack.
11. 拒绝服务（DoS）攻击：通常情况下，内存和计算能力非常有限。因此，它们容易受到资源耗尽攻击。攻击者可以连续向特定对象发送请求，以耗尽其资源。这在物联网中尤其危险，因为攻击者可能位于后端和目标资源受限设备中，这些设备是受限节点网络的一部分[RFC7228]。DoS攻击也可以通过物理干扰通信信道来发起。网络可用性也可能因大量数据包充斥网络而中断。另一方面，攻击者破坏的东西可以通过分布式拒绝服务（DDoS）攻击破坏其他网络或系统的运行。
To deal with the above threats, it is required to find and apply suitable security mitigations. However, new threats and exploits appear on a daily basis, and products are deployed in different environments prone to different types of threats. Thus, ensuring a proper level of security in an IoT system at any point of time is challenging. To address this challenge, some of the following methodologies can be used:
为了应对上述威胁，需要找到并应用适当的安全缓解措施。但是，每天都会出现新的威胁和利用漏洞的情况，产品部署在容易受到不同类型威胁的不同环境中。因此，在任何时间点确保物联网系统的适当安全水平都是一项挑战。为了应对这一挑战，可以使用以下一些方法：
1. A Business Impact Analysis (BIA) assesses the consequences of the loss of basic security attributes: confidentiality, integrity, and availability in an IoT system. These consequences might include the impact from lost data, reduced sales, increased expenses, regulatory fines, customer dissatisfaction, etc. Performing a business impact analysis allows a business to determine the relevance of having a proper security design.
1. 业务影响分析（BIA）评估基本安全属性丢失的后果：物联网系统中的机密性、完整性和可用性。这些后果可能包括数据丢失、销售额减少、费用增加、监管罚款、客户不满等造成的影响。执行业务影响分析可让企业确定采用适当安全设计的相关性。
2. A Risk Assessment (RA) analyzes security threats to an IoT system while considering their likelihood and impact. It also includes categorizing each of them with a risk level. Risks classified as moderate or high must be mitigated, i.e., the security architecture should be able to deal with those threats.
2. 风险评估（RA）分析物联网系统的安全威胁，同时考虑其可能性和影响。它还包括按风险等级对每种风险进行分类。分类为中等或高风险的风险必须得到缓解，即安全体系结构应该能够应对这些威胁。
3. A Privacy Impact Assessment (PIA) aims at assessing the Personally Identifiable Information (PII) that is collected, processed, or used in an IoT system. By doing so, the goal is to fulfill applicable legal requirements and determine the risks and effects of manipulation and loss of PII.
3. 隐私影响评估（PIA）旨在评估物联网系统中收集、处理或使用的个人识别信息（PII）。这样做的目的是满足适用的法律要求，并确定操纵和丢失PII的风险和影响。
4. Procedures for incident reporting and mitigation refer to the methodologies that allow becoming aware of any security issues that affect an IoT system. Furthermore, this includes steps towards the actual deployment of patches that mitigate the identified vulnerabilities.
4. 事件报告和缓解程序是指允许了解影响物联网系统的任何安全问题的方法。此外，这包括实际部署补丁的步骤，这些补丁可以缓解已识别的漏洞。
BIA, RA, and PIA should generally be realized during the creation of a new IoT system or when deploying significant system/feature upgrades. In general, it is recommended to reassess them on a regular basis, taking into account new use cases and/or threats. The way a BIA, RA, or PIA is performed depends on the environment and the industry. More information can be found in NIST documents such as [NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122].
BIA、RA和PIA通常应在创建新的物联网系统期间或部署重大系统/功能升级时实现。一般来说，建议定期对其进行重新评估，同时考虑新的用例和/或威胁。BIA、RA或PIA的执行方式取决于环境和行业。更多信息可在NIST文件中找到，如[NISTSP800-34r1]、[NISTSP800-30r1]和[NISTSP800-122]。
This section is organized as follows. Section 4.1 summarizes the state of the art on IP-based IoT systems, within both the IETF and other standardization bodies. Section 4.2 summarizes the state of the art on IP-based security protocols and their usage. Section 4.3 discusses guidelines and regulations for securing IoT as proposed by other bodies. Note that the references included in this section are a representative of the state of the art at the point of writing, and they are by no means exhaustive. The references are also at varying levels of maturity; thus, it is advisable to review their specific status.
本节的组织如下。第4.1节总结了IETF和其他标准化机构内基于IP的物联网系统的最新技术。第4.2节总结了基于IP的安全协议及其使用的最新技术。第4.3节讨论了其他机构提出的物联网安全指南和条例。请注意，本节中包含的参考文献在写作时代表了最先进的技术，它们并非详尽无遗。参考文件的成熟度也各不相同；因此，建议审查其具体状况。
Nowadays, there exists a multitude of control protocols for IoT. For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI [DALI] play key roles. Recent trends, however, focus on an all-IP approach for system control.
目前，物联网有多种控制协议。对于BAC系统，ZigBee标准[ZB]、BACNet[BACNet]和DALI[DALI]起着关键作用。然而，最近的趋势侧重于系统控制的全IP方法。
In this setting, a number of IETF working groups are designing new protocols for resource-constrained networks of smart things. The 6LoWPAN Working Group [WG-6LoWPAN], for example, has defined methods and protocols for the efficient transmission and adaptation of IPv6 packets over IEEE 802.15.4 networks [RFC4944].
在这种情况下，许多IETF工作组正在为资源受限的智能物联网设计新的协议。例如，6LoWPAN工作组[WG-6LoWPAN]定义了在IEEE 802.15.4网络上高效传输和适配IPv6数据包的方法和协议[RFC4944]。
The CoRE Working Group [WG-CoRE] has specified the Constrained Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol for constrained devices that is modeled after HTTP and typically runs over UDP to enable efficient application-level communication for things. ("RESTful" refers to the Representational State Transfer (REST) architecture.)
核心工作组[WG CoRE]规定了受限应用协议（CoAP）[RFC7252]。CoAP是一种用于受约束设备的RESTful协议，它以HTTP为模型，通常在UDP上运行，以实现高效的应用程序级通信。（“RESTful”指的是代表性状态转移（REST）体系结构。）
In many smart-object networks, the smart objects are dispersed and have intermittent reachability either because of network outages or because they sleep during their operational phase to save energy. In such scenarios, direct discovery of resources hosted on the constrained server might not be possible. To overcome this barrier, the CoRE Working Group is specifying the concept of a Resource Directory (RD) [RD]. The Resource Directory hosts descriptions of resources that are located on other nodes. These resource descriptions are specified as CoRE link format [RFC6690].
在许多智能对象网络中，智能对象分散且具有间歇性的可达性，这可能是因为网络中断，也可能是因为它们在运行阶段睡眠以节省能源。在这种情况下，可能无法直接发现托管在受约束服务器上的资源。为了克服这一障碍，核心工作组正在指定资源目录（RD）[RD]的概念。资源目录承载位于其他节点上的资源的描述。这些资源描述被指定为核心链接格式[RFC6690]。
While CoAP defines a standard communication protocol, a format for representing sensor measurements and parameters over CoAP is required. "Sensor Measurement Lists (SenML)" [RFC8428] is a specification that defines media types for simple sensor measurements and parameters. It has a minimalistic design so that constrained
虽然CoAP定义了一个标准的通信协议，但需要一种通过CoAP表示传感器测量和参数的格式。“传感器测量列表（SenML）”[RFC8428]是定义简单传感器测量和参数的介质类型的规范。它有一个极简主义的设计，使限制
devices with limited computational capabilities can easily encode their measurements and, at the same time, servers can efficiently collect a large number of measurements.
计算能力有限的设备可以轻松地对其测量值进行编码，同时，服务器可以有效地收集大量测量值。
In many IoT deployments, the resource-constrained smart objects are connected to the Internet via a gateway that is directly reachable. For example, an IEEE 802.11 Access Point (AP) typically connects the client devices to the Internet over just one wireless hop. However, some deployments of smart-object networks require routing between the smart objects themselves. The IETF has therefore defined the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. RPL provides support for multipoint-to-point traffic from resource-constrained smart objects towards a more resourceful central control point, as well as point-to-multipoint traffic in the reverse direction. It also supports point-to-point traffic between the resource-constrained devices. A set of routing metrics and constraints for path calculation in RPL are also specified [RFC6551].
在许多物联网部署中，资源受限的智能对象通过可直接访问的网关连接到互联网。例如，IEEE 802.11接入点（AP）通常仅通过一个无线跳将客户端设备连接到Internet。但是，智能对象网络的某些部署需要在智能对象本身之间进行路由。因此，IETF定义了低功耗和有损网络（RPL）的IPv6路由协议[RFC6550]。RPL支持从资源受限的智能对象到资源更丰富的中央控制点的多点对点通信，以及反向的点对多点通信。它还支持资源受限设备之间的点对点通信。还指定了RPL中用于路径计算的一组路由度量和约束[RFC6551]。
The IPv6 over Networks of Resource-constrained Nodes (6lo) Working Group of the IETF [WG-6lo] has specified how IPv6 packets can be transmitted over various link-layer protocols that are commonly employed for resource-constrained smart-object networks. There is also ongoing work to specify IPv6 connectivity for a Non-Broadcast Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH) links [ARCH-6TiSCH]. Other link-layer protocols for which the IETF has specified or is currently specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air interface [RFC8105], and Near Field Communication (NFC) [IPv6-over-NFC].
IETF[WG-6lo]的资源受限节点网络上的IPv6（6lo）工作组已规定了如何通过资源受限智能对象网络常用的各种链路层协议传输IPv6数据包。还正在进行工作，为由IEEE 802.15.4时隙信道跳频（TSCH）链路[ARCH-6TiSCH]形成的非广播多址（NBMA）网状网络指定IPv6连接。IETF已指定或目前正在指定IPv6支持的其他链路层协议包括蓝牙[RFC7668]、数字增强无绳通信（DECT）超低能（ULE）空中接口[RFC8105]和近场通信（NFC）[IPv6 over NFC]。
Baker and Meyer [RFC6272] identify which IP protocols can be used in smart-grid environments. They give advice to smart-grid network designers on how they can decide on a profile of the Internet protocol suite for smart-grid networks.
Baker和Meyer[RFC6272]确定了哪些IP协议可用于智能电网环境。他们向智能电网网络设计师提供建议，指导他们如何决定智能电网网络互联网协议套件的配置文件。
The Low Power Wide-Area Network (LPWAN) Working Group [WG-LPWAN] is analyzing features, requirements, and solutions to adapt IP-based protocols to networks such as LoRa [LoRa], Sigfox [sigfox], NB-IoT [NB-IoT], etc. These networking technologies enable a smart thing to run for years on a single coin-cell by relying on a star network topology and using optimized radio modulation with frame sizes in the order of tens of bytes. Such networks bring new security challenges, since most existing security mechanism do not work well with such resource constraints.
低功耗广域网（LPWAN）工作组[WG-LPWAN]正在分析特性、要求和解决方案，以使基于IP的协议适应LoRa[LoRa]、Sigfox[Sigfox]、NB IoT[NB IoT]等网络，这些网络技术依靠星形网络拓扑结构，使用帧大小为数十字节的优化无线电调制，使智能设备能够在单个硬币电池上运行数年。这种网络带来了新的安全挑战，因为大多数现有的安全机制不能很好地处理这种资源限制。
JavaScript Object Notation (JSON) is a lightweight text-representation format for structured data [RFC8259]. It is often used for transmitting serialized structured data over the network. The IETF has defined specifications for encoding cryptographic keys, encrypted content, signed content, and claims to be transferred between two parties as JSON objects. They are referred to as JSON Web Keys (JWKs) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON Web Signatures (JWSs) [RFC7515], and JSON Web Token (JWT) [RFC7519].
JavaScript对象表示法（JSON）是结构化数据的轻量级文本表示格式[RFC8259]。它通常用于通过网络传输序列化的结构化数据。IETF定义了加密密钥、加密内容、签名内容的编码规范，并声明在双方之间作为JSON对象传输。它们被称为JSON Web密钥（JWKs）[RFC7517]、JSON Web加密（JWE）[RFC7516]、JSON Web签名（JWSs）[RFC7515]和JSON Web令牌（JWT）[RFC7519]。
An alternative to JSON, Concise Binary Object Representation (CBOR) [RFC7049], is a concise binary data format that is used for serialization of structured data. It is designed for resource-constrained nodes, and therefore it aims to provide a fairly small message size with minimal implementation code and extensibility without the need for version negotiation. CBOR Object Signing and Encryption (COSE) [RFC8152] specifies how to encode cryptographic keys, message authentication codes, encrypted content, and signatures with CBOR.
JSON的另一种替代方法是简明二进制对象表示（CBOR）[RFC7049]，它是一种用于结构化数据序列化的简明二进制数据格式。它是为资源受限的节点而设计的，因此它的目标是提供一个相当小的消息大小，具有最小的实现代码和可扩展性，而无需进行版本协商。CBOR对象签名和加密（COSE）[RFC8152]指定如何使用CBOR对加密密钥、消息身份验证码、加密内容和签名进行编码。
The Light-Weight Implementation Guidance (LWIG) Working Group [WG-LWIG] is collecting experiences from implementers of IP stacks in constrained devices. The working group has already produced documents such as [RFC7815], which defines how a minimal Internet Key Exchange Version 2 (IKEv2) initiator can be implemented.
轻量级实施指南（LWIG）工作组[WG-LWIG]正在收集受限设备中IP堆栈实施者的经验。工作组已经编制了[RFC7815]等文件，其中定义了如何实现最小Internet密钥交换版本2（IKEv2）启动器。
The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating the remaining research issues that need to be addressed to quickly turn the vision of IoT into a reality where resource-constrained nodes can communicate with each other and with other more capable nodes on the Internet.
Thing-2-Thing研究小组（T2TRG）[RG-T2TRG]正在调查需要解决的剩余研究问题，以快速将物联网的愿景转变为现实，在这一现实中，资源受限的节点可以相互通信，也可以与互联网上其他能力更强的节点通信。
Additionally, industry alliances and other standardization bodies are creating constrained IP protocol stacks based on the IETF work. Some important examples of this include:
此外，行业联盟和其他标准化机构正在基于IETF工作创建受限IP协议栈。这方面的一些重要例子包括：
1. Thread [Thread]: Specifies the Thread protocol that is intended for a variety of IoT devices. It is an IPv6-based network protocol that runs over IEEE 802.15.4.
1. 线程[线程]：指定用于各种IoT设备的线程协议。它是一种基于IPv6的网络协议，运行于IEEE 802.15.4之上。
2. Industrial Internet Consortium [IIoT]: The consortium defines reference architectures and security frameworks for development, adoption, and widespread use of Industrial Internet technologies based on existing IETF standards.
2. 工业互联网联盟[IIoT]：该联盟定义了基于现有IETF标准开发、采用和广泛使用工业互联网技术的参考体系结构和安全框架。
3. IPSO Alliance (which subsequently merged with OMA SpecWorks [OMASpecWorks]): The alliance specifies a common object model that enables application software on any device to interoperate with other conforming devices.
3. IPSO联盟（随后与OMA SpecWorks[OMASpecWorks]合并）：该联盟指定了一个通用对象模型，使任何设备上的应用软件都能够与其他符合要求的设备进行互操作。
4. OneM2M [OneM2M]: The standards body defines technical and API specifications for IoT devices. It aims to create a service layer that can run on any IoT device hardware and software.
4. OneM2M[OneM2M]：标准机构定义物联网设备的技术和API规范。它旨在创建一个可以在任何物联网设备硬件和软件上运行的服务层。
5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops standards and certifications primarily for IoT devices that use Constrained Application Protocol (CoAP) as the application-layer protocol.
5. 开放连接基金会（OCF）[OCF]：该基金会主要针对使用受限应用协议（COAP）作为应用层协议的IOT设备开发标准和认证。
6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to enable a common IP network infrastructure between different application standards used in building automation and lighting systems such as BACnet, KNX, and ZigBee.
6. Fairhair Alliance[Fairhair]：指定一个物联网中间件，用于在楼宇自动化和照明系统（如BACnet、KNX和ZigBee）中使用的不同应用标准之间实现通用IP网络基础设施。
7. OMA LwM2M [LWM2M]: OMA Lightweight M2M is a standard from the OMA SpecWorks for M2M and IoT device management. LwM2M relies on CoAP as the application-layer protocol and uses a RESTful architecture for remote management of IoT devices.
7. OMA LwM2M[LwM2M]：OMA轻量级M2M是OMA规范中用于M2M和物联网设备管理的标准。LwM2M依赖CoAP作为应用层协议，并使用RESTful体系结构远程管理物联网设备。
There are three main security objectives for IoT networks:
物联网网络有三个主要安全目标：
1. protecting the IoT network from attackers
1. 保护物联网网络免受攻击者攻击
2. protecting IoT applications and thus the things and users
2. 保护物联网应用程序，从而保护物品和用户
3. protecting the rest of the Internet and other things from attacks that use compromised things as an attack platform
3. 保护互联网的其余部分和其他东西免受攻击，这些攻击将受损的东西用作攻击平台
In the context of the IP-based IoT deployments, consideration of existing Internet security protocols is important. There are a wide range of specialized as well as general-purpose security solutions for the Internet domain, such as IKEv2/IPsec [RFC7296], Transport Layer Security (TLS) [RFC8446], Datagram Transport Layer Security (DTLS) [RFC6347], Host Identity Protocol (HIP) [RFC7401], PANA [RFC5191], Kerberos [RFC4120], Simple Authentication and Security Layer (SASL) [RFC4422], and Extensible Authentication Protocol (EAP) [RFC3748].
在基于IP的物联网部署中，考虑现有的互联网安全协议非常重要。互联网领域有广泛的专用和通用安全解决方案，如IKEv2/IPsec[RFC7296]、传输层安全性（TLS）[RFC8446]、数据报传输层安全性（DTLS）[RFC6347]、主机身份协议（HIP）[RFC7401]、PANA[RFC5191]、Kerberos[RFC4120]，简单身份验证和安全层（SASL）[RFC4422]和可扩展身份验证协议（EAP）[RFC3748]。
TLS provides security for TCP and requires a reliable transport. DTLS secures and uses datagram-oriented protocols such as UDP. Both protocols are intentionally kept similar and share the same ideology and cipher suites. The CoAP base specification [RFC7252] provides a description of how DTLS can be used for securing CoAP. It proposes three different modes for using DTLS: the PreSharedKey mode, where nodes have pre-provisioned keys for initiating a DTLS session with another node, RawPublicKey mode, where nodes have asymmetric-key
TLS为TCP提供安全性，并且需要可靠的传输。DTLS保护并使用面向数据报的协议，如UDP。这两个协议有意保持相似，并共享相同的思想和密码套件。CoAP基本规范[RFC7252]描述了如何使用DTL保护CoAP。它提出了使用DTLS的三种不同模式：预共享密钥模式，其中节点具有用于启动与另一节点的DTLS会话的预配置密钥；RawPublicKey模式，其中节点具有非对称密钥
pairs but no certificates to verify the ownership, and Certificate mode, where public keys are certified by a certification authority. An IoT implementation profile is defined for TLS version 1.2 and DTLS version 1.2 that offers communication security for resource-constrained nodes [RFC7925].
配对但无证书以验证所有权和证书模式，其中公钥由证书颁发机构认证。为TLS版本1.2和DTLS版本1.2定义了物联网实施概要文件，为资源受限节点提供通信安全[RFC7925]。
There is ongoing work to define an authorization and access-control framework for resource-constrained nodes. The Authentication and Authorization for Constrained Environments (ACE) Working Group [WG-ACE] is defining a solution to allow only authorized access to resources that are hosted on a smart-object server and identified by a URI. The current proposal [ACE-OAuth] is based on the OAuth 2.0 framework [RFC6749], and it comes with profiles intended for different communication scenarios, e.g., "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" [ACE-DTLS].
目前正在为资源受限的节点定义授权和访问控制框架。受限环境的身份验证和授权（ACE）工作组[WG-ACE]正在定义一种解决方案，只允许对托管在智能对象服务器上并由URI标识的资源进行授权访问。当前的提案[ACE OAuth]基于OAuth 2.0框架[RFC6749]，并且它附带了用于不同通信场景的配置文件，例如，“用于受限环境（ACE）的身份验证和授权的数据报传输层安全（DTLS）配置文件”[ACE-DTLS]。
Object Security for Constrained RESTful Environments (OSCORE) [OSCORE] is a proposal that protects CoAP messages by wrapping them in the COSE format [RFC8152]. Thus, OSCORE falls in the category of object security, and it can be applied wherever CoAP can be used. The advantage of OSCORE over DTLS is that it provides some more flexibility when dealing with end-to-end security. Section 5.1.3 discusses this further.
受限RESTful环境的对象安全性（OSCORE）[OSCORE]是一项提案，它通过将CoAP消息包装为COSE格式[RFC8152]来保护CoAP消息。因此，OSCORE属于对象安全的范畴，它可以应用于任何可以使用CoAP的地方。与DTLS相比，OSCORE的优势在于它在处理端到端安全性时提供了更多的灵活性。第5.1.3节对此进行了进一步讨论。
The Automated Certificate Management Environment (ACME) Working Group [WG-ACME] is specifying conventions for automated X.509 certificate management. This includes automatic validation of certificate issuance, certificate renewal, and certificate revocation. While the initial focus of the working group is on domain-name certificates (as used by web servers), other uses in some IoT deployments are possible.
自动证书管理环境（ACME）工作组[WG-ACME]正在指定自动X.509证书管理的约定。这包括证书颁发、证书续订和证书吊销的自动验证。虽然工作组最初的重点是域名证书（由web服务器使用），但在某些物联网部署中也可能有其他用途。
The Internet Key Exchange (IKEv2)/IPsec -- as well as the less used Host Identity protocol (HIP) -- reside at or above the network layer in the OSI model. Both protocols are able to perform an authenticated key exchange and set up the IPsec for secure payload delivery. Currently, there are also ongoing efforts to create a HIP variant coined Diet HIP [HIP-DEX] that takes constrained networks and nodes into account at the authentication and key-exchange level.
Internet密钥交换（IKEv2）/IPsec——以及使用较少的主机标识协议（HIP）——位于OSI模型的网络层或网络层之上。这两个协议都能够执行经过身份验证的密钥交换，并为安全的有效负载传递设置IPsec。目前，还正在努力创建一种HIP变体，即Diet HIP[HIP-DEX]，它在身份验证和密钥交换级别上考虑受约束的网络和节点。
Migault et al. [Diet-ESP] are working on a compressed version of IPsec so that it can easily be used by resource-constrained IoT devices. They rely on the Internet Key Exchange Protocol Version 2 (IKEv2) for negotiating the compression format.
Migault等人[Diet ESP]正在开发IPsec的压缩版本，以便资源受限的物联网设备可以轻松使用。他们依靠Internet密钥交换协议版本2（IKEv2）协商压缩格式。
The Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework supporting multiple authentication methods.
可扩展身份验证协议（EAP）[RFC3748]是一个支持多种身份验证方法的身份验证框架。
EAP runs directly over the data link layer and thus does not require the deployment of IP. It supports duplicate detection and retransmission but does not allow for packet fragmentation. PANA is a network-layer transport for EAP that enables network access authentication between clients and the network infrastructure. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator.
EAP直接在数据链路层上运行，因此不需要部署IP。它支持重复检测和重传，但不允许数据包碎片。PANA是EAP的网络层传输，支持客户端和网络基础设施之间的网络访问身份验证。在EAP术语中，PANA是一个基于UDP的EAP底层，运行在EAP对等方和EAP验证器之间。
Attacks on and from IoT devices have become common in recent years -- for instance, large-scale DoS attacks on the Internet Infrastructure from compromised IoT devices. This fact has prompted many different standards bodies and consortia to provide guidelines for developers and the Internet community at large to build secure IoT devices and services. The following is a subset of the different guidelines and ongoing projects:
近几年来，对物联网设备的攻击和来自物联网设备的攻击已经变得很普遍——例如，来自受损物联网设备的对互联网基础设施的大规模DoS攻击。这一事实促使许多不同的标准机构和联盟为开发者和整个互联网社区提供指导方针，以构建安全的物联网设备和服务。以下是不同指南和正在进行的项目的子集：
1. Global System for Mobile Communications Association (GSMA) IoT security guidelines [GSMAsecurity]: GSMA has published a set of security guidelines for the benefit of new IoT product and service providers. The guidelines are aimed at device manufacturers, service providers, developers, and network operators. An enterprise can complete an IoT Security Self-Assessment to demonstrate that its products and services are aligned with the security guidelines of the GSMA.
1. 全球移动通信系统协会（GSMA）物联网安全指南[GSMAsecurity]：GSMA已经发布了一套安全指南，以惠及新的物联网产品和服务提供商。该指南面向设备制造商、服务提供商、开发人员和网络运营商。企业可以完成物联网安全自我评估，以证明其产品和服务符合GSMA的安全指南。
2. Broadband Internet Technical Advisory Group (BITAG) IoT Security and Privacy Recommendations [BITAG]: BITAG has published recommendations for ensuring the security and privacy of IoT device users. BITAG observes that many IoT devices are shipped from the factory with software that is already outdated and vulnerable. The report also states that many devices with vulnerabilities will not be fixed, either because the manufacturer does not provide updates or because the user does not apply them. The recommendations include that IoT devices should function without cloud and Internet connectivity and that all IoT devices should have methods for automatic secure software updates.
2. 宽带互联网技术咨询小组（BITAG）物联网安全和隐私建议[BITAG]：BITAG发布了确保物联网设备用户安全和隐私的建议。BITAG观察到，许多物联网设备出厂时附带的软件已经过时且易受攻击。该报告还指出，由于制造商不提供更新或用户不应用更新，许多存在漏洞的设备将无法修复。建议包括物联网设备应在没有云和互联网连接的情况下运行，所有物联网设备应具有自动安全软件更新的方法。
3. United Kingdom Department for Digital, Culture, Media and Sport (DCMS) [DCMS]: UK DCMS has released a report that includes a list of 13 steps for improving IoT security. These steps, for example, highlight the need for implementing a vulnerability disclosure policy and keeping software updated. The report is aimed at device manufacturers, IoT service providers, mobile application developers, and retailers.
3. 英国数字、文化、媒体和体育部（DCMS）[DCMS]：英国DCMS发布了一份报告，其中包括改善物联网安全的13个步骤。例如，这些步骤强调了实施漏洞披露策略和保持软件更新的必要性。该报告针对设备制造商、物联网服务提供商、移动应用程序开发商和零售商。
4. Cloud Security Alliance (CSA) New Security Guidance for Early Adopters of the IoT [CSA]: CSA recommendations for early adopters of IoT encourage enterprises to implement security at different layers of the protocol stack. It also recommends implementation of an authentication/authorization framework for IoT deployments. A complete list of recommendations is available in the report [CSA].
4. 云安全联盟（CSA）针对物联网早期采用者的新安全指南[CSA]：针对物联网早期采用者的CSA建议鼓励企业在协议栈的不同层实施安全。它还建议为物联网部署实施身份验证/授权框架。报告[CSA]中提供了完整的建议列表。
5. United States Department of Homeland Security (DHS) [DHS]: DHS has put forth six strategic principles that would enable IoT developers, manufacturers, service providers, and consumers to maintain security as they develop, manufacture, implement, or use network-connected IoT devices.
5. 美国国土安全部（DHS）[DHS]：DHS提出了六项战略原则，使物联网开发商、制造商、服务提供商和消费者在开发、制造、实施或使用网络连接物联网设备时能够维护安全。
6. National Institute of Standards and Technology (NIST) [NIST-Guide]: The NIST special publication urges enterprise and US federal agencies to address security throughout the systems engineering process. The publication builds upon the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288 standard and augments each process in the system lifecycle with security enhancements.
6. 国家标准与技术研究所（NIST）[NIST指南]：NIST特别出版物敦促企业和美国联邦机构在整个系统工程过程中解决安全问题。本出版物以国际标准化组织（ISO）/国际电工委员会（IEC）15288标准为基础，并通过安全增强增强系统生命周期中的每个过程。
7. National Institute of Standards and Technology (NIST) [NIST-LW-PROJECT] [NIST-LW-2016]: NIST is running a project on lightweight cryptography with the purpose of: (i) identifying application areas for which standard cryptographic algorithms are too heavy, classifying them according to some application profiles to be determined; (ii) determining limitations in those existing cryptographic standards; and (iii) standardizing lightweight algorithms that can be used in specific application profiles.
7. 国家标准与技术研究所（NIST）[NIST-LW-PROJECT][NIST-LW-2016]：NIST正在运行一个轻量级加密项目，目的是：（i）确定标准加密算法过于繁重的应用领域，并根据待确定的一些应用概要对其进行分类；（ii）确定这些现有加密标准的限制；（iii）标准化可用于特定应用程序配置文件的轻量级算法。
8. Open Web Application Security Project (OWASP) [OWASP]: OWASP provides security guidance for IoT manufacturers, developers, and consumers. OWASP also includes guidelines for those who intend to test and analyze IoT devices and applications.
8. 开放式Web应用程序安全项目（OWASP）[OWASP]：OWASP为物联网制造商、开发者和消费者提供安全指导。OWASP还包括针对打算测试和分析物联网设备和应用程序的人员的指南。
9. IoT Security Foundation [IoTSecFoundation]: The IoT Security Foundation has published a document that enlists various considerations that need to be taken into account when developing IoT applications. For example, the document states that IoT devices could use a hardware root of trust to ensure that only authorized software runs on the devices.
9. IOT安全基金会[IOTSECKASTIM]：IOT安全基金会发布了一份文件，其中列出了在开发物联网应用时需要考虑的各种考虑事项。例如，该文件指出，物联网设备可以使用硬件信任根来确保设备上仅运行授权软件。
10. National Highway Traffic Safety Administration (NHTSA) [NHTSA]: The US NHTSA provides guidance to the automotive industry for improving the cyber security of vehicles. While some of the
10. 美国国家公路交通安全管理局（NHTSA）[NHTSA]：美国国家公路交通安全管理局为汽车行业提供指导，以提高车辆的网络安全性。而一些
guidelines are general, the document provides specific recommendations for the automotive industry, such as how various automotive manufacturers can share cybersecurity vulnerabilities discovered.
指南是一般性的，该文件为汽车行业提供了具体建议，例如各种汽车制造商如何共享发现的网络安全漏洞。
11. "Best Current Practices for Securing Internet of Things (IoT) Devices" [Moore]: This document provides a list of minimum requirements that vendors of IoT devices should to take into account while developing applications, services, and firmware updates in order to reduce the frequency and severity of security incidents that arise from compromised IoT devices.
11. “物联网（IoT）设备安全的最佳当前实践”【摩尔】：本文件提供了物联网设备供应商在开发应用程序、服务和服务时应考虑的最低要求列表，以及固件更新，以降低因受损物联网设备引起的安全事件的频率和严重性。
12. European Union Agency for Network and Information Security (ENISA) [ENISA-ICS]: ENISA published a document on communication-network dependencies for Industrial Control Systems (ICS)/Supervisory Control And Data Acquisition (SCADA) systems in which security vulnerabilities, guidelines, and general recommendations are summarized.
12. 欧盟网络和信息安全局（ENISA）[ENISA-ICS]：ENISA发布了一份关于工业控制系统（ICS）/监控和数据采集（SCADA）系统的通信网络依赖性的文件，其中总结了安全漏洞、指南和一般建议。
13. Internet Society Online Trust Alliance [ISOC-OTA]: The Internet Society's IoT Trust Framework identifies the core requirements that manufacturers, service providers, distributors, purchasers, and policymakers need to understand, assess, and embrace for effective security and privacy as part of the Internet of Things.
13. 互联网协会在线信任联盟[ISOC-OTA]：互联网协会的物联网信任框架确定了制造商、服务提供商、分销商、购买者和决策者需要了解、评估和接受的核心要求，以确保作为物联网一部分的有效安全和隐私。
Other guideline and recommendation documents may exist or may later be published. This list should be considered nonexhaustive. Despite the acknowledgment that security in the Internet is needed and the existence of multiple guidelines, the fact is that many IoT devices and systems have very limited security. There are multiple reasons for this. For instance, some manufacturers focus on delivering a product without paying enough attention to security. This may be because of lack of expertise or limited budget. However, the deployment of such insecure devices poses a severe threat to the privacy and safety of users. The vast number of devices and their inherently mobile nature also imply that an initially secure system can become insecure if a compromised device gains access to the system at some point in time. Even if all other devices in a given environment are secure, this does not prevent external attacks caused by insecure devices. Recently, the US Federal Communications Commission (FCC) has stated the need for additional regulation of IoT systems [FCC]. It is possible that we may see other such regional regulations in the future.
其他指南和建议文件可能存在，或可能随后发布。此列表应被视为非穷举列表。尽管承认互联网的安全性是必要的，并且存在多种指导原则，但事实是许多物联网设备和系统的安全性非常有限。这有多种原因。例如，一些制造商专注于交付产品，而没有对安全性给予足够的重视。这可能是因为缺乏专业知识或预算有限。然而，这种不安全设备的部署对用户的隐私和安全构成了严重威胁。大量设备及其固有的移动特性还意味着，如果受损设备在某个时间点访问系统，则最初安全的系统可能变得不安全。即使给定环境中的所有其他设备都是安全的，这也不能防止由不安全设备引起的外部攻击。最近，美国联邦通信委员会（FCC）表示需要对物联网系统[FCC]进行额外监管。将来我们可能会看到其他此类区域性法规。
In this section, we take a closer look at the various security challenges in the operational and technical features of IoT and then discuss how existing Internet security protocols cope with these technical and conceptual challenges through the lifecycle of a thing. This discussion should not be understood as a comprehensive evaluation of all protocols, nor can it cover all possible aspects of IoT security. Yet, it aims at showing concrete limitations and challenges in some IoT design areas rather than giving an abstract discussion. In this regard, the discussion handles issues that are most important from the authors' perspectives.
在本节中，我们将更深入地了解物联网运营和技术特征中的各种安全挑战，然后讨论现有互联网安全协议如何在物联网的整个生命周期中应对这些技术和概念挑战。此讨论不应理解为对所有协议的全面评估，也不能涵盖物联网安全的所有可能方面。然而，它旨在展示一些物联网设计领域的具体限制和挑战，而不是进行抽象的讨论。在这方面，讨论从作者的角度处理最重要的问题。
Coupling resource-constrained networks and the powerful Internet is a challenge, because the resulting heterogeneity of both networks complicates protocol design and system operation. In the following subsections, we briefly discuss the resource constraints of IoT devices and the consequences for the use of Internet protocols in the IoT domain.
将资源受限的网络和功能强大的互联网耦合起来是一个挑战，因为由此产生的两个网络的异构性使协议设计和系统操作复杂化。在以下小节中，我们将简要讨论物联网设备的资源限制以及在物联网领域使用互联网协议的后果。
IoT deployments are often characterized by lossy and low-bandwidth communication channels. IoT devices are also often constrained in terms of the CPU, memory, and energy budget available [RFC7228]. These characteristics directly impact the design of protocols for the IoT domain. For instance, small packet-size limits at the physical layer (127 Bytes in IEEE 802.15.4) can lead to (i) hop-by-hop fragmentation and reassembly or (ii) small IP-layer maximum transmission unit (MTU). In the first case, excessive fragmentation of large packets that are often required by security protocols may open new attack vectors for state-exhaustion attacks. The second case might lead to more fragmentation at the IP layer, which commonly downgrades the overall system performance due to packet loss and the need for retransmission.
物联网部署通常以有损和低带宽通信信道为特征。物联网设备通常在CPU、内存和可用能源预算方面受到限制[RFC7228]。这些特性直接影响物联网领域协议的设计。例如，物理层的小数据包大小限制（IEEE 802.15.4中的127字节）可能导致（i）逐跳分段和重新组装，或（ii）小IP层最大传输单元（MTU）。在第一种情况下，安全协议通常需要的大数据包的过度碎片化可能会为状态耗尽攻击打开新的攻击向量。第二种情况可能会导致IP层出现更多的碎片，这通常会由于数据包丢失和需要重新传输而降低系统的整体性能。
The size and number of messages should be minimized to reduce memory requirements and optimize bandwidth usage. In this context, layered approaches involving a number of protocols might lead to worse performance in resource-constrained devices since they combine the headers of the different protocols. In some settings, protocol negotiation can increase the number of exchanged messages. To improve performance during basic procedures such as, for example, bootstrapping, it might be a good strategy to perform those procedures at a lower layer.
消息的大小和数量应该最小化，以减少内存需求并优化带宽使用。在这种情况下，涉及多个协议的分层方法可能会导致资源受限设备的性能下降，因为它们将不同协议的头组合在一起。在某些设置中，协议协商会增加交换消息的数量。为了提高基本过程（例如，引导）期间的性能，在较低层执行这些过程可能是一个不错的策略。
Small CPUs and scarce memory limit the usage of resource-expensive cryptographic primitives such as public key cryptography as used in most Internet security standards. This is especially true if the basic cryptographic blocks need to be frequently used or the underlying application demands low delay.
小型CPU和稀缺内存限制了资源昂贵的加密原语的使用，如大多数互联网安全标准中使用的公钥加密。如果需要频繁使用基本加密块或底层应用程序要求低延迟，则尤其如此。
There are ongoing efforts to reduce the resource consumption of security protocols by using more efficient underlying cryptographic primitives such as Elliptic Curve Cryptography (ECC) [RFC8446]. The specification of elliptic curve X25519 [ecc25519], stream ciphers such as ChaCha [ChaCha], Diet HIP [HIP-DEX], and ECC groups for IKEv2 [RFC5903] are all examples of efforts to make security protocols more resource efficient. Additionally, most modern security protocols have been revised in the last few years to enable cryptographic agility, making cryptographic primitives interchangeable. However, these improvements are only a first step in reducing the computation and communication overhead of Internet protocols. The question remains if other approaches can be applied to leverage key agreement in these heavily resource-constrained environments.
通过使用更有效的底层加密原语，如椭圆曲线加密（ECC）[RFC8446]，目前正在努力减少安全协议的资源消耗。椭圆曲线X25519[ecc25519]的规范、诸如ChaCha[ChaCha]、Diet HIP[HIP-DEX]等流密码以及IKEv2[RFC5903]的ECC组都是使安全协议更具资源效率的努力的示例。此外，大多数现代安全协议在过去几年中都进行了修订，以实现加密灵活性，使加密原语可互换。然而，这些改进只是减少互联网协议的计算和通信开销的第一步。问题在于，在这些资源严重受限的环境中，是否可以应用其他方法来利用关键协议。
A further fundamental need refers to the limited energy budget available to IoT nodes. Careful protocol (re)design and usage are required to reduce not only the energy consumption during normal operation but also under DoS attacks. Since the energy consumption of IoT devices differs from other device classes, judgments on the energy consumption of a particular protocol cannot be made without tailor-made IoT implementations.
另一个基本需求是物联网节点可用的有限能源预算。仔细的协议（重新）设计和使用不仅需要降低正常运行期间的能耗，而且还需要降低DoS攻击下的能耗。由于物联网设备的能耗不同于其他设备类别，因此在没有定制物联网实施的情况下，无法对特定协议的能耗做出判断。
The tight memory and processing constraints of things naturally alleviate resource-exhaustion attacks. Especially in unattended T2T communication, such attacks are difficult to notice before the service becomes unavailable (for example, because of battery or memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP implement return routability checks based on a cookie mechanism to delay the establishment of state at the responding host until the address of the initiating host is verified. The effectiveness of these defenses strongly depends on the routing topology of the network. Return routability checks are particularly effective if hosts cannot receive packets addressed to other hosts and if IP addresses present meaningful information as is the case in today's Internet. However, they are less effective in broadcast media or when attackers can influence the routing and addressing of hosts (for example, if hosts contribute to the routing infrastructure in ad hoc networks and meshes).
紧内存和处理限制自然缓解了资源耗尽攻击。特别是在无人值守的T2T通信中，在服务不可用之前很难发现此类攻击（例如，由于电池或内存耗尽）。作为DoS对策，DTL、IKEv2、HIP和Diet HIP基于cookie机制执行返回路由性检查，以延迟响应主机上状态的建立，直到验证发起主机的地址。这些防御的有效性在很大程度上取决于网络的路由拓扑。如果主机无法接收到发往其他主机的数据包，并且IP地址呈现有意义的信息（如当今的Internet），则返回路由性检查尤其有效。但是，在广播媒体中或攻击者可以影响主机的路由和寻址时（例如，如果主机有助于adhoc网络和网格中的路由基础设施），它们的效率较低。
In addition, HIP implements a puzzle mechanism that can force the initiator of a connection (and potential attacker) to solve cryptographic puzzles with variable difficulties. Puzzle-based defense mechanisms are less dependent on the network topology but perform poorly if CPU resources in the network are heterogeneous (for example, if a powerful Internet host attacks a thing). Increasing the puzzle difficulty under attack conditions can easily lead to situations where a powerful attacker can still solve the puzzle while weak IoT clients cannot and are excluded from communicating with the victim. Still, puzzle-based approaches are a viable option for sheltering IoT devices against unintended overload caused by misconfiguration or malfunctioning things.
此外，HIP实现了一种谜题机制，可以强制连接的发起人（以及潜在的攻击者）解决各种困难的密码谜题。基于谜题的防御机制对网络拓扑的依赖性较小，但如果网络中的CPU资源是异构的（例如，如果一个强大的Internet主机攻击某个对象），则性能较差。在攻击条件下增加谜题难度很容易导致这样的情况：强大的攻击者仍然可以解决谜题，而弱小的物联网客户端无法解决，并且被排除在与受害者的通信之外。尽管如此，基于谜题的方法仍然是一种可行的选择，可以保护物联网设备免受因错误配置或故障导致的意外过载。
5.1.3. End-to-End Security, Protocol Translation, and the Role of Middleboxes
5.1.3. 端到端安全性、协议转换和中间盒的作用
The term "end-to-end security" often has multiple interpretations. Here, we consider end-to-end security in the context of end-to-end IP connectivity from a sender to a receiver. Services such as confidentiality and integrity protection on packet data, message authentication codes, or encryption are typically used to provide end-to-end security. These protection methods render the protected parts of the packets immutable as rewriting is either not possible because (i) the relevant information is encrypted and inaccessible to the gateway or (ii) rewriting integrity-protected parts of the packet would invalidate the end-to-end integrity protection.
“端到端安全”一词通常有多种解释。在这里，我们考虑端到端的安全性的背景下，从发送者到接收者的端到端IP连接。包数据的保密性和完整性保护、消息身份验证代码或加密等服务通常用于提供端到端安全性。这些保护方法使数据包的受保护部分不可变，因为重写是不可能的，因为（i）相关信息已加密且网关无法访问，或者（ii）重写数据包的受完整性保护部分将使端到端完整性保护失效。
Protocols for constrained IoT networks are not exactly identical to their larger Internet counterparts, for efficiency and performance reasons. Hence, more or less subtle differences between protocols for constrained IoT networks and Internet protocols will remain. While these differences can be bridged with protocol translators at middleboxes, they may become major obstacles if end-to-end security measures between IoT devices and Internet hosts are needed.
出于效率和性能原因，受限物联网网络的协议与大型互联网协议并不完全相同。因此，受限物联网协议和互联网协议之间或多或少存在细微差异。虽然这些差异可以通过中间盒的协议转换器来弥补，但如果需要物联网设备和互联网主机之间的端到端安全措施，它们可能会成为主要障碍。
If access to data or messages by the middleboxes is required or acceptable, then a diverse set of approaches for handling such a scenario is available. Note that some of these approaches affect the meaning of end-to-end security in terms of integrity and confidentiality, since the middleboxes will be able to either decrypt or partially modify the exchanged messages:
如果需要或可以接受通过中间盒访问数据或消息，则可以使用一组不同的方法来处理这种情况。请注意，其中一些方法会影响端到端安全性在完整性和机密性方面的含义，因为中间件将能够解密或部分修改交换的消息：
1. Sharing credentials with middleboxes enables them to transform (for example, decompress, convert, etc.) packets and reapply the security measures after transformation. This method abandons end-to-end security and is only applicable to simple scenarios with a rudimentary security model.
1. 通过与中间盒共享凭据，它们可以转换（例如，解压缩、转换等）数据包，并在转换后重新应用安全措施。此方法放弃了端到端安全性，仅适用于具有基本安全模型的简单场景。
2. Reusing the Internet wire format for IoT makes conversion between IoT and Internet protocols unnecessary. However, it can lead to poor performance in some use cases because IoT-specific optimizations (for example, stateful or stateless compression) are not possible.
2. 为物联网重复使用互联网有线格式使得物联网和互联网协议之间的转换变得不必要。但是，在某些用例中，它可能导致性能低下，因为不可能进行物联网特定的优化（例如，有状态或无状态压缩）。
3. Selectively protecting vital and immutable packet parts with a message authentication code or encryption requires a careful balance between performance and security. Otherwise, this approach might either result in poor performance or poor security, depending on which parts are selected for protection, where they are located in the original packet, and how they are processed. [OSCORE] proposes a solution in this direction by encrypting and integrity protecting most of the message fields except those parts that a middlebox needs to read or change.
3. 使用消息身份验证代码或加密有选择地保护重要且不可变的数据包部分需要在性能和安全性之间保持谨慎的平衡。否则，此方法可能会导致性能差或安全性差，具体取决于选择保护的部件、它们在原始数据包中的位置以及处理方式。[OSCORE]提出了一种解决方案，通过加密和完整性保护大多数消息字段，但中间盒需要读取或更改的部分除外。
4. Homomorphic encryption techniques can be used in the middlebox to perform certain operations. However, this is limited to data processing involving arithmetic operations. Furthermore, the performance of existing libraries -- for example, Microsoft SEAL [SEAL] -- is still too limited, and homomorphic encryption techniques are not widely applicable yet.
4. 同态加密技术可以在中间盒中用于执行某些操作。然而，这仅限于涉及算术运算的数据处理。此外，现有库（例如Microsoft SEAL[SEAL]）的性能仍然非常有限，同态加密技术还没有得到广泛应用。
5. Message authentication codes that sustain transformation can be realized by considering the order of transformation and protection (for example, by creating a signature before compression so that the gateway can decompress the packet without recalculating the signature). Such an approach enables IoT-specific optimizations but is more complex and may require application-specific transformations before security is applied. Moreover, the usage of encrypted or integrity-protected data prevents middleboxes from transforming packets.
5. 支持转换的消息认证码可以通过考虑转换和保护的顺序来实现（例如，通过在压缩之前创建签名，以便网关可以在不重新计算签名的情况下解压缩数据包）。这种方法支持特定于物联网的优化，但更为复杂，可能需要在应用安全性之前进行特定于应用程序的转换。此外，使用加密或完整性保护的数据可以防止中间盒转换数据包。
6. Mechanisms based on object security can bridge the protocol worlds but still require that the two worlds use the same object-security formats. Currently, the object-security format based on COSE [RFC8152] is different from JSON Object Signing and Encryption (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS) [RFC5652]. Legacy devices relying on traditional Internet protocols will need to update to the newer protocols for constrained environments to enable real end-to-end security. Furthermore, middleboxes do not have any access to the data, and this approach does not prevent an attacker who is capable of modifying relevant message header fields that are not protected.
6. 基于对象安全性的机制可以连接协议世界，但仍然要求两个世界使用相同的对象安全格式。目前，基于COSE[RFC8152]的对象安全格式不同于JSON对象签名和加密（JOE）[RFC7520]或加密消息语法（CMS）[RFC5652]。依赖传统互联网协议的传统设备将需要更新到适用于受限环境的较新协议，以实现真正的端到端安全。此外，中间盒对数据没有任何访问权限，并且这种方法无法阻止攻击者修改未受保护的相关消息头字段。
To the best of our knowledge, none of the mentioned security approaches that focus on the confidentiality and integrity of the communication exchange between two IP endpoints provide the perfect solution in this problem space.
据我们所知，上述安全方法中没有一种侧重于两个IP端点之间通信交换的机密性和完整性，在这个问题空间中提供了完美的解决方案。
There is a multitude of new link-layer protocols that aim to address the resource-constrained nature of IoT devices. For example, IEEE 802.11ah [IEEE802ah] has been specified for extended range and lower energy consumption to support IoT devices. Similarly, LPWAN protocols such as LoRa [LoRa], Sigfox [sigfox], and NarrowBand IoT (NB-IoT) [NB-IoT] are all designed for resource-constrained devices that require long range and low bit rates. [RFC8376] provides an informational overview of the set of LPWAN technologies being considered by the IETF. It also identifies the potential gaps that exist between the needs of those technologies and the goal of running IP in such networks. While these protocols allow IoT devices to conserve energy and operate efficiently, they also add additional security challenges. For example, the relatively small MTU can make security handshakes with large X509 certificates a significant overhead. At the same time, new communication paradigms also allow IoT devices to communicate directly amongst themselves with or without support from the network. This communication paradigm is also referred to as Device-to-Device (D2D), Machine-to-Machine (M2M), or Thing-to-Thing (T2T) communication, and it is motivated by a number of features such as improved network performance, lower latency, and lower energy requirements.
有许多新的链路层协议，旨在解决物联网设备资源受限的问题。例如，IEEE 802.11ah[IEEE802ah]被指定用于扩展范围和降低能耗，以支持物联网设备。类似地，诸如LoRa[LoRa]、Sigfox[Sigfox]和窄带IoT（NB IoT）[NB IoT]等LPWAN协议都是为需要长距离和低比特率的资源受限设备而设计的。[RFC8376]提供了IETF正在考虑的一组LPWAN技术的信息概述。它还确定了这些技术的需求与在此类网络中运行IP的目标之间存在的潜在差距。虽然这些协议允许物联网设备节约能源并高效运行，但它们也增加了额外的安全挑战。例如，相对较小的MTU会使具有较大X509证书的安全握手成为一项巨大的开销。同时，新的通信模式也允许物联网设备在有或无网络支持的情况下直接相互通信。这种通信模式也被称为设备对设备（D2D）、机器对机器（M2M）或物对物（T2T）通信，其动机是许多特性，例如改进的网络性能、更低的延迟和更低的能量需求。
Creating a security domain from a set of previously unassociated IoT devices is a key operation in the lifecycle of a thing in an IoT network. This aspect is further elaborated and discussed in the T2TRG draft on bootstrapping [BOOTSTRAP].
从一组以前未关联的物联网设备创建安全域是物联网网络中某事物生命周期中的关键操作。T2TRG关于自举[自举]的草案进一步阐述和讨论了这一方面。
After the bootstrapping phase, the system enters the operational phase. During the operational phase, things can use the state information created during the bootstrapping phase in order to exchange information securely. In this section, we discuss the security challenges during the operational phase. Note that many of the challenges discussed in Section 5.1 apply during the operational phase.
在引导阶段之后，系统进入操作阶段。在操作阶段，可以使用在引导阶段创建的状态信息安全地交换信息。在本节中，我们将讨论操作阶段的安全挑战。请注意，第5.1节中讨论的许多挑战适用于运营阶段。
Group-key negotiation is an important security service for IoT communication patterns in which a thing sends some data to multiple things or data flows from multiple things towards a thing. All discussed protocols only cover unicast communication and therefore do not focus on group-key establishment. This applies in particular to (D)TLS and IKEv2. Thus, a solution is required in this area. A potential solution might be to use the Diffie-Hellman keys -- which are used in IKEv2 and HIP to set up a secure unicast link -- for group Diffie-Hellman key negotiations. However, Diffie-Hellman is a relatively heavy solution, especially if the group is large.
组密钥协商是物联网通信模式中的一项重要安全服务，在这种模式中，一个对象向多个对象发送一些数据，或者数据从多个对象流向一个对象。所有讨论的协议只涉及单播通信，因此不关注组密钥的建立。这尤其适用于（D）TLS和IKEv2。因此，这方面需要一个解决方案。一个潜在的解决方案可能是使用Diffie-Hellman密钥（在IKEv2和HIP中用于建立安全的单播链路）进行组Diffie-Hellman密钥协商。然而，Diffie-Hellman是一个相对沉重的解决方案，尤其是当团队规模较大时。
Symmetric and asymmetric keys can be used in group communication. Asymmetric keys have the advantage that they can provide source authentication. However, doing broadcast encryption with a single public/private key pair is also not feasible. Although a single symmetric key can be used to encrypt the communication or compute a message authentication code, it has inherent risks since the capture of a single node can compromise the key shared throughout the network. The usage of symmetric keys also does not provide source authentication. Another factor to consider is that asymmetric cryptography is more resource-intensive than symmetric key solutions. Thus, the security risks and performance trade-offs of applying either symmetric or asymmetric keys to a given IoT use case need to be well analyzed according to risk and usability assessments [RFC8387]. [MULTICAST] is looking at a combination of confidentiality using a group key and source authentication using public keys in the same packet.
对称和非对称密钥可用于组通信。非对称密钥的优点是可以提供源身份验证。但是，使用单个公钥/私钥对进行广播加密也是不可行的。尽管单个对称密钥可用于加密通信或计算消息身份验证码，但由于捕获单个节点可能会破坏整个网络共享的密钥，因此具有固有风险。对称密钥的使用也不提供源身份验证。另一个要考虑的因素是非对称密码学比对称密钥解决方案更具资源密集性。因此，对给定物联网用例应用对称或非对称密钥的安全风险和性能权衡需要根据风险和可用性评估进行充分分析[RFC8387]。[多播]正在研究使用组密钥的保密性和使用同一数据包中的公钥的源身份验证的组合。
Conceptually, solutions that provide secure group communication at the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage in terms of the cryptographic overhead when compared to application-focused security solutions (TLS/DTLS). This is due to the fact that application-focused solutions require cryptographic operations per group application, whereas network-layer approaches may allow sharing secure group associations between multiple applications (for example, for neighbor discovery and routing or service discovery). Hence, implementing shared features lower in the communication stack can avoid redundant security measures. However, it is important to note that sharing security contexts among different applications involves potential security threats, e.g., if one of the applications is malicious and monitors exchanged messages or injects fake messages. In the case of OSCORE, it provides security for CoAP group communication as defined in RFC 7390, i.e., based on multicast IP. If the same security association is reused for each application, then this solution does not seem to have more cryptographic overhead compared to IPsec.
从概念上讲，与以应用程序为中心的安全解决方案（TLS/DTL）相比，在网络层提供安全组通信的解决方案（IPsec/IKEv2，HIP/DITE HIP）在加密开销方面可能具有优势。这是因为以应用程序为中心的解决方案需要对每个组应用程序进行加密操作，而网络层方法可能允许在多个应用程序之间共享安全组关联（例如，用于邻居发现和路由或服务发现）。因此，在通信堆栈的较低位置实现共享功能可以避免冗余的安全措施。但是，需要注意的是，在不同的应用程序之间共享安全上下文涉及潜在的安全威胁，例如，如果其中一个应用程序是恶意的，并且监视交换的消息或注入假消息。在OSCORE的情况下，它为RFC 7390中定义的CoAP组通信提供安全性，即基于多播IP。如果对每个应用程序重复使用相同的安全关联，那么与IPsec相比，此解决方案似乎没有更多的加密开销。
Several group-key solutions have been developed by the MSEC Working Group of the IETF [WG-MSEC]. The MIKEY architecture [RFC4738] is one example. While these solutions are specifically tailored for multicast and group-broadcast applications in the Internet, they should also be considered as candidate solutions for group-key agreement in IoT. The MIKEY architecture, for example, describes a coordinator entity that disseminates symmetric keys over pair-wise end-to-end secured channels. However, such a centralized approach may not be applicable in a distributed IoT environment, where the choice of one or several coordinators and the management of the group key is not trivial.
IETF的MSEC工作组[WG-MSEC]已经开发了若干组关键解决方案。MIKEY架构[RFC4738]就是一个例子。虽然这些解决方案专门针对互联网中的多播和组广播应用而定制，但它们也应被视为物联网中组密钥协议的候选解决方案。例如，MIKEY体系结构描述了一个协调器实体，它通过成对的端到端安全通道传播对称密钥。然而，这种集中式方法可能不适用于分布式物联网环境，因为在分布式物联网环境中，一个或多个协调员的选择和组密钥的管理并非微不足道。
It is expected that many things (for example, user devices and wearable sensors) will be mobile in the sense that they are attached to different networks during the lifetime of a security association. Built-in mobility signaling can greatly reduce the overhead of the cryptographic protocols because unnecessary and costly re-establishments of the session (possibly including handshake and key agreement) can be avoided. IKEv2 supports host mobility with the MOBIKE extension [RFC4555] [RFC4621]. MOBIKE refrains from applying heavyweight cryptographic extensions for mobility. However, MOBIKE mandates the use of IPsec tunnel mode, which requires the transmission of an additional IP header in each packet.
预计许多东西（例如，用户设备和可穿戴传感器）将是移动的，因为它们在安全关联的生命周期内连接到不同的网络。内置的移动性信令可以极大地减少加密协议的开销，因为可以避免不必要和昂贵的会话重建（可能包括握手和密钥协商）。IKEv2通过MOBIKE扩展[RFC4555][RFC4621]支持主机移动性。MOBIKE避免为移动性应用重量级加密扩展。但是，MOBIKE强制使用IPsec隧道模式，这需要在每个数据包中传输额外的IP头。
HIP offers simple yet effective mobility management by allowing hosts to signal changes to their associations [RFC8046]. However, slight adjustments might be necessary to reduce the cryptographic costs -- for example, by making the public key signatures in the mobility messages optional. Diet HIP does not define mobility yet, but it is sufficiently similar to HIP and can use the same mechanisms. DTLS provides some mobility support by relying on a connection ID (CID). The use of connection IDs can provide all the mobility functionality described in [Williams] except sending the updated location. The specific need for IP-layer mobility mainly depends on the scenario in which the nodes operate. In many cases, mobility supported by means of a mobile gateway may suffice to enable mobile IoT networks, such as body-sensor networks. Using message-based application-layer security solutions such as OSCORE [OSCORE] can also alleviate the problem of re-establishing lower-layer sessions for mobile nodes.
HIP允许主机向其关联发送更改信号，从而提供简单而有效的移动性管理[RFC8046]。然而，为了降低加密成本，可能需要进行一些细微的调整——例如，通过使移动消息中的公钥签名成为可选的。饮食髋关节尚未定义活动性，但它与髋关节非常相似，可以使用相同的机制。DTLS依靠连接ID（CID）提供一些移动性支持。使用连接ID可以提供[Williams]中描述的所有移动功能，但发送更新的位置除外。IP层移动性的具体需求主要取决于节点运行的场景。在许多情况下，通过移动网关支持的移动性可能足以实现移动物联网网络，例如身体传感器网络。使用基于消息的应用层安全解决方案，如OSCORE[OSCORE]，还可以缓解为移动节点重新建立低层会话的问题。
IoT devices are often expected to stay functional for several years or decades, even though they might operate unattended with direct Internet connectivity. Software updates for IoT devices are therefore required not only for new functionality but also to
物联网设备通常会在几年或几十年内保持功能，即使它们可能在无人值守的情况下直接连接互联网。因此，物联网设备的软件更新不仅需要新功能，还需要
eliminate security vulnerabilities due to software bugs, design flaws, or deprecated algorithms. Software bugs might remain even after careful code review. Implementations of security protocols might contain (design) flaws. Cryptographic algorithms can also become insecure due to advances in cryptanalysis. Therefore, it is necessary that devices that are incapable of verifying a cryptographic signature are not exposed to the Internet, even indirectly.
消除由于软件缺陷、设计缺陷或不推荐的算法而导致的安全漏洞。即使经过仔细的代码审查，软件错误也可能仍然存在。安全协议的实现可能包含（设计）缺陷。由于密码分析的进步，密码算法也可能变得不安全。因此，有必要使不能验证密码签名的设备不暴露于因特网，甚至是间接暴露于因特网。
In his essay, Schneier highlights several challenges that hinder mechanisms for secure software update of IoT devices [SchneierSecurity]. First, there is a lack of incentives for manufacturers, vendors, and others on the supply chain to issue updates for their devices. Second, parts of the software running on IoT devices is simply a binary blob without any source code available. Since the complete source code is not available, no patches can be written for that piece of code. Lastly, Schneier points out that even when updates are available, users generally have to manually download and install them. However, users are never alerted about security updates, and many times do not have the necessary expertise to manually administer the required updates.
在他的论文中，Schneier强调了阻碍物联网设备安全软件更新机制的几个挑战[SchneierSecurity]。首先，制造商、供应商和供应链上的其他人缺乏为其设备发布更新的激励。其次，在物联网设备上运行的部分软件只是一个二进制blob，没有任何可用的源代码。由于没有完整的源代码，因此无法为该代码编写修补程序。最后，Schneier指出，即使更新可用，用户通常也必须手动下载并安装它们。但是，用户从未收到有关安全更新的警报，并且很多时候没有必要的专业知识来手动管理所需的更新。
The US Federal Trade Commission (FTC) staff report on "Internet of Things - Privacy & Security in a Connected World" [FTCreport] and the Article 29 Working Party's "Opinion 8/2014 on the Recent Developments on the Internet of Things" [Article29] also document the challenges for secure remote software update of IoT devices. They note that even providing such a software-update capability may add new vulnerabilities for constrained devices. For example, a buffer overflow vulnerability in the implementation of a software update protocol (TR69) [TR69] and an expired certificate in a hub device [wink] demonstrate how the software-update process itself can introduce vulnerabilities.
美国联邦贸易委员会（FTC）工作人员关于“物联网——互联世界中的隐私与安全”的报告[FTCreport]和第29条工作组的“2014年8月关于物联网最新发展的意见”[第29条]也记录了物联网设备安全远程软件更新的挑战。他们指出，即使提供这样的软件更新功能，也可能为受约束的设备增加新的漏洞。例如，软件更新协议（TR69）[TR69]实现中的缓冲区溢出漏洞和集线器设备[wink]中的过期证书说明了软件更新过程本身如何引入漏洞。
Powerful IoT devices that run general-purpose operating systems can make use of sophisticated software-update mechanisms known from the desktop world. However, resource-constrained devices typically do not have any operating system and are often not equipped with a memory management unit or similar tools. Therefore, they might require more specialized solutions.
运行通用操作系统的强大物联网设备可以利用桌面世界已知的复杂软件更新机制。然而，资源受限的设备通常没有任何操作系统，并且通常没有配备内存管理单元或类似工具。因此，它们可能需要更专门的解决方案。
An important requirement for secure software and firmware updates is source authentication. Source authentication requires the resource-constrained things to implement public key signature verification algorithms. As stated in Section 5.1.1, resource-constrained things have limited computational capabilities and energy supply available, which can hinder the amount and frequency of cryptographic processing that they can perform. In addition to source authentication,
安全软件和固件更新的一个重要要求是源身份验证。源认证需要资源受限的东西来实现公钥签名验证算法。如第5.1.1节所述，资源受限的事物具有有限的计算能力和可用的能量供应，这可能会阻碍它们可以执行的加密处理的数量和频率。除了源身份验证，
software updates might require confidential delivery over a secure (encrypted) channel. The complexity of broadcast encryption can force the usage of point-to-point secure links; however, this increases the duration of a software update in a large system. Alternatively, it may force the usage of solutions in which the software update is delivered to a gateway and then distributed to the rest of the system with a network key. Sending large amounts of data that later needs to be assembled and verified over a secure channel can consume a lot of energy and computational resources. Correct scheduling of the software updates is also a crucial design challenge. For example, a user of connected light bulbs would not want them to update and restart at night. More importantly, the user would not want all the lights to update at the same time.
软件更新可能需要通过安全（加密）通道进行保密传输。广播加密的复杂性会迫使使用点对点安全链路；但是，这会增加大型系统中软件更新的持续时间。或者，它可能会强制使用解决方案，其中软件更新被传送到网关，然后使用网络密钥分发到系统的其余部分。通过安全通道发送大量稍后需要组装和验证的数据可能会消耗大量能源和计算资源。软件更新的正确调度也是一个关键的设计挑战。例如，已连接灯泡的用户不希望它们在夜间更新和重新启动。更重要的是，用户不希望所有灯光同时更新。
Software updates in IoT systems are also needed to update old and insecure cryptographic primitives. However, many IoT systems, some of which are already deployed, are not designed with provisions for cryptographic agility. For example, many devices come with a wireless radio that has an AES128 hardware coprocessor. These devices solely rely on the coprocessor for encrypting and authenticating messages. A software update adding support for new cryptographic algorithms implemented solely in software might not fit on these devices due to limited memory, or might drastically hinder its operational performance. This can lead to the use of old and insecure software. Therefore, it is important to account for the fact that cryptographic algorithms would need to be updated and consider the following when planning for cryptographic agility:
物联网系统中的软件更新也需要更新旧的和不安全的加密原语。然而，许多物联网系统（其中一些已经部署）的设计并未提供加密灵活性。例如，许多设备都配有带有AES128硬件协处理器的无线收音机。这些设备仅依赖协处理器对消息进行加密和身份验证。由于内存有限，添加对仅在软件中实现的新加密算法的支持的软件更新可能不适合这些设备，或者可能会严重影响其操作性能。这可能导致使用旧的和不安全的软件。因此，重要的是要考虑的事实是，密码算法将需要更新，并考虑以下规划时的密码灵活性：
1. Would it be secure to use the existing cryptographic algorithms available on the device for updating with new cryptographic algorithms that are more secure?
1. 使用设备上现有的加密算法进行更新时使用更安全的新加密算法是否安全？
2. Will the new software-based implementation fit on the device given the limited resources?
2. 在资源有限的情况下，基于软件的新实现是否适合设备？
3. Would the normal operation of existing IoT applications on the device be severely hindered by the update?
3. 更新是否会严重阻碍设备上现有物联网应用程序的正常运行？
Finally, we would like to highlight the previous and ongoing work in the area of secure software and firmware updates at the IETF. [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652] can be used to protect firmware packages. The IAB has also organized a workshop to understand the challenges for secure software update of IoT devices. A summary of the recommendations to the standards community derived from the discussions during that workshop have been documented [RFC8240]. A working group called Software Updates for Internet of Things (SUIT) [WG-SUIT] is currently working on a new specification to reflect the best current practices for firmware
最后，我们想强调IETF在安全软件和固件更新领域的先前和正在进行的工作。[RFC4108]描述了如何使用加密消息语法（CMS）[RFC5652]来保护固件软件包。IAB还组织了一次研讨会，以了解物联网设备安全软件更新的挑战。从研讨会期间的讨论中得出的对标准团体的建议摘要已记录在案[RFC8240]。一个名为物联网软件更新（SOUT）[WG-SOUT]的工作组目前正在制定一个新的规范，以反映固件的最佳实践
update based on experience from IoT deployments. It is specifically working on describing an IoT firmware update architecture and specifying a manifest format that contains metadata about the firmware update package. Finally, the Trusted Execution Environment Provisioning Working Group [WG-TEEP] aims at developing a protocol for lifecycle management of trusted applications running on the secure area of a processor (Trusted Execution Environment (TEE)).
根据物联网部署的经验进行更新。它专门致力于描述物联网固件更新体系结构，并指定包含固件更新包元数据的清单格式。最后，Trusted Execution Environment Provisioning Working Group[WG-TEEP]旨在开发一种协议，用于在处理器的安全区域（Trusted Execution Environment（TEE））上运行的可信应用程序的生命周期管理。
Like all commercial devices, IoT devices have a given useful lifetime. The term "end-of-life" (EOL) is used by vendors or network operators to indicate the point of time at which they limit or end support for the IoT device. This may be planned or unplanned (for example, when the manufacturer goes bankrupt, the vendor just decides to abandon a product, or a network operator moves to a different type of networking technology). A user should still be able to use and perhaps even update the device. This requires for some form of authorization handover.
与所有商用设备一样，物联网设备也有特定的使用寿命。供应商或网络运营商使用术语“寿命终止”（EOL）来表示他们限制或终止对物联网设备的支持的时间点。这可能是有计划的，也可能是无计划的（例如，当制造商破产时，供应商只是决定放弃产品，或者网络运营商转向不同类型的网络技术）。用户应该仍然能够使用甚至更新设备。这需要某种形式的授权移交。
Although this may seem far-fetched given the commercial interests and market dynamics, we have examples from the mobile world where the devices have been functional and up to date long after the original vendor stopped supporting the device. CyanogenMod for Android devices and OpenWrt for home routers are two such instances where users have been able to use and update their devices even after the official EOL. Admittedly, it is not easy for an average user to install and configure their devices on their own. With the deployment of millions of IoT devices, simpler mechanisms are needed to allow users to add new trust anchors [RFC6024] and install software and firmware from other sources once the device is EOL.
尽管考虑到商业利益和市场动态，这似乎有些牵强，但我们有一些来自移动世界的例子，在原始供应商停止支持该设备很久之后，这些设备就已经具备了功能，并且是最新的。Android设备的CyanogenMod和家用路由器的OpenWrt就是这样的两个例子，在这两个例子中，用户即使在正式下线后也能够使用和更新他们的设备。诚然，普通用户自己安装和配置设备并不容易。随着数百万IoT设备的部署，需要更简单的机制来允许用户添加新的信任锚[RFC6024]，并在设备下线后从其他来源安装软件和固件。
Users using new IoT appliances such as Internet-connected smart televisions, speakers, and cameras are often unaware that these devices can undermine their privacy. Recent revelations have shown that many IoT device vendors have been collecting sensitive private data through these connected appliances with or without appropriate user warnings [cctv].
使用新型物联网设备（如互联网连接的智能电视、扬声器和摄像头）的用户通常不知道这些设备会破坏他们的隐私。最近的披露表明，许多物联网设备供应商一直在通过这些连接的设备收集敏感的私人数据，无论是否有适当的用户警告[cctv]。
An IoT device's user/owner would like to monitor and verify its operational behavior. For instance, the user might want to know if the device is connecting to the server of the manufacturer for any reason. This feature -- connecting to the manufacturer's server -- may be necessary in some scenarios, such as during the initial configuration of the device. However, the user should be kept aware
物联网设备的用户/所有者希望监控和验证其操作行为。例如，用户可能想知道设备是否出于任何原因连接到制造商的服务器。此功能（连接到制造商的服务器）在某些情况下可能是必需的，例如在设备的初始配置期间。但是，用户应该保持警惕
of the data that the device is sending back to the vendor. For example, the user might want to know if his/her TV is sending data when he/she inserts a new USB stick.
设备发送回供应商的数据。例如，当用户插入新的U盘时，可能想知道他/她的电视是否正在发送数据。
Providing such information to the users in an understandable fashion is challenging. This is because IoT devices are not only resource constrained in terms of their computational capability but also in terms of the user interface available. Also, the network infrastructure where these devices are deployed will vary significantly from one user environment to another. Therefore, where and how this monitoring feature is implemented still remains an open question.
以可理解的方式向用户提供此类信息具有挑战性。这是因为物联网设备不仅在计算能力方面受到资源限制，而且在可用的用户界面方面也受到资源限制。此外，部署这些设备的网络基础设施在不同的用户环境中也会有很大差异。因此，在何处以及如何实现此监控功能仍然是一个悬而未决的问题。
Manufacturer Usage Description (MUD) files [RFC8520] are perhaps a first step towards implementation of such a monitoring service. The idea behind MUD files is relatively simple: IoT devices would disclose the location of their MUD file to the network during installation. The network can then retrieve those files and learn about the intended behavior of the devices stated by the device manufacturer. A network-monitoring service could then warn the user/ owner of devices if they don't behave as expected.
制造商使用说明（MUD）文件[RFC8520]可能是实现此类监控服务的第一步。MUD文件背后的想法相对简单：物联网设备将在安装期间向网络披露其MUD文件的位置。然后，网络可以检索这些文件并了解设备制造商声明的设备的预期行为。然后，网络监控服务可以警告设备的用户/所有者，如果它们的行为不符合预期。
Many devices and software services that automatically learn and monitor the behavior of different IoT devices in a given network are commercially available. Such monitoring devices/services can be configured by the user to limit network traffic and trigger alarms when unexpected operation of IoT devices is detected.
许多自动学习和监控给定网络中不同物联网设备行为的设备和软件服务都可以在市场上买到。用户可以配置此类监控设备/服务，以限制网络流量，并在检测到物联网设备的意外操作时触发警报。
Given that IoT devices often have inadvertent vulnerabilities, both users and developers would want to perform extensive testing on their IoT devices, networks, and systems. Nonetheless, since the devices are resource constrained and manufactured by multiple vendors, some of them very small, devices might be shipped with very limited testing, so that bugs can remain and can be exploited at a later stage. This leads to two main types of challenges:
鉴于物联网设备通常存在无意中的漏洞，用户和开发人员都希望在其物联网设备、网络和系统上执行广泛的测试。尽管如此，由于设备资源有限，且由多家供应商生产，其中一些供应商非常小，因此设备可能会附带非常有限的测试，因此缺陷可能会保留下来，并可在稍后阶段加以利用。这导致了两种主要类型的挑战：
1. It remains to be seen how the software-testing and quality-assurance mechanisms used from the desktop and mobile world will be applied to IoT devices to give end users the confidence that the purchased devices are robust. Bodies such as the European Cyber Security Organization (ECSO) [ECSO] are working on processes for security certification of IoT devices.
1. 桌面和移动世界使用的软件测试和质量保证机制将如何应用于物联网设备，以使最终用户相信购买的设备是可靠的，这还有待观察。欧洲网络安全组织（ECSO）[ECSO]等机构正在制定物联网设备的安全认证流程。
2. It is also an open question how the combination of devices from multiple vendors might actually lead to dangerous network configurations -- for example, if the combination of specific
2. 这也是一个悬而未决的问题，来自多个供应商的设备组合如何实际导致危险的网络配置——例如，如果
devices can trigger unexpected behavior. It is needless to say that the security of the whole system is limited by its weakest point.
设备可能触发意外行为。不用说，整个系统的安全性受到其最薄弱环节的限制。
Many IoT systems that are being deployed today will remain operational for many years. With the advancements made in the field of quantum computers, it is possible that large-scale quantum computers will be available in the future for performing cryptanalysis on existing cryptographic algorithms and cipher suites. If this happens, it will have two consequences. First, functionalities enabled by means of primitives such as RSA or ECC -- namely, key exchange, public key encryption, and signature -- would not be secure anymore due to Shor's algorithm. Second, the security level of symmetric algorithms will decrease, for example, the security of a block cipher with a key size of b bits will only offer b/2 bits of security due to Grover's algorithm.
目前正在部署的许多物联网系统将保持运行多年。随着量子计算机领域的进步，未来将有可能使用大规模量子计算机对现有密码算法和密码套件进行密码分析。如果发生这种情况，将产生两个后果。首先，通过RSA或ECC等原语实现的功能——即密钥交换、公钥加密和签名——由于Shor的算法，将不再安全。其次，对称算法的安全级别将降低，例如，由于Grover算法，密钥大小为b位的分组密码的安全性将仅提供b/2位的安全性。
The above scenario becomes more urgent when we consider the so-called "harvest and decrypt" attack in which an attacker can start to harvest (store) encrypted data today, before a quantum computer is available, and decrypt it years later, once a quantum computer is available. Such "harvest and decrypt" attacks are not new and were used in the VENONA project [venona-project]. Many IoT devices that are being deployed today will remain operational for a decade or even longer. During this time, digital signatures used to sign software updates might become obsolete, making the secure update of IoT devices challenging.
当我们考虑一个所谓的“收获和解密”攻击时，上述情况变得更加紧急，攻击者可以在量子计算机可用之前开始收集（存储）加密数据，并且在量子计算机可用之后再解密它。这种“捕获和解密”攻击并不是新的攻击，在VENONA项目[VENONA project]中使用过。今天部署的许多物联网设备将在十年甚至更长时间内保持运行。在此期间，用于签署软件更新的数字签名可能会过时，这使得物联网设备的安全更新具有挑战性。
This situation would require us to move to quantum-resistant alternatives -- in particular, for those functionalities involving key exchange, public key encryption, and signatures. [C2PQ] describes when quantum computers may become widely available and what steps are necessary for transitioning to cryptographic algorithms that provide security even in the presence of quantum computers. While future planning is hard, it may be a necessity in certain critical IoT deployments that are expected to last decades or more. Although increasing the key size of the different algorithms is definitely an option, it would also incur additional computational overhead and network traffic. This would be undesirable in most scenarios. There have been recent advancements in quantum-resistant cryptography. We refer to [ETSI-GR-QSC-001] for an extensive overview of existing quantum-resistant cryptography, and [RFC7696] provides guidelines for cryptographic algorithm agility.
这种情况需要我们转向量子抵抗的替代方案——特别是涉及密钥交换、公钥加密和签名的功能。[C2PQ]描述了量子计算机何时可以广泛使用，以及过渡到加密算法（即使在量子计算机存在的情况下也能提供安全性）所需的步骤。虽然未来规划很困难，但在某些预计将持续数十年或更长时间的关键物联网部署中，这可能是必要的。虽然增加不同算法的密钥大小肯定是一种选择，但它也会带来额外的计算开销和网络流量。这在大多数情况下都是不可取的。抗量子密码学最近取得了一些进展。我们参考[ETSI-GR-QSC-001]对现有抗量子密码术进行了全面概述，[RFC7696]提供了密码算法灵活性的指南。
People will eventually be surrounded by hundreds of connected IoT devices. Even if the communication links are encrypted and protected, information about people might still be collected or processed for different purposes. The fact that IoT devices in the vicinity of people might enable more pervasive monitoring can negatively impact their privacy. For instance, imagine the scenario where a static presence sensor emits a packet due to the presence or absence of people in its vicinity. In such a scenario, anyone who can observe the packet can gather critical privacy-sensitive information.
人们最终将被数百台联网的物联网设备包围。即使通信链路被加密和保护，人们的信息仍可能出于不同的目的被收集或处理。人们附近的物联网设备可能实现更普遍的监控，这一事实可能会对他们的隐私产生负面影响。例如，想象一下这样的场景：静态存在传感器由于其附近是否有人而发射数据包。在这种情况下，任何能够观察数据包的人都可以收集关键的隐私敏感信息。
Such information about people is referred to as personal data in the European Union (EU) or Personally identifiable information (PII) in the US. In particular, the General Data Protection Regulation (GDPR) [GDPR] defines personal data as: "any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person".
此类人员信息在欧盟（EU）称为个人数据，在美国称为个人识别信息（PII）。具体而言，《通用数据保护条例》（GDPR）[GDPR]将个人数据定义为：“与已识别或可识别自然人（“数据主体”）相关的任何信息。”；可识别自然人是指可直接或间接识别的自然人，特别是通过参考标识符（如姓名、识别号、位置数据、在线标识符）或特定于该自然人的身体、生理、遗传、心理、经济、文化或社会身份的一个或多个因素“约翰逊”。
Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold guarantee:
Ziegeldorf[Ziegeldorf]将物联网中的隐私定义为三重保证：
1. Awareness of the privacy risks imposed by IoT devices and services. This awareness is achieved by means of transparent practices by the data controller, i.e., the entity that is providing IoT devices and/or services.
1. 了解物联网设备和服务带来的隐私风险。这种意识是通过数据控制器（即提供物联网设备和/或服务的实体）的透明实践实现的。
2. Individual control over the collection and processing of personal information by IoT devices and services.
2. 对物联网设备和服务收集和处理个人信息的个人控制。
3. Awareness and control of the subsequent use and dissemination of personal information by data controllers to any entity outside the subject's personal control sphere. This point implies that the data controller must be accountable for its actions on the personal information.
3. 了解并控制数据控制员随后向受试者个人控制范围以外的任何实体使用和传播个人信息。这一点意味着数据控制者必须对其对个人信息的行为负责。
Based on this definition, several threats to the privacy of users have been documented [Ziegeldorf] [RFC6973], in particular considering the IoT environment and its lifecycle:
根据这一定义，记录了对用户隐私的几种威胁[Ziegeldorf][RFC6973]，特别是考虑到物联网环境及其生命周期：
1. Identification - refers to the identification of the users, their IoT devices, and generated data.
1. 标识-指用户、其物联网设备和生成数据的标识。
2. Localization - relates to the capability of locating a user and even tracking them, e.g., by tracking MAC addresses in Wi-Fi or Bluetooth.
2. 本地化-与定位用户甚至跟踪用户的能力有关，例如通过跟踪Wi-Fi或蓝牙中的MAC地址。
3. Profiling - is about creating a profile of the user and their preferences.
3. 评测-是关于创建用户及其首选项的评测。
4. Interaction - occurs when a user has been profiled and a given interaction is preferred, presenting (for example, visually) some information that discloses private information.
4. 交互-当用户已被分析并且首选给定的交互时发生，呈现（例如，视觉）一些公开私人信息的信息。
5. Lifecycle transitions - take place when devices are, for example, sold without properly removing private data.
5. 生命周期转换—例如，在出售设备时未正确删除私有数据。
6. Inventory attacks - happen if specific information about IoT devices in possession of a user is disclosed.
6. 库存攻击-如果用户拥有的物联网设备的特定信息被披露，则会发生库存攻击。
7. Linkage - is about when information of two of more IoT systems (or other data sets) is combined so that a broader view of the personal data captured can be created.
7. 链接-是指何时将两个或两个以上物联网系统（或其他数据集）的信息组合在一起，以便能够创建捕获的个人数据的更广泛视图。
When IoT systems are deployed, the above issues should be considered to ensure that private data remains private. These issues are particularly challenging in environments in which multiple users with different privacy preferences interact with the same IoT devices. For example, an IoT device controlled by user A (low privacy settings) might leak private information about another user B (high privacy settings). How to deal with these threats in practice is an area of ongoing research.
部署物联网系统时，应考虑上述问题，以确保私有数据保持私有。在具有不同隐私偏好的多个用户与同一物联网设备交互的环境中，这些问题尤其具有挑战性。例如，由用户A（低隐私设置）控制的物联网设备可能泄漏关于另一用户B的隐私信息（高隐私设置）。如何在实践中应对这些威胁是一个正在进行的研究领域。
Many IoT devices are resource constrained and often deployed in unattended environments. Some of these devices can also be purchased off the shelf or online without any credential-provisioning process. Therefore, an attacker can have direct access to the device and apply advanced techniques to retrieve information that a traditional black-box model does not consider. Examples of those techniques are side-channel attacks or code disassembly. By doing this, the attacker can try to retrieve data such as:
许多物联网设备资源有限，通常部署在无人值守的环境中。这些设备中的一些还可以在没有任何凭证设置过程的情况下从现货或在线购买。因此，攻击者可以直接访问该设备并应用高级技术来检索传统黑箱模型不考虑的信息。这些技术的例子是侧通道攻击或代码反汇编。通过执行此操作，攻击者可以尝试检索以下数据：
1. Long-term keys. These long-term keys can be extracted by means of a side-channel attack or reverse engineering. If these keys are exposed, then they might be used to perform attacks on devices deployed in other locations.
1. 长期键。这些长期密钥可以通过侧通道攻击或反向工程的方式提取。如果这些密钥被公开，那么它们可能被用于对部署在其他位置的设备执行攻击。
2. Source code. Extraction of source code might allow the attacker to determine bugs or find exploits to perform other types of attacks. The attacker might also just sell the source code.
2. 源代码。提取源代码可能使攻击者能够确定bug或发现利用漏洞执行其他类型的攻击。攻击者也可能只是出售源代码。
3. Proprietary algorithms. The attacker can analyze these algorithms gaining valuable know-how. The attacker can also create copies of the product (based on those proprietary algorithms) or modify the algorithms to perform more advanced attacks.
3. 专有算法。攻击者可以分析这些算法，从而获得有价值的专有技术。攻击者还可以创建产品的副本（基于这些专有算法）或修改算法以执行更高级的攻击。
4. Configuration or personal data. The attacker might be able to read personal data, e.g., healthcare data, that has been stored on a device.
4. 配置或个人数据。攻击者可能能够读取存储在设备上的个人数据，例如医疗保健数据。
One existing solution to prevent such data leaks is the use of a secure element, a tamper-resistant device that is capable of securely hosting applications and their confidential data. Another potential solution is the usage of a Physical Unclonable Function (PUF) that serves as unique digital fingerprint of a hardware device. PUFs can also enable other functionalities such as secure key storage. Protection against such data leakage patterns is not trivial since devices are inherently resource-constrained. An open question is whether there are any viable techniques to protect IoT devices and the data in the devices in such an adversarial model.
防止此类数据泄漏的一个现有解决方案是使用安全元素，这是一种能够安全托管应用程序及其机密数据的防篡改设备。另一个潜在的解决方案是使用物理不可压缩功能（PUF），作为硬件设备的唯一数字指纹。PUFs还可以启用其他功能，如安全密钥存储。针对这种数据泄漏模式的保护并非微不足道，因为设备本身就是资源受限的。一个悬而未决的问题是，在这种对抗模式下，是否存在任何可行的技术来保护物联网设备和设备中的数据。
Flaws in the design and implementation of IoT devices and networks can lead to security vulnerabilities. A common flaw is the use of well-known or easy-to-guess passwords for configuration of IoT devices. Many such compromised IoT devices can be found on the Internet by means of tools such as Shodan [shodan]. Once discovered, these compromised devices can be exploited at scale -- for example, to launch DDoS attacks. Dyn, a major DNS service provider, was attacked by means of a DDoS attack originating from a large IoT botnet composed of thousands of compromised IP cameras [Dyn-Attack]. There are several open research questions in this area:
物联网设备和网络的设计和实施缺陷可能导致安全漏洞。一个常见的缺陷是使用众所周知或易于猜测的密码配置物联网设备。通过Shodan[Shodan]等工具，可以在互联网上找到许多此类受损物联网设备。一旦被发现，这些被破坏的设备可以被大规模利用——例如，发动DDoS攻击。Dyn是一家主要的DNS服务提供商，受到来自由数千个受损IP摄像头组成的大型物联网僵尸网络的DDoS攻击[Dyn攻击]。在这一领域有几个公开的研究问题：
1. How to avoid vulnerabilities in IoT devices that can lead to large-scale attacks?
1. 如何避免物联网设备中可能导致大规模攻击的漏洞？
2. How to detect sophisticated attacks against IoT devices?
2. 如何检测针对物联网设备的复杂攻击？
3. How to prevent attackers from exploiting known vulnerabilities at a large scale?
3. 如何防止攻击者大规模利用已知漏洞？
Some ideas are being explored to address this issue. One of the approaches relies on the use of Manufacturer Usage Description (MUD) files [RFC8520]. As explained earlier, this proposal requires IoT devices to disclose the location of their MUD file to the network during installation. The network can then (i) retrieve those files, (ii) learn from the manufacturers the intended usage of the devices (for example, which services they need to access), and then (iii) create suitable filters and firewall rules.
目前正在探讨解决这一问题的一些想法。其中一种方法依赖于使用制造商使用说明（MUD）文件[RFC8520]。如前所述，该提案要求物联网设备在安装期间向网络披露其MUD文件的位置。然后，网络可以（i）检索这些文件，（ii）向制造商了解设备的预期用途（例如，他们需要访问哪些服务），然后（iii）创建合适的过滤器和防火墙规则。
This document provides IoT security researchers, system designers, and implementers with an overview of security requirements in the IP-based Internet of Things. We discuss the security threats, state of the art, and challenges.
本文档为物联网安全研究人员、系统设计师和实施者提供了基于IP的物联网安全需求概述。我们讨论安全威胁、最新技术和挑战。
Although plenty of steps have been realized during the last few years (summarized in Section 4.1) and many organizations are publishing general recommendations describing how IoT should be secured (Section 4.3), there are many challenges ahead that require further attention. Challenges of particular importance are bootstrapping of security, group security, secure software updates, long-term security and quantum-resistance, privacy protection, data leakage prevention -- where data could be cryptographic keys, personal data, or even algorithms -- and ensuring trustworthy IoT operation.
尽管在过去几年中已经实现了许多步骤（第4.1节进行了总结），并且许多组织正在发布关于如何保护物联网的一般性建议（第4.3节），但前面还有许多挑战需要进一步关注。特别重要的挑战是安全引导、组安全、安全软件更新、长期安全和量子电阻、隐私保护、数据泄漏预防（其中数据可能是加密密钥、个人数据甚至算法）以及确保可靠的物联网操作。
Authors of new IoT specifications and implementers need to consider how all the security challenges discussed in this document (and those that emerge later) affect their work. The authors of IoT specifications need to put in a real effort towards not only addressing the security challenges but also clearly documenting how the security challenges are addressed. This would reduce the chances of security vulnerabilities in the code written by implementers of those specifications.
新的IOT规范和实施者的作者需要考虑文档中讨论的所有安全挑战（以及后来出现的所有安全挑战）如何影响它们的工作。物联网规范的作者需要投入真正的努力，不仅要解决安全挑战，还要清楚地记录安全挑战是如何解决的。这将减少这些规范的实现者编写的代码中出现安全漏洞的可能性。
This entire memo deals with security issues.
整个备忘录涉及安全问题。
This document has no IANA actions.
本文档没有IANA操作。
[ACE-DTLS] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, draft-ietf-ace-dtls-authorize-08, April 2019.
[ACE-DTLS]Gerdes，S.，Bergmann，O.，Bormann，C.，Selander，G.，和L.Seitz，“受约束环境（ACE）认证和授权的数据报传输层安全（DTLS）配置文件”，正在进行的工作，草案-ietf-ACE-DTLS-AUTHORAY-082019年4月。
[ACE-OAuth] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace-oauth-authz-24, March 2019.
[ACE OAuth]Seitz，L.，Selander，G.，Wahlstroem，E.，Erdtman，S.，和H.Tschofenig，“使用OAuth 2.0框架（ACE OAuth）的受限环境认证和授权（ACE）”，正在进行中的工作，草案-ietf-ACE-OAuth-authz-242019年3月。
[ARCH-6TiSCH] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-20, March 2019.
[ARCH-6TiSCH]Thubert，P.，“基于IEEE 802.15.4 TSCH模式的IPv6架构”，正在进行的工作，草案-ietf-6TiSCH-Architecture-20，2019年3月。
[Article29] Article 29 Data Protection Working Party, "Opinion 8/2014 on the Recent Developments on the Internet of Things", WP 223, September 2014, <https://ec.europa.eu/justice/ article-29/documentation/opinion-recommendation/files/2014/wp223_en.pdf>.
[第29条]第29条数据保护工作组，“关于物联网最新发展的第8/2014号意见”，WP 223，2014年9月<https://ec.europa.eu/justice/ 第29条/文件/意见建议/文件/2014/wp223_en.pdf>。
[AUTO-ID] "Auto-ID Labs", September 2010, <https://www.autoidlabs.org/>.
[自动识别]“自动识别实验室”，2010年9月<https://www.autoidlabs.org/>.
[BACNET] American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), "BACnet", February 2011, <http://www.bacnet.org>.
[BACNET]美国采暖、制冷和空调工程师协会（ASHRAE），“BACNET”，2011年2月<http://www.bacnet.org>.
[BITAG] Broadband Internet Technical Advisory Group, "Internet of Things (IoT) Security and Privacy Recommendations", November 2016, <https://www.bitag.org/report-internet-of-things-security-privacy-recommendations.php>.
[BITAG]宽带互联网技术咨询小组，“物联网（IoT）安全和隐私建议”，2016年11月<https://www.bitag.org/report-internet-of-things-security-privacy-recommendations.php>.
[BOOTSTRAP] Sarikaya, B., Sethi, M., and D. Garcia-Carillo, "Secure IoT Bootstrapping: A Survey", Work in Progress, draft-sarikaya-t2trg-sbootstrapping-06, January 2019.
[引导]Sarikaya，B.，Sethi，M.，和D.Garcia Carillo，“安全物联网引导：调查”，正在进行的工作，草稿-Sarikaya-t2trg-sbootstrapping-062019年1月。
[C2PQ] Hoffman, P., "The Transition from Classical to Post-Quantum Cryptography", Work in Progress, draft-hoffman-c2pq-04, August 2018.
[C2PQ]Hoffman，P.，“从经典到后量子密码学的过渡”，正在进行的工作，草稿-Hoffman-C2PQ-042018年8月。
[cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an Email Address In China", February 2016, <https://hardware.slashdot.org/story/16/02/17/0422259/ backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an-email-address-in-china>.
[cctv]“MVPower DVR固件中的后门将cctv剧照发送到中国的电子邮件地址”，2016年2月<https://hardware.slashdot.org/story/16/02/17/0422259/ mvpower dvr固件中的后门将cctv剧照发送到中国的电子邮件地址>。
[ChaCha] Bernstein, D., "ChaCha, a variant of Salsa20", January 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.
[ChaCha]Bernstein，D.，“ChaCha，Salsa20的变体”，2008年1月<http://cr.yp.to/chacha/chacha-20080128.pdf>.
[CSA] Cloud Security Alliance Mobile Working Group, "Security Guidance for Early Adopters of the Internet of Things (IoT)", April 2015, <https://downloads.cloudsecurityalliance.org/whitepapers/S ecurity_Guidance_for_Early_Adopters_of_the_Internet_of_Thi ngs.pdf>.
[CSA]云安全联盟移动工作组，“物联网（IoT）早期采用者安全指南”，2015年4月<https://downloads.cloudsecurityalliance.org/whitepapers/S 安全指南\u针对早期采用者\u互联网\u内容。pdf>。
[DALI] DALIbyDesign, "DALI Explained", February 2011, <http://www.dalibydesign.us/dali.html>.
[DALI]Daliby设计，“DALI解释”，2011年2月<http://www.dalibydesign.us/dali.html>.
[Daniel] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", Work in Progress, draft-daniel-6lowpan-security-analysis-05, March 2011.
[Daniel]Park，S.，Kim，K.，Haddad，W.，Chakrabarti，S.，和J.Laganier，“低功耗WPAN上的IPv6安全分析”，正在进行的工作，草稿-Daniel-6lowpan-Security-Analysis-052011年3月。
[DCMS] UK Department for Digital Culture, Media & Sport, "Secure by Design: Improving the cyber security of consumer Internet of Things Report", March 2018, <https://www.gov.uk/government/publications/ secure-by-design-report>.
[DCMS]英国数字文化、媒体和体育部，“设计安全：提高消费者物联网报告的网络安全”，2018年3月<https://www.gov.uk/government/publications/ 按设计报告>进行安全保护。
[DHS] U.S. Department of Homeland Security, "Strategic
Principles For Securing the Internet of Things (IoT)",
November 2016,
<https://www.dhs.gov/sites/default/files/publications/
Strategic_Principles_for_Securing_the_Internet_of_Things-
2016-1115-FINAL....pdf>.
[DHS] U.S. Department of Homeland Security, "Strategic
Principles For Securing the Internet of Things (IoT)",
November 2016,
<https://www.dhs.gov/sites/default/files/publications/
Strategic_Principles_for_Securing_the_Internet_of_Things-
2016-1115-FINAL....pdf>.
[Diet-ESP] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression and Diet-ESP", Work in Progress, draft-mglt-ipsecme-diet-esp-07, March 2019.
[饮食ESP]Migault，D.，Guggemos，T.，Bormann，C.，和D.Schinazi，“ESP封头压缩和饮食ESP”，正在进行的工作，草稿-mglt-ipsecme-Diet-ESP-072019年3月。
[Dyn-Attack] Oracle Dyn, "Dyn Analysis Summary Of Friday October 21 Attack", October 2016, <https://dyn.com/blog/ dyn-analysis-summary-of-friday-october-21-attack/>.
[Dyn攻击]Oracle Dyn，“10月21日星期五攻击的Dyn分析摘要”，2016年10月<https://dyn.com/blog/ dyn-analysis-summary-of-friday-october-21-attack/>。
[ecc25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", February 2006, <https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
[ecc25519]Bernstein，D.，“曲线25519：新的Diffie-Hellman速度记录”，2006年2月<https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
[ECSO] "European Cyber Security Organisation", <https://www.ecs-org.eu/>.
[ECSO]“欧洲网络安全组织”<https://www.ecs-org.eu/>.
[ENISA-ICS] European Union Agency for Network and Information Security, "Communication network dependencies for ICS/ SCADA Systems", February 2017, <https://www.enisa.europa.eu/publications/ ics-scada-dependencies>.
[ENISA-ICS]欧盟网络和信息安全局，“ICS/SCADA系统的通信网络依赖性”，2017年2月<https://www.enisa.europa.eu/publications/ ics scada依赖项>。
[ETSI-GR-QSC-001] European Telecommunications Standards Institute (ETSI), "Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic framework", ETSI GR QSC 001, July 2016, <https://www.etsi.org/deliver/etsi_gr/ QSC/001_099/001/01.01.01_60/gr_qsc001v010101p.pdf>.
[ETSI-GR-QSC-001]欧洲电信标准协会（ETSI），“量子安全密码术（QSC）；量子安全算法框架”，ETSI GR QSC 001，2016年7月<https://www.etsi.org/deliver/etsi_gr/ QSC/001\U 099/001/01.01.01\U 60/gr\U QSC001V01010101P.pdf>。
[Fairhair] "The Fairhair Alliance", <https://www.fairhair-alliance.org/>.
[Fairhair]“Fairhair联盟”<https://www.fairhair-alliance.org/>.
[FCC] US Federal Communications Commission, Chairman Tom Wheeler to Senator Mark Warner, December 2016, <https://docs.fcc.gov/public/attachments/ DOC-342761A1.pdf>.
[FCC]美国联邦通信委员会主席汤姆·惠勒致参议员马克·华纳，2016年12月<https://docs.fcc.gov/public/attachments/ DOC-342761A1.pdf>。
[FTCreport] US 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/news-events/press-releases/2015/01/ ftc-report-internet-things-urges-companies-adopt-best-practices>.
[FTCreport]美国联邦贸易委员会，“FTC关于物联网的报告敦促公司采取最佳做法解决消费者隐私和安全风险”，2015年1月<https://www.ftc.gov/news-events/press-releases/2015/01/ ftc报告《互联网事物》敦促公司采用最佳实践>。
[GDPR] "The EU General Data Protection Regulation", <https://www.eugdpr.org>.
[GDPR]“欧盟通用数据保护条例”<https://www.eugdpr.org>.
[GSMAsecurity] "GSMA IoT Security Guidelines and Assessment", <http://www.gsma.com/connectedliving/future-iot-networks/ iot-security-guidelines>.
[GSMA安全]“GSMA物联网安全指南和评估”<http://www.gsma.com/connectedliving/future-iot-networks/ 物联网安全指南>。
[HIP-DEX] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Work in Progress, draft-ietf-hip-dex-06, December 2017.
[HIP-DEX]Moskowitz，R.和R.Hummen，“HIP饮食交换（DEX）”，正在进行的工作，草稿-ietf-HIP-DEX-062017年12月。
[IEEE802ah] IEEE, "Status of Project IEEE 802.11ah", IEEE P802.11 - Task Group AH - Meeting Update, <http://www.ieee802.org/11/Reports/tgah_update.htm>.
[IEEE802ah]IEEE，“项目状态IEEE 802.11ah”，IEEE P802.11-任务组AH-会议更新<http://www.ieee802.org/11/Reports/tgah_update.htm>.
[IIoT] "Industrial Internet Consortium", <http://www.iiconsortium.org>.
[IIoT]“工业互联网联盟”<http://www.iiconsortium.org>.
[IoTSecFoundation] Internet of Things Security Foundation, "Establishing Principles for Internet of Things Security", <https://iotsecurityfoundation.org/establishing-principles-for-internet-of-things-security>.
[物联网安全基础]“建立物联网安全原则”，<https://iotsecurityfoundation.org/establishing-principles-for-internet-of-things-security>.
[IPv6-over-NFC] Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, "Transmission of IPv6 Packets over Near Field Communication", Work in Progress, draft-ietf-6lo-nfc-13, February 2019.
[IPv6 over NFC]Choi，Y.，Hong，Y.，Youn，J.，Kim，D.，和J.Choi，“通过近场通信传输IPv6数据包”，正在进行的工作，草案-ietf-6lo-NFC-13，2019年2月。
[ISOC-OTA] Internet Society, "Online Trust Alliance (OTA)", <https://www.internetsociety.org/ota/>.
[ISOC-OTA]互联网协会，“在线信任联盟（OTA）”<https://www.internetsociety.org/ota/>.
[LoRa] "LoRa Alliance", <https://www.lora-alliance.org/>.
[LoRa]“LoRa联盟”<https://www.lora-alliance.org/>.
[LWM2M] OMA SpecWorks, "Lightweight M2M (LWM2M)", <http://openmobilealliance.org/iot/lightweight-m2m-lwm2m>.
[LWM2M]OMA SpecWorks，“轻型M2M（LWM2M）”<http://openmobilealliance.org/iot/lightweight-m2m-lwm2m>.
[Mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,, "DDoS in the IoT: Mirai and Other Botnets", Computer, Vol. 50, Issue 7, DOI 10.1109/MC.2017.201, July 2017, <https://ieeexplore.ieee.org/document/7971869>.
[Mirai]Kolias，C.，Kambourakis，G.，Stavrou，A.，和J.Voas，，“物联网中的DDoS：Mirai和其他僵尸网络”，计算机，第50卷，第7期，DOI 10.1109/MC.2017.201，2017年7月<https://ieeexplore.ieee.org/document/7971869>.
[Moore] Moore, K., Barnes, R., and H. Tschofenig, "Best Current Practices for Securing Internet of Things (IoT) Devices", Work in Progress, draft-moore-iot-security-bcp-01, July 2017.
[Moore]Moore，K.，Barnes，R.，和H.Tschofenig，“保护物联网（IoT）设备的最佳当前实践”，正在进行的工作，草稿-Moore-IoT-security-bcp-012017年7月。
[MULTICAST] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, draft-ietf-core-oscore-groupcomm-04, March 2019.
[多播]Tiloca，M.，Selander，G.，Palombini，F.，和J.Park，“组OSCORE-CoAP的安全组通信”，正在进行的工作，草稿-ietf-core-OSCORE-groupcomm-042019年3月。
[NB-IoT] Qualcomm Incorporated, "New Work Item: NarrowBand IOT (NB-IOT)", September 2015, <http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/ RP-151621.zip>.
[NB-IoT]高通公司，“新工作项目：窄带IoT（NB-IoT）”，2015年9月<http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/ RP-151621.zip>。
[NHTSA] National Highway Traffic Safety Administration, "Cybersecurity Best Practices for Modern Vehicles", Report No. DOT HS 812 333, October 2016, <https://www.nhtsa.gov/staticfiles/nvs/ pdf/812333_CybersecurityForModernVehicles.pdf>.
[NHTSA]国家公路交通安全管理局，“现代车辆网络安全最佳实践”，报告编号：DOT HS 812 333，2016年10月<https://www.nhtsa.gov/staticfiles/nvs/ pdf/812333_CybersecurityForModernVehicles.pdf>。
[NIST-Guide] Ross, R., McEvilley, M., and J. Oren, "Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems", NIST Special Publication 800-160, DOI 10.6028/NIST.SP.800-160, November 2016, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800\ -160.pdf>.
[NIST指南]Ross，R.，McEvilley，M.，和J.Oren，“系统安全工程：可信安全系统工程中多学科方法的考虑”，NIST特别出版物800-160，DOI 10.6028/NIST.SP.800-1602016年11月<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800 \-160.pdf>。
[NIST-LW-2016] Sonmez Turan, M., "NIST's Lightweight Crypto Project", October 2016, <https://www.nist.gov/sites/default/files/ documents/2016/10/17/ sonmez-turan-presentation-lwc2016.pdf>.
[NIST-LW-2016]Sonmez Turan，M.，“NIST的轻量级加密项目”，2016年10月<https://www.nist.gov/sites/default/files/ documents/2016/10/17/sonmez-turan-presentation-lwc2016.pdf>。
[NIST-LW-PROJECT] NIST, "Lightweight Cryptography", <https://www.nist.gov/ programs-projects/lightweight-cryptography>.
[NIST-LW-PROJECT]NIST，“轻量级加密技术”<https://www.nist.gov/ 程序项目/轻量级加密>。
[NISTSP800-122] McCallister, E., Grance, T., and K. Scarfone, "Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)", NIST Special Publication 800-122, April 2010, <https://nvlpubs.nist.gov/nistpubs/legacy/sp/ nistspecialpublication800-122.pdf>.
[NISTSP800-122]McCallister，E.，Grance，T.和K.Scarfone，“个人识别信息（PII）保密指南”，NIST特别出版物800-122，2010年4月<https://nvlpubs.nist.gov/nistpubs/legacy/sp/ nistspecialpublication800-122.pdf>。
[NISTSP800-30r1] National Institute of Standards and Technology, "Guide for Conducting Risk Assessments", NIST Special Publication 800-30 Revision 1, September 2012, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-30r1.pdf>.
[NISTP800-30r1]国家标准与技术研究所，“风险评估指南”，NIST特别出版物800-30第1版，2012年9月<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-30r1.pdf>。
[NISTSP800-34r1] Swanson, M., Bowen, P., Phillips, A., Gallup, D., and D. Lynes, "Contingency Planning Guide for Federal Information Systems", NIST Special Publication 800-34 Revision 1, May 2010, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-34r1.pdf>.
[NISTSP800-34r1]Swanson，M.，Bowen，P.，Phillips，A.，Gallup，D.，和D.Lynes，“联邦信息系统应急计划指南”，NIST特别出版物800-34第1版，2010年5月<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-34r1.pdf>。
[OCF] "Open Connectivity Foundation", <https://openconnectivity.org/>.
[OCF]“开放连接基金会”<https://openconnectivity.org/>.
[OMASpecWorks] "OMA SpecWorks", <https://www.omaspecworks.org/ipso-alliance>.
[OMASpecWorks]“OMASpecWorks”<https://www.omaspecworks.org/ipso-alliance>.
[OneM2M] "OneM2M", <http://www.onem2m.org>.
[OneM2M]“OneM2M”<http://www.onem2m.org>.
[OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", Work in Progress, draft-ietf-core-object-security-16, March 2019.
[OSCORE]Selander，G.，Mattsson，J.，Palombini，F.，和L.Seitz，“受限RESTful环境的对象安全（OSCORE）”，正在进行的工作，草案-ietf-core-Object-Security-162019年3月。
[OWASP] The OWASP Foundation, "IoT Security Guidance", February 2017, <https://www.owasp.org/index.php/IoT_Security_Guidance>.
[OWASP ] OWASP基金会，“物联网安全指导”，2017年2月，<https://www.owasp.org/index.php/IoT_Security_Guidance>.
[RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, Ed., "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-20, March 2019.
[RD]Shelby，Z.，Koster，M.，Bormann，C.，Stok，P.，和C.Amsuess，编辑，“核心资源目录”，正在进行的工作，草稿-ietf-CoRE-Resource-Directory-20，2019年3月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<https://www.rfc-editor.org/info/rfc3748>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, <https://www.rfc-editor.org/info/rfc3756>.
[RFC3756]Nikander，P.，Ed.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，DOI 10.17487/RFC3756，2004年5月<https://www.rfc-editor.org/info/rfc3756>.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 3833，DOI 10.17487/RFC3833，2004年8月<https://www.rfc-editor.org/info/rfc3833>.
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, <https://www.rfc-editor.org/info/rfc4016>.
[RFC4016]Parthasarathy，M.“承载身份验证和网络访问协议（PANA）威胁分析和安全要求”，RFC 4016，DOI 10.17487/RFC4016，2005年3月<https://www.rfc-editor.org/info/rfc4016>.
[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>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<https://www.rfc-editor.org/info/rfc4120>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<https://www.rfc-editor.org/info/rfc4422>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <https://www.rfc-editor.org/info/rfc4555>.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC 4555，DOI 10.17487/RFC4555，2006年6月<https://www.rfc-editor.org/info/rfc4555>.
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, DOI 10.17487/RFC4621, August 2006, <https://www.rfc-editor.org/info/rfc4621>.
[RFC4621]Kivinen，T.和H.Tschofenig，“IKEv2移动性和多址（MOBIKE）协议的设计”，RFC 4621DOI 10.17487/RFC46212006年8月<https://www.rfc-editor.org/info/rfc4621>.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, DOI 10.17487/RFC4738, November 2006, <https://www.rfc-editor.org/info/rfc4738>.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，DOI 10.17487/RFC4738，2006年11月<https://www.rfc-editor.org/info/rfc4738>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919]Kushalnagar，N.，黑山，G.和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，DOI 10.17487/RFC4919，2007年8月<https://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<https://www.rfc-editor.org/info/rfc4944>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5191]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 5191，DOI 10.17487/RFC5191，2008年5月<https://www.rfc-editor.org/info/rfc5191>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, January 2010, <https://www.rfc-editor.org/info/rfc5713>.
[RFC5713]Moustafa，H.，Tschofenig，H.，和S.De Cnodder，“接入节点控制协议（ANCP）的安全威胁和安全要求”，RFC 5713，DOI 10.17487/RFC5713，2010年1月<https://www.rfc-editor.org/info/rfc5713>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, DOI 10.17487/RFC5903, June 2010, <https://www.rfc-editor.org/info/rfc5903>.
[RFC5903]Fu，D.和J.Solinas，“IKE和IKEv2的椭圆曲线群模素数（ECP群）”，RFC 5903，DOI 10.17487/RFC5903，2010年6月<https://www.rfc-editor.org/info/rfc5903>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC6024]Reddy，R.和C.Wallace，“信托锚管理要求”，RFC 6024，DOI 10.17487/RFC60242010年10月<https://www.rfc-editor.org/info/rfc6024>.
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, <https://www.rfc-editor.org/info/rfc6272>.
[RFC6272]Baker，F.和D.Meyer，“智能电网的互联网协议”，RFC 6272，DOI 10.17487/RFC6272，2011年6月<https://www.rfc-editor.org/info/rfc6272>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 6550，DOI 10.17487/RFC6550，2012年3月<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <https://www.rfc-editor.org/info/rfc6551>.
[RFC6551]Vasseur，JP.，Ed.，Kim，M.，Ed.，Pister，K.，Dejean，N.，和D.Barthel，“低功率和有损网络中用于路径计算的路由度量”，RFC 6551，DOI 10.17487/RFC6551，2012年3月<https://www.rfc-editor.org/info/rfc6551>.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, DOI 10.17487/RFC6568, April 2012, <https://www.rfc-editor.org/info/rfc6568>.
[RFC6568]Kim，E.，Kaspar，D.，和JP。Vasseur，“低功率无线个人区域网络（6LoWPANs）上IPv6的设计和应用空间”，RFC 6568，DOI 10.17487/RFC6568，2012年4月<https://www.rfc-editor.org/info/rfc6568>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 6690，DOI 10.17487/RFC6690，2012年8月<https://www.rfc-editor.org/info/rfc6690>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<https://www.rfc-editor.org/info/rfc6749>.
[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>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049]Bormann，C.和P.Hoffman，“简明二进制对象表示法（CBOR）”，RFC 7049，DOI 10.17487/RFC7049，2013年10月<https://www.rfc-editor.org/info/rfc7049>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<https://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<https://www.rfc-editor.org/info/rfc7296>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>.
[RFC7401]Moskowitz，R.，Ed.，Heer，T.，Jokela，P.，和T.Henderson，“主机身份协议版本2（HIPv2）”，RFC 7401，DOI 10.17487/RFC7401，2015年4月<https://www.rfc-editor.org/info/rfc7401>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC7517]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<https://www.rfc-editor.org/info/rfc7519>.
[RFC7520] Miller, M., "Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)", RFC 7520, DOI 10.17487/RFC7520, May 2015, <https://www.rfc-editor.org/info/rfc7520>.
[RFC7520]Miller，M.“使用JSON对象签名和加密（JOSE）保护内容的示例”，RFC 7520，DOI 10.17487/RFC7520，2015年5月<https://www.rfc-editor.org/info/rfc7520>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <https://www.rfc-editor.org/info/rfc7668>.
[RFC7668]Nieminen，J.，Savolainen，T.，Isomaki，M.，Patil，B.，Shelby，Z.，和C.Gomez，“蓝牙（R）低能量IPv6”，RFC 7668，DOI 10.17487/RFC7668，2015年10月<https://www.rfc-editor.org/info/rfc7668>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[RFC7696]Housley，R.，“加密算法敏捷性和选择强制算法的指南”，BCP 201，RFC 7696，DOI 10.17487/RFC7696，2015年11月<https://www.rfc-editor.org/info/rfc7696>.
[RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., and S. Kumar, "Use Cases for Authentication and Authorization in Constrained Environments", RFC 7744, DOI 10.17487/RFC7744, January 2016, <https://www.rfc-editor.org/info/rfc7744>.
[RFC7744]Seitz，L.，Ed.，Gerdes，S.，Ed.，Selander，G.，Mani，M.，和S.Kumar，“受限环境中身份验证和授权的用例”，RFC 7744，DOI 10.17487/RFC7744，2016年1月<https://www.rfc-editor.org/info/rfc7744>.
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, <https://www.rfc-editor.org/info/rfc7815>.
[RFC7815]Kivinen，T，“最小互联网密钥交换版本2（IKEv2）启动器实现”，RFC 7815，DOI 10.17487/RFC7815，2016年3月<https://www.rfc-editor.org/info/rfc7815>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.
[RFC7925]Tschofenig，H.，Ed.和T.Fossati，“物联网的传输层安全（TLS）/数据报传输层安全（DTLS）配置文件”，RFC 7925，DOI 10.17487/RFC79252016年7月<https://www.rfc-editor.org/info/rfc7925>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, <https://www.rfc-editor.org/info/rfc8046>.
[RFC8046]Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“主机身份协议下的主机移动性”，RFC 8046，DOI 10.17487/RFC8046，2017年2月<https://www.rfc-editor.org/info/rfc8046>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8105]Mariager，P.，Petersen，J.，Ed.，Shelby，Z.，Van de Logt，M.，和D.Barthel，“通过数字增强无绳通信（DECT）超低能（ULE）传输IPv6数据包”，RFC 8105，DOI 10.17487/RFC8105，2017年5月<https://www.rfc-editor.org/info/rfc8105>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152]Schaad，J.，“CBOR对象签名和加密（COSE）”，RFC 8152，DOI 10.17487/RFC8152，2017年7月<https://www.rfc-editor.org/info/rfc8152>.
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet of Things Software Update (IoTSU) Workshop 2016", RFC 8240, DOI 10.17487/RFC8240, September 2017, <https://www.rfc-editor.org/info/rfc8240>.
[RFC8240]Tschofenig，H.和S.Farrell，“2016年物联网软件更新（IoTSU）研讨会报告”，RFC 8240，DOI 10.17487/RFC8240，2017年9月<https://www.rfc-editor.org/info/rfc8240>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, <https://www.rfc-editor.org/info/rfc8376>.
[RFC8376]Farrell，S.，Ed.，“低功耗广域网（LPWAN）概述”，RFC 8376，DOI 10.17487/RFC8376，2018年5月<https://www.rfc-editor.org/info/rfc8376>.
[RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387, May 2018, <https://www.rfc-editor.org/info/rfc8387>.
[RFC8387]Sethi，M.，Arkko，J.，Keranen，A.，和H.Back，“保护智能对象网络的实际考虑因素和实施经验”，RFC 8387，DOI 10.17487/RFC8387，2018年5月<https://www.rfc-editor.org/info/rfc8387>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428]Jennings，C.，Shelby，Z.，Arkko，J.，Keranen，A.，和C.Bormann，“传感器测量列表（SenML）”，RFC 8428，DOI 10.17487/RFC8428，2018年8月<https://www.rfc-editor.org/info/rfc8428>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.
[RFC8520]Lear，E.，Droms，R.，和D.Romascanu，“制造商使用说明规范”，RFC 8520，DOI 10.17487/RFC8520，2019年3月<https://www.rfc-editor.org/info/rfc8520>.
[RG-T2TRG] IRTF, "Thing-to-Thing Research Group (T2TRG)", <https://datatracker.ietf.org/rg/t2trg/charter/>.
[RG-T2TRG]IRTF，“物对物研究小组（T2TRG）”<https://datatracker.ietf.org/rg/t2trg/charter/>.
[SchneierSecurity] 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>.
[SchneierSecurity]Schneier，B.，“物联网非常不安全，而且常常无法修补”，2014年1月<https://www.schneier.com/essays/archives/2014/01/ _thin.html>的互联网。
[SEAL] Microsoft, "Microsoft SEAL: Fast and Easy-to-Use Homomorphic Encryption Library", <https://www.microsoft.com/en-us/research/project/ microsoft-seal/>.
[SEAL]Microsoft，“Microsoft SEAL:快速且易于使用的同态加密库”<https://www.microsoft.com/en-us/research/project/ microsoft seal/>。
[shodan] "Shodan", <https://www.shodan.io>.
[shodan]“shodan”<https://www.shodan.io>.
[sigfox] "Sigfox - The Global Communications Service Provider for the Internet of Things (IoT)", <https://www.sigfox.com>.
[sigfox]“sigfox-物联网（IoT）的全球通信服务提供商”<https://www.sigfox.com>.
[Thread] "Thread", <http://threadgroup.org>.
[线程]“线程”<http://threadgroup.org>.
[TR69] Oppenheim, L. and S. Tal, "Too Many Cooks - Exploiting the Internet-of-TR-069-Things", December 2014, <https://media.ccc.de/v/31c3_-_6166_-_en_-_saal_6_- _201412282145_-_too_many_cooks_-_exploiting_the_internet-of-tr-069-things_-_lior_oppenheim_-_shahar_tal>.
[TR69]Oppenheim，L.和S.Tal，“太多的厨师-利用TR-069-Things互联网”，2014年12月<https://media.ccc.de/v/31c3_-_6166_-_en_-_saal_6_- _201412282145——太多——厨师——利用——tr-069-things——互联网——lior——oppenheim——shahar——tal>。
[venona-project] National Security Agency | Central Security Service, "VENONA", <https://www.nsa.gov/news-features/declassified-documents/venona/index.shtml>.
[venona项目]国家安全局|中央安全局，“venona”<https://www.nsa.gov/news-features/declassified-documents/venona/index.shtml>.
[WG-6lo] IETF, "IPv6 over Networks of Resource-constrained Nodes (6lo)", <https://datatracker.ietf.org/wg/6lo/charter/>.
[WG-6lo]IETF，“资源受限节点（6lo）网络上的IPv6”<https://datatracker.ietf.org/wg/6lo/charter/>.
[WG-6LoWPAN] IETF, "IPv6 over Low power WPAN (6lowpan)", <http://datatracker.ietf.org/wg/6lowpan/charter/>.
[WG-6LoWPAN]IETF，“低功耗WPAN上的IPv6（6LoWPAN）”<http://datatracker.ietf.org/wg/6lowpan/charter/>.
[WG-ACE] IETF, "Authentication and Authorization for Constrained Environments (ace)", <https://datatracker.ietf.org/wg/ace/charter/>.
[WG-ACE]IETF，“受限环境的认证和授权（ACE）”<https://datatracker.ietf.org/wg/ace/charter/>.
[WG-ACME] IETF, "Automated Certificate Management Environment (acme)", <https://datatracker.ietf.org/wg/acme/charter/>.
[WG-ACME]IETF，“自动证书管理环境（ACME）”<https://datatracker.ietf.org/wg/acme/charter/>.
[WG-CoRE] IETF, "Constrained RESTful Environment (core)", <https://datatracker.ietf.org/wg/core/charter/>.
[WG CoRE]IETF，“受限RESTful环境（CoRE）”<https://datatracker.ietf.org/wg/core/charter/>.
[WG-LPWAN] IETF, "IPv6 over Low Power Wide-Area Networks (lpwan)", <https://datatracker.ietf.org/wg/lpwan/charter/>.
[WG-LPWAN]IETF，“低功耗广域网（LPWAN）上的IPv6”<https://datatracker.ietf.org/wg/lpwan/charter/>.
[WG-LWIG] IETF, "Light-Weight Implementation Guidance (lwig)", <https://datatracker.ietf.org/wg/lwig/charter/>.
[WG-LWIG]IETF，“轻型实施指南（LWIG）”<https://datatracker.ietf.org/wg/lwig/charter/>.
[WG-MSEC] IETF, "Multicast Security (msec)", <https://datatracker.ietf.org/wg/msec/charter/>.
[WG-MSEC]IETF，“多播安全（MSEC）”<https://datatracker.ietf.org/wg/msec/charter/>.
[WG-SUIT] IETF, "Software Updates for Internet of Things (suit)", <https://datatracker.ietf.org/wg/suit/charter/>.
[WG-SUIT]IETF，“物联网软件更新（SUIT）”<https://datatracker.ietf.org/wg/suit/charter/>.
[WG-TEEP] IETF, "Trusted Execution Environment Provisioning (teep)", <https://datatracker.ietf.org/wg/teep/charter/>.
[WG-TEEP]IETF，“可信执行环境资源调配（TEEP）”<https://datatracker.ietf.org/wg/teep/charter/>.
[Williams] Williams, M. and J. Barrett, "Mobile DTLS", Work in Progress, draft-barrett-mobile-dtls-00, March 2009.
[Williams]Williams，M.和J.Barrett，“移动DTLS”，正在进行的工作，草稿-Barrett-Mobile-DTLS-00，2009年3月。
[wink] Barrett, B., "Wink's Outage Shows Us How Frustrating Smart Homes Could Be", Wired, Gear, April 2015, <http://www.wired.com/2015/04/smart-home-headaches/>.
[wink]Barrett，B.，“wink的故障向我们展示了智能家庭可能会多么令人沮丧”，Wired，Gear，2015年4月<http://www.wired.com/2015/04/smart-home-headaches/>.
[ZB] "Zigbee Alliance", <http://www.zigbee.org/>.
[ZB]“Zigbee联盟”<http://www.zigbee.org/>.
[Ziegeldorf] Ziegeldorf, J., Garcia Morchon, O., and K. Wehrle, "Privacy in the Internet of Things: Threats and Challenges", Security and Communication Networks, Vol. 7, Issue 12, pp. 2728-2742, DOI 10.1002/sec.795, 2014.
[Ziegeldorf]Ziegeldorf，J.，Garcia Morchon，O.，和K.Wehrle，“物联网中的隐私：威胁和挑战”，安全与通信网络，第7卷，第12期，第2728-2742页，DOI 10.1002/sec.7952014。
Acknowledgments
致谢
We gratefully acknowledge feedback and fruitful discussion with Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig, Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred Baker, Vicent Roca, Thomas Fossati, and Eliot Lear. We acknowledge the additional authors of a draft version of this document: Sye Loong Keoh, Rene Hummen, and Rene Struik.
我们非常感谢与Tobias Heer、Robert Moskowitz、Thorsten Dahm、Hannes Tschofenig、Carsten Bormann、Barry Ravendran、Ari Keranen、Goran Selander、Fred Baker、Vicent Roca、Thomas Fossati和Eliot Lear的反馈和富有成效的讨论。我们确认本文件草稿的其他作者：Sye Long Keoh、Rene Hummen和Rene Struik。
Authors' Addresses
作者地址
Oscar Garcia-Morchon Philips High Tech Campus 5 Eindhoven, 5656 AE The Netherlands
Oscar Garcia Morchon飞利浦高科技园区5埃因霍温，5656 AE荷兰
Email: oscar.garcia-morchon@philips.com
Email: oscar.garcia-morchon@philips.com
Sandeep S. Kumar Signify High Tech Campus 7 Eindhoven, 5656 AE The Netherlands
Sandeep S.Kumar表示荷兰埃因霍温7号高科技园区，邮编5656
Email: sandeep.kumar@signify.com
Email: sandeep.kumar@signify.com
Mohit Sethi Ericsson Jorvas 02420 Finland
Mohit Sethi Ericsson Jorvas 02420芬兰
Email: mohit@piuha.net
Email: mohit@piuha.net