1. AnonySense: Privacy-Aware People-Centric Sensing Cory Conelius, Apu Kapadia, David Kotz, Dan Peebles, Minho Shin [Institute for Security Technology Studies Dartmouth College, USA] Nikos Triandopoulos [Department of Computer Science University of Aarhus, Denmark] MobiSys’08 Presented By: Leyla Kazemi

2. Outline Motivation AnonySense Architecture  System Design  Task Language  Threat Model  Trust Model Protocol  Tasking Protocol  Reporting Protocol  Security Properties Evaluation

3. Motivation Personal Mobile Devices equipped with many sensors (e.g., cameras, microphones, accelerometers) Opportunity for cooperative sensing applications Users Contributing data to information services Challenge: Protecting the user privacy while their devices reliably contribute data

4. Motivation Opportunistic sensing: Leveraging users’ mobile devices to collectively measure environmental data (context) Introducing people-centric, dynamic, and highly mobile communication Applications: CarTel, Mobiscopes, Urbanet, Senseweb, Metrosense Examples: Finding Parking Spots, Locating lost Bluetooth-enabled objects, collecting traffic reports of a street Sensor-enabled cellphones

5. Challenges Dependent on a large-scale, and heterogeneous personal devices Should be implemented across autonomous wireless access points, and public internet Protecting users’ privacy

6. Privacy Issue Report includes time and location of the sensor  revealing user’s location at that time Integrity of system and reliability of report  User trusted?? Wilshire, Stanley Ave, 90036 10:00am Mar20th 2009

7. AnonySense A privacy-aware architecture for realizing pervasive applications based on collaborative, opportunistic sensing by personal mobile devices Allowing applications to submit sensing tasks that will be distributed across anonymous devices Receiving verified, yet anonymized sensor data reports App System Task Anonymous Verified Report

8. System Components Mobile Nodes (MN):  Sensing  Computation  Memory  Wireless communication Carrier:  carries the mobile node

9. Components Registration Authority (RA):  Registering nodes Verifying the proper installation on the MNs Verifying the attributes of the MNs Installing a private group key on the node  Issuing certificates to task service and report service Apps and nodes can later verify the authenticity of the services

10. Components Task Service (TS):  Receiving Task descriptions from apps  Performing Consistency checking  Distributing current task to MNs  Returning a token to app for later retrieving the tasked data Report Service (RS):  Receiving reports from MNs  Aggregating them for more privacy  Responding to queries from apps

11. Components Mix Network (MIX):  Anonymizing channel between MNs and RS  De-linking reports submitted by MNs  Allowing users to anonymously send messages  How: waiting for enough incoming messages before sending messages to the next node Delaying and mixing of messages makes it difficult to correlate incoming and outgoing messages

12. Task Language AnonyTL : A language for applications to specify their tasks  Acceptance Conditions  Report Statements  Termination Conditions (Task 25043) ( Expires 1196728453) (Accept (= @carrier ‘ professor ’ ) ) ( Report ( location SSIDs ) ( Every 1 Minute ) ( In location ( Polygon ( Point 1 1) ( Point 2 2) ( Point 3 0 ) ) ) ) (Task 25044) ( Expires 1210392000) (Accept (< temperature 0 ) ) ( Report ( location time temperature ) ( Every 5 Minute ) ( and (< temperature 0) (< humidity 2 0 ) ) ) ( Report ( location time temperature humidity ) ( Every 10 Minute ) ( and (> temperature 20) (> humidity 8 0 ) ) )

13. Threat Model Carrier Anonymity  De-anonymizing a carrier by linking a report to the carrier  Eavesdropping on communication between MN and APs  Submitting tasks, and retrieve the reports  Registering as MN Data Integrity  Tampering with the sensor data  Submitting bogus reports to RS  Impersonating the RS to deliver bogus reports to the apps  Tampering with MN hardware or software Other threats (Not considered)  Tampering directly with MN sensors  Denial-of-service threats

14. Trust Model Carrier  Trusting the node software to properly implement AnonySense Protocol Mobile Nodes  Communicating with TS, and RS using WiFi APs  MN trusting the RA to certify the identities of TS and RS  RA certifying each MN as valid using a group signature  MN trusting RA to certify authenticity of each task Applications  Trusting RA to certify TS and RS  Trusting TS to deploy tasks as requested  Trusting MN to correctly execute tasks  Apps are not authenticated

