Improving the Privacy of Wireless Protocols Jeffrey Pang Carnegie Mellon University

2

3 Protocol Header Protocol Control Info

What can Protocol Control Info Reveal? 4 Location traces can be deanonymized [Beresford 03, Hoh 05-07, Krum 07] Kim’s House

Who Might be Tracking You? 5

Talk Overview Motivation Quantifying the tracking threat Building identifier-free protocols Other research 6

Building identifier-free protocols Quantifying the tracking threat –My work: How to build efficient protocols that reveals no transmitted bits to eavesdroppers [MobiSys 08 Best Paper, HotNets 07] –Previous work: Temporary device addresses [Gruteser 05, Hu 06, Jiang 07, Stajano 05] –My work: Temporary addresses are not enough; Other protocol info can be used to track devices [MobiCom 07, HotOS 07] Talk Overview 7

Name: Bob’s Device Secret: Alice<3Bob Name: Alice’s Device Secret: Alice<3Bob Bootstrap Out-of-band (e.g., password, PIN) Confidentiality Authenticity Integrity Best Security Practices Today 8  K session Use to encrypt & authenticate

Discover From: 19:1A:1B:1C:1D:1E To: BROADCAST From: 19:1A:1B:1C:1D:1E To: BROADCAST Search probe From: 22:1E:3E:4F:A1:45 To: BROADCAST From: 22:1E:3E:4F:A1:45 To: BROADCAST Announcement From: 19:1A:1B:1C:1D:1E To: 22:1E:3E:4F:A1:45 From: 19:1A:1B:1C:1D:1E To: 22:1E:3E:4F:A1:45 Credentials, key exchange From: 22:1E:3E:4F:A1:45 To: 19:1A:1B:1C:1D:1E From: 22:1E:3E:4F:A1:45 To: 19:1A:1B:1C:1D:1E Credentials, key exchange Authenticate and Bind Authenticate and Bind From: 19:1A:1B:1C:1D:1E To: 22:1E:3E:4F:A1:45 From: 19:1A:1B:1C:1D:1E To: 22:1E:3E:4F:A1:45 From: 22:1E:3E:4F:A1:45 To: 19:1A:1B:1C:1D:1E From: 22:1E:3E:4F:A1:45 To: 19:1A:1B:1C:1D:1E Send Data Confidentiality Authenticity Integrity Best Security Practices Today 9 Temporary Addresses: [Gruteser 05, Hu 06, Jiang 07, Stajano 05]  K session

Tracking Example Consider one user at SIGCOMM 2004 – Seen in an “anonymized” wireless trace (device addresses hashed, effectively a temporary address) – Transferred 512MB via BitTorrent on a congested network (Poor network etiquette?) Can we still identify the culprit? 10

Tracking Example Fingerprint: network names in probes ? User of “roofnet” community network at MIT Wardriving Database 11

Bootstrap Problem: Long-term Linkability 12 Name: Alice’s Laptop Secret: Alice<3Bob Name: Bob’s Network Secret: Alice<3Bob Is Bob’s Network here? Bob’s Network is here Identifiers needed for rendezvous! Proof that I’m Alice Proof that I’m Bob Identifiers needed for authentication!

Tracking Example time 13

Tracking Example Fingerprint: IP broadcast packet sizes – Set of broadcast packet sizes in network traffic – e.g., advertisements by Apple Bonjour, iTunes, NetBIOS ? time 14

From: 12:34:56:78:90:ab To: 11:22:33:44:55:66 From: 12:34:56:78:90:ab To: 11:22:33:44:55:66 From: 12:34:56:78:90:ab To: 11:22:33:44:55:66 From: 12:34:56:78:90:ab To: 11:22:33:44:55:66 From: 00:00:99:99:11:11 To: 11:22:33:44:55:66 From: 00:00:99:99:11:11 To: 11:22:33:44:55:66 From: 00:00:99:99:11:11 To: 11:22:33:44:55: bytes 500 bytes 250 bytes 200 bytes Data packets in the same session remain linked; in aggregate, these can be fingerprints Data packets in the same session remain linked; in aggregate, these can be fingerprints Problem: Short-term Linkability 15 From: 00:00:99:99:11:11 To: 22:33:AA:BB:CC:DD From: 00:00:99:99:11:11 To: 22:33:AA:BB:CC:DD From: 00:00:99:99:11:11 To: 22:33:AA:BB:CC:DD 11:22:33:44:55:66 22:33:AA:BB:CC:DD

