Doc.: IEEE 802.11-08/1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 1 SlyFi: Enhancing 802.11 Privacy by Concealing Link Layer Identifiers

Embed Size (px)

DESCRIPTION

doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 3 Tracking Example MAC: 01:34:4F:88:7A:FE MAC: 54:CC:F2:B8:77:10 MAC: 24:AB:87:11:62:99

Citation preview

doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 1 SlyFi: Enhancing Privacy by Concealing Link Layer Identifiers Date: Authors: doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 2 Our Wireless World doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 3 Tracking Example MAC: 01:34:4F:88:7A:FE MAC: 54:CC:F2:B8:77:10 MAC: 24:AB:87:11:62:99 doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 4 Tracking Example 01:2F:3D:44:59:22 0A:BB:C1:99:07:01 04:50:7D:FE:F1:89 Etc. 04:50:7D:FE:F1:89 12:20:00:01:7F:e2 Etc. 4:30 PM 8:30 AM SSID=Linksys SSID=MaryJaneHome SSID=DrChoice SSID=tMobile SSID=WashingtonCSE Abortion Doctors Home? doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 5 Tracking Example 01:2F:3D:44:59:22 0A:BB:C1:99:07:01 04:50:7D:FE:F1:89 Etc. 04:50:7D:FE:F1:89 12:20:00:01:7F:e2 Etc. 4:30 PM 8:30 AM Is a deal brewing? doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 6 Inventorying Example Diabetes Advertisement! HIV Advertisement! doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 7 Location tracking, user profiling, inventorying, relationship profiling are a growing concernHome headerIs djw here? djw is here doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 8 Talk Argument is increasingly insufficient Level of privacy different from what people would expect Privacy and anonymity safeguards lagging behind cellular (e.g., GSM) Slowing adoption in healthcare, finance, and military markets Important to standardize privacy enhancements Cant do within the context of the existing standard Requires changes at multiple endpoints Enhancements most effective when widely deployed Will increase attractiveness of , strengthen marketplace doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 9 Technical Feasibility SlyFi demonstrates possibility of enhancing for privacy Complete link layer solution with better privacy guarantees than 11i, 11w We prototyped it As efficient as todays protocols Same usage model as ; coexists with Academia and industry enthusiastic, e.g., 2008 ACM Mobisys Best Paper paper:source:paper:source: doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 10 Privacy Problem with Best Practices Is Bobs Network here? Proof that Im Bob Bobs Network is here MAC addr, seqno, Many exposed bits are (or can be used as) identifiers that are linked over time Confidentiality Authenticity Integrity 10 doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide Goal: Make All Bits Appear Random To Eavesdroppers Bootstrap SSID: Bobs Network Key: 0x Username: Alice Key: 0x348190 ? ? doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 12 Challenge: Making the protocol work when all bits are hidden Which packets are mine? 12 Filtering without Identifiers Without changing the usage model Without breaking services Without changing authentication machinery While staying just as efficient doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 13 Design Requirement: Add privacy to security without breaking anything else When A generates Message to B, she sends: PrivateMsg = F(A, B, Message) Where F has these properties: Confidentiality: Only A and B can determine Message. Authenticity: B can verify A created PrivateMsg. Integrity: B can verify Message not modified Unlinkability: Only A and B can link PrivateMsgs to same sender or receiver Efficiency:B can process PrivateMsgs as fast as he can receive them Compatibility with existing usage model Compatibility with existing authentication and other services doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 14 Solution Summary Unlinkability Integrity Authenticity Efficiency Confidentiality WPA MAC Pseudonyms Nave Symmetric Key SlyFi: Discovery/Binding SlyFi: Data packets Only Data Payload Long Term 14 Only Data Payload Only Data Payload doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 15 Nave approach (symmetric encryption of all bits) is slow 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 15 Different symmetric key per potential sender Cant identify the decryption key in the packet or else it is linkable doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 16 Solution Summary Unlinkability Integrity Authenticity Efficiency Confidentiality WPA MAC Pseudonyms Nave Symmetric Key SlyFi: Discovery/Binding SlyFi: Data packets Long Term 16 Only Data Payload Only Data Payload Only Data Payload doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 17 Symmetric key almost works, but tension between: Unlinkability: cant 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: An open source reference implementation 17 AB doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 18 SlyFi Probe Bob ClientService Symmetric encryption (e.g., AES w/ random IV) Check MAC: MAC:K AB Lookup T i in a table to get K AB AB 18 Need a shared variable, i, that changes often TiTi AB Main challenge: Sender and receiver must synchronize i without communication Main challenge: Sender and receiver must synchronize i without communication doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 19 Data Transport Synchronize i on transmission number Only sent over established connections Expect messages to be delivered Synchronize i on loose idea of time Infrequent: sent when trying to associate Narrow interface: single application, few side-channels Linkability at short timescales is OK Discovery and Binding On receipt of T i, receiver computes T i+1 Handling message loss or clock skew: On receipt of T i save T i+1, , T i+k in table Tolerates k consecutive losses or skew of 5 * k minutes No loss compute one token per reception AB doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 20 Discovery/Binding Time SlyFi link setup has less overhead than WPA 20 Lower = Better doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 21 Data Throughput SlyFi data filtering is about as efficient as With simulated AES hardware Performs like symmetric key Higher = Better doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 22 Solution Summary Unlinkability Integrity Authenticity Efficiency Confidentiality WPA MAC Pseudonyms Nave Symmetric Key SlyFi: Discovery/Binding SlyFi: Data packets Long Term Long Term 22 Only Data Payload Only Data Payload Only Data Payload doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 23 Other Protocol Details to Work Through Broadcast Higher-layer binding Time synchronization Roaming Coexistence with Link-layer ACKs Preventing replay attacks Location services etc. See paper for some proposals 23 doc.: IEEE /1022r0 Submission September 2008 Greenstein (Intel) et al. Slide 24 Conclusion Wireless devices are becoming personal and pervasive Best practices dont protect users from simple attacks Long-term linking: tracking, profiling, inventorying Short-term linking: side-channel attacks We need a protocol enhancement to defend against these attacks That removes all identifying bits 24 paper:source:paper:source: