[要約] 要約：RFC 8576は、IoTセキュリティの現状と課題についての情報を提供する。IoTのセキュリティに関する最新の状況と課題を理解するためのガイドラインとして役立つ。目的：RFC 8576の目的は、IoTセキュリティに関する情報を提供し、セキュリティの課題を理解し、適切な対策を講じるためのガイドラインを提供すること。
Internet Research Task Force (IRTF) O. Garcia-Morchon
Request for Comments: 8576 Philips
Category: Informational S. Kumar
ISSN: 2070-1721 Signify
M. Sethi
Ericsson
April 2019
Internet of Things (IoT) Security: State of the Art and Challenges
モノのインターネット（IoT）のセキュリティ：最先端の技術と課題
Abstract
概要
The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
モノのインターネット（IoT）の概念は、標準のインターネットプロトコルを使用して、人間とモノ、モノとモノのコミュニケーションを可能にすることを指します。 IoTシステムのセキュリティニーズはよく認識されており、セキュリティを提供するための多くの標準化手順が実行されています。たとえば、データグラムトランスポート層セキュリティ（DTLS）で保護されたConstrained Application Protocol（CoAP）の仕様。ただし、適切なソリューションが不足しているユースケースがあるだけでなく、多くのIoTデバイスおよびシステムが非常に限られたセキュリティ機能で設計および導入されているため、セキュリティの課題は依然として存在しています。このドキュメントでは、最初にモノのライフサイクルのさまざまな段階について説明します。次に、モノに対するセキュリティの脅威と、これらの脅威から保護するために直面する可能性のある課題を文書化します。最後に、安全なIoTシステムの導入を促進するために必要な次のステップについて説明します。このドキュメントは、IoT仕様の実装者と作成者が、特定のセキュリティの課題、脅威モデル、緩和策を文書化しながら、セキュリティに関する考慮事項の詳細を参照するために使用できます。
This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).
このドキュメントは、IRTF Thing-to-Thing Research Group（T2TRG）の製品です。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8576.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8576で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . . . 5
3. Security Threats and Managing Risk . . . . . . . . . . . . . 8
4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 13
4.1. IP-Based IoT Protocols and Standards . . . . . . . . . . 13
4.2. Existing IP-Based Security Protocols and Solutions . . . 16
4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 18
5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 21
5.1. Constraints and Heterogeneous Communication . . . . . . . 21
5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 21
5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 22
5.1.3. End-to-End Security, Protocol Translation, and the
Role of Middleboxes . . . . . . . . . . . . . . . . . 23
5.1.4. New Network Architectures and Paradigm . . . . . . . 25
5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 25
5.3. Operational Challenges . . . . . . . . . . . . . . . . . 25
5.3.1. Group Membership and Security . . . . . . . . . . . . 26
5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 27
5.4. Secure Software Update and Cryptographic Agility . . . . 27
5.5. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Verifying Device Behavior . . . . . . . . . . . . . . . . 30
5.7. Testing: Bug Hunting and Vulnerabilities . . . . . . . . 31
5.8. Quantum-Resistance . . . . . . . . . . . . . . . . . . . 32
5.9. Privacy Protection . . . . . . . . . . . . . . . . . . . 33
5.10. Reverse-Engineering Considerations . . . . . . . . . . . 34
5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 35
6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Informative References . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
The Internet of Things (IoT) denotes the interconnection of highly heterogeneous networked entities and networks that follow a number of different communication patterns, such as: human-to-human (H2H), human-to-thing (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term "IoT" was first coined in 1999 by the Auto-ID center [AUTO-ID], which had envisioned a world where every physical object has a radio-frequency identification (RFID) tag with a globally unique identifier. This would not only allow tracking of objects in real time but also allow querying of data about them over the Internet. However, since then, the meaning of the Internet of Things has expanded and now encompasses a wide variety of technologies, objects, and protocols. It is not surprising that the IoT has received significant attention from the research community to (re)design, apply, and use standard Internet technology and protocols for the IoT.
モノのインターネット（IoT）とは、人から人へ（H2H）、人から物へ（H2T）、物から人へなど、さまざまな通信パターンに従う高度に異種のネットワークエンティティとネットワークの相互接続を意味します-thing（T2T）、またはthing-to-things（T2T）。 「IoT」という用語は、すべての物理的オブジェクトがグローバルに一意の識別子を持つ無線周波数識別（RFID）タグを持つ世界を想定していたAuto-IDセンター[AUTO-ID]によって1999年に最初に作られた。これにより、オブジェクトをリアルタイムで追跡できるだけでなく、インターネットを介してオブジェクトに関するデータを照会することもできます。しかし、それ以来、モノのインターネットの意味は拡大し、現在ではさまざまなテクノロジー、オブジェクト、プロトコルが含まれています。 IoTがIoTの標準のインターネット技術とプロトコルを（再）設計、適用、および使用することについて研究コミュニティから大きな注目を集めたことは当然のことです。
The things that are part of the Internet of Things are computing devices that understand and react to the environment they reside in. These things are also often referred to as smart objects or smart devices. The introduction of IPv6 [RFC6568] and CoAP [RFC7252] as fundamental building blocks for IoT applications allows connecting IoT hosts to the Internet. This brings several advantages, including: (i) a homogeneous protocol ecosystem that allows simple integration with other Internet hosts; (ii) simplified development for devices that significantly vary in their capabilities; (iii) a unified interface for applications, removing the need for application-level proxies. These building blocks greatly simplify the deployment of the envisioned scenarios, which range from building automation to production environments and personal area networks.
モノのインターネットの一部であるものは、それらが存在する環境を理解してそれに反応するコンピューティングデバイスです。これらのものは、スマートオブジェクトまたはスマートデバイスとも呼ばれます。 IoTアプリケーションの基本的なビルディングブロックとしてIPv6 [RFC6568]とCoAP [RFC7252]を導入すると、IoTホストをインターネットに接続できます。これには、次のようないくつかの利点があります。（i）他のインターネットホストとの簡単な統合を可能にする同種のプロトコルエコシステム。 （ii）機能が大幅に異なるデバイスの開発を簡素化。 （iii）アプリケーションレベルのプロキシの必要性を排除し、アプリケーションの統合インターフェース。これらのビルディングブロックは、ビルディングオートメーションから本番環境やパーソナルエリアネットワークまで、想定されるシナリオの展開を大幅に簡素化します。
This document presents an overview of important security aspects for the Internet of Things. We begin by discussing the lifecycle of a thing in Section 2. In Section 3, we discuss security threats for the IoT and methodologies for managing these threats when designing a secure system. Section 4 reviews existing IP-based (security) protocols for the IoT and briefly summarizes existing guidelines and regulations. Section 5 identifies remaining challenges for a secure IoT and discusses potential solutions. Section 6 includes final remarks and conclusions. This document can be used by IoT standards specifications as a reference for details about security considerations that apply to the specified system or protocol.
このドキュメントでは、モノのインターネットのセキュリティに関する重要な側面の概要を示します。セクション2では、モノのライフサイクルについて説明します。セクション3では、IoTのセキュリティ脅威と、安全なシステムを設計する際にこれらの脅威を管理する方法論について説明します。セクション4では、IoT用の既存のIPベース（セキュリティ）プロトコルをレビューし、既存のガイドラインと規制を簡単に要約します。セクション5では、安全なIoTの残りの課題を特定し、潜在的なソリューションについて説明します。セクション6には、最終的な発言と結論が含まれています。このドキュメントは、指定されたシステムまたはプロトコルに適用されるセキュリティの考慮事項の詳細についてのリファレンスとして、IoT標準仕様で使用できます。
The first draft version of this document was submitted in March 2011. Initial draft versions of this document were presented and discussed during the meetings of the Constrained RESTful Environments (CORE) Working Group at IETF 80 and later. Discussions on security lifecycle at IETF 92 (March 2015) evolved into more general security considerations. Thus, the draft was selected to address the T2TRG work item on the security considerations and challenges for the Internet of Things. Further updates of the draft were presented and discussed during the T2TRG meetings at IETF 96 (July 2016) and IETF 97 (November 2016) and at the joint interim meeting in Amsterdam (March 2017). This document has been reviewed by, commented on, and discussed extensively for a period of nearly six years by a vast majority of the T2TRG and related group members, the number of which certainly exceeds 100 individuals. It is the consensus of T2TRG that the security considerations described in this document should be published in the IRTF Stream of the RFC series. This document does not constitute a standard.
このドキュメントの最初のドラフトバージョンは2011年3月に提出されました。このドキュメントの最初のドラフトバージョンは、IETF 80以降の制約付きRESTful環境（CORE）ワーキンググループのミーティング中に提示され、議論されました。 IETF 92（2015年3月）でのセキュリティライフサイクルに関する議論は、より一般的なセキュリティの考慮事項に発展しました。したがって、ドラフトは、モノのインターネットのセキュリティに関する考慮事項と課題に関するT2TRG作業項目に対処するために選択されました。 IETF 96（2016年7月）とIETF 97（2016年11月）でのT2TRG会議、およびアムステルダムでの合同中間会議（2017年3月）で、草案の更なる更新が提示され、議論されました。このドキュメントは、T2TRGと関連グループのメンバーの大多数によって、ほぼ6年間にわたってレビュー、コメント、および広範囲にわたって議論されており、その数は確かに100人を超えています。このドキュメントで説明されているセキュリティに関する考慮事項は、RFCシリーズのIRTFストリームで公開する必要があるというのがT2TRGの合意です。この文書は標準を構成するものではありません。
The lifecycle of a thing refers to the operational phases of a thing in the context of a given application or use case. Figure 1 shows the generic phases of the lifecycle of a thing. This generic lifecycle is applicable to very different IoT applications and scenarios. For instance, [RFC7744] provides an overview of relevant IoT use cases.
モノのライフサイクルは、特定のアプリケーションまたはユースケースのコンテキストにおけるモノの運用フェーズを指します。図1は、モノのライフサイクルの一般的なフェーズを示しています。この一般的なライフサイクルは、非常に異なるIoTアプリケーションとシナリオに適用できます。たとえば、[RFC7744]は、関連するIoTの使用例の概要を提供します。
In this document, we consider a Building Automation and Control (BAC) system to illustrate the lifecycle and the meaning of these different phases. A BAC system consists of a network of interconnected nodes that performs various functions in the domains of Heating, Ventilating, and Air Conditioning (HVAC), lighting, safety, etc. The nodes vary in functionality, and a large majority of them represent resource-constrained devices such as sensors and luminaries. Some devices may be battery operated or may rely on energy harvesting. This requires us to also consider devices that sleep during their operation to save energy. In our BAC scenario, the life of a thing starts when it is manufactured. Due to the different application areas (i.e., HVAC, lighting, or safety), nodes/things are tailored to a specific task. It is therefore unlikely that one single manufacturer will create all nodes in a building. Hence, interoperability as well as trust bootstrapping between nodes of different vendors is important.
このドキュメントでは、ビルディングオートメーションおよび制御（BAC）システムを検討して、これらのさまざまなフェーズのライフサイクルと意味を説明します。 BACシステムは、暖房、換気、および空調（HVAC）、照明、安全などのドメインでさまざまな機能を実行する相互接続されたノードのネットワークで構成されます。ノードは機能が異なり、それらの大多数はリソースを表します。センサーや照明器具などの制約のあるデバイス。一部のデバイスは、バッテリーで動作する場合や、環境発電に依存している場合があります。これには、エネルギーを節約するために、動作中にスリープするデバイスも考慮する必要があります。私たちのBACシナリオでは、モノの寿命は製造時に始まります。さまざまなアプリケーション領域（つまり、HVAC、照明、安全性）により、ノード/モノは特定のタスクに合わせて調整されます。したがって、単一の製造業者が建物内にすべてのノードを作成することはほとんどありません。したがって、相互運用性と、異なるベンダーのノード間のブートストラップを信頼することが重要です。
The thing is later installed and commissioned within a network by an installer during the bootstrapping phase. Specifically, the device identity and the secret keys used during normal operation may be provided to the device during this phase. Different subcontractors may install different IoT devices for different purposes. Furthermore, the installation and bootstrapping procedures may not be a discrete event and may stretch over an extended period. After being bootstrapped, the device and the system of things are in operational mode and execute the functions of the BAC system. During this operational phase, the device is under the control of the system owner and used by multiple system users. For devices with lifetimes spanning several years, occasional maintenance cycles may be required. During each maintenance phase, the software on the device can be upgraded, or applications running on the device can be reconfigured. The maintenance tasks can be performed either locally or from a backend system. Depending on the operational changes to the device, it may be required to rebootstrap at the end of a maintenance cycle. The device continues to loop through the operational phase and the eventual maintenance phases until the device is decommissioned at the end of its lifecycle. However, the end-of-life of a device does not necessarily mean that it is defective; rather, it denotes a need to replace and upgrade the network to next-generation devices for additional functionality. Therefore, the device can be removed and recommissioned to be used in a different system under a different owner, thereby starting the lifecycle all over again.
事物は後でブートストラップ段階でインストーラーによってネットワーク内にインストールされ、コミッショニングされます。具体的には、通常の動作中に使用されるデバイスIDと秘密鍵が、このフェーズ中にデバイスに提供されます。請負業者が異なれば、目的に応じて異なるIoTデバイスをインストールできます。さらに、インストールとブートストラップの手順は、個別のイベントではなく、長期間にわたる場合があります。ブートストラップされた後、デバイスとモノのシステムは動作モードになり、BACシステムの機能を実行します。この運用段階では、デバイスはシステム所有者の制御下にあり、複数のシステムユーザーによって使用されます。寿命が数年にわたるデバイスの場合、不定期のメンテナンスサイクルが必要になることがあります。各メンテナンスフェーズで、デバイスのソフトウェアをアップグレードしたり、デバイスで実行されているアプリケーションを再構成したりできます。メンテナンスタスクは、ローカルまたはバックエンドシステムから実行できます。デバイスの運用上の変更によっては、メンテナンスサイクルの最後に再起動する必要がある場合があります。デバイスは、ライフサイクルの最後に使用停止になるまで、運用フェーズと最終的なメンテナンスフェーズをループし続けます。ただし、デバイスの寿命が尽きても、必ずしも欠陥があるとは限りません。むしろ、追加機能のためにネットワークを交換して次世代デバイスにアップグレードする必要があることを示しています。したがって、デバイスを取り外し、別のシステムで別の所有者のもとで使用できるように再稼働させることで、ライフサイクルを最初からやり直すことができます。
We note that the presented lifecycle represents to some extent a simplified model. For instance, it is possible to argue that the lifecycle does not start when a tangible device is manufactured but rather when the oldest bit of code that ends up in the device -- maybe from an open-source project or the operating system -- was written. Similarly, the lifecycle could also include an on-the-shelf phase where the device is in the supply chain before an owner/user purchases and installs it. Another phase could involve the device being rebadged by some vendor who is not the original manufacturer. Such phases can significantly complicate other phases such as maintenance and bootstrapping. Finally, other potential end states can be, e.g., a vendor that no longer supports a device type because it is at the end of its life or a situation in which a device is simply forgotten but remains functional.
提示されたライフサイクルは、ある程度簡略化されたモデルを表すことに注意してください。たとえば、有形のデバイスが製造されたときにライフサイクルが開始するのではなく、デバイスに到達する最も古いコードが（おそらくオープンソースプロジェクトまたはオペレーティングシステムから）発生したときに、ライフサイクルが開始したと主張することは可能です。書かれた。同様に、ライフサイクルには、所有者/ユーザーがデバイスを購入してインストールする前のデバイスがサプライチェーンにある、既製の段階を含めることもできます。別のフェーズでは、元の製造元ではない一部のベンダーによってデバイスがリバッジされる可能性があります。このようなフェーズは、メンテナンスやブートストラップなどの他のフェーズを非常に複雑にする可能性があります。最後に、他の潜在的な最終状態としては、たとえば、デバイスタイプが寿命に達したためにデバイスタイプをサポートしなくなったベンダーや、デバイスが単に忘れられたが機能的なままである状況が考えられます。
_Manufactured _SW update _Decommissioned
/ / /
| _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced
| | _Commissioned | | | |
| | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | |
| | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>>
\/ \______________/ \/ \_____________/ \___/ time //
/ / \ \ \
Bootstrapping / Maintenance & \ Maintenance &
/ rebootstrapping \ rebootstrapping
Operational Operational
Figure 1: The Lifecycle of a Thing in the Internet of Things
図1：モノのインターネットにおけるモノのライフサイクル
Security is a key requirement in any communication system. However, security is an even more critical requirement in real-world IoT deployments for several reasons. First, compromised IoT systems can not only endanger the privacy and security of a user but can also cause physical harm. This is because IoT systems often comprise sensors, actuators, and other connected devices in the physical environment of the user that could adversely affect the user if they are compromised. Second, a vulnerable IoT system means that an attacker can alter the functionality of a device from a given manufacturer. This not only affects the manufacturer's brand image but can also leak information that is very valuable for the manufacturer (such as proprietary algorithms). Third, the impact of attacking an IoT system goes beyond a specific device or an isolated system, since compromised IoT systems can be misused at scale. For example, they may be used to perform a Distributed Denial of Service (DDoS) attack that limits the availability of other networks and services. The fact that many IoT systems rely on standard IP protocols allows for easier system integration, but this also makes attacks on standard IP protocols widely applicable in other environments. This results in new requirements regarding the implementation of security.
セキュリティは、どの通信システムでも重要な要件です。ただし、セキュリティは、いくつかの理由により、実際のIoT展開ではさらに重要な要件です。第1に、侵害されたIoTシステムは、ユーザーのプライバシーとセキュリティを危険にさらすだけでなく、物理的な危害を引き起こす可能性があります。これは、IoTシステムがユーザーの物理的環境にセンサー、アクチュエーター、およびその他の接続されたデバイスを備えている場合が多いためです。次に、脆弱なIoTシステムは、攻撃者が特定の製造元のデバイスの機能を変更できることを意味します。これは、製造元のブランドイメージに影響を与えるだけでなく、製造元にとって非常に貴重な情報（独自のアルゴリズムなど）を漏洩する可能性もあります。第3に、侵害されたIoTシステムは大規模に悪用される可能性があるため、IoTシステムへの攻撃の影響は、特定のデバイスまたは分離されたシステムを超えます。たとえば、他のネットワークやサービスの可用性を制限する分散サービス拒否（DDoS）攻撃を実行するために使用される可能性があります。多くのIoTシステムが標準IPプロトコルに依存しているため、システム統合が容易になりますが、これにより、標準IPプロトコルへの攻撃が他の環境にも広く適用されるようになります。これにより、セキュリティの実装に関する新しい要件が発生します。
The term "security" subsumes a wide range of primitives, protocols, and procedures. For instance, it includes services such as confidentiality, authentication, integrity, authorization, source authentication, and availability. It often also includes augmented services such as duplicate detection and detection of stale packets (timeliness). These security services can be implemented through a combination of cryptographic mechanisms such as block ciphers, hash functions, and signature algorithms, as well as noncryptographic mechanisms that implement authorization and other aspects of security-policy enforcement. For ensuring security in IoT networks, one should not only focus on the required security services but also pay special attention to how the services are realized in the overall system.
「セキュリティ」という用語は、幅広いプリミティブ、プロトコル、および手順を包括しています。たとえば、機密性、認証、整合性、承認、ソース認証、可用性などのサービスが含まれます。多くの場合、重複検出や古いパケットの検出（適時性）などの拡張サービスも含まれます。これらのセキュリティサービスは、ブロック暗号、ハッシュ関数、署名アルゴリズムなどの暗号化メカニズムと、認証およびセキュリティポリシー実施の他の側面を実装する非暗号化メカニズムの組み合わせを通じて実装できます。 IoTネットワークのセキュリティを確保するには、必要なセキュリティサービスだけでなく、システム全体でサービスがどのように実現されるかに特に注意を払う必要があります。
Security threats in related IP protocols have been analyzed in multiple documents, including Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained Application Protocol (CoAP) [RFC7252], IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6 Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying Authentication and Network Access (PANA) [RFC4016]. In this section, we specifically discuss the threats that could compromise an individual thing or the network as a whole. Some of these threats might go beyond the scope of Internet protocols, but we gather them here for the sake of completeness. The threats in the following list are not in any particular order, and some threats might be more critical than others, depending on the deployment scenario under consideration:
関連するIPプロトコルのセキュリティの脅威は、トランスポート層セキュリティ（TLS）（HTTPS）上のハイパーテキスト転送プロトコル（HTTP）[RFC2818]、制約付きアプリケーションプロトコル（CoAP）[RFC7252]、低電力ワイヤレス上のIPv6など、複数のドキュメントで分析されていますパーソナルエリアネットワーク（6LoWPAN）[RFC4919]、アクセスノード制御プロトコル（ANCP）[RFC5713]、ドメインネームシステム（DNS）[RFC3833]、IPv6近隣探索（ND）[RFC3756]、および認証とネットワークアクセスを実行するためのプロトコル（ PANA）[RFC4016]。このセクションでは、個別のものまたはネットワーク全体を危険にさらす可能性がある脅威について具体的に説明します。これらの脅威の一部はインターネットプロトコルの範囲を超える可能性がありますが、完全を期すためにここにまとめます。次のリストの脅威は特定の順序ではなく、検討中の展開シナリオによっては、いくつかの脅威は他のものよりも重大である可能性があります。
1. Vulnerable software/code: Things in the Internet of Things rely on software that might contain severe bugs and/or bad design choices. This makes the things vulnerable to many different types of attacks, depending on the criticality of the bugs, e.g., buffer overflows or lack of authentication. This can be considered one of the most important security threats. The large-scale Distributed Denial of Service (DDoS) attack, popularly known as the Mirai botnet [Mirai], was caused by things that had well-known or easy-to-guess passwords for configuration.
1. 脆弱なソフトウェア/コード：モノのインターネットのモノは、深刻なバグや不適切な設計の選択を含む可能性のあるソフトウェアに依存しています。これにより、バッファオーバーフローや認証の欠如など、バグの重要度に応じて、さまざまな種類の攻撃に対して脆弱になります。これは、最も重要なセキュリティ脅威の1つと見なすことができます。一般にMiraiボットネット[Mirai]として知られている大規模な分散型サービス拒否（DDoS）攻撃は、構成用のよく知られた、または推測しやすいパスワードが原因で発生しました。
2. Privacy threat: The tracking of a thing's location and usage may pose a privacy risk to people around it. For instance, an attacker can infer privacy-sensitive information from the data gathered and communicated by individual things. Such information may subsequently be sold to interested parties for marketing purposes and targeted advertising. In extreme cases, such information might be used to track dissidents in oppressive regimes. Unlawful surveillance and interception of traffic to/ from a thing by intelligence agencies is also a privacy threat.
2. プライバシーの脅威：モノの場所と使用状況の追跡は、周囲の人々にプライバシーのリスクをもたらす可能性があります。たとえば、攻撃者は、個人的な事柄によって収集および通信されたデータからプライバシーの機密情報を推測できます。そのような情報は、マーケティング目的およびターゲット広告のために、その後利害関係者に販売される可能性があります。極端な場合には、そのような情報は、抑圧的な体制の反体制派を追跡するために使用される可能性があります。諜報機関によるモノへの/からのトラフィックの違法な監視と傍受もプライバシーの脅威です。
3. Cloning of things: During the manufacturing process of a thing, an untrusted factory can easily clone the physical characteristics, firmware/software, or security configuration of the thing. Deployed things might also be compromised and their software reverse engineered, allowing for cloning or software modifications. Such a cloned thing may be sold at a cheaper price in the market and yet can function normally as a genuine thing. For example, two cloned devices can still be associated and work with each other. In the worst-case scenario, a cloned device can be used to control a genuine device or perform an attack. One should note here that an untrusted factory may also change functionality of the cloned thing, resulting in degraded functionality with respect to the genuine thing (thereby inflicting potential damage to the reputation of the original thing manufacturer). Moreover, additional functionality can be introduced in the cloned thing. An example of such functionality is a backdoor.
3.モノの複製：モノの製造プロセス中に、信頼できない工場がモノの物理的特性、ファームウェア/ソフトウェア、またはセキュリティ構成を簡単に複製できます。デプロイされたものも危険にさらされ、ソフトウェアがリバースエンジニアリングされて、クローン作成またはソフトウェアの変更が可能になる場合があります。このような複製物は、市場で安く売れるかもしれないが、本物としては正常に機能する。たとえば、2つの複製されたデバイスを関連付けて、互いに連携させることができます。最悪のシナリオでは、クローンデバイスを使用して、正規のデバイスを制御したり、攻撃を実行したりできます。ここで、信頼されていないファクトリは、複製されたモノの機能も変更し、その結果、本物に関して機能が低下する可能性があることに注意してください（その結果、元のモノの製造元の評判が損なわれる可能性があります）。さらに、クローンされたものに追加機能を導入できます。このような機能の例として、バックドアがあります。
4. Malicious substitution of things: During the installation of a thing, a genuine thing may be replaced by a similar variant (of lower quality) without being detected. The main motivation may be cost savings, where the installation of lower-quality things (for example, noncertified products) may significantly reduce the installation and operational costs. The installers can subsequently resell the genuine things to gain further financial benefits. Another motivation may be to inflict damage to the reputation of a competitor's offerings.
4. 悪意のあるモノの置換：モノのインストール中に、本物のモノが検出されずに（品質の低い）同様の亜種に置き換えられる可能性があります。主な動機はコストの節約である可能性があり、品質の低いもの（たとえば、認定されていない製品）をインストールすると、インストールおよび運用コストを大幅に削減できます。設置者は、本物を再販して、さらなる経済的利益を得ることができます。もう1つの動機は、競合他社の提供物の評判にダメージを与えることである可能性があります。
5. Eavesdropping attack: During the commissioning of a thing into a network, it may be susceptible to eavesdropping, especially if operational keying materials, security parameters, or configuration settings are exchanged in the clear using a wireless medium or if used cryptographic algorithms are not suitable for the envisioned lifetime of the device and the system. After obtaining the keying material, the attacker might be able to recover the secret keys established between the communicating entities, thereby compromising the authenticity and confidentiality of the communication channel, as well as the authenticity of commands and other traffic exchanged over this communication channel. When the network is in operation, T2T communication can be eavesdropped if the communication channel is not sufficiently protected or if a session key is compromised due to protocol weaknesses. An adversary may also be able to eavesdrop if keys are not renewed or updated appropriately. Lastly, messages can also be recorded and decrypted offline at a later point of time. The VENONA project [venona-project] is one such example where messages were recorded for offline decryption.
5. 盗聴攻撃：モノのネットワークへのコミッショニング中に、特に無線メディアを使用して平文で操作用の鍵素材、セキュリティパラメータ、または構成設定が交換された場合、または使用されている暗号アルゴリズムが適切でない場合、盗聴の影響を受ける可能性がありますデバイスとシステムの想定寿命。キー情報を取得した後、攻撃者は通信エンティティ間で確立された秘密キーを復元できるため、通信チャネルの信頼性と機密性、およびこの通信チャネルを介して交換されるコマンドとその他のトラフィックの信頼性が損なわれる可能性があります。ネットワークが動作しているときに、通信チャネルが十分に保護されていない場合、またはプロトコルの脆弱性が原因でセッションキーが危険にさらされている場合、T2T通信が盗聴される可能性があります。キーが適切に更新または更新されていない場合、攻撃者も盗聴できる可能性があります。最後に、メッセージはオフラインで記録および復号化することもできます。 VENONAプロジェクト[venona-project]は、オフラインでの復号化のためにメッセージが記録された例の1つです。
6. Man-in-the-middle attack: Both the commissioning and operational phases may be vulnerable to man-in-the-middle attacks. For example, when keying material between communicating entities is exchanged in the clear, the security of the key establishment protocol depends on the tacit assumption that no third party can eavesdrop during the execution of this protocol. Additionally, device authentication or device authorization may be nontrivial or need the support of a human decision process, since things usually do not have a priori knowledge about each other and cannot always differentiate friends and foes via completely automated mechanisms.
6. 中間者攻撃：コミッショニング段階と運用段階の両方が中間者攻撃に対して脆弱である可能性があります。たとえば、通信エンティティ間でキーイング情報が平文で交換される場合、キー確立プロトコルのセキュリティは、このプロトコルの実行中に第三者が盗聴できないという暗黙の仮定に依存します。さらに、通常、物事は互いに関する事前の知識を持たず、完全に自動化されたメカニズムを介して友人と敵を常に区別できるとは限らないため、デバイス認証またはデバイス承認は重要ではないか、人間の決定プロセスのサポートを必要とする場合があります。
7. Firmware attacks: When a thing is in operation or maintenance phase, its firmware or software may be updated to allow for new functionality or new features. An attacker may be able to exploit such a firmware upgrade by maliciously replacing the thing's firmware, thereby influencing its operational behavior. For example, an attacker could add a piece of malicious code to the firmware that will cause it to periodically report the energy usage of the thing to a data repository for analysis. The attacker can then use this information to determine when a home or enterprise (where the thing is installed) is unoccupied and break in. Similarly, devices whose software has not been properly maintained and updated might contain vulnerabilities that might be exploited by attackers to replace the firmware on the device.
7. ファームウェア攻撃：物事が運用または保守フェーズにある場合、そのファームウェアまたはソフトウェアは、新しい機能または新しい機能を許可するように更新される可能性があります。攻撃者は、物事のファームウェアを悪意を持って置き換えることにより、そのようなファームウェアアップグレードを悪用し、その動作に影響を与える可能性があります。たとえば、攻撃者は、悪意のあるコードをファームウェアに追加する可能性があり、これにより、モノのエネルギー使用量が分析のためにデータリポジトリに定期的に報告されます。その後、攻撃者はこの情報を使用して、家または企業（モノがインストールされている場所）が占有されて侵入する時期を判断できます。同様に、ソフトウェアが適切に保守および更新されていないデバイスには、攻撃者が悪用して置き換えられる脆弱性が含まれている可能性がありますデバイスのファームウェア。
8. Extraction of private information: IoT devices (such as sensors, actuators, etc.) are often physically unprotected in their ambient environment, and they could easily be captured by an attacker. An attacker with physical access may then attempt to extract private information such as keys (for example, a group key or the device's private key), data from sensors (for example, healthcare status of a user), configuration parameters (for example, the Wi-Fi key), or proprietary algorithms (for example, the algorithm performing some data analytics task). Even when the data originating from a thing is encrypted, attackers can perform traffic analysis to deduce meaningful information, which might compromise the privacy of the thing's owner and/or user.
8. 個人情報の抽出：IoTデバイス（センサー、アクチュエーターなど）は、周囲の環境で物理的に保護されていないことが多く、攻撃者によって簡単にキャプチャされる可能性があります。物理的なアクセスを持つ攻撃者は、キー（たとえば、グループキーまたはデバイスのプライベートキー）、センサーからのデータ（たとえば、ユーザーのヘルスケアステータス）、構成パラメーター（たとえば、 Wi-Fiキー）、または独自のアルゴリズム（たとえば、一部のデータ分析タスクを実行するアルゴリズム）。モノに由来するデータが暗号化されている場合でも、攻撃者はトラフィック分析を実行して意味のある情報を推測できるため、モノの所有者やユーザーのプライバシーが侵害される可能性があります。
9. Routing attack: As highlighted in [Daniel], routing information in IoT networks can be spoofed, altered, or replayed, in order to create routing loops, attract/repel network traffic, extend/ shorten source routes, etc. A nonexhaustive list of routing attacks includes:
9. ルーティング攻撃：[Daniel]で強調されているように、ルーティングループの作成、ネットワークトラフィックの誘引/反発、ソースルートの延長/短縮などのために、IoTネットワークのルーティング情報を偽装、変更、または再生できます。ルーティングの完全ではないリスト攻撃には以下が含まれます：
a. Sinkhole attack (or blackhole attack), where an attacker declares himself to have a high-quality route/path to the base station, thus allowing him to do manipulate all packets passing through it.
a. シンクホール攻撃（またはブラックホール攻撃）。攻撃者は、基地局への高品質のルート/パスを持っていると宣言し、通過するすべてのパケットを操作できるようにします。
b. Selective forwarding, where an attacker may selectively forward packets or simply drop a packet.
b. 選択的転送。攻撃者はパケットを選択的に転送するか、単にパケットをドロップする可能性があります。
c. Wormhole attack, where an attacker may record packets at one location in the network and tunnel them to another location, thereby influencing perceived network behavior and potentially distorting statistics, thus greatly impacting the functionality of routing.
c. ワームホール攻撃。攻撃者はネットワーク内の1つの場所でパケットを記録し、それらを別の場所にトンネリングする可能性があり、知覚されるネットワークの動作に影響を与え、統計情報を歪め、ルーティングの機能に大きな影響を与えます。
d. Sybil attack, whereby an attacker presents multiple identities to other things in the network. We refer to [Daniel] for further router attacks and a more detailed description.
d. シビル攻撃。攻撃者は、ネットワーク内の他のものに複数のIDを提示します。さらなるルーター攻撃と詳細な説明については、[Daniel]を参照してください。
10. Elevation of privilege: An attacker with low privileges can misuse additional flaws in the implemented authentication and authorization mechanisms of a thing to gain more privileged access to the thing and its data.
10. 特権の昇格：低い特権を持つ攻撃者は、Thingの実装された認証および承認メカニズムの追加の欠陥を悪用して、Thingとそのデータへのより特権的なアクセスを取得できます。
11. Denial of Service (DoS) attack: Often things have very limited memory and computation capabilities. Therefore, they are vulnerable to resource-exhaustion attack. Attackers can continuously send requests to specific things so as to deplete their resources. This is especially dangerous in the Internet of Things since an attacker might be located in the backend and target resource-constrained devices that are part of a constrained-node network [RFC7228]. A DoS attack can also be launched by physically jamming the communication channel. Network availability can also be disrupted by flooding the network with a large number of packets. On the other hand, things compromised by attackers can be used to disrupt the operation of other networks or systems by means of a Distributed DoS (DDoS) attack.
11. サービス拒否（DoS）攻撃：多くの場合、メモリと計算機能は非常に限られています。したがって、それらはリソース枯渇攻撃に対して脆弱です。攻撃者は、リソースを使い果たすために、特定のものに継続的にリクエストを送信できます。攻撃者はバックエンドに配置され、制約付きノードネットワーク[RFC7228]の一部であるリソースが制約されたデバイスをターゲットとする可能性があるため、これは特にInternet of Thingsで危険です。 DoS攻撃は、通信チャネルを物理的に妨害することによっても開始できます。ネットワークの可用性は、大量のパケットでネットワークをフラッディングすることによっても混乱する可能性があります。一方、攻撃者によって侵害されたものは、分散DoS（DDoS）攻撃によって他のネットワークまたはシステムの動作を妨害するために使用される可能性があります。
To deal with the above threats, it is required to find and apply suitable security mitigations. However, new threats and exploits appear on a daily basis, and products are deployed in different environments prone to different types of threats. Thus, ensuring a proper level of security in an IoT system at any point of time is challenging. To address this challenge, some of the following methodologies can be used:
上記の脅威に対処するには、適切なセキュリティ緩和策を見つけて適用する必要があります。ただし、新しい脅威とエクスプロイトが日常的に出現し、製品はさまざまな種類の脅威になりやすいさまざまな環境に展開されています。したがって、IoTシステムの適切なレベルのセキュリティをいつでも確保することは困難です。この課題に対処するために、以下の方法論のいくつかを使用できます。
1. A Business Impact Analysis (BIA) assesses the consequences of the loss of basic security attributes: confidentiality, integrity, and availability in an IoT system. These consequences might include the impact from lost data, reduced sales, increased expenses, regulatory fines, customer dissatisfaction, etc. Performing a business impact analysis allows a business to determine the relevance of having a proper security design.
1. ビジネスインパクトアナリシス（BIA）は、基本的なセキュリティ属性（IoTシステムの機密性、整合性、可用性）の喪失による影響を評価します。これらの結果には、データの損失、売上の減少、費用の増加、規制上の罰金、顧客の不満などの影響が含まれる場合があります。ビジネスへの影響分析を実行することで、ビジネスは適切なセキュリティ設計の妥当性を判断できます。
2. A Risk Assessment (RA) analyzes security threats to an IoT system while considering their likelihood and impact. It also includes categorizing each of them with a risk level. Risks classified as moderate or high must be mitigated, i.e., the security architecture should be able to deal with those threats.
2. リスク評価（RA）は、IoTシステムに対するセキュリティの脅威を分析し、その可能性と影響を考慮します。また、それぞれをリスクレベルで分類することも含まれます。中程度または高に分類されるリスクは軽減する必要があります。つまり、セキュリティアーキテクチャはそれらの脅威に対処できる必要があります。
3. A Privacy Impact Assessment (PIA) aims at assessing the Personally Identifiable Information (PII) that is collected, processed, or used in an IoT system. By doing so, the goal is to fulfill applicable legal requirements and determine the risks and effects of manipulation and loss of PII.
3. プライバシー影響評価（PIA）は、IoTシステムで収集、処理、または使用される個人識別情報（PII）を評価することを目的としています。そうすることで、目的は適用される法的要件を満たし、PIIの操作と損失のリスクと影響を判断することです。
4. Procedures for incident reporting and mitigation refer to the methodologies that allow becoming aware of any security issues that affect an IoT system. Furthermore, this includes steps towards the actual deployment of patches that mitigate the identified vulnerabilities.
4. インシデントのレポートと軽減の手順は、IoTシステムに影響を与えるセキュリティの問題を認識できるようにする方法論を指します。さらに、これには、特定された脆弱性を軽減するパッチの実際の展開に向けたステップが含まれます。
BIA, RA, and PIA should generally be realized during the creation of a new IoT system or when deploying significant system/feature upgrades. In general, it is recommended to reassess them on a regular basis, taking into account new use cases and/or threats. The way a BIA, RA, or PIA is performed depends on the environment and the industry. More information can be found in NIST documents such as [NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122].
BIA、RA、およびPIAは通常、新しいIoTシステムの作成中、または重要なシステム/機能のアップグレードを展開するときに実現する必要があります。一般に、新しい使用例や脅威を考慮して、定期的に再評価することをお勧めします。 BIA、RA、またはPIAの実行方法は、環境と業界によって異なります。詳細については、[NISTSP800-34r1]、[NISTSP800-30r1]、[NISTSP800-122]などのNISTドキュメントを参照してください。
This section is organized as follows. Section 4.1 summarizes the state of the art on IP-based IoT systems, within both the IETF and other standardization bodies. Section 4.2 summarizes the state of the art on IP-based security protocols and their usage. Section 4.3 discusses guidelines and regulations for securing IoT as proposed by other bodies. Note that the references included in this section are a representative of the state of the art at the point of writing, and they are by no means exhaustive. The references are also at varying levels of maturity; thus, it is advisable to review their specific status.
このセクションは次のように構成されています。セクション4.1は、IETFと他の標準化団体の両方の中で、IPベースのIoTシステムに関する最新技術を要約しています。セクション4.2は、IPベースのセキュリティプロトコルとその使用に関する最新技術をまとめたものです。セクション4.3では、他の機関によって提案されたIoTを保護するためのガイドラインと規制について説明します。このセクションに含まれているリファレンスは、執筆時点での最新技術の代表であり、決して網羅的なものではないことに注意してください。参照は、成熟度のレベルもさまざまです。したがって、特定のステータスを確認することをお勧めします。
Nowadays, there exists a multitude of control protocols for IoT. For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI [DALI] play key roles. Recent trends, however, focus on an all-IP approach for system control.
今日、IoTには多数の制御プロトコルが存在します。 BACシステムでは、ZigBee標準[ZB]、BACNet [BACNET]、およびDALI [DALI]が重要な役割を果たします。ただし、最近の傾向は、システム制御のためのオールIPアプローチに焦点を当てています。
In this setting, a number of IETF working groups are designing new protocols for resource-constrained networks of smart things. The 6LoWPAN Working Group [WG-6LoWPAN], for example, has defined methods and protocols for the efficient transmission and adaptation of IPv6 packets over IEEE 802.15.4 networks [RFC4944].
この設定では、多くのIETFワーキンググループが、リソースに制約のあるスマートなもののための新しいプロトコルを設計しています。たとえば6LoWPANワーキンググループ[WG-6LoWPAN]は、IEEE 802.15.4ネットワーク[RFC4944]を介したIPv6パケットの効率的な送信と適応のための方法とプロトコルを定義しています。
The CoRE Working Group [WG-CoRE] has specified the Constrained Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol for constrained devices that is modeled after HTTP and typically runs over UDP to enable efficient application-level communication for things. ("RESTful" refers to the Representational State Transfer (REST) architecture.)
CoREワーキンググループ[WG-CoRE]は、Constrained Application Protocol（CoAP）[RFC7252]を指定しています。 CoAPは、制約されたデバイス用のRESTfulプロトコルであり、HTTPに基づいてモデル化され、通常はUDP上で実行され、物事の効率的なアプリケーションレベルの通信を可能にします。 （「RESTful」とは、Representational State Transfer（REST）アーキテクチャーを指します。）
In many smart-object networks, the smart objects are dispersed and have intermittent reachability either because of network outages or because they sleep during their operational phase to save energy. In such scenarios, direct discovery of resources hosted on the constrained server might not be possible. To overcome this barrier, the CoRE Working Group is specifying the concept of a Resource Directory (RD) [RD]. The Resource Directory hosts descriptions of resources that are located on other nodes. These resource descriptions are specified as CoRE link format [RFC6690].
多くのスマートオブジェクトネットワークでは、スマートオブジェクトは分散しており、ネットワークの停止のため、またはエネルギーを節約するために運用フェーズ中にスリープするため、断続的に到達可能です。このようなシナリオでは、制約されたサーバーでホストされているリソースを直接検出できない場合があります。この障壁を克服するために、CoREワーキンググループはリソースディレクトリ（RD）[RD]の概念を指定しています。リソースディレクトリは、他のノードにあるリソースの説明をホストします。これらのリソース記述は、CoREリンク形式[RFC6690]として指定されています。
While CoAP defines a standard communication protocol, a format for representing sensor measurements and parameters over CoAP is required. "Sensor Measurement Lists (SenML)" [RFC8428] is a specification that defines media types for simple sensor measurements and parameters. It has a minimalistic design so that constrained devices with limited computational capabilities can easily encode their measurements and, at the same time, servers can efficiently collect a large number of measurements.
CoAPは標準の通信プロトコルを定義しますが、CoAPを介してセンサーの測定値とパラメーターを表す形式が必要です。 「センサー測定リスト（SenML）」[RFC8428]は、単純なセンサー測定とパラメーターのメディアタイプを定義する仕様です。計算能力が制限された制約のあるデバイスが簡単に測定値をエンコードできるように、最小限の設計が施されていると同時に、サーバーは多数の測定値を効率的に収集できます。
In many IoT deployments, the resource-constrained smart objects are connected to the Internet via a gateway that is directly reachable. For example, an IEEE 802.11 Access Point (AP) typically connects the client devices to the Internet over just one wireless hop. However, some deployments of smart-object networks require routing between the smart objects themselves. The IETF has therefore defined the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. RPL provides support for multipoint-to-point traffic from resource-constrained smart objects towards a more resourceful central control point, as well as point-to-multipoint traffic in the reverse direction. It also supports point-to-point traffic between the resource-constrained devices. A set of routing metrics and constraints for path calculation in RPL are also specified [RFC6551].
多くのIoT展開では、リソースに制約のあるスマートオブジェクトは、直接到達可能なゲートウェイを介してインターネットに接続されます。たとえば、IEEE 802.11アクセスポイント（AP）は通常、クライアントデバイスを1つのワイヤレスホップだけでインターネットに接続します。ただし、スマートオブジェクトネットワークの一部の展開では、スマートオブジェクト間のルーティングが必要です。したがって、IETFは、低電力および損失の多いネットワーク（RPL）のIPv6ルーティングプロトコル[RFC6550]を定義しています。 RPLは、リソースに制約のあるスマートオブジェクトからよりリソースの多い中央制御ポイントに向かうマルチポイントツーポイントトラフィック、および逆方向のポイントツーマルチポイントトラフィックをサポートします。また、リソースに制約のあるデバイス間のポイントツーポイントトラフィックもサポートします。 RPLでの経路計算のルーティングメトリックと制約のセットも指定されています[RFC6551]。
The IPv6 over Networks of Resource-constrained Nodes (6lo) Working Group of the IETF [WG-6lo] has specified how IPv6 packets can be transmitted over various link-layer protocols that are commonly employed for resource-constrained smart-object networks. There is also ongoing work to specify IPv6 connectivity for a Non-Broadcast Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH) links [ARCH-6TiSCH]. Other link-layer protocols for which the IETF has specified or is currently specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air interface [RFC8105], and Near Field Communication (NFC) [IPv6-over-NFC].
リソースが制約されたノードのネットワーク上のIPv6（6lo）ワーキンググループのIETF [WG-6lo]は、リソースが制約されたスマートオブジェクトネットワークで一般的に採用されているさまざまなリンク層プロトコルでIPv6パケットを送信する方法を指定しています。 IEEE 802.15.4タイムスロットチャネルホッピング（TSCH）リンクによって形成される非ブロードキャストマルチアクセス（NBMA）メッシュネットワークのIPv6接続を指定する作業も進行中です[ARCH-6TiSCH]。 IETFが指定した、または現在IPv6サポートを指定している他のリンク層プロトコルには、Bluetooth [RFC7668]、Digital Enhanced Cordless Telecommunications（DECT）Ultra Low Energy（ULE）air interface [RFC8105]、Near Field Communication（NFC）[ IPv6-over-NFC]。
Baker and Meyer [RFC6272] identify which IP protocols can be used in smart-grid environments. They give advice to smart-grid network designers on how they can decide on a profile of the Internet protocol suite for smart-grid networks.
ベイカーとマイヤー[RFC6272]は、スマートグリッド環境で使用できるIPプロトコルを特定します。スマートグリッドネットワークのインターネットプロトコルスイートのプロファイルをどのように決定するかについて、スマートグリッドネットワーク設計者にアドバイスを提供します。
The Low Power Wide-Area Network (LPWAN) Working Group [WG-LPWAN] is analyzing features, requirements, and solutions to adapt IP-based protocols to networks such as LoRa [LoRa], Sigfox [sigfox], NB-IoT [NB-IoT], etc. These networking technologies enable a smart thing to run for years on a single coin-cell by relying on a star network topology and using optimized radio modulation with frame sizes in the order of tens of bytes. Such networks bring new security challenges, since most existing security mechanism do not work well with such resource constraints.
低電力ワイドエリアネットワーク（LPWAN）ワーキンググループ[WG-LPWAN]は、LoRa [LoRa]、Sigfox [sigfox]、NB-IoT [NBなどのネットワークにIPベースのプロトコルを適合させるための機能、要件、およびソリューションを分析しています-IoT]など。これらのネットワーキングテクノロジーは、スターネットワークトポロジに依存し、フレームサイズが数十バイトの最適化された無線変調を使用することにより、単一のコインセルで何年もスマートに動作することを可能にします。ほとんどの既存のセキュリティメカニズムはそのようなリソースの制約ではうまく機能しないため、そのようなネットワークは新しいセキュリティの課題をもたらします。
JavaScript Object Notation (JSON) is a lightweight text-representation format for structured data [RFC8259]. It is often used for transmitting serialized structured data over the network. The IETF has defined specifications for encoding cryptographic keys, encrypted content, signed content, and claims to be transferred between two parties as JSON objects. They are referred to as JSON Web Keys (JWKs) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON Web Signatures (JWSs) [RFC7515], and JSON Web Token (JWT) [RFC7519].
JavaScript Object Notation（JSON）は、構造化データの軽量テキスト表現形式です[RFC8259]。シリアル化された構造化データをネットワーク経由で送信するためによく使用されます。 IETFは、暗号化キー、暗号化されたコンテンツ、署名されたコンテンツをエンコードするための仕様を定義し、JSONオブジェクトとして2つのパーティ間で転送されることを要求します。これらは、JSON Web Keys（JWK）[RFC7517]、JSON Web Encryption（JWE）[RFC7516]、JSON Web Signatures（JWSs）[RFC7515]、JSON Web Token（JWT）[RFC7519]と呼ばれます。
An alternative to JSON, Concise Binary Object Representation (CBOR) [RFC7049], is a concise binary data format that is used for serialization of structured data. It is designed for resource-constrained nodes, and therefore it aims to provide a fairly small message size with minimal implementation code and extensibility without the need for version negotiation. CBOR Object Signing and Encryption (COSE) [RFC8152] specifies how to encode cryptographic keys, message authentication codes, encrypted content, and signatures with CBOR.
JSONの代わりに、簡潔なバイナリオブジェクト表現（CBOR）[RFC7049]は、構造化データのシリアル化に使用される簡潔なバイナリデータ形式です。リソースに制約のあるノード用に設計されているため、バージョンネゴシエーションを必要とせずに、最小限の実装コードと拡張性でかなり小さいメッセージサイズを提供することを目的としています。 CBORオブジェクトの署名と暗号化（COSE）[RFC8152]は、CBORで暗号化キー、メッセージ認証コード、暗号化されたコンテンツ、および署名をエンコードする方法を指定します。
The Light-Weight Implementation Guidance (LWIG) Working Group [WG-LWIG] is collecting experiences from implementers of IP stacks in constrained devices. The working group has already produced documents such as [RFC7815], which defines how a minimal Internet Key Exchange Version 2 (IKEv2) initiator can be implemented.
軽量実装ガイダンス（LWIG）ワーキンググループ[WG-LWIG]は、制約のあるデバイスのIPスタックの実装者から経験を収集しています。ワーキンググループは、[RFC7815]などのドキュメントをすでに作成しています。これは、最小限のインターネットキーエクスチェンジバージョン2（IKEv2）イニシエーターを実装する方法を定義しています。
The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating the remaining research issues that need to be addressed to quickly turn the vision of IoT into a reality where resource-constrained nodes can communicate with each other and with other more capable nodes on the Internet.
Thing-2-Thing Research Group（T2TRG）[RG-T2TRG]は、IoTのビジョンをリソースに制約のあるノードが互いに通信できる現実にすばやく変えるために取り組む必要のある残りの研究課題を調査していますインターネット上のより有能なノード。
Additionally, industry alliances and other standardization bodies are creating constrained IP protocol stacks based on the IETF work. Some important examples of this include:
さらに、業界のアライアンスやその他の標準化団体は、IETFの取り組みに基づいて制約付きのIPプロトコルスタックを作成しています。このいくつかの重要な例は次のとおりです。
1. Thread [Thread]: Specifies the Thread protocol that is intended for a variety of IoT devices. It is an IPv6-based network protocol that runs over IEEE 802.15.4.
1. スレッド[スレッド]：さまざまなIoTデバイスを対象としたスレッドプロトコルを指定します。これは、IEEE 802.15.4で実行されるIPv6ベースのネットワークプロトコルです。
2. Industrial Internet Consortium [IIoT]: The consortium defines reference architectures and security frameworks for development, adoption, and widespread use of Industrial Internet technologies based on existing IETF standards.
2. インダストリアルインターネットコンソーシアム[IIoT]：コンソーシアムは、既存のIETF標準に基づくインダストリアルインターネットテクノロジーの開発、採用、および広範な使用のためのリファレンスアーキテクチャとセキュリティフレームワークを定義します。
3. IPSO Alliance (which subsequently merged with OMA SpecWorks [OMASpecWorks]): The alliance specifies a common object model that enables application software on any device to interoperate with other conforming devices.
3. IPSOアライアンス（その後OMA SpecWorks [OMASpecWorks]と統合）：アライアンスは、任意のデバイス上のアプリケーションソフトウェアが他の準拠デバイスと相互運用できるようにする共通オブジェクトモデルを指定します。
4. OneM2M [OneM2M]: The standards body defines technical and API specifications for IoT devices. It aims to create a service layer that can run on any IoT device hardware and software.
4. OneM2M [OneM2M]：標準化団体は、IoTデバイスの技術仕様とAPI仕様を定義します。任意のIoTデバイスのハードウェアとソフトウェアで実行できるサービスレイヤーを作成することを目的としています。
5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops standards and certifications primarily for IoT devices that use Constrained Application Protocol (CoAP) as the application-layer protocol.
5. Open Connectivity Foundation（OCF）[OCF]：財団は、アプリケーション層プロトコルとしてConstrained Application Protocol（CoAP）を使用する主にIoTデバイスの標準と認証を開発します。
6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to enable a common IP network infrastructure between different application standards used in building automation and lighting systems such as BACnet, KNX, and ZigBee.
6. Fairhair Alliance [Fairhair]：BACnet、KNX、ZigBeeなどのビルディングオートメーションと照明システムで使用されるさまざまなアプリケーション標準間の共通IPネットワークインフラストラクチャを有効にするIoTミドルウェアを指定します。
7. OMA LwM2M [LWM2M]: OMA Lightweight M2M is a standard from the OMA SpecWorks for M2M and IoT device management. LwM2M relies on CoAP as the application-layer protocol and uses a RESTful architecture for remote management of IoT devices.
7. OMA LwM2M [LWM2M]：OMAライトウェイトM2Mは、M2MおよびIoTデバイス管理用のOMA SpecWorksの標準です。 LwM2Mは、アプリケーション層プロトコルとしてCoAPに依存し、IoTデバイスのリモート管理にRESTfulアーキテクチャを使用します。
There are three main security objectives for IoT networks:
IoTネットワークには、3つの主要なセキュリティ目標があります。
1. protecting the IoT network from attackers
1. 攻撃者からIoTネットワークを保護する
2. protecting IoT applications and thus the things and users
2. IoTアプリケーション、つまりモノとユーザーの保護
3. protecting the rest of the Internet and other things from attacks that use compromised things as an attack platform
3. 残りのインターネットおよびその他のものを、侵害されたものを攻撃プラットフォームとして使用する攻撃から保護する
In the context of the IP-based IoT deployments, consideration of existing Internet security protocols is important. There are a wide range of specialized as well as general-purpose security solutions for the Internet domain, such as IKEv2/IPsec [RFC7296], Transport Layer Security (TLS) [RFC8446], Datagram Transport Layer Security (DTLS) [RFC6347], Host Identity Protocol (HIP) [RFC7401], PANA [RFC5191], Kerberos [RFC4120], Simple Authentication and Security Layer (SASL) [RFC4422], and Extensible Authentication Protocol (EAP) [RFC3748].
IPベースのIoT展開のコンテキストでは、既存のインターネットセキュリティプロトコルを考慮することが重要です。 IKEv2 / IPsec [RFC7296]、トランスポートレイヤーセキュリティ（TLS）[RFC8446]、データグラムトランスポートレイヤーセキュリティ（DTLS）[RFC6347]など、インターネットドメインにはさまざまな特殊セキュリティソリューションと汎用セキュリティソリューションがあります。 Host Identity Protocol（HIP）[RFC7401]、PANA [RFC5191]、Kerberos [RFC4120]、Simple Authentication and Security Layer（SASL）[RFC4422]、およびExtensible Authentication Protocol（EAP）[RFC3748]。
TLS provides security for TCP and requires a reliable transport. DTLS secures and uses datagram-oriented protocols such as UDP. Both protocols are intentionally kept similar and share the same ideology and cipher suites. The CoAP base specification [RFC7252] provides a description of how DTLS can be used for securing CoAP. It proposes three different modes for using DTLS: the PreSharedKey mode, where nodes have pre-provisioned keys for initiating a DTLS session with another node, RawPublicKey mode, where nodes have asymmetric-key pairs but no certificates to verify the ownership, and Certificate mode, where public keys are certified by a certification authority. An IoT implementation profile is defined for TLS version 1.2 and DTLS version 1.2 that offers communication security for resource-constrained nodes [RFC7925].
TLSはTCPにセキュリティを提供し、信頼できるトランスポートを必要とします。 DTLSは、UDPなどのデータグラム指向プロトコルを保護して使用します。両方のプロトコルは意図的に類似しており、同じイデオロギーと暗号スイートを共有しています。 CoAP基本仕様[RFC7252]は、CoAPを保護するためにDTLSを使用する方法を説明しています。これは、DTLSを使用するための3つの異なるモードを提案します。ノードが別のノードとのDTLSセッションを開始するために事前にプロビジョニングされたキーを持つPreSharedKeyモード、ノードが非対称キーペアを持っているが所有権を検証する証明書がないRawPublicKeyモード、および証明書モード、公開鍵は認証局によって認証されます。 IoT実装プロファイルはTLSバージョン1.2およびDTLSバージョン1.2に対して定義されており、リソースに制約のあるノードに通信セキュリティを提供します[RFC7925]。
There is ongoing work to define an authorization and access-control framework for resource-constrained nodes. The Authentication and Authorization for Constrained Environments (ACE) Working Group [WG-ACE] is defining a solution to allow only authorized access to resources that are hosted on a smart-object server and identified by a URI. The current proposal [ACE-OAuth] is based on the OAuth 2.0 framework [RFC6749], and it comes with profiles intended for different communication scenarios, e.g., "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" [ACE-DTLS].
リソースに制約のあるノードの承認とアクセス制御のフレームワークを定義する作業が進行中です。制約付き環境の認証と承認（ACE）ワーキンググループ[WG-ACE]は、スマートオブジェクトサーバーでホストされ、URIで識別されるリソースへの承認されたアクセスのみを許可するソリューションを定義しています。現在の提案[ACE-OAuth]はOAuth 2.0フレームワーク[RFC6749]に基づいており、さまざまな通信シナリオ向けのプロファイルが付属しています。たとえば、「制限された環境（ACE）の認証と承認のためのデータグラムトランスポート層セキュリティ（DTLS）プロファイル） "[ACE-DTLS]。
Object Security for Constrained RESTful Environments (OSCORE) [OSCORE] is a proposal that protects CoAP messages by wrapping them in the COSE format [RFC8152]. Thus, OSCORE falls in the category of object security, and it can be applied wherever CoAP can be used. The advantage of OSCORE over DTLS is that it provides some more flexibility when dealing with end-to-end security. Section 5.1.3 discusses this further.
制約付きRESTful環境（OSCORE）のオブジェクトセキュリティ[OSCORE]は、COAPメッセージをCOSE形式[RFC8152]でラップすることによってCoAPメッセージを保護する提案です。したがって、OSCOREはオブジェクトセキュリティのカテゴリに分類され、CoAPを使用できる場所であればどこでも適用できます。 DTLSよりもOSCOREが優れている点は、エンドツーエンドのセキュリティを処理するときに柔軟性が向上することです。セクション5.1.3では、これについてさらに説明します。
The Automated Certificate Management Environment (ACME) Working Group [WG-ACME] is specifying conventions for automated X.509 certificate management. This includes automatic validation of certificate issuance, certificate renewal, and certificate revocation. While the initial focus of the working group is on domain-name certificates (as used by web servers), other uses in some IoT deployments are possible.
自動証明書管理環境（ACME）ワーキンググループ[WG-ACME]は、自動X.509証明書管理の規則を指定しています。これには、証明書の発行の自動検証、証明書の更新、および証明書の失効が含まれます。ワーキンググループの最初の焦点はドメイン名証明書（Webサーバーで使用される）ですが、一部のIoT展開では他の用途も可能です。
The Internet Key Exchange (IKEv2)/IPsec -- as well as the less used Host Identity protocol (HIP) -- reside at or above the network layer in the OSI model. Both protocols are able to perform an authenticated key exchange and set up the IPsec for secure payload delivery. Currently, there are also ongoing efforts to create a HIP variant coined Diet HIP [HIP-DEX] that takes constrained networks and nodes into account at the authentication and key-exchange level.
インターネットキーエクスチェンジ（IKEv2）/ IPsec（使用頻度の低いホストIDプロトコル（HIP）と同様）は、OSIモデルのネットワークレイヤー以上に存在します。どちらのプロトコルも、認証されたキー交換を実行し、安全なペイロード配信のためにIPsecを設定できます。現在、制限されたネットワークとノードを認証および鍵交換レベルで考慮に入れるHIPバリアントダイエットHIP [HIP-DEX]を作成するための継続的な取り組みもあります。
Migault et al. [Diet-ESP] are working on a compressed version of IPsec so that it can easily be used by resource-constrained IoT devices. They rely on the Internet Key Exchange Protocol Version 2 (IKEv2) for negotiating the compression format.
ミゴート他[Diet-ESP]はIPsecの圧縮バージョンに取り組んでいるため、リソースに制約のあるIoTデバイスで簡単に使用できます。圧縮形式のネゴシエーションは、インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）に依存しています。
The Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework supporting multiple authentication methods.
拡張認証プロトコル（EAP）[RFC3748]は、複数の認証方法をサポートする認証フレームワークです。
EAP runs directly over the data link layer and thus does not require the deployment of IP. It supports duplicate detection and retransmission but does not allow for packet fragmentation. PANA is a network-layer transport for EAP that enables network access authentication between clients and the network infrastructure. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator.
EAPはデータリンク層で直接実行されるため、IPの展開は必要ありません。重複検出と再送信をサポートしますが、パケットの断片化はできません。 PANAは、クライアントとネットワークインフラストラクチャ間のネットワークアクセス認証を可能にするEAPのネットワーク層トランスポートです。 EAP用語では、PANAはUDPベースのEAP下位層であり、EAPピアとEAPオーセンティケーターの間で実行されます。
Attacks on and from IoT devices have become common in recent years -- for instance, large-scale DoS attacks on the Internet Infrastructure from compromised IoT devices. This fact has prompted many different standards bodies and consortia to provide guidelines for developers and the Internet community at large to build secure IoT devices and services. The following is a subset of the different guidelines and ongoing projects:
近年、IoTデバイスに対する攻撃が一般的になっています。たとえば、侵害されたIoTデバイスからのインターネットインフラストラクチャに対する大規模なDoS攻撃などです。この事実により、さまざまな標準化団体やコンソーシアムが、安全なIoTデバイスとサービスを構築するための開発者とインターネットコミュニティ全体にガイドラインを提供するようになりました。以下は、さまざまなガイドラインと進行中のプロジェクトのサブセットです。
1. Global System for Mobile Communications Association (GSMA) IoT security guidelines [GSMAsecurity]: GSMA has published a set of security guidelines for the benefit of new IoT product and service providers. The guidelines are aimed at device manufacturers, service providers, developers, and network operators. An enterprise can complete an IoT Security Self-Assessment to demonstrate that its products and services are aligned with the security guidelines of the GSMA.
1. モバイルシステムのグローバルシステム（GSMA）IoTセキュリティガイドライン[GSMAsecurity]：GSMAは、新しいIoT製品とサービスプロバイダーのために一連のセキュリティガイドラインを公開しています。このガイドラインは、デバイスメーカー、サービスプロバイダー、開発者、およびネットワークオペレーターを対象としています。企業は、IoTセキュリティの自己評価を完了して、その製品とサービスがGSMAのセキュリティガイドラインに沿っていることを実証できます。
2. Broadband Internet Technical Advisory Group (BITAG) IoT Security and Privacy Recommendations [BITAG]: BITAG has published recommendations for ensuring the security and privacy of IoT device users. BITAG observes that many IoT devices are shipped from the factory with software that is already outdated and vulnerable. The report also states that many devices with vulnerabilities will not be fixed, either because the manufacturer does not provide updates or because the user does not apply them. The recommendations include that IoT devices should function without cloud and Internet connectivity and that all IoT devices should have methods for automatic secure software updates.
2. ブロードバンドインターネット技術諮問グループ（BITAG）のIoTセキュリティとプライバシーに関する推奨事項[BITAG]：BITAGは、IoTデバイスユーザーのセキュリティとプライバシーを確保するための推奨事項を公開しています。 BITAGは、多くのIoTデバイスが工場から出荷されており、ソフトウェアがすでに古くて脆弱であることを確認しています。また、レポートには、製造元がアップデートを提供していないか、ユーザーがそれらを適用していないため、脆弱性のある多くのデバイスは修正されないことも記載されています。推奨事項には、クラウドおよびインターネット接続なしでIoTデバイスが機能する必要があること、およびすべてのIoTデバイスに安全なソフトウェアの自動更新のメソッドが必要であることが含まれます。
3. United Kingdom Department for Digital, Culture, Media and Sport (DCMS) [DCMS]: UK DCMS has released a report that includes a list of 13 steps for improving IoT security. These steps, for example, highlight the need for implementing a vulnerability disclosure policy and keeping software updated. The report is aimed at device manufacturers, IoT service providers, mobile application developers, and retailers.
3. 英国デジタル文化文化スポーツ局（DCMS）[DCMS]：英国DCMSは、IoTセキュリティを改善するための13のステップのリストを含むレポートをリリースしました。たとえば、これらの手順は、脆弱性開示ポリシーを実装し、ソフトウェアを最新の状態に保つ必要性を強調しています。レポートは、デバイスメーカー、IoTサービスプロバイダー、モバイルアプリケーション開発者、および小売業者を対象としています。
4. Cloud Security Alliance (CSA) New Security Guidance for Early Adopters of the IoT [CSA]: CSA recommendations for early adopters of IoT encourage enterprises to implement security at different layers of the protocol stack. It also recommends implementation of an authentication/authorization framework for IoT deployments. A complete list of recommendations is available in the report [CSA].
4. クラウドセキュリティアライアンス（CSA）IoTの早期導入者向けの新しいセキュリティガイダンス[CSA]：IoTの早期導入者に対するCSAの推奨事項により、企業はプロトコルスタックのさまざまなレイヤーでセキュリティを実装することが推奨されます。また、IoT展開用の認証/承認フレームワークの実装を推奨しています。推奨事項の完全なリストは、レポート[CSA]にあります。
5. United States Department of Homeland Security (DHS) [DHS]: DHS has put forth six strategic principles that would enable IoT developers, manufacturers, service providers, and consumers to maintain security as they develop, manufacture, implement, or use network-connected IoT devices.
5. 米国国土安全保障省（DHS）[DHS]：DHSは、IoT開発者、メーカー、サービスプロバイダー、および消費者がネットワーク接続IoTを開発、製造、実装、または使用する際にセキュリティを維持できるようにする6つの戦略的原則を発表しましたデバイス。
6. National Institute of Standards and Technology (NIST) [NIST-Guide]: The NIST special publication urges enterprise and US federal agencies to address security throughout the systems engineering process. The publication builds upon the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288 standard and augments each process in the system lifecycle with security enhancements.
6. 国立標準技術研究所（NIST）[NIST-Guide]：NISTの特別刊行物は、企業と米国連邦政府機関に、システムエンジニアリングプロセス全体のセキュリティに取り組むよう要請しています。この出版物は、国際標準化機構（ISO）/ International Electrotechnical Commission（IEC）15288標準に基づいて構築されており、システムのライフサイクルの各プロセスにセキュリティの強化を加えています。
7. National Institute of Standards and Technology (NIST) [NIST-LW-PROJECT] [NIST-LW-2016]: NIST is running a project on lightweight cryptography with the purpose of: (i) identifying application areas for which standard cryptographic algorithms are too heavy, classifying them according to some application profiles to be determined; (ii) determining limitations in those existing cryptographic standards; and (iii) standardizing lightweight algorithms that can be used in specific application profiles.
7. 国立標準技術研究所（NIST）[NIST-LW-PROJECT] [NIST-LW-2016]：NISTは、以下の目的で軽量暗号化に関するプロジェクトを実行しています。（i）標準暗号化アルゴリズムが適用されるアプリケーション領域を特定する決定するいくつかのアプリケーションプロファイルに従ってそれらを分類する重い。 （ii）これらの既存の暗号規格の制限を決定する。 （iii）特定のアプリケーションプロファイルで使用できる軽量アルゴリズムを標準化する。
8. Open Web Application Security Project (OWASP) [OWASP]: OWASP provides security guidance for IoT manufacturers, developers, and consumers. OWASP also includes guidelines for those who intend to test and analyze IoT devices and applications.
8. Open Web Application Security Project（OWASP）[OWASP]：OWASPは、IoTメーカー、開発者、消費者にセキュリティガイダンスを提供します。 OWASPには、IoTデバイスとアプリケーションをテストおよび分析する人のためのガイドラインも含まれています。
9. IoT Security Foundation [IoTSecFoundation]: The IoT Security Foundation has published a document that enlists various considerations that need to be taken into account when developing IoT applications. For example, the document states that IoT devices could use a hardware root of trust to ensure that only authorized software runs on the devices.
9. IoT Security Foundation [IoTSecFoundation]：IoT Security Foundationは、IoTアプリケーションを開発する際に考慮する必要があるさまざまな考慮事項を列挙したドキュメントを公開しています。たとえば、ドキュメントでは、IoTデバイスは信頼されたハードウェアルートを使用して、承認されたソフトウェアのみがデバイスで実行されるようにすることができると述べています。
10. National Highway Traffic Safety Administration (NHTSA) [NHTSA]: The US NHTSA provides guidance to the automotive industry for improving the cyber security of vehicles. While some of the guidelines are general, the document provides specific recommendations for the automotive industry, such as how various automotive manufacturers can share cybersecurity vulnerabilities discovered.
10. National Highway Traffic Safety Administration（NHTSA）[NHTSA]：US NHTSAは、自動車のサイバーセキュリティを向上させるために自動車業界にガイダンスを提供しています。ガイドラインの一部は一般的なものですが、このドキュメントでは、さまざまな自動車メーカーが発見したサイバーセキュリティの脆弱性をどのように共有できるかなど、自動車業界に固有の推奨事項を提供しています。
11. "Best Current Practices for Securing Internet of Things (IoT) Devices" [Moore]: This document provides a list of minimum requirements that vendors of IoT devices should to take into account while developing applications, services, and firmware updates in order to reduce the frequency and severity of security incidents that arise from compromised IoT devices.
11. 「モノのインターネット（IoT）デバイスを保護するための現在のベストプラクティス」[ムーア]：このドキュメントでは、IoTデバイスのベンダーがアプリケーション、サービス、およびファームウェアの更新を開発する際に考慮する必要がある最小要件のリストを提供します。侵害されたIoTデバイスから発生するセキュリティインシデントの頻度と重大度。
12. European Union Agency for Network and Information Security (ENISA) [ENISA-ICS]: ENISA published a document on communication-network dependencies for Industrial Control Systems (ICS)/Supervisory Control And Data Acquisition (SCADA) systems in which security vulnerabilities, guidelines, and general recommendations are summarized.
12. 欧州連合のネットワークおよび情報セキュリティ機関（ENISA）[ENISA-ICS]：ENISAは、産業用制御システム（ICS）/監視制御およびデータ収集（SCADA）システムの通信ネットワークの依存関係に関するドキュメントを公開しました。と一般的な推奨事項が要約されています。
13. Internet Society Online Trust Alliance [ISOC-OTA]: The Internet Society's IoT Trust Framework identifies the core requirements that manufacturers, service providers, distributors, purchasers, and policymakers need to understand, assess, and embrace for effective security and privacy as part of the Internet of Things.
13. インターネットソサエティオンライントラストアライアンス[ISOC-OTA]：インターネットソサエティのIoTトラストフレームワークは、製造業者、サービスプロバイダー、ディストリビューター、購入者、および政策立案者が、効果的なセキュリティとプライバシーを理解、評価、採用するために必要なコア要件を特定し、モノのインターネット。
Other guideline and recommendation documents may exist or may later be published. This list should be considered nonexhaustive. Despite the acknowledgment that security in the Internet is needed and the existence of multiple guidelines, the fact is that many IoT devices and systems have very limited security. There are multiple reasons for this. For instance, some manufacturers focus on delivering a product without paying enough attention to security. This may be because of lack of expertise or limited budget. However, the deployment of such insecure devices poses a severe threat to the privacy and safety of users. The vast number of devices and their inherently mobile nature also imply that an initially secure system can become insecure if a compromised device gains access to the system at some point in time. Even if all other devices in a given environment are secure, this does not prevent external attacks caused by insecure devices. Recently, the US Federal Communications Commission (FCC) has stated the need for additional regulation of IoT systems [FCC]. It is possible that we may see other such regional regulations in the future.
他のガイドラインおよび推奨ドキュメントが存在するか、後で公開される可能性があります。このリストは網羅的ではないと考えるべきです。インターネットのセキュリティが必要であるという認識と複数のガイドラインの存在にもかかわらず、多くのIoTデバイスとシステムのセキュリティは非常に限られているというのが事実です。これには複数の理由があります。たとえば、一部の製造元は、セキュリティに十分な注意を払うことなく製品の提供に重点を置いています。これは、専門知識の不足または予算の制限が原因である可能性があります。ただし、このような安全でないデバイスの配備は、ユーザーのプライバシーと安全性に深刻な脅威をもたらします。膨大な数のデバイスとそれらの本質的にモバイル性の性質は、侵害されたデバイスがある時点でシステムにアクセスすると、最初は安全なシステムが安全でなくなる可能性があることも意味します。特定の環境にある他のすべてのデバイスが安全であっても、安全でないデバイスが原因の外部からの攻撃を防ぐことはできません。最近、米国連邦通信委員会（FCC）は、IoTシステムの追加規制の必要性を表明しています[FCC]。将来、他のそのような地域の規制が見られる可能性があります。
In this section, we take a closer look at the various security challenges in the operational and technical features of IoT and then discuss how existing Internet security protocols cope with these technical and conceptual challenges through the lifecycle of a thing. This discussion should not be understood as a comprehensive evaluation of all protocols, nor can it cover all possible aspects of IoT security. Yet, it aims at showing concrete limitations and challenges in some IoT design areas rather than giving an abstract discussion. In this regard, the discussion handles issues that are most important from the authors' perspectives.
このセクションでは、IoTの運用機能と技術機能におけるさまざまなセキュリティの課題を詳しく検討し、既存のインターネットセキュリティプロトコルがモノのライフサイクルを通じてこれらの技術的および概念的な課題にどのように対処するかについて説明します。この議論は、すべてのプロトコルの包括的な評価として理解されるべきではなく、IoTセキュリティのすべての可能な側面をカバーすることもできません。しかし、それは抽象的な議論を与えるのではなく、いくつかのIoT設計領域における具体的な制限と課題を示すことを目的としています。この点で、議論は著者の観点から最も重要な問題を扱います。
Coupling resource-constrained networks and the powerful Internet is a challenge, because the resulting heterogeneity of both networks complicates protocol design and system operation. In the following subsections, we briefly discuss the resource constraints of IoT devices and the consequences for the use of Internet protocols in the IoT domain.
リソースに制約のあるネットワークと強力なインターネットを結合することは困難です。それは、両方のネットワークの結果として生じる異質性がプロトコル設計とシステム操作を複雑にするためです。以下のサブセクションでは、IoTデバイスのリソースの制約と、IoTドメインでのインターネットプロトコルの使用による影響について簡単に説明します。
IoT deployments are often characterized by lossy and low-bandwidth communication channels. IoT devices are also often constrained in terms of the CPU, memory, and energy budget available [RFC7228]. These characteristics directly impact the design of protocols for the IoT domain. For instance, small packet-size limits at the physical layer (127 Bytes in IEEE 802.15.4) can lead to (i) hop-by-hop fragmentation and reassembly or (ii) small IP-layer maximum transmission unit (MTU). In the first case, excessive fragmentation of large packets that are often required by security protocols may open new attack vectors for state-exhaustion attacks. The second case might lead to more fragmentation at the IP layer, which commonly downgrades the overall system performance due to packet loss and the need for retransmission.
IoTの配備は、多くの場合、損失の多い低帯域幅の通信チャネルによって特徴付けられます。 IoTデバイスは、CPU、メモリ、および利用可能なエネルギーバジェットの点でも制約を受けることがよくあります[RFC7228]。これらの特性は、IoTドメインのプロトコルの設計に直接影響します。たとえば、物理層でのパケットサイズ制限が小さいと（IEEE 802.15.4では127バイト）、（i）ホップバイホップの断片化と再構成、または（ii）小さいIP層の最大転送単位（MTU）が発生する可能性があります。最初のケースでは、セキュリティプロトコルでしばしば必要とされる大きなパケットの過度の断片化により、ステート枯渇攻撃の新しい攻撃ベクトルが開かれる可能性があります。 2番目のケースでは、IP層でのフラグメンテーションが増える可能性があり、これは一般に、パケット損失と再送信の必要性により、システム全体のパフォーマンスを低下させます。
The size and number of messages should be minimized to reduce memory requirements and optimize bandwidth usage. In this context, layered approaches involving a number of protocols might lead to worse performance in resource-constrained devices since they combine the headers of the different protocols. In some settings, protocol negotiation can increase the number of exchanged messages. To improve performance during basic procedures such as, for example, bootstrapping, it might be a good strategy to perform those procedures at a lower layer.
メッセージのサイズと数を最小限にして、メモリ要件を減らし、帯域幅の使用を最適化する必要があります。このコンテキストでは、複数のプロトコルを含む階層化アプローチは、異なるプロトコルのヘッダーを組み合わせるため、リソースに制約のあるデバイスのパフォーマンスを低下させる可能性があります。一部の設定では、プロトコルネゴシエーションにより、交換されるメッセージの数を増やすことができます。たとえば、ブートストラップなどの基本的な手順の実行中にパフォーマンスを向上させるには、これらの手順を下位層で実行することをお勧めします。
Small CPUs and scarce memory limit the usage of resource-expensive cryptographic primitives such as public key cryptography as used in most Internet security standards. This is especially true if the basic cryptographic blocks need to be frequently used or the underlying application demands low delay.
小さなCPUと少ないメモリにより、ほとんどのインターネットセキュリティ標準で使用されている公開鍵暗号など、リソースを消費する暗号プリミティブの使用が制限されます。これは、基本的な暗号ブロックを頻繁に使用する必要がある場合、または基盤となるアプリケーションが低遅延を要求する場合に特に当てはまります。
There are ongoing efforts to reduce the resource consumption of security protocols by using more efficient underlying cryptographic primitives such as Elliptic Curve Cryptography (ECC) [RFC8446]. The specification of elliptic curve X25519 [ecc25519], stream ciphers such as ChaCha [ChaCha], Diet HIP [HIP-DEX], and ECC groups for IKEv2 [RFC5903] are all examples of efforts to make security protocols more resource efficient. Additionally, most modern security protocols have been revised in the last few years to enable cryptographic agility, making cryptographic primitives interchangeable. However, these improvements are only a first step in reducing the computation and communication overhead of Internet protocols. The question remains if other approaches can be applied to leverage key agreement in these heavily resource-constrained environments.
Elliptic Curve Cryptography（ECC）[RFC8446]などのより効率的な基礎となる暗号プリミティブを使用することにより、セキュリティプロトコルのリソース消費を削減するための継続的な取り組みがあります。楕円曲線X25519 [ecc25519]、ChaCha [ChaCha]、Diet HIP [HIP-DEX]などのストリーム暗号、およびIKEv2 [RFC5903]のECCグループの仕様は、セキュリティプロトコルをより効率的にするための取り組みの例です。さらに、最近のほとんどのセキュリティプロトコルは過去数年で改訂され、暗号の俊敏性を実現し、暗号プリミティブを交換可能にしています。ただし、これらの改善は、インターネットプロトコルの計算と通信のオーバーヘッドを削減するための最初のステップにすぎません。リソースに制約のあるこれらの環境で鍵合意を活用するために他のアプローチを適用できるかどうかという問題は残ります。
A further fundamental need refers to the limited energy budget available to IoT nodes. Careful protocol (re)design and usage are required to reduce not only the energy consumption during normal operation but also under DoS attacks. Since the energy consumption of IoT devices differs from other device classes, judgments on the energy consumption of a particular protocol cannot be made without tailor-made IoT implementations.
さらに根本的な必要性は、IoTノードが利用できる限られたエネルギー量に関係しています。通常の運用時だけでなく、DoS攻撃時のエネルギー消費量を削減するには、慎重なプロトコルの（再）設計と使用法が必要です。 IoTデバイスのエネルギー消費量は他のデバイスクラスと異なるため、特定のプロトコルのエネルギー消費量を判断するには、オーダーメイドのIoT実装が必要です。
The tight memory and processing constraints of things naturally alleviate resource-exhaustion attacks. Especially in unattended T2T communication, such attacks are difficult to notice before the service becomes unavailable (for example, because of battery or memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP implement return routability checks based on a cookie mechanism to delay the establishment of state at the responding host until the address of the initiating host is verified. The effectiveness of these defenses strongly depends on the routing topology of the network. Return routability checks are particularly effective if hosts cannot receive packets addressed to other hosts and if IP addresses present meaningful information as is the case in today's Internet. However, they are less effective in broadcast media or when attackers can influence the routing and addressing of hosts (for example, if hosts contribute to the routing infrastructure in ad hoc networks and meshes).
物事の厳しいメモリと処理の制約は、リソース枯渇攻撃を自然に軽減します。特に無人T2T通信では、このような攻撃は、サービスが利用できなくなる前に（たとえば、バッテリーまたはメモリの消耗が原因で）気づくことは困難です。 DoS対策として、DTLS、IKEv2、HIP、およびダイエットHIPは、開始ホストのアドレスが確認されるまで、応答ホストでの状態の確立を遅らせるために、Cookieメカニズムに基づくリターンルーティング可能性チェックを実装します。これらの防御の有効性は、ネットワークのルーティングトポロジに強く依存します。ホストが他のホストに宛てられたパケットを受信できない場合、および今日のインターネットの場合のようにIPアドレスが意味のある情報を提供する場合は、戻りルータビリティチェックが特に有効です。ただし、ブロードキャストメディアや攻撃者がホストのルーティングとアドレッシングに影響を与える可能性がある場合（たとえば、ホストがアドホックネットワークとメッシュのルーティングインフラストラクチャに関与している場合）は、効果が低くなります。
In addition, HIP implements a puzzle mechanism that can force the initiator of a connection (and potential attacker) to solve cryptographic puzzles with variable difficulties. Puzzle-based defense mechanisms are less dependent on the network topology but perform poorly if CPU resources in the network are heterogeneous (for example, if a powerful Internet host attacks a thing). Increasing the puzzle difficulty under attack conditions can easily lead to situations where a powerful attacker can still solve the puzzle while weak IoT clients cannot and are excluded from communicating with the victim. Still, puzzle-based approaches are a viable option for sheltering IoT devices against unintended overload caused by misconfiguration or malfunctioning things.
さらに、HIPは、接続の開始者（および潜在的な攻撃者）に、さまざまな困難を伴う暗号パズルを解くように強制できるパズルメカニズムを実装しています。パズルベースの防御メカニズムは、ネットワークトポロジへの依存度は低くなりますが、ネットワークのCPUリソースが異種である場合（たとえば、強力なインターネットホストが攻撃する場合）は、パフォーマンスが低下します。攻撃条件下でパズルの難易度を上げると、強力な攻撃者がパズルを解くことができる一方で、弱いIoTクライアントは被害者との通信から除外され、除外される状況に簡単につながる可能性があります。それでも、パズルベースのアプローチは、構成ミスや誤動作による意図しない過負荷からIoTデバイスを保護するための実行可能なオプションです。
5.1.3. End-to-End Security, Protocol Translation, and the Role of Middleboxes
5.1.3. エンドツーエンドのセキュリティ、プロトコル変換、ミドルボックスの役割
The term "end-to-end security" often has multiple interpretations. Here, we consider end-to-end security in the context of end-to-end IP connectivity from a sender to a receiver. Services such as confidentiality and integrity protection on packet data, message authentication codes, or encryption are typically used to provide end-to-end security. These protection methods render the protected parts of the packets immutable as rewriting is either not possible because (i) the relevant information is encrypted and inaccessible to the gateway or (ii) rewriting integrity-protected parts of the packet would invalidate the end-to-end integrity protection.
「エンドツーエンドのセキュリティ」という用語は、多くの場合複数の解釈があります。ここでは、送信者から受信者へのエンドツーエンドのIP接続のコンテキストでエンドツーエンドのセキュリティを検討します。エンドツーエンドのセキュリティを提供するには、通常、パケットデータの機密性と整合性の保護、メッセージ認証コード、暗号化などのサービスが使用されます。これらの保護方法では、（i）関連情報が暗号化されてゲートウェイにアクセスできないため、または（ii）パケットの整合性で保護された部分を書き換えると、エンドツーエンドが無効になるため、書き換えが不可能になるため、パケットの保護された部分が不変になります。完全性保護を終了します。
Protocols for constrained IoT networks are not exactly identical to their larger Internet counterparts, for efficiency and performance reasons. Hence, more or less subtle differences between protocols for constrained IoT networks and Internet protocols will remain. While these differences can be bridged with protocol translators at middleboxes, they may become major obstacles if end-to-end security measures between IoT devices and Internet hosts are needed.
効率とパフォーマンスの理由から、制約のあるIoTネットワークのプロトコルは、大規模なインターネット対応のものとまったく同じではありません。したがって、制約のあるIoTネットワークのプロトコルとインターネットプロトコルの間には、多少の微妙な違いが残ります。これらの違いはミドルボックスのプロトコルトランスレーターで解決できますが、IoTデバイスとインターネットホスト間のエンドツーエンドのセキュリティ対策が必要な場合は、大きな障害になる可能性があります。
If access to data or messages by the middleboxes is required or acceptable, then a diverse set of approaches for handling such a scenario is available. Note that some of these approaches affect the meaning of end-to-end security in terms of integrity and confidentiality, since the middleboxes will be able to either decrypt or partially modify the exchanged messages:
ミドルボックスによるデータまたはメッセージへのアクセスが必要または許容できる場合、そのようなシナリオを処理するためのさまざまなアプローチのセットが利用可能です。ミドルボックスは交換されたメッセージを復号化または部分的に変更できるため、これらのアプローチの一部は整合性と機密性の観点からエンドツーエンドのセキュリティの意味に影響を与えることに注意してください。
1. Sharing credentials with middleboxes enables them to transform (for example, decompress, convert, etc.) packets and reapply the security measures after transformation. This method abandons end-to-end security and is only applicable to simple scenarios with a rudimentary security model.
1. 資格情報をミドルボックスと共有すると、パケットを変換（たとえば、解凍、変換など）し、変換後にセキュリティ対策を再適用できます。この方法は、エンドツーエンドのセキュリティを放棄し、基本的なセキュリティモデルを使用した単純なシナリオにのみ適用できます。
2. Reusing the Internet wire format for IoT makes conversion between IoT and Internet protocols unnecessary. However, it can lead to poor performance in some use cases because IoT-specific optimizations (for example, stateful or stateless compression) are not possible.
2. IoTのインターネットワイヤー形式を再利用すると、IoTとインターネットプロトコル間の変換が不要になります。ただし、IoT固有の最適化（たとえば、ステートフルまたはステートレス圧縮）が不可能であるため、一部のユースケースではパフォーマンスが低下する可能性があります。
3. Selectively protecting vital and immutable packet parts with a message authentication code or encryption requires a careful balance between performance and security. Otherwise, this approach might either result in poor performance or poor security, depending on which parts are selected for protection, where they are located in the original packet, and how they are processed. [OSCORE] proposes a solution in this direction by encrypting and integrity protecting most of the message fields except those parts that a middlebox needs to read or change.
3. 重要で不変のパケット部分をメッセージ認証コードまたは暗号化で選択的に保護するには、パフォーマンスとセキュリティの慎重なバランスが必要です。それ以外の場合、このアプローチでは、保護対象として選択されたパーツ、元のパケット内の場所、およびそれらの処理方法に応じて、パフォーマンスまたはセキュリティが低下する可能性があります。 [OSCORE]は、ミドルボックスが読み取りまたは変更する必要がある部分を除いて、ほとんどのメッセージフィールドを暗号化して整合性を保護することにより、この方向のソリューションを提案します。
4. Homomorphic encryption techniques can be used in the middlebox to perform certain operations. However, this is limited to data processing involving arithmetic operations. Furthermore, the performance of existing libraries -- for example, Microsoft SEAL [SEAL] -- is still too limited, and homomorphic encryption techniques are not widely applicable yet.
4. ミドルボックスで準同型暗号化技術を使用して、特定の操作を実行できます。ただし、これは算術演算を含むデータ処理に限定されます。さらに、既存のライブラリ（Microsoft SEAL [SEAL]など）のパフォーマンスはまだ非常に制限されており、準同型暗号化技術はまだ広く適用されていません。
5. Message authentication codes that sustain transformation can be realized by considering the order of transformation and protection (for example, by creating a signature before compression so that the gateway can decompress the packet without recalculating the signature). Such an approach enables IoT-specific optimizations but is more complex and may require application-specific transformations before security is applied. Moreover, the usage of encrypted or integrity-protected data prevents middleboxes from transforming packets.
5. 変換と保護の順序を考慮することで、変換を維持するメッセージ認証コードを実現できます（たとえば、ゲートウェイが署名を再計算せずにパケットを解凍できるように、圧縮前に署名を作成するなど）。このようなアプローチはIoT固有の最適化を可能にしますが、より複雑であり、セキュリティを適用する前にアプリケーション固有の変換が必要になる場合があります。さらに、暗号化または整合性保護されたデータを使用すると、ミドルボックスがパケットを変換できなくなります。
6. Mechanisms based on object security can bridge the protocol worlds but still require that the two worlds use the same object-security formats. Currently, the object-security format based on COSE [RFC8152] is different from JSON Object Signing and Encryption (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS) [RFC5652]. Legacy devices relying on traditional Internet protocols will need to update to the newer protocols for constrained environments to enable real end-to-end security. Furthermore, middleboxes do not have any access to the data, and this approach does not prevent an attacker who is capable of modifying relevant message header fields that are not protected.
6. オブジェクトセキュリティに基づくメカニズムは、プロトコルの世界を橋渡しすることができますが、2つの世界が同じオブジェクトセキュリティの形式を使用する必要があります。現在、COSE [RFC8152]に基づくオブジェクトセキュリティ形式は、JSONオブジェクト署名および暗号化（JOSE）[RFC7520]または暗号化メッセージ構文（CMS）[RFC5652]とは異なります。従来のインターネットプロトコルに依存するレガシーデバイスは、制約のある環境で実際のエンドツーエンドのセキュリティを実現するために、新しいプロトコルに更新する必要があります。さらに、ミドルボックスはデータにアクセスできず、このアプローチは、保護されていない関連するメッセージヘッダーフィールドを変更できる攻撃者を防ぐことはできません。
To the best of our knowledge, none of the mentioned security approaches that focus on the confidentiality and integrity of the communication exchange between two IP endpoints provide the perfect solution in this problem space.
私たちの知る限りでは、2つのIPエンドポイント間の通信交換の機密性と整合性に焦点を当てた前述のセキュリティアプローチのいずれも、この問題領域で完璧なソリューションを提供しません。
There is a multitude of new link-layer protocols that aim to address the resource-constrained nature of IoT devices. For example, IEEE 802.11ah [IEEE802ah] has been specified for extended range and lower energy consumption to support IoT devices. Similarly, LPWAN protocols such as LoRa [LoRa], Sigfox [sigfox], and NarrowBand IoT (NB-IoT) [NB-IoT] are all designed for resource-constrained devices that require long range and low bit rates. [RFC8376] provides an informational overview of the set of LPWAN technologies being considered by the IETF. It also identifies the potential gaps that exist between the needs of those technologies and the goal of running IP in such networks. While these protocols allow IoT devices to conserve energy and operate efficiently, they also add additional security challenges. For example, the relatively small MTU can make security handshakes with large X509 certificates a significant overhead. At the same time, new communication paradigms also allow IoT devices to communicate directly amongst themselves with or without support from the network. This communication paradigm is also referred to as Device-to-Device (D2D), Machine-to-Machine (M2M), or Thing-to-Thing (T2T) communication, and it is motivated by a number of features such as improved network performance, lower latency, and lower energy requirements.
リソースに制約のあるIoTデバイスの性質に対処することを目的とした、多数の新しいリンク層プロトコルがあります。たとえば、IEEE 802.11ah [IEEE802ah]は、IoTデバイスをサポートするために範囲を拡大し、エネルギー消費を低減するように指定されています。同様に、LoRa [LoRa]、Sigfox [sigfox]、およびNarrowBand IoT（NB-IoT）[NB-IoT]などのLPWANプロトコルはすべて、長距離および低ビットレートを必要とするリソースに制約のあるデバイス用に設計されています。 [RFC8376]は、IETFによって検討されている一連のLPWANテクノロジーの情報概要を提供します。また、これらのテクノロジーのニーズとそのようなネットワークでIPを実行するという目標の間に存在する潜在的なギャップを特定します。これらのプロトコルにより、IoTデバイスはエネルギーを節約し、効率的に動作することができますが、セキュリティ上の課題も追加されます。たとえば、MTUが比較的小さいと、大きなX509証明書を使用したセキュリティハンドシェイクが大きなオーバーヘッドになる可能性があります。同時に、新しい通信パラダイムにより、IoTデバイスはネットワークからのサポートの有無にかかわらず、デバイス間で直接通信することもできます。この通信パラダイムは、デバイス間（D2D）、マシン間（M2M）、またはThing-to-Thing（T2T）通信とも呼ばれ、ネットワークの改善などの多くの機能が動機となっています。パフォーマンス、低レイテンシ、低エネルギー要件。
Creating a security domain from a set of previously unassociated IoT devices is a key operation in the lifecycle of a thing in an IoT network. This aspect is further elaborated and discussed in the T2TRG draft on bootstrapping [BOOTSTRAP].
以前は関連付けられていなかった一連のIoTデバイスからセキュリティドメインを作成することは、IoTネットワーク内のモノのライフサイクルにおける重要な操作です。この点については、ブートストラップに関するT2TRGドラフト[BOOTSTRAP]でさらに詳しく説明されています。
After the bootstrapping phase, the system enters the operational phase. During the operational phase, things can use the state information created during the bootstrapping phase in order to exchange information securely. In this section, we discuss the security challenges during the operational phase. Note that many of the challenges discussed in Section 5.1 apply during the operational phase.
ブートストラップ段階の後、システムは運用段階に入ります。運用段階では、情報は安全に情報を交換するために、ブートストラップ段階で作成された状態情報を使用できます。このセクションでは、運用フェーズにおけるセキュリティの課題について説明します。セクション5.1で説明した課題の多くは、運用フェーズ中に適用されることに注意してください。
Group-key negotiation is an important security service for IoT communication patterns in which a thing sends some data to multiple things or data flows from multiple things towards a thing. All discussed protocols only cover unicast communication and therefore do not focus on group-key establishment. This applies in particular to (D)TLS and IKEv2. Thus, a solution is required in this area. A potential solution might be to use the Diffie-Hellman keys -- which are used in IKEv2 and HIP to set up a secure unicast link -- for group Diffie-Hellman key negotiations. However, Diffie-Hellman is a relatively heavy solution, especially if the group is large.
グループキーネゴシエーションは、モノが複数のモノにデータを送信したり、複数のモノからモノへのデータフローを送信したりするIoT通信パターンの重要なセキュリティサービスです。説明されているすべてのプロトコルはユニキャスト通信のみを対象としているため、グループキーの確立に焦点を当てていません。これは特に（D）TLSとIKEv2に適用されます。したがって、この領域では解決策が必要です。可能性のある解決策は、グループDiffie-HellmanキーネゴシエーションのためにDiffie-Hellmanキー（IKEv2とHIPで使用され、安全なユニキャストリンクをセットアップする）を使用することです。ただし、特にグループが大きい場合、Diffie-Hellmanは比較的重いソリューションです。
Symmetric and asymmetric keys can be used in group communication. Asymmetric keys have the advantage that they can provide source authentication. However, doing broadcast encryption with a single public/private key pair is also not feasible. Although a single symmetric key can be used to encrypt the communication or compute a message authentication code, it has inherent risks since the capture of a single node can compromise the key shared throughout the network. The usage of symmetric keys also does not provide source authentication. Another factor to consider is that asymmetric cryptography is more resource-intensive than symmetric key solutions. Thus, the security risks and performance trade-offs of applying either symmetric or asymmetric keys to a given IoT use case need to be well analyzed according to risk and usability assessments [RFC8387]. [MULTICAST] is looking at a combination of confidentiality using a group key and source authentication using public keys in the same packet.
対称鍵と非対称鍵は、グループ通信で使用できます。非対称キーには、ソース認証を提供できるという利点があります。ただし、単一の公開鍵と秘密鍵のペアでブロードキャスト暗号化を行うことも不可能です。単一の対称キーを使用して通信を暗号化したり、メッセージ認証コードを計算したりできますが、単一ノードのキャプチャはネットワーク全体で共有されるキーを危険にさらす可能性があるため、固有のリスクがあります。対称鍵の使用もソース認証を提供しません。考慮すべきもう1つの要素は、非対称暗号化は対称キーソリューションよりもリソースを集中的に使用することです。したがって、対称鍵または非対称鍵を特定のIoTユースケースに適用することによるセキュリティリスクとパフォーマンスのトレードオフは、リスクとユーザビリティの評価[RFC8387]に従って十分に分析する必要があります。 [マルチキャスト]は、グループキーを使用する機密性と、同じパケット内の公開キーを使用するソース認証の組み合わせを調べています。
Conceptually, solutions that provide secure group communication at the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage in terms of the cryptographic overhead when compared to application-focused security solutions (TLS/DTLS). This is due to the fact that application-focused solutions require cryptographic operations per group application, whereas network-layer approaches may allow sharing secure group associations between multiple applications (for example, for neighbor discovery and routing or service discovery). Hence, implementing shared features lower in the communication stack can avoid redundant security measures. However, it is important to note that sharing security contexts among different applications involves potential security threats, e.g., if one of the applications is malicious and monitors exchanged messages or injects fake messages. In the case of OSCORE, it provides security for CoAP group communication as defined in RFC 7390, i.e., based on multicast IP. If the same security association is reused for each application, then this solution does not seem to have more cryptographic overhead compared to IPsec.
概念的には、ネットワーク層（IPsec / IKEv2、HIP / Diet HIP）で安全なグループ通信を提供するソリューションは、アプリケーション中心のセキュリティソリューション（TLS / DTLS）と比較した場合、暗号化のオーバーヘッドの点で利点があります。これは、アプリケーション中心のソリューションではグループアプリケーションごとに暗号化操作が必要なのに対し、ネットワーク層のアプローチでは、複数のアプリケーション間で安全なグループの関連付けを共有できる場合があるためです（たとえば、近隣探索やルーティングやサービス探索など）。したがって、通信スタックの下位にある共有機能を実装すると、冗長なセキュリティ対策を回避できます。ただし、異なるアプリケーション間でセキュリティコンテキストを共有すると、潜在的なセキュリティ脅威が発生することに注意することが重要です。たとえば、アプリケーションの1つが悪意のあるもので、交換されたメッセージを監視したり、偽のメッセージを挿入したりする場合などです。 OSCOREの場合、RFC 7390で定義されているように、つまりマルチキャストIPに基づいて、CoAPグループ通信にセキュリティを提供します。各アプリケーションで同じセキュリティアソシエーションが再利用される場合、このソリューションはIPsecと比較してより多くの暗号化オーバーヘッドを持っているようには見えません。
Several group-key solutions have been developed by the MSEC Working Group of the IETF [WG-MSEC]. The MIKEY architecture [RFC4738] is one example. While these solutions are specifically tailored for multicast and group-broadcast applications in the Internet, they should also be considered as candidate solutions for group-key agreement in IoT. The MIKEY architecture, for example, describes a coordinator entity that disseminates symmetric keys over pair-wise end-to-end secured channels. However, such a centralized approach may not be applicable in a distributed IoT environment, where the choice of one or several coordinators and the management of the group key is not trivial.
IETF [WG-MSEC]のMSECワーキンググループによっていくつかのグループキーソリューションが開発されました。 MIKEYアーキテクチャ[RFC4738]はその一例です。これらのソリューションは、インターネットでのマルチキャストおよびグループブロードキャストアプリケーション用に特別に調整されていますが、IoTでのグループキー契約の候補ソリューションとしても検討する必要があります。たとえば、MIKEYアーキテクチャは、ペアワイズのエンドツーエンドのセキュリティで保護されたチャネルを介して対称鍵を配布するコーディネーターエンティティを記述します。ただし、このような集中型のアプローチは、1つまたは複数のコーディネーターの選択とグループキーの管理が簡単ではない分散型IoT環境には適用できない場合があります。
It is expected that many things (for example, user devices and wearable sensors) will be mobile in the sense that they are attached to different networks during the lifetime of a security association. Built-in mobility signaling can greatly reduce the overhead of the cryptographic protocols because unnecessary and costly re-establishments of the session (possibly including handshake and key agreement) can be avoided. IKEv2 supports host mobility with the MOBIKE extension [RFC4555] [RFC4621]. MOBIKE refrains from applying heavyweight cryptographic extensions for mobility. However, MOBIKE mandates the use of IPsec tunnel mode, which requires the transmission of an additional IP header in each packet.
セキュリティアソシエーションの存続期間中、さまざまなネットワークに接続されているという意味で、多くのものが（たとえば、ユーザーデバイスやウェアラブルセンサーなど）モバイルであることが予想されます。組み込みのモビリティシグナリングは、セッションの不必要でコストのかかる再確立（おそらくハンドシェイクとキーの合意を含む）を回避できるため、暗号プロトコルのオーバーヘッドを大幅に削減できます。 IKEv2は、MOBIKE拡張[RFC4555] [RFC4621]でホストモビリティをサポートします。 MOBIKEは、モビリティにヘビー級の暗号拡張を適用することを控えています。ただし、MOBIKEでは、IPsecトンネルモードの使用が義務付けられており、各パケットで追加のIPヘッダーを送信する必要があります。
HIP offers simple yet effective mobility management by allowing hosts to signal changes to their associations [RFC8046]. However, slight adjustments might be necessary to reduce the cryptographic costs -- for example, by making the public key signatures in the mobility messages optional. Diet HIP does not define mobility yet, but it is sufficiently similar to HIP and can use the same mechanisms. DTLS provides some mobility support by relying on a connection ID (CID). The use of connection IDs can provide all the mobility functionality described in [Williams] except sending the updated location. The specific need for IP-layer mobility mainly depends on the scenario in which the nodes operate. In many cases, mobility supported by means of a mobile gateway may suffice to enable mobile IoT networks, such as body-sensor networks. Using message-based application-layer security solutions such as OSCORE [OSCORE] can also alleviate the problem of re-establishing lower-layer sessions for mobile nodes.
HIPは、アソシエーションの変更をホストが通知できるようにすることで、シンプルでありながら効果的なモビリティ管理を提供します[RFC8046]。ただし、暗号化コストを削減するには、たとえばモビリティメッセージの公開鍵署名をオプションにするなど、わずかな調整が必要になる場合があります。ダイエットHIPはモビリティをまだ定義していませんが、HIPと十分に似ており、同じメカニズムを使用できます。 DTLSは、接続ID（CID）に依存することにより、いくつかのモビリティサポートを提供します。接続IDを使用すると、更新された場所の送信を除いて、[Williams]で説明されているすべてのモビリティ機能を提供できます。 IPレイヤーモビリティの具体的なニーズは、主にノードが動作するシナリオに依存します。多くの場合、モバイルゲートウェイによってサポートされるモビリティは、ボディセンサーネットワークなどのモバイルIoTネットワークを有効にするのに十分です。 OSCORE [OSCORE]などのメッセージベースのアプリケーション層セキュリティソリューションを使用すると、モバイルノードの下位層セッションを再確立する問題も軽減できます。
IoT devices are often expected to stay functional for several years or decades, even though they might operate unattended with direct Internet connectivity. Software updates for IoT devices are therefore required not only for new functionality but also to eliminate security vulnerabilities due to software bugs, design flaws, or deprecated algorithms. Software bugs might remain even after careful code review. Implementations of security protocols might contain (design) flaws. Cryptographic algorithms can also become insecure due to advances in cryptanalysis. Therefore, it is necessary that devices that are incapable of verifying a cryptographic signature are not exposed to the Internet, even indirectly.
IoTデバイスは、直接インターネット接続で無人で動作する場合でも、数年または数十年は機能し続けることが期待されています。したがって、IoTデバイスのソフトウェアアップデートは、新機能だけでなく、ソフトウェアのバグ、設計上の欠陥、非推奨のアルゴリズムによるセキュリティの脆弱性を排除するためにも必要です。注意深くコードを確認した後でも、ソフトウェアのバグが残る可能性があります。セキュリティプロトコルの実装には、（設計上の）欠陥が含まれている可能性があります。暗号解読の進歩により、暗号アルゴリズムも安全でなくなる可能性があります。したがって、暗号署名を検証できないデバイスは、間接的にであってもインターネットに公開されないようにする必要があります。
In his essay, Schneier highlights several challenges that hinder mechanisms for secure software update of IoT devices [SchneierSecurity]. First, there is a lack of incentives for manufacturers, vendors, and others on the supply chain to issue updates for their devices. Second, parts of the software running on IoT devices is simply a binary blob without any source code available. Since the complete source code is not available, no patches can be written for that piece of code. Lastly, Schneier points out that even when updates are available, users generally have to manually download and install them. However, users are never alerted about security updates, and many times do not have the necessary expertise to manually administer the required updates.
Schneierは彼のエッセイで、IoTデバイスの安全なソフトウェア更新のメカニズムを妨げるいくつかの課題を強調しています[SchneierSecurity]。第1に、製造業者、ベンダー、その他のサプライチェーンのデバイスがデバイスのアップデートを発行するインセンティブが不足しています。第2に、IoTデバイスで実行されるソフトウェアの一部は、ソースコードが利用できないバイナリブロブにすぎません。完全なソースコードは利用できないため、そのコードの一部に対してパッチを作成することはできません。最後に、Schneier氏は、アップデートが利用可能であっても、ユーザーは通常、手動でダウンロードしてインストールする必要があると指摘しています。ただし、ユーザーはセキュリティ更新について警告を受けることはなく、多くの場合、必要な更新を手動で管理するために必要な専門知識がありません。
The US Federal Trade Commission (FTC) staff report on "Internet of Things - Privacy & Security in a Connected World" [FTCreport] and the Article 29 Working Party's "Opinion 8/2014 on the Recent Developments on the Internet of Things" [Article29] also document the challenges for secure remote software update of IoT devices. They note that even providing such a software-update capability may add new vulnerabilities for constrained devices. For example, a buffer overflow vulnerability in the implementation of a software update protocol (TR69) [TR69] and an expired certificate in a hub device [wink] demonstrate how the software-update process itself can introduce vulnerabilities.
米国連邦取引委員会（FTC）のスタッフは、「モノのインターネット-コネクテッドワールドにおけるプライバシーとセキュリティ」[FTCレポート]と第29条作業部会の「モノのインターネットに関する最近の進展に関する意見8/2014」について報告します[第29条]また、IoTデバイスの安全なリモートソフトウェアアップデートの課題を文書化します。彼らは、そのようなソフトウェア更新機能を提供することでさえ、制約されたデバイスに新しい脆弱性を追加するかもしれないことに注意します。たとえば、ソフトウェア更新プロトコル（TR69）[TR69]の実装におけるバッファオーバーフローの脆弱性およびハブデバイス[ウィンク]の期限切れの証明書は、ソフトウェア更新プロセス自体がどのように脆弱性をもたらすかを示しています。
Powerful IoT devices that run general-purpose operating systems can make use of sophisticated software-update mechanisms known from the desktop world. However, resource-constrained devices typically do not have any operating system and are often not equipped with a memory management unit or similar tools. Therefore, they might require more specialized solutions.
汎用オペレーティングシステムを実行する強力なIoTデバイスは、デスクトップの世界で知られている高度なソフトウェア更新メカニズムを利用できます。ただし、リソースに制約のあるデバイスには通常、オペレーティングシステムがなく、多くの場合、メモリ管理ユニットや同様のツールが装備されていません。したがって、より専門的なソリューションが必要になる場合があります。
An important requirement for secure software and firmware updates is source authentication. Source authentication requires the resource-constrained things to implement public key signature verification algorithms. As stated in Section 5.1.1, resource-constrained things have limited computational capabilities and energy supply available, which can hinder the amount and frequency of cryptographic processing that they can perform. In addition to source authentication, software updates might require confidential delivery over a secure (encrypted) channel. The complexity of broadcast encryption can force the usage of point-to-point secure links; however, this increases the duration of a software update in a large system. Alternatively, it may force the usage of solutions in which the software update is delivered to a gateway and then distributed to the rest of the system with a network key. Sending large amounts of data that later needs to be assembled and verified over a secure channel can consume a lot of energy and computational resources. Correct scheduling of the software updates is also a crucial design challenge. For example, a user of connected light bulbs would not want them to update and restart at night. More importantly, the user would not want all the lights to update at the same time.
安全なソフトウェアとファームウェアの更新のための重要な要件は、ソース認証です。ソース認証では、公開鍵署名検証アルゴリズムを実装するために、リソースに制約のあるものが必要です。セクション5.1.1で述べたように、リソースに制約のあるものは、計算機能と利用可能なエネルギー供給に制限があり、実行できる暗号処理の量と頻度を妨げる可能性があります。ソース認証に加えて、ソフトウェアの更新では、安全な（暗号化された）チャネルを介した機密配信が必要になる場合があります。ブロードキャスト暗号化は複雑であるため、ポイントツーポイントの安全なリンクを強制的に使用できます。ただし、これにより、大規模なシステムでのソフトウェア更新の期間が長くなります。または、ソフトウェアの更新がゲートウェイに配信され、ネットワークキーを使用してシステムの残りの部分に配布されるソリューションの使用を強制する場合もあります。後で組み立てて検証する必要がある大量のデータを安全なチャネル経由で送信すると、多くのエネルギーと計算リソースを消費する可能性があります。ソフトウェアアップデートの正しいスケジュールも、設計上の重要な課題です。たとえば、接続されている電球のユーザーは、夜間に更新して再起動することを望まないでしょう。さらに重要なのは、ユーザーがすべてのライトを同時に更新したくないということです。
Software updates in IoT systems are also needed to update old and insecure cryptographic primitives. However, many IoT systems, some of which are already deployed, are not designed with provisions for cryptographic agility. For example, many devices come with a wireless radio that has an AES128 hardware coprocessor. These devices solely rely on the coprocessor for encrypting and authenticating messages. A software update adding support for new cryptographic algorithms implemented solely in software might not fit on these devices due to limited memory, or might drastically hinder its operational performance. This can lead to the use of old and insecure software. Therefore, it is important to account for the fact that cryptographic algorithms would need to be updated and consider the following when planning for cryptographic agility:
古くて安全ではない暗号プリミティブを更新するには、IoTシステムのソフトウェア更新も必要です。ただし、多くのIoTシステムは、その一部はすでに展開されており、暗号化の俊敏性に対応できるように設計されていません。たとえば、多くのデバイスには、AES128ハードウェアコプロセッサを搭載したワイヤレスラジオが付属しています。これらのデバイスは、メッセージの暗号化と認証をコプロセッサに依存しています。ソフトウェアのみで実装された新しい暗号化アルゴリズムのサポートを追加するソフトウェア更新プログラムは、メモリが限られているためにこれらのデバイスに適合しないか、または動作パフォーマンスを大幅に低下させる可能性があります。これは、古くて安全でないソフトウェアの使用につながる可能性があります。したがって、暗号化の俊敏性を計画する場合は、暗号化アルゴリズムを更新する必要があることを考慮し、次の点を考慮することが重要です。
1. Would it be secure to use the existing cryptographic algorithms available on the device for updating with new cryptographic algorithms that are more secure?
1. デバイスで利用可能な既存の暗号化アルゴリズムを使用して、より安全な新しい暗号化アルゴリズムで更新することは安全ですか？
2. Will the new software-based implementation fit on the device given the limited resources?
2. リソースが限られている場合、新しいソフトウェアベースの実装はデバイスに適合しますか？
3. Would the normal operation of existing IoT applications on the device be severely hindered by the update?
3. デバイス上の既存のIoTアプリケーションの正常な動作は、更新によって著しく妨げられますか？
Finally, we would like to highlight the previous and ongoing work in the area of secure software and firmware updates at the IETF. [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652] can be used to protect firmware packages. The IAB has also organized a workshop to understand the challenges for secure software update of IoT devices. A summary of the recommendations to the standards community derived from the discussions during that workshop have been documented [RFC8240]. A working group called Software Updates for Internet of Things (SUIT) [WG-SUIT] is currently working on a new specification to reflect the best current practices for firmware update based on experience from IoT deployments. It is specifically working on describing an IoT firmware update architecture and specifying a manifest format that contains metadata about the firmware update package. Finally, the Trusted Execution Environment Provisioning Working Group [WG-TEEP] aims at developing a protocol for lifecycle management of trusted applications running on the secure area of a processor (Trusted Execution Environment (TEE)).
最後に、IETFでの安全なソフトウェアとファームウェアの更新の分野でのこれまでおよび現在進行中の作業に焦点を当てます。 [RFC4108]は、暗号化メッセージ構文（CMS）[RFC5652]を使用してファームウェアパッケージを保護する方法を説明しています。 IABは、IoTデバイスの安全なソフトウェア更新の課題を理解するためのワークショップも開催しました。そのワークショップでの議論から導き出された標準化コミュニティへの推奨事項の要約が文書化されています[RFC8240]。モノのインターネット（SUIT）のソフトウェアアップデート[WG-SUIT]と呼ばれるワーキンググループは、IoT展開の経験に基づくファームウェアアップデートの現在のベストプラクティスを反映する新しい仕様に取り組んでいます。具体的には、IoTファームウェア更新アーキテクチャの説明と、ファームウェア更新パッケージに関するメタデータを含むマニフェスト形式の指定に取り組んでいます。最後に、Trusted Execution Environmentプロビジョニングワーキンググループ[WG-TEEP]は、プロセッサ（Trusted Execution Environment（TEE））の安全な領域で実行される信頼できるアプリケーションのライフサイクル管理のためのプロトコルの開発を目的としています。
Like all commercial devices, IoT devices have a given useful lifetime. The term "end-of-life" (EOL) is used by vendors or network operators to indicate the point of time at which they limit or end support for the IoT device. This may be planned or unplanned (for example, when the manufacturer goes bankrupt, the vendor just decides to abandon a product, or a network operator moves to a different type of networking technology). A user should still be able to use and perhaps even update the device. This requires for some form of authorization handover.
すべての商用デバイスと同様に、IoTデバイスには一定の有効寿命があります。 「サポート終了（EOL）」という用語は、ベンダーまたはネットワークオペレーターがIoTデバイスのサポートを制限または終了する時点を示すために使用されます。これは計画されている場合と計画外の場合があります（たとえば、製造業者が破産した場合、ベンダーは製品を放棄することを決定するか、ネットワークオペレーターは別の種類のネットワーク技術に移行します）。ユーザーは引き続きデバイスを使用でき、場合によってはデバイスを更新することもできます。これには、何らかの形の承認の引き渡しが必要です。
Although this may seem far-fetched given the commercial interests and market dynamics, we have examples from the mobile world where the devices have been functional and up to date long after the original vendor stopped supporting the device. CyanogenMod for Android devices and OpenWrt for home routers are two such instances where users have been able to use and update their devices even after the official EOL. Admittedly, it is not easy for an average user to install and configure their devices on their own. With the deployment of millions of IoT devices, simpler mechanisms are needed to allow users to add new trust anchors [RFC6024] and install software and firmware from other sources once the device is EOL.
これは商業的な関心と市場のダイナミクスを考えると、遠く離れているように思えるかもしれませんが、モバイルワールドから、元のベンダーがデバイスのサポートを停止してからかなり前にデバイスが機能し、最新の状態になっている例があります。 Androidデバイス用のCyanogenModとホームルーター用のOpenWrtは、公式のEOL後でもユーザーがデバイスを使用および更新できる2つの例です。確かに、平均的なユーザーが自分でデバイスをインストールして構成するのは簡単ではありません。数百万のIoTデバイスの導入により、ユーザーが新しいトラストアンカー[RFC6024]を追加し、デバイスがEOLになったときに他のソースからソフトウェアとファームウェアをインストールできるようにするためのより単純なメカニズムが必要です。
Users using new IoT appliances such as Internet-connected smart televisions, speakers, and cameras are often unaware that these devices can undermine their privacy. Recent revelations have shown that many IoT device vendors have been collecting sensitive private data through these connected appliances with or without appropriate user warnings [cctv].
インターネットに接続されたスマートテレビ、スピーカー、カメラなどの新しいIoTアプライアンスを使用しているユーザーは、これらのデバイスがプライバシーを損なう可能性があることに気づかないことがよくあります。最近の啓示は、多くのIoTデバイスベンダーが、適切なユーザー警告[cctv]の有無にかかわらず、これらの接続されたアプライアンスを通じて機密のプライベートデータを収集していることを示しています。
An IoT device's user/owner would like to monitor and verify its operational behavior. For instance, the user might want to know if the device is connecting to the server of the manufacturer for any reason. This feature -- connecting to the manufacturer's server -- may be necessary in some scenarios, such as during the initial configuration of the device. However, the user should be kept aware of the data that the device is sending back to the vendor. For example, the user might want to know if his/her TV is sending data when he/she inserts a new USB stick.
IoTデバイスのユーザー/所有者は、その動作を監視および検証したいと考えています。たとえば、ユーザーが何らかの理由でデバイスが製造元のサーバーに接続しているかどうかを知りたい場合があります。この機能（メーカーのサーバーへの接続）は、デバイスの初期構成時など、一部のシナリオで必要になる場合があります。ただし、ユーザーは、デバイスがベンダーに送り返しているデータを常に認識している必要があります。たとえば、ユーザーが新しいUSBスティックを挿入したときにテレビがデータを送信しているかどうかを知りたい場合があります。
Providing such information to the users in an understandable fashion is challenging. This is because IoT devices are not only resource constrained in terms of their computational capability but also in terms of the user interface available. Also, the network infrastructure where these devices are deployed will vary significantly from one user environment to another. Therefore, where and how this monitoring feature is implemented still remains an open question.
そのような情報を理解しやすい方法でユーザーに提供することは困難です。これは、IoTデバイスは、計算能力の点だけでなく、利用可能なユーザーインターフェイスの点でもリソースに制約があるためです。また、これらのデバイスが展開されているネットワークインフラストラクチャは、ユーザー環境によって大きく異なります。したがって、この監視機能がどこでどのように実装されているかは未解決の問題です。
Manufacturer Usage Description (MUD) files [RFC8520] are perhaps a first step towards implementation of such a monitoring service. The idea behind MUD files is relatively simple: IoT devices would disclose the location of their MUD file to the network during installation. The network can then retrieve those files and learn about the intended behavior of the devices stated by the device manufacturer. A network-monitoring service could then warn the user/ owner of devices if they don't behave as expected.
Manufacturer Usage Description（MUD）ファイル[RFC8520]は、おそらくそのような監視サービスの実装に向けた最初のステップです。 MUDファイルの背後にある考え方は比較的単純です。IoTデバイスは、インストール中にMUDファイルの場所をネットワークに公開します。その後、ネットワークはそれらのファイルを取得し、デバイスの製造元が指定したデバイスの意図された動作について知ることができます。ネットワーク監視サービスは、デバイスが期待どおりに動作しない場合、デバイスのユーザー/所有者に警告することができます。
Many devices and software services that automatically learn and monitor the behavior of different IoT devices in a given network are commercially available. Such monitoring devices/services can be configured by the user to limit network traffic and trigger alarms when unexpected operation of IoT devices is detected.
特定のネットワーク内のさまざまなIoTデバイスの動作を自動的に学習および監視する多くのデバイスおよびソフトウェアサービスが市販されています。このような監視デバイス/サービスは、ユーザーがネットワークトラフィックを制限し、IoTデバイスの予期しない操作が検出されたときにアラームをトリガーするように構成できます。
Given that IoT devices often have inadvertent vulnerabilities, both users and developers would want to perform extensive testing on their IoT devices, networks, and systems. Nonetheless, since the devices are resource constrained and manufactured by multiple vendors, some of them very small, devices might be shipped with very limited testing, so that bugs can remain and can be exploited at a later stage. This leads to two main types of challenges:
多くの場合、IoTデバイスには不注意による脆弱性があるため、ユーザーと開発者の両方がIoTデバイス、ネットワーク、およびシステムに対して広範なテストを実行する必要があります。それにもかかわらず、デバイスはリソースに制約があり、複数のベンダーによって製造されているため、一部のデバイスは非常に小型であり、非常に限られたテストで出荷される可能性があるため、バグが残り、後の段階で悪用される可能性があります。これにより、主に2つのタイプの課題が発生します。
1. It remains to be seen how the software-testing and quality-assurance mechanisms used from the desktop and mobile world will be applied to IoT devices to give end users the confidence that the purchased devices are robust. Bodies such as the European Cyber Security Organization (ECSO) [ECSO] are working on processes for security certification of IoT devices.
1. デスクトップとモバイルの世界で使用されているソフトウェアテストと品質保証のメカニズムがIoTデバイスにどのように適用され、購入したデバイスが堅牢であるかをエンドユーザーに確信させる方法はまだ見られません。 European Cyber Security Organization（ECSO）[ECSO]などの団体は、IoTデバイスのセキュリティ認証のプロセスに取り組んでいます。
2. It is also an open question how the combination of devices from multiple vendors might actually lead to dangerous network configurations -- for example, if the combination of specific devices can trigger unexpected behavior. It is needless to say that the security of the whole system is limited by its weakest point.
2.また、特定のデバイスの組み合わせが予期しない動作を引き起こす可能性がある場合など、複数のベンダーのデバイスの組み合わせが実際に危険なネットワーク構成につながる可能性があることも未解決の問題です。言うまでもなく、システム全体のセキュリティは、その弱点によって制限されています。
Many IoT systems that are being deployed today will remain operational for many years. With the advancements made in the field of quantum computers, it is possible that large-scale quantum computers will be available in the future for performing cryptanalysis on existing cryptographic algorithms and cipher suites. If this happens, it will have two consequences. First, functionalities enabled by means of primitives such as RSA or ECC -- namely, key exchange, public key encryption, and signature -- would not be secure anymore due to Shor's algorithm. Second, the security level of symmetric algorithms will decrease, for example, the security of a block cipher with a key size of b bits will only offer b/2 bits of security due to Grover's algorithm.
今日展開されている多くのIoTシステムは、何年も稼働し続けます。量子コンピューターの分野での進歩により、既存の暗号アルゴリズムと暗号スイートで暗号解読を実行するために、将来、大規模な量子コンピューターが利用可能になる可能性があります。これが発生した場合、2つの結果が生じます。まず、RSAやECCなどのプリミティブによって有効にされる機能（つまり、鍵交換、公開鍵暗号化、署名）は、Shorのアルゴリズムのために安全ではなくなります。次に、対称アルゴリズムのセキュリティレベルが低下します。たとえば、キーサイズがbビットのブロック暗号のセキュリティは、Groverのアルゴリズムによりb / 2ビットのセキュリティしか提供しません。
The above scenario becomes more urgent when we consider the so-called "harvest and decrypt" attack in which an attacker can start to harvest (store) encrypted data today, before a quantum computer is available, and decrypt it years later, once a quantum computer is available. Such "harvest and decrypt" attacks are not new and were used in the VENONA project [venona-project]. Many IoT devices that are being deployed today will remain operational for a decade or even longer. During this time, digital signatures used to sign software updates might become obsolete, making the secure update of IoT devices challenging.
上記のシナリオは、量子コンピューターが利用可能になる前に攻撃者が暗号化されたデータを今日収集（格納）し、数年後に量子化された後、それを復号化できる、いわゆる「収集と復号化」攻撃を考えると、より緊急になります。コンピュータが利用可能です。そのような「収穫と解読」攻撃は新しいものではなく、VENONAプロジェクト[venona-project]で使用されました。現在展開されている多くのIoTデバイスは、10年以上も稼働し続けます。この間、ソフトウェア更新の署名に使用されていたデジタル署名が古くなり、IoTデバイスの安全な更新が困難になる可能性があります。
This situation would require us to move to quantum-resistant alternatives -- in particular, for those functionalities involving key exchange, public key encryption, and signatures. [C2PQ] describes when quantum computers may become widely available and what steps are necessary for transitioning to cryptographic algorithms that provide security even in the presence of quantum computers. While future planning is hard, it may be a necessity in certain critical IoT deployments that are expected to last decades or more. Although increasing the key size of the different algorithms is definitely an option, it would also incur additional computational overhead and network traffic. This would be undesirable in most scenarios. There have been recent advancements in quantum-resistant cryptography. We refer to [ETSI-GR-QSC-001] for an extensive overview of existing quantum-resistant cryptography, and [RFC7696] provides guidelines for cryptographic algorithm agility.
この状況では、量子耐性のある代替手段、特に、鍵交換、公開鍵暗号化、および署名に関連する機能に移行する必要があります。 [C2PQ]は、量子コンピュータが広く利用可能になる時期と、量子コンピュータが存在する場合でもセキュリティを提供する暗号化アルゴリズムに移行するために必要な手順について説明しています。将来の計画は困難ですが、数十年以上続くことが予想される特定の重要なIoT展開では必要になる場合があります。さまざまなアルゴリズムのキーサイズを増やすことは間違いなく選択肢ですが、追加の計算オーバーヘッドとネットワークトラフィックも発生します。これはほとんどのシナリオで望ましくありません。量子耐性暗号法は最近進歩しています。既存の量子耐性暗号の広範な概要については[ETSI-GR-QSC-001]を参照し、[RFC7696]は暗号アルゴリズムの俊敏性に関するガイドラインを提供します。
People will eventually be surrounded by hundreds of connected IoT devices. Even if the communication links are encrypted and protected, information about people might still be collected or processed for different purposes. The fact that IoT devices in the vicinity of people might enable more pervasive monitoring can negatively impact their privacy. For instance, imagine the scenario where a static presence sensor emits a packet due to the presence or absence of people in its vicinity. In such a scenario, anyone who can observe the packet can gather critical privacy-sensitive information.
人々は最終的に何百もの接続されたIoTデバイスに囲まれます。通信リンクが暗号化されて保護されている場合でも、人々に関する情報はさまざまな目的で収集または処理される可能性があります。人々の近くにあるIoTデバイスがより広範な監視を可能にするかもしれないという事実は、彼らのプライバシーに悪影響を与える可能性があります。たとえば、近くにいる人の存在または不在により、静的存在センサーがパケットを送信するシナリオを想像してみてください。このようなシナリオでは、パケットを観察できる人はだれでも、重要なプライバシー機密情報を収集できます。
Such information about people is referred to as personal data in the European Union (EU) or Personally identifiable information (PII) in the US. In particular, the General Data Protection Regulation (GDPR) [GDPR] defines personal data as: "any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person".
このような人に関する情報は、欧州連合（EU）では個人データ、米国では個人識別情報（PII）と呼ばれます。特に、一般データ保護規則（GDPR）[GDPR]は、個人データを次のように定義しています。「識別された、または識別可能な自然人（「データ主体」）に関するあらゆる情報。識別可能な自然人とは、直接、または間接的に、特に名前、識別番号、場所データ、オンライン識別子などの識別子、またはその自然の物理的、生理学的、遺伝的、精神的、経済的、文化的または社会的アイデンティティに固有の1つ以上の要素を参照する人"。
Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold guarantee:
Ziegeldorf [Ziegeldorf]は、IoTにおけるプライバシーを3つの保証として定義しています。
1. Awareness of the privacy risks imposed by IoT devices and services. This awareness is achieved by means of transparent practices by the data controller, i.e., the entity that is providing IoT devices and/or services.
1. IoTデバイスおよびサービスによって課せられるプライバシーリスクの認識。この認識は、データコントローラー、つまりIoTデバイスやサービスを提供しているエンティティによる透過的なプラクティスによって達成されます。
2. Individual control over the collection and processing of personal information by IoT devices and services.
2. IoTデバイスとサービスによる個人情報の収集と処理に対する個別の制御。
3. Awareness and control of the subsequent use and dissemination of personal information by data controllers to any entity outside the subject's personal control sphere. This point implies that the data controller must be accountable for its actions on the personal information.
3. データ管理者による個人情報のその後の使用と普及の認識と管理、対象の個人管理領域外のエンティティへの配布。この点は、データ管理者が個人情報に対するアクションに対して責任を負う必要があることを意味します。
Based on this definition, several threats to the privacy of users have been documented [Ziegeldorf] [RFC6973], in particular considering the IoT environment and its lifecycle:
この定義に基づいて、特にIoT環境とそのライフサイクルを考慮して、ユーザーのプライバシーに対するいくつかの脅威が文書化されています[Ziegeldorf] [RFC6973]。
1. Identification - refers to the identification of the users, their IoT devices, and generated data.
1. 識別-ユーザー、そのIoTデバイス、および生成されたデータの識別を指します。
2. Localization - relates to the capability of locating a user and even tracking them, e.g., by tracking MAC addresses in Wi-Fi or Bluetooth.
2. ローカライゼーション-たとえば、Wi-FiまたはBluetoothでMACアドレスを追跡することにより、ユーザーを特定し、追跡する機能に関連します。
3. Profiling - is about creating a profile of the user and their preferences.
3. プロファイリング-ユーザーとその設定のプロファイルを作成することです。
4. Interaction - occurs when a user has been profiled and a given interaction is preferred, presenting (for example, visually) some information that discloses private information.
4. インタラクション-ユーザーのプロファイルが作成され、特定のインタラクションが好ましい場合に発生し、個人情報を開示する情報を（たとえば視覚的に）提示します。
5. Lifecycle transitions - take place when devices are, for example, sold without properly removing private data.
5. ライフサイクルの移行-たとえば、個人データを適切に削除せずにデバイスが販売された場合などに発生します。
6. Inventory attacks - happen if specific information about IoT devices in possession of a user is disclosed.
6. インベントリ攻撃-ユーザーが所有しているIoTデバイスに関する特定の情報が開示された場合に発生します。
7. Linkage - is about when information of two of more IoT systems (or other data sets) is combined so that a broader view of the personal data captured can be created.
7. リンケージ-2つ以上のIoTシステム（または他のデータセット）の情報を組み合わせて、収集された個人データのより広いビューを作成できるようにすることを指します。
When IoT systems are deployed, the above issues should be considered to ensure that private data remains private. These issues are particularly challenging in environments in which multiple users with different privacy preferences interact with the same IoT devices. For example, an IoT device controlled by user A (low privacy settings) might leak private information about another user B (high privacy settings). How to deal with these threats in practice is an area of ongoing research.
IoTシステムを展開するときは、上記の問題を考慮して、プライベートデータがプライベートのままであることを確認する必要があります。これらの問題は、プライバシー設定が異なる複数のユーザーが同じIoTデバイスと対話する環境では特に困難です。たとえば、ユーザーA（プライバシー設定が低い）によって制御されているIoTデバイスは、別のユーザーB（プライバシー設定が高い）に関する個人情報を漏洩する可能性があります。これらの脅威に実際に対処する方法は、現在進行中の研究分野です。
Many IoT devices are resource constrained and often deployed in unattended environments. Some of these devices can also be purchased off the shelf or online without any credential-provisioning process. Therefore, an attacker can have direct access to the device and apply advanced techniques to retrieve information that a traditional black-box model does not consider. Examples of those techniques are side-channel attacks or code disassembly. By doing this, the attacker can try to retrieve data such as:
多くのIoTデバイスはリソースに制約があり、多くの場合、無人環境に展開されます。これらのデバイスの一部は、クレデンシャルプロビジョニングプロセスなしで、市販またはオンラインで購入することもできます。したがって、攻撃者はデバイスに直接アクセスし、高度な手法を適用して、従来のブラックボックスモデルでは考慮されていない情報を取得できます。これらの手法の例は、サイドチャネル攻撃やコードの逆アセンブリです。これを行うことにより、攻撃者は次のようなデータを取得しようとすることができます。
1. Long-term keys. These long-term keys can be extracted by means of a side-channel attack or reverse engineering. If these keys are exposed, then they might be used to perform attacks on devices deployed in other locations.
1. 長期キー。これらの長期鍵は、サイドチャネル攻撃またはリバースエンジニアリングによって抽出できます。これらのキーが公開されると、他の場所に展開されたデバイスへの攻撃に使用される可能性があります。
2. Source code. Extraction of source code might allow the attacker to determine bugs or find exploits to perform other types of attacks. The attacker might also just sell the source code.
2. ソースコード。ソースコードの抽出により、攻撃者はバグを特定したり、他の種類の攻撃を実行するためのエクスプロイトを見つけたりする可能性があります。攻撃者は、ソースコードを販売することもできます。
3. Proprietary algorithms. The attacker can analyze these algorithms gaining valuable know-how. The attacker can also create copies of the product (based on those proprietary algorithms) or modify the algorithms to perform more advanced attacks.
3. 独自のアルゴリズム。攻撃者はこれらのアルゴリズムを分析して、貴重なノウハウを得ることができます。攻撃者は、製品のコピー（独自のアルゴリズムに基づく）を作成したり、アルゴリズムを変更してより高度な攻撃を実行したりすることもできます。
4. Configuration or personal data. The attacker might be able to read personal data, e.g., healthcare data, that has been stored on a device.
4. 構成または個人データ。攻撃者は、デバイスに保存されている個人データ（ヘルスケアデータなど）を読み取ることができる可能性があります。
One existing solution to prevent such data leaks is the use of a secure element, a tamper-resistant device that is capable of securely hosting applications and their confidential data. Another potential solution is the usage of a Physical Unclonable Function (PUF) that serves as unique digital fingerprint of a hardware device. PUFs can also enable other functionalities such as secure key storage. Protection against such data leakage patterns is not trivial since devices are inherently resource-constrained. An open question is whether there are any viable techniques to protect IoT devices and the data in the devices in such an adversarial model.
このようなデータ漏洩を防ぐための既存のソリューションの1つは、アプリケーションとその機密データを安全にホストできる改ざん防止デバイスであるセキュアエレメントの使用です。もう1つの解決策として考えられるのは、ハードウェアデバイスの一意のデジタルフィンガープリントとして機能する物理的クローン解除機能（PUF）の使用です。 PUFは、セキュアキーストレージなどの他の機能を有効にすることもできます。デバイスは本質的にリソースに制約があるため、このようなデータ漏洩パターンに対する保護は簡単ではありません。未解決の問題は、そのような敵対的なモデルでIoTデバイスとデバイス内のデータを保護するための実行可能な技術があるかどうかです。
Flaws in the design and implementation of IoT devices and networks can lead to security vulnerabilities. A common flaw is the use of well-known or easy-to-guess passwords for configuration of IoT devices. Many such compromised IoT devices can be found on the Internet by means of tools such as Shodan [shodan]. Once discovered, these compromised devices can be exploited at scale -- for example, to launch DDoS attacks. Dyn, a major DNS service provider, was attacked by means of a DDoS attack originating from a large IoT botnet composed of thousands of compromised IP cameras [Dyn-Attack]. There are several open research questions in this area:
IoTデバイスとネットワークの設計と実装の欠陥は、セキュリティの脆弱性につながる可能性があります。よくある欠陥は、IoTデバイスの構成によく知られている、または推測が容易なパスワードを使用することです。このような侵害されたIoTデバイスの多くは、Shodan [shodan]などのツールを使用してインターネット上で見つけることができます。いったん発見されると、これらの侵害されたデバイスは大規模に悪用される可能性があります。たとえば、DDoS攻撃を開始するためです。主要なDNSサービスプロバイダーであるDynは、侵害された数千のIPカメラで構成される大規模なIoTボットネットから発生するDDoS攻撃によって攻撃されました[Dyn-Attack]。この分野には、いくつかの未解決の研究課題があります。
1. How to avoid vulnerabilities in IoT devices that can lead to large-scale attacks?
1. 大規模な攻撃につながる可能性のあるIoTデバイスの脆弱性を回避するにはどうすればよいですか？
2. How to detect sophisticated attacks against IoT devices?
2. IoTデバイスに対する高度な攻撃を検出するにはどうすればよいですか？
3. How to prevent attackers from exploiting known vulnerabilities at a large scale?
3. 攻撃者が既知の脆弱性を大規模に悪用することを防ぐにはどうすればよいですか？
Some ideas are being explored to address this issue. One of the approaches relies on the use of Manufacturer Usage Description (MUD) files [RFC8520]. As explained earlier, this proposal requires IoT devices to disclose the location of their MUD file to the network during installation. The network can then (i) retrieve those files, (ii) learn from the manufacturers the intended usage of the devices (for example, which services they need to access), and then (iii) create suitable filters and firewall rules.
この問題に対処するためにいくつかのアイデアが検討されています。アプローチの1つは、製造元使用説明（MUD）ファイル[RFC8520]の使用に依存しています。前に説明したように、この提案では、IoTデバイスがインストール時にMUDファイルの場所をネットワークに開示する必要があります。ネットワークは、（i）それらのファイルを取得し、（ii）製造元からデバイスの使用目的（たとえば、どのサービスにアクセスする必要があるか）を学習し、（iii）適切なフィルターとファイアウォールルールを作成できます。
This document provides IoT security researchers, system designers, and implementers with an overview of security requirements in the IP-based Internet of Things. We discuss the security threats, state of the art, and challenges.
このドキュメントは、IoTセキュリティの研究者、システム設計者、および実装者に、IPベースのモノのインターネットにおけるセキュリティ要件の概要を提供します。セキュリティの脅威、最新技術、課題について説明します。
Although plenty of steps have been realized during the last few years (summarized in Section 4.1) and many organizations are publishing general recommendations describing how IoT should be secured (Section 4.3), there are many challenges ahead that require further attention. Challenges of particular importance are bootstrapping of security, group security, secure software updates, long-term security and quantum-resistance, privacy protection, data leakage prevention -- where data could be cryptographic keys, personal data, or even algorithms -- and ensuring trustworthy IoT operation.
過去数年の間に多くのステップが実現され（セクション4.1に要約）、多くの組織がIoTのセキュリティ保護方法を説明する一般的な推奨事項を公開しています（セクション4.3）が、さらなる注意を必要とする多くの課題があります。特に重要な課題は、セキュリティ、グループセキュリティ、セキュリティで保護されたソフトウェアの更新、長期的なセキュリティと量子耐性、プライバシー保護、データ漏洩防止（データが暗号化キー、個人データ、またはアルゴリズムでさえある場合）のブートストラップと、その確保です。信頼できるIoT運用。
Authors of new IoT specifications and implementers need to consider how all the security challenges discussed in this document (and those that emerge later) affect their work. The authors of IoT specifications need to put in a real effort towards not only addressing the security challenges but also clearly documenting how the security challenges are addressed. This would reduce the chances of security vulnerabilities in the code written by implementers of those specifications.
新しいIoT仕様の作成者と実装者は、このドキュメントで説明されているすべてのセキュリティの課題（および後で発生するもの）が自分の作業にどのように影響するかを考慮する必要があります。 IoT仕様の作成者は、セキュリティの課題に対処するだけでなく、セキュリティの課題への対処方法を明確に文書化するために真の努力を払う必要があります。これにより、これらの仕様の実装者が記述したコードにセキュリティの脆弱性が生じる可能性が低くなります。
This entire memo deals with security issues.
このメモ全体は、セキュリティの問題を扱っています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[ACE-DTLS] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, draft-ietf-ace-dtls-authorize-08, April 2019.
[ACE-DTLS] Gerdes、S.、Bergmann、O.、Bormann、C.、Selander、G.、and L. Seitz、 "Datagram Transport Layer Security（DTLS）Profile for Authentication and Authorization for Constrained Environments（ACE）" 、Work in Progress、draft-ietf-ace-dtls-authorize-08、2019年4月。
[ACE-OAuth] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace-oauth-authz-24, March 2019.
[ACE-OAuth] Seitz、L.、Selander、G.、Wahlstroem、E.、Erdtman、S。、およびH. Tschofenig、「OAuth 2.0フレームワークを使用した制約付き環境（ACE）の認証と承認（ACE-OAuth） "、作業中、draft-ietf-ace-oauth-authz-24、2019年3月。
[ARCH-6TiSCH] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-20, March 2019.
[ARCH-6TiSCH] Thubert、P。、「IEEE 802.15.4のTSCHモードを介したIPv6のアーキテクチャ」、作業中、draft-ietf-6tisch-architecture-20、2019年3月。
[Article29] Article 29 Data Protection Working Party, "Opinion 8/2014 on the Recent Developments on the Internet of Things", WP 223, September 2014, <https://ec.europa.eu/justice/ article-29/documentation/opinion-recommendation/files/2014/wp223_en.pdf>.
[Article29] Article 29 Data Protection Working Party、 "Opinion 8/2014 on the Recent Developments on Internet of Things"、WP 223、2014年9月、<https://ec.europa.eu/justice/article-29/documentation /opinion-recommendation/files/2014/wp223_en.pdf>。
[AUTO-ID] "Auto-ID Labs", September 2010, <https://www.autoidlabs.org/>.
[AUTO-ID]「Auto-ID Labs」、2010年9月、<https://www.autoidlabs.org/>。
[BACNET] American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), "BACnet", February 2011, <http://www.bacnet.org>.
[BACNET] American Society of Heating、Refrigerating and Air-Conditioning Engineers（ASHRAE）、「BACnet」、2011年2月、<http://www.bacnet.org>。
[BITAG] Broadband Internet Technical Advisory Group, "Internet of Things (IoT) Security and Privacy Recommendations", November 2016, <https://www.bitag.org/report-internet-of-things-security-privacy-recommendations.php>.
[BITAG]ブロードバンドインターネット技術諮問グループ、「モノのインターネット（IoT）のセキュリティとプライバシーに関する推奨事項」、2016年11月、<https://www.bitag.org/report-internet-of-things-security-privacy-recommendations。 php>。
[BOOTSTRAP] Sarikaya, B., Sethi, M., and D. Garcia-Carillo, "Secure IoT Bootstrapping: A Survey", Work in Progress, draft-sarikaya-t2trg-sbootstrapping-06, January 2019.
[ブートストラップ] Sarikaya、B.、Sethi、M。、およびD. Garcia-Carillo、「Secure IoT Bootstrapping：A Survey」、Work in Progress、draft-sarikaya-t2trg-sbootstrapping-06、2019年1月。
[C2PQ] Hoffman, P., "The Transition from Classical to Post-Quantum Cryptography", Work in Progress, draft-hoffman-c2pq-04, August 2018.
[C2PQ]ホフマン、P。、「古典からポスト量子暗号への移行」、進行中の作業、draft-hoffman-c2pq-04、2018年8月。
[cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an Email Address In China", February 2016, <https://hardware.slashdot.org/story/16/02/17/0422259/ backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an-email-address-in-china>.
[cctv]「MVPower DVRファームウェアのバックドアがCCTV静止画を中国のメールアドレスに送信する」、2016年2月、<https://hardware.slashdot.org/story/16/02/17/0422259/ backdoor-in-mvpower- dvr-firmware-sends-cctv-stills-to-an-email-address-in-china>。
[ChaCha] Bernstein, D., "ChaCha, a variant of Salsa20", January 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.
[ChaCha] Bernstein、D。、「ChaCha、Salsa20のバリアント」、2008年1月、<http://cr.yp.to/chacha/chacha-20080128.pdf>。
[CSA] Cloud Security Alliance Mobile Working Group, "Security Guidance for Early Adopters of the Internet of Things (IoT)", April 2015, <https://downloads.cloudsecurityalliance.org/whitepapers/S ecurity_Guidance_for_Early_Adopters_of_the_Internet_of_Thi ngs.pdf>.
[CSA]クラウドセキュリティアライアンスモバイルワーキンググループ、「モノのインターネット（IoT）の早期導入者のためのセキュリティガイダンス」、2015年4月、<https://downloads.cloudsecurityalliance.org/whitepapers/S ecurity_Guidance_for_Early_Adopters_of_the_Internet_of_Thi ngs.pdf>。
[DALI] DALIbyDesign, "DALI Explained", February 2011, <http://www.dalibydesign.us/dali.html>.
SHALALISHT Dalibadesign、「DALI Explained」、2011年2月、<http：//vvv.dalibudesign.us/dali.html>。
[Daniel] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", Work in Progress, draft-daniel-6lowpan-security-analysis-05, March 2011.
[Daniel] Park、S.、Kim、K.、Haddad、W.、Chakrabarti、S。、およびJ. Laganier、「低電力WPANセキュリティ分析によるIPv6」、作業中、draft-daniel-6lowpan-security-分析-05、2011年3月。
[DCMS] UK Department for Digital Culture, Media & Sport, "Secure by Design: Improving the cyber security of consumer Internet of Things Report", March 2018, <https://www.gov.uk/government/publications/ secure-by-design-report>.
[DCMS]英国デジタル文化、メディア、スポーツ省、「Secure by Design：Improving the cyber security of consumer Internet of Things Report」、2018年3月、<https://www.gov.uk/government/publications/secure- by-design-report>。
[DHS] U.S. Department of Homeland Security, "Strategic
Principles For Securing the Internet of Things (IoT)",
November 2016,
<https://www.dhs.gov/sites/default/files/publications/
Strategic_Principles_for_Securing_the_Internet_of_Things-
2016-1115-FINAL....pdf>.
[Diet-ESP] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression and Diet-ESP", Work in Progress, draft-mglt-ipsecme-diet-esp-07, March 2019.
[Diet-ESP] Migault、D.、Guggemos、T.、Bormann、C。、およびD. Schinazi、「ESPヘッダー圧縮とDiet-ESP」、作業中、draft-mglt-ipsecme-diet-esp-07 、2019年3月。
[Dyn-Attack] Oracle Dyn, "Dyn Analysis Summary Of Friday October 21 Attack", October 2016, <https://dyn.com/blog/ dyn-analysis-summary-of-friday-october-21-attack/>.
[Dyn-Attack] Oracle Dyn、「Dyn Analysis Summary Of Friday October 21 Attack」、2016年10月、<https://dyn.com/blog/ dyn-analysis-summary-of-friday-october-21-attack /> 。
[ecc25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", February 2006, <https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
[ecc25519] Bernstein、D。、「Curve25519：新しいDiffie-Hellman速度レコード」、2006年2月、<https://cr.yp.to/ecdh/curve25519-20060209.pdf>。
[ECSO] "European Cyber Security Organisation", <https://www.ecs-org.eu/>.
[ECSO]「ヨーロッパのサイバーセキュリティ組織」、<https://www.ecs-org.eu/>。
[ENISA-ICS] European Union Agency for Network and Information Security, "Communication network dependencies for ICS/ SCADA Systems", February 2017, <https://www.enisa.europa.eu/publications/ ics-scada-dependencies>.
[ENISA-ICS]欧州連合ネットワーク情報セキュリティ庁、「ICS / SCADAシステムの通信ネットワーク依存関係」、2017年2月、<https://www.enisa.europa.eu/publications/ics-scada-dependencies>。
[ETSI-GR-QSC-001] European Telecommunications Standards Institute (ETSI), "Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic framework", ETSI GR QSC 001, July 2016, <https://www.etsi.org/deliver/etsi_gr/ QSC/001_099/001/01.01.01_60/gr_qsc001v010101p.pdf>.
[ETSI-GR-QSC-001] European Telecommunications Standards Institute（ETSI）、「Quantum-Safe Cryptography（QSC）; Quantum-safe Algorithmic framework」、ETSI GR QSC 001、2016年7月、<https：//www.etsi。 org / deliver / etsi_gr / QSC / 001_099 / 001 / 01.01.01_60 / gr_qsc001v010101p.pdf>。
[Fairhair] "The Fairhair Alliance", <https://www.fairhair-alliance.org/>.
[Fairhair]「The Fairhair Alliance」、<https://www.fairhair-alliance.org/>。
[FCC] US Federal Communications Commission, Chairman Tom Wheeler to Senator Mark Warner, December 2016, <https://docs.fcc.gov/public/attachments/ DOC-342761A1.pdf>.
[FCC]米国連邦通信委員会、トムウィーラー会長からマークワーナー上院議員、2016年12月、<https://docs.fcc.gov/public/attachments/ DOC-342761A1.pdf>。
[FTCreport] US Federal Trade Commission, "FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks", January 2015, <https://www.ftc.gov/news-events/press-releases/2015/01/ ftc-report-internet-things-urges-companies-adopt-best-practices>.
[FTCレポート]米国連邦取引委員会、「モノのインターネットに関するFTCレポートは企業に消費者のプライバシーとセキュリティのリスクに対処するためのベストプラクティスの採用を促す」、2015年1月、<https://www.ftc.gov/news-events/press-リリース/ 2015/01 / ftc-report-internet-things-urges-companies-adopt-best-practices>。
[GDPR] "The EU General Data Protection Regulation", <https://www.eugdpr.org>.
[GDPR]「EU一般データ保護規則」、<https://www.eugdpr.org>。
[GSMAsecurity] "GSMA IoT Security Guidelines and Assessment", <http://www.gsma.com/connectedliving/future-iot-networks/ iot-security-guidelines>.
[GSMAsecurity]「GSMA IoTセキュリティガイドラインと評価」、<http://www.gsma.com/connectedliving/future-iot-networks/iot-security-guidelines>。
[HIP-DEX] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Work in Progress, draft-ietf-hip-dex-06, December 2017.
[HIP-DEX] Moskowitz、R。およびR. Hummen、「HIP Diet EXchange（DEX）」、Work in Progress、draft-ietf-hip-dex-06、2017年12月。
[IEEE802ah] IEEE, "Status of Project IEEE 802.11ah", IEEE P802.11 - Task Group AH - Meeting Update, <http://www.ieee802.org/11/Reports/tgah_update.htm>.
[IEEE802ah] IEEE、「Status of Project IEEE 802.11ah」、IEEE P802.11-Task Group AH-Meeting Update、<http://www.ieee802.org/11/Reports/tgah_update.htm>。
[IIoT] "Industrial Internet Consortium", <http://www.iiconsortium.org>.
[IIoT]「Industrial Internet Consortium」、<http://www.iiconsortium.org>。
[IoTSecFoundation] Internet of Things Security Foundation, "Establishing Principles for Internet of Things Security", <https://iotsecurityfoundation.org/establishing-principles-for-internet-of-things-security>.
[IoTSecFoundation] Internet of Things Security Foundation、「Establishing Principles for Internet of Things Security」、<https://iotsecurityfoundation.org/establishing-principles-for-internet-of-things-security>。
[IPv6-over-NFC] Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, "Transmission of IPv6 Packets over Near Field Communication", Work in Progress, draft-ietf-6lo-nfc-13, February 2019.
[IPv6-over-NFC] Choi、Y.、Hong、Y.、Youn、J.、Kim、D。、およびJ. Choi、「近距離無線通信によるIPv6パケットの送信」、作業中、draft-ietf -6lo-nfc-13、2019年2月。
[ISOC-OTA] Internet Society, "Online Trust Alliance (OTA)", <https://www.internetsociety.org/ota/>.
[ISOC-OTA]インターネット協会、「Online Trust Alliance（OTA）」、<https://www.internetsociety.org/ota/>。
[LoRa] "LoRa Alliance", <https://www.lora-alliance.org/>.
[LoRa]「LoRa Alliance」、<https://www.lora-alliance.org/>。
[LWM2M] OMA SpecWorks, "Lightweight M2M (LWM2M)", <http://openmobilealliance.org/iot/lightweight-m2m-lwm2m>.
[LWM2M] OMA SpecWorks、「Lightweight M2M（LWM2M）」、<http://openmobilealliance.org/iot/lightweight-m2m-lwm2m>。
[Mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,, "DDoS in the IoT: Mirai and Other Botnets", Computer, Vol. 50, Issue 7, DOI 10.1109/MC.2017.201, July 2017, <https://ieeexplore.ieee.org/document/7971869>.
[Mirai] Kolias、C.、Kambourakis、G.、Stavrou、A。、およびJ. Voas、「IoTにおけるDDoS：Miraiおよびその他のボットネット」、Computer、Vol。 50、Issue 7、DOI 10.1109 / MC.2017.201、2017年7月、<https://ieeexplore.ieee.org/document/7971869>。
[Moore] Moore, K., Barnes, R., and H. Tschofenig, "Best Current Practices for Securing Internet of Things (IoT) Devices", Work in Progress, draft-moore-iot-security-bcp-01, July 2017.
[ムーア]ムーア、K。、バーンズ、R。、およびH.チョフェニグ、「モノのインターネット（IoT）デバイスを保護するための現在のベストプラクティス」、作業中、draft-moore-iot-security-bcp-01、7月2017。
[MULTICAST] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, draft-ietf-core-oscore-groupcomm-04, March 2019.
[マルチキャスト] Tiloca、M.、Selander、G.、Palombini、F.、J。Park、「Group OSCORE-Secure Group Communication for CoAP」、Work in Progress、draft-ietf-core-oscore-groupcomm-04、 2019年3月。
[NB-IoT] Qualcomm Incorporated, "New Work Item: NarrowBand IOT (NB-IOT)", September 2015, <http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/ RP-151621.zip>.
[NB-IoT] Qualcomm Incorporated、「New Work Item：NarrowBand IOT（NB-IOT）」、2015年9月、<http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/ RP-151621。 zip>。
[NHTSA] National Highway Traffic Safety Administration, "Cybersecurity Best Practices for Modern Vehicles", Report No. DOT HS 812 333, October 2016, <https://www.nhtsa.gov/staticfiles/nvs/ pdf/812333_CybersecurityForModernVehicles.pdf>.
[NHTSA] National Highway Traffic Safety Administration、 "Cybersecurity Best Practices for Modern Vehicles"、Report No. DOT HS 812 333、October 2016、<https://www.nhtsa.gov/staticfiles/nvs/ pdf / 812333_CybersecurityForModernVehicles.pdf> 。
[NIST-Guide] Ross, R., McEvilley, M., and J. Oren, "Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems", NIST Special Publication 800-160, DOI 10.6028/NIST.SP.800-160, November 2016, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800\ -160.pdf>.
[NIST-Guide] Ross、R.、McEvilley、M.、J。Oren、「システムセキュリティエンジニアリング：信頼できる安全なシステムのエンジニアリングにおける学際的アプローチに関する考慮事項」、NIST Special Publication 800-160、DOI 10.6028 / NIST .SP.800-160、2016年11月、<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800 \ -160.pdf>。
[NIST-LW-2016] Sonmez Turan, M., "NIST's Lightweight Crypto Project", October 2016, <https://www.nist.gov/sites/default/files/ documents/2016/10/17/ sonmez-turan-presentation-lwc2016.pdf>.
[NIST-LW-2016] Sonmez Turan、M。、「NISTの軽量暗号プロジェクト」、2016年10月、<https://www.nist.gov/sites/default/files/documents/2016/10/17/ sonmez- turan-presentation-lwc2016.pdf>。
[NIST-LW-PROJECT] NIST, "Lightweight Cryptography", <https://www.nist.gov/ programs-projects/lightweight-cryptography>.
[NIST-LW-PROJECT] NIST、「軽量暗号」、<https://www.nist.gov/programs-projects/lightweight-cryptography>。
[NISTSP800-122] McCallister, E., Grance, T., and K. Scarfone, "Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)", NIST Special Publication 800-122, April 2010, <https://nvlpubs.nist.gov/nistpubs/legacy/sp/ nistspecialpublication800-122.pdf>.
[NISTSP800-122] McCallister、E.、Grance、T。、およびK. Scarfone、「個人を特定できる情報（PII）の機密性を保護するためのガイド」、NIST Special Publication 800-122、2010年4月、<https：// nvlpubs.nist.gov/nistpubs/legacy/sp/ nistspecialpublication800-122.pdf>。
[NISTSP800-30r1] National Institute of Standards and Technology, "Guide for Conducting Risk Assessments", NIST Special Publication 800-30 Revision 1, September 2012, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-30r1.pdf>.
[NISTSP800-30r1]国立標準技術研究所、「リスク評価を実施するためのガイド」、NIST Special Publication 800-30 Revision 1、2012年9月、<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800 -30r1.pdf>。
[NISTSP800-34r1] Swanson, M., Bowen, P., Phillips, A., Gallup, D., and D. Lynes, "Contingency Planning Guide for Federal Information Systems", NIST Special Publication 800-34 Revision 1, May 2010, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-34r1.pdf>.
[NISTSP800-34r1] Swanson、M.、Bowen、P.、Phillips、A.、Gallup、D。、およびD. Lynes、「連邦情報システムの緊急時対応計画ガイド」、NIST Special Publication 800-34 Revision 1、5月2010、<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-34r1.pdf>。
[OCF] "Open Connectivity Foundation", <https://openconnectivity.org/>.
[OCF]「Open Connectivity Foundation」、<https://openconnectivity.org/>。
[OMASpecWorks] "OMA SpecWorks", <https://www.omaspecworks.org/ipso-alliance>.
[OMASpecWorks]「OMA SpecWorks」、<https://www.omaspecworks.org/ipso-alliance>。
[OneM2M] "OneM2M", <http://www.onem2m.org>.
[OneM2M]「OneM2M」、<http://www.onem2m.org>。
[OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", Work in Progress, draft-ietf-core-object-security-16, March 2019.
[OSCORE] Selander、G.、Mattsson、J.、Palombini、F。、およびL. Seitz、「制約付きRESTful環境のオブジェクトセキュリティ（OSCORE）」、作業中、draft-ietf-core-object-security-16 、2019年3月。
[OWASP] The OWASP Foundation, "IoT Security Guidance", February 2017, <https://www.owasp.org/index.php/IoT_Security_Guidance>.
[OWASP] OWASP Foundation、「IoT Security Guidance」、2017年2月、<https://www.owasp.org/index.php/IoT_Security_Guidance>。
[RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, Ed., "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-20, March 2019.
[RD]シェルビー、Z。、コスター、M。、ボルマン、C。、ストック、P。、およびC.アムス、編、「CoREリソースディレクトリ」、作業中、draft-ietf-core-resource-directory -20、2019年3月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、DOI 10.17487 / RFC3748、2004年6月、<https://www.rfc-editor.org/info/rfc3748>。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, <https://www.rfc-editor.org/info/rfc3756>.
[RFC3756] Nikander、P.、Ed。、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、DOI 10.17487 / RFC3756、2004年5月、<https：// www.rfc-editor.org/info/rfc3756>。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC3833] Atkins、D。およびR. Austein、「ドメインネームシステム（DNS）の脅威分析」、RFC 3833、DOI 10.17487 / RFC3833、2004年8月、<https://www.rfc-editor.org/info / rfc3833>。
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, <https://www.rfc-editor.org/info/rfc4016>.
[RFC4016] Parthasarathy、M。、「認証とネットワークアクセス（PANA）の脅威分析とセキュリティ要件を実行するためのプロトコル」、RFC 4016、DOI 10.17487 / RFC4016、2005年3月、<https://www.rfc-editor.org/ info / rfc4016>。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.
[RFC4108] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、DOI 10.17487 / RFC4108、2005年8月、<https://www.rfc-editor.org/info/rfc4108> 。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、DOI 10.17487 / RFC4120、2005年7月、<https：// www.rfc-editor.org/info/rfc4120>。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.
[RFC4422]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、DOI 10.17487 / RFC4422、2006年6月、<https://www.rfc-editor.org/info/rfc4422>。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <https://www.rfc-editor.org/info/rfc4555>.
[RFC4555] Eronen、P。、「IKEv2 Mobility and Multihoming Protocol（MOBIKE）」、RFC 4555、DOI 10.17487 / RFC4555、2006年6月、<https://www.rfc-editor.org/info/rfc4555>。
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, DOI 10.17487/RFC4621, August 2006, <https://www.rfc-editor.org/info/rfc4621>.
[RFC4621] Kivinen、T。およびH. Tschofenig、「Design of the IKEv2 Mobility and Multihoming（MOBIKE）Protocol」、RFC 4621、DOI 10.17487 / RFC4621、2006年8月、<https://www.rfc-editor.org/ info / rfc4621>。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, DOI 10.17487/RFC4738, November 2006, <https://www.rfc-editor.org/info/rfc4738>.
[RFC4738] Ignjatic、D.、Dondeti、L.、Audet、F。、およびP. Lin、「MIKEY-RSA-R：マルチメディアインターネットキーイング（MIKEY）でのキー配布の追加モード」、RFC 4738、DOI 10.17487 / RFC4738、2006年11月、<https://www.rfc-editor.org/info/rfc4738>。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919] Kushalnagar、N.、Montenegro、G。、およびC. Schumacher、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」、RFC 4919、DOI 10.17487 / RFC4919 、2007年8月、<https://www.rfc-editor.org/info/rfc4919>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https： //www.rfc-editor.org/info/rfc4944>。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5191] Forsberg、D.、Ohba、Y.、Ed。、Patil、B.、Tschofenig、H.、A。Yegin、「Protocol for Carrying Authentication for Network Access（PANA）」、RFC 5191、DOI 10.17487 / RFC5191、2008年5月、<https://www.rfc-editor.org/info/rfc5191>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, January 2010, <https://www.rfc-editor.org/info/rfc5713>.
[RFC5713] Moustafa、H.、Tschofenig、H。、およびS. De Cnodder、「セキュリティ脅威とAccess Node Control Protocol（ANCP）のセキュリティ要件」、RFC 5713、DOI 10.17487 / RFC5713、2010年1月、<https： //www.rfc-editor.org/info/rfc5713>。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, DOI 10.17487/RFC5903, June 2010, <https://www.rfc-editor.org/info/rfc5903>.
[RFC5903] Fu、D。およびJ. Solinas、「IKEおよびIKEv2のPrime（ECPグループ）を法とする楕円曲線グループ」、RFC 5903、DOI 10.17487 / RFC5903、2010年6月、<https：//www.rfc-editor .org / info / rfc5903>。
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC6024] Reddy、R。およびC. Wallace、「Trust Anchor Management Requirements」、RFC 6024、DOI 10.17487 / RFC6024、2010年10月、<https://www.rfc-editor.org/info/rfc6024>。
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, <https://www.rfc-editor.org/info/rfc6272>.
[RFC6272]ベイカー、F。およびD.マイヤー、「スマートグリッドのインターネットプロトコル」、RFC 6272、DOI 10.17487 / RFC6272、2011年6月、<https://www.rfc-editor.org/info/rfc6272>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T。、編、Thubert、P。、編、Brandt、A。、ホイ、J。、ケルシー、R。、リーバイス、P。、ピスター、K。、ストルーク、R。、ヴァッサー、JP。、およびR.アレクサンダー、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https://www.rfc-editor.org/info/ rfc6550>。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <https://www.rfc-editor.org/info/rfc6551>.
[RFC6551] Vasseur、JP。、Ed。、Kim、M.、Ed。、Pister、K.、Dejean、N.、and D. Barthel、 "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks"、 RFC 6551、DOI 10.17487 / RFC6551、2012年3月、<https://www.rfc-editor.org/info/rfc6551>。
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, DOI 10.17487/RFC6568, April 2012, <https://www.rfc-editor.org/info/rfc6568>.
[RFC6568] Kim、E.、Kaspar、D.、JP。 Vasseur、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）の設計およびアプリケーションスペース」、RFC 6568、DOI 10.17487 / RFC6568、2012年4月、<https://www.rfc-editor.org/info/rfc6568> 。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<https://www.rfc-editor.org/info/rfc6690>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049] Bormann、C。およびP. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<https://www.rfc-editor.org/info/rfc7049> 。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<https://www.rfc-editor.org / info / rfc7228>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「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、「インターネットキーエクスチェンジプロトコルバージョン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.、Ed。、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]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<https://www.rfc-editor.org/info/rfc7516>。
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC7517]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<https://www.rfc-editor.org/info/rfc7517>。
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https://www.rfc-editor.org / info / rfc7519>。
[RFC7520] Miller, M., "Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)", RFC 7520, DOI 10.17487/RFC7520, May 2015, <https://www.rfc-editor.org/info/rfc7520>.
[RFC7520] Miller、M。、「JSONオブジェクトの署名と暗号化（JOSE）を使用したコンテンツ保護の例」、RFC 7520、DOI 10.17487 / RFC7520、2015年5月、<https://www.rfc-editor.org/info/ rfc7520>。
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <https://www.rfc-editor.org/info/rfc7668>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z。、およびC. Gomez、「IPv6 over BLUETOOTH（R）Low Energy」、RFC 7668、DOI 10.17487 / RFC7668、2015年10月、<https://www.rfc-editor.org/info/rfc7668>。
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[RFC7696] Housley、R。、「暗号化アルゴリズムの敏捷性と実装必須アルゴリズムの選択に関するガイドライン」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<https://www.rfc-editor.org / info / rfc7696>。
[RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., and S. Kumar, "Use Cases for Authentication and Authorization in Constrained Environments", RFC 7744, DOI 10.17487/RFC7744, January 2016, <https://www.rfc-editor.org/info/rfc7744>.
[RFC7744] Seitz、L.、Ed。、Gerdes、S.、Ed。、Selander、G.、Mani、M.、and S. Kumar、 "Use Cases for Authentication and Authorization in Constrained Environments"、RFC 7744、DOI 10.17487 / RFC7744、2016年1月、<https://www.rfc-editor.org/info/rfc7744>。
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, <https://www.rfc-editor.org/info/rfc7815>.
[RFC7815] Kivinen、T。、「Minimal Internet Key Exchange Version 2（IKEv2）Initiator Implementation」、RFC 7815、DOI 10.17487 / RFC7815、2016年3月、<https://www.rfc-editor.org/info/rfc7815> 。
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.
[RFC7925] Tschofenig、H.、Ed。 T. Fossati、「モノのインターネットのためのトランスポート層セキュリティ（TLS）/データグラムトランスポート層セキュリティ（DTLS）プロファイル」、RFC 7925、DOI 10.17487 / RFC7925、2016年7月、<https：//www.rfc-editor。 org / info / rfc7925>。
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, <https://www.rfc-editor.org/info/rfc8046>.
[RFC8046] Henderson、T.、Ed。、Vogt、C。、およびJ. Arkko、「Host Identity Protocol with the Host Identity Protocol」、RFC 8046、DOI 10.17487 / RFC8046、2017年2月、<https：//www.rfc -editor.org/info/rfc8046>。
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8105] Mariager、P.、Petersen、J.、Ed。、Shelby、Z.、Van de Logt、M。、およびD. Barthel、「Digital Enhanced Cordless Telecommunications（DECT）超低エネルギーによるIPv6パケットの送信（ ULE）」、RFC 8105、DOI 10.17487 / RFC8105、2017年5月、<https://www.rfc-editor.org/info/rfc8105>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J。、「CBOR Object Signing and Encryption（COSE）」、RFC 8152、DOI 10.17487 / RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>。
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet of Things Software Update (IoTSU) Workshop 2016", RFC 8240, DOI 10.17487/RFC8240, September 2017, <https://www.rfc-editor.org/info/rfc8240>.
[RFC8240] Tschofenig、H。およびS. Farrell、「Internet of Things Software Update（IoTSU）Workshop 2016」、RFC 8240、DOI 10.17487 / RFC8240、2017年9月、<https：//www.rfc-editor。 org / info / rfc8240>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, <https://www.rfc-editor.org/info/rfc8376>.
[RFC8376] Farrell、S。、編、「低電力ワイドエリアネットワーク（LPWAN）の概要」、RFC 8376、DOI 10.17487 / RFC8376、2018年5月、<https://www.rfc-editor.org/info/ rfc8376>。
[RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387, May 2018, <https://www.rfc-editor.org/info/rfc8387>.
[RFC8387] Sethi、M.、Arkko、J.、Keranen、A。、およびH. Back、「実用的な考慮事項とスマートオブジェクトネットワークの保護における実装経験」、RFC 8387、DOI 10.17487 / RFC8387、2018年5月、<https： //www.rfc-editor.org/info/rfc8387>。
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428]ジェニングス、C。、シェルビー、Z。、アルコ、J。、ケラネン、A。、およびC.ボーマン、「センサー測定リスト（SenML）」、RFC 8428、DOI 10.17487 / RFC8428、2018年8月、<https ：//www.rfc-editor.org/info/rfc8428>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.
[RFC8520] Lear、E.、Droms、R。、およびD. Romascanu、「Manufacturer Usage Description Specification」、RFC 8520、DOI 10.17487 / RFC8520、2019年3月、<https://www.rfc-editor.org/info / rfc8520>。
[RG-T2TRG] IRTF, "Thing-to-Thing Research Group (T2TRG)", <https://datatracker.ietf.org/rg/t2trg/charter/>.
[RG-T2TRG] IRTF、「Thing-to-Thing Research Group（T2TRG）」、<https://datatracker.ietf.org/rg/t2trg/charter/>。
[SchneierSecurity] Schneier, B., "The Internet of Things Is Wildly Insecure -- And Often Unpatchable", January 2014, <https://www.schneier.com/essays/archives/2014/01/ the_internet_of_thin.html>.
[SchneierSecurity] Schneier、B.、「モノのインターネットは非常に安全ではなく、パッチを適用できないことが多い」、2014年1月、<https://www.schneier.com/essays/archives/2014/01/ the_internet_of_thin.html>。
[SEAL] Microsoft, "Microsoft SEAL: Fast and Easy-to-Use Homomorphic Encryption Library", <https://www.microsoft.com/en-us/research/project/ microsoft-seal/>.
[SEAL] Microsoft、「Microsoft SEAL：高速で使いやすいHomomorphic Encryption Library」、<https://www.microsoft.com/en-us/research/project/ microsoft-seal />。
[shodan] "Shodan", <https://www.shodan.io>.
「しょだん」 ”しょだん”、 ＜ｈっｔｐｓ：／／ｗっｗ。しょだん。いお＞。
[sigfox] "Sigfox - The Global Communications Service Provider for the Internet of Things (IoT)", <https://www.sigfox.com>.
[sigfox]「Sigfox-モノのインターネット（IoT）のグローバルコミュニケーションサービスプロバイダー」、<https://www.sigfox.com>。
[Thread] "Thread", <http://threadgroup.org>.
[スレッド] "スレッド"、<http://threadgroup.org>。
[TR69] Oppenheim, L. and S. Tal, "Too Many Cooks - Exploiting the Internet-of-TR-069-Things", December 2014, <https://media.ccc.de/v/31c3_-_6166_-_en_-_saal_6_- _201412282145_-_too_many_cooks_-_exploiting_the_internet-of-tr-069-things_-_lior_oppenheim_-_shahar_tal>.
[TR69]オッペンハイム、L。、およびS.タル、「Too Many Cooks-Exploit the Internet-of-TR-069-Things」、2014年12月、<https://media.ccc.de/v/31c3_-_6166_- _en _-_ saal_6_- _201412282145 _-_ too_many_cooks _-_ exploiting_the_internet-of-tr-069-things _-_ lior_oppenheim _-_ shahar_tal>。
[venona-project] National Security Agency | Central Security Service, "VENONA", <https://www.nsa.gov/news-features/declassified-documents/venona/index.shtml>.
[venona-project]国家安全保障局|中央セキュリティサービス、「VENONA」、<https://www.nsa.gov/news-features/declassified-documents/venona/index.shtml>。
[WG-6lo] IETF, "IPv6 over Networks of Resource-constrained Nodes (6lo)", <https://datatracker.ietf.org/wg/6lo/charter/>.
[WG-6lo] IETF、「リソースに制約のあるノードのネットワーク上のIPv6（6lo）」、<https://datatracker.ietf.org/wg/6lo/charter/>。
[WG-6LoWPAN] IETF, "IPv6 over Low power WPAN (6lowpan)", <http://datatracker.ietf.org/wg/6lowpan/charter/>.
[WG-6LoWPAN] IETF、「IPv6 over Low power WPAN（6lowpan）」、<http://datatracker.ietf.org/wg/6lowpan/charter/>。
[WG-ACE] IETF, "Authentication and Authorization for Constrained Environments (ace)", <https://datatracker.ietf.org/wg/ace/charter/>.
[WG-ACE] IETF、「制約された環境の認証と承認（ace）」、<https://datatracker.ietf.org/wg/ace/charter/>。
[WG-ACME] IETF, "Automated Certificate Management Environment (acme)", <https://datatracker.ietf.org/wg/acme/charter/>.
[WG-ACME] IETF、「自動証明書管理環境（acme）」、<https://datatracker.ietf.org/wg/acme/charter/>。
[WG-CoRE] IETF, "Constrained RESTful Environment (core)", <https://datatracker.ietf.org/wg/core/charter/>.
[WG-CoRE] IETF、「制約付きRESTful環境（コア）」、<https://datatracker.ietf.org/wg/core/charter/>。
[WG-LPWAN] IETF, "IPv6 over Low Power Wide-Area Networks (lpwan)", <https://datatracker.ietf.org/wg/lpwan/charter/>.
[WG-LPWAN] IETF、「IPv6 over Low Power Wide-Area Networks（lpwan）」、<https://datatracker.ietf.org/wg/lpwan/charter/>。
[WG-LWIG] IETF, "Light-Weight Implementation Guidance (lwig)", <https://datatracker.ietf.org/wg/lwig/charter/>.
[WG-LWIG] IETF、「軽量実装ガイダンス（lwig）」、<https://datatracker.ietf.org/wg/lwig/charter/>。
[WG-MSEC] IETF, "Multicast Security (msec)", <https://datatracker.ietf.org/wg/msec/charter/>.
[WG-MSEC] IETF、「マルチキャストセキュリティ（ミリ秒）」、<https://datatracker.ietf.org/wg/msec/charter/>。
[WG-SUIT] IETF, "Software Updates for Internet of Things (suit)", <https://datatracker.ietf.org/wg/suit/charter/>.
[WG-SUIT] IETF、「モノのインターネット（スーツ）のソフトウェアアップデート」、<https://datatracker.ietf.org/wg/suit/charter/>。
[WG-TEEP] IETF, "Trusted Execution Environment Provisioning (teep)", <https://datatracker.ietf.org/wg/teep/charter/>.
[WG-TEEP] IETF、「Trusted Execution Environment Provisioning（teep）」、<https://datatracker.ietf.org/wg/teep/charter/>。
[Williams] Williams, M. and J. Barrett, "Mobile DTLS", Work in Progress, draft-barrett-mobile-dtls-00, March 2009.
[ウィリアムズ]ウィリアムズ、M.、J。バレット、「Mobile DTLS」、Work in Progress、draft-barrett-mobile-dtls-00、2009年3月。
[wink] Barrett, B., "Wink's Outage Shows Us How Frustrating Smart Homes Could Be", Wired, Gear, April 2015, <http://www.wired.com/2015/04/smart-home-headaches/>.
[ウィンク]バレット、B。、「ウィンクの停止はスマートホームがいかに苛立たしいかを示す」、Wired、Gear、2015年4月、<http://www.wired.com/2015/04/smart-home-headaches/> 。
[ZB] "Zigbee Alliance", <http://www.zigbee.org/>.
[ZB]「Zigbee Alliance」、<http://www.zigbee.org/>。
[Ziegeldorf] Ziegeldorf, J., Garcia Morchon, O., and K. Wehrle, "Privacy in the Internet of Things: Threats and Challenges", Security and Communication Networks, Vol. 7, Issue 12, pp. 2728-2742, DOI 10.1002/sec.795, 2014.
[Ziegeldorf] Ziegeldorf、J.、Garcia Morchon、O.、and K. Wehrle、 "Privacy in the Internet of Things：Threats and Challenges"、Security and Communication Networks、Vol。 7、12号、pp.2728-2742、DOI 10.1002 / sec.795、2014。
Acknowledgments
謝辞
We gratefully acknowledge feedback and fruitful discussion with Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig, Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred Baker, Vicent Roca, Thomas Fossati, and Eliot Lear. We acknowledge the additional authors of a draft version of this document: Sye Loong Keoh, Rene Hummen, and Rene Struik.
Tobias Heer、Robert Moskowitz、Thorsten Dahm、Hannes Tschofenig、Carsten Bormann、Barry Raveendran、Ari Keranen、Goran Selander、Fred Baker、Vicent Roca、Thomas Fossati、およびEliot Learとのフィードバックと有益な議論に感謝します。このドキュメントのドラフトバージョンの追加の作成者であるSye Loong Keoh、Rene Hummen、およびRene Struikを認めます。
Authors' Addresses
著者のアドレス
Oscar Garcia-Morchon Philips High Tech Campus 5 Eindhoven, 5656 AE The Netherlands
オスカーガルシアモルコンフィリップスハイテクキャンパス5アイントホーフェン、5656 AEオランダ
Email: oscar.garcia-morchon@philips.com
Sandeep S. Kumar Signify High Tech Campus 7 Eindhoven, 5656 AE The Netherlands
Sandeep S. Kumarが意味するハイテクキャンパス7アイントホーフェン、5656 AEオランダ
Email: sandeep.kumar@signify.com
Mohit Sethi Ericsson Jorvas 02420 Finland
Mohit Sethi Ericsson Jorvas 02420フィンランド
Email: mohit@piuha.net