Anonymous Internet Access for the Masses with MorphMix

Transcription

1 Anonymous Internet Access for the Masses with MorphMix Marc Rennhard Swiss Federal Institute of Technology, Computer Engineering and Networks Laboratory; Zurich, Switzerland Technical Report TIK-Nr. 159 May, 23 Abstract In this technical report, we present the full design, a very detailed analysis, and the protocol specifications of MorphMix, a peer-to-peer based mix-network to enable anonymous Internet access. MorphMix overcomes the limits of traditional mix-networks without introducing new drawbacks. In particular, MorphMix fulfils all requirements to support a potentially unlimited number of users and to provide them with low latency anonymous Internet access. 1 Introduction MorphMix [31, 32] is a peer-to-peer based mix-network [8] to enable anonymous Internet usage. Unlike traditional static mix-networks such as Mixmaster [9], Onion Routing [28], the Freedom Network [6], Web Mixes [3], and the Anonymity Network [34], MorphMix does not consist of a relatively small set of dedicated mixes that serve many users. Rather, every MorphMix user is also a mix at the same time. In MorphMix, nodes can join and leave at any moment and we therefore call peer-to-peer based approaches dynamic mix-networks. Other examples of dynamic mix-networks are Crowds [29] and Tarzan [21]. The main motivation for MorphMix is to provide low-latency anonymous Internet access for the masses, i.e. for millions of users. Static mix-networks operated commercially or not are not well suited to fulfil this task [33]: the experience with the commercial Freedom network has shown it is difficult to operate such a system in a profitable way and static mix-networks made up of volunteers running a mix may fail to acquire enough mixes for cost reasons and due to potential political and legal pressure. In general, small static mix-networks suffer from the problem that an adversary can try to operate a significant portion of all mixes himself. Consequently, the only way that mix-networks composed of mixes operated by volunteers are secure against a well-funded adversary trying to operate several mixes in the system is to make sure that the number of honest mixes is so high that the attack gets too expensive. MorphMix does not intend to provide perfect anonymity. In fact, considering the asynchronous nature of the Internet and powerful attacks on mix-networks [5, 4, 41], it is very unlikely that operating a practical mix-network that offers perfect anonymity is possible at all especially when the mix-networks aims at supporting low-latency applications. Cover traffic helps somewhat against certain kinds of adversaries but introduces significant bandwidth overhead and is of limited value against an attacker that operates some of the mixes by himself. Consequently, practical anonymity systems have always been a

2 compromise between usability, overhead, and protection from attacks, and MorphMix is in line with this practice. In this technical report, we present a heavily updated version of the original MorphMix design [31, 32]. The goals of MorphMix remain the same as in the first version: 1. Joining the system should be easy for anybody having access to a computer with a public IP address that is connected to the Internet. 2. The bandwidth overhead should be kept low. In particular, we do not want to employ cover traffic. 3. MorphMix should protect from an adversary operating several malicious nodes to break the anonymity of legitimate users. 4. The system should make successful traffic analysis attacks very difficult. 5. MorphMix should be able to efficiently cope with a large number of participating nodes. 6. The end-to-end performance should be acceptable despite the dynamic environment and unreliable nodes. Compared to the previous version of MorphMix, this documents solves many issues that were left as open problems: We define a precise threat model to which MorphMix is supposed to be resistant in section 3. The setup protocol in section 4.1 to append a node to an anonymous tunnel has been changed. It still makes use of the same basic principles as the original protocol, but has been adapted to resist a certain attack and to be more efficient when appending the first node of a tunnel. When computing the correlation of an extended selection, IP addresses were either equal or completely different. This allowed an adversary who owns a class B network to operate completely distinct nodes at the same time. In section 5 we present a modified version of the collusion detection algorithm, which forces an adversary to control nodes in a wide variety of networks to be effective. The original design had scalability problems. Computing the correlation of a new extended selection grew beyond a few 1 ms as the number of nodes in the system approached several 1. Additionally, memory requirements also grew with the number of nodes. The modified collusion detection algorithm in section 5 solves this scalability problem. In particular, The system can now handle an arbitrary number of nodes, i.e. there can be as many nodes in the system as there are public IP addresses. The problem of discovering other nodes has been solved and is introduced in section 6. Only a few attacks were analysed in the original papers. In section 8, we will look at a much wider spectrum of attacks. The detailed protocol description is given in section 11. To analyse of the end-to-end performance users can expect when accessing services through MorphMix, a simulator has been implemented and the results are presented in section 12. 2

