AnonySense: Privacy-Aware People-Centric Sensing

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 Wilshire, Stanley Ave, 90036 10:00am Mar20th 2009 • Report includes time and location of the sensor  revealing user’s location at that time • Integrity of system and reliability of report  User trusted??

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 System Task Anonymous Verified Report App

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