Bootstrap Problem: Short-term Linkability 16 Name: Alice’s Laptop Secret: Alice<3Bob Name: Bob’s Network Secret: Alice<3Bob Is Bob’s Network here? Bob’s Network is here Proof that I’m Alice Proof that I’m Bob Identifiers needed for packet filtering! 250 bytes 500 bytes

Fingerprint Accuracy Developed an automated identification algorithm – Based on Naïve Bayes classifier – Fingerprints: network names broadcast packet sizes supported capabilities Simulated user tracking with traffic from 500+ users – Assume encryption and device address changes each hour 17 Question: Given some traffic samples from a device, can we identify when it is present in the future? Question: Given some traffic samples from a device, can we identify when it is present in the future? Was Alice here? Known to be from Alice

Fingerprint Accuracy Results: – 53% of devices can be identified with 90% accuracy when at a small hotspot for the day (5 devices/hour) – 27% with 99% accuracy – 17% even if in a very busy hotspot (100 users/hour) – More fingerprints exist  this is only a lower bound! 18 Question: Given some traffic samples from a device, can we identify when it is present in the future? Question: Given some traffic samples from a device, can we identify when it is present in the future? Was Alice here? Known to be from Alice

Other Attacks Enabled User profiling, inventorying, relationship profiling – [Greenstein 07, Jiang 07, Pang 07] Side-channel analysis on packet sizes and timing – Exposes keystrokes, webpages, movies, VoIP calls, … [Liberatore 06, Saponas 07, Song 01, Wright 08, Wright 07] ≈ DFT Movie signature attack Keystroke timing attack Home header Is “djw” here? “djw” is here User profiling attack 19

Bootstrap Is There a Common Defense? 20 Name: Alice’s Laptop Secret: Alice<3Bob Name: Bob’s Network Secret: Alice<3Bob Is Bob’s Network here? Bob’s Network is here Proof that I’m Alice Proof that I’m Bob Problem: Long-term Linkability Problem: Short-term Linkability

Goal: Make All Bits Appear Random Bootstrap 21 Name: Alice’s Laptop Secret: Alice<3Bob Name: Bob’s Network Secret: Alice<3Bob No bits linkable over the long-term Many streams overlap in real traffic  much nosier side-channels

Goal: Make All Bits Appear Random Bootstrap 22 Identifiers needed for rendezvous! Identifiers needed for authentication! Identifiers needed for packet filtering! Name: Alice’s Laptop Secret: Alice<3Bob Name: Bob’s Network Secret: Alice<3Bob

Talk Overview Motivation Quantifying the tracking threat Building identifier-free protocols Other research 23

Design Requirements When A generates Message to B, she sends: F(A, B, Message) → PrivateMessage where F has these properties: – Confidentiality: Only A and B can determine Message. – Authenticity: B can verify A created PrivateMessage. – Integrity: B can verify Message not modified. – Unlinkability: Only A and B can link PrivateMessages to same sender or receiver. – Efficiency:B can process PrivateMessages as fast as he can receive them. A→B Header…Unencrypted payload 24

Solution Summary Unlinkability Integrity Authenticity Efficiency Confidentiality Today’s protocols (e.g., WPA) Public Key Symmetric Key SlyFi: Discovery/Binding SlyFi: Data packets Only Data Payload Only Data Payload Only Data Payload Only Data Payload Only Data Payload Only Data Payload Finger- prints remain 25 Temporary addresses (e.g., [Gruteser 05, Jiang 07])

