[要約] RFC 8240は、2016年のIoTソフトウェアアップデート（IoTSU）ワークショップの報告書です。このRFCの目的は、IoTデバイスのセキュアなソフトウェアアップデートに関する課題と解決策を議論することです。
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 8240 S. Farrell
Category: Informational September 2017
ISSN: 2070-1721
Report from the Internet of Things Software Update (IoTSU) Workshop 2016
モノのインターネットソフトウェアアップデート（IoTSU）ワークショップ2016からのレポート
Abstract
概要
This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.
このドキュメントは、2016年6月13日および14日にアイルランドのトリニティカレッジダブリンで開催されたモノのインターネットソフトウェアアップデート（IoTSU）ワークショップの概要を提供します。ワークショップの主な目的は、要件、課題に関する議論を促進することでした。 、およびソフトウェアとファームウェアの更新をIoTデバイスにもたらすためのソリューション。このレポートは、議論を要約し、標準化コミュニティへの推奨事項をリストします。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8240.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8240で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Questions Raised . . . . . . . . . . . . . . 6
4. Authorizing a Software/Firmware Update . . . . . . . . . . . 12
5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 13
6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15
8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16
9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 17
10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17
11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 24
Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 24
Appendix C. List of Participants . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop [IoTSU] that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices.
このドキュメントは、2016年6月13日と14日にアイルランドのトリニティカレッジダブリンで開催されたモノのインターネットソフトウェアアップデート（IoTSU）ワークショップ[IoTSU]の概要を提供します。ワークショップの主な目的は、 IoTデバイスにソフトウェアとファームウェアの更新をもたらすための要件、課題、およびソリューション。
The views and positions in this report are those of the workshop participants and do not necessarily reflect those of their employers/ sponsors, the authors of this memo, nor the Internet Architecture Board (IAB), under whose auspices the workshop was held.
このレポートの見解と見解はワークショップ参加者の見解と見解であり、必ずしもワークショップが主催された彼らの雇用者/スポンサー、このメモの著者、またはインターネットアーキテクチャボード（IAB）の見解と見解を反映しているわけではありません。
The IAB holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. The topics investigated often require coordinated efforts of different organizations and industry bodies to improve an identified problem. One of the goals of such workshops is to assist with communication between relevant organizations, companies, and universities, especially when the topics are partly out of the scope for the Internet Engineering Task Force (IETF). This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF.
IABは、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。調査されたトピックは、特定された問題を改善するために、さまざまな組織や業界団体の調整された取り組みを必要とすることがよくあります。そのようなワークショップの目的の1つは、特にトピックがインターネット技術特別調査委員会（IETF）の範囲外である場合は特に、関連組織、企業、大学間のコミュニケーションを支援することです。 IABのこの長期計画機能は、IETFのワーキンググループによって実行されている継続的なエンジニアリングの取り組みを補完するものです。
In his essay "The Internet of Things Is Wildly Insecure -- And Often Unpatchable" [BS14], Bruce Schneier expressed concerns about the status of software/firmware updates for IoT devices. IoT devices, which have a reputation for being insecure from the time they are manufactured, are often expected to stay active in the field for 10 or more years and to operate unattended with Internet connectivity.
Bruce Schneierは、エッセイ「モノのインターネットは非常に安全ではなく、パッチを適用できないことが多い」[BS14]で、IoTデバイスのソフトウェア/ファームウェアの更新状況について懸念を表明しています。 IoTデバイスは、製造された時点から安全ではないという評判があり、フィールドで10年以上アクティブであり、インターネット接続なしで無人で動作することが期待されています。
Incorporating a software update mechanism to fix vulnerabilities, to update configuration settings and, to add new functionality as well, is recommended by security experts. However, there are challenges when using software updates, as documented in the United States Federal Trade Commission (FTC) report titled "internet of things: Privacy & Security in a Connected World" [FTC] and in the Article 29 Data Protection Working Party document "Opinion 8/2014 on the on [sic] Recent Developments on the Internet of Things"[WP29].
セキュリティの専門家は、脆弱性を修正し、構成設定を更新し、新しい機能を追加するためのソフトウェア更新メカニズムを組み込むことを推奨しています。ただし、米国連邦取引委員会（FTC）のレポート「モノのインターネット：接続された世界でのプライバシーとセキュリティ」[FTC]および第29条のデータ保護ワーキングパーティーの文書に記載されているように、ソフトウェアアップデートの使用には課題があります。 「オピニオン8/2014 on on [sic]最近の開発、モノのインターネット」[WP29]。
Among the challenges in designing a basic software/firmware update function are:
基本的なソフトウェア/ファームウェア更新機能の設計における課題には、次のものがあります。
- Implementations of software update mechanisms may incorporate vulnerabilities, becoming an attractive attack target. See, for example, [OS14].
- ソフトウェア更新メカニズムの実装には脆弱性が組み込まれている可能性があり、魅力的な攻撃対象になる可能性があります。たとえば、[OS14]を参照してください。
- Operational challenges, such as the case of an expired certificate in a hub device [BB14].
- ハブデバイスで証明書が期限切れになる場合などの運用上の課題[BB14]。
- Privacy issues if devices "call home" often to check for updates.
- 更新を確認するためにデバイスが「コールホーム」を頻繁に行う場合のプライバシーの問題。
- A lack of incentives to distribute software updates along the value chain.
- バリューチェーンに沿ってソフトウェアアップデートを配布するインセンティブがない。
- Questions such as the following. Who should be able to update device software after normal support stops? When should an alternate source of software updates take over?
- 以下のような質問です。通常のサポートが停止した後、誰がデバイスソフトウェアを更新できますか？ソフトウェアアップデートの代替ソースはいつ引き継ぐべきですか？
There are various (often proprietary) software update mechanisms in use today, and the functionality of those varies significantly with the envisioned use of the IoT devices. More powerful IoT devices, such as those running general purpose operating systems (like Linux), can make use of sophisticated software update mechanisms known from the desktop and the mobile world. This workshop focused on more constrained IoT devices that often run dedicated real-time operating systems or potentially no operating system at all.
今日使用されているさまざまな（多くの場合は独自仕様の）ソフトウェア更新メカニズムがあり、それらの機能はIoTデバイスの想定される使用によって大幅に異なります。汎用オペレーティングシステム（Linuxなど）を実行しているデバイスなど、より強力なIoTデバイスは、デスクトップやモバイルの世界で知られている高度なソフトウェア更新メカニズムを利用できます。このワークショップは、専用のリアルタイムオペレーティングシステムを実行することが多い、またはオペレーティングシステムをまったく実行しない可能性がある、より制約の多いIoTデバイスに焦点を当てました。
There is a real risk that many IoT devices will continue to be shipped without a solid software/firmware update mechanism in place. Ideally, IoT software developers and product designers should be able to integrate standardized mechanisms that have experienced substantial review and where the documentation is available to the public.
多くのIoTデバイスが、堅固なソフトウェア/ファームウェアの更新メカニズムなしで出荷され続けるという実際のリスクがあります。理想的には、IoTソフトウェア開発者と製品設計者は、実質的なレビューを経てドキュメントが公開されている標準化されたメカニズムを統合できる必要があります。
Hence, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state of the art and to identify requirements and gaps. In particular, the call for position papers asked for:
そのため、IABは、関連する利害関係者に連絡して最新技術を調査し、要件とギャップを特定するためのワークショップを開催することを決定しました。特に、ポジションペーパーの募集では、
- Protocol mechanisms for distributing software updates.
- ソフトウェアの更新を配布するためのプロトコルメカニズム。
- Mechanisms for securing software updates.
- ソフトウェア更新を保護するためのメカニズム。
- Metadata about software/firmware packages.
- ソフトウェア/ファームウェアパッケージに関するメタデータ。
- Implications of operating system and hardware design on the software update mechanisms.
- ソフトウェア更新メカニズムに対するオペレーティングシステムとハードウェア設計の影響。
- Installation of software updates (in context of software and hardware security of IoT devices).
- ソフトウェア更新のインストール（IoTデバイスのソフトウェアおよびハードウェアセキュリティのコンテキストで）。
- Privacy implications of software update mechanisms.
- ソフトウェア更新メカニズムのプライバシーへの影響。
- Implications of device ownership and control for software update.
- ソフトウェアの更新に対するデバイスの所有権と制御の影響。
The rest of the document is organized as follows: basic terminology is provided in Section 2, followed by a longer section discussing requirements. Subsequent sections explore selected topics, such as incentives and measurements in more detail. Most of the write-up does raise more questions than it answers. Nevertheless, we tried to synthesize possible conclusions and offer a few next steps.
ドキュメントの残りの部分は次のように構成されています。基本的な用語はセクション2で提供され、その後に要件を説明する長いセクションが続きます。後続のセクションでは、インセンティブや測定など、選択したトピックについて詳しく説明します。ほとんどの記事では、回答よりも多くの質問が出されます。それにもかかわらず、私たちは可能な結論を総合し、いくつかの次のステップを提供しようとしました。
As is typical with people from different backgrounds, workshop participants started the workshop with a discussions of terminology. This section is more intended to reflect those discussions than to present canonical definitions of terms.
さまざまなバックグラウンドを持つ人々によく見られるように、ワークショップの参加者は、用語について話し合ってワークショップを開始しました。このセクションは、用語の標準的な定義を提示するよりも、それらの議論を反映することを目的としています。
Device Classes: IoT devices come in various "sizes" (such as size of RAM or size of flash memory). With these configurations, devices are limited in what they can support in terms of operating-system features, cryptographic algorithms, and protocol stacks. For this reason, the group differentiated two types of classes, namely ARM Cortex A-class/Intel Atom and Cortex M-class/Intel Quark types of devices. A-class devices are equipped with powerful processors typically found in set-top boxes and home routers. The Raspberry Pi is an example of an A-class device that is capable of running a regular desktop operating system, such as Linux. There are differences between the Intel and the ARM-based CPUs in terms of architecture, microcode, and who is allowed to update a Basic Input/Output System (BIOS) (if available). A detailed discussion of these hardware architectural differences were, however, outside the scope of the workshop. The implication is that lower-end microcontrollers have constraints that put restrictions on the amount of software that can be put on them. While it is easy to require support of a wide range of features, those may not necessarily fit on these devices.
デバイスクラス：IoTデバイスには、さまざまな「サイズ」（RAMのサイズやフラッシュメモリのサイズなど）があります。これらの構成では、オペレーティングシステムの機能、暗号化アルゴリズム、およびプロトコルスタックに関して、デバイスがサポートできる機能が制限されます。このため、グループは2種類のクラス、つまりARM Cortex Aクラス/ Intel AtomとCortex Mクラス/ Intel Quarkタイプのデバイスを区別しました。 Aクラスのデバイスには、セットトップボックスやホームルーターによく見られる強力なプロセッサが搭載されています。 Raspberry Piは、Linuxなどの通常のデスクトップオペレーティングシステムを実行できるAクラスデバイスの例です。アーキテクチャ、マイクロコード、および基本入出力システム（BIOS）（利用可能な場合）を更新できるユーザーの点で、IntelベースのCPUとARMベースのCPUの間には違いがあります。ただし、これらのハードウェアアーキテクチャの違いに関する詳細な議論は、ワークショップの範囲外でした。つまり、ローエンドのマイクロコントローラーには、搭載できるソフトウェアの量を制限する制約があるということです。幅広い機能のサポートを必要とすることは簡単ですが、これらのデバイスに必ずしも適合するとは限りません。
Software Update and Firmware Update: Based on the device classes, it was observed that regular operating systems come with sophisticated software update mechanisms (such as Red Hat Package Manager (RPM) [RPM] or pacman [PACMAN]) that make use of the operating system to install and run each application in a compartmentalized fashion. Firmware updates typically do not provide such a fine-grained granularity for software updates and instead distribute the entire binary image, which consists of the (often minimalistic) operating system and all applications. While the distinction between the mechanisms that A-class and M-class devices will typically use may get more fuzzy over time, most M-class devices use firmware updates while A-class devices use a combination of firmware and software updates (with firmware updates being less frequent operations).
ソフトウェアの更新とファームウェアの更新：デバイスクラスに基づいて、通常のオペレーティングシステムには、オペレーティングシステムを利用する高度なソフトウェア更新メカニズム（Red Hat Package Manager（RPM）[RPM]またはpacman [PACMAN]など）が付属していることが確認されました各アプリケーションを区分化された方法でインストールおよび実行するシステム。ファームウェアの更新は、通常、ソフトウェアの更新にそのようなきめ細かい粒度を提供せず、代わりに（多くの場合最小限の）オペレーティングシステムとすべてのアプリケーションで構成されるバイナリイメージ全体を配布します。 AクラスデバイスとMクラスデバイスが通常使用するメカニズムの違いは、時間の経過とともに曖昧になる可能性がありますが、ほとんどのMクラスデバイスはファームウェア更新を使用しますが、Aクラスデバイスはファームウェアとソフトウェア更新の組み合わせ（ファームウェア更新を使用）を使用します頻度の低い操作です）。
Hitless Update: A hitless update implies that the user experience is not "hit", i.e., it is not impacted. It is possible to impact the user experience when applying an update even when the device does not reboot (to obtain or apply said update). If the update is applied when a user is not using a product and their service is not impacted, the update is "hitless".
ヒットレスアップデート：ヒットレスアップデートは、ユーザーエクスペリエンスが「ヒット」しないこと、つまり影響を受けないことを意味します。デバイスが再起動しない場合でも、更新を適用すると（上記の更新を取得または適用するため）、ユーザーエクスペリエンスに影響を与える可能性があります。ユーザーが製品を使用していないときに更新が適用され、サービスに影響がない場合、更新は「ヒットレス」です。
Workshop participants discussed requirements and several of these raised further questions. As with the previous section, we aim to present the discussion as it was.
ワークショップの参加者は要件について議論し、これらのいくつかはさらに質問を提起しました。前節と同様に、そのまま議論を提示していきたいと思います。
- There may be a need to be support partial (differential) updates that do not require the entire firmware image to be sent. This may mean that techniques like bsdiff [BSDIFF] and courgette [COURGETTE] are used but might also mean devices supporting the download of applications and libraries alone. The latter feature may require dynamic linking and position independent code. It was unclear whether position independent code should be recommended for low-end IoT devices.
- ファームウェアイメージ全体を送信する必要のない、部分的な（差分）更新をサポートする必要がある場合があります。これは、bsdiff [BSDIFF]やズッキーニ[COURGETTE]などの手法が使用されていることを意味する場合がありますが、アプリケーションとライブラリのダウンロードのみをサポートするデバイスを意味する場合もあります。後者の機能には、動的リンクと位置に依存しないコードが必要な場合があります。ローエンドのIoTデバイスに位置独立コードを推奨すべきかどうかは不明でした。
- The relative importance of dynamic linkers for low-end IoT devices is unclear. Some operating systems used with M-class devices, such as Contiki, provide support for a dynamic linker according to [OS-Support]. This could help to minimize the amount of data transmitted during updates since only the modified application or library needs to be transmitted.
- ローエンドIoTデバイスの動的リンカーの相対的な重要性は不明です。 Mクラスのデバイスで使用される一部のオペレーティングシステム（Contikiなど）は、[OS-Support]に従って動的リンカーをサポートしています。これにより、変更されたアプリケーションまたはライブラリのみを送信する必要があるため、更新中に送信されるデータの量を最小限に抑えることができます。
- How should dependencies among various software updates be handled? These dependencies may include information about the hardware platform and configuration as well as other software components running on a system. For firmware updates, the problem of dependencies are often solved by the manufacturer or Original Equipment Manufacturer (OEM) rather than on the device itself.
- さまざまなソフトウェアアップデート間の依存関係をどのように処理する必要がありますか？これらの依存関係には、ハードウェアプラットフォームと構成、およびシステムで実行されている他のソフトウェアコンポーネントに関する情報が含まれる場合があります。ファームウェアの更新の場合、依存関係の問題は、デバイス自体ではなく、製造元または相手先ブランド供給（OEM）によって解決されることがよくあります。
- Support for devices with multiple microcontrollers may require an architecture where one microcontroller is responsible for interacting with the update service and then dispatching software images to the attached microcontrollers within its local realm. The alternative of letting each microcontroller interact with an update service appeared less practical.
- 複数のマイクロコントローラーを備えたデバイスのサポートには、1つのマイクロコントローラーが更新サービスとの対話と、ローカルレルム内の接続されたマイクロコントローラーへのソフトウェアイメージのディスパッチを担当するアーキテクチャが必要な場合があります。各マイクロコントローラーを更新サービスとやり取りさせる代替策は、あまり実用的ではないように見えました。
- Support may be required for devices with multiple owners/ stakeholders where the question arises about who is authorized to push a firmware/software update.
- ファームウェア/ソフトウェアの更新をプッシュする権限が誰にあるかという質問が発生する、複数の所有者/関係者がいるデバイスでは、サポートが必要になる場合があります。
- Data origin authentication (DAO) was agreed to be required for software updates. Without DAO, updates simply become a perfect vulnerability. It is, however, nontrivial to ensure that the actual trust relationships that exist are modeled by the DAO mechanism. For some devices and deployment scenarios, any DAO mechanism is onerous, possibly to the point where it may be hard to convince a device maker to include the functionality.
- ソフトウェアの更新にはデータ発信元認証（DAO）が必要であることが合意されました。 DAOがなければ、更新は完全な脆弱性になります。ただし、存在する実際の信頼関係がDAOメカニズムによってモデル化されていることを確認することは重要です。一部のデバイスと展開シナリオでは、DAOメカニズムが煩わしく、デバイスメーカーに機能を含めるように説得するのが難しい場合があります。
- Should digital signatures and encryption for software updates be recommended as a best current practice? This question particularly raises the question about the use of symmetric key cryptography since not all low-end IoT devices are currently using asymmetric crypto.
- ソフトウェア署名のデジタル署名と暗号化は、現在のベストプラクティスとして推奨されますか？すべてのローエンドIoTデバイスが現在非対称暗号を使用しているわけではないため、この質問は特に対称鍵暗号の使用についての質問を提起します。
- DAO is most commonly provided via digital signature mechanisms, but symmetric schemes could also be developed, though IETF discussion of such mechanisms (for purposes less sensitive than software update) has proved significantly controversial. The main problem seems to be that simple symmetric schemes only ensure that the sender is a member of a group, and they do not fully authenticate a specific sender. And with a software update, we do not want any (possibly compromised) device to be able to authenticate new software for all other similar devices.
- DAOはデジタル署名メカニズムを介して提供されるのが最も一般的ですが、そのようなメカニズムに関するIETFの議論（ソフトウェアの更新よりも感度が低い目的のため）はかなり物議を醸すことが証明されていますが、対称的なスキームも開発できます。主な問題は、単純な対称方式では送信者がグループのメンバーであることを確認するだけであり、特定の送信者を完全に認証しないことです。また、ソフトウェアの更新により、他のすべての同様のデバイスの新しいソフトウェアを認証できる（侵害された可能性がある）デバイスが不要になります。
- What are the firmware update signing key requirements? Since devices have a rather long lifetime, there has to be a way to change the signing key during the lifetime of the device.
- ファームウェア更新署名の主要要件は何ですか？デバイスの寿命はかなり長いため、デバイスの寿命中に署名キーを変更する方法が必要です。
- Should a firmware update mechanism support multiple signatures of firmware images? Multiple signatures can come in two different flavors, namely:
- ファームウェア更新メカニズムは、ファームウェアイメージの複数の署名をサポートする必要がありますか？複数のシグネチャには、次の2つの異なる種類があります。
A single firmware image may be signed by multiple different parties. In this case, one could imagine an environment where an OEM signs the software it creates, but then the software is again signed by the enterprise that approves the distribution within the company. Other examples include regulatory signatures where the software for a medical device may be signed as approved by a certification body.
単一のファームウェアイメージが複数の異なる関係者によって署名される場合があります。この場合、OEMが作成したソフトウェアに署名するが、そのソフトウェアは企業内の配布を承認する企業によって再び署名される環境を想像できます。他の例には、医療機器のソフトウェアが認証機関によって承認されたとおりに署名される場合がある規制署名が含まれます。
A software image may contain libraries that are each signed by their developers.
ソフトウェアイメージには、それぞれの開発者によって署名されたライブラリが含まれている場合があります。
Is a device expected to verify the different types of signatures or is this a service provided by some unconstrained device? This raises questions about who the IoT device should trust for what and whether transitive trust is acceptable for some types of devices.
デバイスはさまざまなタイプの署名を検証する必要がありますか、それとも制約のないデバイスによって提供されるサービスですか？これは、IoTデバイスが誰に対して何を信頼する必要があるか、および推移的な信頼が一部のタイプのデバイスに受け入れられるかどうかについての疑問を提起します。
- Are applications from a range of sources allowed to run on a device or only those from the OEM? If the device is a "closed" device that only supports/runs software from the OEM, then a single signature may be sufficient. In a system that is more "open", third-party applications may require support of multiple signatures.
- さまざまなソースのアプリケーションをデバイスで実行できますか、それともOEMのアプリケーションのみですか？デバイスがOEMからのソフトウェアのみをサポート/実行する「クローズド」デバイスである場合、単一の署名で十分な場合があります。より「オープン」なシステムでは、サードパーティのアプリケーションが複数の署名のサポートを必要とする場合があります。
- There is a need for some form of secure storage, at least for those IoT devices that are exposed to physical attacks. This includes at least the need to protect the integrity of the public key of the update service on the device (if signature-based DAO is in use). The use of symmetric key cryptography requires improved confidentiality protection (in addition to integrity protection).
- 少なくとも物理的な攻撃にさらされているIoTデバイスには、何らかの形の安全なストレージが必要です。これには、少なくともデバイス上の更新サービスの公開キーの整合性を保護する必要性が含まれます（署名ベースのDAOが使用されている場合）。対称鍵暗号化を使用するには、（完全性保護に加えて）改善された機密保護が必要です。
- Is there a need to allow the update infrastructure side to authenticate the IoT device before distributing an update? Questions about the identifier used for such an authentication action were raised. The idea of reusing Media Access Control (MAC) addresses lead to concerns about the significant privacy implications of such identifier reuse.
- 更新を配布する前に、更新インフラストラクチャ側でIoTデバイスを認証できるようにする必要がありますか？このような認証アクションに使用される識別子に関する質問が提起されました。メディアアクセスコントロール（MAC）アドレスを再利用するという考えは、このような識別子の再利用によるプライバシーへの重大な影響に関する懸念につながります。
- It is important to minimize device/service downtime due to update processing and to minimize user interaction (e.g., car should not distract the driver) (see "Hitless Update" in Section 2). While it may not be possible to avoid all downtime, there was agreement that one ought to strive for "no inappropriate" device downtime. This means minimal downtime impacting the user/operation of the device. The definition of "downtime" also depends on the use case, with a smart light bulb, the device could be "up" if the light is still on, even if some advanced services are unavailable for a short time. Whether an update can be done without rebooting the device depends on the software being installed, on the OS architecture, and potentially even on the hardware architecture. The cost/benefit ratio also plays a role.
- 更新処理によるデバイス/サービスのダウンタイムを最小限に抑え、ユーザーの操作を最小限に抑えることが重要です（たとえば、車がドライバーの注意をそらさないようにする必要があります）（セクション2の「中断のない更新」を参照）。すべてのダウンタイムを回避することは不可能かもしれませんが、「不適切な」デバイスのダウンタイムがないように努めるべきであるという合意がありました。これは、デバイスのユーザー/操作に影響を与える最小限のダウンタイムを意味します。 「ダウンタイム」の定義はユースケースにも依存します。スマート電球の場合、ライトがまだオンの場合、一部の高度なサービスが短時間利用できない場合でも、デバイスは「アップ」になる可能性があります。デバイスを再起動せずにアップデートを実行できるかどうかは、インストールされているソフトウェア、OSアーキテクチャ、場合によってはハードウェアアーキテクチャによって異なります。費用便益比も役割を果たします。
- It is desirable to minimize the time taken from the start of the update to when it is finished. In some systems with many devices (e.g., industrial lighting), this can be a challenge if updates need to be unicasted.
- 更新の開始から終了までの時間を最小限に抑えることが望ましい。多くのデバイス（産業用照明など）を備えた一部のシステムでは、更新をユニキャストする必要がある場合、これが課題になることがあります。
- In some systems with multiple devices, it can be a challenge to ensure that all devices are at the same release level, especially if some devices are sleepy. There are some systems where ensuring all relevant devices are at the same release level is a hard requirement. In other cases, it is acceptable if devices converge much more slowly to the current release level.
- 複数のデバイスがある一部のシステムでは、特に一部のデバイスがスリープ状態にある場合、すべてのデバイスが同じリリースレベルであることを確認するのが難しい場合があります。一部のシステムでは、すべての関連デバイスが同じリリースレベルであることを確認することが難しい要件です。他の場合では、デバイスが現在のリリースレベルにはるかにゆっくりと収束しても問題ありません。
- It ought not be possible for a factory worker to compromise the update process (e.g., copy signing keys and install unauthorized public keys/trust anchors) during the manufacturing process. There are typically two factories involved: the first factory produces microcontrollers and other components and the second factory produces the complete product, such as a fridge. This fridge contains many of the components previously manufactured. Hence, the firmware of components produced in the first stage may be six months old when the fridge leaves the factory. One does not want to install a firmware update when the fridge boots the first time. For that time, the firmware update happens already at the end of the manufacturing process.
- 工場労働者が製造プロセス中に更新プロセスを侵害すること（たとえば、署名キーをコピーし、不正な公開キー/トラストアンカーをインストールすること）は不可能であるべきです。通常、関連する2つの工場があります。最初の工場はマイクロコントローラーとその他のコンポーネントを製造し、2番目の工場は冷蔵庫などの完全な製品を製造します。この冷蔵庫には、以前に製造されたコンポーネントの多くが含まれています。したがって、冷蔵庫が工場を出ると、最初の段階で作成されたコンポーネントのファームウェアは6か月前になる可能性があります。冷蔵庫が最初に起動するときに、ファームウェアの更新をインストールしたくありません。その間、ファームウェアの更新は製造プロセスの最後にすでに行われています。
- Should devices have a recovery procedure when the device gets compromised? How is the compromise detected?
- デバイスが侵害された場合、デバイスには回復手順が必要ですか？侵害はどのように検出されますか？
- There was a bit of discussion about the importance for IoT devices to know the current time for the purpose of checking certificate validity. For example, what does "real-time clock" (RTC) actually mean? And what constitutes "good enough" time? There are, however, cost, power, size, and environmental constraints that can make the addition of a real-time clock to an IoT device complex:
- 証明書の有効性を確認する目的でIoTデバイスが現在の時刻を知ることの重要性について、少し議論がありました。たとえば、「リアルタイムクロック」（RTC）は実際にはどういう意味ですか？そして、何が「十分な」時間を構成するのでしょうか？ただし、IoTデバイスへのリアルタイムクロックの追加を複雑にする可能性があるコスト、電力、サイズ、および環境の制約があります。
o Cost: Battery- or supercap-backed RTC modules might be several times the cost of the rest of the bill of materials.
o コスト：バッテリーまたはスーパーキャップ付きのRTCモジュールは、残りの部品表のコストの数倍になる場合があります。
o Size: The battery and other components are often several times larger than the rest of the material.
o サイズ：バッテリーやその他のコンポーネントは、他の素材より数倍大きいことがよくあります。
o Manufacturing: Some modules require an extra assembly step, because the battery could be damaged or explode at high temperatures during the reflow process.
o 製造：一部のモジュールでは、リフロープロセス中に高温でバッテリーが損傷または爆発する可能性があるため、追加の組み立て手順が必要です。
o Supply chain: Devices containing fitted batteries need additional supply-chain management to account for storage temperature and to avoid shipping aged devices.
o サプライチェーン：取り付けられた電池を含むデバイスは、保管温度を考慮し、古くなったデバイスの発送を避けるために、追加のサプライチェーン管理が必要です。
o Environmental: Real-time-clock modules are typically not rated at industrial temperature ranges. Those that are have extremely reduced lifetime at high temperatures.
o 環境：リアルタイムクロックモジュールは、通常、工業用温度範囲では定格されていません。高温での寿命が極端に短いもの。
o Lifetime: Some of these modules last only a few years at the top of their environmental range.
o 寿命：これらのモジュールの一部は、環境範囲の最高で数年しか持続しません。
While a good solution is needed, it is not clear whether there is one true solution. A recent proposal from Google called "Roughtime" [RT] may be worthwhile to explore.
良い解決策が必要ですが、真の解決策が1つあるかどうかは明確ではありません。 「ラフタイム」[RT]と呼ばれるGoogleの最近の提案は、検討する価値があるかもしれません。
- How do devices learn about a firmware update? Push or Pull? What should be required functionality for a firmware update protocol?
- デバイスはファームウェアの更新についてどのように学習しますか？押すか引くか？ファームウェア更新プロトコルに必要な機能は何ですか？
- There is a need to find out whether a software update was successful. In one discussed solution, the bootloader analyzes the performance of the running image to determine which image to run (rather than just verifying the integrity of the received image). One of the key criteria is that the updated system is able to make a connection to the device management/software update infrastructure. As long as it is able to talk to the update infrastructure, it can receive another update. As an alternative perspective, the argument was made that one needs to have a way to update the system without having the full system running.
- ソフトウェアの更新が成功したかどうかを確認する必要があります。説明する1つのソリューションでは、ブートローダーは実行中のイメージのパフォーマンスを分析して、（受信したイメージの整合性を検証するだけでなく）実行するイメージを決定します。重要な基準の1つは、更新されたシステムがデバイス管理/ソフトウェア更新インフラストラクチャに接続できることです。更新インフラストラクチャと通信できる限り、別の更新を受信できます。別の見方として、システム全体を稼働させずにシステムを更新する方法が必要であるという主張がなされました。
- Gateway requirements. In some deployments, gateways terminate the IP-based protocol communication and use non-IP mechanisms to communicate with other microcontrollers, for example, within a car. The gateway in such a system is the endpoint of the IP communication. The group had mixed feelings about the use of gateways versus the use of IP communication to every microcontroller. Participants argued that there is a lack of awareness of IPv6 header compression (with the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) standards) and of the possible benefits of IPv6 in those environments in terms of lowering the complexity of the overall system.
- ゲートウェイの要件。一部の展開では、ゲートウェイはIPベースのプロトコル通信を終了し、非IPメカニズムを使用して、車内などの他のマイクロコントローラーと通信します。このようなシステムのゲートウェイは、IP通信のエンドポイントです。グループは、ゲートウェイの使用と、すべてのマイクロコントローラーへのIP通信の使用について、さまざまな感情を抱いていました。参加者は、IPv6ヘッダー圧縮（IPv6 over Low-Powerワイヤレスパーソナルエリアネットワーク（6LoWPAN）標準を使用）に対する認識が不足しており、システム全体の複雑さを軽減するという観点から、これらの環境でIPv6がもたらす可能性のある利点について議論しました。 。
- The amount of energy consumed due to software update needs to be minimized. For example, awakening a sleepy device regularly only to check for new software would seem wasteful if the device cannot feasibly be exploited while asleep. However, the trade-off is that once the device awakens with old software, there may be a window of vulnerability if some relevant exploit has been discovered.
- ソフトウェアの更新により消費されるエネルギー量を最小限に抑える必要があります。たとえば、スリープ状態のデバイスを定期的に目覚めさせて、新しいソフトウェアをチェックすることだけは、デバイスがスリープ状態で悪用される可能性がない場合は無駄に見えます。ただし、トレードオフは、デバイスが古いソフトウェアで起動すると、関連するエクスプロイトが発見された場合に脆弱性のウィンドウが存在する可能性があることです。
- The amount of storage required for update ought to be minimized and can sometimes be significant. However, there are also benefits to schemes that store two or three different software images for robustness, e.g., if one has space for separate current last-known-good and being-updated images, then devices can better survive the buggy occasional updates that are also inevitable.
- 更新に必要なストレージの量は最小限に抑える必要があり、場合によってはかなりの量になることがあります。ただし、堅牢性のために2つまたは3つの異なるソフトウェアイメージを格納するスキームには利点もあります。たとえば、最新の既知の最新のイメージと更新中のイメージを個別に保存できるスペースがある場合、デバイスはバグの多い時々の更新に耐えることができます。また避けられない。
Which of the features discussed in the list above are nice to have? Which are required? Not all of these are required to achieve improvement. Which are most important?
上記のリストで説明した機能のうち、どれが便利ですか。どちらが必要ですか？これらすべてが改善を達成するために必要なわけではありません。最も重要なのはどれですか？
Among the participants, there was consensus that supporting signatures (for integrity and authentication) of the firmware image itself and the need for partial updates were seen as important.
参加者の間では、ファームウェアイメージ自体の署名（整合性と認証のため）のサポートと、部分的な更新の必要性が重要であると見なされているというコンセンサスがありました。
However, there were also concerns regarding the performance implications, since certain device categories may not utilize public key cryptography at all; hence, only a symmetric key approach seems viable, unless some other scheme such as a hash-based signature became practical (they currently aren't, due to signature size). This aspect raised concerns and triggered a discussion around the use of device management infrastructure, similar to Kerberos, that manages keys and distributes them to the appropriate parties. As such, in this setup, there could be a unique key shared with the key distribution center; but for use with specific services (such as a software update service), a fresh and unique secret would be distributed.
ただし、特定のデバイスカテゴリでは公開鍵暗号化をまったく使用できない場合があるため、パフォーマンスへの影響に関する懸念もありました。したがって、ハッシュベースの署名などの他の方式が実用的にならなかった場合を除いて、対称鍵アプローチのみが実行可能であるように見えます（署名サイズのために、現在は実際的ではありません）。この側面から懸念が高まり、Kerberosと同様に、鍵を管理して適切な関係者に配布するデバイス管理インフラストラクチャの使用に関する議論が起こりました。そのため、このセットアップでは、キー配布センターと共有する一意のキーが存在する可能性があります。ただし、特定のサービス（ソフトウェア更新サービスなど）で使用する場合は、新鮮で一意のシークレットが配布されます。
In addition to the requirements for the end devices, there are also infrastructure-related requirements. The infrastructure may consist of servers in the local network and/or various servers deployed on the Internet. It may also consist of some application-layer gateways. The potential benefits of having such a local server might include:
エンドデバイスの要件に加えて、インフラストラクチャ関連の要件もあります。インフラストラクチャは、ローカルネットワーク内のサーバーやインターネット上に展開されたさまざまなサーバーで構成されます。また、一部のアプリケーション層ゲートウェイで構成される場合もあります。このようなローカルサーバーを使用することの潜在的な利点には、次のものがあります。
- The local server acting for neighboring nodes. For example, in a vehicle one microcontroller can process all firmware updates and redistribute the relevant parts of those to interconnected microcontrollers.
- 隣接ノードの役割を果たすローカルサーバー。たとえば、車両では、1つのマイクロコントローラーがすべてのファームウェア更新を処理し、それらの関連部分を相互接続されたマイクロコントローラーに再配布できます。
- Local infrastructure could perform some digital signature checks on behalf of the devices, e.g., certificate-revocation checking.
- ローカルインフラストラクチャは、デバイスに代わっていくつかのデジタル署名チェック（証明書失効チェックなど）を実行できます。
- Local multicast can enable transmission of the same update to many devices.
- ローカルマルチキャストでは、同じ更新を多くのデバイスに送信できます。
- Local servers can hide complexity associated with Network Address Translation (NAT) and firewalls from the device.
- ローカルサーバーは、ネットワークアドレス変換（NAT）およびファイアウォールに関連する複雑さをデバイスから隠すことができます。
Another point related to local infrastructure is that since many IoT devices will not be (directly) connected to the Internet, but only through a gateway, there may in any case be a need to develop a software/firmware update mechanism that works in environments where no end-to-end Internet connectivity exists.
ローカルインフラストラクチャに関連するもう1つのポイントは、多くのIoTデバイスはインターネットに（直接）接続されず、ゲートウェイを介してのみ接続されるため、次のような環境で機能するソフトウェア/ファームウェア更新メカニズムを開発する必要がある場合があるエンドツーエンドのインターネット接続はありません。
Some current firmware update schemes need to identify devices. Different design approaches are possible.
現在の一部のファームウェア更新スキームでは、デバイスを識別する必要があります。さまざまな設計アプローチが可能です。
- In an extreme form in one case, the decision about updating a device is made by the infrastructure based on the unique device identification. The operator of the firmware update infrastructure knows about the hardware and software requirements for the IoT devices, knows about the policy for updating the device, etc. The device itself is provisioned with credentials so that it can verify a firmware update coming from an authorized device.
-極端な例では、デバイスの更新に関する決定は、一意のデバイスIDに基づいてインフラストラクチャによって行われます。ファームウェア更新インフラストラクチャのオペレーターは、IoTデバイスのハードウェアとソフトウェアの要件を知っている、デバイスを更新するためのポリシーを知っているなど。デバイス自体は、承認されたデバイスからのファームウェア更新を検証できるように資格情報がプロビジョニングされています。
- In another extreme, the device has knowledge about the software and hardware configuration and possible dependencies. It consults software repositories to obtain those software packages that are most appropriate. Verifying the authenticity of the software packages/firmware images will still be required.
- 別の極端な例として、デバイスはソフトウェアとハードウェアの構成および可能な依存関係についての知識を持っています。ソフトウェアリポジトリを参照して、最も適切なソフトウェアパッケージを取得します。ソフトウェアパッケージ/ファームウェアイメージの信頼性を確認する必要があります。
Hence, in some deployed software update mechanisms there is no desire for the device to be identified beyond the need to exchange information about the most recent software versions. For other devices, it is seen as important to identify the device itself in order to provide the appropriate firmware image/software packages.
したがって、一部の展開されたソフトウェア更新メカニズムでは、最新のソフトウェアバージョンに関する情報を交換する必要性を超えて、デバイスが識別されることを望んでいません。他のデバイスでは、適切なファームウェアイメージ/ソフトウェアパッケージを提供するために、デバイス自体を識別することが重要であると見なされています。
Related to device identification, various privacy concerns arise, such as the need to determine what information is provided to whom and the uses to which this information is put. For IoT devices where there is a close relationship to an individual (see [RFC6973]), privacy concerns are likely higher than for devices where such a relationship does not exist (e.g., a sensor measuring concrete). The software/firmware update mechanism should, however, not make the privacy situation of IoT devices worse. The proposal from the group was to introduce a minimal requirement of not sending any new identifiers over an unencrypted channel as part of an update protocol.
デバイスの識別に関連して、プライバシーに関するさまざまな懸念が生じます。たとえば、誰にどの情報を提供するか、この情報をどのように使用するかを決定する必要があります。個人と密接な関係にあるIoTデバイスの場合（[RFC6973]を参照）、プライバシーの懸念は、そのような関係が存在しないデバイス（たとえば、センサーでコンクリートを測定する）よりも高くなる可能性があります。ただし、ソフトウェア/ファームウェアの更新メカニズムによって、IoTデバイスのプライバシー状況が悪化することはありません。グループからの提案は、更新プロトコルの一部として暗号化されていないチャネルを介して新しい識別子を送信しないという最小限の要件を導入することでした。
However, software updates will provide yet another venue in which the tension between those advocating better privacy and those seeking to monetize information will play out. It is in the nature of software update that it requires devices to sometimes "call home" and such interactions provide fertile ground for monetization.
ただし、ソフトウェアの更新により、プライバシーの向上を主張する人々と情報を収益化しようとする人々との間の緊張が高まる別の場が提供されます。ソフトウェアアップデートの性質上、デバイスに「コールホーム」が必要な場合があり、そのようなやり取りにより収益化の余地が生まれます。
There were quite a few points revolving around authorization:
承認に関してはかなりの数のポイントがありました：
- Who can accept or reject an update? Is it the owner of the device, the user, or both? The user may not necessarily be the owner.
- 誰が更新を承認または拒否できますか？デバイスの所有者、ユーザー、またはその両方ですか？ユーザーは必ずしも所有者である必要はありません。
- With products that fall under a regulatory structure, such as healthcare, you don't want firmware other than what has been accredited.
- ヘルスケアなどの規制構造に該当する製品では、認定されている以外のファームウェアは必要ありません。
- In some cases, it will be very difficult for a firmware update system to communicate to users that an update is available. Doing so may require tracking the device and its status with regard to the installed firmware/software, with all the privacy downsides if such tracking is badly done.
- 場合によっては、ファームウェア更新システムが、更新が利用可能であることをユーザーに通知することが非常に困難になります。そうすることは、インストールされたファームウェア/ソフトウェアに関してデバイスとそのステータスを追跡することを必要とするかもしれません、そのような追跡がひどく行われるならば、すべてのプライバシーの欠点があります。
- Not all updates are the same. Security updates are often treated differently compared to feature updates, and the authorization for these may differ.
- すべてのアップデートが同じというわけではありません。多くの場合、セキュリティ更新は機能更新とは異なる方法で処理され、これらの承認は異なる場合があります。
- Some people may choose to decline updates, often on the basis that their system is currently stable, but also possibly due to concerns about unwanted changes, such as the HP printer firmware update pushed in March 2016 [HP-Firmware] that turned off features that end users liked.
- 一部の人々は、多くの場合、システムが現在安定しているという理由だけでなく、2016年3月にプッシュされたHPプリンターファームウェアのアップデート[HP-Firmware]などの機能をオフにする不要な変更に関する懸念のために、アップデートを拒否することを選択する場合があります。エンドユーザーが気に入りました。
There was quite a bit of discussion about end-of-support for products/devices and how to handle that.
製品/デバイスのサポート終了とその処理方法については、かなりの議論がありました。
- How should end-of-support or end-of-features be treated? Devices are often deployed for 10+ years (or even longer in some verticals). Device makers may not want or be able to support software and services for such an extended period of time. Will these devices stop working after a certain, previously unannounced period of time, such as Eye-Fi cards [EYEFI]?
- サポート終了または機能終了はどのように処理する必要がありますか？多くの場合、デバイスは10年以上（一部の業種ではさらに長く）展開されます。デバイスメーカーは、そのような長期間にわたってソフトウェアやサービスをサポートしたくない、またはサポートできない場合があります。これらのデバイスは、Eye-Fiカード[EYEFI]など、特定の以前に発表されていない期間が経過すると動作を停止しますか？
- There will be a broad range of device makers involved in IoT, who may differ substantially in terms of how well they can handle the full device life cycle. Some will be large commercial enterprises that are used to dealing with long device lifetimes, whereas others may be very small commercial entities where the device lifetime may be longer than the company lifetime. Yet other devices may be the result of open-source activities that prosper or flounder. The problem of end-of-support arises in all these cases, though feasible solutions for software update may substantially differ. In some cases, device makers may not be willing to continue to update devices, for example, due to a change in business strategies caused by a merger. In yet other cases, a company may have gone bankrupt.
- IoTにはさまざまなデバイスメーカーが関わっており、デバイスライフサイクル全体をどの程度適切に処理できるかは、メーカーによって大きく異なります。一部の企業は、長いデバイス寿命に対処することに慣れている大企業であり、他の企業は、デバイスの寿命が会社の寿命よりも長い可能性がある非常に小規模な企業である場合があります。さらに他のデバイスは、繁栄またはひらめくオープンソース活動の結果である可能性があります。これらすべてのケースでサポート終了の問題が発生しますが、ソフトウェアアップデートの実行可能なソリューションは大幅に異なる場合があります。場合によっては、たとえば、合併によってビジネス戦略が変更されたために、デバイスメーカーがデバイスの更新を続行する気がない場合があります。さらに別のケースでは、会社が破産した可能性があります。
- While there are many legal, ethical, and business-related questions, can we technically enable transfer of device service to another provider? Could there even be business models for entities that take over device updates for original device makers that no longer wish to handle software update?
- 法的、倫理的、ビジネス関連の質問はたくさんありますが、技術的にデバイスサービスを別のプロバイダーに移すことはできますか？ソフトウェアの更新を処理する必要がなくなった元のデバイスメーカーのデバイスの更新を引き継ぐエンティティのビジネスモデルもあるのでしょうか。
- The release of code, as it was done with the Little Printer manufactured and developed by a company called "Berg" [LittlePrinter], could provide a useful example. While the community took over the support in that case, this can hardly be assumed in all cases. Just releasing the source code for a device will not necessarily motivate others to work on the code, to fix bugs, or to maintain a service. Nevertheless, escrowing code so that the community can take it over if a company fails is one possible option.
- "Berg" [LittlePrinter]と呼ばれる会社によって製造および開発されたLittle Printerで行われたコードのリリースは、有用な例を提供することができます。その場合、コミュニティがサポートを引き継ぎましたが、すべてのケースでこれが想定されることはほとんどありません。デバイスのソースコードをリリースするだけでは、他の人がコードに取り組んだり、バグを修正したり、サービスを維持したりする必要はありません。それにもかかわらず、会社が失敗した場合にコミュニティがコードを引き継ぐことができるようにコードをエスクローすることは、1つの可能なオプションです。
- The situation gets more complex when the device has security mechanisms to ensure that only selected parties are allowed to update the device (which is really a basic requirement for any secure software update). In this case, private signing keys (or similar) may need to be made available as well, which could introduce security problems for already-deployed software. In the best case, it changes assumptions made about the trust model and about who can submit updates.
- 選択した関係者だけがデバイスを更新できるようにするセキュリティメカニズムがデバイスにある場合、状況はより複雑になります（これは、すべての安全なソフトウェア更新の基本的な要件です）。この場合、秘密の署名キー（または同様のもの）も使用可能にする必要がある場合があり、これにより、すでに展開されているソフトウェアにセキュリティ上の問題が発生する可能性があります。最良の場合は、信頼モデルと更新を送信できるユーザーについての仮定を変更します。
- How should deployed devices behave when they are end-of-support and support ends? Many of them may still function normally, but others may fail due to the absence of cloud infrastructure services. Some products are probably expected to fail safely, similarly to a smoke alarm that makes a loud noise when the battery becomes empty. Cell phones without a contract can, in some countries, still be used for emergency services (although at the expense of society due to untraceable hoax calls), as discussed in RFC 7406 [RFC7406].
- 展開されたデバイスがサポート終了およびサポート終了の場合、どのように動作する必要がありますか？それらの多くは引き続き正常に機能しますが、クラウドインフラストラクチャサービスがないために失敗するものもあります。バッテリーが空になると大きな音を出す煙警報器と同様に、一部の製品はおそらく安全に故障することが予想されます。 RFC 7406 [RFC7406]で説明されているように、契約のない携帯電話は、一部の国では依然として救急サービスに使用できます（追跡不可能なデマコールのために社会を犠牲にします）。
The recommendation that can be provided to device makers and users is to think about the end-of-support and end-of-support scenarios ahead of time and plan for those. While device makers rarely want to consider what happens if their business fails, it is definitely legitimate to consider scenarios where they are hugely successful and want to evolve a product line instead of supporting previously sold products forever. Maybe there is also value in subscription-based models where product and device support is only provided as long as the subscription is paid. Without a subscription, the product is deactivated and cannot pose a threat to the Internet at large.
デバイスメーカーとユーザーに提供できる推奨事項は、サポートの終了シナリオとサポートの終了シナリオを事前に検討し、それらについて計画することです。デバイスメーカーは、ビジネスが失敗した場合にどうなるかを検討することはめったにありませんが、大成功を収め、以前に販売された製品を永久にサポートするのではなく、製品ラインを進化させたいシナリオを検討することは間違いなく正当です。サブスクリプションベースのモデルにも価値があるかもしれません。サブスクリプションが支払われている限り、製品とデバイスのサポートのみが提供されます。サブスクリプションがない場合、製品は非アクティブ化され、インターネット全体に脅威を与えることはできません。
Workshop participants also discussed how to create incentives for companies to ship software updates, which is particularly important for products that will be deployed in the market for a long time. It is also further complicated by complex value chains.
ワークショップの参加者は、企業がソフトウェア更新を出荷するためのインセンティブを作成する方法についても議論しました。これは、長期間市場に展開される製品にとって特に重要です。また、複雑なバリューチェーンによってさらに複雑になります。
- Companies shipping software updates benefit from improved security. Their devices are less likely to be abused as a vector to launch other attacks, whether on their own networks or (as part of a botnet) on other Internet hosts. This clearly creates an incentive to support and use software updates.
- ソフトウェアアップデートを出荷する企業は、セキュリティの向上から恩恵を受けています。彼らのデバイスは、自分のネットワーク上であれ、（ボットネットの一部として）他のインターネットホスト上であれ、他の攻撃を仕掛けるベクトルとして悪用される可能性は低いです。これにより、ソフトウェアアップデートをサポートおよび使用するインセンティブが明らかに生まれます。
- On the other hand, updates can also break things. The negative customer experience can be due to service interruptions during or after the update process but can also result from bad experience from deliberate changes introduced as part of an update -- such as a feature that is not available anymore, or a "bug" that another service has relied upon being fixed.
- 一方で、更新によっても問題が発生する可能性があります。マイナスのカスタマーエクスペリエンスは、更新プロセス中またはその後のサービスの中断が原因である可能性がありますが、更新の一部として導入された意図的な変更による悪質なエクスペリエンスから発生する場合もあります。たとえば、利用できなくなった機能や「バグ」などです。別のサービスは修正に依存しています。
- For most classes of device, there does not seem to be a regulatory requirement to report or fix vulnerabilities, similar to data-breach-notification laws.
- ほとんどの種類のデバイスでは、データ侵害通知法と同様に、脆弱性を報告または修正するための規制要件はないようです。
- Subscription models for device management were suggested so that companies providing the service have an economic interest in keeping devices online (and updated for that).
- デバイス管理のサブスクリプションモデルが提案されたため、サービスを提供する企業は、デバイスをオンラインに維持する（そしてそのために更新される）ことに経済的利益をもたらします。
From a security point of view, it is important to know what devices are out there and what version of software they run. One workshop paper [PLONKA] reported measurements that were initially done on buggy devices first distributed in 2003, and that were still detectable in significant numbers just before the workshop 13 years later. As such, in addition to the firmware update mechanism, companies have been offering device management solutions that allow OEMs to keep track of their devices. Tracking these devices and their status is still challenging since some devices are only connected irregularly or are only turned on when needed (such as a hockey alarm that is only turned on before a match).
セキュリティの観点から、そこにどのデバイスがあり、それらが実行するソフトウェアのバージョンを知ることが重要です。 1つのワークショップペーパー[PLONKA]は、2003年に最初に配布されたバグのあるデバイスで最初に行われ、13年後のワークショップの直前にまだかなりの数が検出された測定を報告しました。そのため、ファームウェア更新メカニズムに加えて、企業はOEMがデバイスを追跡できるようにするデバイス管理ソリューションを提供しています。一部のデバイスは不規則にしか接続されていないか、必要なときにのみオンになるため、これらのデバイスとそのステータスの追跡は依然として困難です（試合前にのみオンになるホッケーアラームなど）。
Various stakeholders have a justified interest in knowing something about deployed devices. For example:
さまざまな関係者が、配備されたデバイスについて何かを知ることに正当な関心を持っています。例えば：
- Manufacturers and other players in the supply chain are interested to know what devices are out there, how many have been sold, and what devices are out there but have not been sold. This could help to understand which firmware versions to support and for how long.
- メーカーやサプライチェーンの他のプレーヤーは、販売されているデバイス、販売されているデバイスの数、販売されていないが販売されていないデバイスを知りたいと考えています。これは、サポートするファームウェアバージョンとその期間を理解するのに役立ちます。
- Device users, owners, and customers like these may want to know what devices are installed over a longer period of time, what software/firmware version is the device running, what is the uptime of each of these devices, what types of faults have occurred, etc. Forgotten devices may pose problems, particularly if they (have the potential to) behave badly.
- このようなデバイスユーザー、所有者、および顧客は、長期間にわたってインストールされているデバイス、デバイスで実行されているソフトウェア/ファームウェアのバージョン、これらの各デバイスの稼働時間、発生した障害の種類を知りたい場合があります。 、など。忘れられたデバイスは、特にそれらが（潜在的に）正しく動作しない場合、問題を引き起こす可能性があります。
- To an extent, network operators offering services to device owners and other actors may also need similar information, for example, to control botnets.
- ある程度まで、デバイスの所有者や他のアクターにサービスを提供するネットワークオペレーターも、たとえばボットネットを制御するために同様の情報を必要とする場合があります。
- Researchers doing analysis on the state of the Internet ecosystem (such as what protocols are being used, how much data IoT devices generate, etc.,) need measurements for their work.
- インターネットエコシステムの状態（使用されているプロトコル、IoTデバイスが生成するデータの量など）を分析する研究者は、作業に測定が必要です。
There can easily be some invasiveness in approaches to acquiring such measurements. The challenge was put forward to find ways to create measurement infrastructures that are privacy preserving. Arnar Birgisson noted that there are privacy-preserving statistical techniques, such as RAPPOR [RAPPOR], and Ned Smith added that techniques like Intel's Enhanced Privacy ID (EPID) may play a role in maintaining some level of anonymity for the IoT device (owners) while also enabling measurement. It seemed clear that naive approaches to measurement (e.g., where devices are willing to expose a unique identifier to anyone on request) are unlikely to prove sufficient.
そのような測定値を取得するためのアプローチには、ある程度の侵襲性がある可能性があります。プライバシーを保護する測定インフラストラクチャを作成する方法を見つけるという課題が提起されました。 Arnar Birgissonは、RAPPOR [RAPPOR]などのプライバシーを保護する統計手法があることを指摘し、Ned Smithは、IntelのEnhanced Privacy ID（EPID）などの手法がIoTデバイス（所有者）の匿名性の維持に役割を果たす可能性があると付け加えましたまた、測定も可能にします。測定への素朴なアプローチ（たとえば、要求に応じてデバイスが一意の識別子をだれにでも公開する用意がある場合）が十分であるとは考えにくいことは明らかでした。
There was some discussion of the requirements for mesh-based networks, mainly relating to industrial lighting. In these networks, software update can impose unacceptable performance burdens, especially if there are many devices, some of which may be sleepy.
主に産業用照明に関連するメッシュベースのネットワークの要件についていくつかの議論がありました。これらのネットワークでは、ソフトウェアの更新が許容できないパフォーマンスの負荷を課す可能性があり、特に多くのデバイスがあり、その一部はスリープ状態になっている場合があります。
The workshop discussed whether some forms of multicast (perhaps not IP multicast) would be needed to provide acceptable solutions for software update in such cases. It was not clear at which layer a multicast solution might be effective in such cases, though there did not seem to be any clearly applicable standards-based approach that was available at the time of the workshop.
ワークショップでは、このような場合のソフトウェアアップデートに受け入れ可能なソリューションを提供するために、何らかの形式のマルチキャスト（おそらくIPマルチキャストではない）が必要かどうかについて議論しました。ワークショップの時点で利用可能な明確に適用可能な標準ベースのアプローチはないようでしたが、マルチキャストソリューションがそのような場合にどのレイヤーで効果的であるかは明確ではありませんでした。
There was recognition that there are, and perhaps always will be, large numbers of devices that can be, or have been, compromised. While updating these can mitigate problems, there will always be new devices added to networks that cannot be updated (for various reasons); so the question of what, if anything, to do about compromised devices was discussed.
侵害される可能性のある、または侵害された多数のデバイスが存在すること、そしておそらく今後も存在するであろうという認識がありました。これらを更新すると問題を軽減できますが、更新できない新しいデバイスが常にネットワークに追加されます（さまざまな理由により）。そこで、侵害されたデバイスに対して何をすべきか、もしあれば何をすべきかという問題が議論されました。
- There may be value if it were possible to single out a device that shows faulty behavior or has been compromised, and to shut it down in some sense.
- 欠陥のある動作を示したり、危険にさらされているデバイスを特定し、何らかの意味でそれをシャットダウンすることが可能であった場合、価値があるかもしれません。
- Prior work in the IETF on Network Endpoint Assessment (NEA) [NEA] allowed assessing the "posture" of devices. Posture refers to the hardware or software configuration of a device and may include knowledge that the software installed is up to date. The obtained information can then be used by some network infrastructure to create a quarantined region network around the device.
- ネットワークエンドポイントアセスメント（NEA）[NEA]に関するIETFでの以前の作業では、デバイスの「姿勢」を評価することができました。ポスチャとは、デバイスのハードウェアまたはソフトウェアの設定を指し、インストールされているソフトウェアが最新であることを含む場合があります。取得した情報は、ネットワークインフラストラクチャによって使用され、デバイスの周囲に隔離領域ネットワークを作成できます。
- RFC 6561 [RFC6561] describes one scheme for an ISP to send "signals" to customers about hosts (usually those that are part of a botnet or generating spam) in their home network.
- RFC 6561 [RFC6561]は、ISPがホームネットワーク内のホスト（通常はボットネットの一部であるか、スパムを生成しているホスト）に関する「信号」を顧客に送信するための1つのスキームについて説明しています。
- Neither RFC 6561 nor NEA has found widespread deployment. Whether such mechanisms can be more successful in the IoT environment has yet to be studied.
- RFC 6561もNEAも広範囲に及ぶ展開を発見していません。そのようなメカニズムがIoT環境でより成功できるかどうかはまだ研究されていません。
The conclusion of the discussion at the workshop itself was that there is some interest in identifying and stopping misbehaving devices, but the actual solution mechanisms are unclear.
ワークショップ自体での議論の結論は、誤動作しているデバイスを特定して停止することに関心があるということでしたが、実際の解決メカニズムは不明です。
There were a number of points discussed at the workshop that don't neatly fit under the above headings but that are worth recording. Those include:
ワークショップでは、上記の見出しにはきちんと収まらないが、記録する価値のあるいくつかのポイントが議論されました。それらは以下を含みます：
- Complex questions can arise when considering the impact of the lack of updates on other devices, other persons, or the public in general. If I don't update my device, and it is used to attack a random host on the Internet, but at no apparent cost to me, then what incentive do I have to do updates that would have protected that random host? What incentive has my device's vendor to have provided those updates in advance? An example of such a case can be found in DDoS attacks from IoT devices, such as printers [SNMP-DDOS] and cameras [DDOS-KREBS].
- 他のデバイス、他の人、または一般の人々に対する更新の欠如の影響を考慮すると、複雑な質問が発生する可能性があります。デバイスを更新せず、それがインターネット上のランダムなホストを攻撃するために使用されているが、明らかなコストがかからない場合、そのランダムなホストを保護する更新を実行する必要があるのはどのようなインセンティブですか？デバイスのベンダーは、これらのアップデートを事前に提供してくれましたか？このようなケースの例は、プリンター[SNMP-DDOS]やカメラ[DDOS-KREBS]などのIoTデバイスからのDDoS攻撃にあります。
- With some IoT devices, there are many stakeholders contributing to the end product (e.g., contributing different subsystems). Ensuring that vulnerabilities are fixed and software/firmware updates are communicated through the value chain is known to be difficult, as demonstrated in [OS14].
- 一部のIoTデバイスでは、最終製品に貢献している（たとえば、さまざまなサブシステムに貢献している）多くの利害関係者がいます。 [OS14]に示されているように、脆弱性が修正され、ソフトウェア/ファームウェアの更新がバリューチェーンを通じて伝達されることを保証することは困難であることがわかっています。
- What about forgotten devices? There are many such, and there will be more. Even though they are forgotten, such devices may be useless consumers of electricity, or they may be part of some critical system.
- 忘れられたデバイスはどうですか？そのようなものがたくさんあり、もっとあります。それらが忘れられていても、そのようなデバイスは電力の無駄な消費者であるか、またはいくつかの重要なシステムの一部である可能性があります。
- Can we determine whether an update impacts other devices in the Internet? Updates to one device can have unintended impact on other devices that depend on it. This can have cascading effects if we are not careful. Changing the format of the output of a sensor could have cascading impacts, e.g., if some actuator reacts to the presence/absence of that sensor's data.
- 更新がインターネット内の他のデバイスに影響を与えるかどうかを判断できますか？ 1つのデバイスへの更新は、そのデバイスに依存する他のデバイスに意図しない影響を与える可能性があります。注意しないと、カスケード効果が生じる可能性があります。センサーの出力の形式を変更すると、たとえば、センサーのデータの有無に反応するアクチュエーターがある場合など、連鎖的に影響を与える可能性があります。
- How should a device behave when it is running out-of-date software? The example of a smoke alarm was mentioned. We don't want 100 devices in a living room to start beeping when their batteries run low or when they cannot communicate with the cloud. But are devices supposed to simply stop working?
- 古いソフトウェアを実行している場合、デバイスはどのように動作する必要がありますか？煙探知機の例に触れました。電池が消耗したり、クラウドと通信できないときに、リビングルームにある100台のデバイスがビープ音を鳴らしたくない。しかし、デバイスは単に動作を停止するはずですか？
- The IETF has published a specification that uses the Cryptographic Message Syntax (CMS) to protect firmware packages, as described in RFC 4108 [RFC4108], which also contains metadata to describe the firmware image itself. During the workshop, the question was raised whether a solution will, in the future, be needed that is post-quantum secure. A post-quantum cryptosystem is a system that is secure against quantum computers that have more than a trivial number of quantum bits. It is open to conjecture whether it is feasible to build such a machine, but current signature algorithms are known not to be post-quantum secure. This would require introducing technologies like the Hash-based Merkle Tree Signature (MTS) [HOUSLEY], which was presented and discussed at the workshop. The downsides of such solutions are their novelty and, for these use cases, the fairly large signature or key sizes involved; e.g., depending on the parameters, a signature could easily have a size of 5-10 KiB [HASHSIG] [XMSS]. While it is likely that post-quantum secure signature algorithms will be needed for software updates at some point in time, it may be the case that such algorithms will be needed sooner for services requiring long-term confidentiality, (e.g., using Transport Layer Security (TLS)), so it was not clear that this application would be a first-mover in terms of post-quantum security.
- IETFは、RFC 4108 [RFC4108]で説明されているように、暗号化メッセージ構文（CMS）を使用してファームウェアパッケージを保護する仕様を公開しています。これには、ファームウェアイメージ自体を説明するメタデータも含まれています。ワークショップ中に、量子化後の安全なソリューションが将来必要になるかどうかという問題が提起されました。ポスト量子暗号システムは、量子ビットの数がごくわずかな量子コンピュータに対して安全なシステムです。そのようなマシンを構築することが可能であるかどうかを推測することは可能ですが、現在の署名アルゴリズムはポスト量子安全ではないことが知られています。これには、ワークショップで発表され、議論されたハッシュベースのマークルツリー署名（MTS）[HOUSLEY]などの技術を導入する必要があります。このようなソリューションの欠点は、その新規性と、これらのユースケースの場合、かなり大きな署名またはキーサイズが関係することです。たとえば、パラメータによっては、シグネチャのサイズが5〜10 KiB [HASHSIG] [XMSS]になる可能性があります。ある時点でのソフトウェア更新には、量子後の安全な署名アルゴリズムが必要になる可能性がありますが、長期的な機密性を必要とするサービス（トランスポート層セキュリティの使用など）には、そのようなアルゴリズムがより早く必要になる場合があります。 （TLS））、したがって、このアプリケーションがポストクォンタムセキュリティの点で先駆者になることは明らかではありませんでした。
- Many devices that use certificates do not check the revocation status of certificates, even though extensions like Online Certificate Status Protocol (OCSP) stapling exists [RFC6961] and is increasingly deployed with Web browsers. The workshop participants did not reach a conclusion regarding the recommendations of certificate revocation checking, although the importance has been recognized. The reluctance regarding deploying certificate revocation deserves further investigation.
- 証明書を使用する多くのデバイスは、オンライン証明書ステータスプロトコル（OCSP）ステープリングなどの拡張機能が存在し[RFC6961]、Webブラウザーでますます展開されているにもかかわらず、証明書の失効ステータスをチェックしません。ワークショップの参加者は、証明書の失効チェックの推奨事項に関する結論に達しませんでしたが、重要性は認識されています。証明書失効の展開に関する不本意は、さらに調査する価値があります。
The workshop participants discussed some tentative conclusions and possible next steps:
ワークショップの参加者は、いくつかの暫定的な結論と考えられる次のステップについて議論しました。
- There was strong agreement that having some standardized secure (authorized and authenticated) software update would be an improvement over having none.
- いくつかの標準化された安全な（承認および認証された）ソフトウェア更新を使用すると、何もない場合よりも改善されるという強い合意がありました。
- It would be valuable to find agreement on the right scope for a standardized software/firmware update mechanism. It is not clear that an entire update system can or should be standardized, but there may be some aspects of such solutions where standards would be beneficial, e.g., (meta-)data formats and/or protocols for distributing firmware updates. More discussion is needed to identify which parts of the problem space could benefit from standardization.
- 標準化されたソフトウェア/ファームウェア更新メカニズムの適切な範囲について合意を見つけることは価値があります。更新システム全体を標準化できるか、または標準化する必要があるかは明らかではありませんが、ファームウェアの更新を配布するための（メタ）データ形式やプロトコルなど、標準が有益であるようなソリューションにはいくつかの側面があるかもしれません。問題空間のどの部分が標準化の恩恵を受けることができるかを特定するには、さらに議論が必要です。
- It will be useful to investigate solutions to install updates with no operational interruption as well as ways to distribute software updates without disrupting network operations (specifically, in low-power wireless networks), including the development of a multicast transfer mechanism (with appropriate security).
- 運用を中断することなく更新をインストールするソリューションと、（適切なセキュリティを備えた）マルチキャスト転送メカニズムの開発を含む、ネットワーク運用（特に、低電力無線ネットワーク）を中断せずにソフトウェア更新を配布する方法を調査することは有用です。 。
- There will almost certainly be a need for a way to transfer authority/responsibility for updates, particularly considering end-of-support cases. This is very close to calling for a standard way to "root" devices as a feature of all devices.
- 特にサポート終了のケースを考えると、更新の権限/責任を委譲する方法がほぼ確実に必要になります。これは、すべてのデバイスの機能として、デバイスを「ルート化」する標準的な方法を求めることと非常に似ています。
- We would benefit from documentation of proofs-of-concept of software/firmware updates for constrained devices on different operating system architectures. The IETF Light-Weight Implementation Guidance (lwig) Working Group may be a good venue for such documents.
- さまざまなオペレーティングシステムアーキテクチャ上の制約されたデバイスに対するソフトウェア/ファームウェアの更新の概念実証の文書化は有益です。 IETF軽量実装ガイダンス（lwig）ワーキンググループは、このようなドキュメントの良い場になるかもしれません。
This document summarizes an IAB workshop on software/firmware updates and the entire content is, therefore, security related. Standardizing and deploying a software/firmware update mechanism for use with IoT devices could help fix security vulnerabilities faster and, in some cases, be the only via to get vulnerability patched at all.
このドキュメントは、ソフトウェア/ファームウェアの更新に関するIABワークショップをまとめたものであり、そのためコンテンツ全体はセキュリティに関連しています。 IoTデバイスで使用するためのソフトウェア/ファームウェア更新メカニズムを標準化して展開すると、セキュリティの脆弱性をより迅速に修正でき、場合によっては、脆弱性にパッチを適用する唯一の手段となります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[BB14] Barrett, B., "Winks Outage Shows Us How Frustrating Smart Homes Could Be", April 2014, <http://www.wired.com/2015/04/smart-home-headaches/>.
[BB14]バレット、B。、「ウィンクの停止は私たちにいらいらするスマートホームがいかにあり得るかを私たちに示します」、2014年4月、<http://www.wired.com/2015/04/smart-home-headaches/>。
[BS14] Schneier, B., "The Internet of Things Is Wildly Insecure -- And Often Unpatchable", January 2014, <https://www.schneier.com/essays/archives/2014/01/ the_internet_of_thin.html>.
[BS14]シュナイアーB.、「モノのインターネットは非常に安全ではなく、パッチを適用できないことが多い」、2014年1月、<https://www.schneier.com/essays/archives/2014/01/ the_internet_of_thin.html>。
[BSDIFF] Percival, C., "Matching with Mismatches and Assorted Applications", September 2016, <https://ora.ox.ac.uk/objects/ uuid:4f0d53cc-fb9f-4246-a835-3c8734eba735/datastreams/ THESIS01>.
[BSDIFF]パーシバル、C。、「不一致と各種アプリケーションとのマッチング」、2016年9月、<https://ora.ox.ac.uk/objects/ uuid：4f0d53cc-fb9f-4246-a835-3c8734eba735 / datastreams / THESIS01 >。
[COURGETTE] Google, "Software Updates: Courgette", September 2016, <https://www.chromium.org/developers/design-documents/ software-updates-courgette>.
[COURGETTE] Google、「ソフトウェアアップデート：ズッキーニ」、2016年9月、<https://www.chromium.org/developers/design-documents/ software-updates-courgette>。
[DDOS-KREBS] Goodin, D., "Record-breaking DDoS reportedly delivered by >145k hacked cameras", September 2016, <http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[DDOS-KREBS] Goodin、D。、「報告によると> 145kのハッキングされたカメラによって記録を破ったDDoS」、2016年9月、<http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-伝えられるところによれば、-deliver-internets-biggest-ddos-ever />。
[EYEFI] Aldred, J., "Eye-Fi to Drop Suport for Some Cards. They Will 'Magically' Stop Working on September 16, 2016", June 2016, <http://www.diyphotography.net/eyefi-drop-support-cards-will-magically-stop-working-september-16-2016/>.
[EYEFI] Aldred、J。、「Eye-Fiは一部のカードのサポートを中止します。彼らは2016年9月16日に「魔法のように」機能しなくなります」、2016年6月、<http://www.diyphotography.net/eyefi-drop -support-cards-will-magically-stop-working-september-16-2016 />。
[FTC] Federal Trade Commission, "FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks", January 2015, <https://www.ftc.gov/system/files/documents/reports/ federal-trade-commission-staff-report-november-2013- workshop-entitled-internet-things-privacy/150127iotrpt.pdf>.
[FTC]連邦取引委員会、「モノのインターネットに関するFTCレポートは企業に消費者のプライバシーとセキュリティのリスクに対処するためのベストプラクティスの採用を促す」、2015年1月、<https://www.ftc.gov/system/files/documents/reports / federal-trade-commission-staff-report-november-2013- Workshop-entitled-internet-things-privacy / 150127iotrpt.pdf>。
[HASHSIG] Langley, A., "Hash based signatures", July 2013, <https://www.imperialviolet.org/2013/07/18/hashsig.html>.
[HASHSIG] Langley、A。、「ハッシュベースの署名」、2013年7月、<https://www.imperialviolet.org/2013/07/18/hashsig.html>。
[HOUSLEY] Housley, R., "Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, draft-housley-cms-mts-hash-sig-07, June 2017.
[HOUSLEY] Housley、R。、「暗号化メッセージ構文（CMS）でのハッシュベースのマークルツリー署名（MTS）アルゴリズムの使用」、作業中、draft-housley-cms-mts-hash-sig-07、 2017年6月。
[HP-Firmware] BoingBoing, "HP detonates its timebomb: printers stop accepting third party ink en masse", September 2016, <http://boingboing.net/2016/09/19/ hp-detonates-its-timebomb-pri.html>.
[HPファームウェア] BoingBoing、「HPが時限爆弾を爆発させる：プリンターがサードパーティのインクを一斉に受け入れるのを止める」、2016年9月、<http://boingboing.net/2016/09/19/ hp-detonates-its-timebomb-pri .html>。
[IoTSU] IAB, "Internet of Things Software Update Workshop (IoTSU) 2016", June 2016, <https://www.iab.org/activities/workshops/iotsu/>.
[IoTSU] IAB、「Internet of Things Software Update Workshop（IoTSU）2016」、2016年6月、<https://www.iab.org/activities/workshops/iotsu/>。
[LittlePrinter] Berg, "The future of Little Printer", September 2014, <http://littleprinterblog.tumblr.com/post/97047976103/ the-future-of-little-printer>.
[LittlePrinter] Berg、「リトルプリンターの未来」、2014年9月、<http://littleprinterblog.tumblr.com/post/97047976103/ the-future-of-little-printer>。
[NEA] IETF, "Network Endpoint Assessment (nea) Concluded WG", October 2016, <https://datatracker.ietf.org/wg/nea/charter/>.
[NEA] IETF、「Network Endpoint Assessment（nea）Concluded WG」、2016年10月、<https://datatracker.ietf.org/wg/nea/charter/>。
[OS-Support] Dong, W., Chen, C., Liu, X., and J. Bu, "Providing OS Support for Wireless Sensor Networks: Challenges and Approaches", DOI 10.1109/SURV.2010.032610.00045, May 2010, <http://ieeexplore.ieee.org/stamp/ stamp.jsp?arnumber=5462978>.
[OS-Support] Dong、W.、Chen、C.、Liu、X.、and J. Bu、 "Providing OS Support for Wireless Sensor Networks：Challenges and Approaches"、DOI 10.1109 / SURV.2010.032610.00045、May 2010 、<http://ieeexplore.ieee.org/stamp/ stamp.jsp？arnumber = 5462978>。
[OS14] Oppenheim, L. and S. Tal, "Too Many Cooks: Exploiting the Internet of TR-069 Things", December 2014, <http://mis.fortunecook.ie/ too-many-cooks-exploiting-tr069_tal-oppenheim_31c3.pdf>.
[OS14] Oppenheim、L。およびS. Tal、「Too Many Cooks：Exploit the Internet of TR-069 Things」、2014年12月、<http://mis.fortunecook.ie/ too-many-cooks-exploiting-tr069_tal -oppenheim_31c3.pdf>。
[PACMAN] "pacman", 2016, <https://www.archlinux.org/pacman/>.
[パックマン] "pacman"、2016、<https://www.archlinux.org/pacman/>。
[PLONKA] Plonka, D. and E. Boschi, "The Internet of Things Old and Unmanaged", June 2016, <https://down.dsg.cs.tcd.ie/iotsu/subs/ IoTSU_2016_paper_25.pdf>.
[PLONKA]プロンカ、D。、およびE.ボスキ、「古いものと管理されていないもののインターネット」、2016年6月、<https://down.dsg.cs.tcd.ie/iotsu/subs/ IoTSU_2016_paper_25.pdf>。
[RAPPOR] Erlingsson, U., Pihur, V., and A. Korolova, "RAPPOR", DOI 10.1145/2660267.2660348, July 2014, <http://dl.acm.org/citation.cfm?doid=2660267.2660348>.
[RAPPOR]アーリンソン、U、ピハー、V、およびA.コロロバ、「RAPPOR」、DOI 10.1145 / 2660267.2660348、2014年7月、<http://dl.acm.org/citation.cfm?doid=2660267.2660348>。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.
[RFC4108] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、DOI 10.17487 / RFC4108、2005年8月、<https://www.rfc-editor.org/info/rfc4108> 。
[RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, "Recommendations for the Remediation of Bots in ISP Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, <https://www.rfc-editor.org/info/rfc6561>.
[RFC6561] Livingood、J.、Mody、N。、およびM. O'Reirdan、「ISPネットワークにおけるボットの修復に関する推奨事項」、RFC 6561、DOI 10.17487 / RFC6561、2012年3月、<https：// www。 rfc-editor.org/info/rfc6561>。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961] Pettersen、Y。、「The Transport Layer Security（TLS）Multiple Certificate Status Request Extension」、RFC 6961、DOI 10.17487 / RFC6961、2013年6月、<https://www.rfc-editor.org/info/rfc6961 >。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., and D. Kroeselberg, "Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, December 2014, <https://www.rfc-editor.org/info/rfc7406>.
[RFC7406] Schulzrinne、H.、McCann、S.、Bajko、G.、Tschofenig、H.、およびD. Kroeselberg、「Extensions to the Emergency Services Architecture to扱いwith Unauthenticated and Unauthorized Devices」、RFC 7406、DOI 10.17487 / RFC7406、2014年12月、<https://www.rfc-editor.org/info/rfc7406>。
[RPM] "Red Hat Package Manager (RPM)", 2016, <http://rpm.org/>.
[RPM]「Red Hat Package Manager（RPM）」、2016、<http://rpm.org/>。
[RT] Google, "Roughtime", September 2016, <https://roughtime.googlesource.com/roughtime>.
[RT] Google、「Roughtime」、2016年9月、<https://roughtime.googlesource.com/roughtime>。
[SNMP-DDOS] BITAG, "SNMP Reflected Amplification DDoS Attack Mitigation", August 2012, <https://www.bitag.org/documents/ SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf>.
[SNMP-DDOS] BITAG、「SNMP Reflected Amplification DDoS Attack Mitigation」、2012年8月、<https://www.bitag.org/documents/ SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf>。
[WP29] Article 29 Data Protection Working Party, "Opinion 8/2014 on the on Recent Developments on the Internet of Things", 14/EN, WP 223, September 2014, <http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/ wp223_en.pdf>.
[WP29]第29条データ保護作業部会、「モノのインターネットに関する最近の進展に関する意見8/2014」、14 / EN、WP 223、2014年9月、<http://ec.europa.eu/justice/ data-protection / article-29 / documentation / opinion-recommendation / files / 2014 / wp223_en.pdf>。
[XMSS] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. Mohaisen, "XMSS: Extended Hash-Based Signatures", Work in Progress, draft-irtf-cfrg-xmss-hash-based-signatures-10, July 2017.
[XMSS] Huelsing、A.、Butin、D.、Gazdag、S.、Rijneveld、J。、およびA. Mohaisen、「XMSS：Extended Hash-Based Signatures」、作業中、draft-irtf-cfrg-xmss- hash-based-signatures-10、2017年7月。
The following individuals helped to organize the workshop: Jari Arkko, Arnar Birgisson, Carsten Bormann, Stephen Farrell, Russ Housley, Ned Smith, Robert Sparks, and Hannes Tschofenig.
次の個人がワークショップの開催を支援しました：Jari Arkko、Arnar Birgisson、Carsten Bormann、Stephen Farrell、Russ Housley、Ned Smith、Robert Sparks、およびHannes Tschofenig。
The list of accepted position papers is below. Links to these, and to the workshop agenda and raw minutes are accessible at: <https://down.dsg.cs.tcd.ie/iotsu/>.
採用されたポジションペーパーのリストは以下のとおりです。これら、およびワークショップの議題と議事録へのリンクは、<https://down.dsg.cs.tcd.ie/iotsu/>からアクセスできます。
- R. Housley, "Position Paper for Internet of Things Software Update Workshop (IoTSU)"
- R. Housley、「モノのインターネットソフトウェアアップデートワークショップ（IoTSU）に関するポジションペーパー」
- D. Thomas and A. Beresford, "Incentivising software updates"
- D.トーマスとA.ベレスフォード、「ソフトウェアアップデートの奨励」
- L. Zappaterra and E. Dijk, "Software Updates for Wireless Connected Lighting Systems: requirements, challenges and recommendations"
- L. ZappaterraおよびE. Dijk、「ワイヤレス接続照明システムのソフトウェアアップデート：要件、課題、推奨事項」
- M. Orehek and A. Zugenmaier, "Updates in IoT are more than just one iota"
- M. OrehekおよびA. Zugenmaier、「IoTの更新は単なる1つのイオタではありません」
- D. Plonka and E. Boschi, "The Internet of Things Old and Unmanaged"
- D.プロンカとE.ボスキ、「古いものと管理されていないもののインターネット」
- D. Bosschaert, "Using OSGi for an extensible, updatable and future proof IoT"
- D. Bosschaert、「拡張性があり、更新可能で将来を見据えたIoTのためのOSGiの使用」
- A. Padilla, E. Baccelli, T. Eichinger, and K. Schleiser, "The Future of IoT Software Must be Updated"
- A. Padilla、E。Baccelli、T。Eichinger、およびK. Schleiser、「IoTソフトウェアの未来を更新する必要がある」
- T. Hardie, "Software Update in a multi-system Internet of Things"
- T. Hardie、「マルチシステムのモノのインターネットにおけるソフトウェアアップデート」
- R. Sparks and B. Campbell, "Avoiding the Obsolete-Thing Event Horizon"
- R.スパークスとB.キャンベル、「時代遅れのイベントの地平線を避ける」
- J. Karkov, "SW update for Long lived products"
- J.カルコフ、「長寿命製品のソフトウェアアップデート」
- S. Farrell, "Some Software Update Requirements"
- S. Farrell、「一部のソフトウェアアップデート要件」
- S. Chakrabarti, "Internet Of Things Software Update Challenges: Ownership, Software Security & Services"
- S.チャクラバルティ、「モノのインターネットのソフトウェア更新の課題：所有権、ソフトウェアのセキュリティとサービス」
- M. Kovatsch, A. Scholz, and J. Hund, "Why Software Updates Are More Than a Security Issue: Challenges for IETF CoRE and the W3C Web of Things"
- M. Kovatsch、A。Scholz、およびJ. Hund、「ソフトウェアの更新がセキュリティの問題以上の理由：IETF CoREとW3C Web of Thingsの課題」
- A. Grau, "Secure Software Updates for IoT Devices"
- A. Grau、「IoTデバイス用の安全なソフトウェアアップデート」
- Birr-Pixton, "Electric Imp's experiences of upgrading half a million embedded devices"
- Birr-Pixton、「Electric Impの50万台の組み込みデバイスのアップグレード経験」
- Y. Zhang, J. Yin, C. Groves, and M. Patel, "oneM2M device management and software/firmware update"
- Y. Zhang、J。Yin、C。Groves、およびM. Patel、「oneM2Mデバイス管理およびソフトウェア/ファームウェアの更新」
- E. Smith, M. Stitt, R. Ensink, and K. Jager, "User Experience (UX) Centric IoT Software Update"
- E.スミス、M。スティット、R。エンシンク、およびK.イェーガー、「ユーザーエクスペリエンス（UX）Centric IoT Software Update」
- J.-P. Fassino, E.A. Moktad, and J.-M. Brun, "Secure Firmware Update in Schneider Electric IOT-enabled offers"
- J.-P. Fassino、EA Moktad、およびJ.-M. Brun、「Schneider Electric IOT対応のオファーでのセキュアなファームウェアアップデート」
- M. Orehek, "Summary of existing firmware update strategies for deeply embedded systems"
- M. Orehek、「ディープエンベデッドシステム向けの既存のファームウェアアップデート戦略の概要」
- N. Smith, "Toward A Common Modeling Standard for Software Update and IoT Objects"
- N.スミス、「ソフトウェアアップデートとIoTオブジェクトの共通モデリング標準に向けて」
- S. Schmidt, M. Tausig, M. Hudler, and G. Simhandl, "Secure Firmware Update Over the Air in the Internet of Things Focusing on Flexibility and Feasibility"
- S. Schmidt、M。Tausig、M。Hudler、およびG. Simhandl、「柔軟性と実現可能性に重点を置いたモノのインターネットにおける無線による安全なファームウェアアップデート」
- A. Adomnicai, J. Fournier, L. Masson, and A. Tria, "How careful should we be when implementing cryptography for software update mechanisms in the IoT?"
- A. Adomnicai、J。Fournier、L。Masson、およびA. Triaは、「IoTでソフトウェア更新メカニズムの暗号化を実装する場合、どの程度注意する必要がありますか？」
- V. Prevelakis and H. Hamad, "Controlling Change via Policy Contracts"
- V. PrevelakisおよびH. Hamad、「ポリシーコントラクトによる変更の制御」
- H. Birkholz, N. Cam-Winget, and C. Bormann, "IoT Software Updates need Security Automation"
- H. Birkholz、N。Cam-Winget、およびC. Bormann、「IoTソフトウェアの更新にはセキュリティの自動化が必要」
- R. Bisewski, "Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that Constitute the Internet of Things"
- R. Bisewski、「分散リポジトリの更新方法の比較分析と、CoAPのような更新方法により、モノのインターネットを構成するデバイスのインターネット負荷を軽減する方法」
- J. Arrko, "Architectural Considerations with Smart Objects and Software Updates"
- J. Arrko、「スマートオブジェクトとソフトウェアの更新に関するアーキテクチャの考慮事項」
- J. Jimenez and M. Ocak, "Software Update Experiences for IoT"
- J. JimenezとM. Ocak、「IoTのソフトウェアアップデートエクスペリエンス」
- H. Tschofenig, "Software and Firmware Updates with the OMA LWM2M Protocol"
- H. Tschofenig、「OMA LWM2Mプロトコルによるソフトウェアとファームウェアのアップデート」
- Arnar Birgisson, Google
- Arnar Birgisson、Google
- Alan Grau, IconLabs
- アラン・グラウ、IconLabs
- Alexandre Adomnicai, Trusted Objects
- Alexandre Adomnicai、信頼できるオブジェクト
- Alf Zugenmaier, Munich University of Applied Science
- ミュンヘン応用科学大学、Alf Zugenmaier
- Ben Campbell, Oracle
- ベン・キャンベル、オラクル
- Carsten Bormann, TZI University Bremen
- Carsten Bormann、TZI大学ブレーメン
- Daniel Thomas, University of Cambridge
- ダニエルトーマス、ケンブリッジ大学
- David Bosschaert, Adobe
- アドビ、デビッド・ボスチャート
- David Malone, Maynooth University
- メイヌース大学、デビッドマローン
- David Plonka, Akamai
- アカマイ、David Stuff
- Doug Leith, Trinity College Dublin
- ダグリース、トリニティカレッジダブリン
- Emmanuel Baccelli, Inria
- エマニュエルバチェッリ、インリア
- Eric Smith, SpinDance
- Eric Smith、SpinDance
- Jean-Philippe Fassino, Schneider Electric
- ジャン・フィリップ・ファシーノ、シュナイダーエレクトリック
- Joergen Karkov, Grundfos
- ヨルゲン・カルコフ、グルンドフォス
- Jonathon Dukes, Trinity College Dublin
- Jonathon Dukes、トリニティカレッジダブリン
- Joseph Birr-Pixton, Electric Imp
- ジョセフ・ブル=ピクストン、エレクトリック・インプ
- Kaspar Schleiser, Freie Universitaet Berlin
- Kaspar Schleiser、ベルリン自由大学
- Luca Zappaterra, Philips Lighting Research
- Luca Zappaterra、Philips Lighting Research
- Martin Orehek, Munich University of Applied Science
- Martin Orehek、ミュンヘン応用科学大学
- Mathias Tausig, FH Campus Wien
- Mathias Tausig、FH Campus Vienna
- Matthias Kovatsch, Siemens
- Matthias Kovatsch、シーメンス
- Milan Patel, Huawei
- ファーウェイ、ミラノパテル
- Ned Smith, Intel
- Ned Smith、Intel
- Robert Ensink, SpinDance
- Robert Ensink、SpinDance
- Robert Sparks, Oracle
- Robert Sparks、Oracle
- Russ Housley, Vigil Security
- Russ Housley、Vigil Security
- Samita Chakrabarti, Ericsson
- エリクソン、サミティチャクラバーティ
- Stephen Farrell, Trinity College Dublin
- スティーブンファレル、トリニティカレッジダブリン
- Vassilis Prevelakis, TU Braunschweig
- Vassilis Prevelakis、TUブラウンシュヴァイク
- Hannes Tschofenig, ARM Ltd.
- ARM Ltd. Hannes Tschofenig
Acknowledgements
謝辞
We would like to thank all paper authors and participants for their contributions. The IoTSU workshop is co-sponsored by the Internet Architecture Board and the Science Foundation Ireland funded CONNECT Centre for future networks and communications. The program committee would like to express their thanks to Comcast for sponsoring the social event.
すべての論文執筆者と参加者の貢献に感謝します。 IoTSUワークショップは、インターネットアーキテクチャボードとScience Foundation Irelandが資金を提供するCONNECT Centerが共同主催して、将来のネットワークと通信を支援します。プログラム委員会は、社交イベントを後援してくれたコムキャストに感謝の意を表したい。
Authors' Addresses
著者のアドレス
Hannes Tschofenig ARM Limited
Hannes Tschofenig ARM Limited
Email: hannes.tschofenig@gmx.net
Stephen Farrell Trinity College Dublin Dublin 2 Ireland
スティーブンファレルトリニティカレッジダブリンダブリン2アイルランド
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie