AnonySense: PrivacyAware People-Centric
Sensing
Authors: Cory Cornelius, Apu Kapadia, David Kotz, Dan Peebles, Minho Shin (Inst. For
Security Tech. Studies, Dartmouth College, USA)
Nikos Triandopoulos (CS Dept., Univ. of Aarhus, Denmark)
Conference Venue: MobiSys’08, June 17-20, 2008, Breckenridge, Colorado, USA
Copyright 2008 ACM
Presented by: Sara Gaffar
Contents





Introduction
Architecture
Protocol
Evaluation
Discussion
I. INTRODUCTION





Cooperative sensing applications
Privacy – security challenge
AnonySense: a privacy aware architecture for realizing pervasive applications
based on collaborative, opportunistic sensing by personal mobile devices.
AnonySense allows applications to submit sensing tasks – distributed across
anonymous participating mobile devices – later receives verified, anonymized
sensor data reports => secure participatory sensing model.
Three challenges:



Sensing infrastructure – large-scale, heterogeneous and unpredictable collection
of users
Implementation – across administratively autonomous WAPs and public internet
Privacy of users – no gain for users, consumption of mobile resources, reveals
user’s location; reliable, efficient and privacy-preserving context tasking and
reporting.

Previous work: Focus on



AnonySense:





Narrow set of pre-defined applications, or
Only parts of tasking and reporting lifecycle
application-independent infrastructure for realizing anonymous tasking and
reporting designed from ground up to provide users with privacy
provides new tasking language – can express rich set of context queries
uses stringent threat model – assume that the mobile device carriers do not
completely trust the system, the applications, or the users of the application
first implementation of the fundamental task-report model
Anonymity:



no entity should be able to link a report to a particular carrier
no intermediate entity can infer information about what is reported, tamper with
tasks, or falsify reports
Tradeoff – accuracy at the cost of higher latency in receiving reports

Demonstration:


AnonySense developed within the Metrosense project
Two applications built:
1. RougeFinder – to detect unauthorized Wi-Fi access points (in and around
Dartmouth College)
 2. Object Finder – to locate Bluetooth-enabled objects
NOTE: AnonySense focused on anonymous tasking and reporting; does not address
leakage of private information through reported data (i.e inside report)


Contributions:



A general-purpose framework presented for anonymous opportunistic tasking
and reporting
Implemented AnonySense and through experiments show that their privacy-aware
tasking and reporting approach can be realized efficiently in terms of resources
Demonstrated flexibility and feasibility in supporting collaborative-sensing
applications by presenting two prototype apps: RougeFinder, ObjectFinder
II. AnonySense
Architecture
1. System Design

Three design principles:




broad range of sensor types and
application tasks
anonymity
integrity of sensor data
Overview/ Components:

MNs (Mobile Nodes)


devices with sensing, computation,
memory and wireless
communication capability;
carried/ stationary (on vehicle);
carrier- person/ owner of vehicle
assumptions:


all MNs have wireless access to
internet (atleast through APs
distributed in sensing area)
existence of open-access Wi-Fi
infrastructure
Applications request desired context through task
Node receives task
Accept/ not (acceptance conditions, attributes of MN/ carrier)
If yes, node produces series of reports
(each a tuple = unique task ID + task-specific data fields)
Four core services:


Registration authority (RA)




register nodes that wish to
participate
certifies each MN – MN can
prove its validity to RS, TS
issue certificates to TS and RS
for applications and nodes to
verify their authenticity
mobile-node registration



verifies whether task
interpreter is properly
installed on node; node’s
sensors are properly calibrated
verifies attributes of mobile
node & human carrier;
records in RA database for
use in future tasking decisions
installs private “group key” on
node => node can sign
reports anonymously

Task service (TS)





Report service (RS)




receives task descriptions from
applications
performs consistency checking
distributes current tasks to MNs
returns token to application to
retrive tasked data
Receives reports from MNs
aggregates them internally for
privacy
responds to queries from
applications (token presented)
MIX network (MIX)




channel b/w MNs and RS: it delinks
reports submitted by MNs before
they reach RS => users anonymity
delaying and mixing
assumption: enough users sending
msgs
Mixmaster – most popular MIX
proposed by Chaum
2. Task Language

AnonyTL: For applications to specify their task’s behavior. It provides







