Securing Chord for ShadowWalker Nandit Tiku Department of Computer Science University of Illinois at Urbana-Champaign tiku1@illinois.edu
ABSTRACT Peer to Peer anonymous communication promises to eliminate issues of scalability and single points of failure. ShadowWalker[1] proposed by Prateek Mittal and Prof. Nikita Borisov tackles this problem. However, the underlying DHT being used, Chord[2], can be made more secure and stable for use with ShadowWalker[1]. In this paper, we demonstrate ways to make Chord[2] more secure. We calculate the benefits of maintaining successor and predecessor lists and not just the immediate successor and predecessor. We provide an efficient algorithm to deal with stabilizing these lists and ensuring that the node values are as close to the current network. We use redundancy to validate the shadows of a given node using our secure application level lookups. We use Chord[2], to perform secure DHT level lookups and demonstrate how redundancy can be used to reduce the threat of application level attacks. We also show that NISAN[3] protocol can be used to efficiently and successfully secure Chord[2] preventing DHT level attacks. Finally we provide ways to authenticate the identity of the nodes and ensure secure communication between nodes. performing secure application level lookups. We also show how NISAN[3] can be used to secure the DHT. Having both secure application level and DHT level lookups address the issues with ShadowWalker[1] as pointed out in Balancing the Shadows[4]. Finally, we provide suggestions for authenticating nodes and performing secure communications between nodes. 1.1 Terms rlookup : Redundancy parameter for secure lookups. rsucc : Redundancy parameter for successor list and predecessor list stabilization. 2. Secure Stabilize Successor and Predecessor Lists ShadowWalker[1] utilizes a single successor and a single predecessor. This can easily be exploited by a malicious party. 2.1 Current ShadowWalker Implementation 1. INTRODUCTION The paper is broken down into four parts. The first part addresses the inherent issue with having only a single successor and a single predecessor. We suggest a simple algorithm for securely stabilizing a successor list and predecessor list. Next, we address Figure 1: Identifying new predecessor A sends stabilize request to B; i.e, A contacts B to check if A is still its predecessor. 1. B replies with its successor list which contains its immediate predecessor. 2 of 9
2. Two scenarios: A is still the predecessor of B. If a new node C is now the predecessor of B, A needs to contact C to notify it that A is its predecessor. 3. A notifies its immediate successor that A is its predecessor. The immediate successor (B or C) updates its successor list, and predecessor accordingly. 4. A updates its successor list accordingly. 2.2 Weakness of Current Implementation If node B is malicious, then it can return incorrect successor list data to A. We need to verify that the information sent by B is correct. Moreover, all communication between the nodes are in plain-text. This issue is addressed in Section 5. Messages can easily be intercepted and altered. We need to encrypt all traffic between nodes during stabilization. 2.3 Proposal for Secure Stabilization 1. Each node keeps track of its m successors and m predecessors. 2. On receiving the stabilize_reply from B, we use the information returned and redundantly verify its correctness. We check every node in the successor list of B and make a request to obtain their respective predecessor list and successor list. 3. We then perform a smart merge on these lists. We use the algorithm described in Section 2.4 to securely stabilize both the successor and predecessor lists. 2.4 Algorithm 1. Send request to first rsucc successors of the node where 1 <= rsucc <= m. 2. Reducing rsucc is a speed vs security tradeoff. 3. Find union of the successor list and predecessor list. 4. Only consider nodes with ID > ID of A. 5. Sort the list by id and authenticate nodes. Authenticate pings(tcp) as well as verifies ID to IP address mapping. See Section 3 for more information. 2.5 Pseudo Code /* Global variables */ node* possiblesuccessors = {} int m int rsucc = m /* Send stabilize request to nodes */ stabilizesuccessorlistrequest(): // reset possiblesuccessors possiblesuccessors = {} // Obtain the successorlist and // predecessorlist of first rsucc nodes in the // current successor list for first rsucc nodes in stabilize_list as node: // send get succ & pred list getsuccandpredrequest(node) // call stabilizesuccessorlist after timeout set_timeout (stabilizesuccessorlist, timeout) /* Called after timeout or after obtaining response from nodes */ stabilizesuccessorlist (): // let us sort possiblesuccessors by node ids sort(possiblesuccessors) Remove(possibleSuccessors, greaterthan(myid)) 3 of 9
node * succlist = {} // m is the number of nodes we want in our successor // list for node in possiblesuccessors while succlist.size() < m : if (authenticate(node)) : succlist.insert(node) updatepublickeymap(node) // create another stabilize request after some time delay_cb (stabilizesuccessorlistrequest(), time) /* Create get succ and pred request request */ getsuccandpredrequest(node): sendgetsuccandpredrequest (node) 3. Secure Application level lookup ShadowWalker[1] relies heavily on the underlying DHT to perform lookups. When looking for a particular ID, it simply queries its finger table for that ID. 3.1 Weakness of Current Implementation A malicious node in our path could give us incorrect node information or even drop our requests. A network with sufficient number of malicious nodes can perform DoS attacks and greatly compromise privacy and security. /* On receiving request, return requested data. */ getsuccandpredreceive(node): SendSuccAndPredList(node, succlist, predlist) /* On receiving succ and pred lists */ receivesuccandpredlist(listinfo): possiblesuccessors = set_union(possiblesuccessors, listinfo) 3.2 Proposal for Secure Lookup We use a redundancy parameter rlookup to create multiple lookup paths. We then use the information returned and pick the nodeid closest to the ID we were looking for(after authentication). 1 < rlookup < m 2.6 Node Behavior Non malicious nodes return their successor and predecessor lists correctly. Malicious nodes perform a selective DoS attack on nodes by not returning nonmalicious nodes in their successor and predecessor lists. They can include other malicious nodes in their successor and predecessor lists or return non existent node IDs. The redundancy deals with the selective DoS attack and the authentication step described in Section 3 deals with non-existent node IDs. 3.3 Algorithm 1. Send lookup requests to rlookup random nodes in finger table. 2. Wait for a given time period for responses. 3. Combine all the information and pick the node ID closest to the requested ID (after authentication). 4 of 9
3.3 Pseudo-Code securelookup(): // Send lookup request to rlookup random nodes in my current finger table. securelookuprequest(): // if looking for myself, i can just set up a lookup reply // with my data. if(lookupid == me): secure_lookupreply(mydata, lookuprequester) // check if node is in my successor list else if(lookupid = in successor list): secure_lookupreply(nodedata, lookuprequester) // propagate message down the finger table else: securelookuprequest( closestnodeinfingertable ) Fig3: Successful lookups vs malicious nodes in network Using successor list size = 2m securelookupreply(): // check if new nodeid returned is more accurate than // current nodeid in fingertable. 3.4 Node Behavior Non malicious nodes return the node ID closest to the requested node or propagate the request down their finger table. Malicious nodes either perform a DoS attack and not respond or return an ID to a malicious node closest to the requested ID in an attempt to attack the node. Fig2: Lookup Failure vs malicious nodes in network. Bigger successor list sizes result in secure lookups. Due to the secure stabilize of our successor and predecessor lists, we can obtain ~10% increase in successful lookups. 5 of 9
4. Secure DHT level lookups ShadowWalker[1] uses Chord[2] to create random walks to ensure anonymous communication. We need to ensure that the fingers maintained by the nodes are accurate and do not contain malicious nodes. We use redundancy to try to secure our DHT. We will discuss two methods: partial NISAN[3] (without bounds check), and NISAN[3] (with bounds check). We will also outline the benefits of having a successor list over a single successor. 5. Once we notice that the α closest nodes to X have not changed through an iteration we choose the closest node to X. This is the node we are looking for. 4.1 Partial NISAN (without bounds check) Using simple redundancy to stabilize the finger table is ineffective. Eventually all the fingers in the finger table get poisoned. We can use an aggregated greedy search as suggested in NISAN[3]. We first demonstrate the benefits of having a successor list for stabilizing our DHT by using only the aggregated greedy search part of the NISAN[3] protocol, i.e, we do not perform bounds check. Fig4. DHT level attack on partial NISAN protocol. Using a successor list of size 2m Demonstrates benefits of a successor list 4.1.1 Algorithm 1. We use redundancy parameter α. 2. We choose α closest nodes to our query id X from our finger table. 3. We send a request to these α nodes for their finger tables and successor lists. 4. We combine the finger table information returned from these α nodes and then repeat the process from step 2 (but this time using this new set of finger information and not our original finger table). Fig5. DHT level attack on partial NISAN protocol. Successor list not used. 6 of 9
4.1.2 Node Behavior Non malicious nodes return their finger table and successor list. Malicious nodes return a malicious finger table and malicious successor list. The list returned contains the closest malicious node ID in the network to the expected ID in the list. The finger table and successor list returned contain only malicious nodes. 4.2 NISAN (with bounds check) NISAN[3] without bounds check does not do a very good job protecting against DHT level attacks. By adding the bounds check and using the complete NISAN[3] protocol, we can efficiently and effectively secure DHT level lookups. 5. Node Authentication and additional security measures 5.1 Node Authentication Malicious nodes can return invalid node IDs in an attempt to poison our successor list, predecessor list and/or finger table. We need to verify that a node ID corresponds to a valid node in the network. 5.2 Algorithm: 1. Make sure that the id to IP address mapping is correct using a hashing function like SHA or MD5. 2. Ping node to check if node is alive or exists. This is also coupled with requesting the fingerprint of the ssh key. 3. Obtain public key of the node. 5.3 Pseudo-Code: authenticate (node): // confirm that nodes IP address maps to nodes id if ( node.id!= hash(node.ipaddress) ): return false // application level 3-way handshake pingrequestfingerprint(node.ipaddress) Fig 6. NISAN protocol used to secure stabilize DHT. Simulated on a network of 10,000 nodes. Node behavior and set up are the same as described in Section 4.1. FT (α) is the fault tolerance factor for bounds check as described in NISAN[3]. updatenodestatus(node, authenticating) wait(time) if ( getstatus ( node ) == alive ): if (authentication_t.getfingerprint(node)!= obtainedfingerprint ): updatepublickeymap(node) return true else: return false 7 of 9
5.4 Public Keys We can simply request the public key from the node and trust the information returned. However, this can lead to a number of attacks. This is an open issue for now. We assume that the bootstrap server has returned accurate and valid public key information during initialization of the node. Section 5.4.1 describes how we can securely obtain a new public key. We use the public key encryption to securely communicate between nodes in the network. This adds additional security to ShadowWalker[1]. Nodes in the finger table, successor list and predecessor list are periodically pinged to check their status. If nodes are alive, they also return the fingerprint of their ssh key. Fingerprint information can be used in two ways. Since ssh keys do not change very often, this information can be used to verify the authenticity of the information returned. A simple sequence number or authentication code encrypted with the nodes public key can be used. The fingerprint returned can also be used to verify that we have the latest ssh keys for the nodes we are aware of. including their public keys. Using simple redundancy, and secure communication using public key encryption we can verify the authenticity of the change of a nodes public key. 6. Concluding Remarks ShadowWalker[1] can be made more secure by securing the underlying DHT (Chord[2]). The use of successor and predecessor lists can be used to both securely find shadows and to securely stabilize the finger tables. Using simple redundancy, we can efficiently and effectively protect against application level attacks. NISAN[3] protocol can be used to prevent against both application and DHT level attacks. 5.4.1 Change in Public Keys A node will broadcast its new public key to nodes in the network, especially nodes in its predecessor and successor list (the shadows in ShadowWalker[1]). We can then verify a change in ssh key by communicating with a nodes shadow and requesting the new ssh key or fingerprint. The shadows now also have to maintain public key information. By Property 1 of ShadowWalker[1], a node already has information about the shadows 8 of 9
REFERENCES [1] Prateek Mittal and Nikita Borisov. ShadowWalker: Peer-to-peer Anonymous Communication Using Redundant Structures Topologies. CCS'09, November 9-13, 2009 [2] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, F. Dabek, and H. Balakrishnan. Chord: a scalable peer-to-peer lookup protocol for internet applications. IEEE/ACM Trans. Netw., 11(1):17 32, 2003. [3] Andriy Panchenko, Stefan Richter, and Arne Rache. 2009. NISAN: network information service for anonymization networks. In Proceedings of the 16th ACM conference on Computer and communications security (CCS '09). [4] Max Schuchard, Alexander W. Dean, Victor Heorhiadi, Nicholas Hopper, and Yongdae Kim. 2010. Balancing the shadows. In Proceedings of the 9th annual ACM workshop on Privacy in the electronic society (WPES '10). 9 of 9