[要約] RFC 7744は、制約のある環境での認証と認可の使用例についてのガイドラインです。このRFCの目的は、制約のある環境でのセキュリティ要件を満たすための認証と認可の方法を提供することです。
Internet Engineering Task Force (IETF) L. Seitz, Ed.
Request for Comments: 7744 SICS Swedish ICT AB
Category: Informational S. Gerdes, Ed.
ISSN: 2070-1721 Universitaet Bremen TZI
G. Selander
Ericsson
M. Mani
Itron
S. Kumar
Philips Research
January 2016
Use Cases for Authentication and Authorization in Constrained Environments
制約された環境での認証と承認の使用例
Abstract
概要
Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.
制約付きデバイスは、処理能力、ストレージスペース、および伝送容量が制限されたノードです。多くの場合、これらのデバイスはユーザーインターフェイスを備えておらず、多くの場合、人間の介入なしに対話することを目的としています。
This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.
このドキュメントには、制限された環境での認証と承認の代表的な使用例のコレクションが含まれています。これらの使用例は、制約のあるデバイスのライフサイクル中に発生する承認の問題を特定することを目的としており、このクラスのシナリオの包括的な認証および承認ソリューションを開発するためのガイドラインを提供することを目的としています。
Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.
特定の詳細が関連する場合、デバイスは通信プロトコルとして制約付きアプリケーションプロトコル（CoAP）を使用すると想定されます。ただし、ほとんどの結論は一般的に適用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc7744.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7744で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Use Cases .......................................................5
2.1. Container Monitoring .......................................5
2.1.1. Bananas for Munich ..................................6
2.1.2. Authorization Problems Summary ......................7
2.2. Home Automation ............................................8
2.2.1. Controlling the Smart Home Infrastructure ...........8
2.2.2. Seamless Authorization ..............................8
2.2.3. Remotely Letting in a Visitor .......................9
2.2.4. Selling the House ...................................9
2.2.5. Authorization Problems Summary ......................9
2.3. Personal Health Monitoring ................................10
2.3.1. John and the Heart Rate Monitor ....................11
2.3.2. Authorization Problems Summary .....................12
2.4. Building Automation .......................................13
2.4.1. Device Life Cycle ..................................13
2.4.1.1. Installation and Commissioning ............13
2.4.1.2. Operational ...............................14
2.4.1.3. Maintenance ...............................15
2.4.1.4. Recommissioning ...........................16
2.4.1.5. Decommissioning ...........................16
2.4.2. Public Safety ......................................17
2.4.2.1. A Fire Breaks Out .........................17
2.4.3. Authorization Problems Summary .....................18
2.5. Smart Metering ............................................19
2.5.1. Drive-By Metering ..................................19
2.5.2. Meshed Topology ....................................20
2.5.3. Advanced Metering Infrastructure ...................20
2.5.4. Authorization Problems Summary .....................21
2.6. Sports and Entertainment ..................................22
2.6.1. Dynamically Connecting Smart Sports Equipment ......22
2.6.2. Authorization Problems Summary .....................23
2.7. Industrial Control Systems ................................23
2.7.1. Oil Platform Control ...............................23
2.7.2. Authorization Problems Summary .....................24
3. Security Considerations ........................................24
3.1. Attacks ...................................................25
3.2. Configuration of Access Permissions .......................26
3.3. Authorization Considerations ..............................26
3.4. Proxies ...................................................28
4. Privacy Considerations .........................................28
5. Informative References .........................................28
Acknowledgments ...................................................29
Authors' Addresses ................................................30
Constrained devices [RFC7228] are nodes with limited processing power, storage space, and transmission capacities. These devices are often battery-powered and in many cases do not provide user interfaces.
制約付きデバイス[RFC7228]は、処理能力、ストレージスペース、および伝送容量が制限されたノードです。これらのデバイスは、多くの場合、バッテリ駆動であり、多くの場合、ユーザーインターフェイスを備えていません。
Constrained devices benefit from being interconnected using Internet protocols. However, deploying common security protocols can sometimes be difficult because of device or network limitations. Regardless, adequate security mechanisms are required to protect these constrained devices, which are expected to be integrated in all aspects of everyday life, from attackers wishing to gain control over the device's data or functions.
制約のあるデバイスは、インターネットプロトコルを使用して相互接続することでメリットを得ます。ただし、デバイスまたはネットワークの制限により、一般的なセキュリティプロトコルの展開が困難な場合があります。とにかく、日常生活のあらゆる側面に統合されることが予想されるこれらの制約されたデバイスを、デバイスのデータまたは機能を制御したい攻撃者から保護するために、適切なセキュリティメカニズムが必要です。
This document comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device. Note that this document does not aim at collecting all possible use cases.
このドキュメントは、制限された環境での認証と承認のアプリケーションの代表的な使用事例の集まりで構成されています。これらの使用例は、制約されたデバイスのライフサイクル中に発生する認証の問題を特定することを目的としています。このドキュメントはすべての可能なユースケースを収集することを目的としないことに注意してください。
We assume that the communication between the devices is based on the Representational State Transfer (REST) architectural style, i.e., a device acts as a server that offers resources such as sensor data and actuators. The resources can be accessed by clients, sometimes without human intervention (M2M). In some situations, the communication will happen through intermediaries (e.g., gateways, proxies).
デバイス間の通信は、Representational State Transfer（REST）アーキテクチャスタイルに基づいていると想定しています。つまり、デバイスは、センサーデータやアクチュエータなどのリソースを提供するサーバーとして機能します。クライアントはリソースにアクセスできますが、人の介入は必要ありません（M2M）。状況によっては、通信は仲介者（ゲートウェイ、プロキシなど）を介して行われます。
Where specific detail is necessary, it is assumed that the devices communicate using CoAP [RFC7252], although most conclusions are generic.
特定の詳細が必要な場合、ほとんどの結論は一般的なものですが、デバイスはCoAP [RFC7252]を使用して通信すると想定されています。
Readers are required to be familiar with the terms defined in [RFC7228].
読者は、[RFC7228]で定義されている用語に精通している必要があります。
This section includes the use cases; each use case first presents a general description of the application environment, then one or more specific use cases, and finally a summary of the authorization-related problems to be solved. The document aims at listing the relevant authorization problems and not to provide an exhaustive list. It might not be possible to address all of the listed problems with a single solution; there might be conflicting goals within or among some requirements.
このセクションには、ユースケースが含まれています。各ユースケースでは、最初にアプリケーション環境の一般的な説明を示し、次に1つ以上の特定のユースケースを示し、最後に、解決する承認関連の問題の概要を示します。このドキュメントは、関連する承認の問題を一覧表示することを目的としており、完全なリストを提供することは目的としていません。リストされているすべての問題に単一のソリューションで対処することは不可能かもしれません。一部の要件内または要件間で競合する目標がある可能性があります。
There are various reasons for assigning a function (client or server) to a device. The function may even change over time; e.g., the device that initiates a conversation is temporarily assigned the role of client, but could act as a server in another context. The definition of the function of a device in a certain use case is not in scope of this document. Readers should be aware that there might be reasons for each setting and that endpoints might even have different functions at different times.
機能（クライアントまたはサーバー）をデバイスに割り当てるには、さまざまな理由があります。関数は時間の経過とともに変化する場合もあります。たとえば、会話を開始するデバイスには一時的にクライアントの役割が割り当てられますが、別のコンテキストではサーバーとして機能することもできます。特定のユースケースにおけるデバイスの機能の定義は、このドキュメントの範囲外です。読者は、各設定に理由がある可能性があること、およびエンドポイントが異なる時点で異なる機能を持っている可能性さえあることに注意する必要があります。
The ability of sensors to communicate environmental data wirelessly opens up new application areas. Sensor systems make it possible to continuously track and transmit characteristics such as temperature, humidity, and gas content while goods are transported and stored.
センサーが環境データをワイヤレスで通信する機能は、新しいアプリケーション領域を切り開きます。センサーシステムにより、商品の輸送および保管中に、温度、湿度、ガス含有量などの特性を継続的に追跡して送信できます。
Sensors in this scenario have to be associated with the appropriate pallet of the respective container. Sensors, as well as the goods, belong to specific customers.
このシナリオのセンサーは、それぞれのコンテナーの適切なパレットに関連付ける必要があります。センサーと商品は特定の顧客のものです。
While in transit, goods often pass stops where they are transloaded to other means of transportation, e.g., from ship transport to road transport.
輸送中、商品は多くの場合、ストップを通過し、そこで他の輸送手段（例：船輸送から道路輸送）に積み替えられます。
Perishable goods need to be stored at a constant temperature and with proper ventilation. Real-time information on the state of the goods is needed by both the transporter and the vendor. Transporters want to prioritize goods that will expire soon. Vendors want to react when goods are spoiled to continue to fulfill delivery obligations.
生鮮品は、一定の温度で適切な換気で保管する必要があります。商品の状態に関するリアルタイムの情報は、輸送業者とベンダーの両方に必要です。輸送業者は、すぐに期限が切れる商品に優先順位を付けたいと考えています。ベンダーは、商品が台無しになったら、配達義務を果たし続けるために対応したいと考えています。
The Intelligent Container <http://www.intelligentcontainer.com> is an example project that explores solutions to continuously monitor perishable goods.
Intelligent Container <http://www.intelligentcontainer.com>は、生鮮食品を継続的に監視するためのソリューションを模索するサンプルプロジェクトです。
A fruit vendor grows bananas in Costa Rica for the German market. It instructs a transport company to deliver the goods via ship to Rotterdam where they are picked up by trucks and transported to a ripening facility. A Munich supermarket chain buys ripened bananas from the fruit vendor and transports them from the ripening facility to the individual markets with their own company's trucks.
果物の売り手がコスタリカでドイツ市場向けにバナナを栽培しています。それは輸送会社に、商品を船でロッテルダムに配達するように指示します。そこでロッテルダムはそれらをトラックでピックアップし、熟成施設に輸送します。ミュンヘンのスーパーマーケットチェーンは、果物のベンダーから熟成バナナを購入し、それらを熟成施設から自社のトラックで個々の市場に輸送します。
The fruit vendor's quality management wants to assure the quality of their products; thus, it equips the banana boxes with sensors. The state of the goods is monitored consistently during shipment and ripening, and abnormal sensor values are recorded (U1.2). Additionally, the sensor values are used to control the climate within the cargo containers (U1.1, U1.5, U1.7). Therefore, the sensors need to communicate with the climate-control system. Since an incorrect sensor value leads to a wrong temperature, and thus to spoiled goods, the integrity of the sensor data must be assured (U1.2, U1.3). The banana boxes within a container will, in most cases, belong to the same owner. Adjacent containers might contain goods and sensors of different owners (U1.1).
果物のベンダーの品質管理は、自社の製品の品質を保証したいと考えています。したがって、バナナボックスにセンサーを装備しています。商品の状態は出荷中および熟成中に一貫して監視され、異常なセンサー値が記録されます（U1.2）。さらに、センサー値は、貨物コンテナー内の気候を制御するために使用されます（U1.1、U1.5、U1.7）。したがって、センサーは空調システムと通信する必要があります。誤ったセンサー値は誤った温度につながり、その結果商品が台無しになるため、センサーデータの完全性を保証する必要があります（U1.2、U1.3）。コンテナ内のバナナボックスは、ほとんどの場合、同じ所有者に属します。隣接するコンテナには、異なる所有者の商品とセンサーが含まれている場合があります（U1.1）。
The personnel that transloads the goods must be able to locate the goods meant for a specific customer (U1.1, U1.6, U1.7). However, the fruit vendor does not want to disclose sensor information pertaining to the condition of the goods to other companies and therefore wants to assure the confidentiality of this data (U1.4). Thus, the transloading personnel is only allowed to access logistic information (U1.1). Moreover, the transloading personnel is only allowed to access the data for the time of the transloading (U1.8).
商品を積み込む担当者は、特定の顧客向けの商品（U1.1、U1.6、U1.7）を見つけられる必要があります。ただし、果物のベンダーは、商品の状態に関するセンサー情報を他の会社に開示することを望まないため、このデータの機密性を保証したいと考えています（U1.4）。したがって、トランスローディング担当者はロジスティック情報（U1.1）にのみアクセスできます。さらに、トランスローディング担当者は、トランスローディング時（U1.8）のデータにのみアクセスできます。
Due to the high water content of the fruits, the propagation of radio waves is hindered, thus often inhibiting direct communication between nodes [Jedermann14]. Instead, messages are forwarded over multiple hops (U1.9). The sensors in the banana boxes cannot always reach the Internet during the journey (U1.10). Sensors may need to use relay stations owned by the transport company to connect to endpoints on the Internet.
果物には水分が多く含まれているため、電波の伝播が妨げられ、ノード間の直接通信が妨げられることがよくあります[Jedermann14]。代わりに、メッセージは複数のホップを介して転送されます（U1.9）。旅行中、バナナボックス内のセンサーが常にインターネットに到達できるわけではありません（U1.10）。センサーは、インターネット上のエンドポイントに接続するために、運送会社が所有するリレーステーションを使用する必要がある場合があります。
In the ripening facility bananas are stored until they are ready to be sold. The banana box sensors are used to control the ventilation system and to monitor the degree of ripeness of the bananas. Ripe bananas need to be identified and sold before they spoil (U1.2, U1.8).
熟成施設では、販売の準備ができるまでバナナを保管しています。バナナボックスセンサーは、換気システムを制御し、バナナの熟度を監視するために使用されます。熟したバナナは、腐敗する前に識別して販売する必要があります（U1.2、U1.8）。
The supermarket chain gains ownership of the banana boxes when the bananas have ripened and are ready to leave the ripening facility.
スーパーマーケットチェーンは、バナナが熟し、熟成施設を離れる準備ができると、バナナボックスの所有権を獲得します。
U1.1: Fruit vendors and container owners want to grant different authorizations for their resources and/or endpoints to different parties.
U1.1：果物のベンダーとコンテナの所有者は、さまざまな関係者に、リソースやエンドポイントのさまざまな承認を付与したいと考えています。
U1.2: The fruit vendor requires the integrity and authenticity of the sensor data that pertains to the state of the goods for climate control and to ensure the quality of the monitored recordings.
U1.2：果物のベンダーは、気候制御のために商品の状態に関連するセンサーデータの整合性と信頼性を求め、監視された記録の品質を確保する必要があります。
U1.3: The container owner requires the integrity and authenticity of the sensor data that is used for climate control.
U1.3：コンテナの所有者は、気候制御に使用されるセンサーデータの完全性と信頼性を要求します。
U1.4: The fruit vendor requires the confidentiality of the sensor data that pertains the state of the goods and the confidentiality of location data, e.g., to protect them from targeted attacks from competitors.
U1.4：果物のベンダーは、商品の状態に関連するセンサーデータの機密性と、たとえば競合他社からの標的型攻撃から保護するために、位置データの機密性を要求します。
U1.5: The fruit vendor may need different protection for several different types of data on the same endpoint, e.g., sensor data and the data used for logistics.
U1.5：フルーツベンダーは、同じエンドポイント上のいくつかの異なるタイプのデータ（センサーデータやロジスティクスに使用されるデータなど）に対して異なる保護を必要とする場合があります。
U1.6: The fruit vendor and the transloading personnel require the authenticity and integrity of the data that is used to locate the goods, in order to ensure that the goods are correctly treated and delivered.
U1.6：果物のベンダーと積み替え担当者は、商品が正しく処理されて配送されることを保証するために、商品の場所を特定するために使用されるデータの信頼性と完全性を要求します。
U1.7: The container owner and the fruit vendor may not be present at the time of access and cannot manually intervene in the authorization process.
U1.7：コンテナーの所有者とフルーツベンダーは、アクセス時に不在であり、承認プロセスに手動で介入することはできません。
U1.8: The fruit vendor, container owner, and transloading company want to grant temporary access permissions to a party, in order to avoid giving permanent access to parties that are no longer involved in processing the bananas.
U1.8：フルーツベンダー、コンテナーの所有者、およびトランスローディング会社は、バナナの処理に関与していないパーティーに永続的なアクセス権を与えないようにするために、パーティーに一時的なアクセス許可を与えたいと考えています。
U1.9: The fruit vendor, container owner, and transloading company want their security objectives to be achieved, even if the messages between the endpoints need to be forwarded over multiple hops.
U1.9：エンドポイント間のメッセージを複数のホップで転送する必要がある場合でも、フルーツベンダー、コンテナー所有者、およびトランスローディング会社は、セキュリティ目標の達成を望んでいます。
U1.10: The constrained devices might not always be able to reach the Internet but still need to enact the authorization policies of their principals.
U1.10：制約されたデバイスは、常にインターネットにアクセスできるわけではないかもしれませんが、プリンシパルの承認ポリシーを制定する必要があります。
U1.11: Fruit vendors and container owners want to be able to revoke authorization on a malfunctioning sensor.
U1.11：果物のベンダーとコンテナの所有者は、誤動作しているセンサーの認証を取り消すことができることを望んでいます。
One application of the Internet of Things is home automation systems. Such a system can connect household devices that control, for example, heating, ventilation, lighting, home entertainment, and home security to the Internet making them remotely accessible and manageable.
モノのインターネットの1つのアプリケーションは、ホームオートメーションシステムです。このようなシステムは、暖房、換気、照明、ホームエンターテイメント、ホームセキュリティなどを制御する家庭用デバイスをインターネットに接続して、リモートでアクセスおよび管理できるようにします。
Such a system needs to accommodate a number of regular users (inhabitants, close friends, cleaning personnel) as well as a heterogeneous group of dynamically varying users (visitors, repairmen, delivery men).
このようなシステムは、多数の一般ユーザー（住民、親しい友人、清掃員）と、動的に変化するユーザー（訪問者、修理工、配達員）の異種グループに対応する必要があります。
As the users are not typically trained in security (or even computer use), the configuration must use secure default settings, and the interface must be well adapted to novice users.
ユーザーは通常セキュリティ（またはコンピューターの使用）のトレーニングを受けていないため、構成は安全な既定の設定を使用する必要があり、インターフェイスは初心者のユーザーにうまく適合させる必要があります。
Alice and Bob own a flat that is equipped with home automation devices such as HVAC and shutter control, and they have a motion sensor in the corridor that controls the light bulbs there (U2.5).
アリスとボブは、HVACやシャッターコントロールなどのホームオートメーションデバイスを備えたフラットを所有しており、廊下にモーションセンサーがあり、そこで電球を制御しています（U2.5）。
Alice and Bob can control the shutters and the temperature in each room using either wall-mounted touch panels or an Internet connected device (e.g., a smartphone). Since Alice and Bob both have full-time jobs, they want to be able to change settings remotely, e.g., turn up the heating on a cold day if they will be home earlier than expected (U2.5).
アリスとボブは、壁に取り付けられたタッチパネルまたはインターネットに接続されたデバイス（スマートフォンなど）を使用して、各部屋のシャッターと温度を制御できます。アリスとボブは両方ともフルタイムの仕事をしているので、リモートで設定を変更できるようにしたいと考えています。たとえば、寒い日に暖房が予想よりも早く家に帰る場合（U2.5）は暖房をオンにします。
The couple does not want people in radio range of their devices, e.g., their neighbors, to be able to control them without authorization. Moreover, they don't want burglars to be able to deduce behavioral patterns from eavesdropping on the network (U2.8).
夫婦は、デバイスの無線範囲内にいる人、たとえば隣人が許可なしにデバイスを制御できることを望んでいません。さらに、彼らは強盗がネットワーク上の盗聴から行動パターンを推測できるようにしたくありません（U2.8）。
Alice buys a new light bulb for the corridor and integrates it into the home network, i.e., makes resources known to other devices in the network. Alice makes sure that the new light bulb and her other devices in the network get to know the authorization policies for the new device. Bob is not at home, but Alice wants him to be able to control the new device with his devices (e.g., his smartphone) without the need for additional administration effort (U2.7). She provides the necessary configurations for that (U2.9, U2.10).
アリスは廊下用に新しい電球を購入し、それをホームネットワークに統合します。つまり、ネットワーク内の他のデバイスにリソースを知らせます。アリスは、新しい電球とネットワーク内の他のデバイスが新しいデバイスの認証ポリシーを確実に認識できるようにします。ボブは不在ですが、アリスは追加の管理作業（U2.7）を必要とせずに自分のデバイス（スマートフォンなど）で新しいデバイスを制御できるようにしたいと考えています。彼女はそれに必要な構成を提供します（U2.9、U2.10）。
Alice and Bob have equipped their home with automated connected door-locks and an alarm system at the door and the windows. The couple can control this system remotely.
アリスとボブは家に自動接続されたドアロックとドアと窓に警報システムを装備しました。カップルはこのシステムをリモートで制御できます。
Alice and Bob have invited Alice's parents over for dinner, but are stuck in traffic and cannot arrive in time; whereas Alice's parents are using the subway and will arrive punctually. Alice calls her parents and offers to let them in remotely, so they can make themselves comfortable while waiting (U2.1, U2.6). Then, Alice sets temporary permissions that allow them to open the door and shut down the alarm (U2.2). She wants these permissions to be only valid for the evening since she does not like it if her parents are able to enter the house as they see fit (U2.3, U2.4).
アリスとボブは夕食のためにアリスの両親を招待しましたが、交通渋滞のため、間に合うように到着できません。一方、アリスの両親は地下鉄を利用しており、時間通りに到着します。アリスは彼女の両親に電話し、リモートでそれらを入れることを申し出るので、彼らは待っている間彼ら自身を快適にすることができます（U2.1、U2.6）。次に、アリスは一時的な許可を設定して、ドアを開いてアラームをシャットダウンできるようにします（U2.2）。彼女は、両親が家に入ることができるように家に入ることができる場合（U2.3、U2.4）は好きではないため、これらの権限が夜のみ有効であることを望んでいます。
When Alice's parents arrive at Alice and Bob's home, they use their smartphone to communicate with the door-lock and alarm system (U2.5, U2.9). The permissions Alice issued to her parents only allow limited access to the house (e.g., opening the door, turning on the lights). Certain other functions, such as checking the footage from the surveillance cameras, are not accessible to them (U2.3).
アリスの両親がアリスとボブの家に到着すると、彼らはスマートフォンを使用してドアロックおよび警報システム（U2.5、U2.9）と通信します。アリスが両親に発行した許可は、家への限られたアクセスのみを許可します（例：ドアを開く、照明をつける）。監視カメラからの映像の確認など、他の特定の機能にはアクセスできません（U2.3）。
Alice and Bob also issue similarly restricted permissions to e.g., cleaners, repairmen, or their nanny (U2.3).
アリスとボブは、同様に制限された許可を、例えば、掃除人、修理工、またはそれらの乳母に発行します（U2.3）。
Alice and Bob have to move because Alice is starting a new job. They therefore decide to sell the house and transfer control of all automated services to the new owners (U2.11). Before doing so, they want to erase privacy-relevant data from the logs of the automated systems, while the new owner is interested to keep some historic data e.g., pertaining to the behavior of the heating system (U2.12). At the time of transfer of ownership of the house, the new owners also want to make sure that permissions issued by the previous owners to access the house or connected devices (in the case where device management may have separate permissions from house access) are no longer valid (U2.13).
アリスが新しい仕事を始めているので、アリスとボブは移動しなければなりません。したがって、彼らは家を売却し、すべての自動化サービスの制御を新しい所有者に譲渡することを決定します（U2.11）。その前に、自動化システムのログからプライバシー関連のデータを消去したいと考えていますが、新しい所有者は、たとえば暖房システムの動作に関連するいくつかの履歴データを保持することに関心があります（U2.12）。家の所有権の譲渡時に、新しい所有者は前の所有者が発行した家または接続されたデバイスへのアクセス許可（デバイス管理に家のアクセスとは別のアクセス許可がある場合）が許可されていないことも確認する必要があります有効期間が長くなりました（U2.13）。
U2.1: A home owner (Alice and Bob in the example above) wants to spontaneously provision authorization means to visitors.
U2.1：住宅所有者（上記の例ではアリスとボブ）は、訪問者に承認手段を自発的に提供したいと考えています。
U2.2: A home owner wants to spontaneously change the home's access control policies.
U2.2：住宅所有者は、住宅のアクセス制御ポリシーを自発的に変更したいと考えています。
U2.3: A home owner wants to apply different access rights for different users (including other inhabitants).
U2.3：住宅所有者は、異なるユーザー（他の住民を含む）に異なるアクセス権を適用したいと考えています。
U2.4: The home owners want to grant access permissions to someone during a specified time frame.
U2.4：住宅所有者は、指定された時間枠の間に誰かにアクセス許可を与えたいと考えています。
U2.5: The smart home devices need to be able to securely communicate with different control devices (e.g., wall-mounted touch panels, smartphones, electronic key fobs, and device gateways).
U2.5：スマートホームデバイスは、さまざまな制御デバイス（壁に取り付けられたタッチパネル、スマートフォン、電子キーフォブ、デバイスゲートウェイなど）と安全に通信できる必要があります。
U2.6: The home owner wants to be able to configure authorization policies remotely.
U2.6：住宅所有者は、承認ポリシーをリモートで構成できるようにしたいと考えています。
U2.7: Authorized users want to be able to obtain access with little effort.
U2.7：許可されたユーザーは、少しの労力でアクセス権を取得できることを望んでいます。
U2.8: The owners of the automated home want to prevent unauthorized entities from being able to deduce behavioral profiles from devices in the home network.
U2.8：自動化された家の所有者は、許可されていないエンティティがホームネットワーク内のデバイスから行動プロファイルを推測できないようにする必要があります。
U2.9: Usability is particularly important in this scenario since the necessary authorization related tasks in the life cycle of the device (commissioning, operation, maintenance, and decommissioning) likely need to be performed by the home owners who, in most cases, have little knowledge of security.
U2.9：デバイスのライフサイクルで必要な許可関連のタスク（試運転、操作、保守、および廃止）は、ほとんどの場合、セキュリティに関する知識がほとんどない。
U2.10: Home owners want their devices to seamlessly (and in some cases even unnoticeably) fulfill their purpose. Therefore, the authorization administration effort needs to be kept at a minimum.
U2.10：家の所有者は、デバイスがシームレスに（場合によっては目立たないように）目的を果たすことを望んでいます。したがって、許可管理の労力を最小限に抑える必要があります。
U2.11: Home owners want to be able to transfer ownership of their automated systems when they sell the house.
U2.11：家の所有者は、家を売るときに自動システムの所有権を譲渡できるようにしたいと考えています。
U2.12: Home owners want to be able to sanitize the logs of the automated systems when transferring ownership without deleting important operational data.
U2.12：住宅所有者は、重要な運用データを削除せずに所有権を譲渡するときに、自動システムのログをサニタイズできることを望んでいます。
U2.13: When a transfer of ownership occurs, the new owner wants to make sure that access rights created by the previous owner are no longer valid.
U2.13：所有権の譲渡が発生した場合、新しい所有者は、前の所有者によって作成されたアクセス権が無効であることを確認する必要があります。
Personal health monitoring devices, i.e., eHealth devices, are typically battery-driven and located physically on or in the user to monitor some bodily function, such as temperature, blood pressure, or pulse rate. These devices typically connect to the Internet through an intermediary base station, using wireless technologies and through this connection they report the monitored data to some entity, which may either be the user or a medical caregiver.
パーソナルヘルスモニタリングデバイス、つまりeHealthデバイスは通常、バッテリー駆動であり、体温または血圧、脈拍数などの身体機能をモニタリングするために、ユーザーの身体上またはユーザー内に物理的に配置されます。これらのデバイスは通常、無線技術を使用して中間基地局を介してインターネットに接続し、この接続を介して、ユーザーまたは医療介護者のいずれかである監視対象のデータを何らかのエンティティに報告します。
Medical data has always been considered very sensitive, and therefore requires good protection against unauthorized disclosure. A frequent, conflicting requirement is the capability for medical personnel to gain emergency access, even if no specific access rights exist. As a result, the importance of secure audit logs increases in such scenarios.
医療データは常に非常に機密性が高いと見なされているため、不正な開示からの適切な保護が必要です。頻繁に競合する要件は、特定のアクセス権が存在しない場合でも、医療関係者が緊急アクセスを取得する機能です。その結果、このようなシナリオでは、安全な監査ログの重要性が高まります。
Since the users are not typically trained in security (or even computer use), the configuration must use secure default settings, and the interface must be well adapted to novice users. Parts of the system must operate with minimal maintenance. Especially frequent changes of battery are unacceptable.
ユーザーは通常セキュリティ（またはコンピューターの使用）のトレーニングを受けていないため、構成は安全な既定の設定を使用する必要があり、インターフェイスは初心者ユーザーに適切に適合させる必要があります。システムの一部は、最小限のメンテナンスで動作する必要があります。特にバッテリーの頻繁な交換は許容できません。
There is a plethora of wearable health monitoring technology and the need for open industry standards to ensure interoperability between products has lead to initiatives such as Continua Alliance <http://continuaalliance.org> and Personal Connected Health Alliance <http://www.pchalliance.org>.
多数のウェアラブルヘルスモニタリングテクノロジーがあり、製品間の相互運用性を確保するためのオープンな業界標準の必要性により、Continua Alliance <http://continuaalliance.org>やPersonal Connected Health Alliance <http：// www。 pchalliance.org>。
John has a heart condition that can result in sudden cardiac arrests. He therefore uses a device called "HeartGuard" that monitors his heart rate and his location (U3.7). In the event of a cardiac arrest, it automatically sends an alarm to an emergency service, transmitting John's current location (U3.1). Either the device has long-range connectivity itself (e.g., via GSM) or it uses some intermediary, nearby device (e.g., John's smartphone) to transmit such an alarm. To ensure John's safety, the device is expected to be in constant operation (U3.3, U3.6).
ジョンには心臓病があり、突然の心停止を引き起こす可能性があります。したがって、彼は心拍数と位置を監視する「ハートガード」と呼ばれるデバイスを使用しています（U3.7）。心停止の場合、それは自動的に警報を緊急サービスに送信し、ジョンの現在の位置を送信します（U3.1）。デバイス自体が（GSMなどを介して）長距離接続を備えているか、中間の近くのデバイス（Johnのスマートフォンなど）を使用してこのようなアラームを送信しています。ジョンの安全を確保するために、デバイスは常に動作している必要があります（U3.3、U3.6）。
The device includes an authentication mechanism to prevent other persons who get physical access to it from acting as the owner and altering the access control and security settings (U3.8).
デバイスには、デバイスに物理的にアクセスする他の人が所有者として機能し、アクセス制御とセキュリティ設定を変更することを防ぐ認証メカニズムが含まれています（U3.8）。
John can configure a list of people that get notified in an emergency, for example his daughter Jill. Furthermore, the device stores data on John's heart rate, which can later be accessed by a physician to assess the condition of John's heart (U3.2).
ジョンは、娘のジルなど、緊急時に通知を受ける人のリストを設定できます。さらに、このデバイスにはジョンの心拍数に関するデータが保存されており、医師はこのデータにアクセスしてジョンの心臓の状態を評価できます（U3.2）。
However, John is a privacy-conscious person and is worried that Jill might use HeartGuard to monitor his location even when there is no emergency. Furthermore, he doesn't want his health insurance to get access to the HeartGuard data, or even to the fact that he is wearing a HeartGuard, since they might refuse to renew his insurance if they decided he was too great of a risk for them (U3.8).
しかし、ジョンはプライバシーを重視する人物であり、緊急事態が発生していなくても、ジルがハートガードを使用して自分の位置を監視するのではないかと心配しています。さらに、彼は自分の健康保険がHeartGuardデータにアクセスすることを望んでいない、または彼がHeartGuardを身に付けているという事実にさえ、彼らが彼らにとってリスクが大きすぎると彼らが彼の保険を更新することを拒否するかもしれないのでさえ、望んでいない（U3.8）。
Finally, John, while being comfortable with modern technology and able to operate it reasonably well, is not trained in computer security. Therefore, he needs an interface for the configuration of the HeartGuard security that is easy to understand and use (U3.5). If John does not understand the meaning of a setting, he tends to leave it alone, assuming that the manufacturer has initialized the device to secure settings (U3.4).
最後に、ジョンは最新のテクノロジーに慣れていて、それを適切に操作することができますが、コンピュータセキュリティのトレーニングを受けていません。したがって、彼には、理解しやすく使いやすいハートガードセキュリティの構成用のインターフェイスが必要です（U3.5）。 Johnが設定の意味を理解していない場合、製造元がデバイスを初期化して設定を保護する（U3.4）と仮定して、設定をそのままにする傾向があります。
Note: Monitoring of some state parameter (e.g., an alarm button) and the position of a person also fits well into a nursing service context. This is particularly useful for people suffering from dementia, where the relatives or caregivers need to be notified of the whereabouts of the person under certain conditions. In that case, it is not the patient that decides about access.
注：いくつかの状態パラメーター（例えば、アラームボタン）と人の位置の監視も、看護サービスのコンテキストによく適合します。これは、特定の状況下で親族や介護者にその人の居場所を通知する必要がある、認知症に苦しんでいる人にとって特に役立ちます。その場合、アクセスについて決定するのは患者ではありません。
U3.1: The wearer of an eHealth device (John in the example above) wants to preconfigure special access rights in the context of an emergency.
U3.1：eHealthデバイスの着用者（上記の例ではJohn）は、緊急時に特別なアクセス権を事前設定したいと考えています。
U3.2: The wearer of an eHealth device wants to selectively allow different persons or groups access to medical data.
U3.2：eHealthデバイスの装着者は、さまざまな個人またはグループが医療データに選択的にアクセスできるようにしたいと考えています。
U3.3: Battery changes are very inconvenient and sometimes impractical, so battery life impacts on the authorization mechanisms need to be minimized.
U3.3：電池交換は非常に不便であり、実際的でない場合があるため、認証メカニズムへの電池寿命の影響を最小限に抑える必要があります。
U3.4: Devices are often used with default access control settings that might threaten the security objectives of the device's users.
U3.4：デバイスは、多くの場合、デバイスのユーザーのセキュリティ対策方針を脅かす可能性のあるデフォルトのアクセス制御設定で使用されます。
U3.5: Wearers of eHealth devices are often not trained in computer use, especially computer security.
U3.5：eHealthデバイスの装着者は、コンピューターの使用、特にコンピューターのセキュリティに関するトレーニングを受けていないことがよくあります。
U3.6: Security mechanisms themselves could provide opportunities for denial-of-service (DoS) attacks, especially on the constrained devices.
U3.6：特に制限されたデバイスでは、セキュリティメカニズム自体がサービス拒否（DoS）攻撃の機会を提供する可能性があります。
U3.7: The device provides a service that can be fatal for the wearer if it fails. Accordingly, the wearer wants the device to have a high degree of resistance against attacks that may cause the device to fail to operate partially or completely.
U3.7：このデバイスは、故障した場合に着用者にとって致命的なサービスを提供します。したがって、着用者は、デバイスが部分的または完全に動作しなくなる可能性のある攻撃に対してデバイスが高度な耐性を持つことを望んでいる。
U3.8: The wearer of an eHealth device requires the integrity and confidentiality of the data measured by the device.
U3.8：eHealthデバイスの装着者は、デバイスによって測定されたデータの完全性と機密性を要求します。
Buildings for commercial use such as shopping malls or office buildings nowadays are equipped increasingly with semi-automatic components to enhance the overall living quality and to save energy where possible. This includes for example heating, ventilation and air condition (HVAC) as well as illumination and security systems such as fire alarms. These components are being increasingly managed centrally in a Building and Lighting Management System (BLMS) by a facility manager.
現在、ショッピングモールやオフィスビルなどの商業用の建物には、全体的な生活の質を高め、可能な場合はエネルギーを節約するための半自動コンポーネントがますます装備されています。これには、たとえば、暖房、換気、および空調（HVAC）、および火災警報器などの照明およびセキュリティシステムが含まれます。これらのコンポーネントは、施設管理者によってビルディングおよび照明管理システム（BLMS）で一元的に管理されるようになっています。
Different areas of these buildings are often exclusively leased to different companies. However, they also share some of the common areas of the building. Accordingly, a company must be able to control the lighting and HVAC system of its own part of the building and must not have access to control rooms that belong to other companies.
これらの建物のさまざまなエリアは、多くの場合、さまざまな企業に独占的にリースされています。ただし、建物の共通領域の一部も共有しています。したがって、企業は建物の一部の照明とHVACシステムを制御できなければならず、他の企業に属する制御室にアクセスできないようにする必要があります。
Some parts of the building automation system such as entrance illumination and fire-alarm systems are controlled either by all parties together or by a facility-management company.
エントランスイルミネーションや火災警報システムなどのビルディングオートメーションシステムの一部は、すべての関係者によって、または施設管理会社によって制御されます。
Installation of the building automation components often start even before the construction work is completed. Lighting is one of the first components to be installed in new buildings. A lighting plan created by a lighting designer provides the necessary information related to the kind of lighting devices (luminaires, sensors, and switches) to be installed along with their expected behavior. The physical installation of the correct lighting devices at the right locations are done by electricians based on the lighting plan. They ensure that the electrical wiring is performed according to local regulations and lighting devices, which may be from multiple manufacturers, are connected to the electrical power supply properly. After the installation, lighting can be used in a default out-of-box mode, e.g., at full brightness when powered on. After this step (or in parallel in a different section of the building), a lighting commissioner adds the devices to the building domain (U4.1) and performs the proper configuration of the lights as prescribed in the lighting plan. This involves, for example, grouping to ensure that light points react together, more or less synchronously (U4.8) and defining lighting scenes for particular areas of the building. The commissioning is often done in phases, either by one or more commissioners, on different floors. The building lighting network at this stage may be in different network islands with no connectivity between them due to lack of the IT infrastructure.
多くの場合、ビルディングオートメーションコンポーネントのインストールは、建設作業が完了する前でも開始されます。照明は新しい建物に設置される最初のコンポーネントの1つです。照明デザイナーが作成した照明計画は、設置する照明装置（照明器具、センサー、スイッチ）の種類に関連する必要な情報と、それらの予想される動作を提供します。適切な場所への適切な照明デバイスの物理的な設置は、照明計画に基づいて電気技師が行います。彼らは、電気配線が地域の規制に従って行われることを保証し、複数の製造元からの照明デバイスが電源に正しく接続されていることを確認します。インストール後、照明はデフォルトのアウトオブボックスモードで使用できます。たとえば、電源を入れたときに最大の明るさで使用できます。このステップの後（または建物の別のセクションで並行して）、照明コミッショナーはデバイスを建物ドメイン（U4.1）に追加し、照明計画で規定されているように適切な照明の構成を実行します。これには、たとえば、光点がほぼ同時に反応するようにグループ化すること（U4.8）と、建物の特定の領域の照明シーンを定義することが含まれます。コミッショニングは、多くの場合、1人または複数のコミッショナーによって、異なるフロアで段階的に行われます。この段階の建物の照明ネットワークは、ITインフラストラクチャが不足しているため、異なるネットワークアイランドにあり、それらの間に接続がない可能性があります。
After this, other building components, like HVAC and security systems, are similarly installed by electricians and later commissioned by their respective domain professionals. Similar configurations related to grouping (U4.8) are required to ensure, e.g., HVAC equipment is controlled by the closest temperature sensor.
この後、HVACやセキュリティシステムなどの他の建築コンポーネントも同様に電気技師によって設置され、後でそれぞれの専門家によって委託されます。グループ化（U4.8）に関連する同様の構成は、たとえばHVAC機器が最も近い温度センサーによって制御されるようにするために必要です。
For the building IT systems, the Ethernet wiring is initially laid out in the building according to the IT plan. The IT network is often commissioned after the construction is completed to avoid any damage to sensitive networking and computing equipment. The commissioning is performed by an IT engineer with additional switches (wired and/or wireless), IP routers, and computing devices. Direct Internet connectivity for all installed/commissioned devices in the building is only available at this point. The BLMS that monitors and controls the various building automation components is only connected to the field devices at this stage. The different network islands (for lighting and HVAC) are also joined together without any further involvement of domain specialists, such as lighting or HVAC commissioners.
建物のITシステムでは、最初にイーサネット配線がIT計画に従って建物内に配置されます。機密性の高いネットワーキングおよびコンピューティング機器への損傷を回避するために、ITネットワークは建設が完了した後に委託されることがよくあります。試運転は、追加のスイッチ（有線または無線、あるいはその両方）、IPルーター、およびコンピューティングデバイスを備えたITエンジニアによって実行されます。建物内に設置されているすべてのデバイスの直接インターネット接続は、この時点でのみ使用できます。さまざまなビルディングオートメーションコンポーネントを監視および制御するBLMSは、この段階ではフィールドデバイスにのみ接続されています。照明やHVACのコミッショナーなどのドメインスペシャリストが関与することなく、さまざまなネットワークアイランド（照明とHVAC用）も結合されます。
The building automation system is now finally ready, and the operational access is transferred to the facility management company of the building (U4.2). The facility manager is responsible for monitoring and ensuring that the building automation system meets the needs of the building occupants. If changes are needed, the facility-management company hires an external installation and commissioning company to perform the changes.
これでビルディングオートメーションシステムの準備が整い、運用アクセスがビルディングの施設管理会社に転送されます（U4.2）。施設管理者は、ビルディングオートメーションシステムが建物の居住者のニーズを満たしていることを監視および保証する責任があります。変更が必要な場合、施設管理会社は、外部の設置および委託会社に雇用して、変更を実行します。
Different parts of the building are rented out to different companies for office space. The tenants are provided access to use the automated HVAC, lighting, and physical access control systems deployed. The safety of the occupants is also managed using automated systems, such as a fire-alarm system, which is triggered by several smoke detectors that are spread out across the building.
建物のさまざまな部分は、オフィススペースのためにさまざまな会社に貸し出されています。テナントには、展開された自動HVAC、照明、および物理的アクセス制御システムを使用するためのアクセスが提供されます。居住者の安全は、火災警報システムなどの自動システムを使用して管理されます。これは、建物全体に散らばっているいくつかの煙探知器によってトリガーされます。
Company A's staff moves into the newly furnished office space. Most lighting is controlled by presence sensors that control the lighting of a specific group of lights based on the authorization rules in the BLMS. Additionally, employees are allowed to manually override the lighting brightness and color in their offices by using the switches or handheld controllers. Such changes are allowed only if the authorization rules exist in the BLMS. For example, lighting in the corridors may not be manually adjustable.
A社のスタッフが、新しく家具を配置したオフィススペースに移動します。ほとんどの照明は、BLMSの承認規則に基づいて特定のグループの照明を制御する存在センサーによって制御されます。さらに、従業員は、スイッチまたはハンドヘルドコントローラーを使用して、オフィスの照明の明るさと色を手動で上書きできます。このような変更は、BLMSに承認規則が存在する場合にのみ許可されます。たとえば、廊下の照明は手動で調整できない場合があります。
At the end of the day, lighting is dimmed or switched off if no occupancy is detected, even if manually overridden during the day.
1日の終わりに手動でオーバーライドされたとしても、1日の終わりに、占有が検出されない場合、照明は淡色表示またはオフになります。
On a later date, Company B also moves into the same building, and shares some of the common spaces and associated building automation components with Company A (U4.2, U4.9).
後日、B社も同じ建物に移動し、A社（U4.2、U4.9）といくつかの共通スペースおよび関連するビルディングオートメーションコンポーネントを共有します。
Company A's staff is annoyed that the lighting switches off too often in their rooms if they work silently in front of their computers. Company A notifies the facility manager of the building to increase the delay before lights switch off. The facility manager can either configure the new values directly in the BLMS or, if additional changes are needed on the field devices, hire commissioning Company C to perform the needed changes (U4.4).
A社のスタッフは、コンピューターの前で静かに作業していると、部屋の照明が頻繁にオフになることに不満を感じています。 A社は、ライトをオフにするまでの遅延を増やすように、建物の施設管理者に通知します。施設管理者は、BLMSで新しい値を直接構成するか、フィールドデバイスで追加の変更が必要な場合は、C社に依頼して必要な変更を実行することができます（U4.4）。
Company C gets the necessary authorization from the facility-management company to interact with the BLMS. The commissioner's tool gets the necessary authorization from the BLMS to send a configuration change to all lighting devices in Company A's offices to increase the delay before they switch off.
会社Cは、施設管理会社からBLMSと対話するために必要な許可を取得します。コミッショナーのツールは、BLMSから必要な許可を得て、A社のオフィスにあるすべての照明デバイスに構成変更を送信して、スイッチがオフになるまでの遅延を増やします。
At some point, the facility-management company wants to update the firmware of lighting devices in order to eliminate software bugs. Before accepting the new firmware, each device checks the authorization of the facility-management company to perform this update (U4.13).
ある時点で、施設管理会社は、ソフトウェアのバグをなくすために照明装置のファームウェアを更新したいと考えています。新しいファームウェアを受け入れる前に、各デバイスは施設管理会社の承認を確認して、この更新を実行します（U4.13）。
A network-diagnostic tool of the BLMS detects that a luminaire in one of Company A's offices is no longer connected to the network. The BLMS alerts the facility manager to replace the luminaire. The facility manager replaces the old broken luminaire and informs the BLMS of the identity (e.g., the Media Access Control (MAC) address) of the newly added device. Then, the BLMS authorizes the new device in the system and seamlessly transfers all the permissions of the previous broken device to the replacement device (U4.12).
BLMSのネットワーク診断ツールは、A社のオフィスの1つにある照明器具がネットワークに接続されていないことを検出します。 BLMSは、照明器具を交換するように施設管理者に警告します。施設管理者は古い壊れた照明器具を交換し、新しく追加されたデバイスのID（メディアアクセスコントロール（MAC）アドレスなど）をBLMSに通知します。次に、BLMSはシステム内の新しいデバイスを承認し、以前に破損したデバイスのすべての権限をシームレスに交換用デバイスに転送します（U4.12）。
A vacant area of the building has recently been leased to Company A. Before moving into its new office, Company A wishes to replace the lighting with more energy efficient and better light quality luminaries. They hire an installation and commissioning Company C to redo the illumination. Company C is instructed to integrate the new lighting devices, which may be from multiple manufacturers, into the existing lighting infrastructure of the building, which includes presence sensors, switches, controllers, etc. (U4.1).
建物の空きエリアが最近A社にリースされました。A社は、新しいオフィスに移動する前に、照明をよりエネルギー効率が高く、より高品質の照明器具に置き換えたいと考えています。彼らは設備を雇い、照明をやり直すために会社Cに委託しました。 C社は、複数の製造元からの新しい照明デバイスを、プレゼンスセンサー、スイッチ、コントローラーなどを含む建物の既存の照明インフラストラクチャに統合するように指示されています（U4.1）。
Company C gets the necessary authorization from the facility-management company to interact with the existing BLMS (U4.4). To prevent disturbance to other occupants of the building, Company C is provided authorization to perform the commissioning only during non-office hours and only to modify configuration on devices belonging to the domain of Company A's space (U4.5). Before removing existing devices, all security and configuration material that belongs to the domain is deleted and the devices are set back to factory state (U4.3). This ensures that these devices may be reused at other installations or in other parts of the same building without affecting future operations. After installation (wiring) of the new lighting devices, the commissioner adds the devices into Company A's lighting domain.
C社は、既存のBLMSとやり取りするために施設管理会社から必要な許可を取得します（U4.4）。建物の他の居住者への妨害を防ぐために、C社には、営業時間外のみにコミッショニングを実行し、A社のスペースのドメイン（U4.5）に属するデバイスの構成のみを変更する権限が与えられます。既存のデバイスを削除する前に、ドメインに属するすべてのセキュリティと構成資料が削除され、デバイスは工場出荷時の状態に戻されます（U4.3）。これにより、将来の運用に影響を与えることなく、これらのデバイスを他の設備や同じ建物の他の部分で再利用できるようになります。新しい照明デバイスのインストール（配線）後、コミッショナーはデバイスをA社の照明ドメインに追加します。
Once the devices are in the correct domain, the commissioner authorizes the interaction rules between the new lighting devices and existing devices, like presence sensors (U4.7). For this, the commissioner creates the authorization rules on the BLMS that define which lights form a group and which sensors/switches/controllers are allowed to control which groups (U4.8). These authorization rules may be context based, like time of the day (office or non-office hours) or location of the handheld lighting controller, etc. (U4.5).
デバイスが正しいドメインに入ると、コミッショナーは、新しい照明デバイスと、存在センサー（U4.7）などの既存のデバイスとの間の相互作用規則を承認します。このために、コミッショナーは、BLMSに承認ルールを作成し、どのライトがグループを形成し、どのセンサー/スイッチ/コントローラーがどのグループを制御できるかを定義します（U4.8）。これらの承認規則は、時刻（オフィスまたは非オフィスの時間）やハンドヘルド照明コントローラーの場所など（U4.5）のように、コンテキストベースの場合があります。
Company A has noticed that the handheld controllers are often misplaced and hard to find when needed. So most of the time, staff use the existing wall switches for manual control. Company A decides it would be better to completely remove handheld controllers and asks Company C to decommission them from the lighting system (U4.4).
A社は、ハンドヘルドコントローラーが紛失していることが多く、必要なときに見つけにくいことに気づきました。そのため、ほとんどの場合、スタッフは既存の壁のスイッチを使用して手動で制御します。会社Aは、ハンドヘルドコントローラーを完全に削除する方がよいと判断し、会社Cにそれらを照明システムから廃止するよう依頼します（U4.4）。
Company C again gets the necessary authorization from the facility-management company to interact with the BLMS. The commissioner now deletes any rules that allowed handheld controllers authorization to control the lighting (U4.3, U4.6). Additionally, the commissioner instructs the BLMS to push these new rules to prevent cached rules at the end devices from being used. Any cryptographic key material belonging to the site in the handheld controllers is also removed, and they are set to the factory state (U4.3).
会社Cは、施設管理会社からBLMSと対話するために必要な承認を再度取得します。コミッショナーは、ハンドヘルドコントローラーが照明を制御することを許可したすべてのルールを削除します（U4.3、U4.6）。さらに、コミッショナーはBLMSにこれらの新しいルールをプッシュして、エンドデバイスでキャッシュされたルールが使用されないように指示します。ハンドヘルドコントローラーのサイトに属する暗号化キーマテリアルもすべて削除され、工場出荷時の状態（U4.3）に設定されます。
As part of the building safety code, the fire department requires that the building have sensors that sense the level of smoke, heat, etc., when a fire breaks out. These sensors report metrics that are then used by a back-end server to map safe areas and unsafe areas within a building and possibly the structural integrity of the building before firefighters may enter it. Sensors may also be used to track where human/animal activity is within the building. This will allow people stuck in the building to be guided to safer areas and allow the suggestion of possible actions that they may take (e.g., using a client application on their phones or giving loudspeaker directions) in order to bring them to safety. In certain cases, other organizations such as the police, ambulance, and federal organizations are also involved and therefore the co-ordination of tasks between the various entities have to be carried out using efficient messaging and authorization mechanisms.
建物の安全コードの一部として、消防署は、火災が発生したときに建物に煙や熱などのレベルを感知するセンサーが必要です。これらのセンサーは、バックエンドサーバーが建物内の安全な領域と安全でない領域をマップするために使用するメトリックを報告します。消防士が建物に入る前に、建物の構造的完全性をマップする可能性があります。センサーは、建物内の人間/動物の活動を追跡するためにも使用できます。これにより、建物内で立ち往生している人々をより安全な場所に誘導し、安全を確保するために、電話でクライアントアプリケーションを使用したり、スピーカーに指示を出すなど、可能な行動を提案できるようになります。特定のケースでは、警察、救急車、連邦組織などの他の組織も関与しているため、さまざまなエンティティ間のタスクの調整は、効率的なメッセージングおよび認証メカニズムを使用して実行する必要があります。
James, who works for Company A, turns on the air conditioning in his office on a really hot day. Lucy, who works for Company B, wants to make tea using an electric kettle. After she turns it on, she goes outside to talk to a colleague until the water is boiling. Unfortunately, her kettle has a malfunction that causes overheating and results in a smoldering fire of the kettle's plastic case.
会社Aに勤務するジェームズは、本当に暑い日にオフィスのエアコンをオンにします。 B社で働いているルーシーは、電気ポットを使用してお茶を作りたいと考えています。電源を入れた後、水が沸騰するまで外に出て同僚と話します。残念ながら、彼女のやかんは過熱を引き起こし、やかんのプラスチックケースのくすぶり火災を引き起こす誤動作があります。
Due to the smoke coming from the kettle, the fire alarm is triggered. Alarm sirens throughout the building are switched on simultaneously (using a group communication scheme) to alert the staff of both companies (U4.8). Additionally, the ventilation system of the whole building is closed off to prevent the smoke from spreading and to withdraw oxygen from the fire. The smoke cannot get into James' office, even though he turned on his air conditioning, because the fire alarm overrides the manual setting by sending commands (using group communication) to switch off all the air conditioning (U4.10).
やかんからの煙により、火災警報器が作動します。建物全体の警報サイレンが同時にオンになり（グループ通信スキームを使用）、両方の会社のスタッフに警告します（U4.8）。さらに、建物全体の換気システムは閉鎖され、煙の拡散を防ぎ、火災から酸素を取り除きます。ジェームスがエアコンをオンにしても、煙はジェームズのオフィスに入ることができません。火災警報は、すべてのエアコンをオフにするコマンド（グループ通信を使用）を送信することによって手動設定を上書きするためです（U4.10）。
The fire department is notified of the fire automatically and arrives within a short time. They automatically get access to all parts of the building according to an emergency authorization policy (U4.4, U4.5). After inspecting the damage and extinguishing the smoldering fire, a firefighter resets the fire alarm because only the fire department is authorized to do that (U4.4, U4.11).
消防署は自動的に火災の通知を受け、短時間で到着します。緊急時の許可ポリシー（U4.4、U4.5）に従って、建物のすべての部分に自動的にアクセスできます。損傷を調べてくすぶっている火を消した後、消防署だけが許可するため、消防士は火災警報をリセットします（U4.4、U4.11）。
U4.1: During commissioning, the building owner or the companies add new devices to their administrative domain. Access control should then apply to these devices seamlessly.
U4.1：試運転中に、建物の所有者または企業が新しいデバイスを管理ドメインに追加します。その後、アクセス制御はこれらのデバイスにシームレスに適用されます。
U4.2: During a handover, the building owner or the companies integrate devices that formerly belonged to a different administrative domain to their own administrative domain. Access control of the old domain should then cease to apply, with access control of the new domain taking over.
U4.2：ハンドオーバー中に、建物の所有者または会社は、以前は別の管理ドメインに属していたデバイスを、独自の管理ドメインに統合します。その後、古いドメインのアクセス制御は適用されなくなり、新しいドメインのアクセス制御が引き継がれます。
U4.3: During decommissioning, the building owner or the companies remove devices from their administrative domain. Access control should cease to apply to these devices and relevant credentials need to be erased from the devices.
U4.3：使用停止中に、建物の所有者または会社が管理ドメインからデバイスを削除します。アクセス制御はこれらのデバイスに適用されなくなり、関連する資格情報がデバイスから消去される必要があります。
U4.4: The building owner and the companies want to be able to delegate specific access rights for their devices to others.
U4.4：建物の所有者と会社は、デバイスへの特定のアクセス権を他のユーザーに委任できるようにしたいと考えています。
U4.5: The building owner and the companies want to be able to define context-based authorization rules.
U4.5：建物の所有者と会社は、コンテキストベースの承認ルールを定義できるようにしたいと考えています。
U4.6: The building owner and the companies want to be able to revoke granted permissions and delegations.
U4.6：建物の所有者と会社は、許可された許可と委任を取り消すことができることを望んでいます。
U4.7: The building owner and the companies want to allow authorized entities to send data to their endpoints (default deny).
U4.7：建物の所有者と会社は、承認されたエンティティがエンドポイントにデータを送信できるようにしたいと考えています（デフォルトでは拒否）。
U4.8: The building owner and the companies want to be able to authorize a device to control several devices at the same time using a group communication scheme.
U4.8：建物の所有者と会社は、グループ通信スキームを使用して、デバイスが複数のデバイスを同時に制御することを許可できることを望んでいます。
U4.9: The companies want to be able to interconnect their own subsystems with those from a different operational domain while keeping the control over the authorizations (e.g., granting and revoking permissions) for their endpoints and devices.
U4.9：企業は、エンドポイントとデバイスの承認（権限の付与と取り消しなど）を制御しながら、独自のサブシステムを異なる運用ドメインのサブシステムと相互接続できることを望んでいます。
U4.10: The authorization mechanisms must be able to cope with extremely time-sensitive operations that have to be carried out quickly.
U4.10：認可メカニズムは、迅速に実行する必要がある非常に時間に敏感な操作に対処できなければなりません。
U4.11: The building owner and the public safety authorities want to be able to perform data origin authentication on messages sent and received by some of the systems in the building.
U4.11：建物の所有者と公安当局は、建物内の一部のシステムによって送受信されたメッセージに対してデータ発信元認証を実行できることを望んでいます。
U4.12: The building owner should be allowed to replace an existing device with a new device providing the same functionality within their administrative domain. Access control from the replaced device should then apply to these new devices seamlessly.
U4.12：建物の所有者は、既存のデバイスを、管理ドメイン内で同じ機能を提供する新しいデバイスに置き換えることを許可されている必要があります。交換されたデバイスからのアクセス制御は、これらの新しいデバイスにシームレスに適用されます。
U4.13: When software on a device is updated, this update needs to be authenticated and authorized.
U4.13：デバイスのソフトウェアが更新されると、この更新は認証および承認される必要があります。
Automated measuring of customer consumption is an established technology for electricity, water, and gas providers. Increasingly, these systems also feature networking capability to allow for remote management. Such systems are in use for commercial, industrial, and residential customers and require a certain level of security, in order to avoid economic loss to the providers, vulnerability of the distribution system, as well as disruption of services for the customers.
顧客の消費量の自動測定は、電気、水道、ガスのプロバイダーにとって確立された技術です。これらのシステムは、リモート管理を可能にするネットワーク機能もますます備えています。このようなシステムは、商業、産業、および住宅の顧客に使用されており、プロバイダーへの経済的損失、流通システムの脆弱性、および顧客へのサービスの中断を回避するために、ある程度のセキュリティが必要です。
The smart metering equipment for gas and water solutions is battery-driven and communication should be used sparingly due to battery consumption. Therefore, these types of meters sleep most of the time, and only wake up every minute/hour to check for incoming instructions. Furthermore, they wake up a few times a day (based on their configuration) to upload their measured metering data.
ガスおよび水のソリューション用のスマートメーター装置はバッテリー駆動であり、バッテリーの消費量のため、通信は控えめに使用する必要があります。したがって、これらのタイプのメーターはほとんどの時間スリープし、着信する指示をチェックするために毎分/時間だけ目覚めます。さらに、1日数回（構成に基づいて）ウェイクアップし、測定された測定データをアップロードします。
Different networking topologies exist for smart metering solutions. Based on environment, regulatory rules, and expected cost, one or a mixture of these topologies may be deployed to collect the metering information. Drive-by metering is one of the most current solutions deployed for collection of gas and water meters.
スマートメータリングソリューションには、さまざまなネットワークトポロジが存在します。環境、規制ルール、および予想されるコストに基づいて、これらのトポロジの1つまたは混合を導入して、メータリング情報を収集できます。ドライブバイメータリングは、ガスと水道メーターの収集のために導入された最新のソリューションの1つです。
Various stakeholders have a claim on the metering data. Utility companies need the data for accounting, the metering equipment may be operated by a third-party service operator who needs to maintain it, and the equipment is installed in the premises of the consumers, measuring their consumption, which entails privacy questions.
さまざまな利害関係者が測定データについての主張を持っています。公益事業会社は会計のためのデータを必要とし、計測機器はそれを維持する必要のあるサードパーティのサービスオペレーターによって操作される場合があり、機器は消費者の敷地内に設置され、消費量を測定するため、プライバシーに関する質問が伴います。
A service operator offers smart metering infrastructures and related services to various utility companies. Among these is a water provider, who in turn supplies several residential complexes in a city. The smart meters are installed in the end customer's homes to measure water consumption and thus generate billing data for the utility company. They can also be used to shut off the water if the bills are not paid (U5.1, U5.3). The meters do this by sending and receiving data to and from a base station (U5.2). Several base stations are installed around the city to collect the metering data. However, in the denser urban areas, the base stations would have to be installed very close to the meters. This would require a high number of base stations and expose this more expensive equipment to manipulation or sabotage. The service operator has therefore chosen another approach, which is to drive around with a mobile base station and let the meters connect to that in regular intervals in order to gather metering data (U5.4, U5.6, U5.8).
サービスオペレータは、スマートメータリングインフラストラクチャおよび関連サービスをさまざまな公益事業会社に提供します。これらの中には水道業者があり、都市の住宅団地に供給しています。スマートメーターは、水の消費量を測定するためにエンドユーザーの家に設置され、ユーティリティ会社の請求データを生成します。手形が支払われない場合は、水を止めるためにも使用できます（U5.1、U5.3）。メーターは、基地局（U5.2）との間でデータを送受信することによってこれを行います。メーターデータを収集するために、いくつかの基地局が市内に設置されています。ただし、より密集した都市部では、基地局をメーターの非常に近くに設置する必要があります。これには多数の基地局が必要であり、このより高価な機器を操作または妨害行為にさらすことになります。したがって、サービスオペレーターは別のアプローチを選択しました。これは、モバイルベースステーションで移動し、メーターに定期的に接続して、メーターデータ（U5.4、U5.6、U5.8）を収集することです。
In another deployment, the water meters are installed in a building that already has power meters installed, the latter are mains powered, and are therefore not subject to the same power saving restrictions. The water meters can therefore use the power meters as proxies, in order to achieve better connectivity. This requires the security measures on the water meters to work through intermediaries (U5.9).
別の展開では、水道メーターはすでに電力メーターが設置されている建物に設置されており、後者には主電源が供給されているため、同じ電力節約の制約を受けません。したがって、水道メーターは、接続性を向上させるために、電力メーターをプロキシとして使用できます。これには、仲介者を介して機能する水道メーターのセキュリティ対策が必要です（U5.9）。
A utility company is updating its old utility distribution network with advanced meters and new communication systems, known as an Advanced Metering Infrastructure (AMI). AMI refers to a system that measures, collects, and analyzes usage, and interacts with metering devices such as electricity meters, gas meters, heat meters, and water meters, through various communication media either on request (on-demand) or on predefined schedules. Based on this technology, new services make it possible for consumers to control their utility consumption (U5.2, U5.7) and reduce costs by supporting new tariff models from utility companies, and more accurate and timely billing. However, the end consumers do not want unauthorized persons to gain access to this data. Furthermore, the fine-grained measurement of consumption data may induce privacy concerns, since it may allow others to create behavioral profiles (U5.5, U5.10).
公益事業会社は、高度なメータリングインフラストラクチャ（AMI）として知られる高度なメーターと新しい通信システムを使用して、古い公益事業分配ネットワークを更新しています。 AMIは、使用状況を測定、収集、分析し、要求に応じて（オンデマンドで）または事前定義されたスケジュールに従って、さまざまな通信メディアを介して、電気メーター、ガスメーター、熱メーター、水道メーターなどの計測デバイスと対話するシステムを指します。 。このテクノロジーに基づいて、新しいサービスは、消費者がユーティリティ消費（U5.2、U5.7）を制御し、ユーティリティ企業の新しい料金モデルとより正確でタイムリーな請求をサポートすることでコストを削減できるようにします。ただし、最終消費者は、権限のない人がこのデータにアクセスすることを望んでいません。さらに、消費データのきめの細かい測定は、他者が行動プロファイルを作成することを可能にする可能性があるため、プライバシーの懸念を引き起こす可能性があります（U5.5、U5.10）。
The technical solution is based on levels of data aggregation between smart meters located at the consumer premises and the Meter Data Management (MDM) system located at the utility company (U5.9). For reasons of efficiency and cost, end-to-end connectivity is not always feasible, so metering data is stored and aggregated in various intermediate devices before being forwarded to the utility company, and in turn accessed by the MDM. The intermediate devices may be operated by a third-party service operator on behalf of the utility company (U5.7). One responsibility of the service operator is to make sure that meter readings are performed and delivered in a regular, timely manner. An example of a Service Level Agreement between the service operator and the utility company is, for example, at least 95% of the meters have readings recorded during the last 72 hours.
技術的ソリューションは、消費者の構内にあるスマートメーターと公益事業会社（U5.9）にあるメーターデータ管理（MDM）システム間のデータ集約レベルに基づいています。効率とコストの理由から、エンドツーエンドの接続が常に可能であるとは限らないため、メータリングデータはさまざまな中間デバイスに格納および集約されてから、公益事業会社に転送され、MDMによってアクセスされます。中間デバイスは、公益事業会社（U5.7）に代わってサードパーティのサービスオペレーターが操作できます。サービスオペレーターの責任の1つは、メーターの読み取りが定期的かつタイムリーに実行および配信されるようにすることです。たとえば、サービスオペレーターと電力会社の間のサービスレベルアグリーメントの例として、過去95時間に少なくとも95％のメーターに測定値が記録されています。
U5.1: Devices are installed in hostile environments where they are physically accessible by attackers (including dishonest customers). The service operator and the utility company want to make sure that an attacker cannot use data from a captured device to attack other parts of their infrastructure.
U5.1：デバイスは、攻撃者（不正な顧客を含む）が物理的にアクセスできる敵対的な環境にインストールされます。サービスオペレーターと公益事業会社は、攻撃者がキャプチャしたデバイスからのデータを使用してインフラストラクチャの他の部分を攻撃できないようにする必要があります。
U5.2: The utility company wants to control which entities are allowed to send data to, and read data from, their endpoints.
U5.2：公益事業会社は、エンドポイントにデータを送信したり、エンドポイントからデータを読み取ったりできるエンティティを制御したいと考えています。
U5.3: The utility company wants to ensure the integrity of the data stored on their endpoints.
U5.3：公益事業会社は、エンドポイントに保存されているデータの整合性を確保したいと考えています。
U5.4: The utility company wants to protect such data transfers to and from their endpoints.
U5.4：公益事業会社は、エンドポイントとの間のこのようなデータ転送を保護したいと考えています。
U5.5: Consumers want to access their own usage information and also prevent unauthorized access by others.
U5.5：消費者は自分の使用情報にアクセスし、他人による不正アクセスを防止したいと考えています。
U5.6: The devices may have intermittent Internet connectivity but still need to enact the authorization policies of their principals.
U5.6：デバイスは断続的なインターネット接続を持っている可能性がありますが、それでもプリンシパルの承認ポリシーを制定する必要があります。
U5.7: Neither the service operator nor the utility company are always present at the time of access and cannot manually intervene in the authorization process.
U5.7：サービスオペレーターも公益事業会社も、アクセス時に常に存在しているわけではなく、認証プロセスに手動で介入することはできません。
U5.8: When authorization policies are updated it is impossible, or at least very inefficient to contact all affected endpoints directly.
U5.8：承認ポリシーが更新されると、影響を受けるすべてのエンドポイントに直接連絡することは不可能か、少なくとも非常に非効率的です。
U5.9: Authorization and authentication must work even if messages between endpoints are stored and forwarded over multiple nodes.
U5.9：エンドポイント間のメッセージが保存され、複数のノードに転送される場合でも、承認と認証が機能する必要があります。
U5.10: Consumers may not want the service operator, the utility company or others to have access to a fine-grained level of consumption data that allows the creation of behavioral profiles.
U5.10：消費者は、サービスオペレーター、公益事業会社、またはその他に、行動プロファイルの作成を可能にする、きめの細かいレベルの消費データへのアクセスを望まない場合があります。
In the area of leisure-time activities, applications can benefit from the small size and weight of constrained devices. Sensors and actuators with various functions can be integrated into fitness equipment, games, and even clothes. Users can carry their devices around with them at all times.
余暇活動の分野では、制約されたデバイスのサイズと重量が小さいことから、アプリケーションにメリットがあります。さまざまな機能を備えたセンサーとアクチュエーターは、フィットネス機器、ゲーム、さらには衣服に組み込むことができます。ユーザーはいつでも自分のデバイスを携帯できます。
Usability is especially important in this area since users will often want to spontaneously interconnect their devices with others. Therefore, the configuration of access permissions must be simple and fast and not require much effort at the time of access.
ユーザーは多くの場合、自発的にデバイスを他のデバイスと相互接続することを望むため、この領域では使いやすさが特に重要です。したがって、アクセス許可の構成は、単純かつ高速である必要があり、アクセス時に多くの労力を必要としない必要があります。
Continuously monitoring allows authorized users to create behavioral or movement profiles, that correspond to the devices' intended use, and unauthorized access to the collected data would allow an attacker to create the same profiles. Moreover, the aggregation of data can seriously increase the impact on the privacy of the users.
継続的に監視することで、承認されたユーザーはデバイスの使用目的に対応する行動または動きのプロファイルを作成できます。収集されたデータへの不正アクセスにより、攻撃者が同じプロファイルを作成する可能性があります。さらに、データの集約により、ユーザーのプライバシーへの影響が大幅に増大する可能性があります。
Jody is an enthusiastic runner. To keep track of her training progress, she has smart running shoes that measure the pressure at various points beneath her feet to count her steps, detect irregularities in her stride, and help her to improve her posture and running style. On a sunny afternoon, she goes to the Finnbahn track near her home to work out. She meets her friend Lynn, who shows her the smart fitness watch she bought a few days ago. The watch can measure the wearer's pulse, show speed and distance, and keep track of the configured training program. The girls realize that the watch can be connected with Jody's shoes and can display the information the shoes provide.
ジョディは熱狂的なランナーです。彼女はトレーニングの進捗状況を追跡するために、足の下のさまざまなポイントで圧力を測定して歩数をカウントし、ストライドの不規則性を検出し、姿勢とランニングスタイルを改善するのに役立つスマートランニングシューズを持っています。晴れた日の午後、彼女は自宅近くのFinnbahnトラックに行き、運動をします。彼女は友人のリンと出会い、数日前に購入したスマートフィットネスウォッチを見せてくれました。時計は、装着者の脈拍を測定し、速度と距離を示し、設定されたトレーニングプログラムを追跡できます。女の子は、時計がジョディーの靴に接続でき、靴が提供する情報を表示できることを認識しています。
Jody asks Lynn to let her try the watch and lend it to her for the afternoon. Lynn agrees, but she doesn't want Jody to access her training plan (U6.4). She configures the access policies for the watch so that Jody's shoes are allowed to access the display and measuring features but cannot read or add training data (U6.1, U6.2). Jody's shoes connect to Lynn's watch at the press of a button, because Jody already configured access rights for devices that belong to Lynn a while ago (U6.3). Jody wants the device to report the data back to her fitness account while she borrows it, so she allows it to access her account temporarily.
ジョディはリンに時計を試してもらい、午後に貸してくれるように頼みます。リンは同意しますが、ジョディがトレーニング計画（U6.4）にアクセスすることを望みません。彼女は時計のアクセスポリシーを構成して、ジョディの靴がディスプレイと測定機能にアクセスできるようにしますが、トレーニングデータの読み取りや追加はできません（U6.1、U6.2）。ジョディの靴は、ボタンを押すだけでリンの時計に接続します。これは、ジョディがすでにリンに属しているデバイスのアクセス権を構成しているためです（U6.3）。ジョディは、借りている間、デバイスがデータを自分のフィットネスアカウントに報告することを望んでいるため、一時的に自分のアカウントにアクセスできるようにします。
After an hour, Jody gives the watch back and both girls terminate the connection between their devices.
1時間後、ジョディは時計を返し、両方の女の子がデバイス間の接続を終了します。
U6.1: Sports equipment owners want to be able to grant access rights dynamically when needed.
U6.1：スポーツ用品の所有者は、必要なときに動的にアクセス権を付与できるようにしたいと考えています。
U6.2: Sports equipment owners want the configuration of access rights to work with very little effort.
U6.2：スポーツ用品の所有者は、アクセス権の設定がほとんど労力なしで機能することを望んでいます。
U6.3: Sports equipment owners want to be able to preconfigure access policies that grant certain access permissions to endpoints with certain attributes (e.g., endpoints of a certain user) without additional configuration effort at the time of access.
U6.3：スポーツ用品の所有者は、アクセス時に追加の構成作業を行うことなく、特定の属性を持つエンドポイント（たとえば、特定のユーザーのエンドポイント）に特定のアクセス許可を付与するアクセスポリシーを事前構成できることを望んでいます。
U6.4: Sports equipment owners want to protect the confidentiality of their data for privacy reasons.
U6.4：スポーツ用品の所有者は、プライバシー上の理由からデータの機密性を保護したいと考えています。
Industrial control systems (ICS) and especially supervisory control and data acquisition systems (SCADA) use a multitude of sensors and actuators in order to monitor and control industrial processes in the physical world. Example processes include manufacturing, power generation, and refining of raw materials.
産業用制御システム（ICS）、特に監視制御およびデータ収集システム（SCADA）は、物理世界の産業プロセスを監視および制御するために、多数のセンサーとアクチュエーターを使用します。プロセスの例には、原材料の製造、発電、精製が含まれます。
Since the advent of the Stuxnet worm, it has become obvious to the general public how vulnerable these kind of systems are, especially when connected to the Internet [Karnouskos11]. The severity of these vulnerabilities are exacerbated by the fact that many ICS are used to control critical public infrastructure, such as nuclear power, water treatment, or traffic control. Nevertheless, the economical advantages of connecting such systems to the Internet can be significant if appropriate security measures are put in place (U7.5).
Stuxnetワームの出現以来、特にインターネットに接続されている場合に、この種のシステムがいかに脆弱であるかが一般の人々に明らかになりました[Karnouskos11]。これらの脆弱性の深刻度は、多くのICSが原子力、水処理、交通管制などの重要な公共インフラの制御に使用されているという事実によって悪化しています。それでも、適切なセキュリティ対策が講じられている場合（U7.5）、このようなシステムをインターネットに接続することの経済的メリットは非常に大きくなる可能性があります。
An oil platform uses an industrial control system to monitor data and control equipment. The purpose of this system is to gather and process data from a large number of sensors and control actuators such as valves and switches to steer the oil extraction process on the platform. Raw data, alarms, reports, and other information are also available to the operators, who can intervene with manual commands. Many of the sensors are connected to the controlling units by direct wire, but the operator is slowly replacing these units by wireless ones, since this makes maintenance easier (U7.4).
石油プラットフォームは、産業用制御システムを使用してデータを監視し、機器を制御します。このシステムの目的は、多数のセンサーからデータを収集して処理し、バルブやスイッチなどのアクチュエータを制御して、プラットフォームでのオイル抽出プロセスを制御することです。生データ、アラーム、レポート、およびその他の情報は、手動コマンドで介入できるオペレーターも利用できます。センサーの多くは直接配線で制御ユニットに接続されていますが、メンテナンスが容易になるため、オペレーターはこれらのユニットをゆっくりと無線ユニットに交換しています（U7.4）。
Some of the controlling units are connected to the Internet, to allow for remote administration, since it is expensive and inconvenient to fly in a technician to the platform (U7.3).
一部の制御ユニットはインターネットに接続されており、リモート管理を可能にします。これは、技術者がプラットフォーム（U7.3）に飛ぶのは高価で不便なためです。
The main interest of the operator is to ensure the integrity of control messages and sensor readings (U7.1). Access in some cases needs to be restricted, e.g., the operator wants wireless actuators only to accept commands by authorized control units (U7.2).
オペレーターの主な関心は、制御メッセージとセンサー測定値の完全性を保証することです（U7.1）。場合によっては、アクセスを制限する必要があります。たとえば、オペレーターは、承認されたコントロールユニット（U7.2）によるコマンドのみを受け入れるようにワイヤレスアクチュエーターを望んでいます。
The owner of the platform also wants to collect auditing information for liability reasons (U7.1).
プラットフォームの所有者も、責任の理由から監査情報を収集したいと考えています（U7.1）。
Different levels of access apply e.g., for regular operators vs. maintenance technician vs. auditors of the platform (U7.6).
たとえば、通常のオペレーターと保守技術者とプラットフォームの監査員（U7.6）には、さまざまなレベルのアクセスが適用されます。
U7.1: The operator of the platform wants to ensure the integrity and confidentiality of sensor and actuator data.
U7.1：プラットフォームのオペレーターは、センサーとアクチュエーターのデータの完全性と機密性を確保したいと考えています。
U7.2: The operator wants to ensure that data coming from sensors and commands sent to actuators are authentic.
U7.2：オペレーターは、センサーからのデータとアクチュエーターに送信されたコマンドが本物であることを確認したいと考えています。
U7.3: Some devices do not have direct Internet connection, but they still need to implement current authorization policies.
U7.3：一部のデバイスは直接インターネット接続を備えていませんが、現在の承認ポリシーを実装する必要があります。
U7.4: Devices need to authenticate the controlling units, especially those using a wireless connection.
U7.4：デバイスは、特にワイヤレス接続を使用する制御ユニットを認証する必要があります。
U7.5: The execution of unauthorized commands or the failure to execute an authorized command in an ICS can lead to significant financial damage and threaten the availability of critical infrastructure services. Accordingly, the operator wants authentication and authorization mechanisms that provide a very high level of security.
U7.5：許可されていないコマンドの実行またはICSでの許可されたコマンドの実行の失敗は、重大な経済的損害をもたらし、重要なインフラストラクチャサービスの可用性を脅かす可能性があります。したがって、オペレーターは非常に高いレベルのセキュリティを提供する認証および承認メカニズムを望んでいます。
U7.6: Different users should have different levels of access to the control system (e.g., operator vs. auditor).
U7.6：異なるユーザーは、制御システムへの異なるレベルのアクセス権を持っている必要があります（オペレーターと監査員など）。
As the use cases listed in this document demonstrate, constrained devices are used in various environments. These devices are small and inexpensive and this makes it easy to integrate them into many aspects of everyday life. With access to vast amounts of valuable data and possible control of important functions, these devices need to be protected from unauthorized access. Protecting seemingly innocuous data and functions will lessen the possible effects of aggregation; attackers collecting data or functions from several sources can gain insights or a level of control not immediately obvious from each of these sources on its own.
このドキュメントにリストされている使用例が示すように、制約付きデバイスはさまざまな環境で使用されます。これらのデバイスは小型で安価なため、日常生活のさまざまな側面に簡単に統合できます。膨大な量の貴重なデータにアクセスし、重要な機能を制御できるため、これらのデバイスを不正アクセスから保護する必要があります。一見無害なデータと関数を保護すると、集計の影響の可能性が少なくなります。複数のソースからデータまたは機能を収集する攻撃者は、これらの各ソースからそれ自体ではすぐには明らかではない洞察または制御レベルを取得できます。
Not only the data on the constrained devices themselves is threatened, the devices might also be abused as an intrusion point to infiltrate a network. Once an attacker gains control over the device, it can be used to attack other devices as well. Due to their limited capabilities, constrained devices appear as the weakest link in the network; hence, they pose an attractive target for attackers.
制約のあるデバイス自体のデータが脅かされるだけでなく、デバイスがネットワークに侵入する侵入ポイントとして悪用される可能性もあります。攻撃者がデバイスを制御できるようになると、それを使用して他のデバイスを攻撃することもできます。機能が制限されているため、制約のあるデバイスはネットワークで最も弱いリンクとして表示されます。したがって、攻撃者にとって魅力的な標的となります。
This section summarizes the security problems highlighted by the use cases above and provides guidelines for the design of protocols for authentication and authorization in constrained RESTful environments.
このセクションでは、上記の使用例で強調されたセキュリティの問題を要約し、制約されたRESTful環境での認証と承認のためのプロトコルの設計に関するガイドラインを提供します。
This document lists security problems that users of constrained devices want to solve. Further analysis of attack scenarios is not in scope of the document. However, there are attacks that must be considered by solution developers.
このドキュメントでは、制約のあるデバイスのユーザーが解決したいセキュリティの問題を一覧表示します。攻撃シナリオのさらなる分析は、ドキュメントの範囲外です。ただし、ソリューション開発者が考慮しなければならない攻撃があります。
Because of the expected large number of devices and their ubiquity, constrained devices increase the danger from Pervasive Monitoring [RFC7258] attacks. Solution Designers should consider this in the design of their security solution and provide for protection against this type of attack. In particular, messages containing sensitive data that are sent over unprotected channels should be encrypted if possible.
予想される多数のデバイスとそのユビキタスのため、制約されたデバイスはPervasive Monitoring [RFC7258]攻撃の危険性を高めます。ソリューション設計者は、セキュリティソリューションの設計でこれを考慮し、このタイプの攻撃に対する保護を提供する必要があります。特に、保護されていないチャネルを介して送信される機密データを含むメッセージは、可能であれば暗号化する必要があります。
Attacks aimed at altering data in transit (e.g., to perpetrate fraud) are a problem that is addressed in many web security protocols such as TLS or IPsec. Developers need to consider these types of attacks, and make sure that the protection measures they implement are adapted to the constrained environment.
転送中のデータを変更することを目的とする攻撃（詐欺の実行など）は、TLSやIPsecなどの多くのWebセキュリティプロトコルで対処されている問題です。開発者はこれらのタイプの攻撃を検討し、実装する保護手段が制約された環境に適応していることを確認する必要があります。
As some of the use cases indicate, constrained devices may be installed in hostile environments where they are physically accessible (see Section 2.5). Protection from physical attacks is not in the scope of this document, but it should be kept in mind by developers of authorization solutions.
ユースケースの一部が示すように、制約のあるデバイスは、物理的にアクセス可能な悪環境にインストールされる場合があります（セクション2.5を参照）。物理的な攻撃からの保護はこのドキュメントの範囲外ですが、認可ソリューションの開発者はこれを覚えておく必要があります。
Denial-of-service (DoS) attacks threaten the availability of services a device provides and constrained devices are especially vulnerable to these types of attacks because of their limitations. Attackers can illicit a temporary or, if the battery is drained, permanent failure in a service simply by repeatedly flooding the device with connection attempts; for some services (see Section 2.3), availability is especially important. Solution designers must be particularly careful to consider the following limitations in every part of the authorization solution: o Battery usage
サービス拒否（DoS）攻撃は、デバイスが提供するサービスの可用性を脅かし、制約されたデバイスは、その制限のため、これらのタイプの攻撃に対して特に脆弱です。攻撃者は、一時的に、またはバッテリーが消耗している場合は、接続の試行でデバイスを繰り返しあふれさせるだけで、サービスに永続的な障害を引き起こします。一部のサービス（セクション2.3を参照）では、可用性が特に重要です。ソリューション設計者は、承認ソリューションのすべての部分で次の制限を考慮するように特に注意する必要があります。oバッテリーの使用
o Number of required message exchanges
o 必要なメッセージ交換の数
o Size of data that is transmitted (e.g., authentication and access control data)
o 送信されるデータのサイズ（例：認証およびアクセス制御データ）
o Size of code required to run the protocols
o プロトコルの実行に必要なコードのサイズ
o Size of RAM memory and stack required to run the protocols
o プロトコルの実行に必要なRAMメモリとスタックのサイズ
o Resources blocked by partially completed exchanges (e.g., while one party is waiting for a transaction time to run out)
o 部分的に完了した交換によってブロックされたリソース（たとえば、一方の当事者がトランザクション時間がなくなるのを待っている間）
Solution developers also need to consider whether the session should be protected from information disclosure and tampering.
また、ソリューション開発者は、セッションを情報開示や改ざんから保護する必要があるかどうかを検討する必要があります。
o The access control policies need to be enforced (all use cases): The information that is needed to implement the access control policies needs to be provided to the device that enforces the authorization and applied to every incoming request.
o アクセス制御ポリシーを実施する必要があります（すべての使用例）：アクセス制御ポリシーを実装するために必要な情報は、認証を実施するデバイスに提供し、すべての着信要求に適用する必要があります。
o A single resource might have different access rights for different requesting entities (all use cases).
o 単一のリソースが、異なる要求エンティティ（すべての使用例）に対して異なるアクセス権を持つ場合があります。
Rationale: In some cases, different types of users need different access rights, as opposed to a binary approach where the same access permissions are granted to all authenticated users.
根拠：場合によっては、認証されたすべてのユーザーに同じアクセス許可が付与されるバイナリアプローチとは対照的に、異なるタイプのユーザーには異なるアクセス権が必要です。
o A device might host several resources where each resource has its own access control policy (all use cases).
o デバイスは複数のリソースをホストする場合があり、各リソースには独自のアクセス制御ポリシーがあります（すべての使用例）。
o The device that makes the policy decisions should be able to evaluate context-based permissions such as location or time of access (see Sections 2.2, 2.3, and 2.4). Access may depend on local conditions, e.g., access to health data in an emergency. The device that makes the policy decisions should be able to take such conditions into account.
o ポリシーを決定するデバイスは、アクセスの場所や時間などのコンテキストベースの権限を評価できる必要があります（セクション2.2、2.3、および2.4を参照）。アクセスは、地域の状況、たとえば緊急時の健康データへのアクセスに依存する場合があります。ポリシー決定を行うデバイスは、そのような条件を考慮に入れられるべきです。
o Devices need to be enabled to enforce authorization policies without human intervention at the time of the access request (see Sections 2.1, 2.2, 2.4, and 2.5).
o アクセス要求時に人の介入なしに認証ポリシーを実施するには、デバイスを有効にする必要があります（セクション2.1、2.2、2.4、および2.5を参照）。
o Authorization solutions need to consider that constrained devices might not have Internet access at the time of the access request (see Sections 2.1, 2.3, 2.5, and 2.6).
o 承認ソリューションでは、アクセス要求時に制約されたデバイスがインターネットにアクセスできない可能性があることを考慮する必要があります（セクション2.1、2.3、2.5、および2.6を参照）。
o It should be possible to update access control policies without manually re-provisioning individual devices (see Sections 2.2, 2.3, 2.5, and 2.6).
o 個々のデバイスを手動で再プロビジョニングすることなく、アクセス制御ポリシーを更新できるはずです（セクション2.2、2.3、2.5、および2.6を参照）。
Rationale: Peers can change rapidly which makes manual re-provisioning unreasonably expensive.
理論的根拠：ピアは急速に変化する可能性があるため、手動での再プロビジョニングは不当に高価になります。
o Authorization policies may be defined to apply to a large number of devices that might only have intermittent connectivity. Distributing policy updates to every device for every update might not be a feasible solution (see Section 2.5).
o 断続的な接続しかない可能性のある多数のデバイスに適用するように、許可ポリシーを定義できます。すべての更新に対してすべてのデバイスにポリシー更新を配布することは、実行可能なソリューションではない場合があります（セクション2.5を参照）。
o It must be possible to dynamically revoke authorizations (see Section 2.4 for example).
o 権限を動的に取り消すことが可能でなければなりません（たとえば、セクション2.4を参照）。
o The authentication and access control protocol can put undue burden on the constrained system resources of a device participating in the protocol. An authorization solution must take the limitations of the constrained devices into account (all use cases, see also Section 3.1).
o 認証およびアクセス制御プロトコルは、プロトコルに参加しているデバイスの制約されたシステムリソースに過度の負担をかける可能性があります。承認ソリューションでは、制約されたデバイスの制限を考慮する必要があります（すべての使用例、セクション3.1も参照）。
o Secure default settings are needed for the initial state of the authentication and authorization protocols (all use cases).
o 認証および承認プロトコルの初期状態（すべての使用例）には、安全なデフォルト設定が必要です。
Rationale: Many attacks exploit insecure default settings, and experience shows that default settings are frequently left unchanged by the end users.
理論的根拠：多くの攻撃は安全でないデフォルト設定を悪用しており、経験上、デフォルト設定はエンドユーザーによって変更されないままにされることが多いことがわかっています。
o Access to resources on other devices should only be permitted if a rule exists that explicitly allows this access (default deny) (see Section 2.4 for example).
o 他のデバイス上のリソースへのアクセスは、このアクセスを明示的に許可するルールが存在する場合にのみ許可する必要があります（デフォルトは拒否）（たとえば、セクション2.4を参照）。
o Usability is important for all use cases. The configuration of authorization policies as well as the gaining access to devices must be simple for the users of the devices. Special care needs to be taken for scenarios where access control policies have to be configured by users that are typically not trained in security (see Sections 2.2, 2.3, and 2.6).
o 使いやすさはすべてのユースケースで重要です。許可ポリシーの構成とデバイスへのアクセスの取得は、デバイスのユーザーにとって単純でなければなりません。通常はセキュリティのトレーニングを受けていないユーザーがアクセス制御ポリシーを構成する必要があるシナリオでは、特別な注意が必要です（セクション2.2、2.3、および2.6を参照）。
o Software updates are an important operation for which correct authorization is crucial. Additionally, authenticating the receiver of a software update is also important, for example, to make sure that the update has been received by the intended device.
o ソフトウェアの更新は、正しい認証が重要な重要な操作です。さらに、ソフトウェアの更新の受信者を認証することも重要です。たとえば、目的のデバイスが更新を受信したことを確認します。
In some cases, the traffic between endpoints might go through intermediary nodes (e.g., proxies, gateways). This might affect the function or the security model of authentication and access control protocols e.g., end-to-end security between endpoints with Datagram Transport Layer Security (DTLS) might not be possible (see Section 2.5).
場合によっては、エンドポイント間のトラフィックが中間ノード（プロキシ、ゲートウェイなど）を通過することがあります。これは、認証やアクセス制御プロトコルの機能やセキュリティモデルに影響を与える可能性があります。たとえば、データグラムトランスポート層セキュリティ（DTLS）を備えたエンドポイント間のエンドツーエンドのセキュリティは不可能である場合があります（セクション2.5を参照）。
The constrained devices in focus of this document either collect data from the physical world via sensors or affect their surroundings via actuators. The collected and processed data often can be associated with individuals. Since sensor data may be collected and distributed on a regular interval, a significant amount of information about an individual can be collected and used as input for learning algorithms as part of big data analysis and used in an automated decision making process.
このドキュメントで取り上げる制約のあるデバイスは、センサーを介して現実世界からデータを収集するか、アクチュエータを介して周囲に影響を与えます。収集および処理されたデータは、多くの場合、個人に関連付けることができます。センサーデータは定期的に収集および配布されるため、個人に関するかなりの量の情報を収集し、ビッグデータ分析の一部として学習アルゴリズムの入力として使用し、自動意思決定プロセスで使用できます。
Offering privacy protection for individuals is important to guarantee that only authorized entities are allowed to access collected data, to trigger actions, to obtain consent prior to the sharing of data, and to deal with other privacy-related threats outlined in RFC 6973.
個人にプライバシー保護を提供することは、許可されたエンティティのみが収集されたデータへのアクセス、アクションのトリガー、データ共有前の同意の取得、およびRFC 6973で概説されている他のプライバシー関連の脅威への対処を許可されることを保証するために重要です。
RFC 6973 was written as guidance for engineers designing technical solutions. For a short description about the deployment-related aspects of privacy and further references relevant for the Internet of Things sector, please see Section 7 of RFC 7452.
RFC 6973は、技術ソリューションを設計するエンジニア向けのガイダンスとして作成されました。プライバシーの展開関連の側面に関する簡単な説明と、モノのインターネットセクターに関連するその他の参照については、RFC 7452のセクション7をご覧ください。
[Jedermann14] Jedermann, R., Poetsch, T., and C. LLoyd, "Communication techniques and challenges for wireless food quality monitoring", Philosophical Transactions of the Royal Society A Mathematical, Physical and Engineering Sciences, May 2014, <http://rsta.royalsocietypublishing.org/ content/372/2017/20130304.short>.
[Jedermann14] Jedermann、R.、Poetsch、T。、およびC. LLoyd、「通信技術とワイヤレス食品品質モニタリングの課題」、王立協会の哲学的トランザクション、数理、物理およびエンジニアリング科学、2014年5月、<http： //rsta.royalsocietypublishing.org/ content / 372/2017 / 20130304.short>。
[Karnouskos11] Karnouskos, S., "Stuxnet Worm Impact on Industrial Cyber-Physical System Security", IECON 2011 - 37th Annual Conference on IEEE Industrial Electronics Society, pp. 4490-4494 10.1109/econ.2011.612.0048, November 2011, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=6120048>.
[Karnouskos11] Karnouskos、S.、「産業サイバーフィジカルシステムセキュリティに対するStuxnetワームの影響」、IECON 2011-第37回IEEE産業電子学会年次会議、pp。4490-4494 10.1109 / econ.2011.612.0048、2011年11月、< http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber = 6120048>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
Acknowledgments
謝辞
The authors would like to thank Olaf Bergmann, Sumit Singhal, John Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna Schmitt, Hannes Tschofenig, Erik Wahlstroem, Andreas Baeckman, Samuel Erdtman, Steve Moore, Thomas Hardjono, Kepeng Li, Jim Schaad, Prashant Jhingran, Kathleen Moriarty, and Sean Turner for reviewing and/or contributing to the document. Also, thanks to Markus Becker, Thomas Poetsch, and Koojana Kuladinithi for their input on the container monitoring use case. Furthermore, the authors thank Akbar Rahman, Chonggang Wang, Vinod Choyi, and Abhinav Somaraju who contributed to the building automation use case.
著者は、Olaf Bergmann、Sumit Singhal、John Mattson、Mohit Sethi、Carsten Bormann、Martin Murillo、Corinna Schmitt、Hannes Tschofenig、Erik Wahlstroem、Andreas Baeckman、Samuel Erdtman、Steve Moore、Thomas Hardjono、Kepeng Li、Jim Schaadに感謝します。 、Prashant Jhingran、Kathleen Moriarty、Sean Turnerがドキュメントのレビューや投稿に貢献しました。また、コンテナモニタリングの使用例に関する情報を提供してくれたMarkus Becker、Thomas Poetsch、Koojana Kuladinithiに感謝します。さらに、著者は、ビルディングオートメーションのユースケースに貢献してくれたAkbar Rahman、Chonggang Wang、Vinod Choyi、Abhinav Somarajuに感謝します。
Ludwig Seitz and Goeran Selander worked on this document as part of EIT-ICT Labs activity PST-14056; and as part of the CelticPlus project CyberWI, with funding from Vinnova.
Ludwig SeitzとGoeran Selanderは、EIT-ICTラボアクティビティPST-14056の一環としてこのドキュメントに取り組んだ。また、Vinnovaからの資金提供を受けて、CelticPlusプロジェクトCyberWIの一部として。
Authors' Addresses
著者のアドレス
Ludwig Seitz (editor) SICS Swedish ICT AB Scheelevaegen 17 Lund 223 70 Sweden
Ludwig Seitz（editor）SICS Swedish ICT AB Scheelevaegen 17 Lund 223 70 Sweden
Email: ludwig@sics.se
Stefanie Gerdes (editor) Universitaet Bremen TZI Postfach 330440 Bremen 28359 Germany
Stefanie Gerdes（編集者）ブレーメン大学TZI P.O. Box 330440ブレーメン28359ドイツ
Phone: +49-421-218-63906
Email: gerdes@tzi.org
Goeran Selander Ericsson Faroegatan 6 Kista 164 80 Sweden
Goeran Selander Ericsson Faroegatan 6 Kista 164 80スウェーデン
Email: goran.selander@ericsson.com
Mehdi Mani Itron 52, rue Camille Desmoulins Issy-les-Moulineaux 92130 France
Mehdi Mani Itron 52、rue Camille Desmoulins Issy-les-Moulineaux 92130フランス
Email: Mehdi.Mani@itron.com
Sandeep S. Kumar Philips Research High Tech Campus Eindhoven 5656 AA The Netherlands
Sandeep S. Kumar Philips Researchハイテクキャンパスアイントホーフェン5656 AAオランダ
Email: sandeep.kumar@philips.com