acceptance conditions – evaluated by MNs after retrieving tasks from TS
report statements – implicitly indicates that MN must have the necessary sensors
termination condition/ expiration date => task removed from MN’s task pool
Lisp-like syntax – parenthesized statements; prefix notation; logical expressions;
meaningful operators
NOTE: task are not executable code; tasks specify desired sensor readings and
reporting conditions
NOTE: reports never contain: 1. name of MN’s carrier 2. unique ID for MN =>
anonymity
RogueFinder example:
3. Threat Model
Carrier anonymity:



Adversary – de-anonymizes carrier by linking given report to carrier/ MN,
obtaining detailed information
Possible threats










eavesdrop comm. b/w MN and APs
collude with AP/ MIX node to intercept MN’s traffic
impersonate TS to hand out bogus tasks
attempt to impersonate RS to receive bogus reports
submit tasks via TS and receive reports
register as MN & receive tasks from TS
attempt to link MN’s actions and identify it
attempt to discern activity of MN/ group of MNs by submitting tasks with specific
attributes
RS/ TS maybe an adversary
assumption – adversary is free to observe carrier’s activities except those
activities that generated the reports the attacker desires to link to the carrier

Data integrity:


Provide application with confidence integrity of sensor
data
Adversary may






tamper received sensor data
insert false data
collude with AP/ MIX node to tamper with reports on way to RS
attempt to impersonate RS to deliver bogus reports to applications
tamper with MN hardware/ software
3. Other threats:


Adversary directly tampers with MN sensor/ environment
a sophisticated adversary with physical infrastructure can
track target mobile device.e.g.: by analyzing RF
characteristics
4. Trust Model
Carrier – trusts node s/w to properly implement the AnonySense protocols and trust
relationships
MN – assumption: all MNs comm. with TS & RS through WI-Fi APs


trust APs to allow Internet connections
do not trust APs with confidentiality of their n/w traffic or with their ID/ location
trust RA to



certify IDs of TS & RS
certify authenticity of each task
not conspire against carrier’s privacy



APs – need not trust any component
Apps trust


RA to

certify RS & TS
calibrate MNs; protecting integrity of sensor data


TS to

deploy tasks as requested
not divulge report-retrieval token to any other party


RS



not to drop reports
give task’s reports to another App
RA

trusts nothing; is a root of trust
assumption: RA is administratively independent of task or report services


RS & TS

trust RA to



certify only valid MNs in the system
certify only those tasks that target a sufficiently large subset of MNs
need not trust applications

Certifying MNs - RA verifies the MN’s validity

First verifies






MN is running proper version of AnonyTL interpreter
MN’s h/w & s/w are untampered
attributes of MN and carrier
calibrates the MN’s sensors
Then provides MN with a credential to produce signatures – proof of validity;
do not reveal the ID of MN => maintain anonymity yet remain valid
III. PROTOCOL
1. Tasking Protocol

Step 1:Task generation
App generates task using AnonyTL
Sends task to TS (using server-authenticated channel)
TS generates unique task ID for the task

Step 2:Task verification
(If task sytax is valid) TS sends task to RA
RA computes value of k (no. of unique MNs that satisfy attribute criteria,
sensor capabilities required by task)
If true, RA prepares certificate ad sends back to TS

Step 3:Response to App
If task is incorrect, reply ‘task is invalid’
Else, send msg with taks ID and TS-signed certificate (token)

Step 4: Tasking nodes
MNs poll TS for tasks
MNs use ‘group signature’ to prove its validity without revealing identity
TS delivers recent, unexpired tasks to MN
2. Reporting Protocol
MN process task using AnonyTL interpreter
MN prepares report pkg (includes hash of task, large random nonce)
MN signs each report with group-signature, encrypts with RS public key
& stores in outgoing queue
MN connects to AP anonymously, delivers report to RS through MIX
Data Fusion: RS aggregates reports; sends results to application
Data Retrieval: App polls RS for available context data; presents token;
accesses data from task
MAC Address Recycling: MN’s MAC and IP addresses recycled each
tasking-reporting session, so task & report actions not linked
3. Security Properties