3 The remainder of this document is organised as follows: In section 2, we illustrate the basic functionality of MorphMix. Section 3 describes the threat model and in section 4, we examine how anonymous tunnels, the key concept in MorphMix to access the Internet anonymously are set up. Section 5 explains the collusion detection mechanism and peer discovery is described in section 6 and section 7 analyses scalability issues of MorphMix. In section 8, we take a close look at several attacks on MorphMix. Sections 9 and 1 analyse the performance of the collusion detection mechanism and section 11 describes the protocol in detail. In section 12, we present the MorphMix simulator and the simulation results and section 13 concludes our work. 2 Basic Functionality of MorphMix In this section, we describe the basic functionality of MorphMix by examining how hosts can be accessed anonymously. The details about the MorphMix protocol are given in section 11. MorphMix consists of an open-ended set of nodes. A node i is identified by its IP address ip i. In addition, each node has a key-pair consisting of a private key PrK i and a public key PuK i. This key-pair is generated locally when a node is started for the first time. We assume that at any time, a node knows about some other nodes, i.e. their IP addresses, the ports on which the MorphMix application is listening for incoming connection requests, and their public keys. Learning about other nodes requires a peer discovery mechanism, which we will describe in section 6. Figure 1 depicts the basic idea of MorphMix. Figure 1: Basic idea of MorphMix. A node that is part of MorphMix is connected to one or more other MorphMix nodes at any time. We say that two nodes are connected if they have currently established a link encryption. A link encryption means there is exactly one TCP-connection between the two nodes and that they share a symmetric key that is only known to them. The set of nodes a node a is connected to are a s neighbours. In figure 1, a has five neighbours because it is connected to five nodes. Basically, MorphMix is a circuit-based mix-network and to access hosts in the Internet anonymously, a node establishes a circuit via some other nodes, which we name anonymous tunnel. In figure 1, node a has established an anonymous tunnels via b and c. The first node in a tunnel (a) is the initiator, the last node (c) is the final node, and the nodes in between (c) are intermediate nodes. The initiator and the final node are the endpoints of a tunnel. The total number of nodes in a tunnel is the tunnel length and equals three in the example above. If the tunnel length is more than three, there are multiple intermediate nodes. To send data anonymously to a host h, a sends them through the anonymous tunnel, which means the data are forwarded via b and c to h. The link from c to h and h are not part of MorphMix, which means that for h, it looks as if it communicates with c and it cannot know that c is merely forwarding data for a. Like in any mix-network, every node along an anonymous tunnel only knows the the nodes to the left and right in a tunnel. Node b only knows a and c and c only knows b and the host h, but no 3

4 one except the initiator knows that a communicates with h. In static mix-networks, the client is not part of the system, which means the first mix the circuit can easily identify the client using the circuit. In MorphMix, this is not the case because every client is also a mix. This means that in figure 1, b cannot be sure if a is the initiator of the tunnel or if a is just another intermediate node in the tunnel and relays data for yet another node. The anonymous tunnel setup protocol guarantees that no intermediate node along a tunnel can learn whether it is directly following the initiator or not (see section 4.2). In MorphMix, all data are transported within the payload of fixed-length packets between two neighbours. Such a packet consists of a header and a payload. If the length of the data is longer than what fits into the payload of a single packet, the data are split such that they fit into the payloads of multiple packets. The payload of the last packet is padded with random bits to its fixed length. The header of a packet contains an identifier that has only local significance on a link between two nodes to correctly forward the data along its tunnel. The header also contains a type to distinguish various types of data transported within the packets and a checksum to check the integrity of the data and to counter replayattacks. Note that the data of multiple anonymous tunnels may be transported between two neighbours and all of them use the same TCP-connection and the same link encryption between the two nodes. This is the reason why an identifier is needed in the packet header: to distinguish the packets belonging to different anonymous tunnels. To prevent an external observer from easily identifying what data exchanged between neighbours belong to what tunnel, the header is encrypted using the keys of the corresponding link encryption. To transport data anonymously along a tunnel, MorphMix makes use of layered encryptions. Figure 2 depicts the concept of layered encryptions using a fully set up anonymous tunnel from a via b and c. Figure 2: Layers of encryption. There are link encryptions between nodes a and b (LE ab ), and b and c (LE bc ) that are communicating directly with each other. In addition, there is one nested encryptions (NE ab and NE ac ) between the initiator a and each other node (b and c) along the tunnel to layer-encrypt packets. A nested encryption between two nodes means the two nodes share a symmetric key (k n,ab and k n,bc ) that is only known to them. The initiator always knows the other endpoint of a nested encryption, but not vice versa, which is a fundamental property of layered encryption employed in mix-networks. Even b does not know that a is the other endpoint of the nested encryption NE ab because b does not know if a is the initiator of the tunnel. The main reason to use nested encryptions in mix-networks is to hinder any two nodes that are part of the same anonymous tunnel but that are not directly following each other in the tunnel from easily relating packets flowing through them. The data transported within the payloads of packets are called messages. Messages are either exchanged between two neighbours or between the endpoints of an anonymous tunnel. In the first case, the messages are directly transported within the payloads of the packets and the identifier in the header has often no meaning because the message must not be forwarded to another node. In the case of end-toend messages, the messages are not directly put into the payloads of the packets, but into the payloads of end-to-end packets. End-to-end packets fit exactly into the payload of a packet between neighbours and contain the same header. One end-to-end packet is always put into one packet between neighbours. Anonymous connections are only significant between the initiator and the final node in a tunnel and due to the nested encryptions, the headers and payloads of the end-to-end packets are not visible to the intermediate nodes in a tunnel. In particular, forwarding the packet along a tunnel is done using only the 4

