Upload
elliot
View
23
Download
1
Embed Size (px)
DESCRIPTION
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]. Motivation. Problem Overview. tcpdump. Alice -> AP. IM chat…. Charlie -> AP. Video …. Bob -> AP. - PowerPoint PPT Presentation
Citation preview
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]
Motivation
2
Problem Overview
Bob -> AP WiFi probe IM chat… Alice -> AP Video … Charlie -> AP
tcpdump
3
Problem Overview
Bob -> AP WiFi probe
IM chat… Alice -> AP
Video… Charlie -> APtcpdump
???
???
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
Problem Overview
Bob -> AP WiFi probe
IM chat… Alice -> AP
Video… Charlie -> APtcpdump
???
???
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
??? -> AP
Bob -> Dave
5
Problem Overview
Bob -> AP WiFi probe
IM chat… Alice -> AP
email … Charlie -> APtcpdump
???
???
Charlie -> AP ???
Charlie -> AP ???
Charlie -> AP ???
IM chat… Alice -> AP
Charlie -> AP ???
Charlie -> AP ???
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> 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’sChristmas
Bob -> Dave
???
6
Objective
tcpdump
Bob -> AP WiFi probe
IM chat… Alice -> AP
email … Charlie -> AP
???
???
Charlie -> AP ???
Charlie -> AP ???
Charlie -> AP ???
IM chat… Alice -> AP
Charlie -> AP ???
Charlie -> AP ???
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> AP
??? -> AP ???
Mask entire contents of link layer packets
Which packets are mine? Which packets are mine?
Problem:Efficient packet filtering
Bob -> Dave
???
???
???
???
???
???
???
???
???
???
Mitigates attacks:Tracking,Profiling,
Side-channel analysis
7
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
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
Solution: SlyFi
10
Solution Overview
11
Straw man: Public Key Protocol
Probe “Alice”
Client Service
Key-private encryption(e.g., ElGamal)
KAlice
Check signature:
Try to decrypt
K-1Alice
KBob
Based on [Abadi ’04]
K-1BobSign:
timestamp
12
???
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
Observations
• Must try to decrypt every message– Common case is to rediscover known services– Can bootstrap a secret symmetric key the first time
14
Straw man: Symmetric Key Protocol
Probe “Alice”
Client Service
Symmetric encryption(e.g., AES w/ random IV)
Check MAC:
MAC: K’Shared
KShared
K’Shared
timestamp
Try todecrypt
with each shared key
KShared1
KShared2
KShared3…
15
???
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
???
Discovery & Binding Messages: Tryst
Probe “Alice”
Client Service
Symmetric encryption(e.g., AES w/ random IV)
Check MAC:
MAC: K’Shared
KShared
K’Shared
AT
AT
KShared
Lookup AT in atable to get KShared
timestamp
Try todecrypt
with each shared key
KShared1
KShared2
KShared3…
AT-1A0 AT
AESK’’Shared(0)
AT+1… …
AESK’’Shared(T-1) AESK’’Shared(T) AESK’’Shared(T+1)
T = time epoch
17
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
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
???
Data Transport: Shroud
Data
Client Service
Symmetric encryption(e.g., AES w/ random IV)
Check MAC:
MAC: K’Shared
KShared
K’Shared
AT
AT
KShared
Lookup AT in atable to get KShared
timestamp
AT-1A0 AT
AESK’’Shared(0)
AT+1… …
AESK’’Shared(T-1) AESK’’Shared(T) AESK’’Shared(T+1)
T = transmission #
20
???
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
21
Evaluation
22
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
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
Link Setup Time vs. Background Rate
Tryst has less overhead than WPA25
Link Setup Failure vs. Background Rate
Tryst filtering is much more efficient than straw men26
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
Data Throughput vs. Packet Size
Shroud overhead is similar to WPA28
Data Throughput vs. Background Rate
Shroud filtering is almost as efficient as 802.1129
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