D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication

Title: ANONYMISATION SERVICES

The basics of anonymisation and related protocols are described within the FIDIS Deliverable D13.1 “Identity and impact of privacy enhancing technologies” (Cvrček, Matyáš 2007). Therefore we will concentrate in this deliverable on existing services offered to the public to anonymise the Internet usage of normal users, i.e., for example to allow them to browse the web anonymously. 

In general one can distinguish between high latency and low latency anonymisation services. Thereby the terms “high latency” and “low latency” reflect the maximum tolerable latency from an application point of view to offer a reasonable level of quality of service to the user. A typical application for a high latency anonymisation service is e-mail communication whilst the most prominent area of application for low latency anonymisation services is browsing the web. 

Mixminion (Danezis, Dingledine, Mathewson 2003) is an example of a high latency anonymisation service, whereas AN.ON (Berthold, Federrath, Köpsell 2001) and Tor (Dingledine, Mathewson, Syverson 2004) are examples for low latency anonymisation services. AN.ON has been developed in Germany by the Dresden, University of Technology (TUD) in cooperation with the University of Regensburg and the Independent Centre for Privacy Protection (ICPP) Schleswig-Holstein. Tor has its roots in the Free Haven Project and the U.S. Naval Research Laboratory, while it now gets supported by the Electronic Frontier Foundation.

Figure : Basic principle of Mixes

All three services are based on the ideas of Mixes invented by David Chaum in the early 1980s (Chaum 1981). The basic idea – see Figure 20 – is to redirect the messages sent from a sender to the recipient through servers (which are called Mixes) on the Internet instead of sending them directly from the sender to the recipient. At each hop their coding changes. As the messages from multiple senders and recipients are “mixed” together an attacker who observes (all) the network links can only learn which set of senders communicates with which set of recipients but does not learn who is communicating with whom. This is an important property as anonymisation does not offer the users (and respectively his machine) a “magic hat” which makes him invisible within the network. Anonymisation just hides communication relations on the network.

Besides the general idea of redirecting the data traffic through servers, additional measures are necessary to reach this goal against even strong attackers who are able to listen on many (all) network links and to control parts of the anonymisation services (e.g., through operating or corrupting Mixes) and its users. In substance the following additional measures are necessary:

1. Message padding: each message sent through the anonymisation service is sliced and padded into fixed size packets (also called cells). This ensures that the attacker cannot link incoming and outgoing message just by looking at the message sizes.

2. Message recoding: each message (or more precisely: each packet / cell) is recoded by each mix. This ensures that the attacker cannot link incoming and outgoing messages just by analysing the bit patterns of them. This recoding is usually done by means of cryptography. The sender encrypts the message multiple times. For each layer of encryption he uses the encryption key of a different Mix of the path of Mixes from the sender to the recipient. If a Mix receives a message, it decrypts it using its secret decryption key. This way the Mix removes one layer of encryption. This will lead to a complete new bit pattern of the decrypted message. Thus an attacker would not be able to link incoming and outgoing messages after the decryption step done by the Mix.

3. Message buffering: messages arriving at a Mix need to be delayed, otherwise an attacker could easily correlate incoming and outgoing messages just by looking at the timing of the receive/send events of a given message. How the buffering is done depends on the type of Mix. In general one can distinguish between Batch- and Poolmixes. A Batchmix collects n messages from n different senders before it forwards them all at once. Whereas a Poolmix has an internal pool (buffer) of stored messages. Every time a message arrives, it selects one or more messages from its message pool and forwards them. There exist several strategies of exactly how the messages are chosen (e.g., just randomly).

4. Message reordering: the order of messages needs to be changed by the Mix, otherwise (e.g., if the Mix would work in a “first-in-first-out mode) an attacker could easily link outgoing to incoming messages. Different reordering strategies exist. One could either permute the messages randomly or sort them according to their bit pattern after decryption.

Note that not all anonymisation services implement all these measures. Especially the low latency systems do not implement a buffering strategy as the buffering might introduce an additional delay which would lead to an overall delay above the allowed maximum for offering an appropriated level of quality of service from an applications point of view. 

Figure : AN.ON architecture

One of the main differences between AN.ON and Tor is the topology of the overlay network spanned by the Mixes. AN.ON uses fixed chains of Mixes called cascades. The user can choose which cascade he wants to use but cannot select each single Mix. The Tor system uses free routes meaning that the user can freely select which Mixes he wants to have on his path from the sender to the recipient. Both concepts have their advantages and disadvantages as discussed in (Cvrček, Matyáš 2007) and in (Böhme et al. 2004). The general problem is that the user has to choose very carefully the Mixes (cascade) he wants to use. If all Mixes on his path are corrupt (e.g., working together with the attacker) all activities of the user can be deanonymised. To support the user in making an informed decision the anonymisation services offer a lookup service with information about the available Mixes (and cascades). Within the AN.ON system this service is called “InfoService”, in Mixminion and Tor it is named “Directory Service”. Besides static information like operator, location and software version of a Mix, dynamic information regarding the current number of users, the up-time and reliability as well as the traffic situation of the anonymisation network can also be queried. The architecture of AN.ON is shown in Figure 21.

In order to use one of the mentioned anonymisation services, the user has to install a client. This client software is called “Onion Proxy” in Tor and “JAP” in AN.ON (cf. Figure 22). Furthermore he has to reconfigure the applications (e.g., web browser, e-mail software, etc.) to use the installed client as a local proxy for accessing the network. This means that all network traffic is sent to the client instead of the recipient. The client is responsible for pre-processing the data according to the anonymisation protocol (e.g., for padding and encrypting the data etc.) and sends them to the first Mix in the chain of Mixes chosen by the user. The client also receives the data from the Mix and transforms it back to plaintext understandable by the application. 

Figure : User interface of JAP

Tor, AN.ON and Mixminion are results of research projects and are under active development. They have not by far reached the desired level of protection (e.g., anonymisation even against strong attackers). The research in the field of privacy enhancing technologies has lead to many new attacks on anonymous communication which are at the moment not addressed by the mentioned anonymisation services. Nevertheless (depending on the attacker model and the individual protection goals of the users) we can greatly enhance the level of privacy protection of today’s Internet.  

AN.ON and Tor have a growing user base (roughly estimated at 50,000 users per system). One of the problems of the anonymisation services is that the Mixes are operated by volunteers. Although it allows the service to be offered to the public free of charge, it has the drawback that one has to find volunteer Mix operators and that the anonymisation services cannot give any guarantees with respect to the offered quality of service (e.g., in terms of bandwidth, latency, availability, etc.).  

Therefore the AN.ON project recently started to “experiment” with commercialisation of their anonymisation service. The first attempt (started in 1999) to offer a commercial anonymisation service which offers a high level of protection was done by the Canadian company Zeroknowledge Inc. But their “Freedom” service ran out of business (in 2002) as (according to Zeroknowledge Inc.) they could not attract enough users willing to pay for anonymisation. Whether or not the recent commercialisation attempt of the AN.ON project will succeed in filling a market niche, cannot be predicted at the moment. On the one side, more Internet users seem to be aware of the privacy problems related to the Internet, and also the operational costs are lower compared to 2000 (e.g., rent of servers and bandwidth). But on the other side, the legal framework becomes much more complex, especially the European Directive on Data Retention and the uncertainties with respect to liability issues (e.g., in terms of misuse of the anonymisation service) makes the operation of Mixes risky. In general, one can say that five years ago the costs for servers and data traffic were the most hindering issues for (voluntarily) operating a Mix, whereas today the legal uncertainties are the major obstacles.