ben greenstein, jeff pang, ramki gummadi, srini seshan, and david wetherall

38
Two reasons you can’t trust a wireless network (and some stuff that goes on at Intel Research Seattle) Jeff Hightower, Ali Rahimi, Ian Smith, Josh Smith, Matthai Philipose, Tanzeem Choudhury, Sunny Consolvo, Beverly Harrison, Anthony LaMarca Ben Greenstein, Jeff Pang, Ramki Gummadi, Srini Seshan, and David Wetherall

Upload: lise

Post on 30-Jan-2016

49 views

Category:

Documents


0 download

DESCRIPTION

Two reasons you can’t trust a wireless network (and some stuff that goes on at Intel Research Seattle). Ben Greenstein, Jeff Pang, Ramki Gummadi, Srini Seshan, and David Wetherall. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Two reasons you can’t trust a

wireless network

(and some stuff that goes on at Intel Research Seattle)

Jeff Hightower, Ali Rahimi, Ian Smith, Josh Smith, Matthai Philipose,

Tanzeem Choudhury, Sunny Consolvo, Beverly Harrison, Anthony LaMarca

Ben Greenstein, Jeff Pang, Ramki Gummadi, Srini Seshan, and David Wetherall

Page 2: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Intel Research Seattle (IRS) Lab focus is on computing

systems that work in everyday environments (ubiquitous computing)

Magic formula: Evaluate the need for a

technology Build neat hardware (EE) Apply magic statistics (ML) Provide user feedback (HCI)

+ Ben + Wetherall (NET/SYS) = new focus on mobile networking and systems

Page 3: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Magic Statistics:Sensor-based activity recognition Problem: it’s very hard to understand what

people are doing with vision Idea: instrument objects/people and use

machine learning on sensor data to recognize their activities For eldercare, fitness, social dynamics, …

Page 4: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Neat Hardware: Mobile Sensing Platform Platform Features

Built on iMote2 Linux OS 32M RAM 2GB flash storage ZigBee & Bluetooth radios 10 on-board sensors

3D Accelerometer, 2D Compass, Barometer, Humidity, Visible light, Infrared light, Temperature

UART, GPIO breakouts for additional sensors

~16 hour battery life

MSP body-worn version MSP sensor brick version

Page 5: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Neat Hardware:iBracelet – an RFID tag reader

activitiest= 5 min t= 2 min t= 30s

kettle stove faucet cup teabag milk sugar

0.4

0.2 0.3 0.6 0.2 0.4 0.4

Bracelet detects nearby tag Observation: What you use determines what you do

Page 6: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

User Feedback:Ubiquitous Fitness (UbiFit) Challenge: Use ubiquitous computing to

encourage people to sustain an increased level of physical activity

Approach:

+ + =

MSP for automatic activity detection & mobile phone for manual entry of activities

Phone to provide personal awareness whenever & wherever the user is

Page 7: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Other Projects:WiSPs: Smart RFID tags Problem: Rich sensor networks hit lifetime/size constraints

due to batteries Idea: Extend long-range RFID to provide sensor capabilities

Tags are passive, harvest power to compute/communicate Tags host sensors/actuators (acceleration, light, LEDs, flash) Custom analog circuit for power, communications

Page 8: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Other Projects: Software radio/RFID Build an EPC Gen2 RFID reader w/ USRP

Some hardware tweaks needed WiSPs let the tag side be changed already

No RFID systems work(?) and many issues to explore Particularly for a sensor network context Multi-access, energy, reliability, privacy, …

Page 9: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Other Projects: Personal Robotics Problem: robots mostly function in well

structured environments, e.g., factories Idea: use sensing/ML to enable robots to function

in less structured environments E-field gripper for manipulation WiSPs for localization 3D laser range finder vision

Page 10: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Other Projects: Ultra-mobile devices Problem: Desktop interaction don’t

work well for small, mobile devices Idea: looking at this now …

