1 / 13

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

Toward a Framework for Preventing Side-Channel Attacks in Wireless Networks. Jeff Pang. WPA/VPN/SSHTunnel. The problem. http…ali…@bb!t. divx…data…bcd. Packet sizes, timing :. Packet contents:. time. time. → [probably generated by alice ’s laptop]

beck
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. WPA/VPN/SSHTunnel The problem http…ali…@bb!t divx…data…bcd Packet sizes, timing: Packet contents: time time → [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] → 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

  3. 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]

  4. Problem 1: packet size 100 Example: Broadcast packet sizes used as a fingerprint 250 • 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 500 300 200 120 Broadcast transmission sizes Broadcast transmission sizes time time

  5. Problem 2: packet timing • Inter-packet spacing reveals: • Keystrokes: 50x faster password cracking time • Countermeasures: • [near] constant bit rate cover traffic

  6. Problem 3: size evolution over time DFT • 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 ≈

  7. Previous solutions code modification Language-based information flow security [Volpano ’96, Agat ’00, Meyers ‘99] Proposal: Framework to implement select countermeasures • Enable overhead / privacy protection trade-off • Similar to signature-based anti-virus and IDS Application transparency knowledge of traffic patterns Specific attack countermeasures [Timmerman ’99, Smart ‘00] Trace-based cover traffic [Newman-Wolfe ‘92, Guan ‘01] Status quo Naïve cover traffic opaque overhead none all potential Information prevented from leaking

  8. Part I: Rule-based masking • Example: masking packet sizes •  100 400 250 400 300 400 200 400 120 400  Input transmissions Output transmissions time time Input transmissions • Masking rules: “output size independent of input size” • Performance constraints: “minimize delay”

  9. System overview • definitionMasking rulesPerf. constraints •  outputOutput traffic profile

  10. 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”

  11. Design questions App 1 App 2 App 3 • 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     network

  12. 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 learner learner home masking rules airport masking rules starbucks masking rules input traffic profiles input traffic profiles input traffic profiles

  13. 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

More Related