identity theft protection in structured overlays

21
Identity Theft Protection in Structured Overlays Lakshmi Ganesh Ben Y. Zhao University of California, Santa Barbara NPSec 2005

Upload: orpah

Post on 18-Jan-2016

27 views

Category:

Documents


0 download

DESCRIPTION

Identity Theft Protection in Structured Overlays. Lakshmi Ganesh Ben Y. Zhao University of California, Santa Barbara NPSec 2005. 0353. 7171. key based routing (KBR). 1024. 6576. 1456. 5771. 5701. 2380. 5002. 3202. 4377. Background: Structured Overlays. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Identity Theft Protection in Structured Overlays

Identity Theft Protection in Structured Overlays

Lakshmi GaneshBen Y. ZhaoUniversity of California, Santa Barbara

NPSec 2005

Page 2: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 2

6557

2380

5770

Background: Structured Overlays

• network abstraction – IDs, not IPs

• app level entities assigned keys from same namespace as IDs

• keys mapped to nodes (IDs)

• many applications – eg, dist. db

• Alice wants to store her files

• key(file) = hash(meta info)

• root(file) = ID closest to key(file)

1024

5002

5771

5701

1456

2380

32024377

03537171

6576

Alice

file3

file2

file1

key based routing (KBR)

Page 3: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 3

The Identity Attack

• Structured overlays rely on Key-based Routing– Nodes maintain limited state

• Route messages by forwarding progressively closer to destination

• Routing stops when a node claims it is the closest to the key

– Relies on KBR for setting up connections between application nodes

• Identity Attacks hijacks key node mappings– A hijacker would (falsely) claim that it is the closest node to

the given key.

– Hijack responsibility for storing / retrieving data, forwarding data, or any other application level responsibility

Page 4: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 4

Identity Theft: Illustration

• Eg: Network with namespace length = 4 and base = 8

Source: BobLooking for 5770

Actual root

Hijacker: Carl!

No node is closer to 5770 than I am! So here’s the file you

requested..

1024

5002

5771

5701

5770

Bad!

5770 could be Alice’s employee records

‘Bad’ could be criminal records!

Page 5: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 5

Structured Peer-to-Peer Security

• Sybil Attack – Relies on: nodeIDs are free

– Obtain large number of nodeIDs

– Resulting virtual identities can collude as a group

– Defense: centralized Certificate Authority

• Eclipse Attack– Relies on: routing table optimization for performance

– Leverage Sybil, then fill victim’s routing table with colluders

• Now what…– Sybil or Eclipse get you close to the victim, now what?

– DoS easily detected, Identity Attack more powerful

– Can also perform Identity attack independently w/ single node, hence more general than Sybil or Eclipse

Page 6: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 6

Outline

• What we’ve covered– Background

• Structured Overlays

• Attacks– Identity, Sybil, Eclipse

– Preventing Identity attacks will disempower Sybil, Eclipse attacks

• Now we’ll see– How to detect Identity Attacks

– Analysis of our solution

Page 7: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 7

How to detect Identity Attacks

• First we get suspicious, then we seek proof

• Step 1: Figure out when some responder is suspicious– How far must the responder’s ID be from the key to warrant

suspicion?

• Step 2: So now you’re suspicious: how to verify?– Ask others? But how do they know?

• Certification!

• Based on its ID, each node picks some nodes to certify itself with

• You can now ask these ‘proof managers’

Page 8: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 8

He says he’s the closest I can get to Cairo (Liar!)

Geographical Analogy: Intuition for Step 1

meppl I knowI know 2 ppl in my countryI know 1 person from each continentI want to route to Cairo, Egypt (Africa)I contact the guy I know in Africa (Nigeria)

I look at my address book: there are 3 ppl in my country – isn’t there even one in Egypt?? I’m unconvinced!

Page 9: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 9

Step 1: How it looks for Bob

0353 1024 1001 1020

1024 1177 10 102

2380 1254 1024 102

