Presentation is loading. Please wait.

Presentation is loading. Please wait.

AnonySense: Privacy- Aware People-Centric Sensing Authors: Cory Cornelius, Apu Kapadia, David Kotz, Dan Peebles, Minho Shin (Inst. For Security Tech. Studies,

Similar presentations


Presentation on theme: "AnonySense: Privacy- Aware People-Centric Sensing Authors: Cory Cornelius, Apu Kapadia, David Kotz, Dan Peebles, Minho Shin (Inst. For Security Tech. Studies,"— Presentation transcript:

1 AnonySense: 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: MobiSys’08, June 17-20, 2008, Breckenridge, Colorado, USA Copyright 2008 ACM Presented by: Sara Gaffar

2 Contents Introduction Introduction Architecture Architecture Protocol Protocol Evaluation Evaluation Discussion Discussion

3 I. INTRODUCTION

4 Cooperative sensing applications Cooperative sensing applications Privacy – security challenge Privacy – security challenge AnonySense: a privacy aware architecture for realizing pervasive applications based on collaborative, opportunistic sensing by personal mobile devices. 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. 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: Three challenges: Sensing infrastructure – large-scale, heterogeneous and unpredictable collection of users Sensing infrastructure – large-scale, heterogeneous and unpredictable collection of users Implementation – across administratively autonomous WAPs and public internet 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. Privacy of users – no gain for users, consumption of mobile resources, reveals user’s location; reliable, efficient and privacy-preserving context tasking and reporting.

5 Previous work: Focus on Previous work: Focus on Narrow set of pre-defined applications, or Narrow set of pre-defined applications, or Only parts of tasking and reporting lifecycle Only parts of tasking and reporting lifecycle AnonySense: AnonySense: application-independent infrastructure for realizing anonymous tasking and reporting designed from ground up to provide users with privacy 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 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 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 first implementation of the fundamental task-report model Anonymity: Anonymity: no entity should be able to link a report to a particular carrier 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 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 Tradeoff – accuracy at the cost of higher latency in receiving reports

6 Demonstration: Demonstration: AnonySense developed within the Metrosense project AnonySense developed within the Metrosense project Two applications built: Two applications built: 1. RougeFinder – to detect unauthorized Wi-Fi access points (in and around Dartmouth College) 1. RougeFinder – to detect unauthorized Wi-Fi access points (in and around Dartmouth College) 2. Object Finder – to locate Bluetooth-enabled objects 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: Contributions: A general-purpose framework presented for anonymous opportunistic tasking and reporting 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 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 Demonstrated flexibility and feasibility in supporting collaborative-sensing applications by presenting two prototype apps: RougeFinder, ObjectFinder

7 II. AnonySense Architecture

8 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

9 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)

10 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

11 Task service (TS) receives task descriptions from applications performs consistency checking distributes current tasks to MNs returns token to application to retrive tasked data Report service (RS) 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

12 2. Task Language AnonyTL: For applications to specify their task’s behavior. It provides AnonyTL: For applications to specify their task’s behavior. It provides acceptance conditions – evaluated by MNs after retrieving tasks from TS acceptance conditions – evaluated by MNs after retrieving tasks from TS report statements – implicitly indicates that MN must have the necessary sensors report statements – implicitly indicates that MN must have the necessary sensors termination condition/ expiration date => task removed from MN’s task pool termination condition/ expiration date => task removed from MN’s task pool Lisp-like syntax – parenthesized statements; prefix notation; logical expressions; meaningful operators 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: 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 NOTE: reports never contain: 1. name of MN’s carrier 2. unique ID for MN => anonymity RogueFinder example: RogueFinder example:

