Internet Engineering Task Force (IETF) M. Sethi
Request for Comments: 8387 J. Arkko
Category: Informational A. Keranen
ISSN: 2070-1721 Ericsson
H. Back
Nokia
May 2018
Internet Engineering Task Force (IETF) M. Sethi
Request for Comments: 8387 J. Arkko
Category: Informational A. Keranen
ISSN: 2070-1721 Ericsson
H. Back
Nokia
May 2018
Practical Considerations and Implementation Experiences in Securing Smart Object Networks
保护智能对象网络的实践考虑和实施经验
Abstract
摘要
This memo describes challenges associated with securing resource-constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource-constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches.
本备忘录描述了与保护资源受限的智能对象设备相关的挑战。备忘录描述了一种可能的部署模型，其中资源受限设备对消息对象进行签名，讨论了资源受限设备的加密库的可用性，并介绍了在资源受限设备上使用这些库进行消息签名的一些初步经验。最后，备忘录讨论了涉及不同类型安全方法的权衡。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc8387.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8387.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6
4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9
5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Experiences . . . . . . . . . . . . . . . . . 12
7. Example Application . . . . . . . . . . . . . . . . . . . . . 18
8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Informative References . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6
4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9
5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Experiences . . . . . . . . . . . . . . . . . 12
7. Example Application . . . . . . . . . . . . . . . . . . . . . 18
8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Informative References . . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
This memo describes challenges associated with securing smart object devices in constrained implementations and environments. In Section 3, we specifically discuss three challenges: the implementation difficulties encountered on resource-constrained platforms, the problem of provisioning keys, and making the choice of implementing security at the appropriate layer.
本备忘录描述了在受限实现和环境中保护智能对象设备的相关挑战。在第3节中，我们具体讨论了三个挑战：在资源受限的平台上遇到的实现困难、提供密钥的问题，以及在适当的层上选择实现安全性。
Section 4 discusses a potential deployment model for constrained environments. The model requires a minimal amount of configuration, and we believe it is a natural fit with the typical communication practices in smart object networking environments.
第4节讨论了约束环境的潜在部署模型。该模型需要最少的配置，我们相信它自然适合智能对象网络环境中的典型通信实践。
Section 5 discusses the availability of cryptographic libraries. Section 6 presents some experiences in implementing cryptography on resource-constrained devices using those libraries, including information about achievable code sizes and speeds on typical hardware. Section 7 describes an example proof-of-concept prototype implementation that uses public-key cryptography on resource-constrained devices to provide end-to-end data authenticity and integrity protection.
第5节讨论了加密库的可用性。第6节介绍了使用这些库在资源受限的设备上实现加密的一些经验，包括关于典型硬件上可实现的代码大小和速度的信息。第7节描述了一个概念验证原型实现示例，它在资源受限的设备上使用公钥加密技术来提供端到端数据真实性和完整性保护。
Finally, Section 8 discusses trade-offs involving different types of security approaches.
最后，第8节讨论了涉及不同类型安全方法的权衡。
The Constrained Application Protocol (CoAP) [RFC7252] is a lightweight protocol designed to be used in machine-to-machine applications such as smart energy and building automation. Our discussion uses this protocol as an example, but the conclusions may apply to other similar protocols. The CoAP base specification [RFC7252] outlines how to use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. DTLS can be applied with pairwise shared keys, raw public keys, or certificates. The security model in all cases is mutual authentication, so while there is some commonality to HTTP [RFC7230] in verifying the server identity, in practice the models are quite different. The use of IPsec with CoAP is described with regards to the protocol requirements, noting that lightweight implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) exist [RFC7815]. However, the CoAP specification is silent on policy and other aspects that are normally necessary in order to implement interoperable use of IPsec in any environment [RFC5406].
受限应用协议（CoAP）[RFC7252]是一种轻量级协议，设计用于机器对机器应用，如智能能源和楼宇自动化。我们的讨论以该协议为例，但结论可能适用于其他类似协议。CoAP基本规范[RFC7252]概述了如何使用DTLS[RFC6347]和IPsec[RFC4303]来保护协议。DTL可以与成对共享密钥、原始公钥或证书一起应用。在所有情况下，安全模型都是相互身份验证，因此尽管HTTP[RFC7230]在验证服务器身份方面有一些共性，但在实践中，这些模型是完全不同的。关于协议要求，描述了IPsec与CoAP的使用，注意到存在Internet密钥交换协议版本2（IKEv2）的轻量级实现[RFC7815]。但是，CoAP规范对策略和其他方面没有规定，这些方面通常是在任何环境中实现IPsec互操作使用所必需的[RFC5406]。
[IoT-SECURITY] documents the different stages in the life cycle of a smart object. Next, it highlights the security threats for smart objects and the challenges that one might face to protect against
[IoT SECURITY]记录智能对象生命周期的不同阶段。接下来，它将重点介绍智能对象的安全威胁以及可能面临的保护挑战
these threats. The document also looks at various security protocols available, including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], the Host Identity Protocol (HIP) [RFC7401], HIP Diet EXchange [HIP-DEX], a Protocol for Carrying Authentication for Network Access (PANA) [RFC5191], and the Extensible Authentication Protocol (EAP) [RFC3748]. Lastly, [IoT-BOOTSTRAPPING] discusses bootstrapping mechanisms available for resource-constrained Internet of Things (IoT) devices.
这些威胁。本文档还介绍了各种可用的安全协议，包括IKEv2/IPsec[RFC7296]、TLS/SSL[RFC5246]、DTLS[RFC6347]、主机标识协议（HIP）[RFC7401]、HIP饮食交换[HIP-DEX]、网络访问认证协议（PANA）[RFC5191]和可扩展认证协议（EAP）[RFC3748]。最后，[IoT引导]讨论了可用于资源受限物联网（IoT）设备的引导机制。
[RFC6574] gives an overview of the security discussions at the March 2011 IAB workshop on smart objects. The workshop recommended that additional work should be undertaken in developing suitable credential management mechanisms (perhaps something similar to the Bluetooth pairing mechanism), understanding the implementability of standard security mechanisms in resource-constrained devices, and conducting additional research in the area of lightweight cryptographic primitives.
[RFC6574]概述了2011年3月IAB智能对象研讨会上的安全讨论。研讨会建议在开发合适的凭证管理机制（可能类似于蓝牙配对机制）、了解资源受限设备中标准安全机制的可实施性方面开展更多工作，以及在轻量级密码原语领域进行额外的研究。
[HIP-DEX] defines a lightweight version of the HIP protocol for low-power nodes. This version uses a fixed set of algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash functions. The protocol still operates based on host identities and runs end-to-end between hosts, protecting all IP-layer communications. [RFC6078] describes an extension of HIP that can be used to send upper-layer protocol messages without running the usual HIP base exchange at all.
[HIP-DEX]为低功耗节点定义了HIP协议的轻量级版本。此版本使用一组固定的算法，即椭圆曲线加密（ECC），并消除哈希函数。该协议仍然基于主机身份运行，并在主机之间端到端运行，保护所有IP层通信。[RFC6078]描述了HIP的扩展，该扩展可用于发送上层协议消息，而无需运行通常的HIP基础交换。
[IPV6-LOWPAN-SEC] makes a comprehensive analysis of security issues related to IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) networks, but its findings also apply more generally for all low-powered networks. Some of the issues this document discusses include the need to minimize the number of transmitted bits and simplify implementations, threats in the smart object networking environments, and the suitability of 6LoWPAN security mechanisms, IPsec, and key management protocols for implementation in these environments.
[IPV6-LOWPAN-SEC]对低功耗无线个人区域网（6LoWPAN）网络上与IPV6相关的安全问题进行了全面分析，但其发现也更普遍地适用于所有低功耗网络。本文档讨论的一些问题包括最小化传输比特数和简化实现的必要性、智能对象网络环境中的威胁以及6LoWPAN安全机制、IPsec和密钥管理协议在这些环境中实现的适用性。
This section discusses three challenges: 1) implementation difficulties, 2) practical provisioning problems, and 3) layering and communication models.
本节讨论三个挑战：1）实现困难，2）实际资源调配问题，以及3）分层和通信模型。
One of the most often discussed issues in the security for the Internet of Things relate to implementation difficulties. The desire to build resource-constrained, battery-operated, and inexpensive devices drives the creation of devices with a limited protocol and application suite. Some of the typical limitations include running CoAP instead of HTTP, limited support for security mechanisms,
物联网安全中最常讨论的问题之一与实现困难有关。构建资源受限、电池供电且价格低廉的设备的愿望推动了具有有限协议和应用程序套件的设备的创建。一些典型的限制包括运行CoAP而不是HTTP，对安全机制的支持有限，
limited processing power for long key lengths, a sleep schedule that does not allow communication at all times, and so on. In addition, the devices typically have very limited support for configuration, making it hard to set up secrets and trust anchors.
长密钥长度的处理能力有限，睡眠计划不允许在任何时候进行通信，等等。此外，设备通常对配置的支持非常有限，因此很难设置机密和信任锚。
The implementation difficulties are important, but they should not be overemphasized. It is important to select the right security mechanisms and avoid duplicated or unnecessary functionality. But at the end of the day, if strong cryptographic security is needed, the implementations have to support that. It is important for developers and product designers to determine what security threats they want to tackle and the resulting security requirements before selecting the hardware. Often, development work in the wild happens in the wrong order: a particular platform with a resource-constrained microcontroller is chosen first, and then the security features that can fit on it are decided. Also, the most lightweight algorithms and cryptographic primitives are useful but should not be the only consideration in the design and development. Interoperability is also important, and often other parts of the system, such as key management protocols or certificate formats, are heavier to implement than the algorithms themselves.
执行困难很重要，但不应过分强调。选择正确的安全机制并避免重复或不必要的功能非常重要。但归根结底，如果需要强大的加密安全性，实现必须支持这一点。对于开发人员和产品设计师来说，在选择硬件之前，确定他们想要解决的安全威胁以及由此产生的安全需求非常重要。通常，野外开发工作的顺序是错误的：首先选择具有资源受限微控制器的特定平台，然后确定适合该平台的安全功能。此外，最轻量级的算法和加密原语也很有用，但不应成为设计和开发中的唯一考虑因素。互操作性也很重要，通常系统的其他部分（如密钥管理协议或证书格式）比算法本身更难实现。
The second challenge relates to practical provisioning problems. This is perhaps the most fundamental and difficult issue and is unfortunately often neglected in the design. There are several problems in the provisioning and management of smart object networks:
第二个挑战涉及实际的资源调配问题。这可能是最基本和最困难的问题，不幸的是，在设计中经常被忽略。智能对象网络的供应和管理存在几个问题：
o Resource-constrained devices have no natural user interface for configuration that would be required for the installation of shared secrets and other security-related parameters. Typically, there is no keyboard or display, and there may not even be buttons to press. Some devices may only have one interface, the interface to the network.
o 资源受限的设备没有用于安装共享机密和其他安全相关参数所需配置的自然用户界面。通常，没有键盘或显示器，甚至可能没有按钮可按。有些设备可能只有一个接口，即网络接口。
o Manual configuration is rarely, if at all, possible, as the necessary skills are missing in typical installation environments (such as in family homes).
o 手动配置很少（如果可能的话），因为在典型的安装环境中（例如在家庭中）缺少必要的技能。
o There may be a large number of devices. Configuration tasks that may be acceptable when performed for one device may become unacceptable with dozens or hundreds of devices.
o 可能有大量的设备。在一台设备上执行可接受的配置任务在几十台或数百台设备上可能变得不可接受。
o Smart object networks may rely on different radio technologies. Provisioning methods that rely on specific link-layer features may not work with other radio technologies in a heterogeneous network.
o 智能对象网络可能依赖不同的无线电技术。依赖于特定链路层功能的配置方法可能无法与异构网络中的其他无线电技术配合使用。
o Network configurations evolve over the lifetime of the devices, as additional devices are introduced or addresses change. Various central nodes may also receive more frequent updates than individual devices such as sensors embedded in building materials.
o 随着附加设备的引入或地址的更改，网络配置在设备的生命周期内不断变化。各种中心节点也可能比单个设备（如嵌入建筑材料中的传感器）更频繁地接收更新。
In light of the above challenges, resource-constrained devices are often shipped with a single static identity. In many cases, it is a single raw public key. These long-term static identities makes it easy to track the devices (and their owners) when they move. The static identities may also allow an attacker to track these devices across ownership changes.
鉴于上述挑战，资源受限的设备通常附带一个静态标识。在许多情况下，它是单个原始公钥。这些长期的静态身份使得在设备移动时很容易跟踪设备（及其所有者）。静态标识还允许攻击者跨所有权更改跟踪这些设备。
Finally, layering and communication models present difficulties for straightforward use of the most obvious security mechanisms. Smart object networks typically pass information through multiple participating nodes [CoAP-SENSORS], and end-to-end security for IP or transport layers may not fit such communication models very well. The primary reasons for needing middleboxes relate to the need to accommodate for sleeping nodes as well to enable the implementation of nodes that store or aggregate information.
最后，分层和通信模型为直接使用最明显的安全机制带来了困难。智能对象网络通常通过多个参与节点[CoAP传感器]传递信息，IP或传输层的端到端安全性可能不太适合这种通信模型。需要中间盒的主要原因与需要容纳休眠节点以及支持实现存储或聚合信息的节点有关。
[CoAP-SECURITY] recognizes the provisioning model as the driver of what kind of security architecture is useful. This section reintroduces this model briefly here in order to facilitate the discussion of the various design alternatives later.
[CoAP SECURITY]将供应模型视为哪种安全体系结构有用的驱动因素。本节在此简要介绍该模型，以便于以后讨论各种设计方案。
The basis of the proposed architecture are self-generated secure identities, similar to Cryptographically Generated Addresses (CGAs) [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume the following holds:
该架构的基础是自生成的安全身份，类似于加密生成地址（CGA）[RFC3972]或主机身份标签（HITs）[RFC7401]。也就是说，我们假设以下情况成立：
I = h(P|O)
I=h（P | O）
where I is the secure identity of the device, h is a hash function, P is the public key from a key pair generated by the device, and O is optional other information. "|" (vertical bar) here denotes the concatenation operator.
其中I是设备的安全标识，h是散列函数，P是来自设备生成的密钥对的公钥，O是可选的其他信息。“|”（垂直条）此处表示串联运算符。
As it is difficult to provision security credentials, shared secrets, and policy information, the provisioning model is based only on the secure identities. A typical network installation involves physical placement of a number of devices while noting the identities of these devices. This list of short identifiers can then be fed to a central server as a list of authorized devices. Secure communications can
由于很难提供安全凭据、共享机密和策略信息，因此提供模型仅基于安全身份。典型的网络安装涉及许多设备的物理放置，同时注意这些设备的标识。然后，该短标识符列表可以作为授权设备列表馈送到中央服务器。安全通信可以
then commence with the devices, at least as far as information from the devices to the server is concerned, which is what is needed for sensor networks.
然后从设备开始，至少就从设备到服务器的信息而言，这是传感器网络所需要的。
The above architecture is a perfect fit for sensor networks where information flows from a large number of devices to a small number of servers. But it is not sufficient alone for other types of applications. For instance, in actuator applications, a large number of devices need to take commands from somewhere else. In such applications, it is necessary to secure that the commands come from an authorized source.
上述体系结构非常适合信息从大量设备流向少量服务器的传感器网络。但是，对于其他类型的应用程序，仅此一项是不够的。例如，在执行器应用中，大量设备需要从其他地方接收命令。在此类应用程序中，必须确保命令来自授权来源。
This can be supported, with some additional provisioning effort and optional pairing protocols. The basic provisioning approach is as described earlier; however, in addition there must be something that informs the devices of the identity of the trusted server(s). There are multiple ways to provide this information. One simple approach is to feed the identities of the trusted server(s) to devices at installation time. This requires a separate user interface, a local connection (such as USB), or use of the network interface of the device for configuration. In any case, as with sensor networks, the amount of configuration information is minimized: just one short identity value needs to be fed in (not both an identity and certificate or shared secrets that must be kept confidential). An even simpler provisioning approach is that the devices in the device group trust each other. Then no configuration is needed at installation time.
这可以通过一些额外的资源调配工作和可选的配对协议得到支持。基本供应方法如前所述；但是，此外，还必须有一些信息通知设备受信任服务器的身份。提供此信息有多种方式。一种简单的方法是在安装时将受信任服务器的标识提供给设备。这需要单独的用户界面、本地连接（如USB）或使用设备的网络接口进行配置。在任何情况下，与传感器网络一样，配置信息的数量被最小化：只需要输入一个简短的身份值（而不是必须保密的身份和证书或共享机密）。更简单的配置方法是设备组中的设备相互信任。那么在安装时就不需要配置了。
Once both the parties interested in communicating know the expected cryptographic identity of the other offline, secure communications can commence. Alternatively, various pairing schemes can be employed. Note that these schemes can benefit from the already secure identifiers on the device side. For instance, the server can send a pairing message to each device after their initial power-on and before they have been paired with anyone, encrypted with the public key of the device. As with all pairing schemes that do not employ a shared secret or the secure identity of both parties, there are some remaining vulnerabilities that may or may not be acceptable for the application in question. For example, many pairing methods based on "leap of faith" or "trust on first use" assume that the attacker is not present during the initial setup. Therefore, they are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks.
一旦对通信感兴趣的双方都知道另一方离线的预期密码身份，就可以开始安全通信。或者，可以采用各种配对方案。注意，这些方案可以受益于设备端已经安全的标识符。例如，服务器可以在每个设备首次通电后，在与任何人配对之前，向每个设备发送配对消息，并使用设备的公钥进行加密。与所有不使用共享秘密或双方安全身份的配对方案一样，存在一些剩余的漏洞，这些漏洞可能对相关应用程序是可接受的，也可能不可接受。例如，许多基于“信心飞跃”或“首次使用时信任”的配对方法都假定攻击者在初始设置期间不在场。因此，它们容易受到窃听或中间人（MitM）攻击。
In any case, the secure identities help again in ensuring that the operations are as simple as possible. Only identities need to be communicated to the devices, not certificates, shared secrets, or, e.g., IPsec policy rules.
在任何情况下，安全身份都有助于再次确保操作尽可能简单。只需要向设备传递身份，而不需要向证书、共享机密或（例如）IPsec策略规则传递身份。
Where necessary, the information collected at installation time may also include other parameters relevant to the application, such as the location or purpose of the devices. This would enable the server to know, for instance, that a particular device is the temperature sensor for the kitchen.
如有必要，在安装时收集的信息还可以包括与应用相关的其他参数，例如设备的位置或用途。例如，这将使服务器能够知道某个特定设备是厨房的温度传感器。
Collecting the identity information at installation time can be arranged in a number of ways. One simple but not completely secure method is where the last few digits of the identity are printed on a tiny device just a few millimeters across. Alternatively, the packaging for the device may include the full identity (typically 32 hex digits) retrieved from the device at manufacturing time. This identity can be read, for instance, by a bar code reader carried by the installation personnel. (Note that the identities are not secret; the security of the system is not dependent on the identity information leaking to others. The real owner of an identity can always prove its ownership with the private key, which never leaves the device.) Finally, the device may use its wired network interface or proximity-based communications, such as Near-Field Communications (NFC) or Radio-Frequency Identity (RFID) tags. Such interfaces allow secure communication of the device identity to an information gathering device at installation time.
在安装时收集身份信息可以通过多种方式进行安排。一种简单但不完全安全的方法是将身份的最后几位数字打印在一个只有几毫米宽的微型设备上。或者，设备的包装可包括在制造时从设备检索的完整标识（通常为32个十六进制数字）。例如，安装人员携带的条形码阅读器可以读取该标识。（请注意，身份并非秘密；系统的安全性不取决于泄露给他人的身份信息。身份的真正所有者始终可以使用私钥证明其所有权，私钥永远不会离开设备。）最后，设备可以使用其有线网络接口或基于邻近性的通信，例如近场通信（NFC）或射频识别（RFID）标签。这种接口允许在安装时将设备标识安全地通信到信息收集设备。
No matter what the method of information collection is, this provisioning model minimizes the effort required to set up the security. Each device generates its own identity in a random, secure key-generation process. The identities are self-securing in the sense that if you know the identity of the peer you want to communicate with, messages from the peer can be signed by the peer's private key, and it is trivial to verify that the message came from the expected peer. There is no need to configure an identity and certificate of that identity separately. There is no need to configure a group secret or a shared secret. There is no need to configure a trust anchor. In addition, the identities are typically collected anyway for application purposes (such as identifying which sensor is in which room). Under most circumstances, there is actually no additional configuration effort needed for provisioning security.
无论信息收集的方法是什么，此资源调配模型都可以将设置安全性所需的工作量降至最低。每个设备在随机、安全的密钥生成过程中生成自己的身份。身份是自安全的，即如果您知道要与之通信的对等方的身份，那么来自对等方的消息可以由对等方的私钥签名，并且验证消息是否来自预期的对等方并不重要。不需要单独配置标识和该标识的证书。无需配置组机密或共享机密。不需要配置信任锚。此外，通常出于应用目的收集身份（例如识别哪个传感器在哪个房间）。在大多数情况下，实际上不需要额外的配置工作来提供安全性。
As discussed in the previous section, long-term static identities negatively affect the privacy of the devices and their owners. Therefore, it is beneficial for devices to generate new identities at appropriate times during their life cycle; an example is after a factory reset or an ownership handover. Thus, in our proposed deployment model, the devices would generate a new asymmetric key pair and use the new public-key P' to generate the new identity I'. It is also desirable that these identities are only used during the provisioning stage. Temporary identities (such as dynamic IPv6
如前一节所述，长期静态身份会对设备及其所有者的隐私产生负面影响。因此，设备在其生命周期的适当时间生成新身份是有益的；例如，在工厂重置或所有权移交之后。因此，在我们提出的部署模型中，设备将生成一个新的非对称密钥对，并使用新的公钥P'来生成新的身份I'。还希望仅在供应阶段使用这些标识。临时标识（如动态IPv6）
addresses) can be used for network communication protocols once the device is operational.
地址）可用于设备运行后的网络通信协议。
Groups of devices can be managed through single identifiers as well. In these deployment cases, it is also possible to configure the identity of an entire group of devices, rather than registering the individual devices. For instance, many installations employ a kit of devices bought from the same manufacturer in one package. It is easy to provide an identity for such a set of devices as follows:
设备组也可以通过单个标识符进行管理。在这些部署情况下，还可以配置整个设备组的标识，而不是注册单个设备。例如，许多装置使用从同一制造商处购买的成套设备，并将其装在一个包装中。很容易为这组设备提供标识，如下所示：
Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn)
Idev=h（Pdev | Potherdev1 | Potherdev2 |…| Potherdevn）
Igrp = h(Pdev1|Pdev2|...|Pdevm)
Igrp=h（Pdev1 | Pdev2 |…| Pdevm）
where Idev is the identity of an individual device, Pdev is the public key of that device, Potherdevi are the public keys of other devices in the group, n is all the devices in the group except the device with Pdev as its public key, and m is the total number of devices in the group. Now, we can define the secure identity of the group (Igrp) as a hash of all the public keys of the devices in the group (Pdevi).
其中，Idev是单个设备的标识，Pdev是该设备的公钥，Potherdevi是组中其他设备的公钥，n是组中除Pdev作为其公钥的设备外的所有设备，m是组中设备的总数。现在，我们可以将组的安全标识（Igrp）定义为组中设备的所有公钥的散列（Pdevi）。
The installation personnel can scan the identity of the group from the box that the kit came in, and this identity can be stored in a server that is expected to receive information from the nodes. Later when the individual devices contact this server, they will be able to show that they are part of the group, as they can reveal their own public key and the public keys of the other devices. Devices that do not belong to the kit cannot claim to be in the group, because the group identity would change if any new keys were added to the identity of the group (Igrp).
安装人员可以从工具包进入的盒子中扫描组的标识，并且该标识可以存储在期望从节点接收信息的服务器中。稍后，当各个设备联系此服务器时，它们将能够显示它们是组的一部分，因为它们可以显示自己的公钥和其他设备的公钥。不属于该套件的设备不能声称属于该组，因为如果将任何新密钥添加到该组的标识（Igrp），则该组标识将发生更改。
As noted above, the starting point of the architecture is that nodes self-generate secure identities, which are then communicated out of band to the peers that need to know what devices to trust. To support this model in a protocol architecture, we also need to use these secure identities to implement secure messaging between the peers, explain how the system can respond to different types of attacks such as replay attempts, and decide what protocol layer and endpoints the architecture should use.
如上所述，体系结构的起点是节点自行生成安全身份，然后在带外与需要知道信任哪些设备的对等方通信。为了在协议体系结构中支持此模型，我们还需要使用这些安全身份来实现对等方之间的安全消息传递，解释系统如何响应不同类型的攻击（如重播尝试），并确定体系结构应使用的协议层和端点。
The deployment itself is suitable for a variety of design choices regarding layering and protocol mechanisms. [CoAP-SECURITY] was mostly focused on employing end-to-end data-object security as opposed to hop-by-hop security. But other approaches are possible. For instance, HIP in its opportunistic mode could be used to
部署本身适合于关于分层和协议机制的各种设计选择。[CoAP安全性]主要侧重于采用端到端数据对象安全性，而不是逐跳安全性。但其他方法也是可能的。例如，HIP在其机会主义模式下可以用来
implement largely the same functionality at the IP layer. However, it is our belief that the right layer for this solution is at the application layer, and more specifically, in the data formats transported in the payload part of CoAP. This approach provides the following benefits:
在IP层实现基本相同的功能。然而，我们相信，该解决方案的正确层是应用层，更具体地说，是CoAP有效负载部分传输的数据格式。这种方法具有以下好处：
o Ability for intermediaries to act as caches to support different sleep schedules, without the security model being impacted.
o 中介体作为缓存支持不同睡眠计划的能力，而不会影响安全模型。
o Ability for intermediaries to be built to perform aggregation, filtering, storage, and other actions, again without impacting the security of the data being transmitted or stored.
o 构建中介体以执行聚合、过滤、存储和其他操作的能力，同样不会影响正在传输或存储的数据的安全性。
o Ability to operate in the presence of traditional middleboxes, such as a protocol translators or even NATs (not that we recommend their use in these environments).
o 能够在传统的中间盒中运行，例如协议转换器甚至NAT（我们不建议在这些环境中使用）。
However, as we will see later, there are also some technical implications, namely that link, network, and transport-layer solutions are more likely to be able to benefit from sessions where the cost of expensive operations can be amortized over multiple data transmissions. While this is not impossible in data-object security solutions, it is generally not the typical arrangement.
然而，正如我们稍后将看到的，还有一些技术含义，即链路、网络和传输层解决方案更有可能从会话中获益，在会话中，昂贵的操作成本可以在多个数据传输中分摊。虽然这在数据对象安全解决方案中并非不可能，但通常不是典型的安排。
For implementing public-key cryptography on resource-constrained environments, we chose the Arduino Uno board [arduino-uno] as the test platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of flash memory. Our choice of an 8-bit platform may seem surprising since cheaper and more energy-efficient 32-bit platforms are available. However, our intention was to evaluate the performance of public-key cryptography on the most resource-constrained platforms available. It is reasonable to expect better performance results from 32-bit microcontrollers.
为了在资源受限的环境中实现公钥加密，我们选择Arduino Uno板[Arduino Uno]作为测试平台。Arduino Uno拥有一个ATmega328微控制器、一个时钟速度为16 MHz的8位处理器、2 kB的RAM和32 kB的闪存。我们选择8位平台似乎令人惊讶，因为有更便宜、更节能的32位平台。然而，我们的目的是评估公钥加密在资源最有限的平台上的性能。期望32位微控制器具有更好的性能是合理的。
For selecting potential asymmetric cryptographic libraries, we surveyed and came up with a set of possible code sources and performed an initial analysis of how well they fit the Arduino environment. Note that the results are preliminary and could easily be affected in any direction by implementation bugs, configuration errors, and other mistakes. It is advisable to verify the numbers before relying on them for building something. No significant effort was done to optimize ROM memory usage beyond what the libraries provided themselves, so those numbers should be taken as upper limits.
为了选择潜在的非对称密码库，我们调查并提出了一组可能的代码源，并对它们是否适合Arduino环境进行了初步分析。请注意，结果是初步的，很容易在任何方向受到实现错误、配置错误和其他错误的影响。在依靠数字来建造东西之前，最好先核实一下数字。在优化ROM内存使用方面没有做任何超出库自身提供的内容的重大努力，因此这些数字应该被视为上限。
Here is the set of libraries we found:
以下是我们找到的一组库：
o AVRCryptoLib [avr-cryptolib]: This library provides symmetric key algorithms such as AES. It provides RSA as an asymmetric key algorithm. Parts of the library were written in AVR 8-bit assembly language to reduce the size and optimize the performance.
o AVRCryptoLib[avr cryptolib]：此库提供对称密钥算法，如AES。它将RSA作为非对称密钥算法提供。库的某些部分是用AVR 8位汇编语言编写的，以减小大小并优化性能。
o Relic-toolkit [relic-toolkit]: This library is written entirely in C and provides a highly flexible and customizable implementation of a large variety of cryptographic algorithms. This not only includes RSA and ECC but also pairing-based asymmetric cryptography, Boneh-Lynn-Shacham signatures, and Boneh-Boyen short signatures. The library has also added support for curve25519 (for Elliptic Curve Diffie-Hellman key exchange) [RFC7748] and edwards25519 (for elliptic curve digital signatures) [RFC8032]. The toolkit provides an option to build only the desired components for the required platform.
o Relic toolkit[Relic toolkit]：这个库完全用C编写，提供了一个高度灵活和可定制的多种密码算法的实现。这不仅包括RSA和ECC，还包括基于配对的非对称加密、Boneh-Lynn-Shacham签名和Boneh-Boyen短签名。该库还增加了对curve25519（用于椭圆曲线Diffie-Hellman密钥交换）[RFC7748]和edwards25519（用于椭圆曲线数字签名）[RFC8032]的支持。该工具包提供了一个选项，可以仅为所需平台构建所需的组件。
o TinyECC [tinyecc]: TinyECC was designed for using elliptic-curve-based public-key cryptography on sensor networks. It is written in the nesC programming language [nesC] and as such is designed for specific use on TinyOS. However, the library can be ported to standard C either with tool chains or by manually rewriting parts of the code. It also has one of the smallest memory footprints among the set of elliptic curve libraries surveyed so far.
o TinyECC[TinyECC]：TinyECC是为在传感器网络上使用基于椭圆曲线的公钥密码而设计的。它是用nesC编程语言[nesC]编写的，因此专门用于TinyOS。但是，可以使用工具链或手动重写部分代码将库移植到标准C。它也是迄今为止调查的椭圆曲线库中内存占用最小的库之一。
o Wiselib [wiselib]: Wiselib is a generic library written for sensor networks containing a wide variety of algorithms. While the stable version contains algorithms for routing only, the test version includes algorithms for cryptography, localization, topology management, and many more. The library was designed with the idea of making it easy to interface the library with operating systems like iSense and Contiki. However, since the library is written entirely in C++ with a template-based model similar to Boost/CGAL, it can be used on any platform directly without using any of the operating system interfaces provided. This approach was taken to test the code on Arduino Uno.
o Wiselib[Wiselib]：Wiselib是为包含各种算法的传感器网络编写的通用库。稳定版本只包含路由算法，而测试版本包含加密、本地化、拓扑管理等算法。该库的设计理念是使其易于与iSense和Contiki等操作系统进行接口。然而，由于库完全用C++编写，其模板类似于Boo/CGAL，它可以直接在任何平台上使用，而不使用任何操作系统接口。采用这种方法是为了在Arduino Uno上测试代码。
o MatrixSSL [matrix-ssl]: This library provides a low footprint implementation of several cryptographic algorithms including RSA and ECC (with a commercial license). The library in the original form takes about 50 kB of ROM and is intended for 32-bit platforms.
o MatrixSSL[矩阵ssl]：该库提供了几种加密算法的低占用空间实现，包括RSA和ECC（具有商业许可证）。原始形式的库需要大约50KB的ROM，用于32位平台。
This is by no means an exhaustive list, and there exists other cryptographic libraries targeting resource-constrained devices.
这绝不是一个详尽的列表，而且还有其他针对资源受限设备的加密库。
There are also a number of operating systems that are specifically targeted for resource-constrained devices. These operating systems may include libraries and code for security. Hahm et al. [hahmos] conducted a survey of such operating systems. The ARM Mbed OS [mbed] is one such operating system that provides various cryptographic primitives that are necessary for SSL/TLS protocol implementation as well as X509 certificate handling. The library provides an API for developers with a minimal code footprint. It is intended for various ARM platforms such as ARM Cortex M0, ARM Cortex M0+, and ARM Cortex M3.
还有一些操作系统专门针对资源受限的设备。这些操作系统可能包括用于安全的库和代码。哈姆等人[hahmos]对这种操作系统进行了调查。ARM Mbed OS[Mbed]就是这样一种操作系统，它提供SSL/TLS协议实现以及X509证书处理所需的各种加密原语。该库为开发人员提供了一个API，代码占用空间最小。它适用于各种手臂平台，如手臂皮质M0、手臂皮质M0+和手臂皮质M3。
While evaluating the implementation experiences, we were particularly interested in the signature generation operation. This was because our example application discussed in Section 7 required only the signature generation operation on the resource-constrained platforms. We have summarized the initial results of RSA private-key exponentiation performance using AVRCryptoLib [avr-crypto-lib] in Table 1. All results are from a single run since repeating the test did not change (or had only minimal impact on) the results. The execution time for a key size of 2048 bits was inordinately long and would be a deterrent in real-world deployments.
在评估实施经验时，我们对签名生成操作特别感兴趣。这是因为我们在第7节中讨论的示例应用程序只需要在资源受限的平台上执行签名生成操作。我们在表1中总结了使用AVRCryptoLib[avr crypto-lib]的RSA私钥指数性能的初步结果。所有结果均来自一次运行，因为重复测试不会改变（或对结果的影响最小）。密钥大小为2048位的执行时间太长，在实际部署中会起到威慑作用。
+--------------+------------------------+---------------------------+
| Key length | Execution time (ms); | Memory footprint (bytes); |
| (bits) | key in RAM | key in RAM |
+--------------+------------------------+---------------------------+
| 2048 | 1587567 | 1280 |
+--------------+------------------------+---------------------------+
+--------------+------------------------+---------------------------+
| Key length | Execution time (ms); | Memory footprint (bytes); |
| (bits) | key in RAM | key in RAM |
+--------------+------------------------+---------------------------+
| 2048 | 1587567 | 1280 |
+--------------+------------------------+---------------------------+
Table 1: RSA Private-Key Operation Performance
表1:RSA私钥操作性能
The code size was about 3.6 kB with potential for further reduction. It is also worth noting that the implementation performs basic exponentiation and multiplication operations without using any mathematical optimizations such as Montgomery multiplication, optimized squaring, etc., as described in [rsa-high-speed]. With more RAM, we believe that 2048-bit operations can be performed in much less time as has been shown in [rsa-8bit].
代码大小约为3.6KB，可能会进一步减小。还值得注意的是，如[rsa high speed]中所述，该实现在不使用任何数学优化（如蒙哥马利乘法、优化平方等）的情况下执行基本的求幂和乘法运算。有了更多的RAM，我们相信2048位操作可以在更短的时间内完成，如[rsa-8bit]所示。
In Table 2, we present the results obtained by manually porting TinyECC into the C99 standard and running the Elliptic Curve Digital Signature Algorithm (ECDSA) on the Arduino Uno board. TinyECC supports a variety of SEC-2-recommended elliptic curve domain parameters [sec2ecc]. The execution time and memory footprint are
在表2中，我们展示了手动将TinyECC移植到C99标准并在Arduino Uno板上运行椭圆曲线数字签名算法（ECDSA）所获得的结果。TinyECC支持多种SEC-2推荐的椭圆曲线域参数[sec2ecc]。执行时间和内存占用是
shown next to each of the curve parameters. These results were obtained by turning on all the optimizations and using assembly code where available.
显示在每个曲线参数旁边。这些结果是通过启用所有优化并在可用的情况下使用汇编代码获得的。
The results from the performance evaluation of ECDSA in the following tables also contain a column stating the approximate comparable RSA key length as documented in [sec2ecc]. It is clearly observable that for similar security levels, elliptic curve public-key cryptography outperforms RSA.
下表中的ECDSA性能评估结果还包含一列，说明[sec2ecc]中记录的大致可比RSA密钥长度。很明显，对于类似的安全级别，椭圆曲线公钥密码体制的性能优于RSA。
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 2228 | 892 | 1024 |
| secp160r1 | 2250 | 892 | 1024 |
| secp160r2 | 2467 | 892 | 1024 |
| secp192k1 | 3425 | 1008 | 1536 |
| secp192r1 | 3578 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 2228 | 892 | 1024 |
| secp160r1 | 2250 | 892 | 1024 |
| secp160r2 | 2467 | 892 | 1024 |
| secp192k1 | 3425 | 1008 | 1536 |
| secp192r1 | 3578 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+
Table 2: Performance of ECDSA Sign Operation with TinyECC
表2:TinyECC的ECDSA标志操作性能
We also performed experiments by removing the assembly optimization and using a C-only form of the library. This gives us an idea of the performance that can be achieved with TinyECC on any platform regardless of what kind of OS and assembly instruction set is available. The memory footprint remains the same with or without assembly code. The tables contain the maximum RAM that is used when all the possible optimizations are on. However, if the amount of RAM available is smaller in size, some of the optimizations can be turned off to reduce the memory consumption accordingly.
我们还通过删除组装优化并使用C-only形式的库来执行实验。这让我们了解了TinyECC在任何平台上都可以实现的性能，无论使用何种操作系统和汇编指令集。无论是否使用汇编代码，内存占用都保持不变。这些表包含所有可能的优化启用时使用的最大RAM。但是，如果可用RAM的大小较小，则可以关闭一些优化以相应地减少内存消耗。
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 3795 | 892 | 1024 |
| secp160r1 | 3841 | 892 | 1024 |
| secp160r2 | 4118 | 892 | 1024 |
| secp192k1 | 6091 | 1008 | 1536 |
| secp192r1 | 6217 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 3795 | 892 | 1024 |
| secp160r1 | 3841 | 892 | 1024 |
| secp160r2 | 4118 | 892 | 1024 |
| secp192k1 | 6091 | 1008 | 1536 |
| secp192r1 | 6217 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+
Table 3: Performance of ECDSA Sign Operation with TinyECC (No Assembly Optimizations)
表3:TinyECC的ECDSA签名操作性能（无组件优化）
Table 4 documents the performance of Wiselib. Since there were no optimizations that could be turned on or off, we have only one set of results. By default, Wiselib only supports some of the standard SEC 2 elliptic curves, but it is easy to change the domain parameters and obtain results for all the 128-, 160-, and 192-bit SEC 2 elliptic curves. The ROM size for all the experiments was less than 16 kB.
表4记录了Wiselib的性能。因为没有可以打开或关闭的优化，所以我们只有一组结果。默认情况下，Wiselib只支持一些标准的SEC 2椭圆曲线，但很容易更改域参数并获得所有128、160和192位SEC 2椭圆曲线的结果。所有实验的ROM大小都小于16KB。
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 10957 | 842 | 1024 |
| secp160r1 | 10972 | 842 | 1024 |
| secp160r2 | 10971 | 842 | 1024 |
| secp192k1 | 18814 | 952 | 1536 |
| secp192r1 | 18825 | 952 | 1536 |
+-------------+---------------+-----------------+-------------------+
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 10957 | 842 | 1024 |
| secp160r1 | 10972 | 842 | 1024 |
| secp160r2 | 10971 | 842 | 1024 |
| secp192k1 | 18814 | 952 | 1536 |
| secp192r1 | 18825 | 952 | 1536 |
+-------------+---------------+-----------------+-------------------+
Table 4: Performance ECDSA Sign Operation with Wiselib
表4:Wiselib的ECDSA签名操作性能
For testing the relic-toolkit, we used a different board because it required more RAM/ROM, and we were unable to perform experiments with it on Arduino Uno. Arduino Mega has the same 8-bit architecture as Arduino Uno, but it has a much larger RAM/ROM. We used Arduino Mega for experimenting with the relic-toolkit. Again, it is important to mention that we used Arduino as it is a convenient prototyping platform. Our intention was to demonstrate the feasibility of the entire architecture with public-key cryptography on an 8-bit microcontroller. However, it is important to state that 32-bit microcontrollers are much more easily available, at lower costs, and are more power efficient. Therefore, real deployments are better off using 32-bit microcontrollers that allow developers to include the necessary cryptographic libraries. There is no good reason to choose platforms that do not provide sufficient computing power to run the necessary cryptographic operations.
为了测试relic toolkit，我们使用了另一块板，因为它需要更多的RAM/ROM，并且我们无法在Arduino Uno上使用它进行实验。Arduino Mega与Arduino Uno具有相同的8位体系结构，但它的RAM/ROM要大得多。我们使用Arduino Mega对relic toolkit进行了实验。再次强调，我们使用Arduino是很重要的，因为它是一个方便的原型平台。我们的目的是证明在8位微控制器上使用公钥加密的整个体系结构的可行性。然而，必须指出，32位微控制器更容易获得，成本更低，并且更节能。因此，真正的部署最好使用32位微控制器，允许开发人员包含必要的加密库。选择不提供足够计算能力来运行必要的加密操作的平台是没有充分理由的。
The relic-toolkit supports Koblitz curves over prime as well as binary fields. We have experimented with Koblitz curves over binary fields only. We do not run our experiments with all the curves available in the library since the aim of this work is not to prove which curves perform the fastest but rather to show that asymmetric cryptography is possible on resource-constrained devices.
relic toolkit支持素数和二进制字段上的Koblitz曲线。我们只在二元域上试验了Koblitz曲线。我们没有对库中所有可用的曲线进行实验，因为这项工作的目的不是证明哪些曲线执行得最快，而是表明在资源受限的设备上不对称加密是可能的。
The results from relic-toolkit are documented separately in Tables 5 and 6. The first set of results were performed with the library configured for high-speed performance with no consideration given to the amount of memory used. For the second set, the library was
表5和表6分别记录了文物工具包的结果。第一组结果是在库配置为高速性能的情况下执行的，不考虑使用的内存量。在第二盘中，图书馆被关闭了
configured for low-memory usage irrespective of the execution time required by different curves. By turning on/off optimizations included in the library, a trade-off between memory and execution time between these values can be achieved.
配置为低内存使用率，与不同曲线所需的执行时间无关。通过打开/关闭库中包含的优化，可以在这些值之间实现内存和执行时间之间的权衡。
+-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-----------------+--------------+----------------+-----------------+
| sect163k1 | 261 | 2804 | 1024 |
| (assembly math) | | | |
| sect163k1 | 932 | 2750 | 1024 |
| sect163r2 | 2243 | 2444 | 1024 |
| sect233k1 | 1736 | 3675 | 2048 |
| sect233r1 | 4471 | 3261 | 2048 |
+-----------------+--------------+----------------+-----------------+
+-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-----------------+--------------+----------------+-----------------+
| sect163k1 | 261 | 2804 | 1024 |
| (assembly math) | | | |
| sect163k1 | 932 | 2750 | 1024 |
| sect163r2 | 2243 | 2444 | 1024 |
| sect233k1 | 1736 | 3675 | 2048 |
| sect233r1 | 4471 | 3261 | 2048 |
+-----------------+--------------+----------------+-----------------+
Table 5: Performance of ECDSA Sign Operation with relic-toolkit (Fast)
表5：使用relic toolkit（Fast）执行ECDSA签名操作的性能
+-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-----------------+--------------+----------------+-----------------+
| sect163k1 | 592 | 2087 | 1024 |
| (assembly math) | | | |
| sect163k1 | 2950 | 2215 | 1024 |
| sect163r2 | 3213 | 2071 | 1024 |
| sect233k1 | 6450 | 2935 | 2048 |
| sect233r1 | 6100 | 2737 | 2048 |
+-----------------+--------------+----------------+-----------------+
+-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | footprint | key length |
| | | (bytes) | |
+-----------------+--------------+----------------+-----------------+
| sect163k1 | 592 | 2087 | 1024 |
| (assembly math) | | | |
| sect163k1 | 2950 | 2215 | 1024 |
| sect163r2 | 3213 | 2071 | 1024 |
| sect233k1 | 6450 | 2935 | 2048 |
| sect233r1 | 6100 | 2737 | 2048 |
+-----------------+--------------+----------------+-----------------+
Table 6: Performance of ECDSA Sign Operation with relic-toolkit (Low Memory)
表6：使用relic toolkit进行ECDSA签名操作的性能（内存不足）
It is important to note the following points about the elliptic curve measurements:
关于椭圆曲线测量，请务必注意以下几点：
o Some boards (e.g., Arduino Uno) do not provide a hardware random number generator. On such boards, obtaining cryptographic-quality randomness is a challenge. Real-world deployments must rely on a hardware random number generator for cryptographic operations such as generating a public-private key pair. The Nordic nRF52832 board [nordic], for example, provides a hardware random number generator. A detailed discussion on requirements and best practices for cryptographic-quality randomness is documented in [RFC4086]
o 一些电路板（如Arduino Uno）不提供硬件随机数生成器。在这样的电路板上，获得密码质量的随机性是一个挑战。现实世界中的部署必须依赖硬件随机数生成器进行加密操作，例如生成公私密钥对。例如，北欧nRF52832板[Nordic]提供了一个硬件随机数生成器。[RFC4086]中详细讨论了密码质量随机性的要求和最佳实践
o For measuring the memory footprint of all the ECC libraries, we used the Avrora simulator [avrora]. Only stack memory was used to easily track the RAM consumption.
o 为了测量所有ECC库的内存占用，我们使用了Avrora模拟器[Avrora]。仅使用堆栈内存来轻松跟踪RAM消耗。
Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the performance of ECC on an ARM Coretex platform. The results for the ECDSA sign operation shown in Table 7 are performed on a Freescale FRDM-KL25Z board [freescale] that has an ARM Cortex-M0+ 48MHz microcontroller with 128 kB of flash memory and 16 kB of RAM. The sliding window technique for efficient exponentiation was used with a window size of 2. All other optimizations were disabled for these measurements.
Tschofenig和Pegourie Gonnard[armecdsa]还评估了ECC在ARM Coretex平台上的性能。表7所示ECDSA符号操作的结果在飞思卡尔FRDM-KL25Z板[Freescale]上执行，该板具有ARM Cortex-M0+48MHz微控制器，具有128 kB的闪存和16 kB的RAM。使用滑动窗口技术进行有效的幂运算，窗口大小为2。对于这些测量，所有其他优化都被禁用。
+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length |
+------------------+---------------------+--------------------------+
| secp192r1 | 2165 | 1536 |
| secp224r1 | 3014 | 2048 |
| secp256r1 | 3649 | 2048 |
+------------------+---------------------+--------------------------+
+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length |
+------------------+---------------------+--------------------------+
| secp192r1 | 2165 | 1536 |
| secp224r1 | 3014 | 2048 |
| secp256r1 | 3649 | 2048 |
+------------------+---------------------+--------------------------+
Table 7: Performance of ECDSA Sign Operation with an ARM Mbed TLS Stack on Freescale FRDM-KL25Z
表7:Freescale FRDM-KL25Z上带ARM Mbed TLS堆栈的ECDSA标志操作性能
Tschofenig and Pegourie-Gonnard [armecdsa] also measured the performance of curves on an ST Nucleo F091 (STM32F091RCT6) board [stnucleo] that has an ARM Cortex-M0 48 MHz microcontroller with 256 kB of flash memory and 32 kB of RAM. The execution time for the ECDSA sign operation with different curves is shown in Table 8. The sliding window technique for efficient exponentiation was used with a window size of 7. Fixed-point optimization and NIST curve-specific optimizations were used for these measurements.
Tschofenig和Pegourie Gonnard[armecdsa]还测量了ST NucleoF091（STM32F091RCT6）板[stnucleo]上曲线的性能，该板具有ARM Cortex-M0 48 MHz微控制器，具有256 kB的闪存和32 kB的RAM。具有不同曲线的ECDSA签名操作的执行时间如表8所示。使用滑动窗口技术进行有效的幂运算，窗口大小为7。这些测量采用定点优化和NIST特定曲线优化。
+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length |
+------------------+---------------------+--------------------------+
| secp192k1 | 291 | 1536 |
| secp192r1 | 225 | 1536 |
| secp224k1 | 375 | 2048 |
| secp224r1 | 307 | 2048 |
| secp256k1 | 486 | 2048 |
| secp256r1 | 459 | 2048 |
| secp384r1 | 811 | 7680 |
| secp521r1 | 1602 | 15360 |
+------------------+---------------------+--------------------------+
+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length |
+------------------+---------------------+--------------------------+
| secp192k1 | 291 | 1536 |
| secp192r1 | 225 | 1536 |
| secp224k1 | 375 | 2048 |
| secp224r1 | 307 | 2048 |
| secp256k1 | 486 | 2048 |
| secp256r1 | 459 | 2048 |
| secp384r1 | 811 | 7680 |
| secp521r1 | 1602 | 15360 |
+------------------+---------------------+--------------------------+
Table 8: ECDSA Signature Performance with an ARM Mbed TLS Stack on ST Nucleo F091 (STM32F091RCT6)
表8:ST NucleoF091（STM32F091RCT6）上ARM Mbed TLS堆栈的ECDSA签名性能
Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured the RAM consumption by calculating the heap consumed for the cryptographic operations using a custom memory allocation handler. They did not measure the minimal stack memory consumption. Depending on the curve and the different optimizations enable or disabled, the memory consumption for the ECDSA sign operation varied from 1500 bytes to 15000 bytes.
最后，Tschofenig和Pegourie Gonnard[armecdsa]还通过使用自定义内存分配处理程序计算加密操作所消耗的堆来测量RAM消耗。他们没有测量最小堆栈内存消耗。根据曲线和启用或禁用的不同优化，ECDSA签名操作的内存消耗从1500字节到15000字节不等。
At the time of performing these measurements and this study, it was unclear which exact elliptic curve(s) would be selected by the IETF community for use with resource-constrained devices. However, [RFC7748] defines two elliptic curves over prime fields (Curve25519 and Curve448) that offer a high-level of practical security for Diffie-Hellman key exchange. Correspondingly, there is ongoing work to specify elliptic curve signature schemes with Edwards-curve Digital Signature Algorithm (EdDSA). [RFC8032] specifies the recommended parameters for the edwards25519 and edwards448 curves. From these, curve25519 (for Elliptic Curve Diffie-Hellman key exchange) and edwards25519 (for elliptic curve digital signatures) are especially suitable for resource-constrained devices.
在进行这些测量和本研究时，不清楚IETF社区会选择哪条椭圆曲线用于资源受限的设备。然而，[RFC7748]定义了素域上的两条椭圆曲线（Curve25519和Curve448），为Diffie-Hellman密钥交换提供了高级别的实用安全性。相应地，目前正在进行使用Edwards曲线数字签名算法（EdDSA）指定椭圆曲线签名方案的工作。[RFC8032]指定edwards25519和edwards448曲线的建议参数。由此可知，curve25519（用于椭圆曲线Diffie-Hellman密钥交换）和edwards25519（用于椭圆曲线数字签名）特别适合于资源受限的设备。
We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries provide highly efficient implementations of Diffie-Hellman key exchange with curve25519. The results have shown that these libraries with curve25519 outperform other elliptic curves that provide similar levels of security. Hutter and Schwabe [naclavr] also show that the signing of data using the curve Ed25519 from the NaCl library needs only 23216241 cycles on the same microcontroller that we used for our evaluations (Arduino Mega ATmega2560). This corresponds to about 1451 milliseconds of execution time. When compared to the results for other curves and libraries that offer a
我们发现NaCl[NaCl]和MicoNaCl[micronacl]库提供了Diffie-Hellman密钥交换与curve25519的高效实现。结果表明，这些具有curve25519的库的性能优于提供类似安全级别的其他椭圆曲线。Hutter和Schwabe[naclavr]还表明，使用NaCl库中的曲线Ed25519对数据进行签名，在我们用于评估的同一微控制器（Arduino Mega ATmega2560）上只需23216241个周期。这相当于大约1451毫秒的执行时间。与其他曲线和库的结果进行比较时
similar level of security (such as sect233r1 and sect233k1), this implementation far outperforms all others. As such, it is recommended that the IETF community use these curves for protocol specification and implementations.
类似的安全级别（如sect233r1和sect233k1），此实现远远优于所有其他实现。因此，建议IETF社区将这些曲线用于协议规范和实施。
A summary library flash memory use is shown in Table 9.
表9显示了库闪存使用的摘要。
+------------------------+------------------------------------+
| Library | Flash memory footprint (kilobytes) |
+------------------------+------------------------------------+
| AVRCryptoLib | 3.6 |
| Wiselib | 16 |
| TinyECC | 18 |
| Relic-toolkit | 29 |
| NaCl Ed25519 [naclavr] | 17-29 |
+------------------------+------------------------------------+
+------------------------+------------------------------------+
| Library | Flash memory footprint (kilobytes) |
+------------------------+------------------------------------+
| AVRCryptoLib | 3.6 |
| Wiselib | 16 |
| TinyECC | 18 |
| Relic-toolkit | 29 |
| NaCl Ed25519 [naclavr] | 17-29 |
+------------------------+------------------------------------+
Table 9: Summary of Library Flash Memory Consumption
表9：图书馆闪存消耗汇总
All the measurements here are only provided as an example to show that asymmetric-key cryptography (particularly, digital signatures) is possible on resource-constrained devices. By no means are these numbers the final source for measurements, and some curves presented here may no longer be acceptable for real in-the-wild deployments. For example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also document the performance of ECDSA on similar resource-constrained devices.
这里提供的所有度量仅作为示例，以表明非对称密钥加密（特别是数字签名）在资源受限的设备上是可行的。这些数字决不是测量的最终来源，这里给出的一些曲线可能不再适用于实际的野外部署。例如，Mosdorf等人[Mosdorf]和Liu等人[tinyecc]也记录了ECDSA在类似资源受限设备上的性能。
We developed an example application on the Arduino platform to use public-key cryptography, data-object security, and an easy provisioning model. Our application was originally developed to test different approaches to supporting communications to "always off" sensor nodes. These battery-operated or energy-scavenging nodes do not have enough power to stay on at all times. They wake up periodically and transmit their readings.
我们在Arduino平台上开发了一个示例应用程序，使用公钥加密、数据对象安全性和一个简单的资源调配模型。我们的应用程序最初是为了测试支持与“始终关闭”传感器节点通信的不同方法而开发的。这些由电池供电或能量回收的节点没有足够的电力始终保持供电。他们定期醒来并传送读数。
Such sensor nodes can be supported in various ways. [CoAP-SENSORS] was an early multicast-based approach. In the current application, we have switched to using resource directories [CoRE-RD] and publish-subscribe brokers [CoAP-BROKER] instead. Architecturally, the idea is that sensors can delegate a part of their role to a node in the network. Such a network node could be either a local resource or something in the Internet. In the case of CoAP publish-subscribe brokers, the network node agrees to hold the web resources on behalf of the sensor, while the sensor is asleep. The only role that the sensor has is to register itself at the publish-subscribe broker and
这种传感器节点可以以各种方式得到支持。[CoAP SENSORS]是一种早期的基于多播的方法。在当前的应用程序中，我们已经切换到使用资源目录[CoRE RD]和发布-订阅代理[CoAP BROKER]。从架构上讲，这一想法是传感器可以将其角色的一部分委托给网络中的节点。这样的网络节点可以是本地资源，也可以是Internet上的某些东西。在CoAP发布-订阅代理的情况下，网络节点同意在传感器处于休眠状态时代表传感器持有web资源。传感器的唯一作用是在发布-订阅代理和
periodically update the readings. All queries from the rest of the world go to the publish-subscribe broker.
定期更新读数。来自世界其他地方的所有查询都将转到发布-订阅代理。
We constructed a system with four entities:
我们构建了一个包含四个实体的系统：
Sensor: This is an Arduino-based device that runs a CoAP publish-subscribe broker client and relic-toolkit. Relic takes 29 kB of flash memory, and the simple CoAP client takes roughly 3 kB.
传感器：这是一个基于Arduino的设备，运行CoAP发布-订阅代理客户端和遗留工具包。Relic需要29KB的闪存，而简单的CoAP客户端大约需要3KB。
Publish-Subscribe Broker: This is a publish-subscribe broker that holds resources on the sensor's behalf. The sensor registers itself to this node.
发布-订阅代理：这是一个发布-订阅代理，代表传感器保存资源。传感器将自己注册到此节点。
Resource Directory: While physically in the same node in our implementation, a resource directory is a logical function that allows sensors and publish-subscribe brokers to register resources in the directory. These resources can be queried by applications.
资源目录：在我们的实现中，资源目录物理上位于同一个节点中，它是一种逻辑功能，允许传感器和发布-订阅代理在目录中注册资源。应用程序可以查询这些资源。
Application: This is a simple application that runs on a general purpose computer and can retrieve both registrations from the resource directory and most recent sensor readings from the publish-subscribe broker.
应用程序：这是一个简单的应用程序，在通用计算机上运行，可以从资源目录检索注册和从发布-订阅代理检索最新的传感器读数。
The security of this system relies on a secure-shell-like approach. In Step 1, upon first boot, sensors generate keys and register themselves in the publish-subscribe broker. Their public key is submitted along with the registration as an attribute in the CoRE Link Format data [RFC6690].
该系统的安全性依赖于一种安全的外壳式方法。在步骤1中，在第一次引导时，传感器生成密钥并在发布-订阅代理中注册自己。它们的公钥随注册一起提交，作为核心链接格式数据[RFC6690]中的一个属性。
In Step 2, when the sensor makes a measurement, it sends an update to the publish-subscribe broker and signs the message contents with a JSON Object Signing and Encryption (JOSE) signature on the used JSON [RFC7515] and Sensor Measurement List (SenML) payload [MT-SenML]. The sensor can also alternatively use CBOR Object Signing and Encryption (COSE) [RFC8152] for signing the sensor measurement.
在步骤2中，当传感器进行测量时，它向发布-订阅代理发送更新，并在使用的JSON[RFC7515]和传感器测量列表（SenML）负载[MT SenML]上使用JSON对象签名和加密（JOSE）签名对消息内容进行签名。传感器也可以使用CBOR对象签名和加密（COSE）[RFC8152]对传感器测量进行签名。
In Step 3, any other device in the network -- including the publish-subscribe broker, resource directory, and the application -- can check that the public key from the registration corresponds to the private key used to make the signature in the data update.
在步骤3中，网络中的任何其他设备——包括发布-订阅代理、资源目录和应用程序——都可以检查来自注册的公钥是否对应于用于在数据更新中进行签名的私钥。
Note that checks can be done at any time, and there is no need for the sensor and the checking node to be awake at the same time. In our implementation, the checking is done in the application node. This demonstrates how it is possible to implement end-to-end security even with the presence of assisting middleboxes.
注意，检查可以在任何时候进行，传感器和检查节点不需要同时处于唤醒状态。在我们的实现中，检查是在应用程序节点中完成的。这说明了即使存在辅助中间盒，也可以实现端到端安全性。
To verify the feasibility of our architecture, we developed a proof-of-concept prototype. In our prototype, the sensor was implemented using the Arduino Ethernet shield over an Arduino Mega board. Our implementation uses the standard C99 programming language on the Arduino Mega board. In this prototype, the publish-subscribe broker and the Resource Directory (RD) reside on the same physical host. A 64-bit x86 Linux machine serves as the broker and the RD, while a similar but physically distinct 64-bit x86 Linux machine serves as the client that requests data from the sensor. We chose the Relic library version 0.3.1 for our sample prototype as it can be easily compiled for different bit-length processors. Therefore, we were able to use it on the 8-bit processor of the Arduino Mega, as well as on the 64-bit processor of the x86 client. We used ECDSA to sign and verify data updates with the standard sect163k1 curve parameters. While compiling Relic for our prototype, we used the fast configuration without any assembly optimizations.
为了验证我们架构的可行性，我们开发了一个概念验证原型。在我们的原型中，传感器是使用Arduino以太网屏蔽在Arduino巨板上实现的。我们的实现在Arduino Mega板上使用标准C99编程语言。在这个原型中，发布-订阅代理和资源目录（RD）位于同一个物理主机上。64位x86 Linux机器充当代理和RD，而类似但物理上不同的64位x86 Linux机器充当从传感器请求数据的客户端。我们选择Relic库版本0.3.1作为示例原型，因为它可以很容易地为不同的位长度处理器编译。因此，我们能够在Arduino Mega的8位处理器以及x86客户机的64位处理器上使用它。我们使用ECDSA使用标准sect163k1曲线参数对数据更新进行签名和验证。在为原型编译Relic时，我们使用了快速配置，没有任何程序集优化。
The gateway implements the CoAP base specification in the Java programming language and extends it to add support for publish-subscribe broker and Resource Directory Representational State Transfer (REST) interfaces. We also developed a minimalistic CoAP C-library for the Arduino sensor and for the client requesting data updates for a resource. The library has small RAM requirements and uses stack-based allocation only. It is interoperable with the Java implementation of CoAP running on the gateway. The location of the resource directory was configured into the smart object sensor by hardcoding the IP address. A real implementation based on this prototype would instead use the domain name system for obtaining the location of the resource directory.
网关用Java编程语言实现CoAP基本规范，并对其进行扩展，以添加对发布-订阅代理和资源目录表示性状态传输（REST）接口的支持。我们还为Arduino传感器和请求资源数据更新的客户端开发了一个简约的CoAP C库。该库对RAM的要求很小，仅使用基于堆栈的分配。它可以与在网关上运行的CoAP的Java实现进行互操作。通过硬编码IP地址，将资源目录的位置配置到智能对象传感器中。基于此原型的实际实现将使用域名系统获取资源目录的位置。
Our intention was to demonstrate that it is possible to implement the entire architecture with public-key cryptography on an 8-bit microcontroller. The stated values can be improved further by a considerable amount. For example, the flash memory and RAM consumption is relatively high because some of the Arduino libraries were used out of the box, and there are several functions that can be removed. Similarly, we used the fast version of the Relic library in the prototype instead of the low-memory version. However, it is important to note that this was only a research prototype to verify the feasibility of this architecture and, as stated elsewhere, most modern development boards have a 32-bit microcontroller since they are more economical and have better energy efficiency.
我们的目的是证明在8位微控制器上使用公钥加密实现整个体系结构是可能的。所述值可进一步大幅提高。例如，闪存和RAM消耗相对较高，因为一些Arduino库是开箱即用的，并且有几个功能可以删除。同样，我们在原型中使用了快速版本的Relic库，而不是低内存版本。然而，值得注意的是，这只是验证该体系结构可行性的一个研究原型，正如其他地方所述，大多数现代开发板都有一个32位微控制器，因为它们更经济且具有更好的能源效率。
This section attempts to make some early conclusions regarding trade-offs in the design space, based on deployment considerations for various mechanisms and the relative ease or difficulty of implementing them. In particular, this analysis looks at layering, freshness, and the choice of symmetric vs. asymmetric cryptography.
本节试图根据各种机制的部署考虑以及实现它们的相对容易或困难程度，就设计空间中的权衡做出一些早期结论。特别是，此分析着眼于分层、新鲜度以及对称与非对称加密的选择。
The first question is whether using cryptographic security and asymmetric cryptography in particular is feasible at all on resource-constrained devices. The numbers above give a mixed message. Clearly, an implementation of a significant cryptographic operation such as public-key signing can be done in a surprisingly small amount of code space. It could even be argued that our chosen prototype platform was unnecessarily restrictive in the amount of code space it allows: we chose this platform on purpose to demonstrate something that is as resource constrained and difficult as possible.
第一个问题是，在资源受限的设备上使用密码安全性和非对称密码是否可行。上面的数字给出了一个复杂的信息。显然，一个重要的密码操作（如公钥签名）的实现可以在极少量的代码空间内完成。甚至可以说，我们选择的原型平台在其允许的代码空间量上存在不必要的限制：我们选择这个平台是为了展示尽可能资源受限和困难的东西。
A recent trend in microcontrollers is the introduction of 32-bit CPUs that are becoming cheaper and more easily available than 8-bit CPUs, in addition to being more easily programmable. The flash memory size is probably easier to grow than other parameters in microcontrollers. Flash memory size is not expected to be the most significant limiting factor. Before picking a platform, developers should also plan for firmware updates. This would essentially mean that the platform should at least have a flash memory size of the total code size * 2, plus some space for buffer.
微控制器的一个最新趋势是引入32位CPU，除了更易于编程之外，32位CPU比8位CPU更便宜、更容易获得。闪存大小可能比微控制器中的其他参数更容易增长。闪存大小预计不是最重要的限制因素。在选择平台之前，开发人员还应该计划固件更新。这基本上意味着平台至少应该有一个总代码大小*2的闪存，加上一些缓冲空间。
The situation is less clear with regards to the amount of CPU power needed to run the algorithms. The demonstrated speeds are sufficient for many applications. For instance, a sensor that wakes up every now and then can likely spend a fraction of a second, or even spend multiple seconds in some cases, for the computation of a signature for the message that it is about to send. Most applications that use protocols such as DTLS that use public-key cryptography only at the beginning of the session would also be fine with any of these execution times.
至于运行算法所需的CPU功率，情况就不那么清楚了。证明的速度足以满足许多应用。例如，偶尔醒来的传感器可能会花费几分之一秒，甚至在某些情况下会花费几秒钟来计算其即将发送的消息的签名。大多数使用协议（如DTL）的应用程序仅在会话开始时使用公钥加密，也可以使用这些执行时间。
Yet, with reasonably long key sizes, the execution times are in the seconds, dozens of seconds, or even longer. For some applications, this is too long. Nevertheless, these algorithms can successfully be employed in resource-constrained devices for the following reasons:
然而，对于相当长的密钥大小，执行时间只有几秒、几十秒甚至更长。对于某些应用程序，这太长了。然而，由于以下原因，这些算法可以成功地应用于资源受限的设备中：
o With the right selection of algorithms and libraries, the execution times can actually be very small (less than 500 ms).
o 通过正确选择算法和库，执行时间实际上可以非常小（小于500毫秒）。
o As discussed in [wiman], in general, the power requirements necessary to turn the radio on/off and sending or receiving messages are far bigger than those needed to execute cryptographic operations. While there are newer radios that significantly lower the energy consumption of sending and receiving messages, there is no good reason to choose platforms that do not provide sufficient computing power to run the necessary cryptographic operations.
o 正如[wiman]中所讨论的，一般来说，打开/关闭无线电以及发送或接收消息所需的功率要求远远大于执行加密操作所需的功率要求。虽然有新的无线电可以显著降低发送和接收消息的能耗，但没有理由选择不提供足够计算能力来运行必要的加密操作的平台。
o Commercial libraries and the use of full potential for various optimizations will provide a better result than what we arrived at in this memo.
o 商业图书馆和充分利用各种优化潜力将提供比我们在本备忘录中达成的更好的结果。
o Using public-key cryptography only at the beginning of a session will reduce the per-packet processing times significantly.
o 仅在会话开始时使用公钥加密将显著减少每个数据包的处理时间。
While we did not do an exhaustive performance evaluation of asymmetric key-pair generation on resource-constrained devices, we did note that it is possible for such devices to generate a new key pair. Given that this operation would only occur in rare circumstances (such as a factory reset or ownership change) and its potential privacy benefits, developers should provide mechanisms for generating new identities. However, it is extremely important to note that the security of this operation relies on access to cryptographic-quality randomness.
虽然我们没有对资源受限设备上的非对称密钥对生成进行详尽的性能评估，但我们确实注意到这类设备有可能生成新的密钥对。鉴于此操作只会在极少数情况下发生（如工厂重置或所有权变更）及其潜在的隐私利益，开发人员应提供生成新身份的机制。然而，非常重要的是要注意，此操作的安全性依赖于对密码质量随机性的访问。
In our architecture, if implemented as described thus far, messages along with their signatures sent from the sensors to the publish-subscribe broker can be recorded and replayed by an eavesdropper. The publish-subscribe broker has no mechanism to distinguish previously received packets from those that are retransmitted by the sender or replayed by an eavesdropper. Therefore, it is essential for the smart objects to ensure that data updates include a freshness indicator. However, ensuring freshness on constrained devices can be non-trivial because of several reasons, which include:
在我们的体系结构中，如果按照到目前为止所描述的方式实现，则窃听者可以记录和重播从传感器发送到发布-订阅代理的消息及其签名。发布-订阅代理没有机制来区分先前接收到的数据包与发送方重新传输或窃听者重播的数据包。因此，智能对象必须确保数据更新包含新鲜度指示器。但是，由于以下几个原因，确保受约束设备的新鲜度并非易事：
o Communication is mostly unidirectional to save energy.
o 通信大多是单向的，以节省能源。
o Internal clocks might not be accurate and may be reset several times during the operational phase of the smart object.
o 内部时钟可能不准确，并且可能在智能对象的操作阶段重置多次。
o Network time synchronization protocols such as the Network Time Protocol (NTP) [RFC5905] are resource intensive and therefore may be undesirable in many smart object networks.
o 网络时间同步协议，如网络时间协议（NTP）[RFC5905]是资源密集型协议，因此在许多智能对象网络中可能不受欢迎。
There are several different methods that can be used in our architecture for replay protection. The selection of the appropriate choice depends on the actual deployment scenario.
在我们的体系结构中，有几种不同的方法可用于重播保护。选择适当的选项取决于实际部署场景。
Including sequence numbers in signed messages can provide an effective method of replay protection. The publish-subscribe broker should verify the sequence number of each incoming message and accept it only if it is greater than the highest previously seen sequence number. The publish-subscribe broker drops any packet with a sequence number that has already been received or if the received sequence number is greater than the highest previously seen sequence number by an amount larger than the preset threshold.
在签名消息中包含序列号可以提供有效的重播保护方法。publish-subscribe代理应该验证每个传入消息的序列号，并且仅当它大于之前看到的最高序列号时才接受它。发布-订阅代理丢弃任何具有已接收序列号的数据包，或者如果接收到的序列号比先前看到的最高序列号大一个大于预设阈值的量。
Sequence numbers can wrap around at their maximum value; therefore, it is essential to ensure that sequence numbers are sufficiently long. However, including long sequence numbers in packets can increase the network traffic originating from the sensor and can thus decrease its energy efficiency. To overcome the problem of long sequence numbers, we can use a scheme similar to that of Huang [huang], where the sender and receiver maintain and sign long sequence numbers of equal bit lengths, but they transmit only the least-significant bits.
序列号可以在其最大值处环绕；因此，必须确保序列号足够长。然而，在分组中包括长序列号会增加来自传感器的网络流量，从而降低其能量效率。为了克服长序列号的问题，我们可以使用类似于Huang[Huang]的方案，其中发送方和接收方保持并签署具有相同比特长度的长序列号，但它们只传输最低有效位。
It is important for the smart object to write the sequence number into the permanent flash memory after each increment and before it is included in the message to be transmitted. This ensures that the sensor can obtain the last sequence number it had intended to send in case of a reset or a power failure. However, the sensor and the publish-subscribe broker can still end up in a discordant state where the sequence number received by the publish-subscribe broker exceeds the expected sequence number by an amount greater than the preset threshold. This may happen because of a prolonged network outage or if the publish-subscribe broker experiences a power failure for some reason. Therefore, it is essential for sensors that normally send Non-Confirmable data updates to send some Confirmable updates and resynchronize with the publish-subscribe broker if a reset message is received. The sensors resynchronize by sending a new registration message with the current sequence number.
对于智能对象来说，重要的是在每次增量之后以及在将其包含在要传输的消息中之前，将序列号写入永久闪存中。这可确保传感器在复位或电源故障的情况下能够获得其打算发送的最后序列号。然而，传感器和发布-订阅代理仍可能最终处于不一致状态，其中发布-订阅代理接收到的序列号超过预期序列号的量大于预设阈值。这可能是由于长期的网络中断，或者发布-订阅代理由于某种原因发生电源故障。因此，通常发送不可确认数据更新的传感器必须发送一些可确认更新，并在收到重置消息时与发布-订阅代理重新同步。传感器通过发送带有当前序列号的新注册信息来重新同步。
Although sequence numbers protect the system from replay attacks, a publish-subscribe broker has no mechanism to determine the time at which updates were created by the sensor. Moreover, if sequence numbers are the only freshness indicator used, a malicious eavesdropper can induce inordinate delays to the communication of signed updates by buffering messages. It may be important in certain smart object networks for sensors to send data updates that include timestamps to allow the publish-subscribe broker to determine the time when the update was created. For example, when the publish-
虽然序列号保护系统免受重播攻击，但发布-订阅代理没有确定传感器创建更新的时间的机制。此外，如果序列号是唯一使用的新鲜度指示器，恶意窃听者可以通过缓冲消息来诱导签名更新通信的过度延迟。在某些智能对象网络中，传感器发送包含时间戳的数据更新可能很重要，以允许发布-订阅代理确定创建更新的时间。例如，当发布-
subscribe broker is collecting temperature data, it may be necessary to know when exactly the temperature measurement was made by the sensor. A simple solution to this problem is for the publish-subscribe broker to assume that the data object was created when it receives the update. In a relatively reliable network with low RTT, it can be acceptable to make such an assumption. However, most networks are susceptible to packet loss and hostile attacks making this assumption unsustainable.
在收集温度数据时，可能需要知道传感器何时准确测量温度。这个问题的一个简单解决方案是发布-订阅代理假定数据对象是在接收更新时创建的。在相对可靠且RTT较低的网络中，可以接受这样的假设。然而，大多数网络易受数据包丢失和恶意攻击的影响，这使得这种假设不可持续。
Depending on the hardware used by the smart objects, they may have access to accurate hardware clocks, which can be used to include timestamps in the signed updates. These timestamps are included in addition to sequence numbers. The clock time in the smart objects can be set by the manufacturer, or the current time can be communicated by the publish-subscribe broker during the registration phase. However, these approaches require the smart objects to either rely on the long-term accuracy of the clock set by the manufacturer or trust the publish-subscribe broker thereby increasing the potential vulnerability of the system. The smart objects could also obtain the current time from NTP, but this may consume additional energy and give rise to security issues discussed in [RFC5905]. The smart objects could also have access to a mobile network or the Global Positioning System (GPS), and they can be used obtain the current time. Finally, if the sensors need to coordinate their sleep cycles, or if the publish-subscribe broker computes an average or mean of updates collected from multiple smart objects, it is important for the network nodes to synchronize the time among them. This can be done by using existing synchronization schemes.
根据智能对象使用的硬件，它们可以访问精确的硬件时钟，这些时钟可用于在签名更新中包含时间戳。除了序列号之外，还包括这些时间戳。智能对象中的时钟时间可以由制造商设置，或者当前时间可以由发布-订阅代理在注册阶段进行通信。然而，这些方法要求智能对象要么依赖制造商设置的时钟的长期准确性，要么信任发布-订阅代理，从而增加系统的潜在漏洞。智能对象也可以从NTP获取当前时间，但这可能会消耗额外的能量，并导致[RFC5905]中讨论的安全问题。智能对象还可以访问移动网络或全球定位系统（GPS），并可用于获取当前时间。最后，如果传感器需要协调其睡眠周期，或者如果发布-订阅代理计算从多个智能对象收集的更新的平均值或平均值，则网络节点必须同步它们之间的时间。这可以通过使用现有的同步方案来实现。
It would be useful to select just one layer where security is provided at. Otherwise, a simple device needs to implement multiple security mechanisms. While some code can probably be shared across such implementations (like algorithms), it is likely that most of the code involving the actual protocol machinery cannot. Looking at the different layers, here are the choices and their implications:
只选择一个提供安全性的层是很有用的。否则，一个简单的设备需要实现多种安全机制。虽然一些代码可能可以在这些实现中共享（如算法），但大多数涉及实际协议机制的代码可能无法共享。看看不同的层次，以下是选择及其含义：
link layer: This is probably the most common solution today. The primary benefits of this choice of layer are that security services are commonly available (WLAN secrets, cellular SIM cards, etc.) and that their application protects the entire communications.
链接层：这可能是目前最常见的解决方案。这种层选择的主要好处是安全服务通常可用（WLAN机密、蜂窝SIM卡等），并且其应用程序保护整个通信。
The main drawback is that there is no security beyond the first hop. This can be problematic, e.g., in many devices that communicate to a server in the Internet. A smart home weighing scale, for instance, can support WLAN security, but without some
主要缺点是在第一跳之后没有安全性。这可能有问题，例如，在许多与Internet中的服务器通信的设备中。例如，智能家庭秤可以支持无线局域网安全，但不需要一些硬件
level of end-to-end security, it would be difficult to prevent fraudulent data submissions to the servers.
在端到端安全级别上，很难防止向服务器提交欺诈性数据。
Another drawback is that some commonly implemented link-layer security designs use group secrets. This allows any device within the local network (e.g., an infected laptop) to attack the communications.
另一个缺点是，一些常用的链路层安全设计使用组机密。这允许本地网络中的任何设备（例如，受感染的笔记本电脑）攻击通信。
network layer: There are a number of solutions in this space and many new ones and variations thereof being proposed: IPsec, PANA, and so on. In general, these solutions have similar characteristics to those in the transport layer: they work across forwarding hops but only as far as to the next middlebox or application entity. There is plenty of existing solutions and designs.
网络层：在这个领域有许多解决方案，许多新的解决方案及其变体正在被提出：IPsec、PANA等等。一般来说，这些解决方案与传输层中的解决方案具有相似的特性：它们跨转发跃点工作，但只工作到下一个中间盒或应用程序实体。现有的解决方案和设计很多。
Experience has shown that it is difficult to control IP-layer entities from an application process. While this is theoretically easy, in practice the necessary APIs do not exist. For instance, most IPsec software has been built for the VPN use case and is difficult or impossible to tweak to be used on a per-application basis. As a result, the authors are not particularly enthusiastic about recommending these solutions.
经验表明，很难从应用程序进程控制IP层实体。虽然这在理论上很容易，但实际上并不存在必要的API。例如，大多数IPsec软件都是为VPN用例而构建的，很难或不可能根据每个应用程序进行调整。因此，作者并不特别热衷于推荐这些解决方案。
transport and application layer: This is another popular solution along with link-layer designs. TLS with HTTP (HTTPS) and DTLS with CoAP are examples of solutions in this space and have been proven to work well. These solutions are typically easy to take into use in an application, without assuming anything from the underlying OS, and they are easy to control as needed by the applications. The main drawback is that generally speaking, these solutions only run as far as the next application level entity. And even for this case, HTTPS can be made to work through proxies, so this limit is not unsolvable. Another drawback is that attacks on the link layer, network layer, and in some cases, transport layer, cannot be protected against. However, if the upper layers have been protected, such attacks can at most result in a denial of service. Since denial of service can often be caused anyway, it is not clear if this is a real drawback.
传输和应用层：这是另一个与链路层设计一起流行的解决方案。带有HTTP（HTTPS）的TLS和带有CoAP的DTL就是这一领域的解决方案示例，并已被证明运行良好。这些解决方案通常很容易在应用程序中使用，而不需要从底层操作系统中获取任何信息，并且很容易根据应用程序的需要进行控制。主要缺点是，一般来说，这些解决方案只能运行到下一个应用程序级实体。即使在这种情况下，HTTPS也可以通过代理来工作，所以这个限制不是无法解决的。另一个缺点是无法防止对链路层、网络层以及在某些情况下对传输层的攻击。但是，如果上层受到保护，此类攻击最多只能导致拒绝服务。由于拒绝服务通常都会导致，因此不清楚这是否是一个真正的缺点。
data-object layer: This solution does not protect any of the protocol layers but protects individual data elements being sent. It works particularly well when there are multiple application-layer entities on the path of the data. Smart object networks are likely to employ such entities for storage, filtering, aggregation and other reasons, and as such, an end-to-end solution is the only one that can protect the actual data.
数据对象层：此解决方案不保护任何协议层，但保护正在发送的单个数据元素。当数据路径上有多个应用层实体时，它工作得特别好。智能对象网络可能出于存储、过滤、聚合和其他原因使用此类实体，因此，端到端解决方案是唯一能够保护实际数据的解决方案。
The downside is that the lower layers are not protected. But again, as long as the data is protected and checked upon every time it passes through an application-level entity, it is not clear that there are attacks beyond denial of service.
缺点是下层没有受到保护。但同样，只要数据在每次通过应用程序级实体时都受到保护和检查，就不清楚是否存在拒绝服务以外的攻击。
The main question mark is whether this type of a solution provides sufficient advantages over the more commonly implemented transport and application-layer solutions.
主要的问题是，这种类型的解决方案是否比更普遍实现的传输层和应用层解决方案具有足够的优势。
The second trade-off that is worth discussing is the use of plain asymmetric cryptographic mechanisms, plain symmetric cryptographic mechanisms, or some mixture thereof.
第二个值得讨论的权衡是使用简单的非对称加密机制、简单的对称加密机制或它们的混合。
Contrary to popular cryptographic community beliefs, a symmetric cryptographic solution can be deployed in large scale. In fact, one of the largest deployments of cryptographic security, the cellular network authentication system, uses Subscriber Identification Module (SIM) cards that are based on symmetric secrets. In contrast, public-key systems have yet to show an ability to scale to hundreds of millions of devices, let alone billions. But the authors do not believe scaling is an important differentiator when comparing the solutions.
与流行的密码社区信念相反，对称密码解决方案可以大规模部署。事实上，最大的加密安全部署之一，蜂窝网络认证系统，使用基于对称秘密的用户识别模块（SIM）卡。相比之下，公钥系统还没有显示出能够扩展到数亿台设备，更不用说数十亿台了。但作者不认为在比较解决方案时，缩放是一个重要的区别。
As can be seen from Section 6, the time needed to calculate some of the asymmetric cryptographic operations with reasonable key lengths can be significant. There are two contrary observations that can be made from this. First, recent wisdom indicates that computing power on resource-constrained devices is far cheaper than transmission power [wiman], and it keeps on becoming more efficient very quickly. From this we can conclude that the sufficient CPU is or at least will be easily available.
从第6节可以看出，计算具有合理密钥长度的一些非对称密码操作所需的时间可能非常长。从这一点可以得出两个相反的结论。首先，最近的智慧表明，资源受限设备上的计算能力远低于传输能力[wiman]，而且它的效率一直在快速提高。从这一点我们可以得出结论，足够的CPU是或至少将很容易获得。
But the other observation is that when there are very costly asymmetric operations, doing a key exchange followed by the use of generated symmetric keys would make sense. This model works very well for DTLS and other transport-layer solutions, but it works less well for data-object security, particularly when the number of communicating entities is not exactly two.
但另一个观察结果是，当存在非常昂贵的不对称操作时，进行密钥交换，然后使用生成的对称密钥是有意义的。此模型对于DTL和其他传输层解决方案非常有效，但对于数据对象安全性，尤其是当通信实体的数量不完全是两个时，效果就不太好了。
This document makes several security recommendations based on our implementation experience. We summarize some of the important ones here:
本文档根据我们的实施经验提出了一些安全建议。我们在此总结一些重要的问题：
o Developers and product designers should choose the hardware after determining the security requirements for their application scenario.
o 开发人员和产品设计师应在确定其应用程序场景的安全要求后选择硬件。
o ECC outperforms RSA-based operations; therefore, it is recommended for resource-constrained devices.
o ECC优于基于RSA的操作；因此，建议将其用于资源受限的设备。
o Cryptographic-quality randomness is needed for many security protocols. Developers and vendors should ensure that the sufficient randomness is available for security critical tasks.
o 许多安全协议都需要密码质量的随机性。开发人员和供应商应确保安全关键任务具有足够的随机性。
o 32-bit microcontrollers are much more easily available, at lower costs, and are more power efficient. Therefore, real-world deployments are better off using 32-bit microcontrollers.
o 32位微控制器更容易获得，成本更低，并且更节能。因此，实际部署最好使用32位微控制器。
o Developers should provide mechanisms for devices to generate new identities at appropriate times during their life cycle, for example, after a factory reset or an ownership handover.
o 开发人员应为设备提供机制，以便在其生命周期的适当时间生成新身份，例如，在工厂重置或所有权移交之后。
o Planning for firmware updates is important. The hardware platform chosen should at least have a flash memory size of the total code size * 2, plus some space for buffer.
o 规划固件更新非常重要。选择的硬件平台应至少具有总代码大小*2的闪存大小，以及一些用于缓冲的空间。
This entire memo deals with security issues.
整个备忘录涉及安全问题。
This document has no IANA actions.
本文档没有IANA操作。
[arduino-uno] Arduino, "Arduino Uno REV3", <http://arduino.cc/en/Main/arduinoBoardUno>.
[arduino uno]arduino，“arduino uno REV3”<http://arduino.cc/en/Main/arduinoBoardUno>.
[armecdsa] Tschofenig, H. and M. Pegourie-Gonnard, "Performance Investigations", March 2015, <https://www.ietf.org/proceedings/92/slides/ slides-92-lwig-3.pdf>.
[armecdsa]Tschofenig，H.和M.Pegourie Gonnard，“绩效调查”，2015年3月<https://www.ietf.org/proceedings/92/slides/ 幻灯片-92-lwig-3.pdf>。
[avr-crypto-lib] Das Labor, "AVR-Crypto-Lib", February 2014, <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>.
[avr加密库]Das劳工，“avr加密库”，2014年2月<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>.
[avr-cryptolib] "AVRCryptoLib", <http://www.emsign.nl/>.
[avr cryptolib]“AVRCryptoLib”<http://www.emsign.nl/>.
[avrora] Avora, "The AVR Simulation and Analysis Framework", <http://compilers.cs.ucla.edu/avrora/>.
[avrora]Avora，“AVR模拟和分析框架”<http://compilers.cs.ucla.edu/avrora/>.
[CoAP-BROKER] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, March 2018.
[CoAP代理]Koster，M.，Keranen，A.，和J.Jimenez，“受限应用程序协议（CoAP）的发布-订阅代理”，正在进行的工作，草稿-ietf-core-CoAP-pubsub-042018年3月。
[CoAP-SECURITY] Arkko, J. and A. Keranen, "CoAP Security Architecture", Work n Progress, draft-arkko-core-security-arch-00, July 2011.
[CoAP安全]Arkko，J.和A.Keranen，“CoAP安全架构”，工作进展，草稿-Arkko-core-SECURITY-arch-00，2011年7月。
[CoAP-SENSORS] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", Wok in Progress, draft-arkko-core-sleepy-sensors-01, July 2011.
[CoAP传感器]Arkko，J.，Rissanen，H.，Loreto，S.，Turanyi，Z.，和O.Novo，“实施微型CoAP传感器”，正在进行的工作，草稿-Arkko-core-sleepy-SENSORS-012011年7月。
[CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-13, March 2018.
[CoRE RD]Z.Shelby、M.Koster、C.Bormann、P.Stok和C.Amsuess，“核心资源目录”，正在进行的工作，草稿-ietf-CoRE-Resource-Directory-13，2018年3月。
[freescale] ARM Mbed, "FRDM-KL25Z", <https://developer.mbed.org/platforms/KL25Z/>.
[飞思卡尔]手臂Mbed，“FRDM-KL25Z”<https://developer.mbed.org/platforms/KL25Z/>.
[hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes, "Operating systems for low-end devices in the internet of things: a survey", IEEE Internet of Things Journal, Vol. 3, Issue 5, DOI 10.1109/JIOT.2015.2505901, October 2016.
[hahmos]Hahm，O.，Baccelli，E.，Petersen，H.，和N.Tsiftes，“物联网中低端设备的操作系统：调查”，《IEEE物联网杂志》，第3卷，第5期，DOI 10.1109/JIOT.2015.2505901，2016年10月。
[HIP-DEX] Moskowitz, R., Ed. and R. Hummen, "HIP Diet EXchange (DEX)", Work in Progress, draft-ietf-hip-dex-06, December 2017.
[HIP-DEX]Moskowitz，R.，Ed.和R.Hummen，“HIP饮食交换（DEX）”，正在进行的工作，草稿-ietf-HIP-DEX-062017年12月。
[huang] Huang, C., "LOFT: Low-overhead freshness transmission in sensor networks", IEEE, DOI 10.1109/SUTC.2008.38, June 2008.
[huang]huang，C.，“LOFT：传感器网络中的低开销新鲜度传输”，IEEE，DOI 10.1109/SUTC.2008.382008年6月。
[IoT-BOOTSTRAPPING] Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT Bootstrapping: A Survey", Work in Progress, draft-sarikaya-t2trg-sbootstrapping-03, February 2017.
[IoT引导]Sarikaya，B.，Sethi，M.，和A.Sangi，“安全IoT引导：调查”，正在进行的工作，草稿-Sarikaya-t2trg-sbootstrapping-032017年2月。
[IoT-SECURITY] Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-the-Art and Challenges for the Internet of Things Security", Work in Progress, draft-irtf-t2trg-iot-seccons-14, April 2018.
[物联网安全]Garcia Morchon，O.，Kumar，S.，和M.Sethi，“物联网安全的现状和挑战”，正在进行的工作，草稿-irtf-t2trg-IoT-seccons-142018年4月。
[IPV6-LOWPAN-SEC] 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.
[IPV6-LOWPAN-SEC]Park，S.，Kim，K.，Haddad，W.，Chakrabarti，S.，和J.Laganier，“低功耗WPAN上的IPV6安全分析”，正在进行的工作，草稿-daniel-6lowpan-Security-Analysis-052011年3月。
[matrix-ssl] Inside Secure, "GUARD TLS Toolkit (formerly Matrix SSL)", <http://www.matrixssl.org/>.
[matrix ssl]内部安全，“GUARD TLS Toolkit（前身为matrix ssl）”<http://www.matrixssl.org/>.
[mbed] ARM Mbed, "Mbed TLS", <https://www.mbed.com/en/technologies/security/mbed-tls/>.
[mbed]手臂mbed，“mbed TLS”<https://www.mbed.com/en/technologies/security/mbed-tls/>.
[micronacl] MicroNaCl, "The Networking and Cryptography library for microcontrollers", <http://munacl.cryptojedi.org/>.
[micronacl]micronacl，“微控制器的网络和加密库”<http://munacl.cryptojedi.org/>.
[mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic curve cryptography for 8-bit and 32-bit embedded systems - time efficiency and power consumption analysis", Pomiary Automatyka Kontrola, 2010.
[mosdorf]mosdorf，M.和W.Zabolotny，“8位和32位嵌入式系统椭圆曲线密码的实现-时间效率和功耗分析”，Pomiary Automatyka Kontrola，2010年。
[MT-SenML] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", Work in Progress, draft-ietf-core-senml-15, May 2018.
[MT SenML]Jennings，C.，Shelby，Z.，Arkko，J.，Keranen，A.，和C.Bormann，“传感器测量列表（SenML）”，正在进行的工作，草案-ietf-core-SenML-15，2018年5月。
[nacl] NaCl, "Networking and Cryptography library", <http://nacl.cr.yp.to/>.
[nacl]nacl，“网络和加密库”<http://nacl.cr.yp.to/>.
[naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR Microcontrollers", International Conference on Cryptology in Africa, Computer Science, Vol. 7918, pp. 156-172, February 2013, <https://doi.org/10.1007/978-3-642-38553-7_9>.
[naclavr]Hutter，M.和P.Schwabe，“8位AVR微控制器上的NaCl”，非洲密码学国际会议，计算机科学，第7918卷，第156-172页，2013年2月<https://doi.org/10.1007/978-3-642-38553-7_9>.
[nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., and D. Culler, "The nesC language: A holistic approach to networked embedded systems", ACM SIGPLAN Notices, Vol. 38, Issue 5, DOI 10.1145/781131.781133, 2003.
[nesC]Gay，D.，Levis，P.，von Behren，R.，Welsh，M.，Brewer，E.，和D.Culler，“nesC语言：网络化嵌入式系统的整体方法”，ACM SIGPLAN Notices，第38卷，第5期，DOI 10.1145/781131.781133，2003年。
[nordic] Nordic Semiconductor, "nRF52832 Product Specification v1.3", March 2017, <http://infocenter.nordicsemi.com/pdf/ nRF52832_PS_v1.3.pdf>.
[北欧]北欧半导体，“nRF52832产品规范v1.3”，2017年3月<http://infocenter.nordicsemi.com/pdf/ nRF52832\u PS\u v1.3.pdf>。
[relic-toolkit] "relic", March 2017, <https://github.com/relic-toolkit/relic>.
[文物工具包]“文物”，2017年3月<https://github.com/relic-toolkit/relic>.
[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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 3972，DOI 10.17487/RFC3972，2005年3月<https://www.rfc-editor.org/info/rfc3972>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<https://www.rfc-editor.org/info/rfc4303>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, February 2009, <https://www.rfc-editor.org/info/rfc5406>.
[RFC5406]Bellovin，S.，“指定IPsec版本2使用的指南”，BCP 146，RFC 5406，DOI 10.17487/RFC5406，2009年2月<https://www.rfc-editor.org/info/rfc5406>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<https://www.rfc-editor.org/info/rfc5905>.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, January 2011, <https://www.rfc-editor.org/info/rfc6078>.
[RFC6078]Camarillo，G.和J.Melen，“主机身份协议（HIP）上层协议信令的即时传输（HICCup）”，RFC 6078，DOI 10.17487/RFC6078，2011年1月<https://www.rfc-editor.org/info/rfc6078>.
[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>.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, <https://www.rfc-editor.org/info/rfc6574>.
[RFC6574]Tschofenig，H.和J.Arkko，“智能对象研讨会的报告”，RFC 6574，DOI 10.17487/RFC6574，2012年4月<https://www.rfc-editor.org/info/rfc6574>.
[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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[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>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748]兰利，A.，汉堡，M.和S.特纳，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<https://www.rfc-editor.org/info/rfc7748>.
[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>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032]Josefsson，S.和I.Liusvaara，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<https://www.rfc-editor.org/info/rfc8032>.
[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>.
[rsa-8bit] Gura, N., Patel, A., Wander, A., Eberle, H., and S. Shantz, "Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs", DOI 10.1007/978-3-540-28632-5_9, 2004.
[rsa-8bit]Gura，N.，Patel，A.，Wander，A.，Eberle，H.，和S.Shantz，“在8位CPU上比较椭圆曲线密码和rsa”，DOI 10.1007/978-3-540-28632-5─9，2004年。
[rsa-high-speed] Koc, C., "High-Speed RSA Implementation", November 1994, <http://storage.jak-stik.ac.id/rsasecurity/tr201.pdf>.
[rsa high speed]Koc，C.，“高速rsa实施”，1994年11月<http://storage.jak-stik.ac.id/rsasecurity/tr201.pdf>.
[sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, January 2010.
[sec2ecc]Certicom Research，“第2节：建议的椭圆曲线域参数”，版本2.0，2010年1月。
[stnucleo] STMicroelectronics, "NUCLEO-F091RC", <http://www.st.com/en/evaluation-tools/ nucleo-f091rc.html/>.
[stnucleo]意法半导体，“核子-F091RC”<http://www.st.com/en/evaluation-tools/ nucleo-f091rc.html/>。
[tinyecc] Liu, A. and P. Nig, "TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks (Version 2.0)", NCSU College of Engineering, February 2011, <http://discovery.csc.ncsu.edu/software/TinyECC/>.
[tinyecc]Liu，A.和P.Nig，“tinyecc：无线传感器网络中椭圆曲线加密的可配置库（版本2.0）”，国立大学工程学院，2011年2月<http://discovery.csc.ncsu.edu/software/TinyECC/>.
[wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, S., Carvalho, T., Naslund, M., and R. Gold, "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds", Proceedings of the 19th International Conference on Computer Communciations and Networks, DOI 10.1109/ICCCN.2010.5560028, 2010.
[wiman]Margi，C.，Oliveira，B.，Sousa，G.，Simplicio，M.，Paulo，S.，Carvalho，T.，Naslund，M.，和R.Gold，“操作系统对无线传感器网络（安全）应用和测试床的影响”，第19届计算机通信和网络国际会议记录，DOI 10.1109/ICCCN.2010.5560028，2010年。
[wiselib] "wiselib", February 2015, <https://github.com/ibr-alg/wiselib>.
[wiselib]“wiselib”，2015年2月<https://github.com/ibr-alg/wiselib>.
Acknowledgments
致谢
The authors would like to thank Mats Naslund, Salvatore Loreto, Bob Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas, Eric Rescorla, and Tero Kivinen for interesting discussions in this problem space. The authors would also like to thank Diego Aranha for helping with the relic-toolkit configurations and Tobias Baumgartner for helping with questions regarding wiselib.
作者要感谢Mats Naslund、Salvatore Loreto、Bob Moskowitz、Oscar Novo、Vlasios Tsiasis、Daoyuan Li、Muhammad Waqas、Eric Rescorla和Tero Kivinen在这个问题空间进行了有趣的讨论。作者还想感谢迭戈·阿兰哈（Diego Aranha）对文物工具包配置的帮助，以及托比亚斯·鲍姆加特纳（Tobias Baumgartner）对有关wiselib的问题的帮助。
Tim Chown, Samita Chakrabarti, Christian Huitema, Dan Romascanu, Eric Vyncke, and Emmanuel Baccelli provided valuable comments that helped us improve this document.
Tim Chown、Samita Chakrabarti、Christian Huitema、Dan Romascanu、Eric Vyncke和Emmanuel Baccelli提供了宝贵的意见，帮助我们改进了本文件。
Authors' Addresses
作者地址
Mohit Sethi Ericsson Jorvas 02420 Finland
Mohit Sethi Ericsson Jorvas 02420芬兰
Email: mohit@piuha.net
Email: mohit@piuha.net
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
Email: jari.arkko@piuha.net
Email: jari.arkko@piuha.net
Ari Keranen Ericsson Jorvas 02420 Finland
Ari Keranen Ericsson Jorvas 02420芬兰
Email: ari.keranen@ericsson.com
Email: ari.keranen@ericsson.com
Heidi-Maria Back Nokia Helsinki 00181 Finland
海蒂·玛丽亚支持诺基亚赫尔辛基00181芬兰
Email: heidi.back@nokia.com
Email: heidi.back@nokia.com