Abstract
The internet community is quickly changing and evolving as more of the world comes on-line. Encryption only conceals information that is being said but not who is talking to whom. Compromised computers on the internet will be able to track all communication passing through it. This information alone can be used to one's advantage or disadvantage. Now a day's onion routing an infrastructure for private communication over a public network and crowds, a mix based system for anonymous communication are most commonly used for anonymous communication. In this paper the working and performances of Onion routing and crowds will be compared and offer an insight will be provided as to which of these will provide better anonymous communication.
1.Introduction
The use of internet is growing very rapidly and so does cyber criminals. There are many kinds of businesses or activities that have to depend on internet for their daily transactions. During these transactions there is a need to give out the personal information. Users have to be very careful while revealing their information because it is possible for the observer to track online transaction and grab all the personal information required. Due to these threats reliable communication on the internet is very desirable. Even if the message if encrypted, the eavesdroppers can gather information about the IP addresses of the sender and receivers systems. It is also possible to collect the information regarding the size of the message that is being exchanged and the time taken to exchange the message. Encryption does not completely provide privacy to the users.
Anonymous communications[12] prevents all these threats and are very useful when the users don't feel like revealing their identity. Onion routing and crowds are two of the anonymous protocols which allow anonymous communication between the sender and the receiver. This paper discusses how these tow anonymous protocols work and in which aspects can they provide anonymity and also the degree to which they can provide anonymity to the sender and the receiver. The features and the aspects in which these provide anonymity will be explained and compared in detailed, to get a better idea as to which of these two protocols is better.
2. Background Study
Crowds and Onion routing had undergone many research works. Crowds is designed by Aviel D. Rubin and Michael K. Reiter[13]. Crowds once introduced the concepts of the members or users blending into the crowd of computers. It is designed, to keep the communication among the users private by routing them randomly among similar users. However crowds have few drawbacks which were discussed by Reiter and Rubin[5] and Mattew K. Wright, Micah Adler and Brian Neil Levine in The Predecessor Attack: An Analysis of a Threat to Anonymous Communications Systems [14]. In 1998 an attack was discussed about the crowds in which powerful attackers can degrade the anonymity of a paper by Reiter and Rubin a similar attack was described by Syverson, et al 2000 for Onion routing.
Onion routing was developed by Michael G. Reed, Paul F. Syverson, and David M. Goldschlag[15]. Later Tor[16] an implementation of the onion routing was developed, which works by relaying all the communications on a network of systems. An IO-automata model for onion routing was discussed by Joan Feigenbaum, Aaron Johnson, Paul Syverson in "A model of onion routing with provable anonymity". Many works were done on working of onion routing and crowds and the issues related to providing anonymity by these protocols. This paper mainly focuses to distinguish the issues related to providing anonymity and the degree of anonymity provided by crowds and onion routing.
3.1 Working of CROWDS
Crowds are anonymous protocol which hides the source of the message. In the crowds network, the users collaborate together so that the request to the server could be made from any of the users in the crowds. Users who wish to remain anonymous runs a special proxy, to strip information and a jondo[5], by which the users are represented on their computers. The initiator of the request knows the symmetric key that exists between the initiator and every jondo. The proxy creates a connection to the local jondo for forwarding a request to it. The jondo on that machine forwards the request to another jondo , which is randomly selected by the hip-hop process. Generally a jondo will have no idea about the initiator of the request. For transmitting the request, the initiator sends a packet containing a random path id and the IP address of the responder and then the request is encrypted using a key which is shared by the next selected jondo. The users receiving the path with new id decides whether to send the request to the next selected jondo or to the responder based on the probability of forwarding. When the packet of the request reaches the responder, it gives a reply and the reply packet is send to the initiator in the same path. In order to have an uninterrupted communication between the jondos, coordination is required between them. This coordination will be provided by the blender, which is a single server responsible for the management of the users.
CROWDS SERVERS
1
1
2
4
3
2
2
4
5
3
5
Fig 1 Path in crowds
The user starts the jondo on a local machine[3]e. An automatic procedure is triggered then so that the local jondo is informed about the current members in the crowds and vice versa. Of this process is successful, then the newly joined jondo can send request to the web servers and its identity is not revealed either to the sever or to the other members. In crowds, each request is transmitted from the user's browser to the final server through the jondos. To assign the next jondo for the path, the jondos will have a set which contains list of all jondos including itself, the jondo will select one of the jondos in the set randomly order. Figure 1 explains how the path is taken and for the figure the paths taken are 1 -> 4 -> server, 2 ->4 -> 5 -> sever, 3 -> 5 -> server, 5 -> 2 -> 3 -> 4 -> server. In the crowds protocol the request will not be changed during all the hops of the path, so the jondos will not know whether its predecessor jondo initiated the request or just forwarded it. Subsequent requests generated by the same jondo follow the same path and the server's reply is forwarded along the same path in the reverse. When the originating jondo received the message the information is delivered to the browser. The path will be modified only if the jondos fail or if new jondos join the group.
3.2 Working of Onion Routing
The onion routing network is connected through a series of proxies. These proxies communicate with the encrypted channels, which will transmit the request to the responder. A series of encrypted layer contain the request, these layers are stripped away along the path to the responders at the proxies. The initiator of the request sends the request by selecting a path via the other onion routers to the responder. Along the path, for each onion router a layer of connection setup packet, which have IP address and the encryption key of the next onion router is built by the initiator. The inner layer contains the data and the responder id[2]. All the outer layers have to be decrypt for reaching the data and the responder's id. As each router gets the packet, it strips away a layer from the onion by decrypting it with its key. Decrypting the layer will uncover the routing instructions for that router and the encrypted instructions for the rest of the routers in the path. When the packet leaves the router, it strips away a layer using its symmetric key, so that it is not recognizable as the same packet. The last router strips away the last layer and forwards the packet to the responder. The initiator requests are forwarded along the same route of onion routers. The initiator must generate a respond onion and forward it along with the request. The responder stores the reply in this onion and encrypts it. The response is send to the last router along the route, which will forward the data in the same path in the reverse order to the initiator.
C
B
ASecure web
X
Receiver/ ResponderX is the routing node/proxy
EControlled by secure web
D
Sender
---- proxy/onion router ---Anonymous connect from X to E
---- onion router ----Encrypted connection
Fig 2. Onion Routing Network
Anonymous connections that are built through onion routing are mixes [4]. Mixes are more like a store and forward machines, which accepts a constant length messages from various sources. After receiving the messages, cryptographic transformations will be done on them and then will be forwarded to the next destination. Bit patterns or the size of the messages will be used by the mixes to track that message. Since routing takes place among large number of mixes in the networks, identifying the sender and the receiver is challenging. The messages could be stored for vague amount of time waiting for enough messages to mix together by the mixes. Core onion router is developed to forward the data in real time, which checks mixing. Large amount of traffic will be able to advance the protection of real time mixes.
3.3 Anonymity in Crowds Versus Anonymity in Onion Routing
In crowds, the last request to the final sever is not encrypted other than that all the others are encrypted. So, if the eavesdropper is able to view any message, they can only view a message that is transmitted to the final server if the user's jondo submits the user's request. A local eavesdropper will be able to eavesdrop only on the messages send or received by the final sever. The probability that the user's jondo submits the request is 1/r[6] where r is the size of the crowds network when the path was created for the transmission of request, so the probability that a eavesdropper can identify the receiver decreases as the size of the crowds increases. However growth of the size of the path, do not have any effect on the assurance of the anonymity against the final server. The anonymity of the receiver, i.e., the web server is not possible if the final sever is the attacker. However the path initiator's anonymity is strong. Since the path initiator initially sends to another jondo when creating its route, the final sever can receive the initiator request from any of the crowd members. That is, to the final sever, all the crowd members are equally likely to have generated a request, so the senders anonymity is guaranteed.
Each and every jondo observes plaintext traffic on a path routed through it, any such traffic and the address of the final sever is exposed to the corrupted collaborating jondos. These collaborators try to identify the member that initiated a path (by a non-collaborating member). Since all the other non- collaborating members are equally likely to be the initiator, the collaborating members cannot not suspect any of the members other that the one from which they immediately received, assuming that the content of the message have no information about the initiator. HTML pages can have URLs, which causes the user's browses to issue another request by itself when the page is retrieved. It is due to these requests timing attacks may occur through collaborating jondos. The initial collaborating jondo on the path can time the period until it receives the request when a web page containing a URL that will automatically be retrieved is returned. If this time period is really short, then the collaborator's immediate predecessor in the initiator of the request. When the jondo receives a HTML reply either from the browser of t a user or submitted directly to the final server, the HTML page is parsed to observe all URLs that the browser of an user will request[5]. The last jondo on the route request these URLs and returns them on the same route on which the original request was received. Upon receiving the requests for these URLs by the user's browser, the user's jondo waits for the contents of the URLs to arrive on the path and then feeds them to the browser. Thus, no other jondos on the route will be able to see the requests that were made by the browser and so they cannot get the timing information.
The use of mixes helps Onion routing to achieve protection on part of trace back attacks[7]. Trace back attacks are threats in which the path from the responder to the sender can be identified by an attacker. The attacker usually attacks a known responder. The trace back attack can be divided into active and passive trace back attacks. In active trace back attacks, the attacker will be able to trace back the origin of packets which are travelling. Attackers in passive attack could collect data about the routing properties of the protocol, which will allow the attacker to identify the sender. Onion routing provides effective protection over active trace back attack because of the mixes. As the proxy servers of the network knows where its previous and next servers are in the path, it is almost impossible for the malicious collaborator to detect the sender of the request. The first onion router of the hosts will have all the information about the senders, so if this router is infected, all the senders which use this router will be identified by the attacker. In order to avoid this, the sender will be given a chance to select the whole path, so that it can avoid all the malicious proxies.
Onion Routing have cryptography which will avoid eavesdroppers[8]. The anonymity of the sender, responder and the data will be at risk only if the packets are tracked in the path from sender to responder. All the onion routers in the path have to mutually cooperate with each other as it is only the last onion router, which has all the information about the responder. The content and the length of the request that is being transmitted in the path can also be observed, which will allow the attacker to combine the path with specific client and server pair. Since onion routing has encryption, this type of attack can be avoided. Tables 1 will show how effective these two protocols are in terms of performances to the users.
Other Issues
Onion routing
Crowds
Reliability
More reliable
Less reliable than onion routing
performance
Satisfactory
Satisfactory
Overhead latencies
Satisfactory
Better than onion routing
Connection
High level anonymity
High level anonymity
Data anonymity
Provides high anonymity
Medium anonymity
Usability
Very hard to use
Better than Onion routing
Table 1: Onion routing vs Crowds
3.4 Measuring the Anonymity
3.4.1. Crowds
For the measurement of the degree of probability that crowds can take malicious collaborators, let X be the number of the users in the crowd network, Y the number of collaborators, be the probability for forwarding the message and be the probability of the jondo i, by the attacker. The entropy is (X-Y). The probability given to the predecessor[10] of the initial collaborator in the route is = = 1-. The probabilities that are given to the malicious collaborators is zero and if the attackers knows nothing about the remaining non-collaborators, then the probabilities that are given to those users are = = , Y+2 . Therefore, the entropy of the system after being attacked is, H(O) = [] + [].
The degree of anonymity can be defined as 1-[10] where is the probability that is given to the member in the crowd network for being the sender by the attacker. For = 75/100, the number of collaborating members that a system can take is Y. There is still a chance for the message to be sent to the receiver only through the honest jondos, in this case the probability is
= (1 - ) ) pwr i = . The attacker will give all the non-collaborators the same probability, = 1/(X-Y) and the degree of anonymity is one.
3.4.2. Onion Routing
For the measurement of the anonymity of onion routing, let us consider two scenarios, they are, let attacker controls a parts of the anonymity set and knows the possible senders and the other is attacker controls a set of onion routers and terminates a set of members. Let X be the number of users in the onion routing network, the entropy for these users is =X. The attacker can get a part of the anonymity set, which have the possible senders in it. The size of the part of this anonymity set is A where 1. If attacker is not able to give probabilities to the members who correspond of this part, then = 1/A, 1; = 0, A+1 . Thus the degree of anonymity and the entropy the attack are, H(N) = (A) and degree of anonymity(d) = =
If (X-A) is compared to the number of collaborators Y in the crowds, it appears like Onion routing is more tolerant against failing the members than the crowds. This is due to the rest of the non-collaborators have equal probability in Onion routing where as in the crowds one jondo will have a larger probability then the rest of the jondos.
4. Results
By analyzing the methods discussed above it is obvious that Onion routing is more resistant to traffic analysis than the Crowds for internet communications, whereas crowds work better than the onion routing while considering the bandwidth. Minimizing the overhead can be performed better using crowds. Table 2 gives a brief idea about the efficiency of both the protocols. After analyzing the table and the measurement of anonymity of the two protocols, I think that Onion routing performs better in providing overall anonymity to the member. Onion routing is more general than the crowds networks both in designing the goals required of anonymity and applications. But the main drawback of Onion routing is, it is difficult to use and the users must be familiar with it, in order to use it efficiently.
Threats
Crowds
Onion routing
Timing attacks
Provides Protection
Provides Protection
Eavesdroppers
Satisfactory protection
Strongly protection
Active trace back attack
Provides protection
Strong protection
Passive trace back attack
No protection provided
No protection provided
Malicious Collaborators
Satisfactory protection
Strong protection
Message coding
Strong Protection
Satisfactory protection
Cookies
Provides Protection
Provides protection
Table 2: Crowds vs Onion Routing in threats
Analysis Of Results:
Conclusion and Further Study
The working and performance of Crowds and Onion routing were discussed. Anonymity in both the protocols is compared and accordingly results were obtained.
