[要約] RFC 7397は、スマートオブジェクトセキュリティワークショップの報告書であり、スマートオブジェクトのセキュリティに関する課題と解決策を提供しています。このRFCの目的は、スマートオブジェクトのセキュリティに関する情報を共有し、セキュリティの向上を促進することです。
Independent Submission J. Gilger
Request for Comments: 7397 H. Tschofenig
Category: Informational December 2014
ISSN: 2070-1721
Report from the Smart Object Security Workshop
スマートオブジェクトセキュリティワークショップからのレポート
Abstract
概要
This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.
このドキュメントは、2012年3月23日にパリで開催された「スマートオブジェクトセキュリティ」に関するワークショップの概要を提供します。ワークショップの主な目的は、参加者が既存の広く展開されているセキュリティメカニズムを活用する能力についての考えを共有できるようにすることでしたスマートオブジェクト用。
This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
このレポートは、議論を要約し、インターネット技術特別調査委員会（IETF）コミュニティへの結論と推奨事項を示しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7397.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7397で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Workshop Structure ..............................................3
3.1. Requirements and Use Cases .................................4
3.2. Implementation Experience ..................................7
3.3. Authorization .............................................10
3.4. Provisioning of Credentials ...............................12
4. Summary ........................................................14
5. Security Considerations ........................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Appendix A. Program Committee .....................................18
Appendix B. Published Workshop Material ...........................18
Appendix C. Accepted Position Papers ..............................18
Appendix D. Workshop Participants .................................21
Acknowledgements ..................................................22
Authors' Addresses ................................................23
In early 2011, the Internet Architecture Board (IAB) solicited position statements for a workshop on 'Interconnecting Smart Objects with the Internet', aiming to get feedback from the wider Internet community on their experience with deploying IETF protocols in constrained environments. The workshop took place in Prague on March 25, 2011. During the workshop, a range of topics were discussed, including architecture, routing, energy efficiency, and security. RFC 6574 [RFC6574] summarizes the discussion and suggests several next steps.
2011年の初めに、インターネットアーキテクチャボード（IAB）は、「スマートオブジェクトとインターネットの相互接続」に関するワークショップに意見表明を募り、制約のある環境でのIETFプロトコルの導入経験に関する幅広いインターネットコミュニティからのフィードバックを得ることを目指しました。ワークショップは、2011年3月25日にプラハで開催されました。ワークショップでは、アーキテクチャ、ルーティング、エネルギー効率、セキュリティなど、さまざまなトピックが議論されました。 RFC 6574 [RFC6574]は議論を要約し、いくつかの次のステップを提案しています。
During the months following the workshop, new IETF initiatives were started, such as the Light-Weight Implementation Guidance (LWIG) working group, and hackathons were organized at IETF 80 and IETF 81 to better facilitate the exchange of ideas.
ワークショップ後の数か月の間に、軽量実装ガイダンス（LWIG）ワーキンググループなどの新しいIETFイニシアチブが開始され、IETF 80とIETF 81でハッカソンが開催され、アイデアの交換がより容易になりました。
Contributions regarding security from the IETF Constrained RESTful Environments (CoRE) working group and the IETF Transport Layer Security (TLS) working group made it clear that further discussions on security were necessary and that those would have to incorporate implementation and deployment experience as well as a shared understanding of how various building blocks fit into a larger architecture.
IETF Constrained RESTful Environments（CoRE）ワーキンググループおよびIETF Transport Layer Security（TLS）ワーキンググループからのセキュリティに関する貢献は、セキュリティに関するさらなる議論が必要であり、実装と展開の経験だけでなく、さまざまなビルディングブロックがより大きなアーキテクチャにどのように適合するかについての共通の理解。
The workshop on 'Smart Object Security' was organized to bring together various disconnected discussions about smart object security happening in different IETF working groups and industry fora. It was a one-day workshop held prior to the IETF 83 in Paris on March 23, 2012.
「スマートオブジェクトセキュリティ」に関するワークショップは、さまざまなIETFワーキンググループや業界のフォーラムで行われているスマートオブジェクトセキュリティに関するさまざまな切り離された議論をまとめるために開催されました。これは、2012年3月23日にパリでIETF 83に先立って開催された1日のワークショップでした。
The workshop organizers were particularly interested in getting input on the following topics, as outlined in the call for position papers:
ワークショップの主催者は、ポジションペーパーの募集で概説されているように、以下のトピックに関する意見を得ることに特に関心がありました。
o What techniques for issuing credentials have been deployed?
o 資格情報を発行するためのどのような技術が導入されていますか？
o What extensions are useful to make existing security protocols more suitable for smart objects?
o 既存のセキュリティプロトコルをスマートオブジェクトにより適したものにするために役立つ拡張機能はどれですか。
o What type of credentials are frequently used?
o どのタイプの資格情報が頻繁に使用されますか？
o What experience has been gained when implementing and deploying application-layer, transport-layer, network-layer, and link-layer security mechanisms (or a mixture of all of them)?
o アプリケーションレイヤー、トランスポートレイヤー、ネットワークレイヤー、およびリンクレイヤーのセキュリティメカニズム（またはそれらすべての組み合わせ）を実装および展開するときに、どのような経験が得られましたか？
o How can "clever" implementations make security protocols a better fit for constrained devices?
o 「巧妙な」実装はどのようにしてセキュリティプロトコルを制約のあるデバイスによりよく適合させることができますか？
o Are there lessons we can learn from existing deployments?
o 既存の展開から学ぶことができる教訓はありますか？
This document lists some of the recurring discussion topics at the workshop. It also offers recommendations from the workshop participants.
このドキュメントは、ワークショップで繰り返されるディスカッショントピックの一部を示しています。また、ワークショップ参加者からの推奨事項も提供します。
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 the views of the authors or the Internet Architecture Board (IAB).
なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者の見解と見解であり、必ずしも著者またはインターネットアーキテクチャボード（IAB）の見解を反映しているわけではありません。
This document uses security terminology from [RFC4949] and terms related to smart objects from [RFC6574].
このドキュメントでは、[RFC4949]のセキュリティ用語と[RFC6574]のスマートオブジェクトに関連する用語を使用しています。
With 35 accepted position papers, there was a wealth of topics to talk about during the one-day workshop. The program committee decided to divide the discussion into four topic areas ("Requirements and Use Cases", "Implementation Experience", "Authorization", and "Providing Credentials"), with two or three invited talks per slot to get a discussion started. This section will summarize the points raised by the invited speakers as well as the essence of the ensuing discussions.
35の受け入れられたポジションペーパーで、1日のワークショップ中に話し合うべきトピックが豊富にありました。プログラム委員会は、ディスカッションを4つのトピック領域（「要件と使用例」、「実装エクスペリエンス」、「承認」、および「資格情報の提供」）に分割することを決定し、スロットごとに2つまたは3つの招待講演を行い、ディスカッションを開始しました。このセクションでは、招待されたスピーカーによって提起されたポイントと、その後のディスカッションの本質を要約します。
To design a security solution, an initial starting point is to understand the communication relationships, the constraints, and the security threats. The typical IETF Security Considerations section describes security threats, security requirements, and security solutions at the level of a single protocol or a single document. To offer a meaningful solution for a smart object deployment, it is, however, necessary to go beyond this limited view to the analysis of the larger ecosystem. The security analysis documented in [RFC3552] and in [RFC4101] still provides valuable guidance.
セキュリティソリューションを設計するための最初の出発点は、通信関係、制約、およびセキュリティの脅威を理解することです。一般的なIETFのセキュリティに関する考慮事項のセクションでは、単一のプロトコルまたは単一のドキュメントのレベルでのセキュリティの脅威、セキュリティ要件、およびセキュリティソリューションについて説明します。ただし、スマートオブジェクトの展開に意味のあるソリューションを提供するには、この限られたビューを超えて、より大きなエコシステムの分析に進む必要があります。 [RFC3552]および[RFC4101]に文書化されているセキュリティ分析は、依然として貴重なガイダンスを提供しています。
Typical questions that arise are:
発生する一般的な質問は次のとおりです。
1. Who are the involved actors?
1. 関係する俳優は誰ですか？
Some usage scenarios look very simple at first but then, after a longer investigation, turn out to be quite complex. The smart meter deployment, for example, certainly belongs to one of the more complex deployments due to the history of the energy sector (see [RFC6272]).
一部の使用シナリオは、最初は非常に単純に見えますが、より長い調査の結果、かなり複雑であることが判明しました。たとえば、スマートメーターの配備は、確かにエネルギーセクターの歴史により、より複雑な配備の1つに属しています（[RFC6272]を参照）。
2. Who provisions credentials?
2. 誰が資格情報をプロビジョニングしますか？
Credentials may, for example, be provisioned by the end user, the hardware manufacturer, an application service provider, or other parties. With security provided at multiple layers, credentials from multiple parties may need to be provisioned.
資格情報は、たとえば、エンドユーザー、ハードウェアの製造元、アプリケーションサービスプロバイダー、または他の関係者によってプロビジョニングされます。セキュリティが複数の層で提供される場合、複数の関係者からの資格情報をプロビジョニングする必要がある場合があります。
3. What constraints are imposed on the design?
3. 設計にはどのような制約が課されていますか？
For example, a constraint can be the need to interwork with existing infrastructure. From an architectural point of view, an important question is whether security is terminated at the border router (or proxy server) at the customer's premise or if end-to-end security to servers in the Internet is required. A more detailed discussion can be found at [SMART-OBJECT].
たとえば、制約は、既存のインフラストラクチャと相互作用する必要がある場合があります。アーキテクチャの観点から、重要な問題は、セキュリティが顧客の構内にある境界ルーター（またはプロキシサーバー）で終端されているかどうか、またはインターネット内のサーバーに対するエンドツーエンドのセキュリティが必要かどうかです。より詳細な議論は[SMART-OBJECT]で見つけることができます。
4. What type of authorization is required by the identified actors?
4. 特定されたアクターにはどのような種類の承認が必要ですか？
This may, for example, be authorization to get access to the network or authorization at the application layer. Authorization decisions may be binary or may consist of complex, role-based access control policies.
これは、たとえば、ネットワークにアクセスするための許可や、アプリケーション層での許可などです。承認の決定は、バイナリの場合もあれば、複雑な役割ベースのアクセス制御ポリシーで構成される場合もあります。
5. What tasks are expected by the customer who deploys the solution?
5. ソリューションを展開する顧客が期待するタスクは何ですか？
An end customer may, for example, be expected to enter short PIN codes to pair devices, need to update the firmware, or need to connect to an appliance via a web browser to make more sophisticated configuration settings. The familiarity of end users with Internet-based devices certainly increases constantly, but user-interface challenges contribute to a large number of security weaknesses of the Internet and therefore have to be taken into account.
エンドカスタマーは、たとえば、デバイスをペアリングするために短いPINコードを入力する、ファームウェアを更新する必要がある、またはより洗練された構成設定を行うためにWebブラウザーを介してアプライアンスに接続する必要がある場合があります。エンドユーザーがインターネットベースのデバイスに慣れ親しんでいることは確かに絶えず高まっていますが、ユーザーインターフェイスの問題はインターネットのセキュリティ上の多くの弱点の原因となっているため、考慮する必要があります。
To illustrate the differences, consider a mass-market deployment for end customers in comparison to a deployment that is targeting enterprise customers. In the latter case, enterprise system administrators are likely to utilize different management systems to provision security and other system-relevant parameters.
違いを説明するために、企業顧客を対象とした導入と比較して、エンド顧客向けの大規模市場導入を検討してください。後者の場合、エンタープライズシステム管理者は、さまざまな管理システムを利用して、セキュリティやその他のシステム関連パラメータをプロビジョニングする可能性があります。
Paul Chilton illustrated the security and usability requirements in a typical end-user scenario for small-scale smart lighting systems [PaulChilton]. These systems present a substantial challenge for providing usable and secure communication because they are supposed to be cheap and very easy to set up, ideally as easy as their "dumb" predecessors. The example of IP-enabled light bulbs shows that the more constrained devices are, the more difficult it is to get security right. For this reason, and the required usability, light bulbs might just be the perfect example for examining the viability of security solutions.
Paul Chiltonは、小規模のスマート照明システム[PaulChilton]の典型的なエンドユーザーシナリオにおけるセキュリティとユーザビリティの要件を示しました。これらのシステムは、安価で、セットアップが非常に簡単で、理想的には「前身のない」前任者と同じくらい簡単であると想定されているため、使用可能で安全な通信を提供するための大きな課題を提示します。 IP対応の電球の例は、デバイスの制約が多いほど、セキュリティを正しく確保することが難しくなることを示しています。このため、必要な使いやすさの点で、電球はセキュリティソリューションの実行可能性を調べるのに最適な例にすぎません。
Rudolf van der Berg focused on large-scale deployments of smart objects, such as eBook readers, smart meters, and automobiles. The use of mobile cellular networks is attractive because they are networks with adequate coverage and capacity on a global scale. In order to make use of mobile networks, you need to make use of authentication based on Subscriber Identity Modules (SIMs). However, at this moment, the SIM is controlled by the network operator. These companies could also use EAP-SIM (Extensible Authentication Protocol SIM) [RFC4186] authentication in, for example, wireless LANs.
Rudolf van der Bergは、eBookリーダー、スマートメーター、自動車などのスマートオブジェクトの大規模な展開に焦点を当てました。モバイルセルラーネットワークは、グローバルな規模で十分なカバレッジと容量を備えたネットワークであるため、魅力的な使用法です。モバイルネットワークを利用するには、加入者識別モジュール（SIM）に基づく認証を利用する必要があります。ただし、現時点では、SIMはネットワークオペレーターによって制御されています。これらの企業は、たとえば無線LANでEAP-SIM（拡張認証プロトコルSIM）[RFC4186]認証を使用することもできます。
The end-user interaction may differ depending on the credentials being used: for a light bulb deployed in the user's home, it is expected that the user somehow configures devices so that only, for example, family members can turn them on and off. Smart objects that are equipped with SIM-based credential infrastructure do not require credential management by the end user since credential management by the operator can be assumed. Switching cellular operators may, however, pose challenges for these devices.
エンドユーザーの操作は、使用されている資格情報に応じて異なる場合があります。ユーザーの自宅に展開されている電球の場合、ユーザーは、たとえば家族だけがデバイスの電源をオン/オフできるようにデバイスを構成することが予想されます。 SIMベースの資格情報インフラストラクチャを備えたスマートオブジェクトは、オペレーターによる資格情報管理を想定できるため、エンドユーザーによる資格情報管理を必要としません。ただし、携帯電話事業者の切り替えは、これらのデバイスに課題をもたらす可能性があります。
Furthermore, we have a technology that will be both deployed by end users and large enterprise customers. While the protocol building blocks may be the same, there is certainly a big difference between deployments for large-scale industrial applications and deployments for regular end users in terms of the architecture. Between these two, the security requirements differ significantly, as do the threats. It is difficult, if not impossible, to develop a single security architecture that fulfills the needs of all users while at the same time meeting the constraints of all kinds of smart objects.
さらに、エンドユーザーと大企業の顧客の両方が展開するテクノロジを使用しています。プロトコルのビルディングブロックは同じかもしれませんが、大規模な産業用アプリケーションの配置と通常のエンドユーザーの配置には、アーキテクチャの点で確かに大きな違いがあります。これら2つの間では、脅威と同様に、セキュリティ要件は大幅に異なります。あらゆる種類のスマートオブジェクトの制約を満たすと同時に、すべてのユーザーのニーズを満たす単一のセキュリティアーキテクチャを開発することは、不可能ではないにしても困難です。
In the consumer market, security should not incur any overhead during installation. If an end user has to invest more time or effort to secure a smart object network, he or she will likely not do it. Consumer products will often be retrofitted into the existing infrastructure, bought, and installed by consumers themselves. This means that devices will have to come pre-installed to some extent and will most likely interoperate only with the infrastructure provided by the vendor, i.e., the devices will be able to connect to the Internet but will only interoperate with the servers provided by the vendor selling the device.
コンシューマ市場では、インストール中にセキュリティによってオーバーヘッドが発生することはありません。エンドユーザーがスマートオブジェクトネットワークをセキュリティで保護するためにより多くの時間や労力を費やす必要がある場合、エンドユーザーはそれを行わない可能性があります。多くの場合、消費者向け製品は既存のインフラストラクチャに組み込まれ、消費者自身が購入してインストールします。つまり、デバイスはある程度事前にインストールする必要があり、ベンダーが提供するインフラストラクチャとのみ相互運用できる可能性があります。つまり、デバイスはインターネットに接続できますが、サーバーが提供するサーバーとのみ相互運用できます。デバイスを販売するベンダー。
Closed systems (one bulb, one switch) typically work out of the box, as they have been extensively tested and often come with factory-configured security credentials. Problems do arise when additional devices are added or when these closed systems get connected to the Internet. It is still very common to ship devices with default passwords. It is, however, not acceptable that a device is in a vulnerable, but Internet-connected, state before it has been correctly configured by a consumer. It is easy to conceive that many consumers do not configure their devices properly and may therefore make it easy for an adversary to take control of the device by, for example, using the default password or outdated firmware.
クローズドシステム（電球1つ、スイッチ1つ）は、広範囲にわたってテストされており、多くの場合、工場で構成されたセキュリティ資格情報が付属しているため、そのまま使用できます。追加のデバイスが追加されたとき、またはこれらのクローズドシステムがインターネットに接続されたときに、問題が発生します。デフォルトのパスワードでデバイスを出荷することはまだ非常に一般的です。ただし、デバイスがコンシューマによって正しく設定される前に、デバイスが脆弱であるがインターネットに接続された状態であることは許容されません。多くの消費者が自分のデバイスを適切に構成していないため、デフォルトのパスワードや古いファームウェアを使用するなどして、攻撃者がデバイスを簡単に制御できるようになる可能性があります。
Once security threats for a specific deployment scenario have been identified, an assessment takes place to decide what security requirements can be identified and what security properties are desirable for the solution. As part of this process, a conscious decision needs to take place about which countermeasures will be used to mitigate certain threats. For some security threats, the assessment may also lead to the conclusion that the threat is considered out-of-scope and, therefore, no technical protection is applied. Different businesses are likely to come to different conclusions about the priorities for protection and what security requirements will be derived.
特定の展開シナリオに対するセキュリティの脅威が特定されると、特定できるセキュリティ要件とソリューションに望ましいセキュリティプロパティを決定するための評価が行われます。このプロセスの一環として、特定の脅威を軽減するためにどの対策を使用するかについて、意識的な決定を行う必要があります。一部のセキュリティ脅威については、評価によって脅威が範囲外と見なされるため、技術的な保護が適用されないという結論に至る場合もあります。保護の優先順位や派生するセキュリティ要件については、企業によって結論が異なる可能性があります。
Which security threats are worthwhile to protect against is certainly in the eye of the beholder and remains an entertaining discussion even among security specialists. For some of the workshop participants, the security threats against a smart lighting system were considered relatively minor compared to other smart home appliances. Clearly, the threats depend on the specific application domain, but there is a certain danger that deployments of vulnerable smart objects will increase. As the systems evolve and become more pervasive, additional security features may be required and may be difficult to incorporate into the already installed base, particularly if smart objects have no software update mechanism incorporated in their initial design. Smart objects that require human interaction to perform software updates will likely be problematic in the future. This is particularly true for devices that are expected to have service schedules of five to twenty-five years. Experience shows that security breaches that are considered pranks usually evolve very rapidly to become destructive attacks.
どのセキュリティの脅威から保護する価値があるかは、確かに見る人の目にあり、セキュリティの専門家の間でも面白い議論のままです。ワークショップ参加者の一部にとって、スマート照明システムに対するセキュリティの脅威は、他のスマート家電に比べて比較的軽微であると考えられていました。明らかに、脅威は特定のアプリケーションドメインに依存しますが、脆弱なスマートオブジェクトの展開が増えるという特定の危険があります。システムが進化して普及すると、特にスマートオブジェクトのソフトウェア更新メカニズムが初期設計に組み込まれていない場合は、追加のセキュリティ機能が必要になり、すでにインストールされているベースに組み込むのが難しい場合があります。ソフトウェアの更新を実行するために人間の操作が必要なスマートオブジェクトは、将来問題になる可能性があります。これは特に、5年から25年のサービススケジュールが予想されるデバイスに当てはまります。経験によれば、いたずらと見なされるセキュリティ違反は、通常、非常に急速に進化して破壊的な攻撃になります。
Apart from the security requirements of individual households and users, it is also important to look at the implications of vulnerabilities in large-scale smart object deployments, for example, in smart meters and the power grid.
個々の世帯およびユーザーのセキュリティ要件とは別に、スマートメーターや電力グリッドなどの大規模なスマートオブジェクトの配置における脆弱性の影響を調べることも重要です。
Finally, there is the usual wealth of other requirements that need to be taken into account, such as ability for remote configuration and software updates, the ability to deal with transfer of ownership of a device, avoidance of operator or vendor lock-in, crypto agility, minimal production, license and IPR costs, etc.
最後に、リモート構成およびソフトウェアの更新機能、デバイスの所有権の譲渡に対処する機能、オペレーターまたはベンダーのロックインの回避、暗号化など、考慮に入れる必要がある他の通常の豊富な要件があります。俊敏性、最小限の生産、ライセンス、IPRコストなど
The second slot of the workshop was dedicated to reports from first-hand implementation experience. Various participants had provided position papers exploring different security protocols and cryptographic primitives. There were three invited talks that covered tiny implementations of the Constrained Application Protocol (CoAP) protected by Datagram Transport Layer Security (DTLS), a TLS implementation using raw public keys, and general experience with implementing public key cryptography on smart object devices.
ワークショップの2番目のスロットは、直接の実装経験からのレポート専用です。さまざまな参加者が、さまざまなセキュリティプロトコルと暗号プリミティブを探索するポジションペーパーを提供していました。データグラムトランスポート層セキュリティ（DTLS）で保護されたConstrained Application Protocol（CoAP）の小さな実装、生の公開鍵を使用したTLS実装、およびスマートオブジェクトデバイスでの公開鍵暗号の実装に関する一般的な経験を取り上げた3つの招待講演がありました。
All three presenters demonstrated that implementations of IETF security protocols on various constraint devices are feasible. This was confirmed by other workshop participants as well. The overall code size and performance of finished implementations will depend on the chosen feature set. It is fairly obvious that more features translate to a more complex outcome. Luckily, IETF security protocols in general (and TLS/DTLS is no exception) can be customized in a variety of ways to fit a specific deployment environment. As such, an engineer will have to decide which features are important for a given deployment scenario and what trade-offs can be made. There was also the belief that IETF security protocols offer useful customization features (such as different ciphersuites in TLS/DTLS) to select the desired combination of algorithms and cryptographic primitives. The need to optimize available security protocols further or to even develop new cryptographic primitives for smart objects was questioned and not seen as worthwhile by many participants.
3人の発表者全員が、さまざまな制約デバイスでのIETFセキュリティプロトコルの実装が可能であることを示しました。これは他のワークショップ参加者によっても確認されました。完成した実装の全体的なコードサイズとパフォーマンスは、選択した機能セットによって異なります。より多くの機能がより複雑な結果に変換されることはかなり明白です。さいわい、IETFセキュリティプロトコル全般（およびTLS / DTLSも例外ではありません）は、特定の展開環境に適合するようにさまざまな方法でカスタマイズできます。そのため、エンジニアは、特定の展開シナリオにとってどの機能が重要であり、どのようなトレードオフを行うことができるかを決定する必要があります。 IETFセキュリティプロトコルは、アルゴリズムと暗号化プリミティブの望ましい組み合わせを選択するための便利なカスタマイズ機能（TLS / DTLSのさまざまな暗号スイートなど）を提供するとの信念もありました。利用可能なセキュリティプロトコルをさらに最適化する必要性、またはスマートオブジェクト用の新しい暗号プリミティブを開発する必要性さえ疑問視され、多くの参加者にとって価値があるとは見なされていませんでした。
The three common constraints for security implementations on smart objects are code size, energy consumption, and bandwidth. The importance of tailoring a solution to one of these constraints depends on the specific deployment environment. It might be difficult to develop a solution that addresses all constraints at the same time. For example, minimizing memory use may lead to increased communication overhead.
スマートオブジェクトのセキュリティ実装に共通する3つの制約は、コードサイズ、エネルギー消費、帯域幅です。これらの制約の1つに合わせてソリューションを調整することの重要性は、特定の展開環境によって異なります。すべての制約に同時に対処するソリューションを開発するのは難しい場合があります。たとえば、メモリの使用を最小限にすると、通信オーバーヘッドが増加する可能性があります。
Waiting for the next generation of hardware typically does not magically lift the constraints faced today. The workshop participants again reinforced the message that was made at the earlier smart object workshop [RFC6574] regarding future developments in the smart object space:
次世代のハードウェアを待つことは、通常、今日直面している制約を魔法のように解除するものではありません。ワークショップの参加者は、以前のスマートオブジェクトワークショップ[RFC6574]で作成された、スマートオブジェクト空間の将来の発展に関するメッセージを再度強化しました。
While there are constantly improvements being made, Moore's law tends to be less effective in the embedded system space than in personal computing devices: gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power.
常に改善が行われていますが、ムーアの法則は、パーソナルコンピューティングデバイスよりも組み込みシステムスペースでは効果が低くなる傾向があります。トランジスタ数と密度の増加によって得られる利益は、計算能力の継続的な増加に。
The above statement is applicable to smart object designs in general, not only for security. Thus, it is expected that designers will continue having to deal with various constraints of smart objects in the future. A short description of the different classes of smart objects can be found in [RFC7228], which also provides security-related guidance. The workshop participants noted that making security protocols suitable for smart objects must not water down their effectiveness. Security functionality will demand some portion of the overall code size. It will have an impact on the performance of communication interactions, lead to higher energy consumption, and certainly make the entire product more complex. Still, omitting security functionality because of various constraints is not an option. The experience with implementing available security protocols was encouraging even though the need to make various architectural design decisions for selecting the right set of protocols and protocol extensions that everyone must agree on was pointed out. Sometimes, the leading constraint is energy consumption, and in other cases, it is main memory, CPU performance, or bandwidth. In any case, for an optimization, it is important to look at the entire system rather than a single protocol or even a specific algorithm.
上記の説明は、セキュリティだけでなく、スマートオブジェクトの設計全般に適用できます。したがって、設計者は今後もスマートオブジェクトのさまざまな制約に対処しなければならないことが予想されます。スマートオブジェクトのさまざまなクラスの簡単な説明は[RFC7228]にあり、セキュリティ関連のガイダンスも提供されています。ワークショップの参加者は、セキュリティオブジェクトをスマートオブジェクトに適したものにすることは、その有効性を損なうものであってはならないことに注意しました。セキュリティ機能は、全体的なコードサイズの一部を要求します。通信の相互作用のパフォーマンスに影響を与え、エネルギー消費量を増やし、製品全体をより複雑にします。それでも、さまざまな制約のためにセキュリティ機能を省略することはできません。利用可能なセキュリティプロトコルの実装経験は、誰もが同意しなければならない適切なプロトコルとプロトコル拡張のセットを選択するために、さまざまなアーキテクチャ設計の決定を行う必要性が指摘されていたとしても、励みになりました。主な制約はエネルギー消費である場合もあれば、メインメモリ、CPUパフォーマンス、または帯域幅である場合もあります。いずれの場合も、最適化のためには、単一のプロトコルや特定のアルゴリズムではなく、システム全体を調べることが重要です。
Equally important to the code size of the protocols being used in a deployed product are various other design decisions, such as the communication model, the number of communication partners, the interoperability requirements, and the threats that are being dealt with. Mohit Sethi noted that even the execution time for relatively expensive operations like asymmetric signature generation and verification are within acceptable limits for very constrained devices, like an Arduino UNO. In either case, public key cryptography will likely only be used for the initial communication setup to establish symmetric session keys. Perhaps surprisingly, the energy cost of transmitting data wirelessly dwarfs even expensive computations like public key cryptography. Since wireless reception is actually the most power-consuming task on a smart object, protocols have to be designed accordingly.
展開された製品で使用されているプロトコルのコードサイズと同様に重要なのは、通信モデル、通信パートナーの数、相互運用性の要件、処理される脅威など、他のさまざまな設計上の決定です。 Mohit Sethiは、非対称署名の生成や検証などの比較的コストのかかる操作の実行時間でさえ、Arduino UNOなどの非常に制約のあるデバイスでは許容範囲内であると指摘しました。どちらの場合も、公開鍵暗号化は、対称セッション鍵を確立するための初期通信セットアップにのみ使用される可能性があります。おそらく驚くべきことに、ワイヤレスでデータを送信するエネルギーコストは、公開キー暗号化のような高価な計算でさえも小さくします。ワイヤレス受信は実際にはスマートオブジェクトで最も電力を消費するタスクであるため、プロトコルはそれに応じて設計する必要があります。
The workshop participants shared the view that the complexity of security protocols is a result of desired features. Redesigning a protocol with the same set of features will, quite likely, lead to a similar outcome in terms of code size, memory consumption, and performance. It was, however, also acknowledged that the security properties offered by DTLS/TLS/IKEv2-IPsec may not be needed for all deployment environments. DTLS, for example, offers an authentication and key exchange framework combined with channel security offering data-origin authentication, integrity protection, and (optionally) confidentiality protection.
ワークショップの参加者は、セキュリティプロトコルの複雑さは望ましい機能の結果であるという見解を共有しました。同じ機能セットを使用してプロトコルを再設計すると、コードサイズ、メモリ消費量、およびパフォーマンスの点で同様の結果が得られる可能性があります。ただし、DTLS / TLS / IKEv2-IPsecによって提供されるセキュリティプロパティがすべての展開環境に必要なわけではないことも認められました。たとえば、DTLSは、認証とキー交換フレームワークをチャネルセキュリティと組み合わせて提供し、データ起源の認証、整合性保護、および（オプションで）機密保護を提供します。
The biggest optimization in terms of code size can be gained when looking at the complete protocol stack, rather than only cryptographic algorithms. This also includes software update mechanisms and configuration mechanisms, all of which have to work together. What may not have been investigated enough is the potential of performing cross-layer and cross-protocol optimization. We also need to think about how many protocols for security setup we want to have. Due to the desire to standardize generic building blocks, the ability to optimize for specific deployment environments has been reduced.
暗号化アルゴリズムだけでなく、完全なプロトコルスタックを見ると、コードサイズの面で最大の最適化を得ることができます。これには、ソフトウェア更新メカニズムと構成メカニズムも含まれます。これらはすべて連携して動作する必要があります。十分に調査されていない可能性があるのは、クロスレイヤーおよびクロスプロトコルの最適化を実行する可能性です。また、セキュリティセットアップに必要なプロトコルの数についても考慮する必要があります。一般的なビルディングブロックを標準化したいという要望により、特定のデプロイメント環境向けに最適化する機能は低下しています。
Finally, it was noted that scalability of security protocols does not imply usability. This means that while smart object technology might currently be developed in large-scale industrial environments, it should be equally usable for consumers who want to equip their home with just a few light bulbs.
最後に、セキュリティプロトコルのスケーラビリティは使いやすさを意味しないことに注意してください。つまり、スマートオブジェクトテクノロジーは現在大規模な産業環境で開発されているかもしれませんが、自宅に数個の電球だけを装備したい消費者にも同様に使用できるはずです。
For details about the investigated protocol implementations, please consult the position papers, such as the ones by Bergmann et al., Perelman et al., Tschofenig, and Raza et al. (see Appendix C).
調査されたプロトコル実装の詳細については、Bergmannら、Perelmanら、Tschofenig、およびRazaらのポジションペーパーなどのポジションペーパーを参照してください。 （付録Cを参照）。
The discussion slot on authorization was meant to provide an idea of what kind of authorization decisions are common in smart object networks. Authorization is defined as an "approval that is granted to a system entity to access a system resource" [RFC4949].
承認に関するディスカッションスロットは、スマートオブジェクトネットワークで一般的な承認の決定の種類についてのアイデアを提供することを目的としています。承認は、「システムリソースにアクセスするためにシステムエンティティに許可される承認」[RFC4949]として定義されます。
Authorization requires a view on the entire smart object lifecycle to determine when and how a device was added to a specific environment, what permissions have been granted for this device, and how users are allowed to interact with it. On a high level, there are two types of authorization schemes. First, there are those systems that utilize an authenticated identifier and match it against an access control list. Second, there are trait-based authorization mechanisms that separate the authenticated identifier from the authorization rights and utilize roles and other attributes to determine whether to grant or deny access to a protected resource.
承認には、デバイスが特定の環境にいつどのように追加されたか、このデバイスにどの権限が付与されているか、ユーザーがデバイスと対話する方法を決定するために、スマートオブジェクトのライフサイクル全体のビューが必要です。高レベルでは、2つのタイプの認可スキームがあります。まず、認証された識別子を利用してアクセス制御リストと照合するシステムがあります。次に、認証された識別子を承認権から分離し、ロールやその他の属性を利用して、保護されたリソースへのアクセスを許可するか拒否するかを決定する特性ベースの承認メカニズムがあります。
Richard Barnes looked at earlier communication security work and argued that the model that dominates the web today will not be enough for the smart object environment. Simply identifying users by their credentials and servers via certificates is not something that translates well to smart object networks because it binds all the capabilities to the credentials. The evolution in access control is moving in the direction of granting third parties certain capabilities, with OAuth [RFC6749] being an example of a currently deployed technology. Access to a resource using OAuth can be done purely based on the capabilities rather than on the authenticated identifier.
Richard Barnesは、以前の通信セキュリティ作業を検討し、今日のWebを支配するモデルは、スマートオブジェクト環境には十分ではないと主張しました。証明書を介して資格情報とサーバーでユーザーを識別するだけでは、すべての機能が資格情報にバインドされるため、スマートオブジェクトネットワークにうまく変換できません。アクセス制御の進化は、サードパーティに特定の機能を付与する方向に進んでいます。OAuth[RFC6749]は、現在展開されているテクノロジーの例です。 OAuthを使用したリソースへのアクセスは、認証された識別子ではなく、単に機能に基づいて行うことができます。
At the time of the workshop, OAuth was very much focused on HTTP-based protocols with early efforts to integrate OAuth into the Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) [SASL-OAUTH]. Further investigations need to be done to determine the suitability of OAuth as a protocol for the smart object environment.
ワークショップの時点では、OAuthはHTTPベースのプロトコルに非常に重点が置かれており、OAuthをSimple Authentication and Security Layer（SASL）およびGeneric Security Service Application Program Interface（GSS-API）[SASL-OAUTH]に統合する初期の取り組みがありました。 ]。スマートオブジェクト環境のプロトコルとしてのOAuthの適合性を判断するには、さらに調査を行う必要があります。
Richard believed that it is important to separate authentication from authorization right from the beginning and to consider how users are supposed to interact with these devices to introduce them into their specific usage environment (and to provision them with credentials) and to manage access from different parties.
Richardは、最初から認証を承認から切り離し、ユーザーがこれらのデバイスを操作して特定の使用環境に導入し（および資格情報を提供する）、さまざまな関係者からのアクセスを管理する方法を検討することが重要であると考えていました。
The relationship between the policy enforcement point and the policy decision point plays an important role regarding the standardization needs and the type of information that needs to be conveyed between these two entities.
ポリシー実施ポイントとポリシー決定ポイントの関係は、標準化のニーズと、これら2つのエンティティ間で伝達する必要のある情報のタイプに関して重要な役割を果たします。
For example, in an Authentication, Authorization, and Accounting (AAA) context, the authorization decision happens at the AAA server (after the user requesting access to a network or some application-level services had been authenticated). Then, the decision about granting access (or rejecting it) is communicated from the AAA server to the AAA client at the end of the network access authentication procedure. The AAA client then typically enforces the authorization decision over the lifetime of the granted user session. The dynamic authorization extension [RFC5176] to the RADIUS protocol, for example, also allows the RADIUS server to make dynamic changes to a previously granted user session. This includes support for disconnecting users and changing authorizations applicable to a user session.
たとえば、認証、承認、およびアカウンティング（AAA）コンテキストでは、承認の決定はAAAサーバーで行われます（ネットワークへのアクセスを要求するユーザーまたは一部のアプリケーションレベルのサービスが認証された後）。次に、ネットワークアクセス認証手順の最後に、アクセスの許可（または拒否）に関する決定がAAAサーバーからAAAクライアントに通知されます。次に、AAAクライアントは通常、許可されたユーザーセッションの存続期間にわたって承認決定を実施します。たとえば、RADIUSプロトコルに対する動的認証拡張[RFC5176]により、RADIUSサーバーは以前に許可されたユーザーセッションに動的な変更を加えることができます。これには、ユーザーの切断と、ユーザーセッションに適用される承認の変更のサポートが含まれます。
The authorization decisions can range from 'only devices with passwords can use the network' to very detailed application-specific authorization policies. The decisions are likely to be more sophisticated in those use cases where ownership of devices may be transferred from one person to another one, group membership concepts may be needed, access rights may be revocable, and fine-grained access rights have to be used. The authorization decisions may also take environmental factors into account, such as proximity of devices to each other, physical location of the device asking access, or the level of authentication. With the configuration of authorization policies, questions arise regarding who will create them and where these policies are stored. This immediately raises questions about how devices are identified and who is allowed to create these policies.
承認の決定は、「パスワードを持つデバイスのみがネットワークを使用できる」から、非常に詳細なアプリケーション固有の承認ポリシーまでさまざまです。デバイスの所有権が1人から別の人に移されたり、グループメンバーシップの概念が必要になったり、アクセス権が取り消されたり、きめの細かいアクセス権を使用したりするようなユースケースでは、決定はより洗練される可能性があります。承認の決定では、デバイスの相互の近接度、アクセスを要求するデバイスの物理的な場所、認証のレベルなどの環境要因も考慮に入れられます。承認ポリシーを構成すると、誰がポリシーを作成し、これらのポリシーをどこに保存するかという疑問が生じます。これにより、デバイスがどのように識別され、誰がこれらのポリシーの作成を許可されるかについての質問がすぐに出されます。
Since smart objects may be limited in terms of code size, persistent storage, and Internet connectivity, established authorization schemes may not be well suited for such devices. Obviously, delegating every authorization decision to another node in the network incurs a certain network overhead, while storing sophisticated access control policies directly on the smart object might be prohibitive because of the size of such a ruleset. Jan Janak presented one approach to distribute access control policies to smart objects within a single administrative domain.
スマートオブジェクトはコードサイズ、永続的なストレージ、インターネット接続の点で制限されている可能性があるため、確立された認証スキームはそのようなデバイスにはあまり適していません。明らかに、すべての承認決定をネットワーク内の別のノードに委任すると、特定のネットワークオーバーヘッドが発生しますが、洗練されたアクセス制御ポリシーをスマートオブジェクトに直接保存すると、そのようなルールセットのサイズが原因で禁止される場合があります。 Jan Janakは、単一の管理ドメイン内のスマートオブジェクトにアクセス制御ポリシーを配布する1つのアプローチを提示しました。
In those cases where access control decisions are bound to the identifiers of devices and humans need to either create or verify these access control policies, the choice of identifier matters for readability and accessibility purposes.
アクセス制御の決定がデバイスの識別子に結び付けられており、人間がこれらのアクセス制御ポリシーを作成または検証する必要がある場合、識別子の選択は読みやすさとアクセシビリティの目的にとって重要です。
A single mechanism will likely not help with solving the wide range of authorization tasks. From the discussions, it was not clear whether there is a need for new authorization mechanisms or whether existing mechanisms can be reused. Examples of available protocols with built-in authorization mechanisms are Kerberos, OAuth, EAP/AAA, attribute certificates, etc. In many cases, it is even conceivable that the authorization decisions are internal to the system and that there is no need to standardize any additional authorization mechanisms or protocols at all. In fact, many of the authentication and key exchange protocols have authorization mechanisms built in.
単一のメカニズムでは、幅広い承認タスクを解決するのに役立つとは限りません。議論の結果、新しい承認メカニズムが必要かどうか、または既存のメカニズムを再利用できるかどうかは明確ではありませんでした。組み込みの承認メカニズムを備えた使用可能なプロトコルの例は、Kerberos、OAuth、EAP / AAA、属性証明書などです。多くの場合、承認の決定はシステムの内部で行われ、標準化する必要がないことも考えられます。追加の認証メカニズムまたはプロトコル。実際、認証および鍵交換プロトコルの多くには、承認メカニズムが組み込まれています。
When a smart object is to be introduced into an environment, like a home or an enterprise network, it usually has to be provisioned with some credentials first. The credentials that are configured at the smart object and at some entity in the network are often an implicit authorization to access the network or some other resource. The provisioned information at the smart object will include some identifier of the smart object, keying material, and other configuration information (e.g., specific servers it has to interact with).
スマートオブジェクトを家庭や企業のネットワークなどの環境に導入する場合、通常、最初にいくつかの資格情報を使用してプロビジョニングする必要があります。多くの場合、スマートオブジェクトとネットワーク内の一部のエンティティで構成されている資格情報は、ネットワークまたは他のリソースにアクセスするための暗黙的な承認です。スマートオブジェクトでプロビジョニングされた情報には、スマートオブジェクトの識別子、キー情報、およびその他の構成情報（相互作用する必要のある特定のサーバーなど）が含まれます。
Some devices will be pre-configured with default security codes or passwords, or will have per-device or per-user credentials pre-configured, when they are bought or when they arrive at the customer.
一部のデバイスは、デフォルトのセキュリティコードまたはパスワードで事前構成されているか、購入時または顧客に到着したときに、デバイスごとまたはユーザーごとの資格情報が事前構成されています。
There is a limited set of solutions available (based on the available interface support). The solutions for imprinting vary between the enterprise and the consumer household scenarios. For large-scale deployments, the time needed to pair two objects further excludes other schemes that rely on manual steps.
利用可能なソリューションのセットは限られています（利用可能なインターフェースサポートに基づく）。インプリンティングのソリューションは、企業のシナリオと家庭のシナリオで異なります。大規模な展開の場合、2つのオブジェクトをペアにするのに必要な時間は、手動の手順に依存する他のスキームをさらに除外します。
Johannes Gilger dealt with the very basic ideas behind pairing schemes, including the kinds of out-of-band channels that could be employed and their limitations. Imprinting and pairing protocols usually establish a security association between two equal devices, such as Bluetooth-equipped cell phones. To deal with man-in-the-middle attacks during this phase, various forms of additional verification checks exist. For example, devices with a display allow numeric values to be shown on each device and let the user verify whether they match. For other devices that have a keypad, a PIN may need to be entered by the user. Where and how a smart object is to be paired with other devices in the network can differ substantially from the specific use cases and the hardware capabilities of devices. Note that pairing is not necessarily something that is only done once during the lifetime of a device. Is group pairing something to be looked at? Or can any group key establishment be reduced to pairwise pairing with a central master device?
ヨハネスギルガーは、ペアリングスキームの背後にある非常に基本的なアイデアを扱いました。インプリンティングとペアリングのプロトコルは通常、Bluetooth対応の携帯電話など、2つの同等のデバイス間にセキュリティアソシエーションを確立します。このフェーズで中間者攻撃に対処するために、さまざまな形式の追加の検証チェックが存在します。たとえば、ディスプレイ付きのデバイスでは、数値を各デバイスに表示し、ユーザーがそれらが一致するかどうかを確認できます。キーパッドを備えた他のデバイスの場合、ユーザーがPINを入力する必要がある場合があります。スマートオブジェクトをネットワーク内の他のデバイスとペアリングする場所と方法は、特定の使用例やデバイスのハードウェア機能とは大幅に異なる場合があります。ペアリングは、必ずしもデバイスの寿命中に一度だけ行われるものではないことに注意してください。グループペアリングは注目すべきものですか？または、グループキーの確立を中央のマスターデバイスとのペアリングに削減できますか？
Cullen Jennings presented a model for smart objects based on a deployment used for IP phones. The idea was that the smart object "phones home", i.e., contacts a server offered by the manufacturer, when it is first switched on. This initial interaction can then be used for managing the device and provisioning keying material for further use. Proof of ownership could be done by identifying the user who purchased the device. This is an approach that is increasingly being done today. Another option is some kind of secret information enclosed in the packaging.
Cullen Jenningsは、IP電話に使用される配置に基づくスマートオブジェクトのモデルを提示しました。このアイデアは、スマートオブジェクト「フォンホーム」、つまり製造元が提供するサーバーに最初に電源が投入されたときに接続するというものでした。その後、この最初の対話を使用して、デバイスを管理し、さらに使用するためのキー情報をプロビジョニングできます。所有権の証明は、デバイスを購入したユーザーを特定することで実行できます。これは、今日ますます行われているアプローチです。別のオプションは、パッケージに含まれるある種の秘密情報です。
For interface-constrained devices, the solution of using (semi)- public information in combination with an online manufacturer during imprinting seems like a possible solution. This solution approach created a lot of discussion among the participants, as it assumes an Internet connection and means that the manufacturer effectively knows about the trust relationships of all the devices it sells.
インターフェイスに制約のあるデバイスの場合、インプリント中に（半）公開情報をオンラインの製造元と組み合わせて使用するソリューションは、考えられるソリューションのようです。このソリューションアプローチは、インターネット接続を想定しており、製造業者が販売するすべてのデバイスの信頼関係を効果的に知っていることを意味するため、参加者の間で多くの議論を引き起こしました。
A few questions did arise with such a model: Will there be third parties that have a business interest in providing something like key distribution and key escrow over the lifetime of a smart object? For constrained devices, will it always be possible to fall back to the existing security associations between device and manufacturer to create new associations? Obviously, we do not want the lifetime of a smart object limited by the manufacturer product support lifespan. What happens if a manufacturer goes bankrupt, changes its business scope, or gets bought by another company? Will end customers not be able to use their smart objects anymore in such a case, or will they lose the ability to resell their devices because the ownership can no longer be transferred?
このようなモデルではいくつかの質問が発生しました。スマートオブジェクトの有効期間中、キーの配布やキーのエスクローなどを提供することにビジネス上の関心を持つサードパーティは存在しますか？制約のあるデバイスの場合、デバイスと製造元間の既存のセキュリティアソシエーションにフォールバックして、新しいアソシエーションを作成することは常に可能ですか？明らかに、製造元の製品サポートの寿命によって制限されるスマートオブジェクトの寿命は必要ありません。製造業者が破産した場合、事業範囲が変更された場合、または別の会社に買収された場合はどうなりますか？このような場合、エンドユーザーはスマートオブジェクトを使用できなくなりますか、または所有権を譲渡できなくなるため、デバイスを再販できなくなりますか？
One important design decision is that the compromise of the manufacturer must not have any impact on the smart objects, which have already been imprinted to their new owners. Furthermore, the question arises of how to transfer ownership, e.g., when reselling a device. While this may not be a requirement for all devices, there will likely be classes of large or expensive devices where support for transferring the ownership is an absolute necessity.
重要な設計上の決定の1つは、メーカーの妥協が、新しい所有者にすでに刻印されているスマートオブジェクトに影響を与えてはならないということです。さらに、たとえばデバイスを再販する場合など、所有権をどのように譲渡するかという問題が生じます。これはすべてのデバイスの要件ではないかもしれませんが、所有権の移転のサポートが絶対に必要なクラスの大型または高価なデバイスが存在する可能性があります。
Industrial users are comfortable when they have to rely on the manufacturer during the imprinting phase, but they want to be in exclusive control over their devices afterwards.
産業ユーザーは、インプリント段階で製造業者に依存する必要がある場合は快適ですが、その後はデバイスを排他的に制御したいと考えています。
There are many classes of devices where we could assume online connectivity to be present; otherwise, these devices would not make sense in the first place. But, there are also other devices that need to be imprinted completely offline.
オンライン接続が存在すると想定できるデバイスのクラスはたくさんあります。そうでなければ、これらのデバイスはそもそも意味がありません。ただし、完全にオフラインでインプリントする必要がある他のデバイスもあります。
Is it important to worry about security vulnerabilities, such as man-in-the-middle attacks, during the very short imprinting phase? Is it realistic that an adversary is in close proximity to mount an attack? Especially for devices with limited capabilities, such as light bulbs, the concerns seemed rather small.
非常に短いインプリンティングフェーズ中に、man-in-the-middle攻撃などのセキュリティの脆弱性について心配することは重要ですか？攻撃者が攻撃を仕掛けるために近接していることは現実的ですか？特に、電球などの機能が制限されているデバイスでは、懸念はかなり小さいように見えました。
What happens if such a device is not enrolled by the customer but still connected in a "naked" state? How does this impact security, and is it possible for an attacker to perform a "drive-by" enrollment procedure of many devices? How should a device behave in this situation? The safest option (for the user at least) would be to not allow the device to work with full functionality if it has not been enrolled. This concern is particularly applicable for cases where smart objects are sold with default passwords or passwords using semi-public information; an example is Raspberry Pi computers with Linux images that use a default password [RaspberryPi].
そのようなデバイスが顧客に登録されていなくても、「ネイキッド」状態で接続されている場合はどうなりますか？これはセキュリティにどのように影響しますか？攻撃者が多くのデバイスの「ドライブバイ」登録手順を実行することは可能ですか？この状況でデバイスはどのように動作しますか？ （少なくともユーザーにとって）最も安全なオプションは、デバイスが登録されていない場合、デバイスが完全な機能で動作しないようにすることです。この懸念は、デフォルトのパスワードまたは半公開情報を使用したパスワードでスマートオブジェクトが販売されている場合に特に当てはまります。たとえば、デフォルトのパスワード[RaspberryPi]を使用するLinuxイメージを搭載したRaspberry Piコンピューターです。
Designing for a smart object environment is about making an optimization decision that needs to take technical aspects, usage scenarios, security threats, and business models into account. Some design constraints may be considered fixed while others are flexible. Compromises will need to be made, but they should not be made at the expense of security functionality.
スマートオブジェクト環境の設計とは、技術的な側面、使用シナリオ、セキュリティの脅威、およびビジネスモデルを考慮する必要がある最適化の決定を行うことです。設計上の制約の中には修正済みと見なされるものもあれば、柔軟なものもあります。妥協する必要がありますが、セキュリティ機能を犠牲にして妥協するべきではありません。
Designing a software update mechanism into the system is crucial to ensure that functionality can be enhanced and vulnerabilities can be fixed. Also, security threats are perceived differently over time. For example, many people considered pervasive monitoring less important prior to the Snowden revelations.
システムにソフトウェア更新メカニズムを設計することは、機能性を強化し、脆弱性を修正できるようにするために重要です。また、セキュリティの脅威に対する認識は、時間の経過とともに異なります。たとえば、多くの人々は、スノーデンの啓示の前は、広汎な監視はそれほど重要ではないと考えていました。
New research and standardization on cryptographic algorithms (like encryption algorithms, hash functions, keyed message digests, and public key crypto systems) that are tailored to smart object environments was not seen as worthwhile by the participants. A huge range of algorithms already exist, and standardized authentication and key exchange protocols can be customized to use almost any selection of algorithms available today.
スマートオブジェクト環境に合わせて調整された暗号化アルゴリズム（暗号化アルゴリズム、ハッシュ関数、キー付きメッセージダイジェスト、公開キー暗号システムなど）に関する新しい研究と標準化は、参加者にとって価値があるとは見なされていませんでした。非常に幅広いアルゴリズムがすでに存在しており、標準化された認証および鍵交換プロトコルをカスタマイズして、現在利用可能なほぼすべてのアルゴリズムを使用できます。
The integration of various building blocks into a complete system was considered important, and this document highlights a number of those areas in Section 3. Searching for a single, universally applicable
さまざまなビルディングブロックを完全なシステムに統合することが重要であると考えられており、このドキュメントでは、セクション3でこれらの領域の多くを取り上げています。
smart object security architecture was seen as a hopeless journey given the large number of use cases, business models, and constraints.
スマートオブジェクトセキュリティアーキテクチャは、多数のユースケース、ビジネスモデル、および制約があるため、絶望的な旅と見なされていました。
In response to the workshop, follow-up work happened in a number of areas (and standardization activities are still ongoing). Here are a few examples:
ワークショップに応じて、多くの分野でフォローアップ作業が行われました（標準化活動はまだ進行中です）。以下にいくつかの例を示します。
o The Light-Weight Implementation Guidance (LWIG) working group was created to offer a venue to collect experiences from implementers of IP stacks, including security protocols, in constrained devices. The ability to tune IETF protocols via extensions and parameter choices gives implementers a lot of flexibility to meet the constraints of a smart object environment.
o 軽量実装ガイダンス（LWIG）ワーキンググループは、制約されたデバイスでセキュリティプロトコルを含むIPスタックの実装者から経験を収集する場を提供するために作成されました。拡張機能とパラメーターの選択を介してIETFプロトコルを調整する機能により、実装者は、スマートオブジェクト環境の制約を満たすために多くの柔軟性を得ることができます。
o The DTLS In Constrained Environments (DICE) working group was formed to define a DTLS profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices, and to define how the DTLS record layer can be used to transmit multicast messages securely. DTLS is seen as an important enabling technology for securing communication interactions by smart objects.
o DTLS In Constrained Environments（DICE）ワーキンググループは、モノのインターネットアプリケーションに適しており、多くの制約されたデバイスで合理的に実装可能なDTLSプロファイルを定義し、DTLSレコードレイヤーを使用してマルチキャストメッセージを安全に送信する方法を定義するために設立されました。 DTLSは、スマートオブジェクトによる通信のやり取りを保護するための重要な有効化テクノロジと見なされています。
o A new working group has been formed to standardize an authentication and authorization protocol for constrained environments offering a dynamic and fine-grained access control mechanism where clients and resource servers are constrained and therefore have to make use of a trusted third party. At the time of writing this document, the Authentication and Authorization for Constrained Environments (ACE) working group has just been started.
o クライアントとリソースサーバーが制約されているため、信頼できるサードパーティを利用する必要がある動的かつきめ細かいアクセス制御メカニズムを提供する制約された環境の認証および承認プロトコルを標準化するために、新しいワーキンググループが形成されました。このドキュメントの執筆時点では、制約付き環境の認証と承認（ACE）ワーキンググループが始まったばかりです。
This whole document is a report on the 'Smart Object Security Workshop'. The focus of this workshop was on security only; privacy was not part of the workshop agenda.
このドキュメント全体は、「スマートオブジェクトセキュリティワークショップ」に関するレポートです。このワークショップの焦点はセキュリティのみでした。プライバシーはワークショップの議題の一部ではありませんでした。
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, April 2012, <http://www.rfc-editor.org/info/rfc6574>.
[RFC6574] Tschofenig、H。およびJ. Arkko、「Report from the Smart Object Workshop」、RFC 6574、2012年4月、<http://www.rfc-editor.org/info/rfc6574>。
[PaulChilton] Chilton, P., "Experiences and Challenges in using constrained Smart Objects", March 2012, <http://www.lix.polytechnique.fr/hipercom/ SmartObjectSecurity/papers/PaulChilton.pdf>.
[PaulChilton] Chilton、P。、「制約付きスマートオブジェクトの使用における経験と課題」、2012年3月、<http://www.lix.polytechnique.fr/hipercom/ SmartObjectSecurity / papers / PaulChilton.pdf>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月、<http://www.rfc-editor.org/info/rfc3552>。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005, <http://www.rfc-editor.org/info/rfc4101>.
[RFC4101] Rescorla、E。およびIAB、「Writing Protocol Models」、RFC 4101、2005年6月、<http://www.rfc-editor.org/info/rfc4101>。
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006, <http://www.rfc-editor.org/info/rfc4186>.
[RFC4186] Haverinen、H。およびJ. Salowey、「グローバルシステムのモバイルコミュニケーション（GSM）加入者識別モジュール（EAP-SIM）の拡張認証プロトコルメソッド」、RFC 4186、2006年1月、<http：//www.rfc -editor.org/info/rfc4186>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008、 <http://www.rfc-editor.org/info/rfc5176>。
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011, <http://www.rfc-editor.org/info/rfc6272>.
[RFC6272]ベイカー、F。およびD.マイヤー、「スマートグリッドのためのインターネットプロトコル」、RFC 6272、2011年6月、<http://www.rfc-editor.org/info/rfc6272>。
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、「The OAuth 2.0 Authorization Framework」、RFC 6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、May 2014、<http://www.rfc-editor.org/info/rfc7228> 。
[RaspberryPi] Raspberry Pi Foundation, "Raspberry Pi", February 2013, <http://www.raspberrypi.org>.
[RaspberryPi] Raspberry Pi Foundation、「Raspberry Pi」、2013年2月、<http://www.raspberrypi.org>。
[SASL-OAUTH] Mills, W., Showalter, T., and H. Tschofenig, "A set of SASL Mechanisms for OAuth", Work in Progress, draft-ietf-kitten-sasl-oauth-18, November 2014.
[SASL-OAUTH] Mills、W.、Showalter、T。、およびH. Tschofenig、「一連のSASLメカニズムfor OAuth」、Work in Progress、draft-ietf-kitten-sasl-oauth-18、2014年11月。
[SMART-OBJECT] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", Work in Progress, draft-iab-smart-object-architecture-06, October 2014.
[SMART-OBJECT] Tschofenig、H.、Arkko、J.、Thaler、D。、およびD. McPherson、「スマートオブジェクトネットワーキングにおけるアーキテクチャの考慮事項」、Work in Progress、draft-iab-smart-object-architecture-06、 2014年10月。
The workshop was organized by the following individuals:
ワークショップは以下の個人によって開催されました：
o Hannes Tschofenig o Jari Arkko o Carsten Bormann o Peter Friess o Cullen Jennings o Antonio Skarmeta o Zach Shelby o Thomas Heide Clausen
o はんえｓ Ｔｓちょふぇにｇ お じゃり あｒっこ お かｒｓてん ぼｒまん お ぺてｒ Ｆりえっｓ お くっぇん じぇんいんｇｓ お あんとにお Ｓかｒめた お ざｃｈ しぇｌｂｙ お てょまｓ へいで Ｃぁうせん
o Main Workshop Page <http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity>
o メインワークショップページ<http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity>
o Position Papers <http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ papers>
o ポジションペーパー<http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ papers>
o Slides <http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ slides>
o スライド<http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ slides>
1. Michael Richardson, "Challenges in Smart Object Security: too many layers, not enough ram"
1. Michael Richardson、「スマートオブジェクトセキュリティへの挑戦：レイヤーが多すぎ、RAMが不十分」
2. Mitsuru Kanda, Yoshihiro Ohba, Subir Das, Stephen Chasko, "PANA applicability in constrained environments"
2. みつる かんだ、 よしひろ おｈば、 すびｒ だｓ、 Ｓてｐへん ちゃｓこ、 ”ぱな あっｐぃかびぃｔｙ いん こんｓｔらいねｄ えんゔぃろんめんｔｓ”
3. Randy Bush, "An Operational View of Trust Needs of Moving Objects"
3. ランディブッシュ、「移動オブジェクトの信頼ニーズの運用ビュー」
4. Andrei Gurtov, Ilya Nikolaevsky, Andrey Lukyanenko, "Using HIP DEX for Key Management and Access Control in Smart Objects"
4. Andrei Gurtov、Ilya Nikolaevsky、Andrey Lukyanenko、「スマートオブジェクトでのキー管理とアクセス制御のためのHIP DEXの使用」
5. Jens-Matthias Bohli, "Access Tokens for the IoT"
5. Jens-Matthias Bohli、「IoTのアクセストークン」
6. Martina Brachmann, Oscar Garcia-Morchon, Sye-Loong Keoh, Sandeep S. Kumar, "Security Considerations around End-to-End Security in the IP-based Internet of Things"
6. Martina Brachmann、Oscar Garcia-Morchon、Sye-Loong Keoh、Sandeep S. Kumar、「IPベースのモノのインターネットにおけるエンドツーエンドのセキュリティに関するセキュリティの考慮事項」
7. Kazunori Miyazawa, "Convergence of Smart Objects in industrial wireless sensor network"
7. 宮沢和典、「産業用無線センサーネットワークにおけるスマートオブジェクトの収束」
8. Thomas Bartzsch, Dirk Burggraf, Laura Cristina Gheorghe, Alexis Olivereau, Nouha Oualha, Emil Slusanschi, Dan Tudose, Markus Wehner, Sven Zeisberg, "AAA-based Infrastructure for Industrial Wireless Sensor Networks"
8. Thomas Bartzsch、Dirk Burggraf、Laura Cristina Gheorghe、Alexis Olivereau、Nouha Oualha、Emil Slusanschi、Dan Tudose、Markus Wehner、Sven Zeisberg、「産業用無線センサーネットワーク用のAAAベースのインフラストラクチャ」
9. Fida Khattak, Philip Ginzboorg, Valtteri Niemi, Jan-Erik Ekberg, "Role of Border Router in 6LoWPAN Security"
9. フィダ・ハッタク、フィリップ・ギネスバーグ、善良のニエミ、ジャン・エリック・エクバーグ、「ロパンセキュリティにおけるボーダールーターの役割」
10. Thomas Fossati, Angelo Castellani, Salvatore Loreto, "(Un)trusted Intermediaries in CoAP"
10. Thomas Fossati、Angelo Castellani、Salvatore Loreto、「（Un）信頼できるCoAPの仲介者」
11. Rene Hummen, Christian Roeller, Klaus Wehrle, "Modeling User-defined Trust Overlays for the IP-based Internet of Things"
11. Rene Hummen、Christian Roeller、Klaus Wehrle、「IPベースのモノのインターネットのためのユーザー定義の信頼オーバーレイのモデリング」
12. Sam Hartman, Margaret Wasserman, "Federation, ABFAB and Smart Devices"
12. サムハートマン、マーガレットワッサーマン、「フェデレーション、ABFAB、スマートデバイス」
13. Cary Bran, Joseph Stachula, "Device Pairing: Lessons Learned"
13. Cary Bran、Joseph Stachula、「デバイスのペアリング：教訓」
14. Jan Janak, Hyunwoo Nam, Henning Schulzrinne, "On Access Control in the Internet of Things"
14. Jan Janak、Hyunwoo Nam、Henning Schulzrinne、「モノのインターネットにおけるアクセス制御について」
15. Rene Struik, "Cryptography and Security for Highly Constrained Networks"
15. Rene Struik、「高度に制約されたネットワークの暗号化とセキュリティ」
16. Zhen Cao, Hui Deng, Judy Zhu, "The Architecture of Open Security Capability"
16. Z and NC Austria、Hui Deng、Judy Z Tiger、「オープンセキュリティ機能のアーキテクチャ」
17. Sujing Zhou, Zhenhua Xie, "On Cryptographic Approaches to Internet-Of-Things Security"
17. Sujing Zhou、Zhenhua Xie、「モノのインターネットのセキュリティへの暗号化アプローチについて」
18. Nancy Cam-Winget, Monique Morrow, "Security Implications to Smart Addressable Objects"
18. Nancy Cam-Winget、Monique Morrow、「スマートアドレス指定可能オブジェクトへのセキュリティの影響」
19. Jouni Korhonen, "Applying Generic Bootstrapping Architecture for use with Constrained Devices"
19. Jouni Korhonen、「制約付きデバイスで使用するための汎用ブートストラップアーキテクチャの適用」
20. Olaf Bergmann, Stefanie Gerdes, Carsten Bormann, "Simple Keys for Simple Smart Objects"
20. Olaf Bergmann、Stefanie Gerdes、Carsten Bormann、「シンプルスマートオブジェクトのシンプルキー」
21. Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Rissanen, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks"
21. Mohit Sethi、Jari Arkko、Ari Keranen、Heidi-Maria Rissanen、「スマートオブジェクトネットワークのセキュリティ保護における実際的な考慮事項と実装経験」
22. Paul Chilton, "Experiences and Challenges in using constrained Smart Objects"
22. ポールチルトン、「制約付きスマートオブジェクトの使用における経験と課題」
23. Vladislav Perelman, Mehmet Ersue, "TLS with PSK for Constrained Devices"
23. Vladislav Perelman、Mehmet Ersue、「制約付きデバイス用のPSKを使用したTLS」
24. Richard Barnes, "Security for Smart Objects beyond COMSEC: Principals and Principles"
24. Richard Barnes、「COMSECを超えたスマートオブジェクトのセキュリティ：プリンシパルとプリンシプル」
25. Rudolf van der Berg, "OECD Publication on Machine-to-Machine Communications: Connecting Billions of Devices", OECD Digital Economy Papers, No. 192, OECD Publishing
25. ルドルフファンデルベルク、「マシンツーマシン通信に関するOECD出版物：何十億ものデバイスを接続する」、OECDデジタルエコノミーペーパー、No。192、OECD出版社
26. Cullen Jennings, "Transitive Trust Enrollment for Constrained Devices"
26. カレン・ジェニングス、「制約付きデバイスの推移的信頼登録」
27. Barbara Fraser, Paul Duffy, Maik Seewald, "Smart Objects: Security Challenges from the Power Sector"
27. Barbara Fraser、Paul Duffy、Maik Seewald、「Smart Objects：Security Challenges from the Power Sector」
28. Hannes Tschofenig, "Smart Object Security: Considerations for Transport Layer Security Implementations"
28. Hannes Tschofenig、「スマートオブジェクトセキュリティ：トランスポート層セキュリティ実装に関する考慮事項」
29. Johannes Gilger, Ulrike Meyer, "Secure Pairing & Context Management"
29. Johannes Gilger、Ulrike Meyer、「Secure Pairing＆Context Management」
30. Klaas Wierenga, "Scalable Authentication for Smart Objects"
30. Klaas Wierenga、「スマートオブジェクトのスケーラブルな認証」
31. Dirk Stegemann, Jamshid Shokrollahi, "Security in the Internet of Things - Experiences from Use Cases"
31. Dirk Stegemann、Jamshid Shokrollahi、「モノのインターネットにおけるセキュリティ-ユースケースからの経験」
32. Alper Yegin, "Credentials for Smart Objects: A Challenge for the Industry"
32. Alper Yegin、「スマートオブジェクトの資格情報：業界への挑戦」
33. Shahid Raza, Thiemo Voigt, Vilhelm Jutvik, "Lightweight IKEv2: A Key Management Solution for both the Compressed IPsec and the IEEE 802.15.4 Security"
33. Shahid Raza、Thiemo Voigt、Vilhelm Jutvik、「軽量IKEv2：圧縮IPsecとIEEE 802.15.4セキュリティの両方のための鍵管理ソリューション」
34. Eric Rescorla, "A Brief Survey of Imprinting Options for Constrained Devices"
34. Eric Rescorla、「制約付きデバイスのインプリンティングオプションの簡単な調査」
35. Fred Baker, "Security in distributed telemetry and control networks"
35. Fred Baker、「分散型テレメトリおよび制御ネットワークのセキュリティ」
We would like to thank the following participants for attending the workshop:
ワークショップに参加していただいた以下の参加者に感謝いたします。
o Jari Arkko
o Carsten Bormann
o Cullen Jennings
o Antonio Skarmeta
o Sean Turner
o Thomas Heide Clausen
o Hannes Tschofenig
o Michael Richardson
o Yoshihiro Ohba
o Subir Das
o Randy Bush
o Andrei Gurtov
o Ilya Nikolaevsky
o Andrey Lukyanenko
o Jens-Matthias Bohli
o Kazunori Miyazawa
o Philip Ginzboorg
o Fida Khattak
o Angelo Castellani
o Salvatore Loreto
o Rene Hummen
o Klaus Wehrle
o Sam Hartman
o Margaret Wasserman
o Cary Bran
o Jan Janak
o Rene Struik
o Zhen Cao
o Hui Deng
o Zhou Sujing
o Xie Zhenhua
o Monique Morrow
o Nancy Cam-Winget
o Jouni Korhonen
o Ari Keranen
o Paul Chilton
o Vladislav Perelman
o Mehmet Ersue
o Richard Barnes
o Rudolf van der Berg
o Barbara Fraser
o Johannes Gilger
o Sye Loong Keoh
o Olaf Bergmann
o Stefanie Gerdes
o Klaus Hartke
o Oualha Nouha
o Alexis Olivereau
o Alper Yegin
o Klaas Wierenga
o Jiazi Yi
o Juan Antonio Cordero Fuertes
o Antonin Bas
o David Schinazi
o Valerie Lecomte
o Ulrich Herberg
o Shahid Raza
o Stephen Farrell
o Eric Rescorla
o Thomas Fossati
o Mohit Sethi
o Alan Duric
o Guido Moritz
o Sebstian Unger
o Hans Loehr
Acknowledgements
謝辞
We would like to thank the participants and the authors of the position papers for their input.
参加者とポジションペーパーの執筆者の意見に感謝します。
Special thanks go to Thomas Heide Clausen and Ecole Polytechnique (Paris) for providing the venue and organization.
会場と組織を提供してくれたThomas Heide ClausenとEcole Polytechnique（Paris）に特に感謝します。
Finally, we would like to thank Rudolf van der Berg for his review comments.
最後に、ルドルフファンデルベルクのレビューコメントに感謝します。
Authors' Addresses
著者のアドレス
Johannes Gilger Mies-van-der-Rohe-Str. 15 Aachen 52074 Germany
ヨハネスギルガーミースファンデルローエ通り15アーヘン52074ドイツ
Phone: +49 (0)241 80 20 781
EMail: Gilger@ITSec.RWTH-Aachen.de
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060オーストリア
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at