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 r er, 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 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 P1 P3 P2 I h1,{h2,{h3,{D,m} k3 } k2 } k1 {h2,{h3,{D,m} k3 } k2 } k 1 {h3,{D,m} k3 } k2 {D,m} k3 m TAP’s tunneling mechanism I: initiator node D: destination node P i : tunnel hop node, whose nodeId is numerically closest to hopId h i {M} K : encryption of message M with symmetric key K Tunnel hop anchor

Tunnel Hop Anchor (THA) A tunnel hop is “anchored” in the system through THA In the form of –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 T f consist of 3 hops with hopIds of h1, h2, and h3 respectively –Create a reply tunnel T r consist of 3 hops with hopIds of h4, h5, and h6, T r ={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’,T r } k3 } k2 } k1 }, where K’ is a temporary public key –Send out M through T f

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 T r The Initiator I –Receive the message {f} k + {k} K’ from the reply tunnel T r –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 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 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 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 Transfer a 2Mb file in a P2P system ranging from 100 to 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