15. Trust Model Registration Authority  Trust Nothing TS/RS  Trusting RA to certify valid MNs only  Not trusting apps Certifying MNs  Running proper version of AnonyTL  Verifying the MN’s attributes  Providing MN with a group signature  MN maintain anonymous

16. Protocol Tasking Protocol: Getting tasks from apps to mobile nodes  Task Generation  Task Verification  Response to App  Tasking Nodes Reporting Protocol: MNs reporting sensor data back to apps  Data fusion  Data retrieval  MAC address recycling Security Properties

17. Tasking Protocol Task Generation  App generates the task, sends it to TS using SSL  ensuring true TS receives it  Specifies an expiration date in the task  TS generates a unique ID for the task Task Verification  If syntax is valid, TS sends it to RA  RA computes k, if k >kg, RA prepares certificate  RA sends the certificate (hash of the task, and task ID) to TS Response to App  If task is incorrect, or k< kg, TS sends a message to App  Otherwise, TS replies to App with a task ID with a TS-signed certificate Tasking nodes  Polls the TS for tasks  MN uses anonymous authentication to prove its validity using its group signature  TS delivers all tasks to MN  Some nodes will repeatedly retrieve the same tasks

18. Reporting Protocol MN signs each report using a group-signature Encrypts it with the RS public key MIX network delivers reports to RS in a “mixed” fashion Data fusion  RS aggregates reports from a task  Reports combined using k-anonimity Data Retrieval  App polls the RS for available data using enc. Channel  App presents the TS-signed token to prove its authority MAC address recycling  MN might be tracked using static MAC address  MN changes its MAC everytime so that report and task actions may not be linked

19. AnonySense Architecture

20. Security Properties Adversary can learn little by eavesdropping on MN communication  all communications are encrypted Adversary cannot pose as TS/RS  MNs and Apps have certificate from RA for public key of TS/RS TS cannot link MN’s tasks  each arrives from one MAC address/ intervals are randomized Adversary can learn little to pose as App  any task must satisfy k> kg Adversary cannot link MN’s reports  each arrives from one MAC address/ intervals are randomized / uses MIX

21. Evaluation Implementation  Communication SSL-encrypted HTTP channel MN encrypts its report with MIX node keys, sending messages using SMTP  Servers Written in Ruby PL  Mobile Nodes Nokia N800 Software in C++ Downloading tasks using libcurl Verifying using RSA/ SHA-1 No MAC address rotation

22. Evaluation Applications  RogueFinder Detecting rogue APs in a given area Tasking AnonySense to report all APs visible to MNs Sensor: MN’s Wi-Fi interface  ObjectFinder Finding the bluetooth Mac address of a lost object After detecting the specified MAC address, MN reports the current location

23. Experimental Results Overall Result  MN detected 84 unique APs, of which RogueFinder found 12 as rogues  Average time for MN receiving task from RF, later reporting it : 15.5 sec  Average power cost: 6. 64 mW  Complete task-scan-report cycle cost : 0.11J  17 times smaller than MP3-quality audio streaming

24. Experimental Results Data Transfer

25. Experimental Results Overall Energy Consumption

26. Experimental Results Detailed Energy Consumption

27. Discussion Scalability  Reduce Increasing burden on MN TS could give MN only a subset of tasks MN rejecting some tasks when overloaded Carrier Policy  Configuring a policy on which tasks to accept Attribute-based tasking  Using other techniques to further enforce anonymity like “statistical k- anonymity” Task Dissemination  App may receive much more reports than needed  AnonySense allow removing a task Delay Tolerance  The more carriers, the less latency in message passing using MIX Data Quality  More accurate data  Less privacy for users  Allowing applications to request a certain granularity of either time or location

28. Summary AnonySense: A comprehensive system to preserve privacy of users in opportunistic- sensing environments Allowing applications to request sensor data using task language Data collected in opportunistic, delay- tolerant manner Data reported, while the users are anonymized but verified

29. Thanks