4.2.3. Data Stored with the Viewer
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.
4.2.4. Information Contained in Rules
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.
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.
The Rules themselves may also reveal information about the Target. A
rule such as the one above would clearly reveal the employment
relationship between the two individuals, as well as the fact that
the employee was hiding something from the employer.
In combination with other information, the location information may
enable the identification of the Target.
4.3. Usage Attacks
4.3.1. Threats Posed by 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.
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.
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.
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.
5. Countermeasures for Usage Violations
5.1. Fair Information Practices
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.
There are seven main principles of fair information practices:
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.
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.
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.
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.
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.
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.
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.
6. Security Properties of the Geopriv Protocol
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].
6.1. Rules as Countermeasures
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.
6.1.1. Rule Maker Should Define Rules
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.
6.1.2. Geopriv Should Have Default Rules
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.
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.
6.1.3. Location Recipient Should Not Be Aware of All Rules
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.
6.1.4. Certain Rules Should Travel With the LO
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.
6.2. Protection of Identities
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.
6.2.1. Short-Lived Identifiers May Protect Target’s Identity
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.
6.2.2. Unlinked Pseudonyms May Protect the Location Recipients’
Identity
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.
6.3. Security During Transmission of Data
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:
6.3.1. Rules May Disallow a Certain Frequency of Requests
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.
Similarly, thresholds on notifications of location information can
help to combat amplification attacks.
6.3.2. Mutual End-Point Authentication
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.
6.3.3. Data Object Integrity & Confidentiality
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.
6.3.4. Replay Protection
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.
7. Security Considerations
This informational document characterizes potential security threats
targeting the Geopriv architecture.
8. IANA Considerations
This document introduces no additional considerations for IANA.
9. Informative References
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk,
"Geopriv Requirements", RFC 3693, January 2004.
10. Authors’ Addresses
Michelle Engelhardt Danley
Samuelson Law, Technology & Public Policy Clinic
Boalt Hall School of Law
University of California
Berkeley, CA 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
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
EMail: jmorris@cdt.org
URI: http://www.cdt.org
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/
11. Full Copyright Statement
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.
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.
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.