TAP: A Novel Tunneling Approach for Anonymity in Structured P2P Systems

Yingwu Zhu and Yiming Hu

University of Cincinnati

Outline

• Motivation and Preliminaries

• Design of TAP

• Evaluation

• Conclusions

• Future Work

Static Mixes-based Anonymous Systems

• Use a small, fixed core set of mixes to form an anonymous tunnel (e.g, anonymous remailer, onion routing)

• Limitations– Corrupt entry mixes reveal traffic source– Colluding entry and exit mixes reveal traffic source and

destination– Difficult to counter traffic analysis attacks (e.g., cover

traffic is expensive and hurts performance)– Capacity problem (small # of mixes and potentially large

# of users)– Law enforcement could be a hurdle for deployment

P2P-based Anonymous Systems

• An anonymous tunnel is formed by a randomly chosen set of P2P nodes (e.g., Crowds, Tarzan)– Each peer node is a potential mix

• Overcome the limitations of static mixes-based anonymous systems

• Drawback– A functionality problem: anonymous tunnels are

unstable due to node joins and departures in P2P systems

Why TAP?

• P2P based anonymous systems pose a functionality problem for tunnels due to dynamism of P2P systems

• TAP– A P2P based system, fault-tolerant to node failures– Avoids the functionality problem while providing

anonymity– Supports applications in the face of node failures

• Long-standing remote login sessions• Anonymous email systems, etc.

Design of TAP

• Goal: to strike a balance point between functionality and anonymity in dynamic P2P systems

• Two infrastructures TAP relies on:– P2P (secure) routing infrastructure (a message

could be securely routed to a destination node in the case that a fraction of nodes are malicious)

– P2P replication mechanism (k replicas for each data item are stored on k different nodes)

Design of TAP

• Basic idea– Decouple anonymous tunnels from fixed nodes – A tunnel is formed by a sequence of tunnel

hops, each of which is specified by a hopId (hop identifier) instead of IP address

• A tunnel hop is an abstract for a hop node (whose nodeId is numerically closest to its hopId), a tunnel therefore is fault-tolerant to hop node failures by relying on P2P replication mechanism

– Use a mix-style layered encryption

D

<h1, k1, H(PW1)>

P1

<h3, k3, H(PW3)>

P3

<h3, k3, H(PW3)>

P2

I

<h1, k1, H(PW1)><h2, k2, H(PW2)><h3, k3, H(PW3)>

h1,{h2,{h3,{D,m}k3}k2}k1

{h2,{h3,{D,m}k3}k2}k1

{h3,{D,m}k3}k2

{D,m}k3

m

TAP’s tunneling mechanism

I: initiator node

D: destination node

Pi: tunnel hop node, whose nodeId is numerically closest to hopId hi

{M}K: encryption of message M withsymmetric key K

Tunnel hop anchor

Tunnel Hop Anchor (THA)

• A tunnel hop is “anchored” in the system through THA

• In the form of <hopId, K, H(PW)>– hopId: hop identifier, acts as a DHT key for

THA’s storage and retrieval– K: symmetric key for encryption/decryption– H(PW): hash of a password PW, to secure the

THA– Stored on k nodes whose nodeIds are

numerically closest to hopId (P2P replication)

TAP’s Tunnel

• Step1: generate a set of THAs– THAs are node-specific, avoiding colliding with other

nodes’ THAs– But do not reveal the node’s identity

• Step2: anonymously deploy the generated THAs– Use a bootstrapping anonymous tunnel

• Step3: form a tunnel using the deployed THAs– Select a sequence of deployed THAs – Selected THAs should be scattered in the identifier

space as far as possible

• Step4: send messages through the formed tunnel to achieve anonymity

Anonymous File Retrieval

• An initiator node I wants to anonymously retrieve a file f with fid as its fileId (file identifier)– Create a forward tunnel Tf consist of 3 hops with hopIds

of h1, h2, and h3 respectively– Create a reply tunnel Tr consist of 3 hops with hopIds of

h4, h5, and h6, Tr={h4,{h5,{h6,{bid,fakeOnion}k6}k5}k4}, where bid is an identifier falling into I’s responsible region

– Create a message M={h1,{h2,{h3,{fid,K’,Tr}k3}k2}k1}, where K’ is a temporary public key

– Send out M through Tf

Anonymous File Retrieval

• The destination node D which is responsible for the file f– Encrypt f with a symmetric key k: {f}k

– Encrypt k with K’: {k}K’

– Send out {f}k + {k}K’ through the reply tunnel Tr

• The Initiator I– Receive the message {f}k + {k}K’ from the reply

tunnel Tr

– Decrypt the file f

Tunnel Performance Enhancement

• Consider a message M which routes through a tunnel of 3 hops with hopIds of h1, h2 and h3: M ={h1,{h2,{h3,{D,m}k3}k2}k1}– Each tunnel hop involves logN hops (N is the

number of nodes in the system) due to P2P routing algorithm

• Enhancement: embedding IP address of tunnel hop nodes into M– M ={h1,IP1,{h2,IP2,{h3,IP3,{D,m}k3}k2}k1}

Evaluation

• Fault-tolerant to node failures

• Impact of colluding malicious nodes

• Impact of P2P system dynamism

• Tunneling performance

Fault-tolerant to Node Failures

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0.01 0.025 0.05 0.1 0.15 0.2 0.25 0.3

Failed nodes (fraction)

Fai

led

tu

nn

els

(fra

ctio

n)

current tunneling

TAP (k=3)

TAP (k=5)

For a 10,000 node P2P system with 5,000 tunnels (each tunnel’s length is 5):(1) TAP’s tunnels are more fault-tolerant to node failures than current tunneling techniques;(2) A higher replication factor k makes TAP’s tunnels more fault-tolerant to node failures

Colluding Malicious Nodes

0

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.01 0.025 0.05 0.1 0.15 0.2 0.25 0.3

Malicious nodes (fraction)

Co

rru

pte

d t

un

nel

s (f

ract

ion

)

For a 10,000 node P2P system with 5,000 tunnels (each tunnel’s length is 5 and the replication factor k is 3):(1) There is no significant corrupted tunnels even when the fraction of malicious nodes is large (=0.3)(2) The fraction of corrupted tunnels increases as the replication factor k increases (not shown here)(3) The fraction of corrupted tunnels decreases with the increasing tunnel length (not shown here)

Impact of P2P Dynamism

0

0.0002

0.0004

0.0006

0.0008

0.001

0.0012

0.0014

0.0016

0.0018

0.002

0 2 4 6 8 10 12 14 16 18 20Time

Co

rru

pte

d t

un

nel

s (f

ract

ion

) un-refreshedrefreshed

For a 10,000 node P2P system with 5,000 tunnels initially (each tunnel’s length is 5, the replication factor k is 5, and the fraction of malicious nodes is fixed at 0.1):(1) During each time unit, 100 benign nodes leave and then another 100 nodes join(2) un-refreshed: keeps the 5,000 tunnels unchanged(3) refreshed: a new set of 5,000 tunnels are created to replace the old set of tunnels after each time unit

--- TAP should reform tunnels periodically to deal with P2P dynamism in the face of malicious nodes

Tunneling Performance

0

10

20

30

40

50

60

100 500 1000 5000 10000Number of nodes

Tra

nsf

er t

ime

(s)

overt

TAP_basic (l=5)

TAP_opt (l=5)TAP_basic (l=3)

TAP_opt (l=3)

Transfer a 2Mb file in a P2P system ranging from 100 to 10000 nodes:(1) overt: rely on P2P routing without any anonymous tunneling mechanism(2) TAP_basic: using TAP’ basic tunneling mechanism(3) TAP_opt: using TAP’s enhanced scheme(4) l: tunnel length--- TAP’s basic tunneling introduces big overhead in file transferring--- a longer tunnel length introduces bigger overhead--- TAP’s enhanced scheme reduces overhead significantly

Conclusions

• Leveraging P2P secure routing and replication mechanism, TAP is fault-tolerant to node failures

• By carefully choosing tunnel length l and replication factor k, TAP strikes a balance between functionality and anonymity

• TAP’s enhanced scheme improves its performance significantly

• TAP users should reform their tunnels periodically against colluding malicious nodes in very dynamic P2P systems

Future Work

• TAP lacks the ability to control future hops along a tunnel, and it trades this ability for functionality– If we can control future hops like Tarzan, TAP

may provide stronger anonymity

• TAP needs a mechanism to detect corrupted tunnels