Network Working Group M. Danley
Request for Comments: 3694 D. Mulligan
Category: Informational Samuelson Law, Technology & Public Policy Clinic
J. Morris
Center for Democracy & Technology
J. Peterson
NeuStar
February 2004
Threat Analysis of the Geopriv Protocol
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements.
この文書では、Geoprivプロトコルアーキテクチャに対する脅威のいくつかの分析を提供します。これは、プロトコルの脅威、アーキテクチャのエンティティによるデータの保存に起因する脅威、およびGeoprivによって得られた情報の乱用によってもたらされる脅威に焦点を当てています。これらの脅威を満たす一部のセキュリティプロパティはGeopriv要件の基準として列挙されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Habitat of the Geopriv Protocol . . . . . . . . . . . . . . . 3
3. Motivations of Attackers of Geopriv . . . . . . . . . . . . . 4
4. Representative Attacks on Geopriv . . . . . . . . . . . . . . 5
4.1. Protocol Attacks . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Eavesdropping and/or Interception . . . . . . . 5
4.1.2. Identity Spoofing . . . . . . . . . . . . . . . 6
4.1.3. Information Gathering . . . . . . . . . . . . . 7
4.1.4. Denial of Service . . . . . . . . . . . . . . . 8
4.2. Host Attacks . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Data Stored at Servers . . . . . . . . . . . . . 9
4.2.2. Data Stored in Devices . . . . . . . . . . . . . 9
4.2.3. Data Stored with the Viewer . . . . . . . . . . 10
4.2.4. Information Contained in Rules . . . . . . . . . 10
4.3. Usage Attacks . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Threats Posed by Overcollection . . . . . . . . 11
5. Countermeasures for Usage Violations . . . . . . . . . . . . . 12
5.1. Fair Information Practices . . . . . . . . . . . . . . . 12
6. Security Properties of the Geopriv Protocol . . . . . . . . . 13
6.1. Rules as Countermeasures . . . . . . . . . . . . . . . . 13
6.1.1. Rule Maker Should Define Rules . . . . . . . . . 13
6.1.2. Geopriv Should Have Default Rules . . . . . . . 14
6.1.3. Location Recipient Should Not Be Aware of All
Rules. . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. Certain Rules Should Travel With the LO . . . . 14
6.2. Protection of Identities . . . . . . . . . . . . . . . . 14
6.2.1. Short-Lived Identifiers May Protect Target's
Identity . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Unlinked Pseudonyms May Protect the Location
Recipients' Identity . . . . . . . . . . . . . . 15
6.3. Security During Transmission of Data . . . . . . . . . . 15
6.3.1. Rules May Disallow a Certain Frequency of
Requests . . . . . . . . . . . . . . . . . . . . 15
6.3.2. Mutual End-Point Authentication . . . . . . . . 16
6.3.3. Data Object Integrity & Confidentiality . . . . 16
6.3.4. Replay Protection . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . . 16
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
The proliferation of location-based services that integrate tracking and navigation capabilities gives rise to significant privacy and security concerns. Such services allow users to identify their own location as well as determine the location of others. In certain peer-to-peer exchanges, device identification takes place automatically within a defined location perimeter, informing peer devices of a given user's identity and availability. Additionally, records of location exchanges can reveal significant information about the habits, whereabouts, and associations of individual users.
追跡とナビゲーション機能を統合ロケーションベースのサービスの普及は重要なプライバシーとセキュリティの懸念を生じさせます。このようなサービスは、ユーザーが自分の位置を特定するだけでなく、他の人の位置を決定することができます。特定のピア・ツー・ピア交換において、デバイス識別は、所与のユーザのアイデンティティおよび可用性のピアデバイスに通知する、定義された位置の境界内で自動的に行われます。また、場所交換の記録は、習慣、所在、および個々のユーザの関連付けに関する重要な情報を明らかにすることができます。
The Geopriv requirements allow the Location Object (LO) to support a wide variety of uses of Location Information (LI); the Geopriv object itself is intended to be technology-neutral, allowing a wide variety of devices to provide LI in the form of an LO. Geopriv also requires that many classes of Viewers be capable of requesting LI from a Location Server. The Geopriv requirements account for circumstances in which the Target has a contractual relationship with the entities that transmit and receive LI and those in which no contract exists. Requiring the Geopriv object to support any technology, Target-Viewer relationship, or underlying legal framework governing LI, complicates the protection of privacy and the security of LI.
Geopriv要件場所オブジェクト（LO）は、位置情報（LI）の用途の広範囲をサポートすることを可能にします。 Geoprivオブジェクト自体は、LOの形態でLIを提供するために、デバイスの様々な可能、技術中立であることを意図しています。 Geoprivも、視聴者の多くのクラスは、ロケーションサーバからLIを要求できることが必要です。 Geopriv要件は、ターゲットが送信し、LIと何の契約が存在しないでそれらを受ける事業体との契約関係を持っている状況を占めています。任意の技術、ターゲット・ビューアの関係、またはLIを支配する基本的な法的枠組みをサポートするために、Geoprivオブジェクトを必要とし、プライバシーの保護やLIのセキュリティを複雑にします。
This document analyzes threats to LI in transmission and storage. The possibility that the LI will be compromised by these threats varies depending on the circumstances. A server selling location information to potential marketers poses a distinctly lower risk than an outside individual intercepting a Target's present location to commit a physical attack. It is important that these threats are considered as we work towards defining the LO.
この文書では、伝送およびストレージにLIへの脅威を分析します。 LIは、これらの脅威によって損なわれる可能性が状況に応じて変化します。潜在的なマーケティング担当者に位置情報を販売サーバは物理的な攻撃をコミットする対象者の現在位置を傍受外の個々よりも明らかに低いリスクをもたらします。我々がLOの定義に取り組むように、これらの脅威を考慮することが重要です。
Some of the threats discussed in this document may be outside the scope of the Geopriv charter, e.g., threats arising from failure to meet contractual obligations. Nevertheless, a comprehensive discussion of threats is necessary to identify desirable security properties and counter-measures that will improve the security of the LO, and thereby better protect LI.
Geoprivチャーターの範囲は、例えば、障害に起因する脅威が契約上の義務を満たすために外本書で論じた脅威の一部であってもよいです。それにもかかわらず、脅威の包括的な議論は、所望のセキュリティ特性とLOのセキュリティを改善し、それによってより良好なLIを保護する対策を特定する必要があります。
The Geopriv architecture will be deployed in the open Internet - in a security environment in which potential attackers can inspect packets on the wire, spoof Internet addresses, and launch large-scale denial-of-service attacks. In some architectures, portions of Geopriv traffic (especially traffic between the Location Generator and an initial Location Server) may occur over managed networks that do not interface with the public Internet.
Geoprivアーキテクチャは、オープンなインターネットで展開されます - セキュリティ環境で潜在的な攻撃者は、ワイヤ上のパケットを検査なりすましインターネットアドレス、および大規模なDoS（サービス拒否）攻撃を開始することができています。いくつかのアーキテクチャでは、Geoprivトラフィック（所在地ジェネレータおよび初期ロケーションサーバ間で特にトラフィック）の部分は、公共のインターネットとのインターフェイスはありません、管理ネットワーク上で発生する可能性があります。
The protocol itself assumes interaction between a number of logical roles, many of which will commonly be implemented in distributed network devices (for a full list of Geopriv roles and entities with definitions, see [1]). The endpoints of the common Geopriv transactions are the Location Generator (the source of location information from the perspective of the network) and the Location Recipient. Both a Location Generator and a Location Recipient may have a relationship with a Location Server; the Location Generator publishes data to a Location Server (which may provide a grooming/ filtration function for location information), and the Location Recipient requests and/or receives information from the Location Server. This provides two points where Geopriv information could require protection across the wire. Rules can also be passed over the network from a Rule Holder to a Location Server; this provides another point where the architecture requires security.
プロトコル自体は、一般的に、分散ネットワークデバイスに実装され、その多くの論理的な役割、（定義とGeoprivロールとエンティティの完全なリストについては、[1]参照）の数との間の相互作用を前提としています。共通Geoprivトランザクションのエンドポイントは、ロケーションジェネレータ（ネットワークの観点からの位置情報のソース）と場所受信者です。場所ジェネレータと場所受信者の両方は、ロケーションサーバとの関係を有していてもよいです。ロケーションジェネレータ（位置情報のグルーミング/濾過機能を提供することができる）ロケーションサーバにデータを公開し、そして場所受信者の要求および/またはロケーションサーバから情報を受信します。これはGeopriv情報は、ワイヤ全体の保護を必要とする可能性がある2つの点を提供します。ルールはまた、ロケーションサーバへのルールのホルダーからネットワーク経由で渡すことができます。これは、アーキテクチャは、セキュリティを必要とする別のポイントを提供します。
It is important to note that Location Generators and Location Recipients may be implemented on low-cost devices for which strong cryptographic security is currently prohibitively expensive computationally.
場所ジェネレータと場所受信者は、強力な暗号化セキュリティは現在、非常に高価に計算しているため、低コストのデバイスに実装されてもよいことに注意することが重要です。
The most obvious motivation for an attacker of Geopriv is to learn the location of a subject who wishes to keep their position private, or even for authorized Viewers to ascertain location information with a greater degree of precision than the Rule Maker desires. However, there are several other potential motivations that cause concern. Attackers might also wish to prevent a Target's location from being distributed, or to modify or corrupt location information in order to misrepresent the location of the Target, or to redirect the Target's location information to a third party that is not authorized to know this information. Attackers may want to identify the associates of a Target, or learn the habit or routines of a Target. Attackers might want to learn the identity of all of the parties that are in a certain location. Finally, some attackers may simply want to halt the operation of an entire Geopriv system through denial-of-service attacks.
Geoprivの攻撃のための最も明白な動機は、プライベート、あるいは許可された視聴者は、ルールメーカーの欲望よりもより高い精度で位置情報を把握するために自分の位置を維持したい被写体の位置を学ぶことです。しかし、懸念を引き起こすいくつかの他の潜在的な動機があります。攻撃者は、分散されることから、ターゲットの位置を防ぐことを望むかもしれない、またはターゲットの場所を不正表示、またはこの情報を知ることが許可されていない第三者に対象者の位置情報をリダイレクトするために、情報を変更したり、破損している場所へ。攻撃者は、ターゲットの仲間を識別するか、または対象の習慣またはルーチンを勉強したいことがあります。攻撃者は、特定の場所にある当事者のすべてのアイデンティティを学びたいと思うかもしれません。最後に、いくつかの攻撃者は、単純に、サービス拒否攻撃による全体Geoprivシステムの動作を停止することをお勧めします。
There is also a class of attackers who may be authorized as legitimate participants in a Geopriv protocol exchange but who abuse location information. This includes the distribution or accumulation of location information outside the parameters of agreements between the principals, possibly for commercial purposes or as an act of unlawful surveillance.
Geoprivプロトコル交換における合法的な参加者として認定することができるが、位置情報を乱用者攻撃のクラスもあります。これは、おそらく商業目的または違法監視の行為として、プリンシパル間の契約のパラメータ外側位置情報の分布または蓄積を含みます。
Imagine a location-based computer game, based on traditional hide-and-seek, in which a centralized server provides hints as to the location of the 'hider' to a set of 'seekers'. Seekers are given access to very coarse location data, whereas a single referee is given access to unfiltered and precise location information of the hider. Each seeker has a wireless device (in the Geopriv architecture, a Location Recipient) that feeds them coarse positioning data from the Location Server. The hider carries a device (a Location Generator employing GPS) that transmits location information to the Location Server.
中央サーバは、「求職者」のセットに「ハイダー」の場所へとヒントを提供している伝統的なかくれんぼ、に基づいて、位置ベースのコンピュータゲームを想像してみてください。単一審判はハイダーのフィルタリングされていないと正確な位置情報へのアクセスを与えられ、一方、求職者は、非常に粗い位置データへのアクセスを与えられています。各求職者は彼らにロケーションサーバからの粗位置決めデータをフィード（Geoprivアーキテクチャでは、所在地の受信者）無線装置を備えています。ハイダーは、ロケーションサーバへ位置情報を送信する装置（ロケーションジェネレータ使用GPS）を運びます。
If one of the seekers wished to cheat by attacking the Geopriv protocol, there are a number of ways they could mount such an attack in order to learn the precise location of the hider. They might eavesdrop on one of two network connections - either the connection between the Location Generator and the Location Server, or the connection between the Location Server and the referee's Location Recipient (which receives precise information). They might also attempt to impersonate the referee to the Location Server, in order to receive unfiltered Location Information. Alternatively, they could impersonate the Location Server to the Location Generator carried by the hider, which would also give them access to precise location information. Finally, the cheater could attempt to act as the Rule Maker, whereby providing Rules to the Location Server would enable the cheater's Location Recipient access to uncoarsened location information.
求職者の1がGeoprivプロトコルを攻撃することでごまかすことを望んだ場合、彼らはハイダーの正確な位置を知るために、このような攻撃を仕掛けることができ、いくつかの方法があります。場所ジェネレータと場所サーバー間の接続、またはロケーションサーバと（正確な情報を受け取る）審判の場所受信者間の接続のいずれか - 彼らは、2つのネットワーク接続の1つを盗聴することがあります。彼らはまた、フィルタリングされていない位置情報を受信するためには、ロケーションサーバへの審判を偽装しようとする場合があります。また、彼らはまた彼らに正確な位置情報へのアクセスを与えるだろうハイダー、によって運ばれる場所ジェネレータへのロケーションサーバになりすますことができます。最後に、詐欺師はuncoarsened位置情報にチーターの場所受信者のアクセスを可能にするロケーションサーバへのルールを提供することにより、ルールメーカーとして動作するように試みることができます。
From these threats, we can derive a need for several security properties of the architecture.
これらの脅威から、我々はアーキテクチャのいくつかのセキュリティプロパティの必要性を導き出すことができます。
o Confidentiality is required on both the connection between the Location Generator and the Location Server, as well as the connection between the Location Server and any given Location Recipient.
O機密性は場所ジェネレータとロケーションサーバ間の接続のほか、ロケーションサーバと任意の場所受信者との間の接続の両方に必要とされます。
o Location Servers must be capable of authenticating and authorizing Location Recipients to prevent impersonation.
Oロケーションサーバは、偽装を防ぐために、場所の受信者を認証し、許可することが可能でなければなりません。
o Similarly, Location Generators must be capable of authenticating and authorizing Location Servers in order to prevent impersonation.
O同様に、ロケーション・ジェネレータは、なりすましを防止するために、ロケーションサーバを認証及び認可することができなければなりません。
o Finally, the Location Server must be able to authenticate Rule Makers, to make sure that unauthorized parties cannot change rules.
O最後に、ロケーションサーバは、権限のない者がルールを変更することはできませんことを確認するために、ルールのメーカーを認証することができなければなりません。
Consider a case in which the same boss employs two rivals. One goes on a business trip to Cleveland. Both rivals carry devices that are tracked by a Location Generator (such as cell phones which the cell carrier can triangulate), and both rivals allow their boss access to their (coarse) location information. The rival that remained home wants to hack the Geopriv protocol to make it appear that the traveling rival is actually goofing off in South Beach rather than attending a dull technology conference in Cleveland. How would such an attack be mounted?
同じボスは2人のライバルを採用した場合を考えてみましょう。一つはクリーブランドへ出張に行きます。両方のライバルは、（例えば、細胞担体は三角測量することができる携帯電話など）ロケーションジェネレータによって追跡し、両方のライバルは、それらの（粗い）位置情報へのボスのアクセスを許可されたデバイスを運びます。家を残ったライバルは、走行ライバルが実際にサウスビーチに怠けるというよりもクリーブランドの鈍い技術会議に出席していることを見せることGeoprivプロトコルをハックしたいと考えています。どのような攻撃をマウントするのでしょうか？
The attacker might attempt to spoof network traffic from the Location Generator to the Location Server (especially if, through some other means such as a denial-of-service attack, the Location Generator became unable to issue its own reports). The goal of the attacker may be to provide falsified location information appropriate for someone in Miami, or perhaps even to replay a genuine location object from a previous visit of the rival to Miami. The attacker might also try to spoof traffic from the Location Server to the boss' Location Recipient.
攻撃者は、ロケーションサーバへの場所ジェネレーターからのネットワークトラフィックを偽装しようとする場合があります（たとえば、サービス拒否攻撃など、いくつかの他の手段によって、特に場合は、場所ジェネレーターは独自の報告書を発行することができませんでしなりました）。攻撃者の目的は、マイアミの誰かのための偽装位置情報の適切なを提供するために、あるいはおそらくマイアミのライバルの前の訪問から本物の場所のオブジェクトを再生することであってもよいです。攻撃者はまた、上司の場所受信者へのロケーションサーバからのトラフィックを偽装しようとするかもしれません。
From these threats we can derive a need for several security properties of the architecture.
これらの脅威から、我々はアーキテクチャのいくつかのセキュリティプロパティの必要性を導き出すことができます。
o There is a need for the Location Server to authenticate Location Generators.
O場所ジェネレータを認証するロケーションサーバが必要です。
o Location Recipients must be capable of authenticating Location Servers.
Oロケーションの受信者は、ロケーションサーバを認証することが可能でなければなりません。
o Location information must be protected from replay attacks.
O位置情報はリプレイ攻撃から保護されなければなりません。
Identity spoofing may create additional threats when the protocol is attacked. In many circumstances, the identity of the Viewer is the basis for controlling whether LI is revealed and, if so, how that LI is filtered. If the identity of that entity is compromised, privacy is threatened. Anyone inside or outside the transaction that is capable of impersonating an authorized entity can gain access to confidential information, or initiate false transmissions in the authorized entity's name. The ability to spoof the identity of the Location Recipient, for example, would create the risk of an unauthorized entity accessing both the identity and the location of the Target at the moment the LO was sent.
プロトコルが攻撃されたときにアイデンティティスプーフィングは、追加の脅威を作成することができます。多くの状況では、ビューアのアイデンティティはLIが明らかと、そうであれば、どのようにLIがフィルタリングされていることをされているかどうかを制御するための基礎となっています。そのエンティティのアイデンティティが侵害された場合、プライバシーが脅かされています。権限のある機関を偽装することができ、トランザクション内部または外部の誰もが機密情報へのアクセスを得る、または認定エンティティの名前で偽の送信を開始することができます。場所受信者のアイデンティティを偽造する能力は、例えば、同一性およびLOが送信された瞬間の対象の位置の両方にアクセスする権限のないエンティティのリスクを作成します。
Eavesdropping and interception can also create traffic analysis threats as the interceptor collects more data over time. Traffic analysis threats are leveraged by an eavesdropper to determine, from the very fact of a network transmission, the relationship between the various entities involved. If an employer sends the location of an employee to a customer, an eavesdropper could determine that these three entities are somehow interacting with one another. If eavesdropping continues over time, the collection of interactions would involve the employer, employees, and all of their customers. Such a log of information would reveal that the employer and employee frequently were associated with one another, and would reveal which clients more frequently dealt with the pair. Thus, the traffic analysis threat creates the risk of eavesdroppers determining the Target's associates.
インターセプターは、時間をかけてより多くのデータを収集して盗聴や傍受は、トラフィック分析の脅威を作成することができます。トラフィック分析の脅威は、ネットワーク伝送、関与する様々なエンティティ間の関係を非常に事実から、判断するために盗聴者によって活用されています。雇用主は、顧客への従業員の位置を送信する場合、盗聴者は、これらの3つのエンティティが何らかの形で相互に対話していることを決定することができます。盗聴は、時間をかけて継続する場合は、相互作用のコレクションは、雇用主、従業員、顧客のすべてを伴うだろう。情報のようなログが雇用主と従業員が頻繁に相互に関連していたことを明らかにしただろう、とクライアントがより頻繁にペアを扱っている明らかにする。このように、トラフィック分析の脅威は、対象者の仲間を決定盗聴のリスクを作成します。
Traffic analysis might also allow an eavesdropper to ascertain the identity or characteristics of targets in a particular location. By observing transmissions between Location Generators in a particular location and Location Servers (perhaps by eavesdropping on a wireless or wireline LAN scoped to the location in question), and then possibly following the data to various Location Recipients, an attacker may be able to learn the associates, including the employer, of targets in that location, and perhaps to extrapolate further identity information.
トラフィック分析も盗聴者が特定の場所に同一性またはターゲットの特性を把握することが可能かもしれません。特定の位置及び場所サーバーに位置ジェネレータの間の送信を観察することによって（無線または有線LANにおそらく盗聴することによって、問題の場所にスコープ）、次いでおそらくは様々な場所受信者にデータを以下、攻撃者は学習することができるかもしれませんその位置でターゲットの雇用者を含む仲間は、おそらくさらなる識別情報を推定します。
If the eavesdropper is able to intercept not only an encrypted LO, but the plaintext LI itself, other threats are raised. Let's return to the above example of the employer requesting an employee's location information. In this instance, the interception of one such past transaction may reveal the identities and/or locations of all three parties involved, in addition to revealing their association. In circumstances where there is a log of this data, however, analysis could reveal any regular route that the employee may travel in visiting customers, a general area that the employee works in, the identities and location of the employee's entire customer base, and information about how the entities relate.
盗聴者が暗号化されたLOが、平文LIそのものだけでなく、を傍受できる場合、他の脅威が発生しています。のは、従業員の位置情報を要求する雇用者の上記の例に戻りましょう。この例では、そのような過去のトランザクションの傍受は、彼らの関連を明らかにすることに加えて、関連するすべての3人の関係者の身元および/または場所を明らかにすることができます。このデータのログがある状況では、しかし、分析では、従業員が、顧客を訪問して従業員が中に動作することを一般的な領域を移動することができることを任意の正規のルートを明らかにアイデンティティと従業員の全体の顧客基盤、および情報の場所でしたエンティティがどのように関連するかについて。
Threats based on traffic analysis are difficult to meet with protocol security measures, but they are important to note.
トラフィック分析に基づいた脅威は、プロトコルのセキュリティ対策を満たすことは困難であるが、彼らは注意することが重要です。
From these threats we can derive a need for several security properties of the architecture.
これらの脅威から、我々はアーキテクチャのいくつかのセキュリティプロパティの必要性を導き出すことができます。
o The Rule Maker must be able to define Rules regarding the use of their LI.
Oルールのメーカーは、彼らのLIの使用に関するルールを定義することができなければなりません。
o The connection between the Location Generator and Location Server, as well as the connection between the Location Server and Location Recipient must remain confidential.
場所ジェネレータとロケーションサーバ間の接続O、だけでなく、ロケーションサーバと場所の受信者との間の接続は、機密のままでなければなりません。
o Location Servers must be capable of authenticating Location Recipients to prevent impersonation.
Oロケーションサーバは、偽装を防ぐために、場所の受信者を認証することが可能でなければなりません。
o Location Servers must be able to authenticate Rule Makers to ensure that unauthorized entities cannot change rules.
Oロケーションサーバは、不正なエンティティがルールを変更することはできませんことを保証するために、ルールのメーカーを認証することができなければなりません。
Parties who wish to deprive entire networks of Geopriv service, rather than just targeting particular users, would probably focus their efforts on the Location Server. Since in many scenarios the Location Server plays the central role of managing access to location information for many devices, it is in such architectures a natural single point of failure.
Geoprivサービスだけではなく、特定のユーザーをターゲットのネットワーク全体を奪うことを望む締約国は、おそらく、ロケーションサーバ上の努力を集中します。多くのシナリオでロケーションサーバは、多くのデバイスのための位置情報へのアクセスを管理する中心的な役割を果たしているので、それは失敗の自然なシングルポイントは、このようなアーキテクチャです。
The Geopriv protocol appears to have some opportunities for amplification attacks. When the Location Generator publishes location information, the Location Server acts as an exploder, potentially delivering this information to numerous targets. If the Location Generator were to provide very rapid updates of position (as many as link speed could accommodate, especially in high-bandwidth wireless environments), then were the Location Server to proxy information to Seekers at a similar rate, this could become problematic when large numbers of Seekers are tracking the same user.
Geoprivプロトコルは、増幅攻撃のためのいくつかの機会を持っているように見えます。場所Generatorは、位置情報を公開すると、ロケーションサーバは、潜在的に多数のターゲットにこの情報を提供する、エクスプローダとして機能します。場所ジェネレーターは、位置の非常に迅速な更新を提供した場合（リンク速度などの多くとして特に高帯域幅の無線環境では、収容できる）、その後、ロケーションサーバは、同様の速度で求職者にプロキシ情報にあったが、これは時に問題となる可能性求職者の多くは、同じユーザーを追跡しています。
Also note that most operations associated with the Location Server probably require cryptographic authentication. Cryptographic operations entail a computational expense on the part of the Location Server. This could provide an attractive means for attackers to flood the Location Server with dummied Geopriv information that is spoofed to appear to come from a Location Generator, Location Recipient, or the Rule Maker. Because the Location Server has to expend resources to verify credentials presented by these Geopriv messages, floods of Geopriv information could have greater impact than denial-of-service attacks based on generic packet flooding.
また、ロケーションサーバに関連付けられているほとんどの操作は、おそらく暗号化認証を必要とすることに注意してください。暗号化操作は、ロケーションサーバの一部に計算コストを伴います。これは、攻撃者が場所ジェネレーター、所在地の受信者、またはルールのメーカーから来るように見えるように偽装されdummied Geopriv情報をロケーションサーバをあふれさせるための魅力的な手段を提供することができます。ロケーションサーバは、これらのGeoprivメッセージが提示する資格情報を確認するためにリソースを消費する必要があるため、Geopriv情報の洪水は、一般的なパケットフラッディングに基づくDoS攻撃よりも大きな影響を与える可能性があります。
From these threats we can derive a need for several security properties of the architecture.
これらの脅威から、我々はアーキテクチャのいくつかのセキュリティプロパティの必要性を導き出すことができます。
o Location Servers must use stateless authentication challenges and similar measures to ensure that authentication attempts will not unnecessarily consume system resources.
Oロケーションサーバは、認証の試みが不必要にシステムリソースを消費しません確実にするためにステートレス認証チャレンジと同様の措置を使用する必要があります。
o The Rule Maker must be able to provision policies that limit the rate at which Location Information is sent to prevent amplification attacks.
Oルールのメーカーは、位置情報が増幅攻撃を防ぐために送信されるレートを制限する規定の方針にできなければなりません。
LI maintained at a server is subject to many potential risks. First, there may be accidental misuse of LI by the server. Whether by negligence, carelessness, or lack of knowledge, the server may accidentally release LI to the wrong Location Recipients, or fail to properly filter the LI that is sent out. Second, the server may intentionally misuse LI. A server may decide to sell a "profile" it has compiled of a Target or Location Recipient despite provisions to the contrary in the Rule Maker's Rule. Alternatively, an individual working for the server may, for personal gain, misuse access to the server to obtain LI. Third, even with the most secure and trusted server, there is the risk that someone outside the system will hack into it in order to retrieve LI. Last, there is always the potential that someone would use the legal system to subpoena an individual's records from a Server. Such a process would likely result in the revelation of the Target's location information without notice to the Target or the Target's consent.
LIは、サーバ、多くの潜在的なリスクにさらされるで維持しました。まず、サーバによってLIの偶然の誤用があるかもしれません。過失、不注意、または知識の欠如によってかどうか、サーバーが誤って間違った場所の受信者にLIを解放する、または適切に送り出されるLIをフィルタリングするために失敗することがあります。第二に、サーバーは、意図的にLIを誤用します。サーバーは、それがルールメーカーのルールに矛盾する規定にもかかわらず、ターゲットや場所受信者のまとめた「プロファイル」を販売することを決定することができます。また、サーバーのために働いて個人が、個人的な利益のために、サーバーへの誤用アクセスがLIを取得することがあります。第三に、も、最も安全で信頼されたサーバーで、システム外の誰かがLIを取得するためにそれに侵入するおそれがあります。最後に、誰かがサーバーから個々のレコードを召喚するための法的システムを使用することを可能性が常にあります。このようなプロセスは、おそらく標的または標的の同意に通知することなく、ターゲットの位置情報の啓示をもたらすであろう。
Data stored at the server may reveal the Target's present location if the data is used or intercepted at or near the moment of transmission. If a Target requests a map from their present location to a nearby store, and the Location Server sends that information to the wrong Location Recipient, the Viewer could know the identity of the Target, the Target's current location, and the location where the Target might be headed.
データが送信の瞬間に、または近くで使用または傍受された場合、サーバに格納されたデータは、対象者の現在の位置を明らかにすることができます。ターゲットは、近くの店に彼らの現在の位置からマップを要求し、ロケーションサーバが間違った場所の受信者にその情報を送信した場合、ビューアは、ターゲット、ターゲットの現在位置の身元を知っている可能性があり、場所はどこターゲットかもしれません向かっています。
Data stored at the Location Server can also create many of the traffic analysis threats discussed in Section 4.1 above. If access is gained not only to the fact of the LO transmission, but also to the LI transmitted, anyone with access to that information can put together a history of where that Target has been, for how long, and with whom.
ロケーションサーバに格納されたデータは、上記のセクション4.1で説明トラフィック分析の脅威の多くを作成することができます。アクセスがないだけLO送信の事実に、だけでなく、送信LIに獲得されている場合は、その情報にアクセスできる者は誰でも一緒にそのターゲットが誰で、どのくらいのために、されている場所の歴史を置くことができます。
Because Geopriv is required to work with any given type of technology or Device, it is difficult to determine the particular threat potential of individual devices. For example, any device that maintains a log of location requests sent, or LOs received, would pose a similar threat to the information maintained at a Location Server, discussed above. A court subpoena or warrant for an individual's device could additionally reveal a similar log.
Geoprivは、技術またはデバイスの任意のタイプで動作するために必要とされているので、個々のデバイスの特定の脅威の可能性を決定することは困難です。例えば、送信されたロケーション要求のログを保持し、またはLOSが受信された任意の装置は、上述したロケーションサーバに保持されている情報と同様の脅威をもたらすであろう。個々のデバイスのための裁判所の召喚状または令状は、さらに同様のログを明らかにすることができます。
Additionally, depending on the device, there is always the potential for data to be compromised in some way. For a Device with a screen, there is always the potential that another individual will have the opportunity to view the Device display without the user's knowledge. A Device that provides verbal feedback (i.e., to give directions to the blind) creates additional potential for LI to be compromised. If the Target/Viewer is sitting in a public place and requests directions from the Target's home to another location, anyone who can hear the Device output may be able to determine the Target's identity, their residence, and possibly the location to which they are headed.
また、デバイスに応じて、いくつかの方法で侵害されるデータの可能性が常にあります。画面を持つデバイスの場合は、別の個人がユーザーの知識がなくてもデバイスの表示を見る機会を持つことになります可能性が常にあります。口頭フィードバックを提供する装置（すなわち、ブラインドに指示を与えるために）妥協するLIのための追加の可能性を作成します。ターゲット/ Viewerが別の場所に対象者の自宅からの指示を公共の場所で座って要求されている場合は、デバイスの出力を聞くことができます誰もが、彼らが向かっている先の対象者の身元、彼らの居住地、そしておそらく場所を決定することができます。
In addition, if the device retained location information and the Device were lost or stolen, someone other than the Rule Maker could potentially access information regarding who LI was sent to and when, as well as potentially the location of the Target during each transaction. Such information could enable an entity to determine significant private information based on who the owner of the Device has associated with in the past, as well as each location where the Target has been and for how long.
デバイス保持する位置情報とデバイスの紛失または盗難された場合また、ルールメーカー以外の誰かが潜在的にLIは、各トランザクション中にターゲットの潜在的な場所としてだけでなく、にいつ送信された方の情報をアクセスすることができました。そのような情報は、デバイスの所有者は、ターゲットがされた各位置と同様に、過去に関連付けられている人に、どのように長い間基づく重要プライベート情報を決定するエンティティを可能にすることができます。
The threats posed here are similar to those discussed above in relation to Location Servers and Devices. The main purpose of separating out threats posed by data stored at the Viewer is to show that, depending on the complexity of the transaction and the other entities involved, data storage at various points in the transaction can bring rise to the same types of privacy risks.
脅威は、ここで提起されたロケーションサーバとデバイスに関連して、上述のものと同様です。ビューアに格納されたデータの脅威を分離する主な目的は、トランザクション内のさまざまなポイントでのデータ・ストレージは、プライバシー上のリスクの同じ種類の上昇をもたらすことができ、取引の複雑さと関連する他のエンティティに応じて、ことを示すことです。
In many instances, the Rules a Rule Maker creates will reveal information either about the Rule Maker or the Target. A rule that degrades all information sent out by approximately 25 miles might tell an interceptor how to determine the Target's true location. A Rule that states, "Tell my boss what room I'm in when I'm in the building, but when I'm outside the building between 9 a.m. and 5 p.m. tell him I'm in the building," would reveal a lot more information than most employees would desire. Any boss who was the Location Recipient who received LI that specified "in the building" would then realize that the employee was elsewhere.
多くの場合、ルールのメーカーが作成したルールは、いずれかのルールメーカーやターゲットについての情報を明らかにします。約25マイルから送信されたすべての情報を劣化させるルールは、対象者の真の位置を決定するために、どのようにインターセプタを伝えるかもしれません。 「私は午前9時から午後5時までの間に建物の外にいる時、私は建物にいる彼に言う私は建物の中にいる時にだけど、何部屋私の上司に知らせる」、と述べルールが明らかになりほとんどの従業員よりも多くの情報が望むだろう。 「建物の中に」指定されたLIを受けた場所の受信者だった任意の上司は、従業員が他の場所であったことを理解するであろう。
In addition, if an entity had access to a log of data at the Location Server or at a Device, knowledge of the content of Rules would enable a sort of "decoding" of the location information of the device to something more accurate. Thus, my boss could not only tell where I am at this minute, but could tell how many times over the last year I had been outside the building between 9 a.m. and 5 p.m.
エンティティは、ロケーションサーバで、またはデバイスでデータのログへのアクセスを持っていた場合また、ルールの内容の知識がより正確なものに、デバイスの位置情報の「デコード」の並べ替えを可能にします。このように、私の上司は、私はこの分で午前ところだけ伝えることができなかったが、昨年、私は9午前と午後5時の間で建物の外であった回数を言うことができます
The Rules themselves may also reveal information about the Target. A rule such as the one above would clearly reveal the employment relationship between the two individuals, as well as the fact that the employee was hiding something from the employer.
ルール自体もターゲットについての情報を公開してもよいです。前述のようなルールが明確に二人の間に雇用関係だけでなく、従業員が雇用主から何かを隠したという事実を明らかにする。
In combination with other information, the location information may enable the identification of the Target.
他の情報と組み合わせて、位置情報は、ターゲットの識別を可能にすることができます。
Weak or absent default privacy rules would also compromise LI. Without default Rules for LOs, it is likely that a large number of Devices would reveal LI by default. Privacy rules should control the collection, use, disclosure, and retention of Location Information. These rules must comply with fair information practices - these practices are further discussed in Section 5.1.
弱いまたは欠席デフォルトのプライバシー規則にもLIを危うくします。 LOのデフォルトのルールがなければ、多数のデバイスがデフォルトでLIを明らかにするであろうと思われます。プライバシー規則は、位置情報の収集、使用、開示、および保持を制御する必要があります。これらの規則は、公正な情報慣行を遵守しなければならない - これらのプラクティスは、さらに、5.1節で議論されています。
While technically savvy Device users may create privacy rules to protect their LI, many individuals will lack the skill or motivation to do so. Thus, left to their own devices many individuals would likely be left without privacy rules for their LI. This in turn would leave these users' LI entirely vulnerable to various attacks. Default rules are necessary to address this problem.
技術的に精通したデバイスのユーザーが自分のLIを保護するためのプライバシー規則を作成することがありますが、多くの人がそうするスキルやモチベーションに欠けます。このように、自分のデバイスに左に多くの個人は、おそらく彼らのLIのプライバシールールなしで残されることになります。これは、順番に様々な攻撃を完全に脆弱これらのユーザーのLIを残すでしょう。デフォルトのルールは、この問題に対処するために必要です。
Without default rules, for example, a device might signal out to anyone nearby at regular intervals, respond to anyone nearby who queried it, or send signals out to unknown entities.
デフォルトのルールがなければ、例えば、デバイスは、定期的に近くの人には信号outかもしれない、それを照会近くの誰にも応える、または未知のエンティティに信号を送ります。
The lack of a default rule of "Do not re-distribute," would allow the Location Server to pass the Target's location information on to others. Lack of a default rule limiting the retention of LI could increase the risk posed by inappropriate use and access to stored data.
デフォルトルールの欠如「しないでください、再配布は、」ロケーションサーバが他の人に、ターゲットの位置情報を渡すことができるようになります。 LIの保持を制限するデフォルトルールの欠如は、不適切な使用や保存されたデータへのアクセスによるリスクを増加させる可能性があります。
While defining default privacy rules is beyond the scope of this document, default rules are necessary to limit the privacy risks posed by the use of services and devices using LI.
デフォルトのプライバシー規則を定義すると、この文書の範囲外ですが、デフォルトのルールは、LIを使用してサービスやデバイスの使用によってもたらされるプライバシー上のリスクを制限する必要があります。
Principles of fair information practices require entities that handle personal information to meet certain obligations with respect to its collection, use, maintenance and security, and give individuals whose personal information is collected certain due process-like rights in the handling of their information. Fair information practices are designed to prevent specific threats posed by the collection of personal information about individuals. For this reason, fair information practices are "countermeasures" that should be reflected in technical systems that handle personal information and the Rules that govern their use. A brief discussion of fair information practices may be beneficial in formulating requirements for the LO.
公正な情報慣行の原則は、その収集、使用、保守、セキュリティに対して一定の義務を満たし、かつその個人情報をその情報の取り扱いに一定のデュー・プロセスのような権利が収集された個人を与えるために、個人情報を取り扱う企業に求めます。フェア情報の取り扱いは、個人に関する個人情報の収集によってもたらされる特定の脅威を防ぐために設計されています。このため、公正な情報慣行は、個人情報とその使用を管理する規則を扱う技術システムに反映されるべき「対策」です。公正な情報慣行の簡単な説明は、LOの要件を策定において有益であり得ます。
There are seven main principles of fair information practices:
公正な情報慣行の7つの主要な原則があります：
1. Openness: The existence of a record-keeping system for personal information must be known, along with a description of the main purpose and uses of the data. Thus, any entity that collects LI should inform individuals that this information is being collected and inform them about what the LI is being used for. Openness is designed to prevent the creation of secret systems.
1.開放性：個人的な情報のための記録管理システムの存在はデータの主な目的と用途の説明とともに、知られていなければなりません。このように、LIを収集する任意のエンティティは、この情報が収集されていることを個人に通知し、LIが使用されているものについて、それらを通知しなければなりません。オープン性は、秘密のシステムの作成を防ぐように設計されています。
2. Individual Participation: Individuals should have a right to view all information collected about them, and to be able to correct or remove data that is not timely, accurate, relevant, or complete. The practice of individual participation acknowledges that sometimes information that is collected may be inaccurate or inappropriate.
2.個々の参加：個人はそれらについて収集されたすべての情報を表示する権利を持つべきである、と、タイムリーに正確な、関連する、または完了していないデータを修正または削除できるようにします。個々の参加の実践は、しばしば収集された情報が不正確または不適切であってもよいことを認めます。
3. Collection Limitation: Data should be collected by lawful and fair means and should be collected, where appropriate, with the knowledge or consent of the subject. Data collection should be minimized to that which is necessary to support the transaction. Placing limits on collection helps protect individuals from the dangers of overcollection - both in terms of collecting too much information, or of collecting information for too long of a time period.
3.コレクション制限：データは、適法かつ公正な手段によって収集されなければならないと対象の知識や同意を得て、適切な場合には、収集する必要があります。データ収集は、トランザクションをサポートするために必要であることに最小化されなければなりません。あまりにも多くの情報を収集するという点で、または期間の長すぎるための情報を集めるの両方 - コレクションに制限を置くことはovercollectionの危険から個人を保護するのに役立ちます。
4. Data Quality: Personal data should be relevant to the purposes for which it is collected and used; personal information should be accurate, complete, and timely. The requirement of data quality is designed to prevent particular kinds of harms that can flow from the use (appropriate or inappropriate) of personal information.
4.データ品質：個人データは、それが収集され、使用される目的に関連する必要があります。個人情報は、正確かつ完全、かつタイムリーにする必要があります。データ品質の要件は、個人情報の（適切なまたは不適切な）使用から流れることができる害の特定の種類のを防止するように設計されています。
5. Finality: There should be limits to the use and disclosure of personal data: data should be used only for purposes specified at the time of collection; data should not be otherwise used or disclosed without the consent of the data subject or other legal authority. A consumer who provides LI to a business in order to receive directions, for example, does not provide that information for any other purpose. The business should then only use that LI to provide directions, and not for other purposes.
5.終局：個人情報の利用および開示には限界があるはずです：データは、収集時に指定した目的のために使用する必要があります。データは、そうでない場合は、データの件名または他の法的権限の同意なしに使用または開示すべきではありません。指示を受けるために、ビジネスにLIを提供し、消費者は、例えば、他の目的のためにその情報を提供していません。事業はその後、唯一の他の目的のためにLIが方向性を提供することを使用し、そしてべきではありません。
6. Security: Personal Data should be protected by reasonable security safeguards against such risks as loss, unauthorized access, destruction, use, modification, or disclosure. While some security measures may take place outside of the LO (i.e., limiting employee access to Location Servers), other measures may be done through the LO or LO applications.
6.セキュリティ：個人情報が紛失、不正アクセス、破壊、使用、修正、または開示などのリスクに対して合理的な安全保護措置により保護されなければなりません。いくつかのセキュリティ対策（すなわち、ロケーションサーバへの従業員のアクセスを制限する）LOの外で行うことができるが、他の対策がLOまたはLOアプリケーションを介して行われてもよいです。
7. Accountability: Record keepers should be accountable for complying with fair information practices. It will typically be easier for an individual to enforce these practices if they are explicitly written - either in the Rules written by the Rule Maker, or in contracts between the individual and a trusted entity.
7.責任：レコードキーパーは、公正な情報慣行の遵守について責任でなければなりません。ルールメーカーによって書かれたルールで、あるいは個人と信頼できるエンティティ間の契約のいずれか - これらは明示的に書かれている場合は個人がこれらの慣行を強制することは一般的に容易になります。
The countermeasures suggested below reflect the threats discussed in this document. There is thus some overlap between the proposed security properties listed below, and the requirements in [1].
以下の提案の対策は、この文書で説明した脅威を反映しています。下記の提案セキュリティ特性との間のいくらかのオーバーラップ、および[1]の要求が存在します。
The sections below are designed to illustrate that in many instances threats to LI can be limited through clear, unavoidable rules determined by Rule Makers.
以下のセクションでは、多くの場合、LIに対する脅威は、ルールメーカーによって決まる明確な、やむを得ない規則によって制限されることができることを示すために設計されています。
The Rule Maker for a given Device will generally be either the user of, or owner of, the Device. In certain circumstances, the Rule Maker may be both of these entities. Depending on the device, the Rule Maker may or may not be the individual most closely aligned with the Target. For instance, a child carrying a cell phone may be the Target, but the parent of that child would likely be the Rule Maker for the Device. Giving the Rule Maker control is a potential opportunity to buttress the consent component of the collection limitation and finality principles discussed above.
所与のデバイスのためのルールメーカーは、一般のユーザ、またはデバイスの所有者のいずれかであろう。特定の状況では、ルールのメーカーは、これらのエンティティの両方であってもよいです。デバイスに応じて、ルールのメーカーは、または最も密接にターゲットに合わせ個別であってもなくてもよいです。例えば、携帯電話を運ぶ子供がターゲットかもしれないが、その子の親は、おそらくデバイスのためのルールメーカーになります。ルールメーカーの制御を与えることは、上述の収集制限とファイナリティ原理の同意成分をバットレスする可能性の機会です。
Because some Rule Makers may not be informed about the role Rules play in the disclosure of their LI, Geopriv should include default Rules. The Rule Maker is, of course, always free to change his or her Rules to provide more or less protection. To protect privacy and physical safety, default Rules should, at a minimum, limit disclosure and retention of LI.
いくつかのルールメーカーはルールが自分のLIの開示において果たす役割について通知されない場合がありますので、Geoprivは、デフォルトのルールを含める必要があります。ルールのメーカーは常に、もちろん、多かれ少なかれ保護を提供するために彼または彼女のルールを変更して自由です。プライバシーと物理的な安全性を保護するために、デフォルトのルールでは、最低でも、開示やLIの保持を制限する必要があります。
Default Rules are also necessary for so-called "dumb" Location Generators (LG). If a LG is unable to determine the Rules set by the Rule Maker before publishing the LO on to a Location Server, it is important that some default Rules protect that LO in transit, and ensure that the LO is eventually only sent to authorized Location Recipients. These default LG Rules would help prevent many of the threats discussed in this document. The Rule Maker should be able to determine the content of these default Rules at any time.
デフォルトのルールは、いわゆる「ダム」の場所・ジェネレータ（LG）のためにも必要です。 LG場所サーバーにLOを公開する前に、ルールメーカーによって設定されたルールを決定することができない場合、いくつかのデフォルトルールが輸送中にLOことを保護し、LOが最終的にのみ許可所在地の受信者に送信されることを保証することが重要です。これらのデフォルトLGのルールは、この文書で説明した脅威の多くを防ぐのに役立つでしょう。ルールのメーカーは、いつでもこれらのデフォルトルールの内容を決定することができるはずです。
A Viewer should not be aware of the full Rules defined by the Rule Maker. The Viewer will only need to be aware of those Rules it must obey (i.e., those regarding its use and retention of the LI). Other Rules, such as those specifying the accuracy or filtering of the LI, or rules that do not cover the given interaction should not be revealed to the Viewer. This countermeasure is consistent with the minimization component of the collection limitation principle and ensures that the Rule Maker reveals only what he intends to reveal.
Viewerは、ルールメーカーによって定義された完全なルールを意識するべきではありません。ビューアは、それが従わなければならないこれらのルールを認識する必要があります（つまり、その使用およびLIの保持に関するものを）。例えば、Li、又は所与の相互作用をカバーしていないルールの精度やフィルタリングを指定するもののような他のルールは、視聴者に明らかにされるべきではありません。この対策は、収集制限の原則の最小化成分と一致しており、ルールのメーカーは、彼は明らかにするつもりだけで何を明らかにすることを保証します。
Security of LI at the device level is a bit complicated, as the Rule Maker has no real control over what is done with the LI once it arrives at the Location Recipient. If certain Rules travel with the LO, the Rule Maker can encourage Viewer compliance with its Rules. Potentially, a Rule could travel with the LO indicating when it was time to purge the data, preventing the compilation of a "log" of the Target's LI on any Device involved in the transmission of the LO. Allowing Rules to travel with the LO has the potential to limit the opportunity for traffic analysis attacks.
ルールのメーカーは、それは場所の受信者に到達した後、LIで行われているものの上には本当のコントロールを持っていないとして、デバイスレベルでのLIのセキュリティは、少し複雑です。一定のルールがLOで旅行する場合、ルールのメーカーは、その規則にビューアの遵守を促すことができます。潜在的に、ルールは、LOの伝達に関与する任意のデバイス上で、対象者LIの「ログ」のコンパイルを防止すること、データをパージする時間だったときを示すLOと一緒に旅行ができます。ルールは、LOと一緒に旅行できるようにすると、トラフィック解析攻撃の機会を制限する可能性を秘めています。
Identities are an extremely important component of the LO. While, in many instances, some form of identification of the Target, Rule Maker, and Viewer will be necessary for authentication, there are various methods to separate these authentication "credentials" from the true identity of these devices. These countermeasures are particularly useful in that compromise of a log of LI, no matter where the source, is less threatening to privacy when the Target's identity is stripped.
アイデンティティは、LOの極めて重要な構成要素です。 、多くの場合、いくつかのターゲットの識別の形式、ルールメーカー、およびViewerは、認証のために必要となりますが、これらのデバイスの正体から、これらの認証「資格証明書」を分離するための様々な方法があります。これらの対策は、LIのログの妥協、対象者の身元が取り除かれたときソースは、以下のプライバシーに威嚇されていない問題で、特に有用です。
Short-Lived identifiers would allow the using protocol to hide the true identity of the Rule Maker and the Target from Location Servers or Location Recipients. These identifiers would still allow authentication, ensuring that only appropriate Location Recipients received the LO. At the same time, however, making these identifiers short-lived helps prevent any association of a true identity of a Target with particular habits and associates.
短命の識別子が使用してプロトコルがロケーションサーバや場所の受信者からのルールメーカーとターゲットの本当の身元を隠すことができるようになります。これらの識別子は、まだのみ適切な位置の受信者がLOを受信したことを確実に、認証を可能にするであろう。しかし同時に、これらの識別子は短命作ることは、特定の習慣や仲間とターゲットの真のアイデンティティの任意の関連付けを防ぐことができます。
6.2.2. Unlinked Pseudonyms May Protect the Location Recipients' Identity
6.2.2. 場所受信者のアイデンティティを保護することができるリンクされていない仮名
Unlinked pseudonyms would protect the identity of the Location Recipients in much the same manner as short-lived identifiers would protect the Target's identity. When using both, any record that a Location Server had of a transaction would have two "credentials" associated with an LI transmission: one linked to the Target and one linked to the Location Recipient. These credentials would allow the Location Server to authenticate the transmission without ever acquiring knowledge of the true identities of the individuals associated with each side of the transaction.
短命の識別子が対象の身元を保護するようリンクされていない仮名はほぼ同じ方法で場所受信者の身元を保護します。 1がターゲットにリンクされ、もう1つは場所の受信者にリンクされている：両方を使用する場合は、ロケーションサーバは、トランザクションの持っていたすべてのレコードがLIの伝送に関連する2つの「資格証明書」を持っているでしょう。これらの資格情報は、ロケーションサーバは、これまで取引の各側面に関連した個人の真のアイデンティティの知識を取得せずに伝送を認証できるようになります。
The attacks described in this document motivate the following security properties for the connections between the Location Generator and Location Server, the Location Server and Rule Maker, and the Location Server and Location Recipient:
この文書で説明された攻撃は場所ジェネレータおよびロケーションサーバ、ロケーションサーバとルールメーカー、およびロケーションサーバと場所受信者間の接続のために、以下のセキュリティプロパティを動機づけ：
The Rule Maker might be able to set a Rule that disallows a certain number of requests made within a specific period of time. This type of arrangement would allow the Rule Maker to somewhat prevent attackers from detecting patterns in randomly coarsened data. To an "untrusted" Location Recipient, for example, to whom the Rule Maker only wants to reveal LI that is coarsened to the level of a city, only one request might be honored every 2 hours. This would prevent Location Recipients from sending repeated requests to gain more accurate presence information.
ルールのメーカーは、特定の期間内で行われた特定の数の要求を禁止するルールを設定することができるかもしれません。このタイプの構成は、ルールメーカーは多少ランダムに粗大化データのパターンを検出することから攻撃を防ぐことを可能にします。 「信頼できない」場所の受信者に、例えば、ルールメーカーは唯一の都市のレベルに粗大化されたLIを明らかにしたい人には、唯一の要求は2時間ごとに表彰される可能性があります。これは、より正確なプレゼンス情報を得るために繰り返し要求を送信場所の受信者を防止するであろう。
Similarly, thresholds on notifications of location information can help to combat amplification attacks.
同様に、位置情報の通知のしきい値は、増幅攻撃に対抗するために助けることができます。
Authentication is crucial to the security of LI during transmission. The Location Server must be capable of authenticating Location Recipients to prevent impersonation. Location Generators must be capable of authenticating Location Servers to ensure that raw location information is not sent to improper entities. Additionally, Location Servers must be able to authenticate Rule Makers to ensure that unauthorized entities cannot change Rules.
認証は、送信中のLIのセキュリティに不可欠です。ロケーションサーバは、偽装を防ぐために、場所の受信者を認証することが可能でなければなりません。場所ジェネレータは、生の位置情報が不適切なエンティティに送信されないことを保証するために、ロケーションサーバを認証することが可能でなければなりません。また、ロケーションサーバは、不正なエンティティがルールを変更することはできませんことを保証するために、ルールのメーカーを認証することができなければなりません。
The LO must maintain integrity at all points of communication between Location Servers and Location Recipients. Confidentiality is required on both the connection between the Location Generator and the Location Server, as well as on the connection between the Location Server and any given Location Recipient. Confidentiality of Rules sent over the network to the Location Server is of comparable importance.
LOは、ロケーションサーバ及びロケーション受信者との間の通信の全ての点で完全性を維持しなければなりません。機密性は、場所ジェネレータと場所サーバーの間の接続だけでなく、ロケーションサーバと任意の場所受信者との間の接続の両方に必要とされます。ロケーションサーバにネットワークを介して送信されるルールの機密性は同等で重要です。
Replay protection prevents an attacker from capturing a particular piece of location information and replaying it at a later time in order to convince Viewers of an erroneous location for the target. Both Location Recipients and Location Servers, depending on their capabilities, may need replay protection.
再生保護は、位置情報の特定の部分を捕捉し、ターゲットのための誤った場所の視聴者を説得するために、後でそれを再生から攻撃を防止します。どちらの場所受信者とロケーションサーバは、その能力に応じて、リプレイ保護が必要な場合があります。
This informational document characterizes potential security threats targeting the Geopriv architecture.
この情報文書はGeoprivアーキテクチャをターゲットと潜在的なセキュリティ上の脅威を特徴付けます。
This document introduces no additional considerations for IANA.
この文書は、IANAのための追加の考慮事項を紹介しません。
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, "Geopriv Requirements", RFC 3693, January 2004.
[1]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年1月。
Michelle Engelhardt Danley Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
ミシェル・エンゲルハルトDanleyサミュエルソン法律、技術・カリフォルニアの法律大学バークレー、CA 94720 USAの公共政策クリニックBoaltホールスクール
EMail: mre213@nyu.edu URI: http://www.law.berkeley.edu/cenpro/samuelson/
電子メール：mre213@nyu.edu URI：http://www.law.berkeley.edu/cenpro/samuelson/
Deirdre Mulligan Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
ディアドラマリガンサミュエルソン法律、技術・カリフォルニアの法律大学バークレー、CA 94720 USAの公共政策クリニックBoaltホールスクール
EMail: dmulligan@law.berkeley.edu URI: http://www.law.berkeley.edu/cenpro/samuelson/
電子メール：dmulligan@law.berkeley.edu URI：http://www.law.berkeley.edu/cenpro/samuelson/
John B. Morris, Jr. Center for Democracy & Technology 1634 I Street NW Suite 1100 Washington, DC 20006 USA
ジョン・B・モリス、民主主義とテクノロジー1634 IストリートNWスイート1100ワシントンD.C. 20006 USAのためのジュニアセンター
EMail: jmorris@cdt.org URI: http://www.cdt.org
電子メール：jmorris@cdt.org URI：http://www.cdt.org
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520 USA
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。