Presentation is loading. Please wait.

Presentation is loading. Please wait.

Improving Wireless Privacy with an Identifier-Free Link Layer Protocol Ben Greenstein, Damon McCoy, Yoshi Kohno, Jeffrey Pang, Srini Seshan, and David.

Similar presentations


Presentation on theme: "Improving Wireless Privacy with an Identifier-Free Link Layer Protocol Ben Greenstein, Damon McCoy, Yoshi Kohno, Jeffrey Pang, Srini Seshan, and David."— Presentation transcript:

1 Improving Wireless Privacy with an Identifier-Free Link Layer Protocol Ben Greenstein, Damon McCoy, Yoshi Kohno, Jeffrey Pang, Srini Seshan, and David Wetherall [MobiSys 2008]

2 Motivation 2

3 Problem Overview Bob -> APWiFi probeIM chat…Alice -> APVideo …Charlie -> AP tcpdump 3

4 Problem Overview Bob -> APWiFi probeIM chat…Alice -> APVideo…Charlie -> AP tcpdump ??? State-of-the-art: WPA-CCMP Encryption Sensitive information remains exposed: – Sender, receiver identities  location tracking – Sender, receiver relationship  profiling – Management frame information  profiling 4

5 Problem Overview Bob -> APWiFi probeIM chat…Alice -> APVideo…Charlie -> AP tcpdump ??? Recent research: MAC address pseudonyms Probes/beacons remain exposed because: – Objective: find out if someone I know is nearby – Problem: Typically done by broadcasting identity – Sender and receiver may want to protect identity ??? -> AP Bob -> Dave 5

6 Problem Overview Bob -> APWiFi probeIM chat…Alice -> APemail …Charlie -> AP tcpdump ??? Charlie -> AP???Charlie -> AP???Charlie -> AP???IM chat…Alice -> APCharlie -> AP???Charlie -> AP??? ??? -> AP big small big small big small Side-channel analysis - patterns in packet sizes and timing can expose: Videos watched Keystrokes Webpages visited Languages spoken Device identity 70% probability: Video of Charlie Brown’s Christmas Bob -> Dave ??? 6

7 Objective tcpdump Bob -> APWiFi probeIM chat…Alice -> APemail …Charlie -> AP ??? Charlie -> AP???Charlie -> AP???Charlie -> AP???IM chat…Alice -> APCharlie -> AP???Charlie -> AP??? ??? -> AP ??? Mask entire contents of link layer packets Which packets are mine? Problem: Efficient packet filtering Bob -> Dave ??? Mitigates attacks: Tracking, Profiling, Side-channel analysis 7

8 Objective Summary of goals: – Hide entire message contents from third parties – Prevent third parties from “linking” any two packets I.e., when A generates Message to B, he sends: PrivateMessage = F(A, B, Message) where F has these security properties: – Unlinkability: Only A and B can link PrivateMessages to same sender or receiver. – Authenticity: B can verify A created PrivateMessage. – Confidentiality: Only A and B can determine Message. – Integrity: B can verify Message not modified. 8

9 Objective Assumptions: – Senders trust intended receivers with their messages We don’t protect clients from malicious APs – Senders and receivers pre-share cryptographic keys Same as WEP, WPA, and secure Bluetooth Bootstrap via pairing, passphrase, etc. (see also HotNets ‘07) Primary challenges – Private rendezvous – Efficient message filtering 9

10 Solution: SlyFi 10

11 Solution Overview 11

12 Straw man: Public Key Protocol Probe “Alice” ClientService Key-private encryption (e.g., ElGamal) K Alice Check signature: Try to decrypt K -1 Alice K Bob Based on [Abadi ’04] K -1 Bob Sign: timestamp 12 ???

13 Problem Must try to decrypt every message – Public key decryption is slow (>100ms on typical AP)  delays processing of other messages  susceptible to low-rate denial-of-service attacks 13

14 Observations Must try to decrypt every message – Common case is to rediscover known services – Can bootstrap a secret symmetric key the first time 14

