RFC3694 日本語訳
3694 Threat Analysis of the Geopriv Protocol. M. Danley, D. Mulligan,J. Morris, J. Peterson. February 2004. (Format: TXT=44364 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Danleyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3694年のD.マリガンカテゴリ: 情報のサミュエルソンLaw、技術、および公共の方針診療所J.モリスはNeuStar2004年2月に民主主義と技術のためにJ.ピーターソンを中心に置きます。
Threat Analysis of the Geopriv Protocol
Geoprivプロトコルの脅威分析
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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要件の参照として数え上げられます。
Danley, et al. Informational [Page 1] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[1ページ]のRFC3694脅威分析
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 Geoprivプロトコル. . . . . . . . . . . . . . . 3 3の生息地。 Geopriv. . . . . . . . . . . . . 4 4の攻撃者の動機。 代表はGeopriv. . . . . . . . . . . . . . 5 4.1で攻撃します。 .1に攻撃. . . . . . . . . . . . . . . . . . . . 5 4.1について議定書の中で述べてください。 盗聴、そして/または、妨害. . . . . . . 5 4.1.2。 アイデンティティスプーフィング. . . . . . . . . . . . . . . 6 4.1.3。 情報収集. . . . . . . . . . . . . 7 4.1.4。 サービス妨害. . . . . . . . . . . . . . . 8 4.2。 .1に攻撃. . . . . . . . . . . . . . . . . . . . . . 9 4.2を主催してください。 サーバ. . . . . . . . . . . . . 9 4.2.2で保存されたデータ。 デバイス. . . . . . . . . . . . . 9 4.2.3で保存されたデータ。 ビューアー. . . . . . . . . . 10 4.2.4で保存されたデータ。 規則. . . . . . . . . 10 4.3で含まれた情報。 用法は.1に.114.3を攻撃します。 脅威はOvercollection. . . . . . . . 11 5によって引き起こされました。 用法違反. . . . . . . . . . . . . 12 5.1のための対策。 公正な情報は.126を練習します。 Geoprivのセキュリティの特性は.136.1について議定書の中で述べます。 対策. . . . . . . . . . . . . . . . 13 6.1.1としての規則。 規則メーカーは.2に規則. . . . . . . . . 13 6.1を定義するべきです。 Geoprivには、省略時の解釈. . . . . . . 14 6.1.3があるはずです。 位置の受取人はすべての規則を意識しているべきではありません。 . . . . . . . . . . . . . . . . . . . . . 14 6.1.4. ある規則は最低気温. . . . 14 6.2とともに旅するべきです。 アイデンティティ. . . . . . . . . . . . . . . . 14 6.2.1の保護。 短命な識別子は目標のアイデンティティ. . . . . . . . . . . . . . . . . . . . 15 6.2.2を保護するかもしれません。 放された匿名は位置の受取人のアイデンティティ. . . . . . . . . . . . . . 15 6.3を保護するかもしれません。 データ. . . . . . . . . . 15 6.3.1の送信の間のセキュリティ。 規則は要求. . . . . . . . . . . . . . . . . . . . 15 6.3.2のある頻度を禁じるかもしれません。 互いのエンドポイント認証. . . . . . . . 16 6.3.3。 データ・オブジェクト保全と秘密性. . . . 16 6.3.4。 保護. . . . . . . . . . . . . . . 16 7を再演してください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 9。 有益な参照. . . . . . . . . . . . . . . . . . . . 16 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 17 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 18
Danley, et al. Informational [Page 2] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[2ページ]のRFC3694脅威分析
1. Introduction
1. 序論
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要件で、Location Object(LO)は多種多様の用途に関するLocation情報(LI)をサポートすることができます。 Geoprivオブジェクト自体が技術中立であることを意図します、さまざまなデバイスがLOの形にLIを供給するのを許容して。 また、Geoprivは、Viewersの多くのクラスがLocation ServerからLIを要求できるのを必要とします。Geopriv要件はTargetがLIを送受信する実体と契約が全く存在しないそれらとの契約上の関係を持っている事情を説明します。 どんな技術もサポートするためにGeoprivオブジェクトを必要として、Target-ビューアー関係、または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が感染される可能性は異なります。 潜在的マーケターに位置情報を販売するサーバは明瞭に肉体攻撃を遂行するためにTargetの現在の位置を妨害する外部の個人より低い危険を引き起こします。 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をよりよく保護する対応策を特定するのに必要です。
2. Habitat of the Geopriv Protocol
2. Geoprivプロトコルの生息地
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トラフィック(特にLocation Generatorと初期のLocation Serverの間のトラフィック)の部分は公共のインターネットに連結しない管理されたネットワークの上に起こるかもしれません。
Danley, et al. Informational [Page 3] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[3ページ]のRFC3694脅威分析
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トランザクションの終点は、Location Generator(ネットワークの見解からの位置情報の源)とLocation Recipientです。 Location GeneratorとLocation Recipientの両方には、Location Serverとの関係があるかもしれません。 Location GeneratorはLocation Server(グルーミング/濾過機能を位置情報に提供するかもしれない)、およびLocation Recipient要求にデータを発表する、そして/または、Geopriv情報がワイヤの向こう側に保護を必要とするかもしれないところで. これが2ポイント提供するLocation Serverから情報を受け取ります。 また、Rule HolderからLocation Serverまでのネットワークの上に規則を通過できます。 これはアーキテクチャがセキュリティを必要とするところにもう1ポイント提供します。
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.
Location GeneratorsとLocation Recipientsが強い暗号のセキュリティが現在法外に計算上高価である安価のデバイスで実装されるかもしれないことに注意するのは重要です。
3. Motivations of Attackers of Geopriv
3. Geoprivの攻撃者の動機
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.
Rule Maker願望より大きい度合いの精度がある位置情報を確かめるためにGeoprivの攻撃者に関する動機が対象の位置を学ぶために、だれがそれらの位置を個人的であるか、または同等に保ちたがっているかがViewersを認可したということであることが最も明白です。 しかしながら、心配をかける他のいくつかの潜在的動機があります。 攻撃者は、Targetの位置が分配されるのを防ぎたいか、Targetの位置を誤り伝えるために位置情報を変更したいか、崩壊させたい、またはまた、この情報を知るのは権限を与えられない第三者にTargetの位置情報を向け直したがっているかもしれません。 攻撃者は、Targetの仲間を特定したいか、またはTargetの習慣かルーチンを学びたがっているかもしれません。 攻撃者はある位置にあるパーティーのすべてのアイデンティティを学びたがっているかもしれません。 最終的に、単にサービス不能攻撃による全体の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の正統の関係者が交換について議定書の中で述べるとき認可されるかもしれませんが、位置情報を乱用する攻撃者のクラスがあります。 これは主体の間の協定のパラメタの外、または、ことによると商業目的か不法な監視の行為として位置情報の分配か蓄積を含んでいます。
Danley, et al. Informational [Page 4] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[4ページ]のRFC3694脅威分析
4. Representative Attacks on Geopriv
4. Geoprivに対する代表している攻撃
4.1. Protocol Attacks
4.1. プロトコル攻撃
4.1.1. Eavesdropping and/or Interception
4.1.1. 盗聴、そして/または、妨害
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'の位置に関して1セットの'探求者'にヒントを提供する。 非常に粗い位置のデータへのアクセスを探求者に与えますが、hiderの非濾過の、そして、正確な位置情報へのアクセスを独身のレフリーに与えます。 それらを粗く食べさせるワイヤレス機器(GeoprivアーキテクチャにおけるLocation Recipient)は各探求者でLocation Serverからデータを置きます。hiderは位置情報をLocation Serverに伝えるデバイス(GPSを使うLocation Generator)を運びます。
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.
探求者のひとりがGeoprivプロトコルを攻撃することによって不正行為をしたかったなら、hiderの正確な位置を学ぶためにそのような攻撃を仕掛けるかもしれない多くの方法があります。 彼らは2人のネットワーク接続のひとりを立ち聞きするかもしれません--Location GeneratorとLocation Serverとの接続かLocation ServerとレフリーのLocation Recipientとの接続(正確な情報を受け取る)のどちらか。 また、彼らは、非濾過のLocation情報を受け取るためにLocation Serverのレフリーをまねるのを試みるかもしれません。 あるいはまた、彼らはhiderによって運ばれたLocation GeneratorにLocation Serverをまねるかもしれません。また、hiderは正確な位置情報へのアクセスをそれらに与えるでしょう。 最終的に、詐欺師は、Rule Makerとして機能するのを試みることができました。(RulesをLocation Serverに供給すると、Rule Makerで、「非-粗雑にな」っている位置情報への詐欺師のLocation Recipientアクセスは可能にされるでしょう)。
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 Location Recipientを考えて、秘密性がLocation GeneratorとLocation Serverとの接続とLocation Serverといずれとの接続の両方で必要です。
o Location Servers must be capable of authenticating and authorizing
Location Recipients to prevent impersonation.
o Location Recipientsを認証して、位置のServersは、ものまねを防ぐために認可できなければなりません。
o Similarly, Location Generators must be capable of authenticating
and authorizing Location Servers in order to prevent
impersonation.
o 同様に、ものまねを防ぐためにLocation Serversを認証して、Location Generatorsは、認可できなければなりません。
Danley, et al. Informational [Page 5] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[5ページ]のRFC3694脅威分析
o Finally, the Location Server must be able to authenticate Rule
Makers, to make sure that unauthorized parties cannot change
rules.
o 最終的に、Location Serverは、Rule Makersを認証して、権限のないパーティーが規則を変えることができないのを確実にすることができなければなりません。
4.1.2. Identity Spoofing
4.1.2. アイデンティティスプーフィング
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人のライバルを雇う場合を考えてください。 1つはクリーブランドへの出張に行きます。 両方のライバルはLocation Generator(セルキャリヤーが三角にすることができる携帯電話などの)によって追跡されるデバイスを運びます、そして、両方のライバルは彼らの(粗い)の位置情報への彼らのボスアクセスを許します。 ホームのままで残っていたライバルは、旅行のライバルが実際にクリーブランドに無味乾燥な技術会議に出席するより南部ビーチでむしろさぼっているのを現れさせるように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.
攻撃者は、Location GeneratorからLocation Serverまでネットワークトラフィックを偽造するのを試みるかもしれません(特にLocation Generatorがサービス不能攻撃などのある他の手段でそれ自身のレポートを発行できないようになったなら)。 攻撃者の目標は、だれかにとって、マイアミで適切な改竄された位置情報を提供するか、または恐らくマイアミへのライバルの前の訪問から本物の位置のオブジェクトを再演するのさえことであるかもしれません。 また、攻撃者はLocation Serverからボスの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 Location ServerがLocation Generatorsを認証する必要があります。
o Location Recipients must be capable of authenticating Location
Servers.
o 位置のRecipientsはLocation Serversを認証できなければなりません。
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.
プロトコルが攻撃されるとき、アイデンティティスプーフィングは追加脅威を作成するかもしれません。 多くの事情では、ViewerのアイデンティティはLIが明らかにされるかどうかと、そうだとすれば、そのLIがどのようにフィルターにかけられるかを制御する基礎です。 その実体のアイデンティティが感染されるなら、プライバシーは脅かされます。 権限のある機関をまねることができるトランザクションのトランザクションの中か外におけるだれでも、秘密情報へのアクセスを得るか、または権限のある機関の名前における誤ったトランスミッションを開始できます。 例えばLocation Recipientのアイデンティティを偽造する能力はアイデンティティとTargetの位置の両方にアクセスする権限のない実体の危険を作成するでしょう、現在、LOを送りました。
Danley, et al. Informational [Page 6] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[6ページ]のRFC3694脅威分析
4.1.3. Information Gathering
4.1.3. 情報収集
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つの実体がどうにかお互いに対話していると決心するかもしれません。 盗聴が時間がたつにつれて続くなら、相互作用の収集は彼らの顧客の雇い主、従業員、およびすべてにかかわるでしょう。 情報に関するそのようなログは、雇い主と従業員が頻繁にお互いに関連していたのを明らかにして、どのクライアントが、より頻繁に組と取り引きしたかを明らかにするでしょう。 したがって、トラヒック分析の脅威はTargetの仲間を決心している立ち聞きする者の危険を作成します。
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.
また、トラヒック分析で、立ち聞きする者は特定の位置の目標のアイデンティティか特性を確かめることができるかもしれません。 特定の位置とLocation Servers(恐らく問題の位置まで見られたワイヤレスかワイヤーラインLANを立ち聞きするのによる)のLocation Generatorsの間のトランスミッションを観測して、次に、ことによると様々なLocation Recipientsにデータに従うのに、攻撃者は、その位置に目標の雇い主を含む仲間を学んで、恐らくさらなるアイデンティティ情報を推定できるかもしれません。
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 Rule Makerは彼らのLIの使用に関してRulesを定義できなければなりません。
Danley, et al. Informational [Page 7] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[7ページ]のRFC3694脅威分析
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 Location ServerとLocation Recipientとの接続が秘密のままで残らなければならないのと同じくらいよくLocation GeneratorとLocation Serverとの接続。
o Location Servers must be capable of authenticating Location
Recipients to prevent impersonation.
o 位置のServersは、ものまねを防ぐためにLocation Recipientsを認証できなければなりません。
o Location Servers must be able to authenticate Rule Makers to
ensure that unauthorized entities cannot change rules.
o 位置のServersは、権限のない実体が規則を変えることができないのを保証するためにRule Makersを認証できなければなりません。
4.1.4. Denial of Service
4.1.4. サービス妨害
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サービスを奪いたがっている党がたぶんただ特定のユーザを狙うよりむしろ彼らの取り組みのLocation Serverに焦点を合わせるでしょう。Location Serverが多くのシナリオで多くのデバイスのための位置情報への管理アクセスの中心的役割をプレーするので、そのようなアーキテクチャでは、それは失敗の自然な単一のポイントです。
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プロトコルは増幅攻撃のいくつかの機会を持っているように見えます。 Location Generatorが位置情報を発表するとき、Location Serverは発破器として機能します、潜在的にこの情報を多数の目標に提供して。 多くのSeekersが同じ追跡ユーザであるときに、Location Generatorが位置(リンク速度が特に高帯域ワイヤレス環境で収容できたのと同じくらい多く)の非常に急速なアップデートを提供するなら、同様のレートにおけるSeekersへのプロキシ情報にLocation Serverがあるなら、これは問題が多くなることができるでしょうに。
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.
また、Location Serverに関連しているほとんどの操作がたぶん暗号の認証を必要とすることに注意してください。 暗号の操作はLocation Server側のコンピュータの費用を伴います。これは攻撃者がLocation Generator、Location Recipient、またはRule Makerから来るように見えるために偽造されるdummied Geopriv情報でLocation Serverをあふれさせる魅力的な手段を提供するかもしれません。 Location Serverがこれらの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 位置のServersは状態がない認証挑戦と認証試みが不必要にシステム資源を消費しないのを保証する同様の測定を使用しなければなりません。
Danley, et al. Informational [Page 8] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[8ページ]のRFC3694脅威分析
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 Rule MakerはLocation情報が増幅攻撃を防ぐために送られるレートを制限する支給方針にできるに違いありません。
4.2. Host Attacks
4.2. ホスト攻撃
4.2.1. Data Stored at Servers
4.2.1. サーバで保存されたデータ
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の偶然の誤用があります。サーバは、怠慢、不注意、または知識不足にかかわらず偶然間違ったLocation RecipientsにLIをリリースしないか、適切に出されるLIをフィルターにかけないかもしれません。 2番目に、サーバは故意にLIを誤用するかもしれません。 サーバは、条項にもかかわらず、Rule MakerのRuleでそれと反対に、それがコンパイルしたTargetかLocation Recipientの「プロフィール」を販売すると決めるかもしれません。 あるいはまた、私利のために、サーバのために働いている個人はLIを入手するサーバへのアクセスを誤用するかもしれません。 最も安全で信じられたサーバがあっても、システムの外におけるだれかがLIを検索するためにそれにハックする危険があります。 最後に、だれかがそうする可能性がいつもあります。法的なシステムを使用します。そのようなプロセスは、Serverからの個人の記録を召喚してください、そして、Targetへの通知もTargetの同意なしでTargetの位置情報の暴露をおそらくもたらすでしょう。
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.
データが瞬間かトランスミッションの瞬間頃に使用されるか、または傍受されるなら、サーバで保存されたデータはTargetの現在の位置を明らかにするかもしれません。 Targetがそれらの現在の位置から近い店まで地図を要求して、Location Serverがその情報を間違ったLocation Recipientに送るなら、ViewerはTargetのアイデンティティ、Targetの現在の位置、およびTargetが率いられるかもしれない位置を知るかもしれません。
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.
また、Location Serverに保存されたデータは上のセクション4.1で議論したトラヒック分析の脅威の多くを作成できます。 LOトランスミッションの事実に得るだけではなく、伝えられたLIにもアクセスを得るなら、その情報へのアクセスのだれでもそのTargetがどれくらい長い、およびだれと共にいたところに関する歴史をまとめることができます。
4.2.2. Data Stored in Devices
4.2.2. デバイスに保存されたデータ
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
Geoprivが技術かDeviceのタイプにいずれも与えていて働かなければならないので、個々のデバイスの特定の脅威の可能性を測定するのは難しいです。 例えば、位置の要求に関するログを維持するどんなデバイスも発信したか、またはLOsは受信したでしょう。
Danley, et al. Informational [Page 9] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[9ページ]のRFC3694脅威分析
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.
上で議論したLocation Serverで保守された情報への同様の脅威を引き起こしてください。 個人のデバイスのための法廷召喚か証明書がさらに、同様のログを明らかにするかもしれません。
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.
さらに、デバイスによって、データが何らかの方法で感染される可能性がいつもあります。 スクリーンがあるDeviceのために、別の個人がDeviceを見る機会にユーザの知識なしで表示させる可能性がいつもあります。 言葉のフィードバック(すなわち、盲人への方向を与える)を提供するDeviceはLIが感染される追加可能性を作成します。 Target/ビューアーが公開の場所で座っていて、Targetのホームからもう1つの位置への方向を要求するなら、Device出力を聞くことができるだれでもTargetのアイデンティティ、それらの住居、およびことによるとそれらがどれであるかに率いられた位置を決定できるかもしれません。
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.
さらに、デバイスが位置情報を保有して、Deviceがなくされているか、または盗まれるなら、Rule Maker以外のだれかが各トランザクションの間、潜在的にLIをだれに送ったかの情報と時と、潜在的にTargetの位置にアクセスできるでしょうに。 そのような情報は、実体がTargetがあったところとどれくらい長い間過去にDeviceの所有者がだれと交際したかに基づいた、重要な個人情報、および各位置を決定するかを可能にするかもしれません。
4.2.3. Data Stored with the Viewer
4.2.3. ビューアーで保存されたデータ
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.
ここで引き起こされた脅威は上でLocation ServersとDevicesと関連して議論したものと同様です。 Viewerに保存されたデータによって引き起こされた脅威を分離する主な目的はトランザクションの複雑さとかかわった他の実体によって、トランザクションにおける様々なポイントでのストレージがもたらすことができるデータが同じタイプのプライバシーリスクに上がるのを示すことです。
4.2.4. Information Contained in Rules
4.2.4. 規則で含まれた情報
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.
多くのインスタンスでは、Rule Makerが作成するRulesはRule MakerかTargetの情報を明らかにするでしょう。 およそ25マイル出されたすべての情報を下がらせる規則はTargetの本当の位置を決定する方法を迎撃戦闘機に教えるかもしれません。 「私がビルにいるときには私がどんな部屋でいるか私のボスに言いなさい、ただし、午前9時と午後5時の間には、私がビルの外にいるときには、私がビルにいると彼に言ってください」と述べるRuleはほとんどの従業員が望んでいるだろうよりはるかに多くの情報を明らかにするでしょう。 そして、「ビル」で指定したLIを受けたLocation Recipientであったどんなボスも、従業員がほかの場所にいたとわかるでしょう。
Danley, et al. Informational [Page 10] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[10ページ]のRFC3694脅威分析
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.
さらに、実体がLocation Serverにおいて、または、Deviceでデータに関するログに近づく手段を持っているなら、Rulesの内容に関する知識はデバイスに関する位置情報の一種の「解読」を何かより正確なものに可能にするでしょうに。 したがって、私のボスは、今、私がどこにいるかを言うことができただけではありませんでしたが、何回、最後の1年間、午前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.
また、Rules自身はTargetの情報を明らかにするかもしれません。 上のものなどの規則は明確に2人の個人の間の雇用関係を明らかにするでしょう、従業員が雇い主から何かを隠していたという事実と同様に。
In combination with other information, the location information may enable the identification of the Target.
他の情報と組み合わせて、位置情報はTargetの識別を可能にするかもしれません。
4.3. Usage Attacks
4.3. 用法攻撃
4.3.1. Threats Posed by Overcollection
4.3.1. Overcollectionによって引き起こされた脅威
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のためのデフォルトRulesがなければ、多くのDevicesがデフォルトでLIを明らかにしそうでしょう。 プライバシー規則はLocation情報の収集、使用、公開、および保有を制御するべきです。 これらの規則は公正な情報習慣に従わなければなりません--セクション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.
技術的に抜け目のないDeviceユーザがそれらの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.
省略時の解釈がなければ、デバイスは、近くにだれへのも外で例えば、それについて質問した近い人はだれにも応じるか、または未知の存在への外にシグナルを送るように一定の間隔を置いて合図するかもしれません。
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.
省略時の解釈の不足、「再配付しない」で、Targetの位置情報を他のものに渡すのをLocation Serverを許容するでしょう。 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を使用しながらサービスとデバイスの使用で引き起こされたプライバシー危険を制限するのに必要です。
Danley, et al. Informational [Page 11] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[11ページ]のRFC3694脅威分析
5. Countermeasures for Usage Violations
5. 用法違反のための対策
5.1. Fair Information Practices
5.1. 公正な情報習慣
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.
公正な情報習慣の原則は収集、使用、メインテナンス、およびセキュリティに関して、ある義務を果たして、それらの情報の取り扱いで、ある適正手続きのような権利を個人情報が集められる個人に与えるために個人情報を扱う実体を必要とします。 公正な情報習慣は、個人に関する個人情報の収集で引き起こされた特定の脅威を防ぐように設計されています。 この理由で、公正な情報習慣は個人情報を扱う技術システムと彼らの使用を治めるRulesに反映されるべきである「対策」です。 公正な情報習慣の簡潔な議論は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. 収集制限: データは、合法的で公正な手段で集められるべきであり、適切であるところに集められるべきです、対象の知識か同意で。 データ収集はトランザクションをサポートするのに必要なそれに最小にされるべきです。 収集に限界を置くのは、ともにあまりに多くの情報を集めることに関する過剰収集かあまりに長い間の期間の情報集めの危険から個人を保護するのを助けます。
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. データの品質: 個人的なデータはそれが集められて、使用される目的に関連しているべきです。 個人情報は、正確で、完全で、タイムリーであるべきです。 データの品質の要件は、個人情報における(適切であるか不適当)の使用から流れることができる特定の種類の害を防ぐように設計されています。
Danley, et al. Informational [Page 12] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[12ページ]のRFC3694脅威分析
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. セキュリティ: 個人的なDataは妥当な安全予防手段によって損失、不正アクセス、破壊、使用、変更、または公開のようなリスクに対して保護されるべきです。 何らかの安全策がLO(すなわち、従業員アクセスをLocation Serversに制限する)の外で行われているかもしれない間、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. 責任: 記録的なキーパーは公正な情報習慣に従うのについて責任があるべきです。 それらが明らかに書かれるなら、それはRule Makerによって書かれたRules、または個々の実体と信じられた実体との契約で個人がこれらの習慣を通常実施しやすいようになるでしょう。
6. Security Properties of the Geopriv Protocol
6. Geoprivプロトコルのセキュリティの特性
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]の要件の間には、何らかのオーバラップがあります。
6.1. Rules as Countermeasures
6.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.
下のセクションは例証するように設計されていて、Rule Makersで決定している明確で、避けられない規則でLIへの多くのインスタンスの脅威におけるそれを制限できるということです。
6.1.1. Rule Maker Should Define Rules
6.1.1. 規則メーカーは規則を定義するべきです。
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.
当然のことのためのDeviceが一般にユーザであるために望んでいるRule Maker、または所有者、Device。 ある特定の状況では、Rule Makerはこれらの実体の両方であるかもしれません。 デバイスによって、Rule Makerは最も密接にTargetに並べられた個人であるかもしれません。 例えば、携帯電話を運ぶ子供はTargetであるかもしれませんが、その子供の親はおそらくDeviceのためのRule Makerでしょう。 Rule Maker支配力を与えるのは、上で議論した収集制限と最終的な状態原則の同意成分を支持する潜在的機会です。
Danley, et al. Informational [Page 13] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[13ページ]のRFC3694脅威分析
6.1.2. Geopriv Should Have Default Rules
6.1.2. Geoprivには、省略時の解釈があるはずです。
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.
いくつかのRule Makersは役割のRulesプレーに関して彼らのLIの公開において知識がないかもしれないので、GeoprivはデフォルトRulesを含んでいるはずです。 Rule Makerは、多少保護を提供するためにもちろん自由にいつもその人のRulesを変えることができます。 プライバシーと身体上の安全を保護するために、最小限で、デフォルトRulesは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.
また、デフォルトRulesもいわゆる「馬鹿な」Location Generators(LG)に必要です。 LGが、Location ServerにLOを発行する前にRulesがRule Makerでセットしたことを決定できないなら、いくつかのデフォルトRulesが、トランジットでそのLOを保護して、LOが結局認可されたLocation Recipientsに送られるだけであるのを確実にするのは、重要です。 これらのデフォルトLG Rulesは、本書では議論した脅威の多くを防ぐのを助けるでしょう。 Rule Makerはいつでも、これらのデフォルトRulesの内容を決定するはずであることができます。
6.1.3. Location Recipient Should Not Be Aware of All Rules
6.1.3. 位置の受取人はすべての規則を意識しているべきではありません。
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はRule Makerによって定義された完全なRulesを意識しているべきではありません。 Viewerは、それが従わなければならないそれらのRules(すなわち、そのLIの使用と保有に関するそれら)を意識している必要があるだけでしょう。 LIの精度かフィルタリングを指定するそれらなどの他のRules、または与えられた相互作用をカバーしない規則をViewerに明らかにするべきではありません。 この対策は、収集制限原則の最小化成分と一致していて、Rule Makerが、彼が何だけを明らかにするつもりであるかを明らかにするのを確実にします。
6.1.4. Certain Rules Should Travel With the LO
6.1.4. ある規則は最低気温とともに旅するべきです。
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のセキュリティは少し複雑です、Rule MakerにいったんLocation Recipientに到着するとLIと共に何をするかのどんな実際のコントロールもないとき。 あるRulesがLOとともに旅するなら、Rule MakerはRulesへのViewerコンプライアンスを奨励できます。 潜在的に、Ruleはいつもうデータを掃除するべき時間であったかを示すLOとともに旅することができました、LOのトランスミッションにかかわるどんなDeviceにおけるTargetのLIの「ログ」の編集を防いで。 RulesがLOとともに旅するのを許容するのにおいて、トラヒック分析攻撃の機会を制限する可能性があります。
6.2. Protection of Identities
6.2. アイデンティティの保護
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
アイデンティティはLOの非常に重要な部品です。 多くのインスタンスでは、何らかの形式のTarget、Rule Maker、およびViewerの識別は認証に必要になるでしょうが、これらのデバイスの本当のアイデンティティとこれらの認証「資格証明書」を切り離す様々なメソッドがあります。 これらの対策はそうです。
Danley, et al. Informational [Page 14] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[14ページ]のRFC3694脅威分析
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.
LIに関するログのその感染で特に役に立ちます、Targetのアイデンティティであるときにソースがプライバシーへの、より少ない脅迫であるどんな問題も剥取られません。
6.2.1. Short-Lived Identifiers May Protect Target's Identity
6.2.1. 短命な識別子は目標のアイデンティティを保護するかもしれません。
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.
急に送られた識別子で、使用プロトコルはLocation ServersかLocation RecipientsからRule MakerとTargetの本当のアイデンティティを隠すことができるでしょう。 適切なLocation RecipientsだけがLOを受けたのを確実にして、これらの識別子はまだ認証を許しているでしょう。 しかしながら、同時にこれらの識別子を短命にするのは、特定の習慣と仲間と共にTargetの本当のアイデンティティのどんな協会も防ぐのを助けます。
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.
短命な識別子がTargetのアイデンティティを保護するように放された匿名は似たり寄ったりの方法によるLocation Recipientsのアイデンティティを保護するでしょう。 両方を使用するとき、Location Serverにはあったトランザクションに関するどんな記録もLIトランスミッションに関連している2「資格証明書」を持っているでしょう: 1つはTargetにリンクされました、そして、1つはLocation Recipientにリンクされました。 これらの資格証明書で、トランザクションのそれぞれの側に関連している個人の本当のアイデンティティに関する知識を習得しないで、Location Serverはトランスミッションを認証できるでしょう。
6.3. Security During Transmission of Data
6.3. データの伝達の間のセキュリティ
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:
本書では説明された攻撃はLocation Generatorと、Location Serverと、Location Serverと、Rule Makerと、Location ServerとLocation Recipientとの接続のための以下のセキュリティの特性を動機づけます:
6.3.1. Rules May Disallow a Certain Frequency of Requests
6.3.1. 規則は要求のある頻度を禁じるかもしれません。
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.
Rule Makerは特定の期間以内にされたある数の要求を禁じるRuleを設定できるかもしれません。 このタイプのアレンジメントで、Rule Makerは、攻撃者が手当たりしだいに粗雑なデータのパターンを検出するのをいくらか防ぐことができるでしょう。 例えば、Rule Makerが都市のレベルに粗雑であるLIを明らかにするだけでありたい「信頼されていない」Location Recipientと、1つの要求だけが2時間毎に光栄に思っているかもしれません。 これは、Location Recipientsが、より正確な存在情報を獲得するという再三の要求を送るのを防ぐでしょう。
Similarly, thresholds on notifications of location information can help to combat amplification attacks.
同様に、位置情報の通知の敷居は、増幅攻撃と戦うのを助けることができます。
Danley, et al. Informational [Page 15] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[15ページ]のRFC3694脅威分析
6.3.2. Mutual End-Point Authentication
6.3.2. 互いのエンドポイント認証
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のセキュリティに重要です。 Location Serverは、ものまねを防ぐためにLocation Recipientsを認証できなければなりません。 位置のGeneratorsは、生の位置情報が不適当な実体に送られないのを保証するためにLocation Serversを認証できなければなりません。 さらに、Location Serversは、権限のない実体がRulesを変えることができないのを保証するためにRule Makersを認証できなければなりません。
6.3.3. Data Object Integrity & Confidentiality
6.3.3. データ・オブジェクト保全と秘密性
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はLocation ServersとLocation Recipientsとのすべてのポイントのコミュニケーションで誠実さを守らなければなりません。 秘密性がLocation GeneratorとLocation Serverとの両方の接続、およびLocation Serverとどんな与えられたLocation Recipientとの接続のときにも必要です。 Location Serverへのネットワークの上に送られたRulesの秘密性は匹敵して重要です。
6.3.4. Replay Protection
6.3.4. 反復操作による保護
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.
反復操作による保護によって、攻撃者は、特定の位置情報を得て、目標のためにViewersに誤った位置を納得させるために後でそれを再演できません。 彼らの能力によって、Location RecipientsとLocation Serversの両方が反復操作による保護を必要とするかもしれません。
7. Security Considerations
7. セキュリティ問題
This informational document characterizes potential security threats targeting the Geopriv architecture.
この情報のドキュメントはGeoprivアーキテクチャを狙う潜在的軍事的脅威を特徴付けます。
8. IANA Considerations
8. IANA問題
This document introduces no additional considerations for IANA.
このドキュメントはIANAのためにどんな追加問題も紹介しません。
9. Informative References
9. 有益な参照
[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要件」、RFC3693、2004年1月。
Danley, et al. Informational [Page 16] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[16ページ]のRFC3694脅威分析
10. Authors' Addresses
10. 作者のアドレス
Michelle Engelhardt Danley Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
ミシェルエンゲルハートDanleyサミュエルソンLaw、技術、および公立の方針診療所ボールト・ホール法学大学院カリフォルニア大学バークレイ校、カリフォルニア94720米国
EMail: mre213@nyu.edu URI: http://www.law.berkeley.edu/cenpro/samuelson/
メール: mre213@nyu.edu ユリ: 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
ディアドラマリガンサミュエルソン法、技術、および公立の方針診療所ボールト・ホール法学大学院カリフォルニア大学バークレー、カリフォルニア94720米国
EMail: dmulligan@law.berkeley.edu URI: http://www.law.berkeley.edu/cenpro/samuelson/
メール: dmulligan@law.berkeley.edu ユリ: 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.モリス、Jr.が民主主義と技術のために1634I通りNWスイートを中心に置く、1100、ワシントン、DC20006米国
EMail: jmorris@cdt.org URI: http://www.cdt.org
メール: jmorris@cdt.org ユリ: http://www.cdt.org
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Danley, et al. Informational [Page 17] RFC 3694 Threat Analysis of the Geopriv Protocol February 2004
Danley、他 Geoprivプロトコル2004年2月の情報[17ページ]のRFC3694脅威分析
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Danley, et al. Informational [Page 18]
Danley、他 情報[18ページ]
一覧
スポンサーリンク
