Toward a Framework for Preventing Side-Channel Attacks

in Wireless Networks

Jeff Pang

The problem

time timePacket sizes, timing:

→ [probably generated by alice’s laptop]→ [probably keystrokes: wh!teR@bb!t]← [probably webpage: http://rightwing-politics.net/madhatter/blog.html]← [probably watching video: Wonderland.DivX.avi]→ [probably speaking: Spanish]← [probably using a p2p application]

http…ali…@bb!t divx…data…bcdPacket contents:

→ user login: alice→ password: wh!teR@bb!t← webpage: http://rightwing-politics.net/madhatter/blog.html← streaming video: Wonderland.DivX.avi→ voip: “¿Cómo es usted, somberero loco?”← p2p download: QueenOfHearts.mp3

WPA/VPN/SSHTunnel

The problem• Adversary

– Passive eavesdropper

– Packet contents appear random

– Can only determine packet size, time, direction

• Packet sizes and timing can reveal sensitive information– Passwords used [Song ’01]

– Webpages visited [Sun ’02]

– Videos watched [Saponas ’07]

– Languages spoken (over VoIP) [Wright ’07]

– Identity (e.g., broadcast packet sizes) [Pang ’07]

Problem 1: packet size

• Set of packet sizes reveals:– identity: >35% accuracy (< 1 hour of traffic)– webpage: 76% accuracy (< 1 min of traffic)– voip language: 66% accuracy (3 min of traffic)

• Usual countermeasures:– Pad packets to [almost] same size

time

Broadcast transmission sizes

time

Broadcast transmission sizes

300250

200

100500

120

Example:Broadcast packet sizes used as a fingerprint

Problem 2: packet timing• Inter-packet

spacing reveals:– Keystrokes: 50x

faster password cracking time

• Countermeasures:– [near] constant bit

rate cover traffic

Problem 3: size evolution over time

• Fourier transform/HMM on packet size evolution:– video: 66% accuracy (10 min of traffic)– application type: 76% accuracy (10 min of traffic)

• Usual countermeasures:– Send at [near] constant bit rate

Example:DFT of VBRvideos as fingerprints≈

DFT

Previous solutions

Information prevented from leakingall potential

Ap

plic

atio

n tr

an

spa

ren

cy

none

code

mod

ifica

tion

opa

que

know

ledg

e of

traf

fic p

atte

rns

Trace-based cover traffic[Newman-Wolfe ‘92, Guan ‘01]

Specific attack countermeasures[Timmerman ’99, Smart ‘00]

Language-based information flow security[Volpano ’96, Agat ’00, Meyers ‘99]

Status quo

Proposal: Framework to implement select countermeasures– Enable overhead / privacy protection trade-off– Similar to signature-based anti-virus and IDS

overhead

Naïve cover traffic

Part I: Rule-based masking

• Example: masking packet sizes

time

Input transmissions

300250

200

100

120

time

Output transmissions

400400

400

400

400

Input transmissions

Masking rules: “output size independent of input size”

Performance constraints: “minimize delay”

System overview definition

Masking rulesPerf. constraints

outputOutput traffic profile

Primary challenges definition: masking rule language

– Must be flexible enough for real countermeasures• Describe packet size, inter-packet spacing• Describe sequences, frequencies, periodicity• Describe multiple time granularities

– Must be uniform enough to enable rule composition• e.g. break up all packets so they have uniform size

express all rules in terms of inter-packet spacing

output: satisfying multiple masking rules– Must handle infeasible constraints gracefully

• Allow the rule language to describe some slack• e.g. “make output as independent as possible of input”

Design questions• Where to apply rules?

– per flow:• Can use some flows to cover for others

• Assumes flows (mostly) independent

– on all outbound traffic• Takes into account flow dependencies

• Harder to make application-specific rules

– combination of both• Requires explicit declaration of dependencies

• How opaque should traffic be?– e.g., treat TCP flows as a unit?

• Possibly avoid adverse end-to-end interactions

– Don’t inspect packet contents at all• Simpler to analyze, implement rules, hide RTT/bottleneck

App 1 App 2 App 3

network

Part II: Learning masking rules• APs learn location dependent rule parameters

– Traffic profiles become location rather than user dependent– Mimic local traffic patterns to customize overhead

• Challenges:– How to learn parameters over time– How to minimize performance impact of adversarial clients

learner

input traffic profiles

home masking rules

learner

input traffic profiles

airport masking rules

learner

input traffic profiles

starbucks masking rules

Summary

• Side channels reveal encrypted data• Wireless makes attacks easy to perform

• Attacks discovered after apps deployed• Need temporary “patches” afterward

• Proposed rule-based masking• Primary challenges: rule language, composition