Straw man: Encrypt Everything Idea: Use bootstrapped keys to encrypt everything 26 Name: Bob’s Network Secret: Alice<3Bob Name: Alice’s Laptop Secret: Alice<3Bob Bootstrap K AB K BA derive keys - Key for Alice→Bob - Key for Bob→Alice

Straw man: Symmetric Key Protocol Probe “Bob” ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K AB K Shared1 K Shared2 K Shared3 … O(M) 27 Probe “Lucy” K SharedM Try to decrypt with each key (accounts + associations)

Straw man: Symmetric Key Protocol Probe “Bob” ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K AB K Shared1 K Shared2 K Shared3 … 1.5 ms/packet (M=100) 28 K SharedM One key per sender (accounts + associations) (Need < 200 μs/packet for g)

Straw man: Public Key Protocol Probe “Bob” Key-private encryption (e.g., ElGamal) K Bob Check signature: Try to decrypt K -1 Bob K Alice Based on [Abadi ’04] K -1 Alice Sign: ClientService 29 O(1)~100 ms/packet

Solution Summary Unlinkability Integrity Authenticity Efficiency Confidentiality Public Key Protocol Symmetric Key Protocol SlyFi: Discovery/Binding SlyFi: Data packets Only Data Payload Only Data Payload Only Data Payload Only Data Payload Only Data Payload Only Data Payload Finger- prints remain Temporary addresses Today’s protocols 30

Symmetric key almost works, but tension between: – Unlinkability: can’t expose the identity of the key – Efficiency: need to identify the key to avoid trying all keys Idea: Identify the key in an unlinkable way Approach: – Sender A and receiver B agree on tokens: T 1, T 2, T 3, … – A attaches T i to encrypted packet for B SlyFi AB 31

150 μs/packet (software) SlyFi Probe “Bob” ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K AB Lookup T i in hash table to get K AB AB Required properties: – Third parties can not link T i and T j if i ≠ j – A doesn’t reuse T i – A and B can compute T i independently Required properties: – Third parties can not link T i and T j if i ≠ j – A doesn’t reuse T i – A and B can compute T i independently AB Main challenge: Sender and receiver must synchronize i Main challenge: Sender and receiver must synchronize i 32

Data messages: – Only sent over established connections  Expect messages to be delivered  i = transmission number On receipt of T i, B computes next expected: T i+1 Handling message loss? – On receipt of T i save T i+1, …, T i+k in table – Tolerates k consecutive losses (k=50 is enough [Reis ‘06]) – No loss  compute one new token per reception AB SlyFi: Data Transport 33 i = hashtable T 3 T 3+k AB … On receipt of T i, B computes next expected: T i+1 AB T 3 AB  T 2 AB T 1 AB T 4 AB On receipt of T i, B computes next expected: T i+1 Handling message loss?

SlyFi: Discovery/Binding Discovery & binding messages: – Often sent when other party is not present  Can’t rely on transmission reception to synchronize i i = ?... Not here. 34

SlyFi: Discovery/Binding 35 i = Discovery & binding messages: – Infrequent: only sent when trying to associate – Narrow interface: single application, few side-channels  Only require long-term unlinkability to prevent tracking  i =  current time/1 min  Handling clock skew: – Receiver B saves T i-c, …, T i+c in table – Tolerates clock skew of c minutes – Steady state: compute one new token per minute AB T i-c T i+c AB … hashtable  T i AB

from, to, seqno, … Credentials, key exchange from, to, capabilities, other protocol fields Bob’s Network is here from, to, capabilities, other protocol fields Is Bob’s Network here? from, to, capabilities, other protocol fields Enc(K AB, t 0, …) MAC(K AB, …) session1 session2 AB Enc(K AB,nonce, …) MAC(K AB, …) encrypt auth Discover Authenticate and Bind Authenticate and Bind Send Data Name: Bob’s Network Secret: Alice<3Bob Name: Alice’s Laptop Secret: Alice<3Bob Bootstrap SlyFi: Putting it Together 36 t0t0 t0t0 BA AB T i = AES(K AB, i) token AB t i = AES(K BA, i) session1 K AB token K AB encrypt K AB auth K BA token K BA encrypt K BA auth derive keys nonce TiTi BA nonce TiTi AB TiTi nonce TiTi BA nonce AB  K session1,2