13 3. Threat Model Carrier anonymity: Carrier anonymity: Adversary – de-anonymizes carrier by linking given report to carrier/ MN, obtaining detailed information Adversary – de-anonymizes carrier by linking given report to carrier/ MN, obtaining detailed information Possible threats Possible threats eavesdrop comm. b/w MN and APs eavesdrop comm. b/w MN and APs collude with AP/ MIX node to intercept MN’s traffic collude with AP/ MIX node to intercept MN’s traffic impersonate TS to hand out bogus tasks impersonate TS to hand out bogus tasks attempt to impersonate RS to receive bogus reports attempt to impersonate RS to receive bogus reports submit tasks via TS and receive reports submit tasks via TS and receive reports register as MN & receive tasks from TS register as MN & receive tasks from TS attempt to link MN’s actions and identify it attempt to link MN’s actions and identify it attempt to discern activity of MN/ group of MNs by submitting tasks with specific attributes attempt to discern activity of MN/ group of MNs by submitting tasks with specific attributes RS/ TS maybe an adversary 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 assumption – adversary is free to observe carrier’s activities except those activities that generated the reports the attacker desires to link to the carrier

14 Data integrity: Data integrity: Provide application with confidence integrity of sensor data Provide application with confidence integrity of sensor data Adversary may Adversary may tamper received sensor data tamper received sensor data insert false data insert false data collude with AP/ MIX node to tamper with reports on way to RS collude with AP/ MIX node to tamper with reports on way to RS attempt to impersonate RS to deliver bogus reports to applications attempt to impersonate RS to deliver bogus reports to applications tamper with MN hardware/ software tamper with MN hardware/ software 3. Other threats: 3. Other threats: Adversary directly tampers with MN sensor/ environment Adversary directly tampers with MN sensor/ environment a sophisticated adversary with physical infrastructure can track target mobile device.e.g.: by analyzing RF characteristics a sophisticated adversary with physical infrastructure can track target mobile device.e.g.: by analyzing RF characteristics

15 4. Trust Model Carrier – trusts node s/w to properly implement the AnonySense protocols and trust relationships 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 MN – assumption: all MNs comm. with TS & RS through WI-Fi APs trust APs to allow Internet connections trust APs to allow Internet connections do not trust APs with confidentiality of their n/w traffic or with their ID/ location do not trust APs with confidentiality of their n/w traffic or with their ID/ location trust RA to trust RA to certify IDs of TS & RS certify IDs of TS & RS certify authenticity of each task certify authenticity of each task not conspire against carrier’s privacy not conspire against carrier’s privacy APs – need not trust any component APs – need not trust any component Apps trust Apps trust RA to RA to certify RS & TS certify RS & TS calibrate MNs; protecting integrity of sensor data calibrate MNs; protecting integrity of sensor data TS to TS to deploy tasks as requested deploy tasks as requested not divulge report-retrieval token to any other party not divulge report-retrieval token to any other party RS RS not to drop reports not to drop reports give task’s reports to another App give task’s reports to another App

16 RA RA trusts nothing; is a root of trust trusts nothing; is a root of trust assumption: RA is administratively independent of task or report services assumption: RA is administratively independent of task or report services RS & TS RS & TS trust RA to trust RA to certify only valid MNs in the system certify only valid MNs in the system certify only those tasks that target a sufficiently large subset of MNs certify only those tasks that target a sufficiently large subset of MNs need not trust applications need not trust applications Certifying MNs - RA verifies the MN’s validity Certifying MNs - RA verifies the MN’s validity First verifies First verifies MN is running proper version of AnonyTL interpreter MN is running proper version of AnonyTL interpreter MN’s h/w & s/w are untampered MN’s h/w & s/w are untampered attributes of MN and carrier attributes of MN and carrier calibrates the MN’s sensors 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 Then provides MN with a credential to produce signatures – proof of validity; do not reveal the ID of MN => maintain anonymity yet remain valid

17 III. PROTOCOL

18 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

19 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

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

21 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

22 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

23 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

24 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 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 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 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 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 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 TS- polling; MIX temporarily separates reports Adversary may link tasks/ reports but MN rotates MAC address; uses random TS- polling; MIX temporarily separates reports Report submitted by adversary is rejected since no group-signature key 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 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 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 If Trusted Platform Module (TPM) used, adversary cannot tamper with MN software

