Privacy Challenges in Pervasive Spaces RESCUE All Hands Meeting – June 2007.
-
Upload
iris-bishop -
Category
Documents
-
view
216 -
download
0
Transcript of Privacy Challenges in Pervasive Spaces RESCUE All Hands Meeting – June 2007.
Privacy Challenges in Pervasive Spaces
RESCUE All Hands Meeting – June 2007
Outline
• Pervasive spaces– Examples
• Privacy Challenges– What can lead to loss of privacy
• Towards privacy preserving pervasive spaces ..– Different components, different trust models.
• Event detection in untrusted model
RESCUE All Hands Meeting – June 2007
Pervasive Spaces
Example: Incident Level Awareness
ExampleMultimodal Surveillance
!
nearby sensors Event: shooter on campus Shooter
location: UCI#outdoors/(300,506)
events of interest
Other Pervasive Space Applications
• Patient/health monitoring systems– In hospitals– At home for elderly
• Smart offices
• Smart Demand-Response System– Smart meters that dynamically monitor consumer
behavior to optimize power usage
• Cyber physical systems in general…
RESCUE All Hands Meeting – June 2007
Outline
• Pervasive spaces– Examples
• Privacy Challenges– What can lead to loss of privacy
• Towards privacy preserving pervasive spaces
• Event detection in untrusted model
RESCUE All Hands Meeting – June 2007
Privacy Challenges
• Whenever sensor data captures human activity, there is a potential possibility of privacy breach…
RESCUE All Hands Meeting – June 2007
RESCUE All Hands Meeting – June 2007
Disclosure Risk in Observation
• Sensing– Sensor reading could disclose identity
– E.g., video data capture, RFID data capture, etc.
– Obvious fix: anonymization/ obfuscation
RESCUE All Hands Meeting – June 2007
How trajectories identify people
Bren Hall ICS Faculty offices hallway
Calit2 4th floor kitchen
Calit2 4th floor Faculty offices
hallway
RESCUE All Hands Meeting – June 2007
Event Detection can lead to Privacy Loss
• Besides location, other information contained in an event could also lead to disclosure of identity
– Server room has been accessed + knowledge that only 3 people have access to server room reveal identity of the individual to an unsafe degree.
RESCUE All Hands Meeting – June 2007
Detecting composite events can lead to inference
• A simple event can affect multiple composite events (rules)– R1: Only a faculty or an admin may login to the IBM server.
– R2: Individuals need to swipe in their cards to enter the server-room (identified up to their group, eg. Student, staff, faculty)
– Knowledge: Some student swiped his card to enter server-room at night + there was one login into the server at night.
– Bob is the only student who is also an admin.
The person who logged into the server must be Bob
RESCUE All Hands Meeting – June 2007
Inference via composite events (example 2)
• Consider two events– E1: CS 295 student enters room – E2: A ISG student enters the room
• Knowledge: – If we know E1 detected 1 out of ~8– If we know E2 detected 1 out of ~40– If we know some event was detected (not which one) 1 out of ~45– If we know both events detected 1 out of ~4!– Replace ISG by Sconce we know it is Ali!!!
• Example shows knowledge of which event or how many are detected could lead to disclosure
Cornell Study of Electric Usage in Dorms
• [Mulligan et. al] data mining over a few months of electric usage in a dorm can able to determine what activities students were involved in:– Eating– Sleeping– …– …
RESCUE All Hands Meeting – June 2007
Inference in Pervasive Spaces
• Pervasive spaces can be viewed as dynamically evolving systems.
• Sensors capture the state of the system at any given instance of time
• Knowledge of what state a system is in could result in privacy violation– A given state, or a state transition might be a distinct
characteristic pattern that identifies presence/absence of and or activity/event a person is involved in.
RESCUE All Hands Meeting – June 2007
Outline
• Pervasive spaces– Examples
• Privacy Challenges– What can lead to loss of privacy
• Towards privacy preserving pervasive spaces ..– Different components, different trust models.
• Event detection in untrusted model
RESCUE All Hands Meeting – June 2007
Towards Pervasive but (NOT) Invasive Spaces
• Before we study privacy preserving pervasive systems we need to address two things:– 1) Components of Pervasive System
– Subjects – who are immersed in space– System -- include the infrastructure owner and/or operators who
manage the infrastructure– Observers – who can communicate with the system to get view of the
state of the system and/or subjects (assuming they have the access privilege to such information).
– This is not a comprehensive model. Could differ from application to application
– 2) Trust Model– is the infrastructure and its operators trusted?– If yes, privacy policies and/or access control mechanisms can be used – Else, similar to outsourcing situation, new techniques for
implementing pervasive functionality needs to be designed
RESCUE All Hands Meeting – June 2007
RESCUE All Hands Meeting – June 2007
Disclosure risk in Untrusted Model
• Pervasive systems can be viewed as consisting of following steps:– Sensing:
• Diverse types of sensors used to track objects, entities, environment
– Event Detection: • Sensor data used to detect events of interest to application
– Action Execution: • Detected event could lead to action execution.
• Each of the above poses disclosure risks!!
• NEXT: event detection in untrusted pervasive environments– But before we do so…..
UCI Responsphere Testbed
Campus-Scale sensing, communication, storage, computing infrastructure
- 200+ video cameras, Motes, sun spots, RFID, mobile cameras, gas sensors,
-Mesh routers, WiFi, power-line network, zigbee-storage & compute clusters
RESCUE All Hands Meeting – June 2007
SATrecorder User Authentication
RESCUE All Hands Meeting – June 2007
SATrecorder Outdoor GUI
RESCUE All Hands Meeting – June 2007
SATrecorder 4th Floor Sensors
RESCUE All Hands Meeting – June 2007
SATrecorder Camera Viewer
RESCUE All Hands Meeting – June 2007
SATrecorder Event Detection
RESCUE All Hands Meeting – June 2007
SATrecorder with two camera’s output
RESCUE All Hands Meeting – June 2007
Scrubbing Sensor Streams in SATWARE
RESCUE All Hands Meeting – June 2007
Privacy Preserving Events in SATWARE
• Sample Events– A person leaves the coffee room dirty– A person drinks the last cup of coffee in the pot but forgets to switch the machine off.– A person drinks 3 cups of coffee.– …– …
• Privacy Preserving Event Detection– System can detect above events, but does not know any intermediate information about such events.– E.g., if a person drinks 3 cups of coffee the sytem is able to determine that. However, system does not know if a person has had 0, 1, or 2 cupts.
Composite events
Composite event templates
• Detect the event when: “A student drinks more than 3 cups of coffee”
e1 ≡ <u STUDENT, coffee_room, ∈ coffee_cup, dispense>
• Detect the event when: “A student tries to accesses the IBM server in the server room”
e1 ≡ <u STUDENT,server_room,*, entry>∈e2 ≡ <ū, server_room, *, exit>e3 ≡ <ū, server_room, IBM-server, login-attempt>
1e1 e3
e2
S0 SF
¬(e3 V e2)
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
Automata & State Information
• Rule Automaton template
• (Rule, Individual) Instance of a template = automaton object
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
Rule R applies to {X, Y, Z}1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
ARX
ARY
ARZ
3 automata that implement R for X, Y and Z respectively
The number of automata in the state table is proportional to the number of individuals who interact with the space
System architecture & adversary
State Information (Encrypted)
Secure Sensor node
(SSN)
Server
Secure Sensor node
(SSN)
Rules DB
::
Basic Assumptions about SSNs
• Secure data capture (Sensors are tamper-proof)
• Secure generation of basic events by SSN
• Trusted & have computation power + limited storage, can carry out encryption/decryption with secret key common to all SSNs
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
Thin trusted middleware to obfuscate origin of events
System architecture & adversary (cont.)
Adversary: Server-side snooper who wants to deduce the identity of the individual associated with a basic-event.
Minimum requirement for security:
State information is to be always encrypted on server
Recall: Goal is to ensure a level k of anonymity for each individual
Basic protocol
Return automata that (possibly) match e (encrypted match)
Store updated automata
Query for set of (encrypted)
automata that match event e
Decrypt automata, advance the state of
automata if necessary
associate encrypted label with new state. Write-back encrypted
automata
SERVER
SECURE SENSOR NODE
Generate basic event e
Question: Does encryption ensure complete anonymity?
NO! SSNs’ pattern of automata access may cause identity disclosure
Example
U enters kitchen
U takes coffee
U enters kitchen
U opens fridge
U enters kitchen
U opens microwav
e
U enters kitchen
U takes coffee
U enters kitchen
U opens fridge
R1
R3
R2
R1
R2
Applies to Tom
Tom enters Kitchen 3 firings
Applies to Bill
Bill enters Kitchen 2 firings
On an event, the # rows retrieved from state table can disclose the identity of the individual
Characteristic access patterns of automata
The characteristic access patterns of rows can potentially reveal the identity of the automaton in spite of encryption
Tom enters kitchen
Tom takes coffee
Tom enters kitchen
Tom takes
coffee
Tom enters kitchen
Tom opens fridge
x
z
y
Tom leaves coffee pot
empty
Tom opens fridge
Tom leaves fridge open
Characteristic patterns of x
P1: {x,y,z} {x y}
Characteristic patterns of yP2: {x,y,z} {x,y} {y}P3: {x,y,z} {y,z} {y}
Characteristic patterns of zP4: {x,y,z} {y z}
The set of rules applicable to an individual maybe unique potentially identify the individual
Rules applicable to TOM
Partitioning events (unrestricted)
Goal: Make the set of characteristic patterns associated with each automaton non-
identifying (k-anonymous)
Candidate solution: • Partition events into k-diverse groups• Index automata (rows of the table) by
event’s group-id instead of the event-label
Tom enters kitchen
Bill enters kitchen
Kate leaves microwave
open
Tom opens fridge
Kate enters kitchenBill takes
coffee
Tom leaves microwave
open
Kate leaves fridge open
Bill leaves microwave
open
Theorem: Checking if an event-partitioning scheme for a given set of automata is k-anonymous is NP-Complete
(The problem of checking the existence of a fixed-point-free automorphism in graphs can be reduced to this problem)
3-diverse event
clusters
Does not guarantee 3-anonymity
C1
C2
C3
Event clustering (restricted)
• Assign all events in an automaton into a single group
• If two automata have a common event, assign them to the same group Connected-groups of automata
• Combine connected-groups into k-diverse partitions
Guarantees k-anonymity
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
1 2 3
¬e1
e1 e1 e1 e1S0 SF
¬e1 ¬e1
C1
C2
All automata in a cluster are associated with the same access pattern k-anonymity
Final partition-based protocol
Return all automata belonging to Partition(e)
Store updated automata
Determine Partition(e)
(encrypted query)
Decrypt automata, Advance the state of
automata if necessary
Write-back all automata in Partition(e)
SERVER
SECURE SENSOR NODE
Generate basic event e
Minimum-cost clustering
Each connected-group of automata is represented by a ball– Each ball has a “weight” (accessed with a frequency)– Each ball has a “price” (transmission overhead)– Each ball has a “color” (denoting individual)
Optimization problem: Partition the set of balls into as many bins as required where the objective is to
∑ ( ∑ b.price ) * ( ∑ b.weight )
s.t. each bin has balls of at least k distinct colors
bini b∈bini b∈bini
Minimize
(Problem is NP-Hard: reduction from sum-of-squares problem)
Solution to optimization problem
We give some simple heuristic solution that works well in practice
1. Start with a random feasible partition meeting k-anonymity constraint
2. Iterate: determine best set of “non-conflicting” ball transfers between bins (i.e. those which reduce cost by largest amount) & execute these transfers
3. Iterate: determine best set of non-conflicting ball exchanges between bins & execute these exchanges
4. Stop when no further cost-reduction is possible
Experiments
• Prototype built on SATware-Responsphere framework
– Responsphere – communications, storage, computing framework consisting of approx. 200 sensors
– SATware – middleware for deploying pervasive space applications
• Dataset for simulation
– Generate events based on real activities in office building– 4 groups of people – STUDENT, FACULTY, STAFF, VISITOR (300 in all)– 3 regions: KITCHEN, SERVER_ROOM, FACILITIES_ROOM– 15 rules belonging to 2 classes of activities: (i) protection of resources;
(ii) suspicious activity
Sample rules
Evaluation using realistic dataset
Cost comparison using 1000 event simulation
0
500000
1000000
1500000
2000000
2500000
3000000
3500000
4000000
10 20 30 40 50 60 70 80 90 100
K (Anonymity level)
To
tal
# au
tom
ato
ns
retr
ieve
d
k-Individuals k-Connected-Groups N-Anonymous
Evaluation• Simulated sequence of 1000 events & measured communication cost
between Server and SSNs
• Compare the following 2 partitioning algorithms:1. k-individual partitioning – all automata of an individual in a single group
2. k-connected-group partitioning – remove the above constraint