SlyFi: Other Protocol Details Broadcast Higher-layer binding Time synchronization Roaming Coexistence with Link-layer ACKs Multi-party discovery Preventing replay attacks See Mobisys 08 paper for details 37

Performance Evaluation 38 Time to setup a linkData throughput Open-source Linux kernel module: Evaluated on embedded devices SlyFi is about as efficient as (wifi-open) (Previous proposal similar to symmetric key)

Solution Summary Unlinkability Integrity Authenticity Efficiency Confidentiality Public Key Symmetric Key SlyFi: Discovery/Binding SlyFi: Data packets Long Term Only Data Payload Only Data Payload Only Data Payload Only Data Payload Only Data Payload Only Data Payload Finger- prints remain Temporary addresses Today’s protocols 39

Talk Overview Motivation Quantifying the tracking threat Building identifier-free protocols Other research 40

Hotspot Recommender System 41 Research Challenges Preserving location privacy – Reports shouldn’t be linked, otherwise they can be used to track users – But also need to limit fraud; e.g., 1 report per hotspot per user – Solution: ecash-like reporting protocol & robust summary functions Preserving location context – Performance dependent on location with respect to access point – Wireless channel effects loss rate – Solution: estimate different loss regimes w/ distributed measurements

Peer-to-Peer Games [SIGCOMM 08, NSDI 06, IPTPS 07] Scalable gameplay update distribution Attention-based update prioritization Player simulation with “guidable” A.I. Distributed File Systems [ICDCS 07] Locality-preserving data placement Decentralized load-balancing Internet Measurement [IMC 04 x2, SIGCOMM 04] DNS infrastructure properties BGP routing and multi-homing Home Networking Out-sourcing network management Social networks for access-control Private application-layer discovery Cloud Computing for Games Automatic scaling & migration for massively multiplayer online games Community Sensing Location-aware measurement platform for mobile devices Wireless Protocol Privacy [MobiSys 08, Mobicom 07, HotOS 07] Quantifying privacy threats Identifier-free link layer protocols Wireless Service Discovery [MobiSys 09, HotNets 07] Hotspot recommender system Private device discovery without per-device bootstrapping Other Research and Future Plans Ubiquitous Computing SystemsWide-Area Internet Systems

=== TOPICS === 43

Peer-to-Peer Games Scaling challenges How to quickly discover and replicate players in your area How to prioritize updates based on attention when bandwidth is limited How to disseminate updates between peers with very little upload capacity, on average 44 High-speed Large-scale ++ P2P Me Who I’m playing attention to Who I’m playing attention to Our Goal

Distributed File Systems Challenges How to maintain file locality without knowledge of future tasks How to balance load without substantial overhead 45 Traditional DHT File System Our DHT File System Files used by two tasks: Preserving file locality: Improves task success rate; depend on fewer machines Improves task performance; need fewer lookups random placement defragmented placement nodes accessed during an NFS trace

Our Goal DNS Measurement Authoritative DNS Servers gTLD Servers Root Servers Local DNS Servers Understand server characteristics: Availability Load balance Deployment characteristics Challenges Collecting DNS server addresses Active monitoring of 300,000+ servers in other domains Inferring load from visible metrics Handling network irregularities, such as dynamic DNS Key Findings Vast majority are highly availability Load is positively correlated with availability and is highly skewed Three distinct deployment styles in different DNS domains

=== MOTIVATION === 47

Who Should Care About Tracking? End-users – CRA Grand Challenge: “Give computer end-users privacy they can control” Service providers – They can’t protect customers from eavesdroppers even if they don’t track users themselves Device manufacturers – Privacy concerns about tracking can hurt sales (e.g., Intel CPUID debacle, Benetton RFID boycott) 48