25 IV. EVALUATION

26 Implementation: Implementation: Services, single-node MIX & application component run on Linux desktop Services, single-node MIX & application component run on Linux desktop Services connected to wired network; MNs to wireless with 1500 APs spread in campus Services connected to wired network; MNs to wireless with 1500 APs spread in campus Nokia N800 used (not TPM supported) Nokia N800 used (not TPM supported) MN software written in C++ MN software written in C++ Not implemented: Not implemented: MAC-address rotation MAC-address rotation Group-signature in tasking protocol Group-signature in tasking protocol Applications: 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 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 ObjectFinder – tasks AnonySense to find specific Bluetooth MAC address. MN detects it, reports current location and App marks on map

27 Experiments: Experiments: Tests conducted in Dartmouth CS building with 60 Wi-Fi BSSIDs visible, 3-7 discoverable Bluetooth devices in vicinity Tests conducted in Dartmouth CS building with 60 Wi-Fi BSSIDs visible, 3-7 discoverable Bluetooth devices in vicinity Results: Results: Out of 84 detected APs, 12 determined rogues Out of 84 detected APs, 12 determined rogues 15.5 sec for one task-scan-report cycle 15.5 sec for one task-scan-report cycle Avg. power cost = 6.64 mW; 0.11 Joule Avg. power cost = 6.64 mW; 0.11 Joule Reduced battery lifetime by 5.26% Reduced battery lifetime by 5.26% Tasking is more expensive than reporting (due to SSL connection with TS) Tasking is more expensive than reporting (due to SSL connection with TS)

28 V. DISCUSSION

29 Scalability: Scalability: replicate RS, TS & RA with load-balancing techniques replicate RS, TS & RA with load-balancing techniques Add more MIX nodes Add more MIX nodes MN can impose resource constraints to reject tasks MN can impose resource constraints to reject tasks Task dissemination: Task dissemination: Anonysense allows Apps to remove tasks Anonysense allows Apps to remove tasks Apps can code task to send null report to indicate how many MNs accepted the task 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 Carrier policy: prompt carrier about which tasks to accept TPM for data integrity: cumbersome to carrier; no freedom (e.g: to install applications) 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) 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 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 RogueFinder: No component knows which MNs/ Carriers accepted task/ submitted report Privacy risks in ObjectFinder: Privacy risks in ObjectFinder: Possible to harvest MAC address => never leave device in ‘discoverable’ state Possible to harvest MAC address => never leave device in ‘discoverable’ state Alternative – linking with another blue-tooth enabled device always accompanying it 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 (carrier- configurable policy module) Savvy AnonySense participant may discover Bluetooth address of object being sought => hide task from carrier (carrier- configurable policy module) Other applications: Other applications: QuietFinder – use N800’s microphone as sound detector QuietFinder – use N800’s microphone as sound detector For public safety: MNs with radiation detectors to inform carrier about personal radiation exposure For public safety: MNs with radiation detectors to inform carrier about personal radiation exposure

30 References Metrosense: A. Campbell, S. Eisenman, N. Lane, E. Miluzzo, and R. Peterson. People- centric urban sensing. In The Second Annual International Wireless Internet Conference (WICON), pages 2–5. IEEE Computer Society Press, August 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 Mixmaster: U. M¨oller, L. Cottrell, P. Palfrader, and L. Sassaman. Mixmaster Protocol — Version 2. IETF Internet Draft, July TPM: Trusted Computing Group (TCG), May https://www.trustedcomputinggroup.org/home. 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 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.

31 Questions/ Suggestions ?


Download ppt "AnonySense: Privacy- Aware People-Centric Sensing Authors: Cory Cornelius, Apu Kapadia, David Kotz, Dan Peebles, Minho Shin (Inst. For Security Tech. Studies,"

Similar presentations


Ads by Google