Sensor-enabled cellphones Wilshire, Stanley Ave, 90036 10:00am Mar20th 2009.

AnonySense: Privacy-Aware People-Centric

SensingCory 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: Vigneshwar Raghuram

Outline

Motivation AnonySense Architecture

System Design Task Language Threat Model Trust Model

Protocol Tasking Protocol Reporting Protocol Security Properties

Evaluation

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

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

Challenges

Dependent on a large-scale, and heterogeneous personal devices

Should be implemented across autonomous wireless access points, and public internet

Protecting users’ privacy

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, 9003610:00am

Mar20th 2009

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

TaskAnonymous

Verified Report

System Components

Mobile Nodes (MN): Sensing

Computation

Memory

Wireless communication

Carrier: carries the mobile node

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

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

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

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 20 ) ) )( Report ( location time temperature humidity )

( Every 10 Minute )( and (> temperature 20) (> humidity 80 ) ) )

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

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

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

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

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

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-anonymity

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

AnonySense Architecture

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

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

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

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

Experimental Results

Data Transfer

Experimental Results

Overall Energy Consumption

Experimental Results

Detailed Energy Consumption

Discussion

Scalability Reduce Increasing burden on MN

TS could give MN only a subset of tasks MN rejecting some tasks when overloaded

Task Dissemination App may receive much more reports than needed AnonySense allow removing a task

Carrier Policy Configuring a policy on which tasks to accept

Attribute-based tasking Using other techniques to further enforce anonymity like “statistical k-

anonymity” 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

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

Thanks