Fingerprints Related Work Other fingerprints – Device driver fingerprints [Franklin 06] – TCP clock-skew fingerprints [Kohno 05] – AP beacon click skew [Jana 08] – Physical layer fingerprints (using specialized hardware) [Brik 08, Patwari 07, Hall 04] Our contributions in comparison: – First link-layer fingerprints for individual devices – Enabling tracking when link-layer encryption is employed – Enabling better coverage than some previous work – Showing how to combine implicit identifiers 49

Unlinkable Tokens Related Work Unlinkable tokens in discovery – Public key protocol (slow in practice) [Abadi 04] – Application layer protocol to find friends (uses hash-chain) [Cox 07] Unlinkable tokens in data transport – General proposal, analysis for TCP (masking piecemeal) [Nikander 05] – proposal (inefficient) [Armknecht 07] – Bluetooth proposal (uses hash-chain) [Singelee 06] SlyFi contributions in comparison – First to ensure no bits exposed (not masking identifiers piecemeal) – First to handle all major wireless protocol functions – First to leverage existing hardware (AES counter instead of hash-chain) – First link layer protocol implementation & evaluation on real devices 50

Location Privacy Related Work Privacy in location-based services, e.g., [Beresford ‘03, Gruteser ‘03, Schilit ‘03] – Don’t protect against third party eavesdroppers Privacy in RFID, e.g., [Fishkin ‘04, Juels ‘05] – General protocols do more than identification Privacy using temporary device addresses [Gruteser ’05, Hu ’06, Jiang ’07, Stajano ‘05] 51

Why not GSM Pseudonyms? GSM pseudonym properties – Provider must assign new pseudonym to client to change it – Only a single application used on GSM network GSM pseudonyms not sufficient when – Both parties in discovery want to be private – May require using pseudonym when the provider is not present (e.g., during discovery) – Many applications with many side-channels – Must accommodate device heterogeneity, evolution 52

802.11w: Protected Management Frames Unlinkability Integrity Authenticity Efficiency Confidentiality i (WPA) MAC Pseudonyms Public Key Symmetric Key SlyFi: Discovery/Binding SlyFi: Data packets Data Payload Long Term Long Term Data Payload Data Payload Unicast Frames i w 53

Research Goals and Future Plans Motivation Ubiquitous computing Federated Internet systems Research Problems How to build systems from partially trusted and heterogeneous components to operate in unpredictable and hostile environments Approach Real-world measurements Empirically driven design Building and evaluating research prototypes Example Topic Area Secure outsourcing of computer and network management Help, my network is broken! We will fix it! Other Applications Secure and private cloud computing Enterprise network management Cooperative wireless fault diagnosis 54

=== MOBISYS === 55

PHY Layer Signatures Charlie -> AP Alice -> AP Charlie -> AP ??? -> AP Physical layer fingerprints [Brik 08, Patwari 07, Hall 04] –Require uncommon and/or expensive hardware –Not as accurate in all circumstances These may be obscured by adding analog noise in hardware SlyFi raises the bar and is a necessary first step 56

Linking with Signal Strength Side-channel attack accuracy degrades significantly even if attacker tries to use signal strength to link packets Side-channel attack accuracy degrades significantly even if attacker tries to use signal strength to link packets Attack: website finger-printing [Liberatore ‘06] Attacker has 5 nodes to record packets’ RSSIs Attacker uses k-means clustering to determine which packets belong to each client. Set of RSSIs is the feature vector. Varying RSSI by +/- 5db reduces accuracy even further to 30% [Bauer ‘08] 57

Why not Time for Data Transport? Data messages: – Frequent: sent often to deliver data (1000+ pkts/sec) – Wide interface: many applications, many side-channels  Linkability at short timescales is NOT usually OK  Can NOT use loosely synchronized time to synchronize i TiTi AB TiTi TiTi TiTi = = = 58

