Location Privacy based on Trusted Computing and Secure

Location Privacy based on
Trusted Computing and Secure Logging
Urs Hengartner
Cheriton School of Computer Science
University of Waterloo
Waterloo ON, N2L 3G1, Canada
Many operators of cellphone networks now offer locationbased services to their customers, whereby an operator often outsources service provisioning to a third-party provider.
Since a person’s location could reveal sensitive information
about the person, the operator must ensure that the service provider processes location information about the operator’s customers in a privacy-preserving way. So far, this
assurance has been based on a legal contract between the operator and the provider. However, there has been no technical mechanism that lets the operator verify whether the
provider adheres to the privacy policy outlined in the contract. We propose an architecture for location-based services
based on Trusted Computing and Secure Logging that provides such a technical mechanism. Trusted Computing lets
an operator query the configuration of a location-based service. The operator will hand over location information to
the service only if the service is configured such that the service provider cannot get access to location information using
software-based attacks. This includes passive attacks, where
the provider monitors information flowing into and out of its
service, and active attacks, where the provider modifies or
injects customer queries to the service. We introduce several requirements that must be satisfied by a location-based
service to defend against passive attacks. Furthermore, we
present Secure Logging, an auditing mechanism to defend
against active attacks.
The ubiquity of cellphones has led many operators of cellphone networks to offer location-based services to their customers, allowing these customers to map their current location, learn about interesting, nearby places, locate other cellphone users, etc. Often, an operator outsources the provisioning of a location-based service to a third-party provider.
This outsourcing raises privacy concerns. Namely, the knowledge of a person’s current or past locations could reveal sensitive information about the person’s interests, her health, or
her political preferences. Therefore, location information itself is sensitive, and the operator should have assurance that
the service provider deals with location information about
the operator’s customers in a privacy-preserving way, based
on a given privacy policy. So far, this assurance has relied
on a legal contract between the operator and the provider.
However, there has been no technical mechanism that lets an
operator verify whether the provider adheres to the privacy
In this paper, we present an architecture for locationbased services that provides such a mechanism. Our architecture exploits Trusted Computing technologies [22] to
let an operator gather information about the configuration
of the platform that provides a location-based service. The
operator hands over location information to the platform
only if the platform is configured to implement an outlined
privacy policy. Here, we are interested in the most constrained case where the policy states that the service platform must provide its service such that the service provider
cannot learn any location information.
Unfortunately, giving a comprehensive guarantee that covers all possible attempts by a service provider to get access
to location information is likely impossible. However, we can
provide a weaker, but still useful guarantee. Namely, we can
guarantee that, using software-based attempts only, the service provider will not be able to learn fine-grained location
information. This guarantee is superior to the non-technical
guarantees offered by current location-based services.
The usage of Trusted Computing technologies to inspect
the configuration of a service has already been suggested [14,
20]. We address two additional challenges. First, the earlier work has not considered how interactions of the service
(e.g., a web server) with the backend infrastructure (e.g., a
database) could lead to information leaks. We show that,
in a passive attack, the service provider could learn location
information by observing the composition or the timing of
information flowing into and out of the service platform.
Second, the earlier work includes an entire application, such
Categories and Subject Descriptors
C.2.0 [General]: Security and protection
General Terms
Design, Security
Location-based Services, Timing Attacks, Trusted Platform
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SecureComm 2008. September 22-25, 2008, Istanbul, Turkey.
Copyright 2008 ACM 978-1-60558-241-2 ...$5.00.
as a web server consisting of thousands of lines of code, in
the computing base that is remotely inspected and subsequently trusted. The size of such an application makes it
likely that there is a vulnerability that a service provider
could exploit. Therefore, we do not want to include an entire location-based service in the trusted computing base.
Instead, only the part that needs direct access to location
information (about 400 lines of code for our sample locationbased services) should be included, but not, for example, the
access-control part. However, this approach enables active
attacks by a service provider, where the provider modifies or
injects queries to the service to learn location information.
We make the following contributions:
• We build an architecture for the privacy-preserving
processing of location information based on Trusted
Computing technologies.
• We give a set of requirements that need to be satisfied
to defend against passive attacks by a service provider.
• We present Secure Logging, an auditing mechanism
that allows the retroactive detection of active attacks
by a service provider.
In the extended version of this paper [11], we present an
implementation, security analysis, and performance evaluation of our architecture. We presented a preliminary version
of our architecture in a workshop paper [10], omitting the
requirements needed to defend against passive attacks, the
protocol to validate satisfaction of these requirements, and
Secure Logging.
In the rest of this paper, we first present our system and
threat models (Section 2). We then introduce our architecture (Section 3). Next, we examine two of its components in
more detail, the Trusted Module (Section 4) and Secure Logging (Section 5). We then present a sample location-based
service built using this architecture (Section 6). Finally, we
survey related work (Section 7).
In our system model, the operator of a cellphone network
and the provider of a location-based service are separate
entities. There are two infrastructures, the cellphone infrastructure, run by the operator of the cellphone network,
and the service infrastructure, run by the provider of the
location-based service. The cellphone infrastructure keeps
track of the location of cellphones by observing which cell
towers a cellphone is connecting to or by directly getting
location information from GPS-enhanced cellphones. When
asked for by the service infrastructure, typically as a consequence of a query by a cellphone user, the cellphone infrastructure hands over location information, maybe in processed form, to the service infrastructure. Several network
operators in the UK, such as Vodafone or Orange, provide
their customers’ location to service providers, such as mapAmobile [4] or World-Tracker.Com [24]. Sprint and Bell
Canada use WaveMarket’s Family Finder [23] to provide
location-based services. Lots of existing location privacy
research is also based on this system model [1, 7, 13, 16, 18,
Our threat model consists of a service provider learning
a user’s fine-grained location. The provider can perform
software-based attacks to extract this information from the
service infrastructure, but no hardware-based attacks or attacks based on physical user observation. These attacks
are more expensive to perform. Also, defending against
software-based attacks still gives us better privacy than what
existing location-based services provide. We also assume
that a service provider can observe the input and the output flowing into and out of the service platform and modify or inject queries sent to the platform. Finally, for efficiency reasons, we allow the service provider to learn a user’s
coarse-grained location. As it turns out, this happens only
for some location-based services, not all of them.
Our threat model allows a service provider to learn the
identity of its users. For some services, such as a service to
locate interesting, nearby places, it is straightforward (ignoring billing challenges) to extend our approach such that
the service provider does not learn identity information; the
cellphone infrastructure simply anonymizes a query before
sending it to the service infrastructure. For other services,
such as a service to locate nearby friends, where the service
infrastructure needs information about friend relationships,
the solution is less obvious and topic of future research.
Figure 1 shows our architecture for location-based services. In the cellphone infrastructure, we leave away components not relevant in this paper, such as cell towers. The
cellphone infrastructure consists of a set of modules and
communication links between these modules, where both the
modules and the links are under the control of the network
operator. The same applies to the service infrastructure,
which is under the control of the service provider. Communication between modules belonging to different infrastructures takes place over TLS with client and server authentication, which avoids sniffing, modification and injection
attacks by outsiders.
Attestation Queries
Initially, the Attestation Module in the cellphone infrastructure queries the service infrastructure for the configuration of the Trusted Module (see Section 4.2 for details).
It does so by sending an attestation query to the Query
Processor Module in the service infrastructure, whose task
is to receive different kinds of queries, to ensure that they
are authorized, to process them if necessary, and to forward
them to another module. In the attestation case, the module
forwards the query to the Trusted Module and returns the
response (“quote”) to the Attestation Module. If this module
is satisfied with the reported configuration (i.e., the configuration does not leak location information, see Section 4.1),
it will give a symmetric key to the Trusted Module such that
the Query Processor Module cannot learn the key. Later, the
cellphone infrastructure will use the key for encrypting location information before handing the information over to the
service infrastructure. This way, the Trusted Module, but
not the Query Processor Module (or the service provider),
can decrypt and learn location information.
Service and Location Queries
A cellphone user who wants to access a location-based
service sends a service query to the cellphone infrastructure,
namely, to the Forwarder Module. The Forwarder Module
checks validity of the query based on information in the User
Database (e.g., did the user sign up to the location-based
Service Infrastructure
Cellphone Infrastructure
Place Query
Log Entry
Place User
Query Query
Service Query
Query Processor
Service Query
Attestation Query
Service Query
Location Query
Location Query
Attestation Query
Figure 1: Architecture for location-based services. A cellphone sends a service query via the cellphone
infrastructure to the service infrastructure, which uses the Trusted Module for processing the query and
generating a response. Items in bold are encrypted (Response and Location).
service?). For accountability reasons, the module then signs
the query and sends it to the location-based service, in particular, to the Query Processor Module. This module validates the signature of the query. For some services, such as
a service that checks whether a friend is nearby, the module
must also ensure that the cellphone user issuing the query
is authorized to learn whether the queried person is nearby.
Authorization information is stored in the User Database. If
the query is authorized, the Query Processor Module sends
a location query to the Locator Module in the cellphone infrastructure to retrieve the location information required for
processing the query, such as the location of the user’s and
her friend’s cellphone. The Locator Module returns location information only in encrypted form, namely, encrypted
with the symmetric key introduced in Section 3.1. Next, the
Query Processor Module hands over the location information, the operator’s public key, and logging information (see
Section 5) to the Trusted Module.
The Trusted Module decrypts the location information. If
necessary, as in the case of a query for interesting, nearby
places or for traffic conditions, the module asks the Places
Database via the Query Processor Module for location-specific
information, such as road maps or conditions, weather information, shops, or restaurants. The Trusted Module then
generates and signs its response and encrypts it with the operator’s public key. To detect misbehaviour by the service
provider, the module generates logging information, which
it hands over to the Logger Module (see Section 5). The
Trusted Module gives its response to the Query Processor Module, which forwards it to the Forwarder Module for
decryption and signature checking. Finally, the Forwarder
Module forwards the plaintext response to the cellphone.
The Trusted Module is at the core of a location-based service and generates responses to service queries. The module
is deployed by the service provider and has access to location
information. Nonetheless, the service provider should not
have access to this information. As stated in Section 2, we
assume that the provider can perform only software-based
attacks to gain access to the information. We discuss the set
of requirements that need to be satisfied in order to defend
against these attacks in Section 4.1. To ensure that a platform actually fulfills these requirements, a network operator
uses the concept of remote attestation, which we discuss in
Section 4.2.
Avoiding Information Leaks
To infer a cellphone’s location, the service provider can
mount various software-based attacks: First, the provider
can observe the input given to the Trusted Module. Second, the provider can observe the output generated by the
module. Third, the provider can observe the delay between
input and output events. Fourth, the provider can examine
the memory used by the module. We now examine each of
these attacks.
Input Attacks
There are two kinds of input that are given to the Trusted
Module and that could reveal a cellphone’s location. First,
there is actual location information. As discussed in Section 3.1, we require that location information is encrypted
before it is given to the Trusted Module. The service provider
does not know the decryption key, so the ciphertext is useless to the provider. Second, there is information about
places (e.g., their locations), as retrieved from the Places
Database. By examining which records the Trusted Module
requests from the database, the provider could learn a user’s
location. We could avoid this attack by including the entire Places Database in the Trusted Module. However, this
would drastically increase the size of the trusted computing
base, whereas our goal is to keep it as small as possible. As
discussed in Section 7, Private Information Retrieval (PIR)
schemes also avoid this attack, but tend to be inefficient. We
use a compromise that is more efficient, but that lets the service provider learn some information about a user’s location.
In particular, we require the Trusted Module to cloak a user’s
location before accessing the Places Database. For example,
when the user is at the train station, the module determines
a larger area that includes the train station, retrieves information about all the places in the cloaked area from the
Places Database, and filters information about places that
are too far away when generating a response. This way, the
service provider can learn the area in which the person is,
but not where exactly. Cloaking has been used extensively
for providing location privacy [2, 5, 7, 9, 16].
Output Attacks
There are two kinds of output from the Trusted Module
that could reveal location information: Responses to service
queries and log entries sent to the Logger Module. For the
first kind, we require that the Trusted Module encrypts responses with the operator’s public key. For the second kind,
we require that log entries do not contain location information. Instead, they contain only information about service
queries and about the public key used for encrypting responses to these queries (see Section 5).
Encrypting the response to a service query is not always
sufficient to prevent the response from leaking location information. We also require that there always is an output, regardless of a cellphone’s location. For example, in a parentchild tracking service, the parent gets alerted when the child
leaves a boundary area, where the boundary area is known to
the service provider. To implement this service, the Query
Processor Module periodically invokes the Trusted Module,
which determines whether the current location is outside of
the boundary area. If the module returned a response only
in the positive case, information would leak to the Query
Processor Module. Therefore, the Trusted Module always
has to generate a response and the content of the response
must not leak any information. For example, the response
could be the semantically secure encryption of the value zero
or one.
Furthermore, we require that the size of the output of
the Trusted Module is determined by the user’s cloaked location, not her precise location. For example, when the
Trusted Module uses cloaked location information to access
the Places Database and filters the records received from
the database, the response generated by the module must
not allow the provider to learn how many of the records got
filtered. See the extended version of this paper [11] for an
implementation of this scheme.
Finally, the Trusted Module could output location information using some other means, such as writing the information to a file or to a display. We require that the Trusted
Module does not generate output information apart from the
output shown in Figure 1.
Timing Attacks
The service provider could measure the delay between giving a service query to the Trusted Module and getting back
a response. If different query outcomes resulted in different
delays, measuring the delay could leak location information.
We require that the processing time of the Trusted Module is
independent of the query outcome. For example, for a service that checks for a nearby friend, the delay must be the
same, regardless whether the friend is nearby or not. To
strictly enforce this property, we would have to guarantee
that the number of consumed CPU cycles is identical in either case, which is difficult to enforce in practice. Instead,
in our sample location-based services, we ensure that the
executed code path is identical in either case and that the
only difference is the outcome of one or multiple statements
comparing variables. For example, for a nearby-friends service, we have the module compute distance dist between
two cellphones and then determine the query response as
response = (dist <= nearby);
where nearby indicates the distance considered nearby. In a
more complex example, the following statements determine
whether a cellphone at position (x,y) is within a rectangular
area (x1,y1)-(x2,y2):
cond1 = (x >= x1);
cond2 = (x <= x2);
cond3 = (y >= y1);
cond4 = (y <= y2);
sum = cond1 + cond2 + cond3 + cond4;
response = (sum == 4);
In the extended version of this paper [11], we show that
the observed timing differences for the code examples shown
above are orders of magnitudes smaller than what is required
for a successful timing attack.
Memory Attacks
The service provider might try to extract location information or the symmetric decryption key from the memory
used by the Trusted Module. We require that the provider
cannot access this memory using software-based mechanisms.
In our sample location-based services, we deploy the Trusted
Module on a dedicated machine and configure the machine
such that the provider cannot log in to it.
Remote Attestation
In Section 4.1, we came up with a set of requirements
that the Trusted Module must satisfy to prevent location
information from leaking. Of course, the developer of the
Trusted Module, who could be identical with the service
provider, might not actually address these requirements in
the implementation. To ensure that our requirements are
being satisfied, we use remote attestation.
Remote attestation is a feature proposed by the Trusted
Computing Group (TCG) [22]. With the help of an inexpensive chip (in TCG terminology, the Trusted Platform
Module (TPM)) soldered to the motherboard of a computer,
this feature allows an entity to remotely gather information about the code running on this computer. Starting
at boot time, each piece of running code (including BIOS
code) gathers information about the next piece of code to be
loaded and executed and stores this information in the TPM.
This process is called a measurement. The TPM guarantees
that measurements cannot be reverted (using software-based
mechanisms). Therefore, we end up with a chain of measurements, rooted at the static root of trust, which typically is
part of the computer’s BIOS. If the entity asking a remote
computer to perform a remote attestation trusts this root,
the TPM, and each piece of loaded code, the entity can retrieve the measurement list from the TPM and infer what
code is loaded and executed on the computer. In practice,
a TPM does not store a measurement list, only a cryptographic digest, and the actual list is kept by the measuring
code (see Sailer et al. [20] for details). A remote attestation
returns the list and its digest, signed by the TPM, to the
querying entity. A signed digest is called a quote.
Going back to the Trusted Module, the network operator
exploits remote attestation to retrieve the measurement list
from the module, which will allow the operator to learn the
configuration of the module. The operator compares the received list to a list of approved measurements. Software is
in an approved state if it is in a given state (e.g., a particular binary with a set of configuration parameters), as in the
case of a kernel, or if it satisfies the requirements discussed
in Section 4.1, as in the case of a component implementing a particular location-based service. To build the list of
approved measurements, the operator must have had access
to the software (including source code, binaries, and compiler) beforehand for inspection purposes. If the operator
can validate the received list of measurements, the operator
will hand over the symmetric key that allows decryption of
location information to the Trusted Module.
We show the protocol for this transfer in Table 1; it is
partially based on earlier work [15, 20]. We assume that
the configuration of the Trusted Module has been measured
in the TPM as part of the boot process. When asking for
a remote attestation, the Attestation Module generates a
nonce and sends it to the Trusted Module, which generates
an asymmetric key pair. The public key, P ublicT ransf er ,
will be given to the Attestation Module, which will employ it to transfer the symmetric key used for encrypting
location information to the Trusted Module. By measuring P ublicT ransf er in the TPM, the Trusted Module guarantees to the Attestation Module that the key pair was
created by the Trusted Module and that the private key,
P rivateT ransf er , is kept within the module and will be erased
from memory after the transfer, as a defense against coldboot attacks [8].
The Trusted Module hands over the nonce received from
the Attestation Module to the TPM and requests a quote.
The returned quote includes the nonce and is signed with
a private key embedded in the TPM (in TCG terminology,
the private key of the Attestation Identity Key (AIK) pair).
The Attestation Module knows the corresponding public
key. The Trusted Module returns the quote, the measurement list, and P ublicT ransf er to the Attestation Module,
which recomputes the measurement list based on the expected configuration of the Trusted Module. The Attestation Module cannot simply look at the quoted digest, since
this value depends on the order in which the OS running on
the Trusted Module’s computer loads kernel modules and
applications, which can differ slightly across reboots. If
there are any values in the measurement list that are unknown to the Attestation Module, the module aborts the
protocol. Else, the Attestation Module uses P ublicT ransf er
to encrypt the symmetric key and sends the ciphertext to
the Trusted Module.
An operator might repeat remote attestation periodically
(e.g., in an attempt to detect time-of-check, time-of-use (TOCTOU) attacks). Here, the Trusted Module also has to hand
over previously used P ublicT ransf er so that the Attestation
Module can recompute the measurement list.
The Trusted Module invokes the Logger Module to keep a
log of its actions. These actions are requested by the Query
Processor Module. With the help of the log, we can detect wrongly requested actions, that is, misbehaviour by the
Query Processor Module (i.e., the service provider). For
example, this module is expected to run access control for
some location-based services, such as ensuring that only authorized people can track a person. If the module did not run
access control and allowed, for example, the service provider
to track the person, a corresponding log entry would make
the person aware of this violation, and she would alert the
network operator.
An alternative approach is to run access control in the
Trusted Module. However, we would like to keep this module as simple as possible, which decreases the likelihood of a
vulnerability in the module and also makes it easier for an
operator to check the module’s correctness. Furthermore, a
service provider could be reluctant to implement the entire
service within the Trusted Module, since part of this implementation might be proprietary, and the provider does not
want to reveal it to an operator for inspection.
Our goal is to log each access to a person’s location such
that log entries cannot be tampered with or removed. For
each access to a person’s location, logging should enable
this person to learn 1) the service query that triggered this
access and 2) the public key that was used for encrypting the
response to this query. In Sections 5.1 and 5.2, we discuss
how we support these requirements. In Section 5.3, we show
how we use the logged information to detect misbehaviour.
Logged Information
A log entry is generated by the Trusted Module whenever it accesses somebody’s location. An entry contains an
identifier unique for the user whose location was accessed, a
cryptographic digest of the service query that triggered this
access, and a cryptographic digest of the public key used
for encrypting the module’s response (see Table 2). It is
possible to log additional information, such as the accessed
location information (in encrypted form) or the response to
a query, but this is not required by our threat model.
The user identifier will be used during log checking to
learn whose location information was accessed. This identifier is communicated to the Trusted Module by the Locator
Module, together with the (encrypted) location information.
A message authentication code protects their integrity.
The query digest is computed by the Query Processor
Module and given to the Trusted Module. The Query Processor Module needs to store the corresponding service query.
The Query Processor Module also hands over the operator’s public key to the Trusted Module so that the module
can encrypt the response to a query. A malicious Query
Processor Module could hand over its own public key, which
would allow it to decrypt the response. Therefore, the Trusted
Module, not the Query Processor Module, computes the digest of the received public key to be included in the log entry.
We let the Query Processor Module compute the digest of a
(signed) query because the module gains no advantage from
cheating here.
A single query can result in multiple log entries. For example, in a nearby-friends service, if Alice tries to locate Bob,
the Trusted Module logs accesses to both Alice and Bob’s
location, each entry containing a digest of Alice’s query. The
operator inserts a nonce into a query to detect replay attacks
by the Query Processor Module (e.g., in a timing attack).
Tampering and Removal Attacks
To protect log entries against tampering, the Trusted Module signs each entry before handing it over to the Logger
Module. The Trusted Module logs the public key for the
signing key in certified form whenever the module is initialized. The certificate is signed with the TPM’s AIK private
key. We cannot use this key directly for signing a log entry,
since it can be used only for signing keys.
To protect log entries against their removal, the Trusted
Module includes the current value of a monotonically in-
Attestation Module → Trusted Module:
Trusted Module:
Trusted Module → Attestation Module:
Attestation Module:
Attestation Module → Trusted Module:
Trusted Module:
generate key pair (P ublicT ransf er , P rivateT ransf er ), measure P ublicT ransf er
in TPM, hand over nonce to TPM, retrieve quote
measurement list M L, SP rivateAIK (nonce||digest(M L)), P ublicT ransf er
check quote signature, re-compute and approve M L, abort if failure
EP ublicT ransf er (SymmetricKey)
retrieve SymmetricKey, erase P rivateT ransf er
Table 1: Transfer protocol for symmetric key. SF oo () is a signing operation with key F oo, EBar () an encryption
operation with key Bar.
TPM Software
Log entry
AIK-certified signature
user id query digest
user id query digest
special log entry
AIK-certified signature
user id query digest
special log entry
AIK-certified signature
user id query digest
verification key
public key digest
public key digest
verification key
public key digest
verification key
public key digest
Table 2: Log format. A signature covers the counter and the log entry.
creasing counter in each entry and increases this counter after generating an entry. Here, the module needs to be able
to reliably determine the value of this counter in case of a
restart of the module. A possible approach is to use a TPM
v1.2 monotonic counter, which is a counter within the TPM
that can never be decreased. A problem with such a counter
is that a TPM might support increases only once every five
seconds to avoid burnouts. To increase logging frequency, we
divide time into epochs. An epoch corresponds to the time
between the initialization of the Trusted Module and its shut
down. We use a TPM v1.2 monotonic counter to denote the
current epoch and a software-based monotonic counter to
denote time within an epoch. The Trusted Module includes
the current values of both counters in a log entry. The module increases the TPM v1.2 monotonic counter only during
module initialization. At the same time, the software-based
counter is set to zero. This counter is increased after generating a log entry, which results in a global order among the
log entries.
The above algorithm ensures that, given a log entry, we
can detect removal of earlier log entries that have the same
TPM v1.2 monotonic counter value. However, the algorithm
does not protect against the removal of more recent log entries (i.e., with larger software-based or TPM counter values) or against the removal of log entries with lower TPM
v1.2 monotonic counter values. For example, given a log
entry with a TPM v1.2 monotonic counter value of 5, all
we can say is there are must be log entries with TPM v1.2
monotonic counter values of 0, 1,..., 4, but not how many of
each kind. There could also be log entries with TPM v1.2
monotonic counter values of 6, 7,... Let us discuss how we
address these two attacks.
For the first attack, we want to ensure to a cellphone user
that the last log entry seen by her when checking the log is
the most recent log entry generated by the Trusted Module
for an access to her location information (or close to the most
recent one, since new entries can be added while the user is
checking log entries). We can satisfy this condition by making the user send a query that accesses her location information to the location-based service before the user checks
her log entries. This way, the Trusted Module will create a
new log entry, and the user can verify whether there is an
entry for her query in the log. If so, the log is up to date.
The second attack can be avoided by having the Trusted
Module generate a special log entry whenever the service
provider makes the module shut down. This way, an increase in the value of the TPM v1.2 monotonic counter, as
observed in the log, is always preceded by such a special entry, and missing log entries can be detected (see Table 2).
The absence of a special entry does not necessarily imply malicious behaviour. For instance, the Trusted Module could
have crashed or there might have been a power outage, which
prevented the module from creating the special entry. However, an operator should get suspicious if there are many
missing special log entries. Then, either the location-based
service is unreliable or there is widespread removal of log
entries. Neither of the options is in the operator’s interest,
and the operator should stop using the service.
Log Validation
Consistent with the architecture described in Section 3,
we assume that the operator will take care of the cryptographic operations required for log validation. If a log entry
is considered valid, the operator will forward the query that
triggered access to a particular user’s location to this user
for inspection. In more detail, log validation consists of the
following steps:
1. The user issues a service query, where processing of
the query requires access to her location information.
This will create a log entry.
2. The operator downloads the log (i.e., the entries added
since the previous validation) from the service platform. The operator checks the digital signature of each
entry and ensures that the counter values are monotonically increasing and complete.
3. The operator determines the log entries relevant to the
user based on the user identifier and asks the service
provider for the corresponding service queries. The operator ensures that the digests of the received queries
match the logged digests and that the queries are properly formed and fresh. The operator also checks whether
the query issued in step 1) is in the log.
4. The operator ensures that the logged digests of the
public key match the digest of the public key of the
operator. If so, the query is forwarded to the user.
5. The user inspects the received queries. If she detects
an unauthorized query, she will alert the operator.
Let us illustrate our architecture by demonstrating how
it can be used to implement a service that allows a user to
learn whether a friend of hers is nearby. Here, the user sends
a query listing the name of the friend to the Forwarder Module, which signs the query, adds the (encrypted) location of
the user’s cellphone, and forwards it to the Query Processor
Module. (Including the location with a query is an optimization to the architecture discussed in Section 3.2.) The
Query Processor Module retrieves the friend’s policy from
the User Database and ensures that the friend has granted
access to the user. If so, the module requests the location
of the friend’s cellphone from the Locator Module. Next, it
hands the two locations and the operator’s public key over
to the Trusted Module.
The Trusted Module uses the symmetric key received during attestation to decrypt the two locations and determines
whether they are nearby. Depending on the result, it signs a
byte of value either zero or one with its private key, encrypts
everything with the operator’s public key, and returns the
ciphertext to the Query Processor Module, which sends it to
the Forwarder Module. This module decrypts the ciphertext
and sends the result to the cellphone. The Trusted Module
also logs two accesses to the user’s and her friend’s location.
Research in location privacy has studied how to address
the apparent contradiction, where, on the one hand, a locationbased service needs access to location information to be useful, but, on the other hand, it should not have this access
because of privacy concerns. A popular approach is location
cloaking [2, 5, 7, 9, 16], where only coarse-grained, less intrusive location information is given to a location-based service.
Other work [1, 18] has suggested the usage of pseudonyms
to keep a person’s identity hidden from a service. However,
some location-based services do require fine-grained location
information or information about the person’s identity, else
service quality could suffer [2]. Services that alert parents
when their child leaves a boundary area or that alert people
of nearby friends fall into this category. Our architecture
supports such services.
Kölsch et al. [13] also examine location privacy in a setup
where the network operator and the service provider are different entities. They introduce a trusted third party that
tracks users and that alerts the service provider when the
user is in a particular area. The authors do not present an
implementation of their concept, in particular, they do not
discuss who acts as this third party. Our Trusted Module,
as introduced in Section 3, can be looked at as such a third
party. Apart from having a proof-of-concept implementation, our architecture has the additional advantage that it
can exploit identity information and fine-grained location information, which increases service quality, whereas the previous work relies on coarse-grained location information and
pseudonyms. Ravi et al. [19] have a service provider migrate
the code that implements a location-based service to a network operator. The operator uses information flow control
to ensure that the code does not leak a cellphone’s finegrained location to the provider. This approach is targeted
at services that exploit aggregate location information and
does not support services that require fine-grained location,
as supported by our solution.
The usage of Trusted Computing or similar technologies
for privacy protection has been proposed in earlier work.
Molnar et al. [17] give a secret required for reading RFID
tags to a reader only if the reader passes a remote configuration check. There is no implementation of this idea and
no discussion of how the operator of a reader might indirectly gain access to data read by the reader. Iliev and
Smith [12] deploy a tamperproof coprocessor at a server
and use it for implementing a Private Information Retrieval
(PIR) scheme [3], which allows database accesses without
the owner of the database learning which records are being
accessed. We could use PIR to let a cellphone retrieve information about interesting places close to its location without the service provider operating the database learning the
location. However, Iliev and Smith’s scheme calls for periodic re-shuffles of all the records in the database, which is
expensive. Efficient PIR schemes that do not require a tamperproof coprocessor (e.g., by Goldberg [6]) touch all the
records in the database for each access. Our compromise,
as explained in Section 4.1, is more efficient, but reveals
coarse-grained location information to the service provider.
Previous research has explored the usage of Trusted Computing technologies to validate the configuration of a remote
server [14, 20]. Here, a client ensures that the server (e.g.,
a web server) has not been tampered with and that it corresponds to an approved version. Our problem is harder
because of the presence of the service provider, who can
passively and actively intercept queries/responses flowing
into/out of the service platform, which might leak location
information (see Section 4.1). Moreover, to limit the danger
of an exploitable vulnerability being present in the configuration trusted by the client, we do not include an entire
server in this configuration, only the part that directly deals
with location information. Finally, we give a set of requirements that need to be satisfied in order for a particular version of software getting approval, which is a topic that has
been neglected in previous work.
In terms of Secure Logging, Schneier and Kelsey [21] look
at logging in the presence of an attacker. However, their
threat model is different from ours. They are concerned
about an attacker breaking into a machine, like a service
provider managing to subvert our architecture, and modify-
ing existing log entries. This is not a threat that we study
in this paper, so the previous research is orthogonal to ours.
A problem that we, but not the previous work, study is how
to securely initialize the logging process upon a reboot of
the service platform.
We have demonstrated that it is possible to build locationbased services for which the service provider does not become aware of users’ fine-grained location. In addition to
keeping location information away from a service provider
by encrypting it, we have also addressed several other passive and active attacks that a service provider might perform
to gain access to this information.
Future work involves studying solutions based on a dynamic root of trust and applying our approach to protect
the privacy of personal information other than location information, not necessarily only in location-based services.
We thank the anonymous reviewers for their comments. This
work is supported by the Natural Sciences and Engineering
Research Council of Canada.
[1] A. R. Beresford and F. Stajano. Location Privacy in
Pervasive Computing. IEEE Pervasive Computing,
2(1):46–55, 2003.
[2] R. Cheng, Y. Zhang, E. Bertino, and S. Prabhakar.
Preserving User Location Privacy in Mobile Data
Management Infrastructures. In Proceedings of PET
2006, June 2006.
[3] B. Chor, E. Kushilevitz, O. Goldreich, and M. Sudan.
Private Information Retrieval. Journal of the ACM,
45(6):965–981, 1998.
[4] Cybit Ltd. mapAmobile.
http://www.mapamobile.com. Accessed June 2008.
[5] G. Ghinita, P. Kalnis, and S. Skiadopoulos. PRIVÉ:
Anonymous Location-Based Queries in Distributed
Mobile Systems. In Proceedings of 16th International
World Wide Web Conference (WWW2007), pages
371–380, May 2007.
[6] I. Goldberg. Improving the Robustness of Private
Information Retrieval. In Proceedings of IEEE Security
and Privacy Symposium, pages 131–148, May 2007.
[7] M. Gruteser and D. Grunwald. Anonymous Usage of
Location-Based Services Through Spatial and
Temporal Cloaking. In Proceedings of 1st International
Conference on Mobile Systems, Applications, and
Services (MobiSys 2003), pages 31–42, May 2003.
[8] J. A. Halderman, S. D. Schoen, N. Heninger,
W. Clarkson, W. Paul, J. A. Calandrino, A. J.
Feldman, J. Appelbaum, and E. W. Felten. Lest We
Remember: Cold Boot Attacks on Encryption Keys.
In Proceedings of 17th USENIX Security Symposium,
July/August 2008.
[9] T. Hashem and L. Kulik. Safeguarding Location
Privacy in Wireless Ad-Hoc Networks. In Proceedings
of 9th International Conference on Ubiquitous
Computing (UbiComp 2007), pages 372–390,
September 2007.
[10] U. Hengartner. Hiding Location Information from
Location-Based Services. In Proceedings of
International Workshop on Privacy-Aware
Location-based Mobile Services (PALMS), May 2007.
[11] U. Hengartner. Design and Evaluation of an
Architecture for Location Privacy. Technical Report
CACR 2008-14, Centre for Applied Cryptographic
Research, University of Waterloo, July 2008.
[12] A. Iliev and S. W. Smith. Protecting Client Privacy
with Trusted Computing at the Server. IEEE Security
and Privacy, 3(2):20–28, March/April 2005.
[13] T. Kölsch, L. Fritsch, M. Kohlweiss, and D. Kesdogan.
Privacy for Profitable Location Based Services. In
Proceedings of 2nd International Conference on
Security in Pervasive Computing (SPC 2005), pages
164–178, April 2005.
[14] J. Marchesini, S. W. Smith, O. Wild, J. Stabiner, and
A. Barsamian. Open-Source Applications of TCPA
Hardware. In Proceedings of 20th Annual Computer
Security Applications Conference (ACSAC’04), pages
294–303, December 2004.
[15] J. M. McCune, B. Parno, A. Perrig, M. K. Reiter, and
A. Seshadri. Minimal TCB Code Execution. In
Proceedings of IEEE Security and Privacy Symposium,
pages 267–272, May 2007.
[16] M. F. Mokbel, C.-Y. Chow, and W. G. Aref. The New
Casper: Query Processing for Location Services
without Compromising Privacy. In Proceedings of
32nd International Conference on Very Large Data
Bases (VLDB 2006), pages 763–774, September 2006.
[17] D. Molnar, A. Soppera, and D. Wagner. RFID Privacy
Through Trusted Computing. In Proceedings of
Workshop on Privacy in the Electronic Society
(WPES’05), November 2005.
[18] G. Myles, A. Friday, and N. Davies. Preserving
Privacy in Environments with Location-Based
Applications. Pervasive Computing, 2(1):56–64,
January-March 2003.
[19] N. Ravi, M. Gruteser, and L. Iftode. Non-Inference:
An Information Flow Control Model for
Location-based Services. In Proceedings of 3rd
International Conference on Mobile and Ubiquitous
Systems: Networks and Services (MobiQuitous 2006),
July 2006.
[20] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn.
Design and Implementation of a TCG-based Integrity
Measurement Architecture. In Proceedings of 13th
USENIX Security Symposium, August 2004.
[21] B. Schneier and J. Kelsey. Cryptographic Support for
Secure Logs on Untrusted Machines. In Proceedings of
7th USENIX Security Symposium, pages 53–62,
January 1998.
[22] Trusted Computing Group.
https://www.trustedcomputinggroup.org. Accessed
June 2008.
[23] WaveMarket, Inc. Family Finder.
http://www.wavemarket.com. Accessed June 2008.
[24] World-Tracker.Com. http://www.world-tracker.com.
Accessed June 2008.