Request for Comments: 3694 D. Mulligan
Category: Informational Samuelson Law, Technology & Public Policy Clinic
J. Morris
Center for Democracy & Technology
J. Peterson
NeuStar
February 2004
Threat Analysis of the Geopriv Protocol
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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.
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. Introduction
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.
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.
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.
2. Habitat of the Geopriv Protocol
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.
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.
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.
3. Motivations of Attackers of 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.
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.
4. Representative Attacks on Geopriv
4.1. Protocol Attacks
4.1.1. Eavesdropping and/or Interception
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.
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.
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 Servers must be capable of authenticating and authorizing
Location Recipients to prevent impersonation.
o Similarly, Location Generators must be capable of authenticating
and authorizing Location Servers in order to prevent
impersonation.
o Finally, the Location Server must be able to authenticate Rule
Makers, to make sure that unauthorized parties cannot change
rules.
4.1.2. Identity Spoofing
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?
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 Location Recipients must be capable of authenticating Location
Servers.
o Location information must be protected from replay attacks.
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.
4.1.3. Information Gathering
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.
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.
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.
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 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 Servers must be capable of authenticating Location
Recipients to prevent impersonation.
o Location Servers must be able to authenticate Rule Makers to
ensure that unauthorized entities cannot change rules.
4.1.4. Denial of Service
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.
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.
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.
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 The Rule Maker must be able to provision policies that limit the
rate at which Location Information is sent to prevent
amplification attacks.
4.2. Host Attacks
4.2.1. Data Stored at Servers
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.
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.2.2. Data Stored in Devices
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.
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.
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.