Other Protocol Details Broadcast – All broadcast packets routed through the AP – Use same shared key for all the clients of the AP Higher-layer binding – Clients report “pseudonym MAC address”-to-IP address bindings to AP – AP answers all ARP queries Time synchronization and roaming – Use protected broadcast to transmit timestamps, same BSSID info Coexistence with – Encapsulate SlyFi in “anonymous” frame with unused FC code – Clients first search for SlyFi AP, then fall back to non-private AP search Link-layer ACKs – If fast enough, just acknowledge last SlyFi token sent – Our software implementation uses windowed ACKs 59

Multi-Party Discovery 60 Search Probe Enc(K payload1, 0, …) MAC(K payload2, …)AB T i T i = AES(K AB, i) token K payload, offset TiTiTiTi AB T i T i = AES(K AB, i)AC token K payload, offset TiTiTiTi AC... Enc(K AB,0, …) MAC(K AB, …) encrypt auth Enc(K AB,0, …) MAC(K AB, …) encrypt auth random key On receipt, check each 16-byte block that could be a token – 1500 byte packets  at most 31 lookups per packet – Can be done in parallel in hardware What if there are more than 31 receivers? – Option 1: Duplicate packet with different tokens in each – Option 2: Approximate token matching; open problem and future work

Packet Format Tryst: Discovery/Binding Shroud: Data Transport TokenUnencrypted Message 61

Protocol Timing Diagram Discover Authenticate and Bind Authenticate and Bind Send Data 62

Comparison protocols – wifi-open: with no security – wifi-wpa: with WPA PSK/CCMP – public-key:straw man – symmetric-key:straw man – armknecht: previous header encryption proposal Performance Evaluation Similar 63

Link Setup Failures “Encrypt everything” fails to setup many links 64

Token Computation Time Token computation time is negligible (Once every token interval) Using software AES, 256 Mhz Geode processor 65

Data Throughput vs. Packet Size SlyFi data transport overhead is similar to WPA 66

Data Throughput SlyFi data filtering is about as efficient as With simulated AES hardware Performs like symmetric key Higher = Better 67

Empirical Stream Interleaving Many streams interleaved even at short timescales 68

Empirical Background Probe Rate Background probes are frequent in practice 69

Empirical # Probes per Client Some clients probe for many network names 70

=== MOBICOM === 71

Tracking Users Tracking scenario: – Every users changes pseudonyms every hour – Adversary monitors some locations  One hourly traffic sample from each user in each location ? ? ? tcpdump Build a profile from training samples: First collect some traffic known to be from user X and from random others tcpdump..... ? ? ? Then classify observation samples Traffic at 2-3PM Traffic at 3-4PM Traffic at 4-5PM Traffic at 2-3PM Traffic at 3-4PM Traffic at 4-5PM Traffic at 2-3PM Traffic at 3-4PM Traffic at 4-5PM 72

Sample Classification Algorithm Core question: – Did traffic sample s come from user X? A simple approach: naïve Bayes classifier – Derive probabilistic model from training samples – Given s with features F, answer “yes” if: Pr[ s from user X | s has features F ] > T for a selected threshold T. – F = feature set derived from implicit identifiers 73

Deriving features F from implicit identifiers Set similarity (Jaccard Index), weighted by frequency: IR_Guest SAMPLE FROM OBSERVATION Sample Classification Algorithm linksys djw SIGCOMM_1 PROFILE FROM TRAINING Rare Common w(e) = low w(e) = high 74

Evaluating Classification Effectiveness Simulate tracking scenario with wireless traces: – Split each trace into training and observation phases – Simulate pseudonym changes for each user X DurationProfiled UsersTotal Users SIGCOMM conf. (2004) 4 days UCSD office building (2006) 1 day Apartment building (2006) 14 days

Question: Is observation sample s from user X? Evaluation metrics: – True positive rate (TPR) Fraction of user X’s samples classified correctly – False positive rate (FPR) Fraction of other samples classified incorrectly Evaluating Classification Effectiveness Pr[ s from user X | s has features F ] > T = 0.01 = ??? Fix T for FPR Measure TPR (See paper) 76

