Improving Wireless Privacy with an Identifier-Free Link Layer Protocol

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

2. Motivation

3. Problem Overview tcpdump Alice -> AP IM chat… Charlie -> AP Video … Bob -> AP WiFi probe

4. Problem Overview ??? tcpdump ??? Alice -> AP IM chat… State-of-the-art: WPA-CCMP Encryption Charlie -> AP Video… Bob -> AP WiFi probe • Sensitive information remains exposed: • Sender, receiver identities  location tracking • Sender, receiver relationship  profiling • Management frame information  profiling

5. Problem Overview ??? -> AP ??? tcpdump Bob -> Dave ??? ??? -> AP Alice -> AP IM chat… Recent research: MAC address pseudonyms Charlie -> AP Video… Bob -> AP WiFi probe • 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

6. Problem Overview ??? -> AP ??? big tcpdump Bob -> Dave ??? -> AP ??? Alice -> AP Alice -> AP IM chat… IM chat… ??? -> AP 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 Charlie -> AP email … ??? -> AP big Bob -> AP WiFi probe Charlie -> AP Charlie -> AP Charlie -> AP Charlie -> AP Charlie -> AP ??? -> AP ??? ??? ??? ??? ??? ??? ??? -> AP small ??? -> AP big ??? -> AP small

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

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 PrivateMessagesto same sender or receiver. • Authenticity: B can verify A created PrivateMessage. • Confidentiality: Only A and B can determine Message. • Integrity: B can verify Messagenot modified.

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

10. Solution: SlyFi

11. Solution Overview

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

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

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

15. KShared1 KShared2 KShared3 … Try to decrypt with each shared key Straw man: Symmetric Key Protocol Client Service Check MAC: K’Shared Probe “Alice” timestamp MAC: K’Shared KShared Symmetric encryption(e.g., AES w/ random IV) ???

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

17. KShared1 KShared2 KShared KShared3 … Try to decrypt with each shared key Lookup AT in a table to get KShared AESK’’Shared(0) AESK’’Shared(T-1) AESK’’Shared(T) AESK’’Shared(T+1) … … A0 AT-1 AT AT+1 Discovery & Binding Messages: Tryst Client Service Check MAC: K’Shared Probe “Alice” timestamp MAC: K’Shared AT KShared AT Symmetric encryption(e.g., AES w/ random IV) T = time epoch ???

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

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

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

21. Data Transport: Shroud • On receipt of packet with address AT,compute next address AT+1 • Handling message loss: • Compute AT+1, … , AT+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

22. Evaluation

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

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?

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

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

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?

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

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

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