[要約] RFC 3694は、Geoprivプロトコルの脅威分析に関するドキュメントであり、プロトコルのセキュリティ上の問題と脆弱性を調査しています。目的は、Geoprivプロトコルのセキュリティを向上させるためのガイドラインを提供することです。
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
GEOPRIVプロトコルの脅威分析
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）The Internet Society（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を送信および受け取るエンティティと契約が存在しないエンティティと契約上の関係を持っている状況を説明します。GEOPRIVオブジェクトに、LIを管理する技術、ターゲットビューアー関係、または基礎となる法的枠組みをサポートするように要求すると、プライバシーの保護と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アーキテクチャは、オープンなインターネットに展開されます。これは、潜在的な攻撃者がワイヤー上のパケットを検査し、インターネットアドレスをスプーフィングし、大規模なサービス拒否攻撃を開始できるセキュリティ環境で展開されます。一部のアーキテクチャでは、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.
集中サーバーが一連の「シーカー」への「ハイダー」の場所に関するヒントを提供する従来の非表示に基づいた位置ベースのコンピューターゲームを想像してください。シーカーには非常に粗い位置データへのアクセスが与えられますが、単一の審判には、Hiderのフィルタリングされていない正確な位置情報へのアクセスが与えられます。各シーカーには、ロケーションサーバーからの粗いポジショニングデータをフィードするワイヤレスデバイス（Geoprivアーキテクチャ、場所の受信者）があります。Hiderには、ロケーションサーバーに位置情報を送信するデバイス（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プロトコルを攻撃して不正行為をしたい場合、Hiderの正確な位置を学ぶためにそのような攻撃を実施する方法はいくつかあります。それらは、2つのネットワーク接続のいずれかを盗聴します - ロケーションジェネレーターとロケーションサーバーの間の接続、またはロケーションサーバーと審判のロケーション受信者（正確な情報を受信する）の間の接続。また、フィルター処理されていない位置情報を受け取るために、審判に位置サーバーになりすまそうとするかもしれません。あるいは、Hiderが運ぶロケーションジェネレーターにロケーションサーバーになりすまして、正確な位置情報へのアクセスも可能にする可能性があります。最後に、詐欺師はルールメーカーとして行動しようとすることができ、それにより、ロケーションサーバーにルールを提供すると、詐欺師の場所の受信者が無視されていない位置情報へのアクセスが可能になります。
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が送信された瞬間に、無許可のエンティティがIDとターゲットの場所の両方にアクセスするリスクを生み出します。
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自体を傍受できる場合、他の脅威が提起されます。雇用主が従業員の位置情報を要求する上記の例に戻りましょう。この例では、そのような過去の1つの取引の傍受は、関係を明らかにすることに加えて、関係する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プロトコルには、増幅攻撃の機会があるようです。ロケーションジェネレーターがロケーション情報を公開すると、ロケーションサーバーは爆発者として機能し、この情報を多数のターゲットに配信する可能性があります。ロケーションジェネレーターが非常に迅速な位置の更新を提供する場合（特に高帯域幅のワイヤレス環境では、リンク速度が対応できる限り）、同様のレートでシーカーにプロキシ情報をプロキシ情報する場所サーバーであった場合、これは問題になる可能性があります。多数の探求者が同じユーザーを追跡しています。
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.
また、ロケーションサーバーに関連するほとんどの操作には、おそらく暗号化認証が必要であることに注意してください。暗号化操作には、ロケーションサーバーの側の計算費用が必要です。これは、攻撃者がロケーションサーバーに、ロケーションジェネレーター、ロケーション受信者、またはルールメーカーから来るように見えるようにスプーフィングされているGeopriv情報をflood濫させる魅力的な手段を提供する可能性があります。ロケーションサーバーは、これらのGEOPRIVメッセージによって提示された資格情報を確認するためにリソースを消費する必要があるため、GEOPRIV情報の洪水は、一般的なパケット洪水に基づいてサービス拒否攻撃よりも大きな影響を与える可能性があります。
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が妥協する可能性を追加します。ターゲット/視聴者が公共の場所に座って、ターゲットの家から別の場所への道順を要求する場合、デバイスの出力を聞くことができる人は誰でも、ターゲットの身元、その居住地、そしておそらくそれらが向かっている場所を決定できるかもしれません。
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.
ルール自体は、ターゲットに関する情報を明らかにする場合があります。上記のようなルールは、2人の個人間の雇用関係と、従業員が雇用主から何かを隠していたという事実を明確に明らかにするでしょう。
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を侵害します。LOSのデフォルトのルールがなければ、多数のデバイスがデフォルトで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はさまざまな攻撃に対して完全に脆弱になります。この問題に対処するには、デフォルトのルールが必要です。
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.
たとえば、デフォルトのルールがなければ、デバイスは、近隔で近くの人に信号を送り、それを照会した人に応答したり、不明なエンティティに信号を送信したりする場合があります。
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が何のために使用されているかについて通知する必要があります。Opennessは、秘密システムの作成を防ぐために設計されています。
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. 収集制限：データは合法かつ公正な手段によって収集されるべきであり、必要に応じて、被験者の知識または同意を得て収集する必要があります。データ収集は、トランザクションをサポートするために必要なものと最小限に抑える必要があります。収集に制限を設けることは、過剰な収集の危険から個人を保護するのに役立ちます - あまりにも多くの情報を収集すること、またはあまりにも長い間情報を収集するという点で。
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.
視聴者は、ルールメーカーによって定義された完全なルールを認識してはなりません。視聴者は、従わなければならない規則（つまり、その使用と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で移動して、データをパージする時期を示すことができ、LOの送信に関与するデバイスでターゲットのLIの「ログ」の編集を防ぐことができます。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の非常に重要なコンポーネントです。多くの場合、ターゲット、ルールメーカー、および視聴者の何らかの形の識別が認証に必要になりますが、これらのデバイスの真のアイデンティティからこれらの認証「資格情報」を分離するさまざまな方法があります。これらの対策は、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を受け取ったことを保証します。ただし、同時に、これらの識別子を短命にすることで、ターゲットの真のアイデンティティと特定の習慣と仲間の関連性を防ぐのに役立ちます。
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.
リンクされていない仮名は、短命の識別子がターゲットの身元を保護するのとほぼ同じ方法で、場所の受信者の身元を保護します。両方を使用する場合、トランザクションのロケーションサーバーが持っていたレコードには、LI送信に関連付けられた2つの「資格情報」があります。1つはターゲットにリンクされ、1つはロケーション受信者にリンクされています。これらの資格情報により、ロケーションサーバーは、トランザクションの各側に関連付けられている個人の真のアイデンティティに関する知識を獲得することなく、送信を認証することができます。
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時間ごとに1つのリクエストのみが尊重される可能性があります。これにより、場所の受信者は、より正確な存在情報情報を取得するために繰り返しのリクエストを送信することができなくなります。
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] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Reportion」、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
ミシェル・エンゲルハルト・ダンリー・サミュエルソン・ロー、テクノロジー・アンド・パブリック・ポリシー・クリニック・ボルト・ホール・スクール・オブ・カリフォルニア大学バークレー校、カリフォルニア州94720 USA
EMail: 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
Deirdre Mulligan Samuelson Law、Technology＆Public Policy Clinic Boalt Hall School of California University of California Berkeley、CA 94720 USA
EMail: 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 Street NW Suite 1100 Washington、DC 20006 USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 USA
Phone: +1 925/363-8720
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。