Pedestrian Navigator demo: Google Earth maps stay oriented to heading and 3D image stays level to the ground

iMote

MSB

An Inertial Board in the 3-board MSP stack

Page 11: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Other Projects: Trustworthy Wireless Problem: wireless lacks privacy and is

vulnerable to interference Idea: Randomize/encrypt

communications to exclude attacker

Client: Tag, MSP, phone, laptop …

Authorized server:AP, reader …

Third party(nearby)

eavesdrop interfere

XXXXXXXXXX

Page 12: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Trustworthy wireless topics Reason 1: Privacy threat

Jeff Pang (CMU) Reason 2: Vulnerability to interference

Page 13: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Location Privacy is Now at Risk

“The New You”

“The Adversary”

Your MAC address:00:0E:35:CE:1F:59

Usually < 100m

“The Old You”The problem

scales

Page 14: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

The Privacy Threat Posed by Wireless Communication is Real

David J. Wetherall

Anonymized 802.11 Traces from SIGCOMM 2004

Search on Wigle for “djw” in the Seattle area

Google pinpoints David’s home (to within 200 ft)

A pseudonym

Page 15: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Problem: Researchers propose using pseudonyms, but is this enough?

PeepResearch.org

“You”

“The Adversary”

Page 16: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Another Real Example: Some “Anonymous” Guy BitTorrents 0.5G of Data at a Conference in 2004

PeepResearch.org

“The Adversary”

IMAPServer

SSHServer

BroadcastPackets with

Sizes 239, 245, 257

ConsistentCard/Driver

Characteristics

SSID:Roofnet

“You”“A guy from MIT”

Page 17: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Identifying Features Network

Destinations Set of IP <address, port>

pairs in a traffic sample

SSIDs in Probe Requests Set of networks

advertised in a traffic sample

Broadcast Packet Sizes

Set of 802.11 broadcast packet sizes seen in a traffic sample

MAC Protocol Fields Header bits (e.g., power

mgmt., order) Supported rates Offered authentication

algorithms

Page 18: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Methodology

“The adversary”

Ethereal Label: MaryFeatures: SSIDs, etc.

Label: JohnFeatures: SSIDs, etc.

Label: BerthaFeatures: SSIDs, etc.

TRAINING

Features: SSIDs, etc.

Features: SSIDs, etc.Features: SSIDs, etc.

VALIDATION

Page 19: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Methodology Simulate using

SIGCOMM, USCD and Home traces Split trace into training

data and validation data

Sample = 1 hour of traffic to/from a user

Ignore MACs for the latter

presume pseudonyms

“The adversary”

Ethereal

Page 20: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Did This Traffic Sample Come from User U?

Distance Metric: Set similarity (Jaccard Index), weighted by frequency:

linksys IR_Guestdjw

SIGCOMM_1

PROFILE FROMTRAINING

SAMPLE FORVALIDATION

Rare

Common

Page 21: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Did This Traffic Sample Come from User U?

Naïve Bayesian Classifier:We say sample s (with features fi) is from user U if LHS > T

We vary T for different True Positive / False Positive Rates

=

Page 22: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Receiver Operating Characteristics (ROCs)

UCSD: 60% TPR with 1% FPR Perfect classifier would have

90% TPR for ~0% FPR

Higher FPR, likely due to not being user specific

Useful only in combination with other features, to rule out identities

sensi

tivit

y

1 - specificity

Page 23: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Combining features helps In public networks, samples from 1 in 4 users are

identified >50% of the time with 0.999 accuracy

bcast + ssids +fields + netdests

bcast + ssids +fields

bcast + ssids

Page 24: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Was User U Here at Time t? Maybe…

Over an 8 hour day, 8 opportunities to misclassify a user’s traffic

Instead, say user U is present if multiple samples are classified as being his

TPRtarget Pr [ X belief ]FPRtarget Pr [ Y belief ]

belief is number of samples you believe are from UX is binomial r. v. with params n = active and p = tprQ1