Results: Individual Feature Accuracy TPR  60% TPR  30% Individual implicit identifiers give evidence of identity

Results: Multiple Feature Accuracy Users with TPR >50%: Public: 63% Home: 31% Enterprise: 27% We can identify many users in all environments PublicHomeEnterprise netdests ssids bcast fields 78

Results: Multiple Feature Accuracy Some users much more distinguishable than others Public networks: ~20% users identified >90% of the time PublicHomeEnterprise netdests ssids bcast fields 79

One Application Question: Was user X here today? More difficult to answer: – Suppose N users present each hour – Over an 8 hour day, 8N opportunities to misclassify  Decide user X is here only if multiple samples are classified as his Revised: Was user X here today for a few hours? 80

Results: Tracking with 90% Accuracy Many users can be identified 81

=== WIFI-REPORTS === 82

Will Reports Improve Selection? Commercial APs at Seattle hotspot locations red = “official” AP grey = other visible AP 83

=== OLD SLIDES === 84

Other Research Wireless Service Discovery [MobiSys 09, HotNets 07] Wi-Fi hotspot reputation system Private device discovery without per-device bootstrapping Peer-to-Peer Games [SIGCOMM 08, NSDI 06, IPTPS 07] Distributed File Systems [ICDCS 07] Internet Measurement [IMC 04 x2, SIGCOMM 04] DNS infrastructure properties DNS cache compliance BGP routing and multi-homing 85

What can Protocol Control Info Reveal? 86 Wardriving Database Me

What can Protocol Control Info Reveal? 87 Wardriving Database David Wetherall

Previous work: Periodically change device addresses [Gruteser 05, Hu 06, Jiang 07, Stajano 05] Central Challenge From: 19:1A:1B:1C:1D:1E Prevent third parties from tracking wireless devices tcpdump 88

Central Challenge My thesis work: – Temporary device addresses are not enough; Other protocol info can be used to track devices [MobiCom 07, HotOS 07] – How to build efficient wireless protocols that reveals no transmitted bits to eavesdroppers [MobiSys 08 Best Paper, HotNets 07] Prevent third parties from tracking wireless devices 89

Implicit Identifiers Example Implicit identifier: other protocol fields – Header bits (e.g., power management) – Supported transmit rates – Supported authentication algorithms tcpdump ? time Protocol Fields: 11,4,2,1Mbps, WEP Protocol Fields: 11,4,2,1Mbps, WEP 90

Wireless Protocol Primer Same basic protocol for ad-hoc infrastructure Bluetooth Other wireless protocols 91

Wireless Protocol Primer Name: Bob’s PSP Password: Alice<3Bob 92

Wireless Protocol Primer 93

PrivateVideo1.avi Blood pressure: high Alice 94 To: 00:12:10:1B:41:4A From: 11:11:22:33:44:55 To: 00:10:5A:04:4F:AF To: 00:0B:DB:73:92:67 Alice’s friend? Alice? From: 00:0B:DB:73:92:67 To: 11:11:22:33:44:55 From: 10:01:D1:73:92:61

Discovery/Binding Time SlyFi link setup has overhead comparable to WPA Lower = Better 95

Data Throughput SlyFi data filtering is about as efficient as Performs like symmetric key Higher = Better 96

Research Goals Motivation Ubiquitous computing Federated Internet systems Research Problems How to build systems from partially trusted and heterogeneous components to operate in unpredictable and hostile environments Approach Real-world measurement Empirically driven design Building and evaluating research prototypes 97

Challenge: Filtering without Identifiers 98 Which packets are for me?

Straw man: Symmetric Key Protocol Probe “Bob” ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K AB Try to decrypt with each shared key K Shared1 K Shared2 K Shared3 … O(# potential senders) Can’t identify the decryption key in the packet or else it is linkable 99

What can Protocol Control Info Reveal? 100 Wardriving Database Anonymous

101 Problem: Identifiers Enable Tracking