Anony Sense Privacy Aware People-Centric Sensing Authors Cory

Anony. Sense: Privacy. Aware 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: Mobi. Sys’ 08, June 17 -20, 2008, Breckenridge, Colorado, USA Copyright 2008 ACM Presented by: Sara Gaffar

Contents Introduction n Architecture n Protocol n Evaluation n Discussion n

I. INTRODUCTION

n n n Cooperative sensing applications Privacy – security challenge Anony. Sense: a privacy aware architecture for realizing pervasive applications based on collaborative, opportunistic sensing by personal mobile devices. Anony. Sense 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: n n n 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.

n Previous work: Focus on n Anony. Sense: n n n 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: n 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

n Demonstration: n n Anony. Sense developed within the Metrosense project Two applications built: 1. Rouge. Finder – to detect unauthorized Wi-Fi access points (in and around Dartmouth College) n 2. Object Finder – to locate Bluetooth-enabled objects NOTE: Anony. Sense focused on anonymous tasking and reporting; does not address leakage of private information through reported data (i. e inside report) n n Contributions: n n n A general-purpose framework presented for anonymous opportunistic tasking and reporting Implemented Anony. Sense 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: Rouge. Finder, Object. Finder

II. Anony. Sense Architecture

1. System Design n Three design principles: n n broad range of sensor types and application tasks anonymity integrity of sensor data Overview/ Components: n MNs (Mobile Nodes) n n devices with sensing, computation, memory and wireless communication capability; carried/ stationary (on vehicle); carrier- person/ owner of vehicle assumptions: n n all MNs have wireless access to internet (atleast through APs (atleast 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)

n Four core services: n Registration authority (RA) n n 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 n 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

n Task service (TS) n n n Report service (RS) n n 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) n n 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 n Anony. TL: For applications to specify their task’s behavior. It provides n n n n 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 Rogue. Finder example:

3. Threat Model Carrier anonymity: n n n Adversary – de-anonymizes carrier by linking given report to carrier/ MN, obtaining detailed information Possible threats n n n n n 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

n Data integrity: n n Provide application with confidence integrity of sensor data Adversary may n n n 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: n n 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 Anony. Sense protocols and trust relationships MN – assumption: all MNs comm. with TS & RS through WI-Fi APs n n 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 n n n certify IDs of TS & RS certify authenticity of each task not conspire against carrier’s privacy n n n APs – need not trust any component Apps trust n n RA to n certify RS & TS calibrate MNs; protecting integrity of sensor data MNs; n n TS to n deploy tasks as requested not divulge report-retrieval token to any other party n n RS n not to drop reports give task’s reports to another App

RA n trusts nothing; is a root of trust assumption: RA is administratively independent of task or report services n n RS & TS n trust RA to n n n certify only valid MNs in the system certify only those tasks that target a sufficiently large subset of MNs need not trust applications n Certifying MNs - RA verifies the MN’s validity n First verifies n n n MN is running proper version of Anony. TL 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 n Step 1: Task generation App generates task using Anony. TL Sends task to TS (using server-authenticated channel) TS generates unique task ID for the task

n 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

n Step 3: Response to App If task is incorrect, reply ‘task is invalid’ Else, send msg with taks ID and TS-signed certificate (token)

n 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 Anony. TL 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 n n n n n 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

n Implementation: n n n 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 N 800 used (not TPM supported) MN software written in C++ Not implemented: n n n MAC-address rotation Group-signature in tasking protocol Applications: n n Rogue. Finder – 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 Object. Finder – tasks Anony. Sense to find specific Bluetooth MAC address. MN detects it, reports current location and App marks on map

n Experiments: n n Tests conducted in Dartmouth CS building with 60 Wi-Fi BSSIDs visible, 3 -7 discoverable Bluetooth devices in vicinity Results: n n n Out of 84 detected APs, 12 determined rogues 15. 5 sec for one task-scan-report cycle Avg. power cost = 6. 64 m. W; 0. 11 Joule Reduced battery lifetime by 5. 26% Tasking is more expensive than reporting (due to SSL connection with TS)

V. DISCUSSION

n Scalability: n n Task dissemination: n n n n 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: Anony. Sense best suited to delay tolerant applications) Wi-Fi vs. cellular network: preserve carrier’s privacy; must not trust provider Privacy-risks in Rogue. Finder: No component knows which MNs/ Carriers accepted task/ submitted report Privacy risks in Object. Finder: n Possible to harvest MAC address => never leave device in ‘discoverable’ state n n n Alternative – linking with another blue-tooth enabled device always accompanying it Savvy Anony. Sense participant may discover Bluetooth address of object being sought => hide task from carrier (carrierconfigurable policy module) Other applications: n n Quiet. Finder – use N 800’s microphone as sound detector For public safety: MNs with radiation detectors to inform carrier about personal radiation exposure

References n n n 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 13 th USENIX Security Symposium, August 2004. Tradeoffs in statistical k-anonymity: A. Kapadia, N. Triandopoulos, C. Cornelius, D. Peebles, and D. Kotz. Anony. Sense: Opportunistic and privacy-preserving context collection. In Proceedings of the Sixth International Conference on Pervasive Computing (Pervasive), May 2008.

Questions/ Suggestions ?