srinivasan seshan (and many collaborators) carnegie mellon university 1

Post on 19-Dec-2015

230 Views

Category:

Documents

3 Downloads

Preview:

Click to see full reader

TRANSCRIPT

1

Improving the Privacy ofWireless Protocols

Srinivasan Seshan (and many collaborators)Carnegie Mellon University

tcpdump

Protocol Control InfoProtocol Header

Protocol Header Buddy list: Alice, Bob, …

Protocol Control InfoProtocol Header

Protocol Header Blood pressure: high

Protocol Header Home location=(47.28,…

2

PrivatePhoto1.jpgLink Layer Header

Link Layer Header Buddy list: Alice, Bob, …

PrivateVideo1.aviLink Layer Header

Link Layer Header Blood pressure: high

Link Layer Header Home location=(47.28,…Protocol Header Home location=(47.28,…

Protocol Control InfoProtocol Header

Protocol Header Buddy list: Alice, Bob, …

Protocol Control InfoProtocol Header

Protocol Header Blood pressure: high

3

Protocol Header

Protocol Header

Protocol Header

Protocol Header

Protocol Header

Protocol Control Info

Protocol Control Infotcpdump

4

What can Protocol Control Info Reveal?

To speed association, done via SSIDs Sample data below from SIGCOMM 2004

Home

Cross-index with location databases (Wigle) for geographic information.

Set of SSIDs helps to identify user in terms of networks and places they’ve been

5

What can Protocol Control Info Reveal?

00:16:4E:11:22:33

www.bluetoothtracking.org

Location traces can be deanonymized[Beresford 03, Hoh 05-07, Krum 07]

Kim’s House

6

Who Might be Tracking You?

7

Outline

Quantifying the tracking threat

Building identifier-free protocols

Private crowd-sourcing

8

Name: Bob’s DeviceSecret: Alice<3Bob

DiscoverFrom: 11:22:33:44:55:66To: BROADCAST Search probe

From: 11:22:33:44:55:66To: BROADCAST Announcement

Name: Alice’s DeviceSecret: Alice<3Bob

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF Credentials, key exchange

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66 Credentials, key exchange

Authenticateand Bind

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66

Send Data

Bootstrap

Out-of-band (e.g., password, PIN)

• Confidentiality• Authenticity• Integrity

Best Security Practices Today

KsessionUse to encrypt& authenticate

9

Identifiers

A well known technical problem Devices have unique and consistent addresses e.g., 802.11 devices have MAC addresses fingerprinting them is trivial!

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

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

Adversarytcpdump tcpdump

time

10

Identifiers

The widely proposed technical solution Pseudonyms: Change addresses over time

802.11: Gruteser ’05, Hu ’06, Jiang ’07 Bluetooth: Stajano ’05 RFID: Juels ‘04 GSM: already employed

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

MAC address later:00:AA:BB:CC:DD:EE

tcpdump tcpdump

?

time

11

IdentifiersOur work shows: Pseudonyms + WPA are not

enough Implicit identifiers: identifying characteristics of traffic E.g., most users identified with 90% accuracy in hotspots

00:0E:35:CE:1F:59 00:AA:BB:CC:DD:EE

tcpdump tcpdump

Search: “Bob’s Home Net”Packets Intel Email Server…

Search: “Bob’s Home Net”Packets Intel Email Server…

time

12

Implicit Identifiers by Example

Consider one user at SIGCOMM 2004 Seen in an “anonymized” wireless trace

(device addresses hashed, effectively a temporary address) Transferred 512MB via BitTorrent on a congested 802.11 network

(Poor network etiquette?)Can we still identify the culprit?

?00:0E:35:CE:1F:59

00:0E:35:CE:1F:59

00:0E:35:CE:1F:59

bittorrent transfer

?

13

Tracking Example

Fingerprint: network names in probes

?

User of “roofnet”community network at MIT

Wardriving Database

Probe: “roofnet”00:0E:35:CE:1F:59

14

DiscoverFrom: 11:22:33:44:55:66To: BROADCAST Search probe

From: 11:22:33:44:55:66To: BROADCAST Announcement

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF Credentials, key exchange

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66 Credentials, key exchange

Authenticateand Bind

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66

Send Data

Bootstrap

Problem: Long-term Linkability

Name: Alice’s LaptopSecret: Alice<3Bob

Name: Bob’s NetworkSecret: Alice<3Bob

Is Bob’s Network here?

Bob’s Network is here

Identifiersneeded forrendezvous!

Proof that I’m Alice

Proof that I’m Bob

Identifiersneeded forauthentication!

15

Implicit Identifiers by Example

Implicit identifier: SSIDs in probes Set of SSIDs in 802.11 probe requests Many 802.11 drivers search for preferred networks Usually networks you have associated with before

00:0E:35:CE:1F:59

SSID Probe:“roofnet”

tcpdump

Bittorrenttransfer

00:AA:BB:CC:DD:EE

?tcpdump

time

16

Tracking Example

Fingerprint: IP broadcast packet sizes Set of broadcast packet sizes in network traffic e.g., advertisements by Apple Bonjour, iTunes, NetBIOS

?

time

11:11:22:33:44:55

11:11:22:33:44:55

11:11:22:33:44:55 239 bytes

245 bytes

257 bytes00:0E:35:CE:1F:59

00:0E:35:CE:1F:59

00:0E:35:CE:1F:59 239 bytes

245 bytes

257 bytes

17

From: 12:34:56:78:90:abTo: 11:22:33:44:55:66

From: 12:34:56:78:90:abTo: 11:22:33:44:55:66

From: 12:34:56:78:90:abTo: 11:22:33:44:55:66

From: 12:34:56:78:90:abTo: 11:22:33:44:55:66

From: 00:00:99:99:11:11To: 11:22:33:44:55:66

From: 00:00:99:99:11:11To: 11:22:33:44:55:66

From: 00:00:99:99:11:11To: 11:22:33:44:55:66

250 bytes

500 bytes

500 bytes

250 bytes

250 bytes

200 bytes

200 bytes

Data packets in the same session remain linked;in aggregate, these can be fingerprints

Problem: Short-term Linkability

Source Address

Decryption key

12:34:56:78:90:ab KAlice

00:00:99:99:11:11 KCharlie

From: 00:00:99:99:11:11To: 22:33:AA:BB:CC:DD

From: 00:00:99:99:11:11To: 22:33:AA:BB:CC:DD

From: 00:00:99:99:11:11To: 22:33:AA:BB:CC:DD

11:22:33:44:55:66

22:33:AA:BB:CC:DD

18

DiscoverFrom: 11:22:33:44:55:66To: BROADCAST Search probe

From: 11:22:33:44:55:66To: BROADCAST Announcement

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF Credentials, key exchange

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66 Credentials, key exchange

Authenticateand Bind

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66

Send Data

Bootstrap

Problem: Short-term Linkability

Name: Alice’s LaptopSecret: Alice<3Bob

Name: Bob’s NetworkSecret: Alice<3Bob

Is Bob’s Network here?

Bob’s Network is here

Proof that I’m Alice

Proof that I’m Bob

Identifiersneeded forpacket filtering!

250 bytes

500 bytes

19

Fingerprint Accuracy

Developed an automated identification algorithm Based on Naïve Bayes classifier Fingerprints:

network names broadcast packet sizes supported capabilities

Simulated user tracking with traffic from 500+ users Assume encryption and device

address changes each hour

Question: Given some traffic samples from a device, can we identify when it is present in the future?

Was Alice here?

Known to befrom Alice

20

Fingerprint Accuracy

Results: 53% of devices can be identified with

90% accuracy when at a small hotspot for the day (5 devices/hour)

27% with 99% accuracy 17% even if in a very busy hotspot (100

users/hour)

More fingerprints exist this is only a lower bound!

Question: Given some traffic samples from a device, can we identify when it is present in the future?

Was Alice here?

Known to befrom Alice

21

DiscoverFrom: 11:22:33:44:55:66To: BROADCAST Search probe

From: 11:22:33:44:55:66To: BROADCAST Announcement

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF Credentials, key exchange

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66 Credentials, key exchange

Authenticateand Bind

From: 11:22:33:44:55:66To: AA:BB:CC:DD:EE:FF

From: AA:BB:CC:DD:EE:FFTo: 11:22:33:44:55:66

Send Data

Bootstrap

Is There a Common Defense?

Name: Alice’s LaptopSecret: Alice<3Bob

Name: Bob’s NetworkSecret: Alice<3Bob

Is Bob’s Network here?

Bob’s Network is here

Proof that I’m Alice

Proof that I’m Bob

Problem:Long-termLinkability

Problem:Short-termLinkability

22

Discover

Authenticateand Bind

Send Data

Goal: Make All Bits Appear Random

Bootstrap

Name: Alice’s LaptopSecret: Alice<3Bob

Name: Bob’s NetworkSecret: Alice<3Bob

No bitslinkable overthe long-term

Many streamsoverlap in real traffic much nosierside-channels

23

Discover

Authenticateand Bind

Send Data

Goal: Make All Bits Appear Random

Bootstrap

Identifiersneeded forrendezvous!

Identifiersneeded forauthentication!

Identifiersneeded forpacket filtering!

Name: Alice’s LaptopSecret: Alice<3Bob

Name: Bob’s NetworkSecret: Alice<3Bob

24

Outline

Quantifying the tracking threat

Building identifier-free protocols

Private crowd-sourcing

25

Design Requirements

When A generates Message to B, she sends: F(A, B, Message) → PrivateMessage

where F has these properties:– Confidentiality: Only A and B can determine Message.– Authenticity: B can verify A created PrivateMessage.– Integrity: B can verify Message not modified.

– Unlinkability: Only A and B can link PrivateMessagesto same sender or receiver.

– Efficiency: B can process PrivateMessages as fast as he can receive them.

A→B Header… Unencrypted payload

26

Solution Summary

Unlinkabilit

y

Integrity

Authenticit

y

Efficie

ncy

Confidentiality

Today’s protocols(e.g., 802.11 WPA)

Public KeySymmetric Key

SlyFi: Discovery/Binding

SlyFi: Data packets

OnlyData

Payload

OnlyData

Payload

OnlyData

PayloadOnlyData

Payload

OnlyData

Payload

OnlyData

Payload

Finger-prints

remain

Temporary addresses(e.g., [Gruteser 05, Jiang 07])

27

Straw man: Encrypt Everything

Idea: Use bootstrapped keys to encrypt everything

Name: Bob’s NetworkSecret: Alice<3Bob

Name: Alice’s LaptopSecret: Alice<3Bob

Bootstrap

KAB

KBA

derive keys- Key for Alice→Bob

- Key for Bob→Alice

28

Straw man: Symmetric Key Protocol

Probe “Bob”

Client Service

Symmetric encryption(e.g., AES w/ random IV)

Check MAC:

MAC: KAB

KAB

KAB

KShared1

KShared2

KShared3…

O(M)

Probe “Lucy”

KSharedM

Try to decrypt with each key (accounts + associations)

29

Straw man: Symmetric Key Protocol

Probe “Bob”

Client Service

Symmetric encryption(e.g., AES w/ random IV)

Check MAC:

MAC: KAB

KAB

KAB

KShared1

KShared2

KShared3…

1.5 ms/packet (M=100)

KSharedM

One key per sender (accounts + associations)

Too slow!(APs have 100s of accounts)

(Need < 200 μs/packet for 802.11g)

30

Straw man: Public Key Protocol

Probe “Bob”

Key-private encryption(e.g., ElGamal)

KBob

Check signature:

Try to decrypt

K-1Bob

KAlice

Based on [Abadi ’04]

K-1AliceSign: Too slow in practice!

Client Service

O(1)~100 ms/packet

31

Solution Summary

Unlinkabilit

y

Integrity

Authenticit

y

Efficie

ncy

Confidentiality

Public Key ProtocolSymmetric Key Protocol

SlyFi: Discovery/Binding

SlyFi: Data packets

OnlyData

Payload

OnlyData

Payload

OnlyData

PayloadOnlyData

Payload

OnlyData

Payload

OnlyData

Payload

Finger-prints

remainTemporary addresses

Today’s protocols

32

Symmetric key almost works, but tension between: Unlinkability: can’t expose the identity of the key Efficiency: need to identify the key to avoid trying all keys

Idea: Identify the key in an unlinkable way

Approach: Sender A and receiver B agree on tokens: T1 , T2 , T3 , … A attaches Ti to encrypted packet for B

SlyFi

AB

AB

AB AB

33

150 μs/packet(software)

SlyFi

Probe “Bob”

Client Service

Symmetric encryption(e.g., AES w/ random IV)

Check MAC:

MAC: KAB

KAB

KAB

KAB

Lookup Ti in hash table to get KAB

Ti AB

AB

Required properties:– Third parties can not link Ti and Tj if i ≠ j– A doesn’t reuse Ti

– A and B can compute Ti independently

AB AB

AB

AB

Ti = AES(KAB, i)ABTi = AES(KAB, i)AB

Main challenge:Sender and receiver must synchronize i

34

Data messages: Only sent over established connections Expect messages to be delivered i = transmission number

• On receipt of Ti , B computes next expected: Ti+1

• Handling message loss?– On receipt of Ti save Ti+1, … , Ti+k in table– Tolerates k consecutive losses (k=50 is enough [Reis ‘06])– No loss compute one new token per reception

AB ABAB

AB AB

SlyFi: Data Transport

T1 AB

T 2AB

T 3AB

T 4AB

i = 1234 i = 1234

hashtable

T 3 T 3+kAB AB…

• On receipt of Ti , B computes next expected: Ti+1AB AB

T 3AB T 2ABT 1ABT 4AB

• On receipt of Ti , B computes next expected: Ti+1

• Handling message loss?

35

SlyFi: Discovery/Binding

Discovery & binding messages: Often sent when other party is not present Can’t rely on transmission reception to synchronize i

i = ?

Probe: “Bob’s Device”T2 AB

Probe: “Bob’s Device”Ti AB

...

Not here.

Not here.

Probe: “Bob’s Device”T1 AB

36

SlyFi: Discovery/Binding

i = i =

Probe: “Bob’s Device”Ti AB

• Discovery & binding messages:– Infrequent: only sent when trying to associate– Narrow interface: single application, few side-channels Only require long-term unlinkability to prevent tracking i = current time/1 min

• Handling clock skew:– Receiver B saves Ti-c, … , Ti+c in table– Tolerates clock skew of c minutes– Steady state: compute one new token per minute

ABAB

T i-c T i+cAB AB…

hashtable

T iAB

37

from, to, seqno, …

from, to, seqno, …

Credentials, key exchange

Credentials, key exchange

from, to, capabilities, other protocol fields

from, to, capabilities, other protocol fields

Bob’s Network is herefrom, to, capabilities, other protocol fields

Is Bob’s Network here?from, to, capabilities, other protocol fields

Enc(KAB , t0 , …)MAC(KAB , …)

session1

session2

AB

Enc(KAB ,nonce, …)MAC(KAB , …)

encrypt

authDiscover

Authenticateand Bind

Send Data

Name: Bob’s NetworkSecret: Alice<3Bob

Name: Alice’s LaptopSecret: Alice<3Bob

Bootstrap

SlyFi: Putting it Together

t0

t0 BA

AB

ABTi = AES(KAB , i)token

ABti = AES(KBA , i)session1

KABtoken KABencrypt KABauth

KBAtoken KBAencrypt KBAauthderive keys

nonce

Ti BA nonce

Ti AB

Ti nonce

Ti BA nonce

AB Ksession1,2

38

Solution Summary

Unlinkabilit

y

Integrity

Authenticit

y

Efficie

ncy

Confidentiality

Public KeySymmetric Key

SlyFi: Discovery/Binding

SlyFi: Data packets

LongTerm

OnlyData

Payload

OnlyData

Payload

OnlyData

PayloadOnlyData

Payload

OnlyData

Payload

OnlyData

Payload

Finger-prints

remainTemporary addresses

Today’s protocols

39

Outline

Quantifying the tracking threat

Building identifier-free protocols

Private crowd-sourcing

40

Problem: Commercial AP Selection

tmobile

attwifi (ap 1)

attwifi (ap 2)

seattlewifi

linksys

Free Public Wifi

$3.99

$9.99

Free!

Free!

Which networks will run my applications?

Which ones have good performance?

Quality = ???

We often have many choices of wireless access points (APs), but little information about each

Jiwire.comHotspot database

41

Goal: Provide More Information

tmobile

attwifi (ap 1)

attwifi (ap 2)

seattlewifi

linksys

Free Public Wifi

I need to use VoIP so this is the best network for me

Bandwidth: 300 kbpsBlocked ports: None

Bandwidth: 100 kbpsBlocked ports: None

Bandwidth: 300 kbpsBlocked ports: None

Doesn’t work!

Doesn’t work!

Bandwidth: 100 kbpsBlocked ports: Email, Skype

Bandwidth: 300 kbpsBlocked ports: None

Doesn’t work!

Provide information about AP performance and application support

Doesn’t work!

Doesn’t work!

Bandwidth: 100 kbpsBlocked ports: None

Bandwidth: 300 kbpsBlocked ports: None

Bandwidth: 300 kbpsBlocked ports: None

ImprovedHotspot database

Bandwidth: 30 kbpsBlocked ports: Email

Bandwidth: 5 MbpsBlocked ports: None

Doesn’t work!

42

Goal: Wifi-Reports

Users automatically report on APs that they use

43

Bob’s Report on AP2Doesn’t work!

Bob’s Report on AP1Doesn’t work!

Bob’s Report on AP3Doesn’t work!

Bob’s Report on AP4Doesn’t work!

Bob’s Report on AP5Bandwidth: 300 kbps

• Location Privacy: Authority/databases cannot link a user’s reports• Limited Influence: Only count 1 report per AP, per user

Mallory’s Report on AP4Bandwidth: 10 MbpsMallory’s Report on AP4

Bandwidth: 10 MbpsMallory’s Report on AP4Bandwidth: 10 MbpsMallory’s Report on AP4

Bandwidth: 10 MbpsMallory’s Report on AP4Bandwidth: 100 Mbps

Design Challenges

• Location Context: Account for wireless channel conditions

44

• Location Privacy: Authority/databases cannot link a user’s reports• Limited Influence: Only count 1 report per AP, per user

Mallory’s Report on AP4Bandwidth: 10 MbpsMallory’s Report on AP4

Bandwidth: 10 MbpsMallory’s Report on AP4Bandwidth: 10 MbpsMallory’s Report on AP4

Bandwidth: 10 MbpsMallory’s Report on AP4Bandwidth: 100 Mbps

Design Requirements

• Location Context: Account for wireless channel conditions

45

If Alice has already submitteda report on cafe1 then abort,else save the report

Straw men Protocols

R report on cafe1

mix network

submit: R

authenticate Alice

measure cafe1

AnonymousReport on cafe1Bandwidth: 5 Mb

AnonymousReport on cafe1Bandwidth: 100 Mb

AnonymousReport on cafe1Bandwidth: 100 Mb

AnonymousReport on cafe1Bandwidth: 100 Mb

AnonymousReport on cafe1Bandwidth: 100 Mb

AnonymousReport on cafe1Bandwidth: 100 Mb

Limited Influence

submit: R

AnonymousReport on cafe1Bandwidth: 5 Mb

Alice’s locations:

cafe1tmobile #3Bob’s NetworkAlcohol Anon NetCMU…

Location Privacy

46

Report Protocol

request: cafe1, Tblind

reply: Sblind

{kcafe1, k-1cafe1} new key pair

If Alice requested cafe1 beforethen abortelse sign the token Sblind

authenticate anddownload list of APs

Unblind the signature Scafe1

R report on cafe1mix network

submit:cafe1, Scafe1, kcafe1, R, SR Verify the signatures

Delete old reports signed with kcafe1

measure cafe1

cafe1cafesolsticetmobile #4AT&T #54

Report on cafe1Bandwidth: 5 MbpsReport on cafe1Bandwidth: 5 Mbps

Blind the token kcafe1 Tblind

Sign the report SR

List of all APs

cafe

1

star

buck

s2ca

fe2

{kcafe2, k-1cafe2} new key pair

47

request: cafe1, Tblind

reply: Sblind

authenticate anddownload list of APs

measure cafe1Report on cafe1Bandwidth: 5 Mbps

Problem: Asking for a token reveals the target APSolution: Ask for the tokens for all APs in a city

Report on cafe1Bandwidth: 5 MbpsReport on cafe1Bandwidth: 100 Mb

Problem: Some users may submit bad reportsSolution: Robust summary functions (e.g., median)

mix network

submit:cafe1, Scafe1, kcafe1, R, SR

cafe

1

star

buck

s2 U

Wtu

llys

shin

kate

a

cafe

2

APs in Seattle

Report Protocol

48

Summary

Slyfi How to build a WiFi replacement that reveals no transmitted bits to

eavesdroppers Key challenge: ensuring efficient processing by both clients and Aps

Wifi-Reports How to build a crowdsourcing application that preserves privacy Key challenge: preventing malicious reports

Other relevant designs Geo-fencing – limiting wireless network coverage to well-defined

regions

50

Geo-fencing

Build on the “virtual walls” model of wireless for privacy [Kapadia’07]: goal is to approximately confine connectivity with “virtual walls” E.g., to an apartment, conference room, office

Prevents information reception outside intended service area for improved privacy and security

May be able to improve coverage within service area and reduce interference across service areas

51

Geo-fencingUse steerable directional antennas to focus signals on a

specified region

Stripe data across antennas to provide coverage only in the region

Code the packetstransmitted bythe antennas to prevent partial information retrieval

52

Geo-fencing Results

Indoor multipath reflections significantly distort antenna radiation pattern

Need periodic tuning of the antenna directions to track changes in environment

Coverage confined tosingle location

top related