3202 1300 10 102

4377 1456 1044 1024

5002 1570 1051 102

6576 1606 10 1026

7171 1711 10 102

Node 1024’s Routing Table1024

5002

5771

5701

Bob examines his routing table

His assumption: node density in the key’sneighborhood ~ node density in hisneighborhood

He sees up to 3 nodesin the 102x range

Is it likely that there isn’t even one node in the 577x range? NO!

How many nodes in XXXX range?How many nodes in 1XXX range?How many nodes in 10XX range?How many nodes in 102X range?

Page 10: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 10

Step 2: Proof Certificates

• Ok, we’re suspicious.. Now what?

• Intuition: – Each node ‘tells’ a set of other nodes about its existence

• Periodic certification (signed, time-stamped certificates)

– These ‘proof managers’ can now be contacted for proofs

– You verify the neighborhood you are in• 5770 verifies 57xx and 577x (for example)

– Proof manager (PM) set computed based on prefix certified• PMs for 57xx = {hash(57,1), hash(57,2), hash(57,3)}

• PMs for 577x = {hash(577,1), hash(577,2), hash(577,3)}

– Bob would now ask hash(577,x) for proofs

• Scalable– You don’t verify every possible neighborhood

• You don’t need to

Page 11: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 11

Verification

• Clients requesting verification– Estimate several prefixes of key that “should” exist

– E.g., key = 5770• Test prefixes 577x, then 57x

– For each prefix• Calculate location of proof managers by hashing prefix

• Issue request to proof managers for certificates

– If certificates exist• Proof of attack

Page 12: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 12

Tying it all together: Illustration

Hash(577,1)

Hash(577,2)

Hash(577,3)

1. Certification (of 577x, say) 2. Routing 3. Verification

Attempted Identity Theft caught!

Really?

Source: Bob Looking for 5770

Actual root

Carl: Hijacker!

No node is closer to 5770 than I am!

1024

5002

5771

5701

Page 13: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 13

System Analysis: Performance

Effectiveness of the verification system under ideal conditions (no denials, no certificate hijacks, no node churn).

Page 14: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 14

System Analysis: Factors

• Message Hijacks– The Identity attack

• Certificate Hijacks – Malicious node on path between node and its proof manager

• Verification Denials– Malicious proof manager

• Node churn – Nodes come and go

Page 15: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 15

System Analysis: Performance

Use of replication factor to increase verification effectiveness (certificate denials, hijacks, and node churn assuming 20% malicious nodes).

Page 16: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 16

System Analysis: Overhead

• Verification Overhead– Bandwidth: certs sent per node per second

P*RF/T (=3*4/500 = 0.024 certs/sec ~ 1.25 bytes/sec)

– Storage: certs stored per node

P*RF (=3*4 certs ~ 600 bytes)

where P = num PGs certified by each node

RF = replication factor,

T = certification interval (secs)

cert size ~ 50 bytes

• Small price to pay to keep Alice happy

Page 17: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 17

Looking ahead…

• Dynamic computation of prefixes to verify

• Load balancing among members of a prefix group

• Extension to other protocols– For protocols that do not use prefix routing

– Replace prefix groups with ‘range specifiers’Each specifier includes central point and range on each side

i.e. 123X range(1234.5, 4.5)

Page 18: Identity Theft Protection in Structured Overlays

Thank You!

Questions?

Page 19: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 19

Certification: Scalability

The probability of the cusp including more than 2 routing levels is

P ≤ b/eb, where b = base of the prefix digit. P < 0.07 for b = 4 and P < 1.8 ∗ 10−6 for b = 16.

Page 20: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 20

System Analysis: Performance

Use of replication factor to increase verification effectiveness (certificate denials, no hijacks, no node churn).

Page 21: Identity Theft Protection in Structured Overlays

Lakshmi Ganesh University of California, Santa Barbara 21

System Analysis: Performance

Use of replication factor to increase verification effectiveness (certificate denials and hijacks, no node churn).