15 Straw man: Symmetric Key Protocol Probe “Alice” ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K’ Shared K Shared K’ Shared timestamp Try to decrypt with each shared key K Shared1 K Shared2 K Shared3 … 15 ???

16 Observations Must try to decrypt every message – Common case is to rediscover known services – Can negotiate a secret symmetric key the first time Discovery & binding messages: – Infrequent: only sent once per association attempt – Narrow interface: single application, few side-channels  Linkability at short timescales is usually OK  Can use temporary unlinkable addresses 16

17 ??? Discovery & Binding Messages: Tryst Probe “Alice” ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K’ Shared K Shared K’ Shared ATAT ATAT K Shared Lookup A T in a table to get K Shared timestamp Try to decrypt with each shared key K Shared1 K Shared2 K Shared3 … A T-1 A0A0 ATAT AES K’’ Shared (0) A T+1 …… AES K’’ Shared (T-1)AES K’’ Shared (T)AES K’’ Shared (T+1) T = time epoch 17

18 More Problems Must try to decrypt every message – Common case is to rediscover known services – Can negotiate a secret symmetric key the first time Data messages: – Frequent: sent often to deliver data – Wide interface: many applications, many side-channels  Linkability at short timescales is NOT usually OK  Can NOT use temporary unlinkable addresses 18

19 More Problems Must try to decrypt every message – Common case is to rediscover known services – Can negotiate a secret symmetric key the first time Data messages: – Only sent over established connections  Expect messages to be delivered, barring message loss 19

20 ??? Data Transport: Shroud Data ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K’ Shared K Shared K’ Shared ATAT ATAT K Shared Lookup A T in a table to get K Shared timestamp A T-1 A0A0 ATAT AES K’’ Shared (0) A T+1 …… AES K’’ Shared (T-1)AES K’’ Shared (T)AES K’’ Shared (T+1) T = transmission # 20 ???

21 Data Transport: Shroud On receipt of packet with address A T, compute next address A T+1 Handling message loss: – Compute A T+1, …, A T+k – Can progress unless k consecutive packets are lost – Studies show k=50 sufficient for vast majority of cases – Common case: compute 1 new address per reception, except first packet, which requires 49 computations 21

22 Evaluation 22

23 Setup SlyFi implementation: – Linux kernel module using Click Modular Router – Run on Soekris devices similar to APs, iPods, etc. – Assume AP with 500 client accounts, 50 associations Compare against: – wifi-open: baseline Click unsecure 802.11 – wifi-wpa: baseline Linux 802.11 with WPA – public-key: straw man #1 – symmetric-key: straw man #2 – armknecht: previous header encryption proposal 23

24 Evaluation Metrics Link setup time – Time to discover and setup a link – Lower  shorter wait to deliver data, less interruption when roaming Key questions: – Is address computation overhead large? – Can Tryst filter messages efficiently? 24

25 Link Setup Time vs. Background Rate Tryst has less overhead than WPA 25

26 Link Setup Failure vs. Background Rate Tryst filtering is much more efficient than straw men 26

27 Evaluation Metrics Data throughput – How fast can link deliver data – Higher  faster applications – Note: Shroud uses software AES while wifi-wpa uses hardware AES  We also simulate Shroud hardware AES Key questions: – What is Shroud’s overhead? – Can Shroud filter messages efficiently? 27

28 Data Throughput vs. Packet Size Shroud overhead is similar to WPA 28

29 Data Throughput vs. Background Rate Shroud filtering is almost as efficient as 802.11 29

30 Summary We presented design, implementation of SlyFi – Link layer that encrypts entire messages – No two messages are linkable by third parties Mitigates attacks that are currently easy to do – Tracking, profiling, and side-channel attacks Performs about as well as WPA – Link setup is actually faster – Throughput penalty is comparable – Similar assumptions, but strictly stronger security 30


Download ppt "Improving Wireless Privacy with an Identifier-Free Link Layer Protocol Ben Greenstein, Damon McCoy, Yoshi Kohno, Jeffrey Pang, Srini Seshan, and David."

Similar presentations


Ads by Google