Toward a Framework for Preventing Side-Channel Attacks in Wireless Networks Jeff Pang

The problem time Packet sizes, timing: → [probably generated by alice’s laptop] → [probably keystrokes: ← [probably webpage: ← [probably watching video: Wonderland.DivX.avi] → [probably speaking: Spanish] ← [probably using a p2p application] Packet contents: → user login: alice → password: ← webpage: ← 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 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 VBR videos as fingerprints ≈ DFT

Previous solutions Information prevented from leaking all potential Application transparency none code modification opaque knowledge of traffic patterns 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 time Output transmissions 400  Input transmissions Masking rules: “output size independent of input size” Performance constraints: “minimize delay”

System overview  definition Masking rules Perf. constraints  output Output 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 1App 2App 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