Adversary learns little by eavesdropping since MNs communications with TS & RS are
encrypted; MN rotates its MAC & IP addresses for each session
MNs & Apps have certificates, thus adversary may not pose as TS/ RS
TS may not link MN’s tasking operations since each poll arrives from new IP address
Adversary learns little by submitting tasks since must satisfy k-anonymity
Adversarial MN may receive tasks but TS validates MN before providing task; RA
certifies MN’s validity; MN must have software; tasks are encrypted
Adversary may link tasks/ reports but MN rotates MAC address; uses random TSpolling; MIX temporarily separates reports
Report submitted by adversary is rejected since no group-signature key
Adversary cannot replay report since nonce encoded and RS memory reports already
submitted
Adversary cannot tamper with reports since signed by MN and encrypted with RS
public key
If Trusted Platform Module (TPM) used, adversary cannot tamper with MN software
IV. EVALUATION

Implementation:





Services, single-node MIX & application component run on Linux desktop
Services connected to wired network; MNs to wireless with 1500 APs spread in
campus
Nokia N800 used (not TPM supported)
MN software written in C++
Not implemented:



MAC-address rotation
Group-signature in tasking protocol
Applications:


RogueFinder – MNs Wi-Fi interface used to check list of APs reported against
list of known deployed APs and display approx. location of rogue AP on map
ObjectFinder – tasks AnonySense to find specific Bluetooth MAC address. MN
detects it, reports current location and App marks on map

Experiments:


Tests conducted in Dartmouth CS
building with 60 Wi-Fi BSSIDs
visible, 3-7 discoverable Bluetooth
devices in vicinity
Results:





Out of 84 detected APs, 12
determined rogues
15.5 sec for one task-scan-report
cycle
Avg. power cost = 6.64 mW; 0.11
Joule
Reduced battery lifetime by 5.26%
Tasking is more expensive than
reporting (due to SSL connection
with TS)
V. DISCUSSION

Scalability:




Task dissemination:








replicate RS, TS & RA with load-balancing techniques
Add more MIX nodes
MN can impose resource constraints to reject tasks
Anonysense allows Apps to remove tasks
Apps can code task to send null report to indicate how many MNs accepted the task
Carrier policy: prompt carrier about which tasks to accept
TPM for data integrity: cumbersome to carrier; no freedom (e.g: to install applications)
Delay tolerance: as no. of msgs passing through MIX increase, latency goes down since queue fills faster
(Technical strong point: AnonySense best suited to delay tolerant applications)
Wi-Fi vs. cellular network: preserve carrier’s privacy; must not trust provider
Privacy-risks in RogueFinder: No component knows which MNs/ Carriers accepted task/ submitted
report
Privacy risks in ObjectFinder:

Possible to harvest MAC address => never leave device in ‘discoverable’ state



Alternative – linking with another blue-tooth enabled device always accompanying it
Savvy AnonySense participant may discover Bluetooth address of object being sought => hide task from carrier (carrierconfigurable policy module)
Other applications:


QuietFinder – use N800’s microphone as sound detector
For public safety: MNs with radiation detectors to inform carrier about personal radiation exposure
References






Metrosense: A. Campbell, S. Eisenman, N. Lane, E. Miluzzo, and R. Peterson. Peoplecentric urban sensing. In The Second Annual International Wireless Internet
Conference (WICON), pages 2–5. IEEE Computer Society Press, August 2006.
Revealing identity of user: J. Krumm. Inference attacks on location tracks. In Proceedings
of the Fifth International Conference on Pervasive Computing (Pervasive), volume
4480 of LNCS, pages 127–143. Springer-Verlag, May 2007.
Mixmaster: U. M¨oller, L. Cottrell, P. Palfrader, and L. Sassaman. Mixmaster Protocol
— Version 2. IETF Internet Draft, July 2003.
TPM: Trusted Computing Group (TCG), May 2005.
https://www.trustedcomputinggroup.org/home.
Tor- A low latency anonymizing network: R. Dingledine, N. Mathewson, and P. Syverson.
Tor: The second-generation onion router. In Proceedings of the 13th USENIX
Security Symposium, August 2004.
Tradeoffs in statistical k-anonymity: A. Kapadia, N. Triandopoulos, C. Cornelius, D.
Peebles, and D. Kotz. AnonySense: Opportunistic and privacy-preserving context
collection. In Proceedings of the Sixth International Conference on Pervasive
Computing (Pervasive), May 2008.
Questions/
Suggestions ?