Improving Wireless Privacy with an Identifier-Free Link Layer Protocol

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