[要約] RFC 8387は、スマートオブジェクトネットワークのセキュリティに関する実用的な考慮事項と実装経験についての要約です。このRFCの目的は、スマートオブジェクトネットワークのセキュリティに関する実践的なガイダンスを提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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では、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]を使用する方法を概説しています。 DTLSは、ペアワイズ共有キー、生の公開キー、または証明書で適用できます。すべての場合のセキュリティモデルは相互認証であるため、サーバーのIDの検証にはHTTP [RFC7230]との共通点がいくつかありますが、実際にはモデルはかなり異なります。 CoAPでのIPsecの使用は、プロトコル要件に関して説明されており、インターネットキーエクスチェンジプロトコルバージョン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 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.
[IoT-SECURITY]は、スマートオブジェクトのライフサイクルのさまざまな段階を文書化しています。次に、スマートオブジェクトのセキュリティの脅威と、これらの脅威から保護するために直面する可能性のある課題について説明します。このドキュメントでは、IKEv2 / IPsec [RFC7296]、TLS / SSL [RFC5246]、DTLS [RFC6347]、ホストアイデンティティプロトコル（HIP）[RFC7401]、HIPダイエットエクスチェンジ[HIP-DEX]、ネットワークアクセスの認証を実行するためのプロトコル（PANA）[RFC5191]、および拡張認証プロトコル（EAP）[RFC3748]。最後に、[IoT-BOOTSTRAPPING]では、リソースに制約のあるモノのインターネット（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ワークショップでのセキュリティの議論の概要を示しています。ワークショップは、適切な資格情報管理メカニズム（おそらくBluetoothペアリングメカニズムに似たもの）の開発、リソースに制約のあるデバイスでの標準的なセキュリティメカニズムの実装可能性の理解、および軽量暗号プリミティブの領域での追加調査の実施に追加の作業を行うことを推奨しました。
[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）を使用し、ハッシュ関数を排除しています。プロトコルは引き続きホストIDに基づいて動作し、ホスト間でエンドツーエンドで実行され、すべての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]は、IPv6 over Low-Powerワイヤレスパーソナルエリアネットワーク（6LoWPAN）ネットワークに関連するセキュリティ問題の包括的な分析を行いますが、その結果は、すべての低電力ネットワークにもより一般的に適用されます。このドキュメントで説明する問題には、送信ビット数を最小限に抑えて実装を簡素化する必要性、スマートオブジェクトネットワーキング環境での脅威、6LoWPANセキュリティメカニズム、IPsec、およびこれらの環境での実装に対するキー管理プロトコルの適合性が含まれます。
This section discusses three challenges: 1) implementation difficulties, 2) practical provisioning problems, and 3) layering and communication models.
このセクションでは、3つの課題について説明します。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, 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.
モノのインターネットのセキュリティで最も頻繁に議論される問題の1つは、実装の問題に関係しています。リソースに制限があり、バッテリーで動作し、安価なデバイスを構築したいという願望が、限られたプロトコルとアプリケーションスイートを備えたデバイスの作成を推進しています。典型的な制限には、HTTPの代わりにCoAPを実行すること、セキュリティメカニズムのサポートの制限、長いキーの長さの処理能力の制限、常時通信を許可しないスリープスケジュールなどがあります。さらに、デバイスは通常、構成のサポートが非常に制限されているため、シークレットとトラストアンカーを設定することが困難です。
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:
2番目の課題は、実用的なプロビジョニングの問題です。これはおそらく最も基本的で難しい問題であり、残念ながら設計ではしばしば無視されます。スマートオブジェクトネットワークのプロビジョニングと管理にはいくつかの問題があります。
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 リソースに制約のあるデバイスには、共有シークレットやその他のセキュリティ関連パラメーターのインストールに必要となる構成のための自然なユーザーインターフェイスはありません。通常、キーボードやディスプレイはなく、ボタンを押すことすらないこともあります。一部のデバイスには、ネットワークへのインターフェイスという1つのインターフェイスしかない場合があります。
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 多数のデバイスが存在する可能性があります。 1つのデバイスに対して実行したときに許容できる可能性がある構成タスクは、数十または数百のデバイスでは許容できない可能性があります。
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.
上記の課題に照らして、リソースに制約のあるデバイスは、多くの場合、単一の静的IDで出荷されます。多くの場合、これは単一の未加工の公開鍵です。これらの長期の静的IDにより、デバイス（およびその所有者）が移動したときに追跡することが容易になります。静的IDにより、攻撃者は所有権の変更全体でこれらのデバイスを追跡することもできます。
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-SENSORS]を介して情報を渡します。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]またはホストIDタグ（HIT）[RFC7401]と同様に、自己生成された安全なIDです。つまり、次のことが成立すると仮定します。
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はデバイスの安全なID、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.
セキュリティ資格情報、共有シークレット、およびポリシー情報をプロビジョニングすることは難しいため、プロビジョニングモデルは安全なIDのみに基づいています。典型的なネットワークのインストールでは、これらのデバイスのIDに注意しながら、多数のデバイスを物理的に配置します。この短い識別子のリストは、許可されたデバイスのリストとして中央サーバーに送られます。その後、少なくともデバイスからサーバーへの情報に関する限り、センサーネットワークに必要な安全な通信をデバイスと開始できます。
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.
これは、追加のプロビジョニング作業とオプションのペアリングプロトコルでサポートできます。基本的なプロビジョニングアプローチは前述のとおりです。ただし、さらに、信頼できるサーバーのIDをデバイスに通知するものも必要です。この情報を提供する方法は複数あります。簡単なアプローチの1つは、インストール時に信頼済みサーバーのIDをデバイスにフィードすることです。これには、個別のユーザーインターフェイス、ローカル接続（USBなど）、または構成のためのデバイスのネットワークインターフェイスの使用が必要です。いずれの場合も、センサーネットワークと同様に、構成情報の量は最小限に抑えられます。短いID値を1つだけ入力する必要があります（IDと証明書、または秘密にしておく必要のある共有シークレットの両方ではありません）。さらに単純なプロビジョニングアプローチは、デバイスグループ内のデバイスが相互に信頼することです。その後、インストール時に構成は必要ありません。
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.
通信に関心のある両方の当事者が他方のオフラインの予期される暗号IDを知ったら、安全な通信を開始できます。あるいは、様々なペアリングスキームを採用することができる。これらのスキームは、デバイス側ですでに安全な識別子から恩恵を受けることができることに注意してください。たとえば、サーバーは、最初の電源投入後、デバイスの公開鍵で暗号化されて誰かとペアリングされる前に、各デバイスにペアリングメッセージを送信できます。両方の共有シークレットまたは安全なIDを使用しないすべてのペアリングスキームと同様に、問題のアプリケーションに許容される場合と許容されない場合があるいくつかの脆弱性が残っています。たとえば、「信頼の飛躍」または「最初の使用時の信頼」に基づく多くのペアリング方法は、初期設定中に攻撃者が存在しないことを前提としています。したがって、それらは盗聴または中間者（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.
いずれの場合でも、安全なIDは、操作が可能な限り単純であることを保証するのに役立ちます。 IDのみをデバイスに通信する必要があり、証明書、共有シークレット、または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.
インストール時にID情報を収集する方法はいくつかあります。単純ですが完全に安全ではない方法の1つは、IDの最後の数桁がわずか数ミリメートルの小さなデバイスに印刷される方法です。あるいは、デバイスのパッケージには、製造時にデバイスから取得された完全なID（通常32桁の16進数）が含まれる場合があります。この識別情報は、たとえば、設置担当者が携帯するバーコードリーダーで読み取ることができます。 （IDは秘密ではないことに注意してください。システムのセキュリティは、他人に漏洩するID情報に依存していません。IDの実際の所有者は常に秘密鍵で所有権を証明でき、デバイスから離れることはありません。）最後に、デバイスは、有線ネットワークインターフェイス、または近接場通信（NFC）または無線周波数ID（RFID）タグなどの近接ベースの通信を使用できます。このようなインターフェースにより、インストール時に情報収集デバイスへのデバイスIDの安全な通信が可能になります。
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.
情報収集の方法に関係なく、このプロビジョニングモデルは、セキュリティのセットアップに必要な労力を最小限に抑えます。各デバイスは、ランダムで安全なキー生成プロセスで独自のIDを生成します。 IDは、通信するピアのIDがわかっている場合、ピアからのメッセージにピアの秘密鍵で署名できるという意味で自己安全です。メッセージが予期したものから送信されたことを確認するのは簡単です。ピア。 IDとそのIDの証明書を個別に構成する必要はありません。グループシークレットまたは共有シークレットを構成する必要はありません。トラストアンカーを設定する必要はありません。さらに、IDは通常、アプリケーションのために収集されます（どのセンサーがどの部屋にあるかを識別するなど）。ほとんどの状況では、セキュリティのプロビジョニングに必要な追加の構成作業は実際にはありません。
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 addresses) can be used for network communication protocols once the device is operational.
前のセクションで説明したように、長期的な静的IDは、デバイスとその所有者のプライバシーに悪影響を及ぼします。したがって、デバイスがライフサイクルの適切なタイミングで新しいIDを生成することは有益です。例としては、出荷時設定へのリセット後または所有権の引き渡し後があります。したがって、提案された展開モデルでは、デバイスは新しい非対称キーペアを生成し、新しい公開キーP 'を使用して新しいID I'を生成します。また、これらのIDは、プロビジョニング段階でのみ使用されることが望ましいです。一時的なID（動的IPv6アドレスなど）は、デバイスが操作可能になると、ネットワーク通信プロトコルに使用できます。
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:
デバイスのグループは、単一の識別子でも管理できます。これらの導入事例では、個々のデバイスを登録するのではなく、デバイスグループ全体のIDを設定することもできます。たとえば、多くのインストールでは、同じメーカーから購入したデバイスのキットを1つのパッケージで使用しています。次のように、このようなデバイスのセットにIDを提供することは簡単です。
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は個々のデバイスのID、Pdevはそのデバイスの公開キー、Potherdeviはグループ内の他のデバイスの公開キー、nはPdevを公開キーとするデバイスを除くグループ内のすべてのデバイス、 mは、グループ内のデバイスの総数です。これで、グループ（Igrp）の安全なIDを、グループ（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).
インストール担当者は、キットが入っていたボックスからグループのIDをスキャンできます。このIDは、ノードから情報を受信することが予想されるサーバーに保存できます。後で、個々のデバイスがこのサーバーに接続すると、自分の公開鍵と他のデバイスの公開鍵を公開できるため、グループの一部であることを示すことができます。キットに属していないデバイスは、グループのIDに新しいキーが追加されるとグループID（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.
上記のように、アーキテクチャの開始点は、ノードが安全なIDを自己生成し、それを帯域外で、信頼するデバイスを知る必要があるピアに伝達することです。プロトコルアーキテクチャでこのモデルをサポートするには、これらの安全なIDを使用してピア間の安全なメッセージングを実装し、システムが再生試行などのさまざまな種類の攻撃にどのように応答できるかを説明し、アーキテクチャのプロトコルレイヤーとエンドポイントを決定する必要があります。使用する必要があります。
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 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:
デプロイメント自体は、階層化およびプロトコルメカニズムに関するさまざまな設計上の選択に適しています。 [CoAP-SECURITY]は、ホップバイホップのセキュリティではなく、エンドツーエンドのデータオブジェクトセキュリティの採用に重点を置いていました。しかし、他のアプローチも可能です。たとえば、日和見モードのHIPは、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のフラッシュメモリが搭載されています。安価でエネルギー効率の高い32ビットプラットフォームが利用可能であるため、8ビットプラットフォームの選択は意外に思われるかもしれません。ただし、私たちの意図は、利用可能なリソースが最も制限されたプラットフォームで公開鍵暗号のパフォーマンスを評価することでした。 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に移植できます。また、これまでに調査された一連の楕円曲線ライブラリの中で、メモリフットプリントが最も小さいものの1つでもあります。
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 ++で記述されており、Boost / 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 [matrix-ssl]：このライブラリは、RSAやECC（商用ライセンスが必要）を含むいくつかの暗号化アルゴリズムのフットプリントの少ない実装を提供します。元の形式のライブラリは、約50 kBの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証明書の処理に必要なさまざまな暗号プリミティブを提供するオペレーティングシステムの1つです。このライブラリは、最小限のコードフットプリントでAPIを開発者に提供します。これは、ARM Cortex M0、ARM Cortex M0 +、ARM Cortex M3などのさまざまなARMプラットフォームを対象としています。
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で説明したサンプルアプリケーションが、リソースに制約のあるプラットフォームでの署名生成操作のみを必要としたためです。 AVRCryptoLib [avr-crypto-lib]を使用したRSA秘密鍵指数性能の初期結果を表1にまとめました。テストを繰り返しても結果は変わらなかった（または影響が最小限だった）ため、すべての結果は1回の実行からのものです。 。 2048ビットのキーサイズの実行時間は非常に長く、実際の展開では抑止力になります。
+--------------+------------------------+---------------------------+
| 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.6 kBで、さらに削減される可能性があります。 [rsa-high-speed]で説明されているように、実装はモンゴメリ乗算、最適化された二乗などの数学的最適化を使用せずに基本的なべき乗および乗算演算を実行することも注目に値します。 [rsa-8bit]で示されているように、より多くのRAMを使用すると、2048ビットの操作をはるかに短い時間で実行できると考えています。
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 |
+-------------+---------------+-----------------+-------------------+
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のみの形式のライブラリを使用して実験を行いました。これにより、使用可能なOSとアセンブリ命令セットの種類に関係なく、任意のプラットフォームで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 |
+-------------+---------------+-----------------+-------------------+
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のパフォーマンスを示しています。オンまたはオフにできる最適化はなかったので、結果のセットは1つしかありません。デフォルトでは、Wiselibは一部の標準SEC 2楕円曲線しかサポートしていませんが、ドメインパラメータを変更して、128、160、192ビットのすべてのSEC 2楕円曲線の結果を簡単に取得できます。すべての実験のROMサイズは16 kB未満でした。
+-------------+---------------+-----------------+-------------------+
| 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がはるかに大きくなっています。 Arlicino Megaを使用して、relic-toolkitを実験しました。繰り返しになりますが、Arduinoは便利なプロトタイピングプラットフォームであるため、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 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.
relic-toolkitの結果は、表5および6に個別に記載されています。最初の結果セットは、使用するメモリ量を考慮せずに、高速パフォーマンス用に構成されたライブラリーで実行されました。 2番目のセットでは、さまざまな曲線で必要な実行時間に関係なく、メモリ使用量が少ないようにライブラリを構成しました。ライブラリに含まれる最適化のオン/オフを切り替えることで、メモリとこれらの値の間の実行時間のトレードオフを実現できます。
+-----------------+--------------+----------------+-----------------+
| 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を使用した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 |
+-----------------+--------------+----------------+-----------------+
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など）には、ハードウェア乱数ジェネレーターがありません。このようなボードでは、暗号品質のランダム性を取得することが課題です。実際の展開では、公開鍵と秘密鍵のペアの生成などの暗号化操作をハードウェア乱数ジェネレーターに依存する必要があります。たとえば、Nordic 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]は、ARM CoretexプラットフォームでのECCのパフォーマンスも評価しました。表7に示すECDSA符号演算の結果は、128 kBのフラッシュメモリと16 kBのRAMを備えたARM Cortex-M0 + 48MHzマイクロコントローラーを備えたFreescale FRDM-KL25Zボード[freescale]で実行されます。効率的な累乗のためのスライディングウィンドウテクニックが2のウィンドウサイズで使用されました。他のすべての最適化はこれらの測定に対して無効にされました。
+------------------+---------------------+--------------------------+
| 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]は、256 kBのフラッシュメモリと32 kBのRAMを備えたARM Cortex-M0 48 MHzマイクロコントローラーを搭載したST Nucleo F091（STM32F091RCT6）ボード[stnucleo]上の曲線のパフォーマンスも測定しました。さまざまな曲線を使用した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 |
+------------------+---------------------+--------------------------+
Table 8: ECDSA Signature Performance with an ARM Mbed TLS Stack on ST Nucleo F091 (STM32F091RCT6)
表8：ST Nucleo F091（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]は、Diffie-Hellman鍵交換に高レベルの実用的なセキュリティを提供する素体（Curve25519およびCurve448）上の2つの楕円曲線を定義しています。これに対応して、エドワーズ曲線デジタル署名アルゴリズム（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 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.
NaCl [nacl]およびMicoNaCl [micronacl]ライブラリは、curve25519とのDiffie-Hellman鍵交換の非常に効率的な実装を提供することがわかりました。結果は、curve25519を備えたこれらのライブラリが、同様のレベルのセキュリティを提供する他の楕円曲線よりも優れていることを示しています。 HutterとSchwabe [naclavr]は、NaClライブラリの曲線Ed25519を使用したデータの署名に、評価に使用したのと同じマイクロコントローラー（Arduino Mega ATmega2560）で23216241サイクルしか必要ないことも示しています。これは、約1451ミリ秒の実行時間に相当します。同じレベルのセキュリティを提供する他の曲線やライブラリ（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 |
+------------------------+------------------------------------+
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 et al。 [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 periodically update the readings. All queries from the rest of the world go to the publish-subscribe broker.
このようなセンサーノードは、さまざまな方法でサポートできます。 [CoAP-SENSORS]は、初期のマルチキャストベースのアプローチでした。現在のアプリケーションでは、代わりにリソースディレクトリ[CoRE-RD]とパブリッシュサブスクライブブローカー[CoAP-BROKER]の使用に切り替えました。アーキテクチャ的には、センサーはその役割の一部をネットワーク内のノードに委任できるという考え方です。このようなネットワークノードは、ローカルリソースまたはインターネット上の何かのいずれかです。 CoAPパブリッシュサブスクライブブローカーの場合、ネットワークノードは、センサーがスリープしている間、センサーに代わってWebリソースを保持することに同意します。センサーの唯一の役割は、パブリッシュ/サブスクライブブローカーに登録し、定期的に測定値を更新することです。その他の国からのすべてのクエリは、パブリッシュ/サブスクライブブローカーに送られます。
We constructed a system with four entities:
4つのエンティティでシステムを構築しました。
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.
センサー：これは、CoAPパブリッシュ/サブスクライブブローカークライアントとrelic-toolkitを実行するArduinoベースのデバイスです。 Relicは29 kBのフラッシュメモリを使用し、シンプルなCoAPクライアントは約3 kBを使用します。
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では、センサーは最初の起動時にキーを生成し、パブリッシュサブスクライブブローカーに登録します。それらの公開鍵は、CoRE Link Formatデータ[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）のJSONオブジェクト署名および暗号化（JOSE）署名でメッセージコンテンツに署名します）ペイロード[MT-SenML]。また、センサーは、センサー測定値の署名に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 Megaボード上の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ビットマイクロコントローラーで公開鍵暗号を使用してアーキテクチャ全体を実装できることを示すことでした。記載されている値は、かなりの量でさらに改善できます。たとえば、Arduinoライブラリの一部はそのまま使用され、削除できる関数がいくつかあるため、フラッシュメモリとRAMの消費量は比較的高くなります。同様に、低メモリバージョンの代わりに、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が登場し、プログラムが容易になるだけでなく、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パワーの量に関しては、状況はあまり明確ではありません。実証された速度は、多くのアプリケーションで十分です。たとえば、時々目を覚ますセンサーは、送信しようとしているメッセージのシグネチャを計算するために、ほんの一瞬、場合によっては数秒も費やす可能性があります。セッションの開始時にのみ公開鍵暗号を使用するDTLSなどのプロトコルを使用するほとんどのアプリケーションも、これらの実行時間のいずれでも問題ありません。
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.
リソースに制約のあるデバイスでの非対称キーペア生成の徹底的なパフォーマンス評価は行いませんでしたが、そのようなデバイスが新しいキーペアを生成する可能性があることに注意しました。この操作はまれな状況（工場出荷時のリセットや所有権の変更など）でのみ発生し、プライバシーの潜在的なメリットがあるため、開発者は新しいIDを生成するメカニズムを提供する必要があります。ただし、この操作のセキュリティは暗号品質のランダム性へのアクセスに依存していることに注意することが非常に重要です。
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.
署名付きメッセージにシーケンス番号を含めると、再生保護の効果的な方法を提供できます。パブリッシュ/サブスクライブブローカーは、各着信メッセージのシーケンス番号を確認し、それが以前に確認された最も高いシーケンス番号より大きい場合にのみ受け入れる必要があります。パブリッシュサブスクライブブローカーは、シーケンス番号が既に受信されているパケット、または受信されたシーケンス番号が以前に確認された最も高いシーケンス番号よりも、事前設定されたしきい値よりも大きい場合に、パケットをドロップします。
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:
セキュリティが提供されている層を1つだけ選択すると便利です。それ以外の場合は、単純なデバイスで複数のセキュリティメカニズムを実装する必要があります。一部のコードは（アルゴリズムなどの）そのような実装間で共有できる可能性がありますが、実際のプロトコル機構を含むほとんどのコードでは共有できない可能性があります。さまざまなレイヤーを見て、選択とその意味を次に示します。
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 level of end-to-end security, it would be difficult to prevent fraudulent data submissions to the servers.
主な欠点は、最初のホップを超えるセキュリティがないことです。これは、たとえばインターネット内のサーバーと通信する多くのデバイスで問題になる可能性があります。たとえば、スマートホームの計量スケールはWLANセキュリティをサポートできますが、ある程度のエンドツーエンドのセキュリティがなければ、サーバーへの不正なデータ送信を防ぐことは困難です。
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.
もう1つの欠点は、一般的に実装されている一部のリンク層セキュリティ設計がグループシークレットを使用することです。これにより、ローカルネットワーク内のすべてのデバイス（感染したラップトップなど）が通信を攻撃できます。
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.
トランスポートレイヤーとアプリケーションレイヤー：これは、リンクレイヤーの設計と共に人気のあるもう1つのソリューションです。 HTTPを使用したTLS（HTTPS）およびCoAPを使用したDTLSは、この分野のソリューションの例であり、うまく機能することが証明されています。これらのソリューションは通常、基盤となるOSから何も想定することなく、アプリケーションで簡単に使用でき、アプリケーションで必要に応じて簡単に制御できます。主な欠点は、一般的に言えば、これらのソリューションは次のアプリケーションレベルのエンティティまでしか実行されないことです。この場合でも、プロキシを介してHTTPSを機能させることができるため、この制限は解決できません。もう1つの欠点は、リンク層、ネットワーク層、および場合によってはトランスポート層への攻撃を防ぐことができないことです。ただし、上位層が保護されている場合、そのような攻撃はせいぜいサービス拒否を引き起こす可能性があります。とにかく、サービス拒否はしばしば引き起こされる可能性があるため、これが実際の欠点であるかどうかは明らかではありません。
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.
議論する価値のある2番目のトレードオフは、単純な非対称暗号化メカニズム、単純な対称暗号化メカニズム、またはそれらの混合の使用です。
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.
一般的な暗号化コミュニティの信念に反して、対称暗号化ソリューションを大規模に展開できます。実際、暗号化セキュリティの最大の展開の1つであるセルラーネットワーク認証システムは、対称秘密に基づく加入者識別モジュール（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からわかるように、適切なキー長で非対称暗号操作の一部を計算するのに必要な時間は、かなり長くなる可能性があります。これから行うことができる2つの反対の観察があります。まず、最近の知識では、リソースに制約のあるデバイスのコンピューティングパワーは、送信パワー[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.
しかし、もう1つの観察は、非常にコストのかかる非対称操作がある場合、生成された対称鍵を使用して鍵交換を行うことは理にかなっているということです。このモデルは、DTLSや他のトランスポート層ソリューションではうまく機能しますが、特に通信するエンティティの数が2つではない場合は、データオブジェクトのセキュリティではあまり機能しません。
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 開発者は、デバイスのライフサイクル中の適切なタイミングで、たとえば、出荷時設定へのリセット後や所有権の引き渡し後などに、デバイスが新しいIDを生成するメカニズムを提供する必要があります。
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、「Performance Investigations」、2015年3月、<https://www.ietf.org/proceedings/92/slides/ 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-crypto-lib] Das Labor、「AVR-Crypto-Lib」、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-BROKER]コスター、M。、ケラネン、A.、J。ヒメネス、「制約付きアプリケーションプロトコル（CoAP）のパブリッシュ-サブスクライブブローカー」、作業中、draft-ietf-core-coap-pubsub-04 、2018年3月。
[CoAP-SECURITY] Arkko, J. and A. Keranen, "CoAP Security Architecture", Work n Progress, draft-arkko-core-security-arch-00, July 2011.
[CoAP-SECURITY] Arkko、J。およびA. Keranen、「CoAP Security Architecture」、Work n Progress、draft-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-SENSORS] Arkko、J.、Rissanen、H.、Loreto、S.、Turanyi、Z。、およびO. Novo、「Implementing Tiny COAP Sensors」、Wok in Progress、draft-arkko-core-sleepy-sensors 2011年7月1日。
[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。、コスター、M。、ボルマン、C。、ストック、P。、およびC.アムス、「CoREリソースディレクトリ」、作業中、draft-ietf-core-resource-directory- 2018年3月13日。
[freescale] ARM Mbed, "FRDM-KL25Z", <https://developer.mbed.org/platforms/KL25Z/>.
[freescale] ARM 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 Internet of Things Journal、Vol。 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 Diet EXchange（DEX）」、Work in Progress、draft-ietf-hip-dex-06、2017年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：Low-overhead freshness transmission in sensor networks」、IEEE、DOI 10.1109 / SUTC.2008.38、2008年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-BOOTSTRAPPING] Sarikaya、B.、Sethi、M。、およびA. Sangi、「Secure IoT Bootstrapping：A Survey」、Work in Progress、draft-sarikaya-t2trg-sbootstrapping-03、2017年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.
[IoT-SECURITY] Garcia-Morchon、O.、Kumar、S。、およびM. Sethi、「モノのインターネットのセキュリティの最先端と課題」、進行中の作業、draft-irtf-t2trg- iot-seccons-14、2018年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、「IPv6 over Low Power WPAN Security Analysis」、Work in Progress、draft-daniel- 6lowpan-security-analysis-05、2011年3月。
[matrix-ssl] Inside Secure, "GUARD TLS Toolkit (formerly Matrix SSL)", <http://www.matrixssl.org/>.
[matrix-ssl] Inside Secure、「GUARD TLS Toolkit（formerly Matrix SSL）」、<http://www.matrixssl.org/>。
[mbed] ARM Mbed, "Mbed TLS", <https://www.mbed.com/en/technologies/security/mbed-tls/>.
[mbed] ARM 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]ジェニングス、C。、シェルビー、Z。、アルコ、J。、ケラネン、A。、およびC.ボーマン、「センサー測定リスト（SenML）」、作業中、draft-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」、アフリカの暗号学に関する国際会議、コンピューターサイエンス、Vol。 7918、pp。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通知、Vol。 38、Issue 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>.
[nordic] Nordic Semiconductor、「nRF52832 Product Specification v1.3」、2017年3月、<http://infocenter.nordicsemi.com/pdf/ nRF52832_PS_v1.3.pdf>。
[relic-toolkit] "relic", March 2017, <https://github.com/relic-toolkit/relic>.
[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、編、「Extensible Authentication Protocol（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。、「Cryptographically Generated Addresses（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.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<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]ケント、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、「Protocol for Carrying Authentication for Network Access（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、「The Transport Layer Security（TLS）Protocol Version 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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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）即時キャリッジおよび上位層プロトコルシグナリング（HICCUPS）の伝達」、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、「Datagram Transport Layer Security Version 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、「Report from the Smart Object Workshop」、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。、「Constrained RESTful Environments（CoRE）Link Format」、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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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、「The Constrained Application Protocol（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、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年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。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 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.崎村、「JSON Web Signature（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。、「Minimal Internet Key Exchange Version 2（IKEv2）Initiator Implementation」、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、「Edwards-Curve Digital Signature Algorithm（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 Object Signing and Encryption（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、「SEC 2：Recommended Elliptic Curve Domain Parameters」、バージョン2.0、2010年1月。
[stnucleo] STMicroelectronics, "NUCLEO-F091RC", <http://www.st.com/en/evaluation-tools/ nucleo-f091rc.html/>.
[stnucleo] STMicroelectronics、「NUCLEO-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：A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks（Version 2.0）」、NCSU College of Engineering、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 Tsiatsis、Daoyuan Li、Muhammad Waqas、Eric Rescorla、Tero Kivinenに感謝します。著者は、レリックツールキットの構成を支援してくれたDiego Aranhaと、wiselibに関する質問を支援してくれたTobias Baumgartnerにも感謝したいと思います。
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
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
Email: jari.arkko@piuha.net
Ari Keranen Ericsson Jorvas 02420 Finland
あり けらねん えりｃっそん じょｒゔぁｓ ０２４２０ ふぃんぁんｄ
Email: ari.keranen@ericsson.com
Heidi-Maria Back Nokia Helsinki 00181 Finland
ハイジマリアバックノキアヘルシンキ00181フィンランド
Email: heidi.back@nokia.com