AnonySense- Privacy-Aware People-Centric Sensing.ppt

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: MobiSys08, June 17-20, 2008, Breckenridge, C

2、olorado, USA Copyright 2008 ACMPresented 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,

3、 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 l

4、arge-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 users location; reliable, efficient and privacy-preserving context tasking and repor

5、ting.,Previous work: Focus on Narrow set of pre-defined applications, or Only parts of tasking and reporting lifecycle AnonySense: application-independent infrastructure for realizing anonymous tasking and reporting designed from ground up to provide users with privacy provides new tasking language

6、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 rep

7、ort 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. Rou

8、geFinder 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) Contributi

9、ons: 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 suppo

10、rting 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) dev

11、ices 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,Four

12、 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 ins

13、talled on node; nodes sensors are properly calibrated verifies attributes of mobile node records in RA database for use in future tasking decisions installs private “group key” on node = node can sign reports anonymously,Task service (TS) receives task descriptions from applications performs consist

14、ency 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

15、 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 tasks behavior. It provides acceptance conditions evaluated by MNs after retriev

16、ing tasks from TS report statements implicitly indicates that MN must have the necessary sensors termination condition/ expiration date = task removed from MNs task pool Lisp-like syntax parenthesized statements; prefix notation; logical expressions; meaningful operators NOTE: task are not executabl

17、e code; tasks specify desired sensor readings and reporting conditions NOTE: reports never contain: 1. name of MNs 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 detaile

18、d information Possible threats eavesdrop comm. b/w MN and APs collude with AP/ MIX node to intercept MNs 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

19、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 carriers activities except those activities that generated the reports the attacker desires to link to the carrier,

20、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

21、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 relatio

22、nships MN assumption: all MNs comm. with TS 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 tasks reports to another App,RA trusts nothing; is a root of trust assumption: RA is administratively inde

23、pendent of task or report services RS 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

24、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, sen

25、d 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 (

26、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

27、for available context data; presents token; accesses data from task,MAC Address Recycling: MNs 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 MIX tempor

28、arily 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 Modul

29、e (TPM) used, adversary cannot tamper with MN software,IV. EVALUATION,Implementation: Services, single-node MIX 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 Appli

30、cations: 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,Experiment

31、s: 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 mo

32、re expensive than reporting (due to SSL connection with TS),V. DISCUSSION,Scalability: replicate RS, TS 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

33、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 (carrier-configurable policy module) Other applications: QuietFinder use N8

34、00s 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. People-centric urban sensing. In The Second Annual International Wireless Intern

35、et Conference (WICON), pages 25. 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 127143. Springer-Verlag, May 2007

36、. Mixmaster: U. Moller, 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. Syver

37、son. 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 ?,