5 identifier in the headers of the packets exchanged between neighbours. Using end-to-end packets allows the endpoints of a tunnel to distinguish between control and data messages. In addition, it enables multiplexing anonymous connections within one anonymous tunnel in the same way as in the Anonymity Network [34]. This means there are two levels of multiplexing: multiple anonymous connections can be transported within one anonymous tunnels and multiple anonymous tunnels can be transported within one TCP-connection between two neighbours. The application data to be anonymised is transported within anonymous connections. One anonymous TCP-connection from the initiator s computer to a host is mapped onto exactly one anonymous connection. The MorphMix node in a computer is accessed like a proxy: the application connects to the node listening on a port p appl, which is 88 per default but can be changed by the operator of the node. Each application must be specifically supported by MorphMix, and in its first version, MorphMix supports HTTP (both versions 1. [2] and 1.1 [18]) and HTTPS [36]. So if a web browser connects to the node and sends a request, the node parses the request, establishes an anonymous connection within an anonymous tunnel and sends the IP address and port of the targeted web server to the final node. The final node connects to the web server and the anonymous end-to-end connection from the web browser to the web server is established. Figure 3 illustrates how the application data are transported within anonymous connections along an anonymous tunnel, and how the forwarding is done using only anonymous tunnel information. &' 1 2 ( - & 3 3 * * &+ ( ", * -. &/ * * * * * * "!! " " #! #! ' (! ' ( # #! % 4- % 5 % ) # %! $% &" &' ( $) & ' ( Figure 3: Anonymous connections and packet forwarding There is again an anonymous tunnel from a via b to c. We assume that 7 is the identifier on the link from a to b and 15 on the link from b to c. This means that b knows that every packet arriving from a with identifier 7 must be forwarded to c with identifier 15. The identifier also tells b which key to use to add and remove the corresponding nested encryption, which is identified with k n,ab. Similarly, c knows that packets arriving from b with identifier 15 have reached their final node and the nested encryption can be removed with k n,ac. The user at the computer running node a wants to access a service that listens on and port p h on host h with IP address ip h. To do so, the application has established a connection to node a and an anonymous end-to-end connection from the application to port p h on h has also been set up. We assume the corresponding anonymous connection is identified with the identifier 3. The connection from the application to a is identified with the socket pair ip a :1295 ip a :p a and a knows that everything arriving from the connection corresponding to this socket pair must be sent through the anonymous tunnel using the anonymous connection with identifier 3. Similarly, c uniquely identifies the connection to h with the socket pair ip c :45763 ip h :8. 5

6 To send data from the application to the service on the host, the application sends them to a. Node a chops them such that the resulting end-to-end packets fit into the payload of fixed-length packets between neighbours. In figure 3, we assume that this results in three end-to-end packets. The payload of the last packet is padded to its maximum length and the identifier of the anonymous connection (3) is put into the headers of the end-to-end packets. Every packet is then completely encrypted with k n,ac corresponding to the nested encryption between a and c, and with k n,ab corresponding to the nested encryption between a and b. The resulting data of a single end-to-end packet is then put into the payload of fixed-length packet between neighbours and the header is filled with the correct identifier to identify the packet on the link between a and b. The header is then encrypted using the link encryption key k l,ab and the packet is sent to b. Upon receiving the packet, b decrypts the header, sees the identifier (7), knows that the nested encryption can be removed with k n,ab and that the packet must be forwarded to c with identifier 15. A new header is built and encrypted with k l,bc, and the packet is forwarded to c. Node c decrypts the header, sees the identifier 15, knows that the nested encryption can be decrypted with k n,ac, and also knows that the packet has reached its final node. It consults the header of the end-to-end packet, sees that the identifier is 3 and knows that the payload (without padding) must be sent out on the connection given by the socket pair ip c :45763 ip h :8. This is done for all three end-to-end packets and the host receives all data in correct order. Sending data back from the host to the application works exactly in the opposite way. Note that end-to-end messages are not only sent through completely set up anonymous tunnels like in the example above. During the setup of anonymous tunnels (see section 4.1), nodes are appended hop by hop to the tunnel. At any time, the initiator can exchange end-to-end messages with the node that is currently the final node in the tunnel. 3 Threat Model In this section, we state our threat model. MorphMix wants to provide anonymity for the masses and aims at a large number of nodes distributed all around the world. This makes a global attacker extremely unlikely [33] because to observe all traffic in the system, the data of hundreds of ISPs need to be correlated, which is not realistic. Therefore, MorphMix is not designed to provide protection from a global eavesdropper. In fact, considering mix-networks and assuming a global eavesdropper, then practical anonymity for low-latency applications is probably impossible. Even bi-directional cover traffic stream between pairs of mixes are of limited help against powerful attacks such as the long-term intersection attack [4]. We therefore do not employ cover traffic between two MorphMix nodes that are directly communicating with each other. Nevertheless, we believe that observing a small portion of all nodes is possible. For instance, an access ISP can observe the data of all its subscribers and a backbone ISP can see the traffic sent to and received from several access ISPs. If the adversary manages to eavesdrop on a percentage p of all nodes, the probability that both the initiator and final node of any anonymous tunnel are observed by the adversary is approximately given by (p/1) 2 [42]. Assuming an adversary can observe 5% of all nodes, he manages to break the anonymity of one out of 4 tunnels. On the other hand, it is easy for an adversary to operate several nodes in MorphMix. There is no admission control and everybody having access to a computer with a public IP address that is connected to the Internet can join and run a node. As a result, we must assume there are honest nodes, which are nodes that do not try to break the anonymity of other users and there are malicious nodes, which collude with other malicious nodes to break the anonymity of honest users. A MorphMix node has a unique IP address, but multiple nodes may run on a single computer. Honest users typically run exactly one node on their own computer, while an adversary can run several nodes on a single computer if he possesses a range of IP addresses. For instance, an adversary owning a class C network can theoretically operate up to 253 different malicious nodes by receiving any packet addressed to an IP address within this network in promiscuous mode. 6

7 Although the traditional notion of class A, B, and C networks has been blurred due to subnetting [25] and classless interdomain routing (CIDR) [3], it is still the case that only contiguous ranges of IP addresses are under a single administrative control. To hinder anybody owning such a range of IP addresses from running a large number of completely different nodes, the collusion detection mechanism of MorphMix (see section 5) does not operate on the whole IP address, but only on their 16-bit IP prefix. We say that all IP addresses with the same 16-bit IP prefix belong to the same /16 domain. There are exactly public /16 domains in the Internet: the unicast address range between 1... and corresponds to 5788 different domains, but 256 of them are assigned for local addresses ( ) and 273 fall into the private address ranges ( , , and ). An adversary owning a whole class B network can still run MorphMix nodes, but from the point of view of collusion detection, they all belong into the same /16 domain. Controlling nodes in many different /16 domains is much more difficult than in a single domain. One possibility is an adversary owning a class A network, but even this gives him easy access to only 256 different /16 domains. The situation is similar when looking at ISPs. Hardly any ISP administrates the addresses of more /16 domains than what corresponds to a class A network. As a result, an adversary won t manage to control nodes in very many different /16 domains if he runs them only in the domains he owns. A better strategy for the adversary is to operate nodes also in networks he does not own. Acquiring IP addresses under his own name in a wide variety of domains could soon become suspicious. So instead of acquiring IP addresses under his own name, the adversary could provide private persons with the necessary equipment to operate nodes at their homes and pay them 1$ a year in addition. Assuming the infrastructure (a decent network connectivity and a PC) costs 4$ a year per node, there are yearly costs of 5$ per node. Convincing 1 people to run 1 nodes in 1 different /16 domains would therefore cost 5$ per year. This is certainly not a barrier for certain organisations that would like to break the anonymity of the MorphMix users. To do so, the adversary would somehow have to advertise that he is looking for users operating nodes for him, which again would eventually become suspicious. In any case, even if the adversary does not care if he is detected, getting control over 1s of nodes in as many different /16 domains either by operating them himself or by private persons he provides with money and equipment is very difficult, in particular because it would involve nodes located in several different geographical and jurisdictional regions. We say that an adversary controls 1% of a /16 domain depending on the percentage of malicious nodes in this domain. If a node contains only malicious nodes, the adversary controls 1% of the domain. If it does contain only honest nodes, the adversary controls %. If it contains both honest and malicious nodes, the adversary controls any percentage greater than % and smaller than 1%. with n D nodes in a domain D where n h,d are honest and n m,d are malicious, the percentage p c,d the adversary controls is given with p c,d = n m,d /n s 1. There is one difference for the adversary between owning a domain and running a node in a domain he does not possess: In the first case, he can operate as many nodes as there are IP addresses available, and he can force p c,d of this domain close to 1% even if there are a few honest nodes. Another option is to simply block all MorphMix traffic from and to the honest nodes. Conversely, if the adversary runs nodes either by himself or by private persons in domains he does not own, p c,d is often smaller than 1% when there are also honest nodes in the domain. The reason is that the adversary controls only one or a small range of IP addresses and cannot run as many nodes as he likes. Our threat model is as follows: we assume the adversary can operate nodes in a limited number of /16 domains. He either owns the domains and controls 1% of them, but we do not assume it is realistic a single adversary will ever own more than 1 /16 domains, which corresponds to about four class A networks or 1 class B networks. Even the largest ISPs do not control addresses in so many /16 domains, which can be seen by querying the whois servers of the Regional Internet Registries such as 7

8 RIPE NCC 1 or ARIN 2. The other option for the adversary is to run nodes in domains he does not possess, either by himself or by private persons. Usually, he controls less than 1% of these domains because there are also honest nodes present. Again, running nodes in several 1 domains across different geographical and jurisdictional regions is very difficult, in particular if the adversary wants to avoid that his activities to break the anonymity of the users of MorphMix become public. We also assume the malicious nodes can mark every packet entering and exiting them with a precise timestamp and send it to a centralised place where the traffic flowing through different malicious nodes can be correlated. Note that we do not consider the external observer as a threat because it is unlikely he can observe more than a few percent of all nodes. In any case, we believe it is easier for an adversary to be present in d domains than to passively observe d domains. 4 Establishing Anonymous Tunnels In this section, we present and analyse the concept of anonymous tunnels, which are the key to enable anonymous communication in MorphMix. We first present how anonymous tunnels are set up and analyse the procedure. Then we talk about the policy about how links to neighbours should be used and why MorphMix provides incentive to relay the data of other nodes. 4.1 Anonymous Tunnel Setup One key feature of MorphMix is that the initiator selects only the first intermediate node and each node along the anonymous tunnel then picks the following node. Consequently, each node only needs to know about the nodes in its neighbourhood. They can communicate with each other and exchange control information to learn which of them have spare resources to accept new anonymous tunnels. The disadvantage of this approach is that once we hit a malicious node that wants to collect data about anonymous tunnels, this node could either simulate all remaining hops by itself or use an accomplice as the next hop. We will show in section 5 how to solve this. When node a wants to set up the link encryption with another node b, it first establishes a TCPconnection with b. a then selects a random bit-string that serves as the symmetric key for the link encryption. The key is encrypted with b s public key and sent to b. Setting up a nested encryption takes place between the initiator and a node along the anonymous tunnel. The goal is to establish a symmetric key known only to the two end-points of the nested encryption. Except for the first intermediate node, the initiator does not know the nodes that will be added hop-by-hop along a tunnel it sets up. Consequently, the initiator does also not know the public keys of these nodes beforehand and we therefore use the Diffie-Hellman (DH) [12] key-exchange algorithm. If the initiator simply sent its half of the DH key-exchange to node b responsible for selecting the next hop c, b could easily play the role of c (and other nodes following c) itself without the initiator noticing this. To counter this attack, we must not allow b to see the initiator s half of the DH key-exchange in the clear. To solve this problem, we introduce the notion of a witness. For each hop, the initiator selects a witness randomly from the nodes it currently knows. The witness task is to act as a third party in the process of establishing a symmetric key between the initiator and the newly appended node. Figure 4 illustrates the principal procedure to append a node to an anonymous tunnel and to set up the nested encryption. It only illustrates the most important fields in the messages. In section 11, we will describe the whole MorphMix protocol in much more detail. Node a is the initiator. We assume the tunnel has already been set up to node b (via zero or more intermediate nodes). In addition, b has currently three connections established to nodes c, d, and e that are willing to accept further anonymous tunnels. To append a new node to the tunnel, all messages 1 whois.ripe.net 2 whois.arin.net 8

9 Z AB T D B T D E F G T D K AB C D B C D E F G C D K L M N O P Q R C O P Q RT K AB C D B C D E F G C D K L M N O P Q R C O P Q R T [ ^ K AB J D AB C O P SR T _ ; WL U V \ ] AB J D K L M N O P Q R C : >? Y AB C D B C D E F G C D AB H D B H D E F G H D AB I D B I D E F G I K AB J D AB CO P SR T D L M C a b < = L M C ` Figure 4: Appending a node to a tunnel and setting up the nested encryption. exchanged between the initiator and the currently final node (messages 1, 2, 3, and 4 in figure 4) are transported within the tunnel that is set up so far using end-to-end packets. All the other messages are directly exchanged in the payload of packets between neighbours. The following messages are needed to append a node and to establish the nested encryption with this node. 1. a sends a message to b that tells b to append another node to the tunnel. The message contains s, which is the number of nodes b has to offer to a in message 2. Here, we assume s = b receives the message and selects s = 3 potential next hop nodes (c, d, and e) among its neighbours. It sends a message back to a that contains the IP addresses (ip c, ip d, and ip e ), ports (p c, p d, and p e ), and public keys (PuK c, PuK d, and PuK e ) of the three potential next hop nodes. We name the list of IP addresses offered by b the selection of b. 3. a receives the message and randomly picks one node from the selection of b as the next hop. Here, we assume c is selected. Then a picks a witness w randomly from the set of nodes it currently knows, generates its half of a DH key-exchange (DH a ), encrypts it for c with PuK c, and encrypts the resulting data together with ip c, p c, and PuK c using w s public key PuK w. This results in in {ip c, p c, PuK c, {DH a } PuKc } PuKw, which is put into a message together with the witness IP address ip w, the port p w on which it accepts connections, and its public key PuK w, and is sent to b. 4. b receives the message, establishes a link encryption with w and forwards the encrypted data. 5. w receives the message, decrypts the encrypted data to get ip c, p c, PuK c and {DH a } PuKc, and establishes a link encryption with c using PuK c. w generates a message consisting of ip b and {DH a } PuKc and sends it to c. 6. c gets the message and checks if it is indeed willing to accept an anonymous tunnel from b. If yes, c decrypts DH a, and sends a message back to w telling it that everything is OK. In addition, c builds its own half DH c of the key-exchange and uses DH a to compute the key k n,ac for the nested encryption between a and c. 7. w receives the message and generates the receipt for a. The receipt contains the IP addresses of b and c and is signed by w using PrK w. 8. b receives the message from w and learns that w has selected c as the next hop. It generates a message containing the identifier ID to be used to identify data belonging to this anonymous tunnel on the link between b and c and sends it to c. 9

10 9. c gets the message and sends its part DH c of the DH key-exchange back to b. 1. b generates a message consisting of DH c and the receipt from w and sends it to a. Upon receiving this message, a checks if the receipt is indeed signed by w and if it contains b s and c s IP addresses. a then uses DH c to compute the key k n,ac for the nested encryption between a and c. 4.2 Analysis of the Anonymous Tunnel Setup The main changes compared to the original protocol is that the initiator picks the node to be appended and not the witness. The witness is now only needed to hide a s half of the DH key-exchange. Letting a pick the next node from b s selection has several advantages, in particular: There is an attack on the original protocol that has not been considered: a malicious witness could simply always pick a malicious node from a selection to be used as the next hop, even if the node offering the selection was not malicious. This significantly increased the chances for the attacker to break a tunnel. Since it is no longer the witness that picks the next hop, the attack is no longer relevant. In the original design, b knew which node was going to be the witness before offering the selection. So if b and w were malicious, they could easily generate a fake selection for a and use any other malicious node for the next hop (or b could simply simulate the next hop itself). Now, the selection is sent to a before w gets known, so even if it happens that b and w are colluding, they cannot prepare for this attack. When appending the first intermediate node to the tunnel, the initiator had to simulate a complete nested encryption setup to hinder that node from learning whether it is the first intermediate node or just any node along the tunnel. In particular, the initiator had to offer a selection of its own neighbours as possible next hops to let the witness pick one from them. In the new protocol, only messages 4 9 in figure 4 must be used to append the node directly following the initiator and a can pick the node to append itself without having to offer a selection to any other node. There are two important points to notice about the nested encryption setup. The first is making sure that b does not learn a s half of the DH key-exchange as this would easily enable b to simulate all remaining hops by itself. This is achieved by encrypting DH a first for c and then for w, which guarantees DH a is never seen in the clear except at c. In particular, b never sees DH a in non-encrypted form. The second is preventing b from selecting the next hop purely by itself. This is achieved by having b offering a selection of possible next hops to a and a selecting one of them. This guarantees that b cannot predict which of the nodes in the selection is going to be picked as the next hop and makes it much more complicated for b to determine the next hop. In particular, if b wants to make sure that c is in the same set of colluding nodes as itself, then all nodes in the selection of b must be in that collusion. There is another aspect in the setup of a nested encryption that requires explanation. Assume b and w are both malicious. When b offers the selection. it cannot yet know who the witness will be, but c can hope for a malicious witness and include only public keys in message 2 it knows the private keys of. If it turns out that the witness is really malicious, b and c can decrypt DH a and b can simulate the next hop itself. However if the witness is not malicious, the setup will fail since c cannot decrypt DH a because it is not encrypted with c s real public key. But even if b and w are malicious and b simulates c itself, this will be detected when appending the next hop if that witness is not malicious. This is why w includes b s IP address in the receipt in message 7: to inform a about the identity of the node that is appending the next node. We conclude that the attack with fake public keys in message 2 can only succeed if the witnesses that are used to append all following nodes are malicious. We analyse the impact of this attack in section

11 To carry out a man-in-the-middle attack on the nested encryption setup, the adversary needs active control over several network links [31, 32]. As a consequence, the most realistic attack is the one where a set of cooperating malicious nodes tries to control as many nodes along an anonymous tunnel as possible by offering many or exclusively nodes from their collusion in their selections. 4.3 Policy on Using the links to Neighbours Basically, the link encryptions to neighbours are bi-directional which means that although a has set up the connection to b, the connection can be used by both end-points to advertise the other node in selections. Similarly, a can pick b as its first intermediate node in a tunnel and vice versa. However, such a policy opens makes an attack possible where the adversary has several of the nodes he controls establish connections with an honest node a such that a ends up with many malicious neighbours. The first consequence is that the probability a picks a malicious node as first intermediate node in a tunnel it sets up is quite high. Since controlling the first intermediate node is a requirement for the adversary to break the anonymity of the tunnel (see section 8), this would increase the adversary s chances to break tunnels initiated by a. To avoid this problems, a should pick the first intermediate node only among those nodes to which a has established the connection itself. The second consequence is that if a should append the next hop to a tunnel of another node, it will offer many malicious nodes in the selection it sends back to the initiator in message 2 of figure 4. Assuming malicious nodes offer mainly other malicious nodes in their selections, this implies the selection of this honest node looks very similar to one of a malicious node. However, this second consequence is not a big problem because if there are too many malicious nodes in the selection, the initiator will detect this with high probability and reject the tunnel (see section 5.3). Nevertheless, we will use the policy that a node only uses those nodes as first intermediate nodes or in selections it offers if it has established the connection to them itself. 4.4 Why Relaying Data for Other Nodes is Good Many peer-to-peer systems suffer from the free rider problem [16]. Especially in popular file-sharing systems, most user only consume but do not provide the files they downloaded to others. The main problem is that there is no real incentive to offer content to others because everything is for free and the systems seem to work well enough even if most users are free riders. Actually, it s slightly worse because offering content consumes some of a node s up-stream bandwidth. Solving the free rider problem by technical means is very difficult and include micropayments and reputation systems, both of which have been discussed in the context of the Free Haven project [14]. MorphMix suffers from the same problem. Nodes can simply not to choose relay data of others by never accepting links being established to them. This poses a problem because assuming that, say, only 1% of all nodes are relaying data of others, the load on them could get quite high and the performance may suffer. However, the advantage of MorphMix compared to other peer-to-peer systems is that MorphMix provides incentive to relay the data of others. This has to do with the fact that the first intermediate node in a tunnel cannot easily learn that it is the first intermediate because no such information is leaked during the setup of the anonymous tunnel. So if a node is accused of having contacted a host anonymously, its operator can claim she only relayed the data for another node. This is also known as plausible deniability and is a very useful property of anonymity-providing systems. For instance, static mix-networks do not have this property because the clients and mixes are strictly separated. However, if a node a is a free rider in MorphMix, other nodes can learn about this by trying to establish link encryptions to a. If this always fails or if a never accepts relaying tunnels, it can be concluded with very high probability that all data sent or received by a belong to tunnels of which a is the initiator. This implies that a cannot plausibly deny being the initiator of a tunnel and reduces a anonymity compared to other nodes that relay the data of others. 11

12 5 Collusion Detection Mechanism The collusion detection mechanism makes use of the fact that if malicious nodes want to control many nodes in an anonymous tunnel, they have to offer many or only malicious nodes in their selections. Corresponding to honest nodes, we name the selections they offer honest selections and the selections from malicious nodes malicious selections. In this paper, we describe a slightly modified collusion detection mechanism than the basic one [31, 32]. The main difference is that it is no longer based on the nodes IP addresses, but on the nodes 16-bit IP prefixes. The main reason is that with the basic mechanism, it was possible for an adversary to own a single class B network to operate completely different nodes. It is still possible for the adversary to operate as many nodes as IP addresses he owns. But from the point of view of the collusion detection mechanism all nodes in the same /16 domain are equal (see section 3). In a large system with honest nodes in the majority of all public /16 domains, an adversary must operate at least one node in several 1 different /16 domains to have at least partial control over a significant portion of MorphMix. Beyond that, moving from IP addresses to /16 domains has more advantages. One is that although as many nodes as there are public IP addresses can participate, the number of different nodes seen by the collusion detection mechanism is bound by the number of public /16 domains. As a result the time required for the collusion detection mechanism to process a selection is bound and won t grow beyond a certain limit. This is a major improvement compared to the original design. Furthermore, many Internet users not connected all the time get dynamic IP addresses. In the original design, this gave the node a new identity every time it joined MorphMix. Since dynamically assigned IP addresses by the same ISP are usually at least within the same /16 domain, the node s identity won t change for the collusion detection mechanism. Otherwise than switching from IP addresses to domains, the collusion detection algorithm stays exactly as it was. It makes use of the selections a user gets during the setup of anonymous tunnels (messages 2 in figure 4). The first node in a receipt is the one selected by the witness, which implies the initiator knows which node has offered which selection for each intermediate node in an anonymous tunnel. 5.1 Correlation and Correlation Distribution Each node maintains an internal table that contains a row for each selection it has received during the setup of anonymous tunnels. Each row is a combination of a selection and the node that offered the selection, which we name extended selection. Again, we distinguish between honest extended selections and malicious extended selections depending on whether the selection has been offered by an honest or malicious node. Having moved to domains, the extended selection does not contain the IP addresses, but the corresponding 16-bit IP prefixes. If prefix 16 (ip) gives the 16-bit IP prefix of an IP address and if node b has offered the selection {ip c, ip d, ip e }, the resulting extended selection is {prefix 16 (ip b ), prefix 16 (ip c ), prefix 16 (ip d ), prefix 16 (ip e )}. For each new extended selection, a node computes the correlation according to algorithm 1: Algorithm 1 Computing the correlation of an extended selection 1. Build a set ES N consisting of the nodes of the new extended selection. 2. Define a result set ES R which is empty at first. 3. Compare each extended selection ES T in the internal table with ES N. If ES N and ES T have at least one element in common, add the elements of ES T to ES R. 4. Count each occurrence of elements in ES R that appear more than once and store the result in m. 5. Count the number of elements that appear only once in ES R and store the result in u. 6. Compute the correlation c which is defined as c = m/u if u >, or otherwise. 12

13 We argue the correlation is in general relatively big if the new extended selection contains many or only colluding nodes. The reasons are that colluding nodes (1) select other colluding nodes with high probability and (2) are selected by other colluding nodes with high probability. This follows from our assumption that attacks by a cooperating malicious set of nodes are most likely. Similarly, honest nodes (3) pick nodes for the selections they offer from the set of all other nodes and (4) are picked by all other honest nodes. In step 3 of algorithm 1, we want to find out what the nodes in the new extended selection have done before, i.e. in what extended selections they have appeared before and collect all extended selections in the internal table that contain elements of the new extended selection in a set ES R. For reasons (1 4), we can state the following properties about the set ES R : 1. If ES N mainly consists of colluding nodes, ES R will contain relatively few different nodes and many occurrences of several colluding nodes. This implies a big m and a small u, resulting in a big c. 2. If ES N mainly consists of honest nodes, ES R will contain relatively many different nodes with only a few of them occurring several times. This implies a small m and a big u, resulting in a small c. Simply counting how many times the domains in ES N show up in the internal table does not work. Although domains with malicious nodes may show up in extended selections more frequently on average because malicious nodes offer many or only other malicious nodes in their selections, many /16 domains consisting of only honest nodes will also show up frequently, either because there are many nodes in them or because some nodes have a lot of bandwidth and computing power to spare. In addition, there is an attack the adversary could exploit if counting the occurrences were used that we will point out in section 8.6. Note that the complexity to compute the correlation of a new extended selection is proportional to the number of extended selections in the internal table. For scalability reasons, we cannot keep all extended selections in the internal table forever. Rather, we forget old extended selections and to keep only the k most recently received extended selections in the internal table. We will talk in section 5.2 about reasonable values for the size of the internal table. A node remembers the correlations it has computed over time and represents them as a correlation distribution. It is implemented as an array with 5 slots, whereas each slot of the array corresponds to a particular discrete correlation. If a new correlation c is computed, it basically affects the slot closest to c by incrementing its value by 1. However, in order not to let grow the values in the array indefinitely, they follow an exponential weighted moving average (EWMA) with parameter α. α is slightly smaller than 1 and depends on the number of extended selections in the internal table. After a new correlation has been computed, the value in each slot is multiplied with α, and (1 α) is added to the slot that corresponds to the new correlation. We analyse how the correlation distribution looks. We assume a system with 1 nodes, where some of them are malicious and in the same colluding set. All 1 nodes are in different /16 domains and every honest node has the same probability of being offered in a selection. We set up 5 anonymous tunnels, whereas each tunnel consists of five nodes in total. This means that the initiator gets three different selections during the setup of each tunnel, one from each of the intermediate nodes. Each selection contains 14 nodes, which is a reasonable selection size in a system with 1 nodes (see section 5.2). For now, we assume that malicious nodes offer only other malicious nodes from their collusion in their selections, i.e. selections from malicious nodes contain 14 malicious nodes. Figure 5 shows the correlation distribution when, 5, 1, 2, 3, and 4% of all nodes are malicious. We can see the contributions of honest and malicious nodes to the correlation distribution. In general, it results in two peaks, one on the left from the honest nodes and one on the right from the malicious nodes. The more malicious nodes there are in the system, the bigger the right peak gets and the closer the two peaks move together. 13

14 .2 extended selections from good nodes extended selections from malicious nodes.2 extended selections from good nodes extended selections from malicious nodes.2 extended selections from good nodes extended selections from malicious nodes frequency.1 frequency.1 frequency correlation correlation correlation a) % malicious nodes b) 5% malicious nodes c) 1% malicious nodes extended selections from good nodes extended selections from malicious nodes.2 extended selections from good nodes extended selections from malicious nodes.2 extended selections from good nodes extended selections from malicious nodes frequency.1 frequency.1 frequency correlation correlation correlation d) 2% malicious nodes e) 3% malicious nodes f) 4% malicious nodes Figure 5: Correlation distribution with 1 nodes 5.2 Selection Size and Size of the Internal Table We pointed out in the original design that the shape of the correlation distribution depends on the selection size and the size of the internal table. In general, both a larger internal table and a larger selection size help to separate the peaks in the correlation distribution, but it has its limits. On the other hand, increasing their size also means that the time to compute the correlation and the memory requirements to store the internal table grow. Using experiments, we have derived reasonable values for both sizes. They depend on the number of different /16 domains of which IP addresses have been seen so far. If d is the number of different /16 domains of which the initiator has seen IP addresses so far, the selection size s to be used is given by: s = max (3, 7.75 log 1 d 17 ) (1) In the original design, the selection size was logarithmically dependent on the number of nodes the initiator had seen, which was one reason the system did not scale well to a million users. But now, the selection size depends on the number of different /16 domains the initiator has seen. Since there are only different /16 domains, there is an upper bound for s, which is given by s max = ( 7.75 log ) = 2. So the selection size is always between 3 and 2. The size of the internal table is also no longer dependent on the number of nodes, but the number of different /16 domains the initiator has seen. If s is the average number of nodes in a selection, the number of extended selections k in the internal table is given by: k = 2 d s (2) Like for the selection size, there is also an upper bound for the size of the internal table, which is given by k max = /2 = So if the initiator has seen nodes from all possible /16 domains, the internal table contains 5656 extended selections with 21 nodes each, and the internal table won t grow any further. 14