anonycast: privacy-preserving location distribution for …t-higuti/papers/ubicomp... ·...
TRANSCRIPT
AnonyCast: Privacy-Preserving Location Distribution forAnonymous Crowd Tracking Systems
Takamasa Higuchi† Paul Martin‡ Supriyo Chakraborty⇤ Mani Srivastava‡
†Osaka University, Japan ‡University of California, Los Angeles, CA ⇤IBM Research, [email protected], [email protected], [email protected], [email protected]
ABSTRACTFusion of infrastructure-based pedestrian tracking systemsand embedded sensors on mobile devices holds promisefor providing accurate positioning in large public buildings.However, privacy concerns regarding handling of sensitiveuser location data potentially disrupt the adoption of such sys-tems. This paper presents AnonyCast, a novel privacy-awaremechanism for delivering precise location information mea-sured by crowd-tracking systems to individual pedestrians’smartphones. AnonyCast uses sparsely placed Bluetooth LowEnergy transmitters to advertise location-dependent, time-varying keys. Using location measurements, AnonyCast esti-mates a subset of keys that each pedestrian’s phone receivesalong its path. By combining a cryptography scheme calledCP-ABE with a novel greedy algorithm for key selection, itencrypts each path before publishing, allowing users to de-crypt only their own trajectories. The results from field exper-iments show that AnonyCast delivers accurate locations over84% of time, bounding probability of unauthorized access toone’s location below 1%.
Author KeywordsLocation privacy; crowd tracking; trajectory identification;ciphertext-policy attribute-based encryption
ACM Classification KeywordsC.5.3 Computer System Implementation: Portable devices;E.3 Data Encryption: Public key cryptosystems
INTRODUCTIONRecent evolution of crowd tracking technologies has en-abled accurate measurement of occupancy and trajectories forpedestrians in indoor spaces using vision [6], radio tomogra-phy [18, 27], and laser range scanners [9, 29]. This in turn hasmotivated research communities in both academia and indus-try to leverage them for marketing [14], crowd management[12], and even optimizing energy expenditures in buildings[1, 23]. As a result, an increasing number of public buildingsare equipped with sensors like cameras or laser range scan-ners and capable of fine-grained crowd behavior analyses.
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected] ’15, September 7–11, 2015, Osaka, Japan.Copyright 2015 c� ACM 978-1-4503-3574-4/15/09...$15.00.http://dx.doi.org/10.1145/2750858.2805827
Given the growing popularity of location-based services formobile devices, it would be natural to expect that the pow-erful measurement capability of such wide-spread sensor in-frastructures could also benefit individual pedestrians walk-ing in indoor spaces. Accurate indoor positioning for mo-bile devices has been a long-standing open problem in ubiq-uitous computing. Currently, the most popular positioningsolution for consumer mobile products is radio fingerprint-ing using Wi-Fi [5, 15] and Bluetooth Low Energy (BLE)radios [7, 8, 17]. However, these approaches often sufferfrom large position errors in practical indoor environmentsdue to dense multi-path signal propagation and low tempo-ral stability of radio fingerprints [4]. Furthermore, the ac-curacy of radio-based positioning systems depends consider-ably on the density of anchor devices (e.g., BLE transmitters)[8]. Since dense anchor deployments obviously cause non-negligible maintenance costs, positioning accuracy is also of-ten limited by operational constraints.
The output of crowd tracking systems is typically a set ofanonymous trajectories which are not associated with any mo-bile device. Therefore, these systems cannot serve alone toprovide mobile devices with their own locations. Recent re-search has bridged this gap by developing trajectory identifi-cation algorithms which find trajectories of individual mobileusers from a set of anonymous trajectories [24, 25, 26]. Theseapproaches assume that the crowd tracking system publishesall of the anonymous trajectories obtained by crowd track-ing sensors via a Wi-Fi network. Each mobile device con-nects to Wi-Fi access points to obtain the published trajecto-ries and then identifies its own location based on the consis-tency between the trajectories and local measurements fromphone-embedded sensors (e.g., accelerometers, gyroscopes,etc.). While these efforts have established an effective wayof utilizing the crowd tracking infrastructure for indoor local-ization, growing awareness of and concern for privacy makessuch unrestricted release of trajectory information a difficultproposition. These systems publish pedestrians’ trajectorieswithout consent and, although the trajectories themselves areanonymous, it is possible for a malicious user to combinethese trajectories with external information (e.g., collected byfollowing an individual for a short period) to deanonymize adesired trajectory. This trajectory can then be used to inferpotentially private information about an individual.
In this paper we present AnonyCast, a privacy preserving lo-cation distribution mechanism for crowd tracking systems.We assume that sensors capable of accurate trajectory mea-
surement (e.g., laser range scanners) are already installed andoperated in a target building for crowd behavior analysis.AnonyCast extends this system to feed the precise trajectorymeasurements to individual mobile phone users in a privacy-preserving manner. The extension is enabled by a small num-ber of BLE transmitters, which are sparsely deployed in theenvironment and periodically advertise location-dependent,time-varying keys. Based on the trajectories measured bythe crowd tracking sensors, the AnonyCast server estimatesa set of keys that each pedestrian’s device is likely to havereceived. The server then uses these keys to encrypt each tra-jectory prior to publishing them, ensuring that mobile phoneusers can gain access to only their own trajectories.
Although the proposed mechanism follows as a natural pri-vacy extension, the following aspects present challenges inits implementation as a practical system: (1) Mobile devicesmay fail to receive advertised keys due to packet loss, evenif they are in close proximity to a BLE transmitter. En-suring that the system provides reasonable accessibility totrajectory information even with such frequent packet lossis difficult. (2) Decryption keys are publicly broadcasted,making it non-trivial to prevent potential privacy leaks byensuring that people other than true owners cannot decryptthe published trajectories. As a solution to these issues, webase our system on the emerging public key cryptographyscheme called Ciphertext-Policy Attribute-Based Encryption(CP-ABE). This allows the sender to specify an access policyon the secret data in the form of a logical expression over pri-vate keys, so that users can decrypt the data only if they havea set of keys that satisfy the policy. Upon this scheme, webuild a framework that probabilistically ensures a desired pri-vacy level. Finally, we build and deploy a prototype systemupon which we conduct field experiments using real crowdtracking sensors and various smartphone models. The re-sults of these experiments show that AnonyCast enables usersto obtain their own precise locations more than 84% of thetime, while bounding the probability of unauthorized accessto one’s location data below 1%. In addition, we conductedextensive simulations to better understand AnonyCast’s per-formance under a variety of conditions and parameters.
The contributions of this paper are summarized as follows:(i) We analyze privacy risks in trajectory identification sys-tems. To the best of our knowledge, this is the first work toexplore the potential privacy risks in utilizing crowd track-ing infrastructures for localization of mobile devices. (ii) Wedesign AnonyCast, a novel location distribution mechanismthat allows mobile users to reliably access accurate trajectorymeasurements from a crowd tracking system without com-promising location privacy. To this end, we develop a com-putationally efficient greedy algorithm that provides strongprobabilistic guarantees on user privacy. (iii) We implement aprototype system and benchmark the performance of Anony-Cast through experiments with real sensor devices as wellas extensive simulations. The experimental results show thatour system can successfully achieve a specified privacy levelwhile providing reasonable accessibility to the trajectory in-formation by the true owner even with severe packet loss.
RELATED WORKOne of the most popular approaches to crowd tracking usesimage sensors (i.e., cameras). The current mainstream invision-based pedestrian tracking systems is to extract the fea-tures that best distinguish pedestrians from images in a train-ing data set and then to use a pattern matching algorithm todetect human bodies [10, 19, 30]. However, the ethics andacceptability of using images from surveillance cameras inpublic spaces for such purposes remains controversial [21], aspersonal identities (e.g., faces) can easily be associated withtrajectories, potentially infringing user privacy.
As alternative solutions, there have been a variety of ap-proaches that track pedestrian locations in an anonymousmanner. Radio tomography [18, 27, 28] employs receivedsignal strength between multiple radio stations to detect hu-man locations, assuming that movement of pedestrians in theenvironment causes temporal variations in the signal strength.Laser range scanners (LRS) have also been explored as a rea-sonable option for accurate and anonymous pedestrian track-ing [9, 29]. This sensor provides precise distance measure-ments to surrounding objects, allowing robust crowd trackingwith sub-meter accuracy. Previous literature has shown thatcapacitive sensor arrays [24] and low-resolution image sen-sors [25] are also suitable for anonymous pedestrian tracking.
Trajectory identification technology has bridged the gapbetween the crowd tracking systems described above andlocation-dependent mobile applications. Teixeila et al. [25]effectively combine a vision-based pedestrian tracking sys-tem with MEMS inertial sensors in mobile phones to enableaccurate indoor positioning. They find the corresponding tra-jectory of each mobile user based on the consistency betweenshapes of the anonymous trajectories and measurements frominertial sensors in the pedestrians’ mobile phones. Sousa etal. [24] developed a similar localization system using capac-itive sensor arrays laid out on a floor. They assume pedes-trians have wearable accelerometers and detect the timing ofwalking steps by both the wearable sensors and the capaci-tive sensors on the floor. Thus trajectory identification canbe done by comparing the sequence of walking steps on theanonymous trajectories. Wada et al. [26] periodically mea-sure proximity between neighboring mobile phones by Blue-tooth radios and evaluate consistency between proximity pat-terns between phones and distances between the anonymoustrajectories. These systems assume that the underlying crowdtracking systems publish all the detected trajectories via a net-work so that mobile phones can locally perform trajectoryidentification to find their own trajectory from a set of anony-mous trajectories. This introduces privacy risks since a pedes-trian’s accurate trajectory can be published without consent.
Some recent work develops mechanisms to prove users’ loca-tions, intending to cope with mobile users who report spoofedlocations to mobile systems [16, 22]. They basically assumethat mobile devices communicate with the neighboring wire-less stations to obtain time-varying tokens as location proofs.Unlike the existing systems, AnonyCast intelligently com-bines multiple location proofs collected on a path to enablesecure delivery of private information (i.e., trajectories).
PRIVACY MODELSIn this section we describe the threat model and privacy re-quirements for AnonyCast.
Threat ModelThis work assumes that a given building has a crowd trackingsystem capable of tracking the locations of pedestrians in anarea of interest in an accurate and anonymous manner. Thecrowd tracking system then publishes the detected trajecto-ries to mobile users for use in location-dependent mobile ap-plications. However, the users may hesitate to subscribe tothe service if there is any concern that the system may asso-ciate the anonymous human trajectories with personal identi-fying information. For example, server operators may try todeanonymize trajectories by associating them with MAC ad-dresses of mobile devices obtained in the process of locationdistribution. This problem is exacerbated if device MAC ad-dresses can be linked to other personal attributes (e.g., phonenumber, home address, etc.). Although some recent mobileoperating systems attempt to reduce this kind of privacy riskby randomly rotating the phone’s Wi-Fi MAC address whileprobing for access points, the device’s original MAC addressis still used once a connection to a specific access point isestablished. Our first goal is to cope with this problem bydesigning a mechanism that enables an operator of the crowdtracking system to deliver the precise location information tomobile users, guaranteeing that this kind of association is notpossible. Thus the users can subscribe to the service even ifthey do not fully trust the system operator.
A privacy threat may also exist among the users: An attacker,say Bob, may attempt to use the published trajectory to learnthe current location of a specific person, say Alice, withouther knowledge. Prior to release, a trajectory is anonymizedby stripping it of all personal identifiers and only a tempo-ral sequence of two dimensional coordinates is published.However, the assumption of anonymity no longer holds inthe presence of external, identifying information—for exam-ple, if Bob follows Alice for a short period of time. If Bobcan follow Alice long enough to uniquely identify and asso-ciate Alice with a specific trajectory in the published data, hecan continue to track her location as long as her trajectory isdetected by the crowd sensing system. A similar attack canbe possible without physically tracking the target person ifher mobility has characteristic patterns. For example, if Bobknows that Alice works at a store in a shopping mall and sheusually goes to a restaurant for lunch at a specific time, Bobmay infer which anonymous trajectory belongs to her.
Privacy RequirementLet T be a set of anonymous trajectories that are detected bythe crowd tracking sensors. We define a pedestrian A as thetrue owner of a trajectory tr
j
2 T if A’s true location hasbeen within d meters of tr
j
for a ratio ✓
own
of time stepsover a recent window W , where d, ✓
own
and W are systemparameters. Otherwise, A is designated as a non-owner oftrajectory tr
j
. Our privacy requirement is that only true own-ers can access each published trajectory. The spatial toler-ance d and the temporal criterion ✓
own
are introduced to offerreasonable accessibility to the trajectory information even if
networked crowd tracking sensors
Clients receive location-dependent
time-varying decryption keys from BLE transmitters
crowd tracking engine AnonyCast server
Wi-Fi access point
raw sensor measurements
anonymous human trajectories
encrypted trajectories
BLE transmitter
Figure 1. A high-level overview of AnonyCast
multiple people move together in a group. While this defini-tion allows people to obtain trajectories of other members inthe same group, this does not introduce any privacy concernsbecause all members are in proximity to each other and canbe considered true owners of the group trajectory.
We define the privacy level of a system by (1�✓
pl
), where ✓pl
is the probability that published trajectories are successfullydecrypted by non-owners. In AnonyCast, ✓
pl
is given as asystem parameter and should be sufficiently small to preventprivacy leakage from the published trajectories.
SYSTEM OVERVIEWIn this section, we outline the architecture and design deci-sions taken to realize privacy-preserving location distribution.
ArchitectureFig. 1 depicts a high-level overview of the AnonyCast sys-tem. We assume that a sensor infrastructure for anonymouscrowd tracking is deployed in the area of interest, trackinglocations of pedestrians in the area. For simplicity of dis-cussion, we assume an LRS-based tracking system hereafter.Note, however, that the basic mechanism of AnonyCast canbe easily extended to other types of sensors provided they cananonymously track pedestrians with sufficient resolution.
In addition to the sensors for anonymous tracking, wesparsely deploy BLE transmitters on the walls or ceilings.Every ⌧ seconds, each transmitter b
i
advertises a location-dependent, time-varying key, say key(b
i
, t) for time t. Mo-bile clients that subscribe to the AnonyCast location serviceprobe these BLE beacons using standard Bluetooth devicediscovery mechanisms and save the corresponding keys in lo-cal storage as evidence that they were within the signal trans-mission range of b
i
at time t.
Here we assume that the AnonyCast server (or simply theserver) maintains the following information: (i) locations ofBLE transmitters, (ii) the keys that are advertised by eachBLE transmitter at each time step, and (iii) the set of anony-mous trajectories T observed during the recent W time steps.If the server and each BLE transmitter share common seed pa-rameters in an installation phase, they can generate the samekeys without the need for communication. For each anony-mous trajectory tr
j
2 T , the server estimates a set of keysK
j
that are likely to be received by the owner’s phone. Thisis derived by calculating the probability of beacon reception
(a) �90 dBm (b) �86 dBmFigure 2. Beacon reception rates for varying transmission powers
based on the Euclidean distance between trj
and each BLEtransmitter, given an empirical radio signal reception model(discussed in the next section). The server then encrypts tr
j
with a subset of the keys in Kj
and publishes all the en-crypted trajectories via the Wi-Fi network.
Subscribers to the location distribution server connect to aWi-Fi access point nearby and receive all encrypted trajecto-ries. Each client can then recover its own trajectory only if ithas the keys that are requested by the server. Thus each tra-jectory is delivered only to its true owner as long as the serverselects the appropriate set of keys for trajectory encryption.
Decentralized Location ServersThe AnonyCast location distribution system is based on a de-centralized architecture in which the system publishes all tra-jectories via a local network so that trajectory identificationcan be performed locally on mobile phones. This is in con-trast to a centralized architecture where each mobile deviceperiodically uploads feature values for trajectory identifica-tion to a server, allowing the server to find and send back theuser’s own trajectory via a secure communication channel. Abasic assumption behind this scheme is that the server is trust-worthy, which may not always hold in practical use cases. Byadopting a decentralized architecture, AnonyCast eliminatesthe need for a trusted central server.
Comparison with Purely BLE-based LocalizationReaders may wonder why the BLE transmitters broadcastkeys rather than their own locations: if they advertise the ref-erence positions, mobile devices can receive these beacons tolocally record their own trajectory. Although this approachdoes not incur any privacy issues, accuracy of such position-ing systems depends considerably on density of transmitters.The recent literature [8] analyzes the accuracy of BLE-basedindoor positioning systems under a variety of configurations,and reports that 6-8 beacons should be available within thesignal reception range of smartphones to achieve sub-meterpositioning accuracy. This means that we need to deploy tensof transmitters to cover, e.g., a wide exhibition venue.
As we discussed in the Introduction section, the recent ma-jor trends for cyber-physical systems, together with the rapidtechnological advancements in big data analytics, have beencontinuously encouraging building managers to consider in-troducing sensor infrastructures for path analysis. The ba-sic motivation behind our work is to extend the anonymouscrowd tracking systems, which are already installed in pub-lic indoor space for crowd behavior analysis, so that they can
help people walking around the building to obtain their ownprecise location information through mobile phones. We willshow in the Evaluation section that AnonyCast can enablerobust delivery of precise location measurements over thewhole simulated exhibition venue of 40m ⇥ 27m by only 4–6BLE transmitters. Thus AnonyCast would provide a strongoption if crowd tracking infrastructures are already installedin the environment.
PRELIMINARYThis section discusses observations from our feasibility studyand the basic idea of the proposed encryption mechanism.
Characteristics of BLE beaconsIn order to meet our privacy requirement, all trajectories areencrypted prior to their release so that users can only decrypttheir own trajectories. To facilitate this decryption, Anony-Cast broadcasts location- and time- dependent keys usingBLE beacons. Thus, BLE propagation characteristics playan important role in the design and feasibility of our system.To explore the characteristics of BLE, we conducted recep-tion rate experiments in an 8m⇥15m-sized room using a com-mercial BLE transmitter [20] and several models of Androidsmartphones (Nexus 4 and Nexus 5 from LG Electronics, andNexus 7 from ASUSTeK). The transmitter was positioned ata height of 1m and programmed to periodically transmit ad-vertisement beacons every 0.5 seconds. Smartphones wereplaced at distances varying from 1-10m away from the trans-mitter and continuously probing for beacons for 300 seconds.
Fig. 2 (a)–(b) show the beacon reception rate for signal trans-mission powers of �90 dBm and �86 dBm, respectively.Due to hardware variations across phone models and Blue-tooth chipsets, the beacon reception rate differs for each ofthe devices evaluated. In addition, because of multipath andfading effects, the reception rate does not always degrademonotonously with distance. Nevertheless, beacon receptionrates clearly tend to decrease with distance, falling to zerowhen the distance exceeds a certain value.
Trajectory Encryption by CP-ABEAs a basic cryptography scheme for our location data dis-tribution mechanism, we harness the emerging concept ofCiphertext-Policy Attribute-Based Encryption (CP-ABE) [3].CP-ABE is a type of public key cryptography that allows flex-ible access control to the encrypted data based on attributesthat each client owns. It assumes that clients have a set ofkeys, each of which is associated with a specific attributesuch as name, title, affiliation, etc. In the encryption process,a party wanting to send a secret message specifies an accesspolicy described in the form of a logical expression over theseattributes. The access policy is then embedded in the cipher-text so that only people who have those attributes, and thushave the corresponding private keys, can decrypt it to accessthe original data. The private keys corresponding to each at-tribute are distributed beforehand via a secure channel.
In AnonyCast, each attribute is no longer associated with anindividual person. Instead, each BLE transmitter has an IDattribute b
i
and a time attribute t, advertising the correspond-ing private keys at the corresponding time. In encrypting
tr1tr0
tr2
t1 t2 t3t4 t5
b1
(b1,t1) (b1,t2)
b2
b3
(b2,t3)
(b3,t4) (b3,t5)
Figure 3. An example scenario
each trajectory, the server builds an access policy based onthe probabilities that the owner has received each key. Con-sider the example scenario shown in Fig. 3, where threeBLE transmitters periodically advertise location-dependent,time-varying keys. During the time window from t
1
to t
5
,crowd tracking sensors detect three anonymous trajectories,namely tr
0
, tr1
and tr2
. Without loss of generality we con-sider an access policy for the trajectory tr
0
. Based on thedistance between tr
0
and each BLE transmitter at each timestep, the server estimates that the owner of tr
0
is likely tohave received key(b
1
, t
1
) and key(b
1
, t
2
) from transmitter b1
,key(b
2
, t
3
) from b
2
, and key(b
3
, t
4
) and key(b
3
, t
5
) from b
3
.In this case, a possible access policy would be “(key(b
1
, t
1
)_key(b
1
, t
2
)_ key(b
2
, t
3
))^ (key(b
3
, t
4
)_ key(b
3
, t
5
)).” Theidea behind this policy is that the three keys in the first clauseserve as evidence that a pedestrian is the owner of tr
0
ratherthan tr
2
, since the owner of tr2
does not likely have anyof these keys. In the same way, the two keys in the secondclause serve as evidence that the pedestrian is the owner oftr
0
rather than tr1
. By concatenating these two clauses byan AND operator, the server can ensure that the owner of tr
0
is uniquely identified against other pedestrians. Obviously,generating such a reasonable access policy becomes muchharder as the number of trajectories, pedestrians, and beaconsincreases. We design an algorithm to solve this problem inthe following sections.
ALGORITHM DESIGNThis section provides detailed discussions on problem formu-lation and algorithm design for the AnonyCast system.
Problem FormulationWe denote a set of anonymous trajectories obtained bythe crowd tracking sensors by T . Each trajectory tr
j
2T is a time series of up to W locations of a singlepedestrian, where W is the window size for trajectoryencryption. Thus a trajectory is denoted by tr
j
=<
trj,t
, trj,t�⌧
, . . . , trj,max(t0,t�(W�1)⌧)
>, where t
0
is thetime when tr
j
first appeared in the sight of the sensors, andtr
j,t
is the estimated location of the pedestrian at time t. Theserver also knows the location of each BLE transmitter b
i
andthe set of all keys K that have been advertised during the re-cent W time steps. We assume that the probability that theowner of tr
j
receives a private key key(b
i
, t) (denoted byp
rcv
(trj
, key(b
i
, t))) is a function of the distance betweeneach point on trajectory tr
j
and each BLE transmitter bi
.
Based on the reception probabilities for the keys advertisedduring the recent W time steps, the server generates an accesspolicy for each trajectory tr
j
2 T .
The goal of access policy generation is to specify a set of ac-ceptable private key combinations such that the system canprobabilistically ensure that a client is the true owner of agiven trajectory if it has received a valid combination of therequested keys. In order to make this guarantee, we have tocalculate the probability that any other clients in the targetfield can receive the requested keys in any of the allowablecombinations, and check that the probability is sufficientlysmaller than that of the true owner. Since the number of pos-sible combinations of private keys is 2|K|, computational costfor the probability calculation amounts to O(|T | ·2|K|
) in theworst case. Although CP-ABE allows for an arbitrary logi-cal formula for an access policy, we limit each access policyby the following rules in order to bound the search space foraccess policy generation.
Rule 1 An access policy C is defined in a conjunctive normalform as follows:
C = C
1
^ C
2
^ · · · ^ C
m
(1)
where each clause C
k
is defined as:
C
k
= key
k,1
_ key
k,2
_ · · · _ key
k,n
. (2)
Rule 2 Each private key in K appears in at most one clausein an access policy C.
The subscripts m and n are the number of clauses in the ac-cess policy C and the number of keys in a clause C
k
, respec-tively. Each key
k,l
in a clause is a private key which is adver-tised by any of the BLE transmitters during the recent W timesteps. Rule 1 does not reduce the description capability of ac-cess policies, because any logical formula can be convertedto such a conjunctive normal form. While the Rule 2 lim-its the types of access structures that a policy can describe,it drastically reduces the computational cost for probabilitycalculation to O(|T | · |K|2) in return.
For simplicity of notation, we represent each clause C
k
in anaccess policy by a set of keys in it, say S
k
. An access policy isthen denoted by S = {S
1
,S2
, . . . ,Sm
}, where each elementSk
corresponds to C
k
in Eq. (1).
Consider access policy generation for a specific trajectorytr
0
, and assume that a certain pedestrian has received aprivate key key(b
i
, t). The probability that she is the trueowner of tr
0
rather than another trajectory trj
(denoted bytr
0
� trj
) can be defined as:
P
id
(tr0
� trj
|key(bi
, t)) =
p
rcv
(tr0,t
, key(b
i
, t))
p
rcv
(tr0,t
, key(b
i
, t)) + p
rcv
(trj,t
, key(b
i
, t))
(3)
We term the probability in Eq. (3) the pair-wise identificationprobability of key(b
i
, t) for tr0
against trj
.
In the same manner, we consider the pair-wise identificationprobability of a given access policy S, assuming that a certainpedestrian has received a set of keys that satisfy S during therecent W time steps. In this case, the probability that sheis the owner of tr
0
rather than another trajectory trj
can be
lower bounded as:
P
id
(tr0
� trj
|S) �Y
Sk2S
p
rcv
(tr0
, key
0(tr
0
, trj
,Sk
))/
(Y
Sk2S
p
rcv
(tr0
, key
0(tr
0
, trj
,Sk
)) +
Y
Sk2S
p
rcv
(trj
|key0(tr0
, trj
,Sk
))
)
(4)
where key
0(tr
0
, trj
,Sk
) = argmin
key2Sk Pid
(tr0
�tr
j
|key) and p
rcv
(tr0
, key(b
i
, t)) = p
rcv
(tr0,t
, key(b
i
, t)).Note that a client can satisfy the access policy S as long asit has at least one key in each clause. Here, we consider theworst case, selecting only a single key with the lowest pair-wise identification capability from each clause.
Our privacy requirement necessitates that the probability thatnon-owners of a trajectory can decrypt it be less than a thresh-old ✓
pl
. Thus the server should build an access policy S thatmeets the following condition:
max
trj2T 0{1� P
id
(tr0
� trj
|S)} < ✓
pl
(5)
where T 0 is a subset of T excluding tr0
itself and trajectorieswhose distance from tr
0
is less than d meters at more thand✓
own
|tr0
|e time steps (trajectories grouped with tr0
).
Given a clause Sk
in an access policy S, the probability thatthe true owner has the keys that satisfy S
k
is calculated by:
P
sat
(Sk
) = 1�Y
key2Sk
(1� p
rcv
(tr0
, key)) . (6)
Likewise the probability that the owner can decrypt the tra-jectory tr
0
is:
P
sat
(S) =Y
Sk2S
P
sat
(Sk
). (7)
Thus, the location distribution server must find an access pol-icy S that maximizes the probability P
sat
(S) while satisfyingthe privacy condition in Eq. (5).
Building Access Policies for Trajectory EncryptionAt each time step, the AnonyCast server builds access poli-cies for each trajectory through the following steps.
Step 1: Estimating the subset of all received keys K0
. Theserver first extracts a set of all the keys K
0
that the ownerof a target trajectory tr
0
is likely to have received during therecent W time steps. For that purpose, it calculates the prob-ability that the owner of tr
0
received each private key (i.e.,p
rcv
(tr0
, key)), and then adds into K0
all the keys whosereception probability is greater than a threshold ✓
rcv
:
K0
= {key(bi
, t) | prcv
(tr0
, key(b
i
, t)) > ✓
rcv
} (8)
Step 2: Clustering the keys in K0
. The server clusters theextracted keys based on similarity in their pairwise identifi-cation probability to form candidates of clauses. We define a
|T 0|-dimensional feature vector for each key key(b
i
, t) in K0
,whose elements are its pair-wise identification probabilitiesfor tr
0
against each of other trajectories trj
: < P
id
(tr0
�tr
j
|key(bi
, t)) | trj
2 T 0>. The server then performs
distance-based clustering in the feature space to form groupsof private keys that have similar pair-wise identification abil-ity. Intuitively, clustering allows the server to avoid placingkeys with dissimilar identification ability in the same clauseand thereby reducing the effectiveness of that clause in distin-guishing a trajectory. We employ hierarchical agglomerativeclustering [13] for key aggregation: This method starts withthose clusters (i.e., clauses) with a single key and then sequen-tially merges the two clusters with the minimum inter-clusterdistance. We define distance between two feature vectors bythe maximum difference in the corresponding elements, anddefine the inter-cluster distance by the maximum distance be-tween all the pairs of feature vectors, each of which belongsto different clusters. This process continues until the mini-mum distance exceeds a pre-defined threshold ✓
dist
. In thispaper, we used a threshold of ✓
dist
= 0.15, which providedthe best performance in our simulated and experimental eval-uations. Consequently, the difference in the pair-wise iden-tification probability P
id
(tr0
� trj
|key) among the keys inthe same cluster is less than ✓
dist
for all trajectories trj
2 T 0.
Step 3: Greedy key selection algorithm. Finally, the serverselects a subset of the clusters (i.e., candidate clauses) aboveto build an access policy. The baseline requirement here isthat the resulting policy meets the privacy condition in Eq.(5). Otherwise, the server should not publish the trajectorytr
0
to avoid the risk that it is decrypted by non-owners. Thepairwise identification probability in Eq. (4) tends to increaseas more clauses are put into the policy. On the other hand,the probability that the true owner can decrypt the trajectory(i.e., Eq. (7)) declines in a monotonic manner as the numberof clauses increases. In order to find a reasonable trade-offbetween these two conflicting factors, we design a greedy al-gorithm with the following reward and cost functions:
reward(Sk
) =
X
trj2T 0
{Pid
(tr0
� trj
|S [ {Sk
})
� P
id
(tr0
� trj
|S)}(9)
cost(Sk
) =
Y
key2Sk
{1� p
rcv
(tr0
, key)} (10)
where S is the set of clauses in the current access policy. Thereward is defined by the marginal gain in the pairwise iden-tification probability obtained by putting S
k
into the accesspolicy, while the cost is defined by the probability that thetrue owner of tr
0
does not receive any of the keys in Sk
.
The server begins with an empty access policy S = �, andsequentially adds the clause S
k
that maximizes the rewardper unit cost (i.e., reward(S
k
)/ cost(Sk
)). Since the rewardof the remaining candidate clauses change by adding a newclause to the access policy, the server updates the rewards foreach clause before selecting the next clause to add. This isrepeated until the access policy S meets the privacy require-ment in Eq. (5), after which the server encrypts the target tra-jectory tr
0
with the resulting policy. If the server cannot meet
random AES key generator
trajectory encryption by AES
access policy generation encrypting AES key by CP-ABE
anonymoustrajectory
AES keyencrypted trajectory
AES key
access policy+ CP-ABE keys + encrypted AES keys
access policy
Wi-Fi
- locations of BLE transmitters- master key for CP-ABE
network
AnonyCast server (1)
(2)
(3) (4) (5)
Figure 4. Steps involved in trajectory encryption at the server
the privacy requirement even after all the candidate clausesare added into the access policy, it suppresses publication oftr
0
at the current time step.
Trajectory Publication and DecryptionAt each time step, the AnonyCast server publishes all the en-crypted trajectories via a local Wi-Fi network. The accesspolicies are also published along with the trajectories to no-tify the clients of the decryption requirements, where the keysin each policy are replaced by key identifiers generated by aone-way hash function. The clients use the same hash func-tion to locally calculate the key identifiers for each privatekey that they have collected. Then each client downloads allof the published trajectories and finds its own trajectory bychecking whether their private keys satisfy the access policyof any of the encrypted trajectories. This process can be doneby a series of set membership tests, in which the client checksif it has at least one key among those requested in each clause.Once it finds a match, it uses the corresponding private keysto decrypt the data and finally obtains its own trajectory.
PROTOTYPE IMPLEMENTATIONAs a proof of concept, we implemented a prototype system ontop of an LRS-based crowd tracking system. In this section,we briefly discuss the implementation of each component.
AnonyCast ServerFig. 4 depicts the steps involved in the generation of the en-crypted trajectory at the server. Technically, the plain text inCP-ABE is limited to an element in a group on an ellipticcurve and cannot directly represent the trajectory data. In-stead, we use Advanced Encryption Standard (AES) for tra-jectory encryption, and randomly sample an AES key fromthe group on an elliptic curve ((1)–(2) in Fig. 4). The Anony-Cast server then (3) builds an access policy using the algo-rithm in the previous section, (4) encrypts the AES key us-ing CP-ABE based on the access policy, and (5) publishesthe encrypted AES key and the access policy along with theencrypted trajectories. Note that different AES keys are gen-erated for each trajectory, and thus only the clients that candecrypt the AES key can access the original trajectory. Thistwo-phase mechanism allows us to deliver arbitrary secretdata from the server to mobile phones. We implemented themodified CP-ABE scheme for trajectory encryption in Pythonby extending the Charm cryptography library [2].
AnonyCast ClientFig. 5 shows steps performed at the AnonyCast client. Uponreceiving the published data via a Wi-Fi network, the client
filtering based on access policy decrypting AES key
decrypting trajectory
{(encrypted AES key,
AES key
trajectory
encrypted AES keyWi-Fi
- received CP-ABE keys- public parameters for CP-ABE
+ CP-ABE keysencrypted trajectory, access policy)}
location-basednetwork mobile apps
encrypted trajectory
AnonyCast client
(2)(1)
(3)
Figure 5. Steps performed at clients for trajectory decryption
Figure 6. Custom BLE transmitters, top and bottom.
first compares the set of decryption keys that has been re-ceived from BLE transmitters over the recent W time stepswith the published access policies, which are associated witheach encrypted trajectory, to quickly find decryptable trajec-tories ((1) in Fig. 5). It then (2) decrypts the AES key withthe received CP-ABE keys so that it can (3) decrypt the cor-responding trajectory. We employed the Charm library on theclient application as well. The library is also supported onAndroid, enabling us to run the client on smartphones.
BLE Transmitters for Decryption Key DistributionFor key distribution, we developed a custom BLE transmit-ter as shown in Fig. 6, in which the advertisement payloads,transmit frequencies, and transmit powers can be changed dy-namically. Many commercial BLE transmitters place limita-tions on the size of user-configurable data that can be placedin a single advertisement packet (e.g., iBeacon devices allowfor 8–20 bytes of configurable data, while the BLE specifi-cation allows for up to 31 bytes of payload). Additionally,commercial BLE transmitters do not typically allow for dy-namic payload or power configuration without manual userintervention. Our custom transmitter is equipped with a TexasInstruments CC2540 BLE chipset and provides 28 bytes ofcustomizable payload out of the 31 byte data field to dis-tribute the private keys (3 bytes must be reserved to specifyadvertisement type and length as per the spec). Dynamicallyconfigurable transmission power and frequency allow for im-proved flexibility of transmitter deployment strategies.
Crowd Tracking Sensors & EngineFor crowd tracking, we deployed UTM-30LX LRS sensors[11] at the height of 1m to track the waists of pedestrians. TheUTM-30LX has a maximum measurement range of 30m, hor-izontal scan angle of 270�, angular resolution of 0.025�, andscan frequency of 40 Hz. Thus, every 0.025 seconds, the sen-sor outputs distance to the nearest objects in each direction.The sensors are connected to the server via a local area net-work to report sensor measurements, which are subsequentlyanalyzed by the Java-based crowd tracking engine.
EVALUATIONWe evaluated the performance of the AnonyCast systemthrough field experiments and computer simulations.
63m
33
.5m
LRS sensor
BLE transmitter
Figure 7. Field experimentFigure 8. Accessibility by each client
(9)
(11)
(13)
(15)
(5)(16)
(1)
(6)
(3)(12)
(7)
(4)
(10)
(2)
(14)
40m
27m
(8)
Figure 9. Simulated exhibition hall
Field ExperimentWe deployed three LRS sensors (UTM-30LX [11]) in corri-dors of our department building, covering the 63m⇥33.5mregion depicted in Fig. 7. The shaded fan-shaped regionsaround the sensors indicate their angular coverage (i.e., 270�),in which the sensors can measure the distance to surround-ing objects within a 30m range. The sensors were connectedto a server machine (Apple Macbook Pro) via Ethernet andUSB cables, and our Java-based server program analyzed themeasurements to derive a set of anonymous trajectories. Dueto limited quantities of custom BLE transmitters, we alterna-tively used commercial BLE transmitters (RadBeacon USB[20]) in this experiment. The transmitters were deployed atsix locations, as indicated by icons in Fig. 9, and periodicallyadvertised radio beacons every 0.5 seconds with transmissionpower of �90 dBm. Since RadBeacons do not allow for dy-namic payload configuration, we simply recorded the bea-con’s MAC address and the corresponding timestamp wheneach client received a beacon, analyzing the beacon receptionlogs offline to evaluate the accessibility and privacy of thepublished trajectories. Five student volunteers walked aroundthe field freely for 6 sessions of 300 seconds each, holdingdifferent smartphone and tablet models (Nexus 4 (N4), Nexus5 (N5), Nexus 7 (N7-1 / N7-2), and Galaxy Note 2 (GN))in hand. The client application on the phones continuouslyprobed the BLE radio beacons, collecting beacon receptionlogs and storing them into local storage for offline analysis.We set the system privacy parameter (1� ✓
pl
) to 0.95, whilethe spatial tolerance d, temporal criterion ✓
own
, and windowsize W are set to 3m, 0.8, and 90 seconds, respectively.
To estimate the clients’ beacon reception probability at theserver side, we provided the AnonyCast server with a slightlymodified version of the experimental model in Fig. 2 (a).Since the server does not know which type of mobile de-vice each user has, it considers the most sensitive device(in this case the Nexus 4) as a reference. On top of thismodel, we introduced a safety margin to conservatively over-estimate reception probabilities. This is done such that theexpected beacon reception probability becomes no less than0.5⇥ (20.0� d)/20.0, were d is distance from the transmit-ter. This helps cope with cases in which clients unexpectedlyreceive BLE beacons from distant transmitters.
For performance metrics, we consider precision and recall ofdecryption under the following definitions. The precision isdefined by TP/(TP+FP ), where TP and FP are the num-ber of correct trajectories that true owners can decrypt and the
number of false trajectories that non-owners can decrypt, re-spectively. The recall is defined by TP/(TP + FN), whereFN is the number of true trajectories that true owners cannotdecrypt. Note that the precision can be interpreted as the pri-vacy level of the location distribution system, while the recallreflects each user’s accessibility to one’s own trajectory.
The time chart in Fig. 8 shows each client’s accessibilityto the published trajectories. The red markers represent thetimes when the client successfully decrypted its own trajec-tory, while blue markers show the times when a client de-crypted another pedestrians’ trajectory. As shown, all clientscould almost continuously access their own trajectories afterinitial startup delays of 9–81 seconds. In terms of privacy,4 of the 5 clients could never decrypt other pedestrians’ tra-jectories throughout the experiment. The only false positiveoccurs when client N7-1 could access the trajectory of clientN7-2 around the 40–50 second marker, when it had been con-tinuously in close proximity to N7-2 for a few tens of sec-onds. Since AnonyCast employs a probabilistic access con-trol mechanism to handle uncertainty in radio signal propaga-tion, it is difficult to perfectly avoid such unexpected access.Nevertheless, the AnonyCast system achieved an overall pre-cision of 0.99 and a recall of 0.84, which would be reasonableand acceptable performance in most practical scenarios. Noteas well that precision can be improved by increasing the sys-tem privacy parameter (1� ✓
pl
) at the cost of recall.
SimulationsWe have also conducted simulation experiments assuming avirtual exhibition venue in Fig. 9 to clarify performance ofAnonyCast under a variety of scenarios and system configu-rations. The field is composed of 17 exhibition booths (repre-sented by shaded areas) and passages that are modeled by 31line segments (indicated by dotted lines). Initially, all pedes-trians stay in a random location in a random booth in the field.Then each pedestrian randomly selects a destination boothand moves towards a random location in that booth using theshortest path along the passages. The speed of the pedestri-ans is chosen randomly, ranging from 0.5 m/s to 1.5 m/s. Bydefault, we set the number of pedestrians to 30. After arriv-ing at the destination booth, the pedestrian remains there for arandom duration between � ± 10 seconds and then leaves forthe next booth. � is the average idle duration of pedestriansand is set to 30 seconds in the default configuration.
We simulate BLE transmitters in a subset of the exhibitionbooths, as indicated by the icons in Fig. 9. Unless otherwise
Figure 10. Radio attenuation by hu-man bodies
Figure 11. Performance for varyingprivacy levels (1� ✓
pl
)Figure 12. Performance for varyingspatial tolerance d
Figure 13. Performance for varyingtemporal criterion ✓
own
Figure 14. Impact of human mobil-ity
.
Figure 15. Performance for varyingwindow size W
Figure 16. Varying the number ofpedestrians
Figure 17. Varying the number ofBLE transmitters
noted, we deploy the transmitters only at the locations (1)–(8)and instruct them to transmit private keys every second (i.e.,⌧ = 1 second). In order to take variations in BLE receiversensitivity into consideration, we randomly choose the modelof each pedestrian’s mobile device from Nexus 4, Nexus 5,and Nexus 7, and employ the corresponding radio receptionmodels in Fig. 2 (b). We further assume that the beaconreception probability decreases by 10-20% when the directsignal is obstructed by partitions between the booths.
To faithfully take radio attenuation by human bodies into ac-count, we also conducted the following preliminary measure-ment campaign. We deployed a RadBeacon USB at the heightof 1.2m, and configured it to repeatedly transmit advertise-ment packets with transmission power of �86 dBm. We thenplaced a receiver smartphone (Nexus 5) at the same heightand 1–10 meters away from the transmitter to measure bea-con reception rates at each distance. We conducted the ex-periments above in both a Line-of-Sight scenario, in whichthere was no obstacle between the transmitter and the receiverphone, and two Non-Line-of-Sight scenarios, where 1–2 per-sons stood between the devices. Fig. 10 shows beacon re-ception rates under each configuration. The reception ratedecreases by about 20% when the line-of-sight is obstructedby human bodies, due to attenuation of direct signals. Basedon the results above, we simulate the impact of human bodiesas follows: we model each pedestrian by a cylinder with ra-dius of 0.124 m and the height of 1.6 m, and assume that theyhold a phone at 0.3 m away from their body. We deploy BLEtransmitters at 1.2 m height, and also assume that simulatedbeacon reception rates are further decreased by 20% if theline-of-sight between a transmitter and a phone is obstructedby any human bodies.
For crowd tracking, we assume that the position informationin each anonymous trajectory contains random errors which
follow a zero-mean Gaussian distribution with a diagonal co-variance matrix �
2I , where I is a two-dimensional identitymatrix. By default, we set the standard deviation � to 0.2m.
Unless otherwise noted, we set the system privacy parameter(1� ✓
pl
) to 0.95, the spatial tolerance d to 3m, temporal cri-terion ✓
own
to 0.8, and window size W to 90 seconds in thefollowing experiments. We ran simulations of 1,000 secondseach and evaluated the precision and recall as a function ofvarious system parameters. The simulations were conducted10 times for each parameter configuration, and we show av-erage performance over all of these trials.
Performance with Different Privacy LevelsWe assume that the desired privacy level (i.e., 1�✓
pl
) is spec-ified as a system parameter. Fig. 11 shows the resulting re-call when the privacy level is varied from 0.9 to 0.98. Whilethe recall slightly declines if a stricter privacy requirement isimposed, it still remains around 0.7 even with a privacy re-quirement of 0.98. This is an encouraging result, because itshows that we can achieve higher privacy requirements with-out significantly sacrificing accessibility to the published tra-jectories. Although we have found that recall falls to zerowhen we require perfect privacy (i.e., ✓
pl
= 0), the systemcould asymptotically achieve near-optimal privacy level.
We also analyzed system performance, varying spatial toler-ance d from 3m to 24m and the temporal tolerance ✓
own
from0.1 to 0.9. Figures 12 and 13 show results of these analy-ses, respectively. Note that our privacy requirement allowsthe clients who have been within d meters from a person ofinterest for a certain ratio of time ✓
own
over the recent timewindow to access her trajectory. Thus larger d and smaller✓
own
both alleviate the privacy requirements for AnonyCast.As a result, both precision and recall tend to increase as theparameter d gets larger or the parameter ✓
own
gets smaller.
Human Mobility and Window SizeFig. 14 shows the performance characteristics when the aver-age idle duration of pedestrians at the booths (i.e., �) is var-ied from 0 to 90 seconds. Both precision and recall becomethe maximum when people continuously move without stop-ping at any booths, because the difference in the set of privatekeys that have been collected by each client is maximizedin this case. Since clients staying at neighboring booths areexpected to receive similar sets of private keys during thatperiod, it becomes harder for the server to distinguish theseclients when the average idle duration exceeds a certain level.Consequently, the location distribution performance tends todecrease as � becomes larger. To cope with such performancedegradation, we can set the window size W to be sufficientlylarger than the typical pedestrian idle duration. Fig. 15 showsthe performance of AnonyCast when W is varied from 30to 180, while fixing the average idle duration at 30 seconds.As seen, the recall starts to converge when W is 90 seconds(i.e., 3 times larger than the average idle duration). This win-dow size provides a reasonable tradeoff between computa-tional cost and location distribution performance.
Varying the Number of PedestriansFig. 16 shows the precision and recall when the number ofpedestrians is varied from 10 to 90. As pedestrian densityincreases, their trajectories have a greater chance of appear-ing similar to the trajectory of another person. This leads theserver to build stricter access policies to maintain the desiredprivacy level and consequently the recall gradually decreases.In exchange for the reduced accessibility, the system main-tains almost constant precision regardless of the pedestriandensity. Thus AnonyCast can adaptively control accessibilityto the trajectories to ensure the desired privacy level. In Fig.16 we also plot the recall values, which are achieved whenwe set the window size W to 120 seconds. The longer timewindows increase the opportunity for mobile devices to re-ceive a unique set of keys, and thus effectively mitigate thedegradation of accessibility to the published trajectories.
Varying the Number of BLE TransmittersIn order to illustrate how the density of BLE transmitters af-fects location distribution performance, we also conductedsimulations with different numbers of transmitters. In eachscenario, we deployed transmitters at locations (1)–(n) in Fig.9, where n is the total number of transmitters. Fig. 17 showsthe precision and recall when n is varied from 2 to 16. Againwe also plot the recall values with the larger window size of120 seconds. As expected, the recall becomes larger as thenumber of transmitters increases, since the clients have moreopportunities to receive private keys that help to distinguishthem from other clients. Even if the number of BLE trans-mitters is limited, we can effectively avoid significant degra-dation in the recall by setting a longer time window. For thisscenario, AnonyCast can provide reasonable accessibility tothe published trajectories with only 4–6 transmitters in total,which is much fewer than the BLE-based positioning systemsdiscussed earlier. This makes AnonyCast a strong indoor lo-calization solution for a growing number of smart buildings,for which crowd tracking capabilities already exist.
DISCUSSIONAnonyCast assumes that clients establish a communicationlink with nearby Wi-Fi hotspots to download encrypted tra-jectories. In this process, the server can learn the MAC ad-dress of the client devices. However, the server still cannotassociate these MAC addresses with a specific trajectory: Theonly knowledge it gains is that a client belongs to one of manyanonymous trajectories within transmission range of the Wi-Fi access points. Additionally, a malicious user attemptingto learn the trajectory of a specific person must obtain all thekeys that are required by the (ever-changing) access policy forthat trajectory. To do so, the attacker must continually followthe person of interest, obviating the need to learn the trajec-tory in the first place. Note however that an attacker maystill deploy a dense arrangement of BLE receivers in orderto remotely collect private keys for trajectory decryption, in-tending to decrypt other pedestrians’ trajectories. The currentversion of AnonyCast does not have any measure to preventsuch brute force sniffing attacks. One possible solution toovercome this vulnerability would be to leverage additionalfeatures extracted from pedestrians’ motion in the decryptionprocess. Based on the accurate trajectories from crowd track-ing systems, the server could robustly detect motion charac-teristics of pedestrians such as sudden stops, turns, etc. Thiscould then be used to generate encryption keys based on thetemporal sequence of these motion events and employed fortrajectory encryption in addition to the BLE-based keys. Mo-bile phones could capture the same motion events with built-in motion sensors to locally generate the same keys indepen-dently of the server. This would effectively improve the se-curity of the system, since potential attackers would need tocontinuously and reliably estimate these motion features. Weleave this possible extension for future work.
CONCLUSIONIn this paper, we presented AnonyCast—a privacy-preservinglocation distribution mechanism for crowd tracking systems.AnonyCast uses anonymous crowd tracking sensors alongwith BLE beacons to distribute time- and location-dependentkeys to location subscribers. AnonyCast then encrypts eachtrajectory with these keys before publishing them, ensuringthat only true owners of each trajectory can gain access.The results from extensive simulations and field experimentsshow that AnonyCast can robustly provide accurate trajecto-ries to the corresponding users 84% of the time, while pre-venting unauthorized access to one’s location data by otherpeople with a probability greater than 99%.
ACKNOWLEDGEMENTSThis work was supported in part by the U.S. ARL, U.K. Min-istry of defense (MoD) under Agreement Number W911NF-06-3-0001, and by the NSF under awards CNS-1136174 andCNS-1213140. Any findings in this material are those of theauthor(s) and do not reflect the views of any of the abovefunding agencies. The U.S. and U.K. Governments are autho-rized to reproduce and distribute reprints for Government pur-poses notwithstanding any copyright notation hereon. Thiswork was also supported in part by JSPS KAKENHI GrantNumbers 26220001 and 15K15980.
REFERENCES1. Agarwal, Y., Balaji, B., Gupta, R., Lyles, J., Wei, M.,
and Weng, T. Occupancy-driven energy management forsmart building automation. In Proceedings of the 2ndACM Workshop on Embedded Sensing Systems forEnergy-Efficiency in Building (BuildSys ’10) (2010),1–6.
2. Akinyele, J., Garman, C., Miers, I., Pagano, M.,Rushanan, M., Green, M., and Rubin, A. Charm: aframework for rapidly prototyping cryptosystems.Journal of Cryptographic Engineering 3, 2 (2013),111–128.
3. Bethencourt, J., Sahai, A., and Waters, B.Ciphertext-policy attribute-based encryption. InProceedings of the 2007 IEEE Symposium on Securityand Privacy (SP ’07) (2007), 321–334.
4. Chen, Y., Lymberopoulos, D., Liu, J., and Priyantha, B.FM-based indoor localization. In Proceedings of the10th International Conference on Mobile Systems,Applications, and Services (MobiSys ’12) (2012),169–182.
5. Chintalapudi, K., Padmanabha Iyer, A., andPadmanabhan, V. N. Indoor localization without thepain. In Proceedings of the 16th Annual InternationalConference on Mobile Computing and Networking(MobiCom ’10) (2010), 173–184.
6. Enzweiler, M., and Gavrila, D. Monocular pedestriandetection: Survey and experiments. IEEE Transactionson Pattern Analysis and Machine Intelligence 31, 12(2009), 2179–2195.
7. Estimote, Inc. estimote. http://estimote.com.
8. Faragher, R., and Harle, R. An analysis of the accuracyof bluetooth low energy for indoor positioningapplications. In Proceedings of the 27th InternationalTechnical Meeting of the Satellite Division of theInstitute of Navigation (ION GNSS+ ’14) (2014),201–210.
9. Fod, A., Howard, A., and Mataric, M. A laser-basedpeople tracker. In Proceedings of the 2002 IEEEInternational Conference on Robotics and Automation(ICRA ’02), vol. 3 (2002), 3024–3029.
10. Giebel, J., Gavrila, D., and Schnorr, C. A bayesianframework for multi-cue 3D object tracking. InProceedings of the 8th European Conference onComputer Vision (ECCV ’04) (2004), 241–252.
11. Hokuyo Automatic Co., LTD. Scanning range finder,UTM-30LX.
12. Jacques Junior, J., Raupp Musse, S., and Jung, C. Crowdanalysis using computer vision techniques. IEEE SignalProcessing Magazine 27, 5 (2010), 66–77.
13. Jain, A. K., Murty, M. N., and Flynn, P. J. Dataclustering: A review. ACM Computing Surveys 31, 3(1999), 264–323.
14. Larson, J. S., Bradlow, E. T., and Fader, P. S. Anexploratory look at supermarket shopping paths.International Journal of Research in Marketing 22, 4(2005), 395 – 414.
15. Lim, H., Kung, L.-C., Hou, J. C., and Luo, H.Zero-configuration, robust indoor localization: Theoryand experimentation. In Proceedings of the 25thConference on Computer Communications (INFOCOM’06) (2006), 1 –12.
16. Luo, W., and Hengartner, U. Veriplace: A privacy-awarelocation proof architecture. In Proceedings of the 18thSIGSPATIAL International Conference on Advances inGeographic Information Systems (GIS ’10) (2010),23–32.
17. Martin, P., Ho, B.-J., Grupen, N., Munoz, S., andSrivastava, M. An ibeacon primer for indoorlocalization: Demo abstract. In Proceedings of the 1stACM Conference on Embedded Systems forEnergy-Efficient Buildings (BuildSys ’14) (2014),190–191.
18. Moussa, M., and Youssef, M. Smart devices for smartenvironments: Device-free passive detection in realenvironments. In Proceedings of the 7th IEEEInternational Conference on Pervasive Computing andCommunications (PerCom ’09) (2009), 1–6.
19. Okuma, K., Taleghani, A., Freitas, N., Little, J., andLowe, D. A boosted particle filter: Multitarget detectionand tracking. In Proceedings of the 8th EuropeanConference on Computer Vision (ECCV ’04) (2004),28–39.
20. Radius Networks, Inc. RadBeacon USB. http://www.radiusnetworks.com/ibeacon/radbeacon/.
21. Rosenbloom, S. In bid to sway sales, cameras trackshoppers.http://www.nytimes.com/2010/03/20/business/
20surveillance.html?pagewanted=all&_r=0.
22. Saroiu, S., and Wolman, A. Enabling new mobileapplications with location proofs. In Proceedings of the10th Workshop on Mobile Computing Systems andApplications (HotMobile ’09) (2009), 3:1–3:6.
23. Scott, J., Bernheim Brush, A., Krumm, J., Meyers, B.,Hazas, M., Hodges, S., and Villar, N. Preheat:Controlling home heating using occupancy prediction.In Proceedings of the 13th International Conference onUbiquitous Computing (UbiComp ’11) (2011), 281–290.
24. Sousa, M., Techmer, A., Steinhage, A., Lauterbach, C.,and Lukowicz, P. Human tracking and identificationusing a sensitive floor and wearable accelerometers. InProceedings of the 11th IEEE International Conferenceon Pervasive Computing and Communications (PerCom’13) (2013), 166–171.
25. Teixeira, T., Jung, D., and Savvides, A. Taskingnetworked CCTV cameras and mobile phones toidentify and localize multiple people. In Proceedings of
the 12th ACM International Conference on UbiquitousComputing (UbiComp ’10) (2010), 213–222.
26. Wada, Y., Higuchi, T., Yamaguchi, H., and Higashino, T.Accurate positioning of mobile phones using laser rangescanners. In Proceedings of the 9th IEEE InternationalConference on Wireless and Mobile Computing,Networking and Communications (WiMob ’13) (2013),441–446.
27. Wilson, J., and Patwari, N. See-through walls: Motiontracking using variance-based radio tomographynetworks. IEEE Transactions on Mobile Computing 10,5 (2011), 612–621.
28. Youssef, M., Mah, M., and Agrawala, A. Challenges:Device-free passive localization for wirelessenvironments. In Proceedings of the 13th ACMInternational Conference on Mobile Computing andNetworking (MobiCom ’07) (2007), 222–229.
29. Zhao, H., and Shibasaki, R. A novel system for trackingpedestrians using multiple single-row laser-rangescanners. IEEE Transactions on Systems, Man andCybernetics, Part A: Systems and Humans 35, 2 (2005),283–291.
30. Zhao, T., and Nevatia, R. Tracking multiple humans incrowded environment. In Proceedings of the 2004 IEEEComputer Society Conference on Computer Vision andPattern Recognition (CVPR ’04), vol. 2 (2004),406–413.