Y is binomial r. v. with params n = 8 and p 1-(1-fprQ1)N

Page 25: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

One 9 of Accuracy… In a busy coffee shop

with 25 concurrent users, more than half (54%) can be identified with 90% accuracy

4 sample median to detect

27% with two 9s.

Page 26: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Conclusion: Pseudonyms Are Insufficient 4 new identifiers: netdests, ssids, fields, bcast Average user emits highly distinguishing identifiers Adversary can combine features

Future Uncover more identifiers (timing, etc.) Build a usable 802.11 network (APs and clients) that

protects privacy Encrypted names/addresses Hidden resource discovery/binding Online verification of privacy Channel hopping to resist interference

Working out next steps now

Page 27: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Trustworthy wireless topics Reason 1: Privacy threat Reason 2: Vulnerability to interference

Ramki Gummadi (USC)

Page 28: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Communication in the ISM band is vulnerable to interference

Increasingly crowded Un-(under)-regulated

n2

Page 29: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Interference threats

SelfishMalicious

Page 30: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Problem Characterize how

802.11 operates with interference in practice

Improve design to better tolerate interference Unacceptable for a low

power or a narrow-band interferer to bring throughput to zero SNR (logscale)

Recep

tion

Rate

theory

pract

ice

Page 31: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

802.11 Implementation Vulnerabilities

Jam with 1s → SYNC on sender clock lost Emit burst at frame start → Gain set incorrectly

Even with weak interferer, b/c attenuated disproportionately Send premature start frame delimiter → packet misinterpreted Damage consecutive beacons → clients disassociate

MACPHY

TimingRecovery

Preamble Detector/Header CRC-16 Checker

AGC

Barker Correlator

DescramblerDemodulatorADC

6-bit samples

To RF Amplifiers

RF Signal

Receiver

Data(includes beacons)

= Vulnerabilities

Page 32: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Experimental Setup

Single active attacker Can vary power and

frequency Can output arbitrary

waveforms Unattenuated PRISM Attenuated PRISM 802.15.4

Wired Endpoint UDP/TCP traffic

between client/wired endpoint through AP

WirelessClient

E

AP

C

AccessPoint

I

802.11

Page 33: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Characterizing 802.11 Interference

How far (i.e., by changing power) can the attacker be and still be effective?

E.g., dynamic range selection interference How much does frequency separation

help?

Page 34: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Dynamic range selection On-off random patterns (5ms/1ms)

0.1

1

10

100

1000

10000

−∞ -20 -12 -2 0 8 12 15 20

Interferer Power (dBm)

Th

rou

gh

pu

t (k

bp

s)

0

100

200

300

400

500

600

700

800

900

Lat

ency

(m

icro

seco

nd

s)

Throughput under

PRISM

Latency under PRISM

Throughput under Zigbee

Latency under Zigbee

AGC:V > t, -30dB

Result:ADC over/underflow

Page 35: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Impact of frequency separation

0.1

1

10

100

1000

10000

−∞ -20 -12 0 8 12 15 20

Interferer Power (dBm)

Th

rou

gh

pu

t (k

bp

s)

5MHz Separation10MHz Separation

15MHz Separation

Same Channel

Page 36: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Rapid channel hopping With existing hw!

Dwell period is 10ms, switching latency is 250µs AP exchanges encrypted MD5 seed with clients AP and clients independently hop to the same

channel

Page 37: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Evaluation of channel hopping

0.1

1

10

100

1000

10000

0 5 10 15 20

PRISM Interferer Power (dBm)

Th

rou

gh

pu

t (k

bp

s)

CH, UDP Traffic

CH, TCP Traffic

No CH, UDP Traffic

Page 38: Ben Greenstein, Jeff Pang, Ramki Gummadi,  Srini Seshan, and David Wetherall

Conclusions Selfish and malicious interferers cause

substantial degradation in commodity NICs Even weak and narrow-band interferers are

effective

Changing 802.11 parameters does not mitigate interference, but rapid channel hopping can