1 / 85

Improving the Privacy of Wireless Protocols

Improving the Privacy of Wireless Protocols. Jeffrey Pang Carnegie Mellon University. tcpdump. Protocol Header. Protocol Header. Protocol Header. Protocol Header. Protocol Header. Protocol Control Info. Buddy list: Alice, Bob, …. Protocol Control Info. Blood pressure: high.

alec
Download Presentation

Improving the Privacy of Wireless Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Improving the Privacy ofWireless Protocols Jeffrey Pang Carnegie Mellon University

  2. tcpdump Protocol Header Protocol Header Protocol Header Protocol Header Protocol Header Protocol Control Info Buddy list: Alice, Bob, … Protocol Control Info Blood pressure: high Home location=(47.28,…

  3. Protocol Header tcpdump Protocol Control Info Protocol Header Protocol Control Info Protocol Header Protocol Header Protocol Header Link Layer Header Link Layer Header Link Layer Header Link Layer Header Link Layer Header Protocol Header Protocol Header Protocol Header Protocol Header Protocol Header Home location=(47.28,… Protocol Control Info Home location=(47.28,… Buddy list: Alice, Bob, … Protocol Control Info Blood pressure: high Blood pressure: high PrivateVideo1.avi Buddy list: Alice, Bob, … PrivatePhoto1.jpg

  4. What can Protocol Control Info Reveal? www.bluetoothtracking.org Location traces can be deanonymized [Beresford 03, Hoh 05-07, Krum 07] Kim’s House 00:16:4E:11:22:33

  5. Who Might be Tracking You?

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

  7. Talk Overview • Building identifier-free protocols • Previous work: Temporarydevice 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] • My work: How to build efficient protocols that reveals no transmitted bits to eavesdroppers [MobiSys 08 Best Paper, HotNets 07] Quantifying the tracking threat

  8. Best Security Practices Today Bootstrap Name: Alice’s Device Secret: Alice<3Bob Name: Bob’s Device Secret: Alice<3Bob Out-of-band (e.g., password, PIN) From: 11:22:33:44:55:66 To: BROADCAST Search probe From: 11:22:33:44:55:66 To: BROADCAST Announcement Discover Authenticate and Bind From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Credentials, key exchange  Ksession From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66 Credentials, key exchange Use to encrypt & authenticate • Confidentiality • Authenticity • Integrity From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Send Data From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66

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

  10. ? 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 802.11 network(Poor network etiquette?) • Can we still identify the culprit? bittorrent transfer 00:0E:35:CE:1F:59 ? 00:0E:35:CE:1F:59 00:0E:35:CE:1F:59

  11. ? Tracking Example • Fingerprint: network names in probes Wardriving Database 00:0E:35:CE:1F:59 Probe: “roofnet” User of “roofnet” community network at MIT

  12. Problem: Long-term Linkability Bootstrap Name: Bob’s Network Secret: Alice<3Bob Name: Alice’s Laptop Secret: Alice<3Bob From: 11:22:33:44:55:66 To: BROADCAST Search probe From: 11:22:33:44:55:66 To: BROADCAST Announcement Discover Is Bob’s Network here? Identifiers needed for rendezvous! Bob’s Network is here Identifiers needed for authentication! Authenticate and Bind From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Credentials, key exchange Proof that I’m Alice From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66 Credentials, key exchange Proof that I’m Bob From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Send Data From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66

  13. time Tracking Example bittorrent transfer 11:11:22:33:44:55 11:11:22:33:44:55 11:11:22:33:44:55 00:0E:35:CE:1F:59 Probe: “roofnet” ?

  14. time Tracking Example • Fingerprint: IP broadcast packet sizes • Set of broadcast packet sizes in network traffic • e.g., advertisements by Apple Bonjour, iTunes, NetBIOS 11:11:22:33:44:55 00:0E:35:CE:1F:59 239 bytes 239 bytes 11:11:22:33:44:55 00:0E:35:CE:1F:59 245 bytes 245 bytes 257 bytes 257 bytes 11:11:22:33:44:55 00:0E:35:CE:1F:59 ?

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

  16. Problem: Short-term Linkability Bootstrap Name: Bob’s Network Secret: Alice<3Bob Name: Alice’s Laptop Secret: Alice<3Bob From: 11:22:33:44:55:66 To: BROADCAST Search probe From: 11:22:33:44:55:66 To: BROADCAST Announcement Discover Is Bob’s Network here? Bob’s Network is here Authenticate and Bind From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Credentials, key exchange Proof that I’m Alice From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66 Credentials, key exchange Proof that I’m Bob Identifiers needed for packet filtering! From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Send Data 250 bytes From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66 500 bytes

  17. Fingerprint Accuracy Was Alice here? Known to be from Alice • Question: Given some traffic samples from a device, • can we identify when it is present in the future? • 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

  18. Fingerprint Accuracy Was Alice here? Known to be from Alice • Question:Given some traffic samples from a device, • can we identify when it is present in the future? • 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!

  19. Other Attacks Enabled DFT ≈ “djw” is here 802.11 header Is “djw” here? User profiling attack Movie signature attack Home Keystroke timing attack • 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, Wright08, Wright07]

  20. Is There a Common Defense? Bootstrap Name: Bob’s Network Secret: Alice<3Bob Name: Alice’s Laptop Secret: Alice<3Bob From: 11:22:33:44:55:66 To: BROADCAST Search probe From: 11:22:33:44:55:66 To: BROADCAST Announcement Discover Is Bob’s Network here? Bob’s Network is here Problem: Long-term Linkability Authenticate and Bind From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Credentials, key exchange Proof that I’m Alice From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66 Credentials, key exchange Proof that I’m Bob Problem: Short-term Linkability From: 11:22:33:44:55:66 To: AA:BB:CC:DD:EE:FF Send Data From: AA:BB:CC:DD:EE:FF To: 11:22:33:44:55:66

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

  22. Goal: Make All Bits Appear Random Bootstrap Name: Bob’s Network Secret: Alice<3Bob Name: Alice’s Laptop Secret: Alice<3Bob Discover Identifiers needed for rendezvous! Identifiers needed for authentication! Authenticate and Bind Identifiers needed for packet filtering! Send Data

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

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

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

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

  27. KShared1 KShared2 KShared3 … Straw man: Symmetric Key Protocol Probe “Lucy” Client Service Check MAC: KAB Probe “Bob” MAC: KAB KAB KSharedM Try to decrypt with each key (accounts + associations) Symmetric encryption(e.g., AES w/ random IV) O(M)

  28. KShared1 KShared2 KShared3 … Straw man: Symmetric Key Protocol Client Service Check MAC: KAB Probe “Bob” MAC: KAB Too slow!(APs have 100s of accounts) KAB KSharedM One key per sender (accounts + associations) Symmetric encryption(e.g., AES w/ random IV) 1.5 ms/packet (M=100) (Need < 200 μs/packet for 802.11g)

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

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

  31. SlyFi • 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: T1 , T2 , T3 , … • A attaches Ti to encrypted packet for B AB AB AB AB

  32. KAB Lookup Tiin hash table to get KAB SlyFi • Required properties: • Third parties can not link Ti and Tj if i ≠ j • Adoesn’t reuse Ti • A and B can compute Tiindependently Client Service AB AB Check MAC: KAB AB Probe “Bob” AB MAC: KAB Main challenge: Sender and receiver must synchronize i KAB AB Ti AB Symmetric encryption (e.g., AES w/ random IV) AB 150 μs/packet (software) AB Ti = AES(KAB, i) Ti = AES(KAB, i)

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

  34. SlyFi: Discovery/Binding Not here. Not here. ... i = ? AB AB AB Probe: “Bob’s Device” Probe: “Bob’s Device” Probe: “Bob’s Device” T2 Ti T1 • Discovery & binding messages: • Often sent when other party is not present  Can’t rely on transmission reception to synchronize i

  35. SlyFi: Discovery/Binding i = i =  hashtable AB AB AB Ti-c T i … Ti+c • 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 AB Probe: “Bob’s Device” Ti • Handling clock skew: • Receiver B saves Ti-c, … , Ti+cin table • Tolerates clock skew of c minutes • Steady state: compute one new token per minute AB AB

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

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

  38. Performance Evaluation Time to setup a link Data throughput (Previous proposal similar to symmetric key) • Open-source Linux kernel module:http://tw.seattle.intel-research.net • Evaluated on embedded devices • SlyFi is about as efficient as 802.11 (wifi-open)

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

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

  41. Hotspot Recommender System Our Goal community uploads reports 100 kbps tmobile 300 kbps Public Report Database attwifi (ap 1) 100 kbps attwifi (ap 2) 300 kbps linksys Doesn’t work! seattlewifi VoIP is blocked! 1 Mbps, blocks VoIP Free Public Wifi Doesn’t work! 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

  42. Other Research and Future Plans Ubiquitous Computing Systems Wide-Area Internet Systems • Wireless Protocol Privacy[MobiSys 08, Mobicom 07, HotOS 07] • Quantifying privacy threats • Identifier-free link layer protocols • Peer-to-Peer Games[SIGCOMM 08, NSDI 06, IPTPS 07] • Scalable gameplay update distribution • Attention-based update prioritization • Player simulation with “guidable” A.I. • Wireless Service Discovery[MobiSys 09, HotNets 07] • Hotspot recommender system • Private device discovery without per-device bootstrapping • 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 Community Sensing • Location-aware measurement platform for mobile devices Cloud Computing for Games • Automatic scaling & migration for massively multiplayer online games Home Networking • Out-sourcing network management • Social networks for access-control • Private application-layer discovery

  43. === TOPICS ===

  44. Peer-to-Peer Games Our Goal + + Who I’m playing attention to Me P2P High-speed Large-scale 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

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

  46. DNS Measurement Our Goal Root Servers ... gTLD Servers Authoritative DNS Servers 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 • Understand server characteristics: • Availability • Load balance • Deployment characteristics Local DNS Servers 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

  47. === MOTIVATION ===

  48. 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)

  49. 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

  50. 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] • 802.11 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

More Related