Chapter 1: Introduction

Chapter 2: Literature Review

2.3. TOR Network

2.3.1. History of TOR

TOR was originally designed and prototyped by Sun Solaris and have been since implemented as part of web browsing application in order to provide secure remote login and sanitising users’ data while transmitting it through internet. The idea of Onion Routing was mainly inspired from the work of David Chaum (Haraty & Zantout, 2014). Nevertheless, several enhancements were introduced by F. Syverson, D. Goldschlag and M. Reeds when the project was adopted, In 1995, by the US army Naval Research Laboratory (Syverson et al., 1997) as the future anonymous communication platform allowing MoD staff to use Internet while remaining anonymous alongside with preventing enemies from performing traffic analysis and eavesdropping of the associated traffic. The Onion Routing (TOR) took place as the name of the platform and research went to life and started the implementation of almost hundred router (node) placed in different locations (corporations, government departments and offices, and academic institutions) and the project was allocated a significant attention of internet security community within the MoD and US government in general.

In 1997, the project received official funding from the famous US Department of Defence Advanced Research Projects Agency (DARPA) and was classified as a High Confidence Program. Furthermore, improvement efforts and research works were introduced to the initial implementation especially the routing and encryption algorithm and the network was running with an average 50,000 use per day and reached a peak of 84,022 simultaneous connections at the end of 1998 (Haraty et al., 2014).

During the period between 1999 and 2002, the project suffered from the absence of funding and support and was abandoned on 2002. Nevertheless, in 2004, and after the project was resumed by a group of volunteers named just after TOR project, TOR won the Edison Invention Award, and shortly after the first generation of the code was officially dropped to leave the place to the second-generation onion routing. To this date, the project are funded by volunteers across the world and users’ donation and it is still under development and constitute the largest network testing platform in the world relying on almost six thousand dedicated routers located worldwide and generating a bandwidth capacity of almost 200 Gb/s (Figure 1) of bidirectional data streams (Dingledine et al., 2014).

Later in 2012, a third-generation of TOR was deployed and took the place of the first one, several new functionalities were added in order to maintain the efficiency of the solution which faced hard time especially with some weaknesses revealed due to the exploits against MD5 hashing which was replaced by SHA256, DES symmetric encryption which was replaced by AES128 (Danezis et al., 2010). The sudden increase of the computing power and parallel processing was also a big issue for TOR's cryptanalysis resistance. The new version was improved by adding a revolutionary protocols and functions such as: the new Forward Secrecy protocol, new shipping protocol in which several TCP packets can share the same circuit, introduce Leaky-pipe circuit topology and a new Congestion control, new dynamic exit policies, source-to-destination integrity checking and hiding the used services. Some existing function were removed such as mixing, padding, and traffic shaping where some others were modified like the Separation of "protocol cleaning" from anonymity protocol (Dingledine et al., 2014). In UK, it is estimated that a couple of thousands of users are using TOR on regular basis (Figure 2) for different purposes varying from legitimate protection (activist, politics and journalist) to illegal activities (cyber-criminals, terrorists, hackers).

2.3.2. About TOR:

TOR network is the most famous and widely used low-latency anonymity platform, it relies on multi-layer encryption in form of onion and special routing concepts (Reed et al., 1998) to achieve anonymity. Today, the network consists of about 6000 routers operated (run) by volunteers across the world (Tor Project, 2016) which are called Onion Routers. Each OR is a part of one or more routing path called Circuits and identified by its contact information (IP address, ID, public keys, geographic location and other functional parameters). All these information is stored into an independent directory authorities (DA) which is responsible of the network consensus and control the network with a minimum information requirement. Onion Proxy (OP) downloads from the DA the consensus documents and the descriptors and use it to establish communication circuits through TOR network before to reach their Internet destinations. Currently, each TOR circuit is composed from three nodes (ORs): Entry guard OR, Middle OR, and Exit OR and traffic is transiting throughout the network in form of fixed-size unites called Cells.

Figure 3. TOR traffic and activity across the world (TOR Flow, 2016).

Figure 3. TOR traffic and activity across the world (TOR Flow, 2016).

The following graph shows the number of running ORs that have had certain flags assigned by the directory authorities. These flags indicate that a relay should be preferred for either Entry (Guard) or Exit positions. Moreover it show the status of the relays especially those with high-bandwidth (Fast) or long-lived (Stable or Trusted).

Figure 4. TOR router types and status evolution across time (TOR Project, 2016).Research on TOR:.

Figure 4. TOR router types and status evolution across time (TOR Project, 2016).Research on TOR:.

TOR is a project under active and continuous development process operated by a wide research community which is completely separate from the volunteers who are running the network. Nevertheless, the two community works closely in several cases such as development implementation, testing, security and performance analysis. Because of the popularity and wide use of the Tor network, several academic and industry people are getting more and more interested and carrying developments or performing research on and about TOR, frequently these researches topics include attacking passively or actively TOR platform or users. On the other hand on, works on anonymity enhancement, performance improvements or flexibility and scalability of the Tor network remain very limited.

During the last three years the research community has taken the challenge to improve the TOR security and performance more seriously especially after the so called “post-Snowden era” (Madden, 2014). Researchers proposed several enhancements which all contribute on the improvement of TOR (AlSabah & Goldberg, 2015). Those proposals covered different areas such as congestion, scalability, routing, and security. Nevertheless, the most urgent challenges which TOR is facing could be divided into three major domains:

-

As TOR is relying on an aging (componential breakable) encryption and integrity mechanisms for which global adversaries are or will soon be able and capable of compromising. Thus, the existing pretended cryptology guarantee such as onion construction (wrapping ciphers), keys exchange protocols and the integrity and authentication checks mechanisms should be reviewed.

-

The delays caused by the congestion on the network and also by the heavyweight encryption and decryption.

-

The identification of TOR user through internet and traffic analysis which leads usually to linking several intercepted communication to involved parties or linking multiple communications to a single user (Nia et al., 2014).

Several academic research works are currently carried out aiming to improving the TOR network. This formal approach was initiate by Backes et al. (2012) tackling for the first time in a formal way the security of TOR and proposing some solution for onion construction (wrapping) and key exchange protocols such as the 1-WAKE.

Regarding TOR circuits selection algorithm, research have tackled the vulnerabilities associated to the first generation of TOR circuit construction and selection algorithms, they ended by proposing (have been now implemented and applied into TOR) the concept of controlled selection Guard ORs and bandwidth/uptime caps (AlSabah & Goldberg, 2013b). Meanwhile, a particularly interesting research carried by Snader and Borisov (2012) in which they proposed two major enhancements; Firstly, they recommended after experimenting that bandwidth value which will be used for selecting the circuit should be measured centrally by the directory server using opportunistically sampling function rather than getting this value from ORs by allowing them to report their own capacity which could be misleading. Secondly, they propose a routing function to be integrated into the circuit selection algorithm which weights faster ORs more heavily but leave the user the choice between secure anonymity and performance.

Nia et al. (2014) proposed a novel anti-detection mechanism which used a function inside the crypto-system for data pattern generation and timely propagate the streams of data. Despite the effectiveness of the proposed system, it present some difficulties in its implementation on the real world TOR and thus an eventual implementation could lead to radical changes on TOR which is risky. On the same year, Haraty and Zantout (2014) had presented TOR cryptosystem and detailed the operating principles and features. They had presented some thread that are facing the Second Generation Onion Routing without giving any solution or proposing an improvement. Also the ultimate aims were the resistance to traffic analysis, and better hiding the users’ identities. However, since first and second generation TOR system relied on slow encryption mechanism and vulnerable routing and circuit establishment functions for which global adversaries possessing adequate resources was able to compromise and thus confidentiality, integrity and authenticity of data might be threaten.

Recently, a work carried out by Lee et al. (2015) tackled the existing TOR weaknesses especially those related to selecting the routing path for cells’ shipping and the risk of fake intermediate and exit nodes and proposed a mitigation policy which was not implemented. AlSabah and Goldberg (2015) in their work entitled “Performance and Security Improvements for Tor” presented a state of current research directions focusing on the Tor network. They gathered in one paper almost all the TOR known design weaknesses and security flaws and improvement challenges facing TOR and enumerates the currently unresolved issues. However, the paper neglected two key points related to TOR: the multi- layers encryption challenges and the delays which is facing the real world TOR user.

On the mathematic and cryptographic side, only few research tackled the issue of proving the security of TOR’s protocols and mechanism. A notable work carried out by Backes et al. (2012) entitled “Provably Secure and Practical Onion Routing” demonstrated the security and efficiency of TOR cryptosystem by elaborating formal framework for TOR. The work was considerably rich in content and divided into two parts: in the first part they introduced a cryptographic definition of global function behind TOR called the forward secrecy which was described as the optimal and perfect "in theory" to be implemented in the real-world TOR along with the One Way Key Exchange (1WAKE) Protocol used for the anonym authentication and Onion construction algorithm. The second part of their work was about proposing some improvements in the existing TOR integrity mechanism and also introducing new way of performing onion encryption into the CTR mode. However, this work neglected some primordial aspects related to TOR real world implementation flexibility and the overall efficiency. Backes et al. (2012) research remain to date the only formal and theoretical TOR analysis and the algorithms and functions introduced were mathematically and cryptographically proved which will increase the TOR network reliability among the academic society and constitute a reference for further research.

Chapter 3: Investigating current TOR Deployment

3.1. Current TOR deployment

In this section, an introduction of TOR’s main components and the current generation functioning principle, capabilities and limits will be provided along with a special focus on: onion encryption, circuits’ construction and selection, security and overall performances.

3.1.1. TOR main components

TOR is a complex modular system composed from several sub-systems working together, Figure 5 illustrates the four basic components of TOR as follow:

a)

TOR Proxies TP (also called Client)

Every TOR client runs a piece of software locally known as onion proxy (OP) which work as a link between the local machine and the TOR network and represent the client part of the anonymity system.

In

b)

Destination Server

The TCP/UDP applications like a web service and is the second part into the anonymous communication with the client.

c)

Onion Routers (Nodes)

ORs are dedicated software routers run by volunteers across the world which the work is to ship packets from client to destination. In TOR, the standard Transport Layer Security protocol (TLS) is used to ensure connection between ORs. The data is packed into equal-sized packets called “Cells”

d)

Certification and Directory servers

The most important TOR components which hold almost all information about ORs, Circuits IDs, Network Status and Performances and other information which will be detailed later in this work.

Figure 5. the TOR main components and overall architecture.

Figure 5. the TOR main components and overall architecture.

3.1.2. TOR communication mean

TOR uses fixed size cells of 512 bytes each to communicate internally and route the data from the client to the destination. TOR Cell is an abstraction of the normal internet transport protocols Datagrams format, it is constituted from two part:

a)

Cell Header

Have a size of 3 bytes, this part of the cell is never encrypted for transmission inside the TOR network in order to allow ORs in the circuit to access to the content.

b)

Cell Data

Have a size of 509 bytes which constitute the transported data. This part of cell is always encrypted and only the next OR in the circuit have the decryption key and can decrypt it to gain access to the required original content or address. Nevertheless, the data part is, in reality, constituted from six parts as shown in the Figure 6. Further details about the commands and other fields will be detailed later in the next chapter.

On the other hand, At the TCP/IP network level the TOR’s Cells are embedded into TCP/IP packets. Therefore, having a fixed size cell will generate fixed size packets which is better for the camouflage of the exchanges. Alongside with the actual data, cells contain TOR system instructions for managing the network such as initiating new connection (circuits) or transmitting commands to other TOR parts. Figure 7 illustrates the use of TOR cell with the TCP/IP packets.

3.2. TOR working principle:

Considering the complexity TOR routing and crypto-system, investigating and understanding the current network design and implementation is essential before proceeding to proposing improvement and enhancement. This section aims to define the TOR structure and different protocols, mechanism or system used by TOR.

3.2.1. Acquiring, connecting and establishing circuit on TOR

After downloading a TOR browser which is done on the client side from the TOR project official website, a checksum is performed to check the downloaded application integrity and ensure that it has not been maliciously edited or tampered. Then, the client can then install TOR browser version depending on variant OS platform and thus establishing the OP (Onion Proxy). Later on, and after initialization the TOR client establish the first connection with TOR and acquire the TOR directories and needed data. This first connection is always done through the ORs called Bridges which are more than just simple ORs but they are set to accept new clients’ first connections requests as they constitute a trusted ORs as they are secured and maintained by TOR team. After establishing the initial contact with one of the five management ORs, the OP performs the specific handshake steps required before connecting. Once the connection to the bridge (Guard OR) established, the OP will communicate the outcome to the one of the five directory node guaranteeing the services management again. The object of this connection is the construction of the circuit by selecting the involved three ORs and the order.

Figure 8. different steps for a user to get connected to a TOR.

Figure 8. different steps for a user to get connected to a TOR.

3.2.2. Selecting and Creating a Circuit on TOR

To communicate with applications, the TOR cells need to be routed through a pre-selected ordered suit of ORs picked from a local cached directory (TOR Proxy) which is downloaded from TOR directory server. The suit of ORs is constituted from three ORs called circuit (or path) where the number of the OR is denoted as path length. The current use a circuit length of three. The circuit of three ORs is composed from: Entry-Guard Node (OR1), Intermediate Node (OR2) and Exit Node (OR3). The circuit selection should follow certain rules as the OR3 should possess the capabilities and information to execute the exit policy suggested for the TCP stream from the sender. Once the circuits selected by the client, it launches the procedure creating them over the selected circuit by performing one connection at a time. Figure 9 illustrates the TOR circuit creation and connection procedure.

3.3. Cryptography over TOR

The TOR conception allows each OR to relay data in form of Cells from senders to recipients or the inverses via the ORs which do not have a full access to the content (data) or even the entire path travelled or being travelled (routing circuit) inside the TOR or the initial source of cells captured before reaching their destination. This ultimate feature is achieved by the TOR cell combined encapsulation and multi-layered encryption mechanism called onion construction, during which each encrypted several time using the circuit ORs secret key order and sent throughout the TOR network. Cell is then decrypted locally at the corresponding ORs which are the only able (following the pre-defined order) to reveal by decrypting (unwrapping) the identity of the next OR/ the final destination address after un- wrapping (decrypting) one layer of the cell (Fu &Ling, 2009).

To illustrate the TOR working principle, we consider the case of client downloading anonymously a file from a server. This example illustrates the complete process starting by establishing connection with a TOR bridge, communicating with the server via Tor passing through a circuit and reaching the destination for downloading the file as follow:

-

The OP requires an Internet connection in order to able of establishing communication with the TOR network (DA),

-

TOR Browser downloads the information known as consensus list which include the available bridges which will be used to initiating the routing circuit establishment.

-

TOR establish the connection with the bridge (guard OR), using a specific handshake take place allowing the TOR directory server to authenticate itself to the client. In this phase a specific One-Way Key Exchange Authentication protocol named TAP (TOR authentication protocol) is used, this protocol is the spirit of the anonymity as it allow an authentication without asking for the client identity,

-

TOR client broadcast a request of creating a circuit to all live (working) ORs on the list provided by the DA and select the ones to be part of the circuit in a predefined order following the selection algorithm.

-

TOR client contacts the selected ORs which are part of the circuit is a secure manner to confirm the circuit and exchange keys.

After establishing the connection, initialising the browser and selecting the ORs constituting the circuit, the network information is updated on OP from the DA which transmit it on encrypted way so that the remaining ORs does ignore the ORs participating in the circuit. Thus, any OR only knows the directly linked two segments of the path; preceding OR which the cell come from, and the next OR which the cell will be forwarded to. This procedure is ensured as follows (Figure 10):

-

The OP establishes a secure TLS link with the Entry (Guard) router called also bridge (OR1) using Create Cell C1 on an encrypted way using RSA and K1. The OP receive the confirmation from the OR1,

-

To establish the remaining part of the circuit (two remaining ORs), the OP continues on the same method by passing though OR1. In fact, The OP establishes another secure TLS encrypted link with the second router (OR2) through OR1 using Create Cell C2 in encrypted way using RSA and K2. The OP receive the confirmation of link establishment from the OR2 via OR1.

-

After a successful link establishment with OR2, the OP establishes the third link with the Exit router OR3 passing via OR1 and OR2 which establish the TLS encrypted link using RSA and K3. It is important to highlight that the links establishment procedure guarantee the forward secrecy (each OR is only knows the predecessor OR/client and the next OR/destination).

Figure 10. the TOR Circuit establishment and credentials exchange process (Boyd, 2011).

Figure 10. the TOR Circuit establishment and credentials exchange process (Boyd, 2011).

The above diagram illustrates in details the procedure of establishing a TOR circuit. In fact, TOR utilizes plenty of modern cryptography concept (algorithm, function and procedure), it first rely on public key cryptography to secure the data exchange when establishing the links between client and ORs, in this phase the information is transmitted in encrypted way using the receiver public key so the intended receiver is the only entity able of decrypting it (the only to know its private key). Moreover, TOR use heavily symmetric cryptography during both the circuit establishment and data transmission, it mainly uses the Advanced Encryption Standard (AES) algorithm. Other cryptographic concept such hashing and digital signature are also used to guarantee the data integrity, authenticity and non- repudiation on TOR (Fu &Ling, 2009).

3.4. Encapsulation and multi-layer encryption

TOR cryptosystem and encapsulation works as it is showed in the diagram. When TOR client needs to connect to TOR it start by establishing a secure connection tunnel with the Guard OR, it sends a Create_Cell to OR1 encrypted using RSA public key of OR1, so OR1 is the only able to decrypt and exploit it. The two remaining segment of the circuit will be built on the same way as the first segment.

Later after the circuit is built, the data being sent to ORs will be encrypted using a symmetric AES encryption which is more performance and efficient when it comes to big or sequential data transmission. TOR utilises AES with a key of 128 bits in CBC mode. In the latest version of TOR, the AES in a stream way with a key of 128 bits in counter mode (CTR) with an initialisation vector (IV) of 0 bytes.

Figure 11. TOR data multi-layer encryption and encapsulation functioning.

Figure 11. TOR data multi-layer encryption and encapsulation functioning.

When the Cells are being transmitted from the client to a destination through TOR, the packets, data is transported in form of Cells (509 bytes each) which are encrypted three times in an ordered way using the routing circuit ORs keys. The Cells are later routed though the ORs and each OR un-wrap (remove) one layer of the encryption to gain access to the address and information of the third OR. At the third (exit) OR, the last layer is decrypted and the OR direct the encapsulated packets to the final destination. This last communication could be either encrypted or clear depending on the used service by the initial client and supported by the destination server. TOR cryptosystem is not involved into securing this segment of communication.

Figure 12. the un-wrapping mechanism across the TOR network.

Figure 12. the un-wrapping mechanism across the TOR network.

3.5. Performances and Congestion Management

TOR is a big network of several thousands of routers. Therefore, to be able of controlling and managing traffic on TOR, ORs are equipped with a capabilities of logging, assessing and reporting performance and link status to the TOR directory servers. The mechanisms used the control and limit the amount of data that enter a portion of the network as follows:

-

Real time link and traffic exchange: the ORs share in an real time basis the information about the network status and traffic proportion with the directories server, this information are used to determine the circuit and manage the congestion over TOR.

-

Rate limit: ORs use token bucket configurable function that help to limit the bandwidth which an OR can use on the network.

-

Circuit windows: TOR circuit relies on a flow control function which limit the quantity of data traveling through a circuit for a given duration. Both the OP and the Exit OR are responsible of maintaining that window which is usually initialised to the default value of 1000 Cells (500 KB). This is the maximum number of cells that OP and exit OR can send before an acknowledgment is received.

Figure 13. Time required to complete a download of 50KB on TOR (TOR Metrics, 2016).

Figure 13. Time required to complete a download of 50KB on TOR (TOR Metrics, 2016).

Figure 14. Time required to complete a download of 1MB on TOR (TOR Metrics, 2016).

Figure 14. Time required to complete a download of 1MB on TOR (TOR Metrics, 2016).

Figure 15. Time required to complete a download of 5 MB on TOR (TOR Metrics, 2016).

Figure 15. Time required to complete a download of 5 MB on TOR (TOR Metrics, 2016).

3.8. TOR limits and vulnerabilities:

Besides the success of the first generation of TOR as online anonymity solution, there were some bad times for the project where a lot of weaknesses and vulnerabilities were revealed to be covered or just exploited my malicious people, researcher or even some law enforcement agencies to actively attack some TOR users. In September 2007, Dan Egerstad, a Swedish researcher, found out that it is possible to capture a lot of sensitive information such as usernames and passwords for emails account though monitoring the data packets transmitted from TOR exit nodes (named later as Exit Node Attack), as at that time most of TCP/IP connections presented no encryption like SSL or TLS, the communications between the exit nodes and the final destinations were done in a clear manner (Schanck et al., 2015). Despite the fact that this attack did not compromised the TOR network overall security, it revealed in fact that the TOR is vulnerable to other type of attacks such as "Timing Attack", "Browser based attack", "traffic analysis attack" (Benmeziane et al, 2011).

As TOR gained in popularity, the list of enemies enlarged and the sophistication of attacked increased, where some attack aims to reveal TOR weaknesses to a later improvement. Others, mainly launched by TOR enemies are intending to compromise the netwok itself and de-anonimise users. There are obviously a several points of attacking TOR system. In this section, a summury of attack against TOR will be presented and discussing in extended detail. The reason of such focussing in the attack is because the proposed improvements aims to cover the vulnerability of TOR facing these attacks, and therefore, understanding the technology and the vulnerability used by each attack will help to address it propoerly. The attacks against TOR are categorised into the following categories:

3.8.1. Application Layer Attacks

These category of attack rely on feeding the TOR application with some data that causes bypassing the OP settings, expose/reveal user crucial information, or enable backdoors to exploit it. There are mainly three locations in wich this attack can be aunched (exit OR, middle OR, and final destination). A perfect example of this attack is the Exit OR spoofing and collecting data. This TOR vulnerability allows attcker to compromise non-https connections of TOR users. Another appplication layer attack related to the user itself is the Mozilla FireFox bundle attack (Zhang,

3.8.2. Intersection Attacks

Intersection attacks rely mainly on the successful correlation of several properties of a TOR user to achieve a matching between captured traffic and TOR user activity. This attack is particcularly accurate whan users use TOR in a slow, irregular (instable) connection speeds, in this case the remakable delays and poor performance information will significantly help the attacker to narrow it intersection work which could potentially lead to de-anonymise the targetted TOR users’ traffic (Schanck et al., 2015).

3.8.3. Traffic fingerprinting

AlSabah & Goldberg (2015) highlated that it is possible to fingerprinting TOR users. This type of attacks requires the control of the Entry OR on a TOR circuit. Since ORs part of the circuit are selected randomly, if an attacker establishs (connects) enough fake ORs into the Tor network, the chances are high that at least one of TOR users will choose a compromised OR as part of his circuuit in the Entry level. During the establishment of a circuit, ORs have to exchange a big amount of data back and forth. In fact, Wacek et al. (2013) proved that by simply observing and looking for special timing patterns in cells transiting in each direction through the compromised Entry OR, then with a help of a machine-learning algorithms it is possible to determine with 99% accuracy whether the circuit is being used for ordinary Web-browsing, introduction point circuit (establishing first connection), or a rendezvous-point circuit (refreash). Moreover, this atack is particualry dangerous as breaking TOR's encryption wasn't even required (Johnson et al., 2010).

3.8.4. Circuit Failure and Selection Attacks

During the circuit construction, the Entry (guard) ORs role is crucial and this was exploited by attacker who force the entry OR to actively fail circuit by not extending to the following ORs. If instead the attacker manage to compromise an Exit OR and divert the traffic through any middle OR, side channel or timming attack could be launched to compromisre the whole circuits having as Entry or Exit the compromised ORs. However, in case when the attacker continue to fail successive circuit extend for a determined duration the OR will be blacklisted by the DA and therefore underscored in term of reliability (Perry, 2007).

3.8.5. Timing Attacks

Time correlation is a advanced type of passive attacks which attempt by using information about connection time, and flow duration to correlate them to TOR users or connection via an Entry or Exit OR connection to an external internet address (Johnson et al., 2010). This type of attack can also be active when attackers inject their own timing patterns into the traffic. Several research studied and emonstrated that this attack can be extremely effective when the adversary possess the adequate computing power and ressources which remains crucial to bypass TOE's stream multiplexing strategy (Fu &Ling, 2009).

3.8.6. Path Selection Attacks

Several previous works have proved that it is possible to take advantage from the current TOR path selection algorithm flaws to develop efficient attacks. In fact, (Overlier & Syverson, 2006) proved mathematically and statistically that client who repeatedly generate fresh paths can becomes more vulnerable as attackers gain a higher probability of controlling both the Guard and Exist ORs into the selected circuit. Moreover, to compromise the anonymity of TOR users an attacker can inject enough compromised (fake) ORs which increase the probability that a connection start and end within compromised ORs, this attack is known as Sybil attack (Dahal et al., 2015). Moreover, a much more efficient attack variant was proposed by Ling et al., (2011) which exploited the traffic load-balancing algorithm based on ORs which assess and report on a real time base the bandwidth and transmit to the TOR directory server (Perry, 2007). The researcher demonstrated that, by artificially changing the advertised bandwidth of ORs, an attacker is able to compromise almost half of TOR traffic while controlling only 10% of the TOR network ORs. This attack was carried out recently by US researcher working with the FBI to de-anonymise successfully several TOR users accessing illegal drug selling website “silk road 2” and since that known as FBI attack.

Figure 18. TOR points of attacks (Perry, 2007).

Figure 18. TOR points of attacks (Perry, 2007).

TOR still present several vulnerabilities and potential points of attack, it is obvious that the system have no protection against global adversary who can control both end of the circuit which was later in 2015 known as FBI attack. A researcher had implemented in early 2015 an attack targeting initially the illegal drug market “silk road 2” in which the managed to introduce a number of fake ORs inside the TOR network taking advantage of their status of academic and research organisation and the available digital asset and computational power, they implemented then an attack which diverted a part of TOR legitimate and real traffic through a compromised entry and exit OR. Once having data transiting via 2 controlled OR out of 3. They launched a tinning and traffic correlation attack to determine the last OR of the circuit. At the end, researchers were able to de-anonymise several thousand of TOR users including a user suspected to be the manager of the drug market. This attack was mainly due to the unfair TOR circuit choosing and construction which leave the pseudo-random function the possibility of choosing a compromised Exit OR (Johnson et al., 2010). Moreover, the current TOR cryptosystem enable adversary who possess the computational power and technical deployment over internet to observe and intervene actively on some fraction of network traffic by deleting, replaying, modifying or forging fake network traffic over TOR could compromise some fraction of the ORs and therefore compromise some directory servers. In fact, this flaw is mainly due to the lack of node-to-node integrity check between TOR ORs which was initially scarified in favour of better multi-layer encryption performance which allow a more efficient TOR by reducing the delays caused by heavy-weight encryption.

Chapter 4: Proposed Improvements and Enhancements

4.2. Problem tackled during this works

This work look for improving TOR anonymity by enforcing some security mechanism and enhancing the performance of others. The proposed improvements will focus on improving TOR overall security and performances along with preserving and enforcing the current features which showed some weaknesses against the recent advanced attacks. This work state a clear statement in which an adversary external to TOR at any location with any capabilities should be unable to link (at large scale or locally) to link or identify any TOR user. This property is known as end-to-end unlinkability which is defined as guaranteeing the anonymity of the source regardless the destination’s location. Note that the anonymity targeted is for both TOR sender anonymity and sender-receiver anonymity.

Figure 19. TOR research and improvements work tree (AlSabah et al., 2015).

Figure 19. TOR research and improvements work tree (AlSabah et al., 2015).

Meanwhile, to preserve TOR reputation in the future, the security design should be reviewed and adapted to emerging threat and achieve better security and performances. In fact, several TOR flaws and vulnerabilities including the newly emerged ones remains untreated, the following is part of the desired properties and capabilities to be included in TOR:

a)

Cryptographic and performance enhancement

The current TOR deployment, despite the fact that it is considered as a low-latency anonymity solution, is facing performance trouble which impact both the quality of the service and the platform usability and flexibility to be used in as much possible situation. Reducing delays is a priority and is closely related to the cryptography used over TOR.

b)

Circuit selection security

An attacker, whatever his capabilities, should not be able to redirect any TOR client to choose a compromised circuit (controlled Guard and Exit ORs) or even modify the packet header to change path without being detected. The adversary should not learn forwarding information of uncompromised OR, OR’s geographic positions, or the total number of hops on a circuit (length).

c)

Sessions’ and Users’ Un-linkability

An adversary should not be able to perform timing attack to link Cells (packets) from different users or sessions, even between the same set of sources and destinations.

d)

Network Confusion and Diffusion

An adversary eavesdropping on multiple links in the network should not be able to correlate two or more packets and determine that are from the same user by observing the bit patterns in the packet headers or data.

e)

Node-to-Node cells’ authentication

In addition to the existing Data secrecy and end-to-end integrity, inter ORs TLS authentication and Directory server authentication, TOR should include selective authentication check mechanism to identify Rogue Cells or any forged cells injected by attacker into the circuit for any intention (misusing TOR computing power and causing DoS, inject fake Cells).

4.3. Proposed improvements and enhancements

During this work, several improvements will be proposed covering different research directions which all aims to address the current design weaknesses, security and performances issues described in Chapter 3. The security is a wide term which in TOR context refer to three thing; information security (Confidentiality, Integrity and Authenticity), Anonymity and un-linkability. The information security part is tackled in this work by proposing an improved AES mode guaranteeing the Confidentiality and the Authenticity simultaneously, where the anonymity and un-linkability are tackled by reviewing the TOR wrapping mechanism, circuit construction and routing within TOR which appear to be not relevant for the security but in reality it’s the most important factors for anonymity and un-link-ability. Moreover, this work tackle the performance issue in TOR and the related security flaws and vulnerabilities, as several attacks against TOR exploited the delays and the poor performances (timing attack, users’ clustering, and path selection attack).

4.3.1. Multi-layer encryption improvement

In this part, we assume that the AES (Advanced Encryption Standard) functioning principle is well known. Nevertheless, we will describe it in details at the appendix. The purpose of this part is to investigate the suitability of replacing the current AES implementation in CBC mode used for cells’ encryption by the authenticated-encryption OCB mode (Bogdanov et al, 2014).

OCB (offset code-book) is a new and revolutionary implementation of AES block cipher guaranteeing authentication along with the traditional confidentiality (privacy) of the user data, this type of ciphering id called authenticated-encryption scheme. Moreover, OCB mode is surprisingly and remarkably fast as it achieves authenticated encryption quicker and consuming almost the same duration as oAES encryption only CTR mode. Therefore, by adopting OCB the user can achieve in the cheapest way two out of three information security goals in an optimised and secure manner as OCB is considered as a simple cipher and resources efficient cipher when it comes to implementation in either hardware or software (Krovetz & Rogaway, 2014). In nowadays cryptography OCB solve three majors cipher issues:

-

OCB eliminate the problem of authenticated-encryption with associated-data (AEAD),

-

The OCB nonce required to encrypt and decrypt should not be necessary random as it utelise a counter,

-

OCB can encrypt data of any size without padding it to any convenient-length and therefore save some precious computing power.

TOR like all others Cryptosystem present cryptographic vulnerabilities related to its corposants, and one of these is the unauthenticated Cells traveling throughout the network leaving the possibility of forging fake Cells an inject them inside the network for malicious purposes. The ORs authentication mechanism remains insufficient. To introduce a node-to-node authenticity check on TOR, two options are available; the first option is an AES mode providing both privacy and authenticity separately (CBC, CTR and others) which perform separately encrypting and then computing the associate authentication using two different keys, the cost of having authenticated-encryption is thus the cumulated cost of encrypting with the cost of MAC.

a)

Working principle of the OCB mode

AES-OCB is a block-cipher with a block length and a key (K) of 128 bits each. It also uses a nonce (N) of 96 bits and an associated incremented counter value (Δ). The OCB detailed working principle is as follow (algorithm in Appendix 2):

-

First the plaintext M is divided into blocks of 128 bits each M = M1 ... Mm, Here there is two cases; the data size in bit is a multiple of 128, or there is a remainder and therefore the algorithm require a padding.

-

Secondly, a Checksum of 128 bits is calculated Checksum = M1 ⊕…⊕ Mm and will be used later during the authentication process.

-

Thirdly, an initialisation function “Init” take place and using the nonce N which is concatenated with a 32 bits constant value to produce a 128 bits value called “Top”. Later, the

Ktop = EK (Top) is computed and Stretched to produce the 256 bits value

Stretch = Ktop || (Ktop⊕(Ktop<<8)) (left shift by 8 positions KTop and replace the empty by zeros). The value Init(N) which is the initial value for Δ.

-

Fourthly, for each block “i” the increment is called to increment the Δ, XOR with the Mi, and encrypted using the key K and the algorithm AES-OCB as showed in the scheme. Later, the output of the encryption in stage 4 is XOR again with the Δ to produce Ci... The authenticated ciphertext is CT = C1 C2 … Cm T.

Afterward, the authentication value which is 128 bits length is computed by processing the associated data A which is XOR with the value of Δ for each block in the same way as the encryption part and later encrypted using the same key K. the result of all the blocks is XOR together to produce a 128 bits length authentication value Auth. Finally the checksum of the initial data is XOR again with the Δ, encrypted using the key K and then XOR with the authentication value Auth to produce a final authentication Tag “T” for the whole data (Krovetz & Rogaway, 2014).

Figure 20. OCB mode functioning schemes (Bogdanov et al, 2014).

Figure 20. OCB mode functioning schemes (Bogdanov et al, 2014).

The Decryption under OCB mode is faster and simpler. By having given K, N, and CT, the receiver recover the initial message M following the normal decrypting way. Then, the authentication tag T is re-computed and compared with the received one to determine the authenticity of the received message (Krovetz & Rogaway, 2014).

Figure 21. AES-OCB version 3 encryption and authentication operations scheme (Krovetz & Rogaway, 2014).

Figure 21. AES-OCB version 3 encryption and authentication operations scheme (Krovetz & Rogaway, 2014).

There is three different implementation (versions) of OCB mode. The adopted version for this work is version 3 which is the most optimised version in term of operation number and computational power. Although, the performance improvement will be relatively small, it remain crucial for TOR to adopt an authenticated-encryption for onion construction. In fact, in addition to the performance enhancement, implementing AES in OCB mode will bring the following properties:

-

Fully parallelizable operations of the block ciphering can be performed simultaneously. Thus, OCB is very efficient and suitable for hardware encrypting at high network speeds.

-

Block-ciphering scheme make it strong and resist better to the new timing attacks which the other mode like CBC would be vulnerable.

-

OCB is a single key scheme as it use the same key for encryption and authentication which make it more efficient in term of memory use.

-

OCB can process any data size without requiring it to be a multiple of the block length. Moreover, no external padding function is used and thus it economise time as there is no bits- waste in the ciphertext due to padding.

-

The main computational function used beyond the block-ciphering is XOR which is very time and power efficient function (three 128 bits XOR per block).

-

OCB can be perfectly used into memory-limited systems as the main memory cost the amount needed to hold the AES sub-keys.

b)

Choice justification

An authenticated-encryption scheme enable two parties sharing a secret symmetric key to communicate in a manner that ensures both privacy and authenticity. AES implementation in OCB mode is designed to be time (time consumed to perform encryption) and resources (processor and memory) efficient in both software and hardware. In fact, the algorithm is perfectly adapted to restricted environments requiring accuracy and pseudo-synchronization along with providing provable security and authenticity (Krovetz & Rogaway, 2014). During this work we will start by assessing OCB Security and performance versus others competitor integrated authenticated-encryption modes. The use of an incremented nonce for each encryption and the decryption process by OCB is one of the major strength. In fact, It is required that the nonce should be unique (not necessary random, secret or unpredictable) for each message but OCB rely on a counter value which ensure that each nonce is different. Thus, the importance of the unicity of the nonce is crucial to maintaining perfect authenticity and privacy.

On the other hand, OCB competitor scheme and particularly CCM and GCM which offer an integrated authentication along with encryption will be assessed in similar testing environments during this work. Moreover, the traditional approach for achieving authenticated-encryption which rely on composite functions (encryption following by MAC or MAC followed by encryption) will be assessed alongside with OCB competitors evaluation, two implementations of both CBC and CTR mode followed by MAC computing will be performed to serve as a reference on the performance evaluation. In this work the implementation of CBC and CTR mode will not use separate keys, in fact we will use the same 128 bits key for encrypting the plaintext and then to calculate the associated MAC of the resulting ciphertext. Nevertheless, for security measure the CBC IV (Initialisation Vector) will not be derived from the key but instead it will be generated using a different function. The following table, summarize the different mode of implementation and the picked candidates for potential adoption instead of the existing CBC/CTR and are: OCB CCM, GCM, and EAX:

Figure 22. AES implementation modes comparaison (Bogdanov et al, 2014).

Figure 22. AES implementation modes comparaison (Bogdanov et al, 2014).

c)

Cryptographic features comparison against competitors

To evaluate the features of each candidate in addition to the practical performances, this work rely on the following points to determine the suitability of the authenticated encryption mode, the features are summarised in the following table and divided into three major part:

Table 1. Authenticated encryption features comparison (Krovetz & Rogaway, 2014).

Table 1. Authenticated encryption features comparison (Krovetz & Rogaway, 2014).

Feature	CCM	GCM	OCB
Security Proved	Yes	Yes	Yes
Online ability	No	Yes	Yes
Key requirement	128 bits block size	128 or 64 bits block size	128 or 64 bits block size

-

Provably secure: all the three modes are proved to be mathematically secure by assuming that the used with block cipher (AES) is pseudorandom permutation. As far as the cryptography permit, AES is proved secure and thus both three modes of implementation are absolutely secure.

-

Online message processing: this feature is crucial for the suitability of the mode as the modes should be able to process data without knowing the whole length in advance as the TOR have no pre-set or pre-defined data length. Moreover, this feature is highly desired for a memory restricted environment which is the case of ORs in this part, CCM mode fail to achieve the set baselines.

-

Cipher requirements: CCM mode is developed to only work with ciphers using block size of 128 bits, while GCM and OCB can work with cipher using different block size (64/128 bits).

Nevertheless, this feature will not affect the CCM mode as the block size in TOR is 128 bits which is anyway more efficient and better for performances.

4.3.2. The Encapsulation approach (Onion wrapping method)

TOR use Cells as mean of transporting TCP/IP data throughout the network to the exit OR which will be in charge of transmitting it to the destination under TCP/IP protocol. Currently, TOR perform a multi-layer encryption-encapsulation which mean that the initial data is placed into fixed size cells of 512 bytes each (509 bytes for data and 3 bytes for header) and then encrypted three times using the three ORs constituting the routing circuit keys into the inverse order. In other words, the whole data along with the next OR address or the final destination is encrypted three times (figure).

Figure 23. the onion multi-layers encryption approach.

Figure 23. the onion multi-layers encryption approach.

This approach of multi-layer encryption is the hearth of the TOR system as it allow only the ORs part of the Circuit and In Ordered way to have access to the information related to the next OR in the circuit or the final destination of data and thus achieving the anonymity of the sender (figure). However, giving the delays caused by heavyweight encryption of relatively big data this mechanism of encapsulation and wrapping became problematic as it, in one hand slowdown the performances and in the other hand was proved mathematically that this approach does not bring additional security to the system. In fact, in cryptography encrypting the same data using the same function (algorithm) several time using different keys will give the same security of encrypting it once using a composite key which is the aggregation of all the keys (not the addition but it is mathematically determined).

To summarize, improving the encapsulation and wrapping on TOR will not only improve security (privacy and anonymity) but also enhance the network overall security and resilience as the current relays on TOR are being exploited by several attacks (correlation and timing attacks).

d)

Proposed Improvement:

Instead of multi-encrypting TOR Cells several time to produce an onion wrapping which only circuit ORs will be able to unwrap, we proposed a much efficient and time saving approach which perform a full encryption of the whole original data including both Exit OR address (Cell Header) and TCP/IP (Header and Data) in the first phase using the Exit node AES shared-secret Key. Then, for the remaining ORs (Entry OR and Middles ORs) only the cell header will be encrypted. In cryptography, encrypting several time data using different keys (k1, k2,…kn) is equivalent to ONE encryption using a composite key K. Thus, the current TOR encryption of the whole Cells several times is useless and cause performance slowing down only as one layer of strong encryption n is enough.

Figure 24. TOR current cell multi-layers and encapsulation approach.

Figure 24. TOR current cell multi-layers and encapsulation approach.

Moreover, the current TOR cells structure is vulnerable and should be reviewed, we propose that only the internal Cell Header contain the Circuit ID, where the external ones (OR1 and OR2) should contain only the address of the next OR and Command. Giving the fact that TOR is managed locally, including this kind of information cause redundancy causing the slowdown of the operation and also leave the circuit ID exposed to threats especially when a fully compromised OR is a part of the circuit.

The proposed approach of encapsulation and onion construction work as follow:

Figure 25. TOR proposed cell multi-layers and encapsulation approach.

Figure 25. TOR proposed cell multi-layers and encapsulation approach.

Basically, the proposed wrapping algorithm will economise (save) a crucial time and componential power. In theory, two (02) round of encrypting data of 509 bytes will be saved along with preserving the same security of the existing TOR. In cryptography encrypting the same text several layers using different (but same size) keys will have the same security of encrypting only one time using the composite key. As AES is provably secure and the key used is also assumed secure enough to suffice on one layer of encryption.

4.4.3. The number of intermediate ORs

TOR users anonymous online activities is mainly due to two computing technology Cryptography and Routing, TOR utilizes a series of ORs and makes users’ data traveling through a number of hops before it reaches the final destination. By ensuring that each OR have not more information than its predecessor and its successor in the circuit, TOR hide the origin or the destination of the cells containing data and therefore guarantee users’ anonymity. Given the aforementioned principle, it is obvious that the more is the number of ORs into a circuit, the better is the source of data (client) is hidden and thus anonym, tracking back the communications will become very complex and the majority of times just impossible to perform. Meanwhile, the number of ORs influence the connection performance as the long circuits cause more delays (latency) and running interactive applications requiring time precision connection becomes impossible. Hence TOR developers, were seeking the best trade-off between a secure connections that enables perfect anonymity while keeping connections latency bearable. Following several research and testing, TOR developers finally adopted the three (03) ORs circuits length which the current TOR deployment use. When a client is communicating with a server, the data is routed through three intermediate ORs before leaving the TOR network and reach its destination. This choice is defined as the optimal balance between security and usability of TOR.

A continuous debate has been raised regarding the appropriate circuit length especially after the 2015 FBI attack which with the help of researchers were able to control, at several occasion, both the Guard and the Exit ORs and therefore performed an advanced attack to de-anonymise several TOR users including “Drug website Silk-Road-2” owner. As consequence, current TOR short three (03) ORs circuit length will be critically reviewed in this work and several improvement strategies will be considered including increasing the length of the circuit and adopting new routing strategies such as controlled exit OR which will be discussed later in this work. TOR developers’ intention behind the choice of a default three ORs circuit is to provide the best balance between the security and performance. In fact, this choice include an Entry OR, an Exit OR and an additional OR aiming to obfuscating the link between the entry and the exit ORs in such way that even if an attacker is able to compromise either of these ORs, the middle OR will constitute the last layer of defence as the attacker can only observe encrypted traffic and it cannot directly deduce the identity of the user. Nevertheless, with the rapid increase and development of the computational power and cryptanalysis attacks, this defence layer become meaningless and can be compromised by performing timing correlation attack.

a)

Proposed Improvement

A systematic thought is that increasing the circuit length further would produce an increase into the TOR security. Unfortunately, this operation will incur a significant impact on TOR performance and penalise further the network as the more ORs are involved in transporting one cell, the more times the same cells are relayed in the network before reaching its destination. To determine the impact of increasing circuit length onto TOR anonymity, we will experience different cases in which the variables will be either the number of OR into the circuit or the routing methodology itself such as controlled exit OR selection and network link-status depending selection.

In this work, we implemented a dynamic TOR circuit construction function which have as input the natural number P which is the length of the circuit, then we uses this function to measure the impact of a longer or shorter circuit on the performances. In the proposed function we proposed different circuits building approach for evaluation purposes, also rebuilding function was modified along with the initial function following two main criteria: time interval and circuit performance. Furthermore, as TOR connections terminating in the public internet, the weakest points for attack in the circuit is obviously the Exit ORs (last OR in the circuit). We introduced the notion of “Controlled Exit OR” in the circuit construction in which the algorithm responsible of defining the ORs which will take part in the circuit is adapted to choose the exit ORs from a pre-defined list which reflect in the real TOR the list of trusted ORs. This proposed solution is expected to reduce considerably the FBI attack success against TOR despite the number of rogue (fake) OR inserted into TOR network (Steven et al., 2011).

Figure 26. Dynamic TOR circuit length scheme.

Figure 26. Dynamic TOR circuit length scheme.

4.4.4. Circuit ORs’ Selection Approach

In this work we will improve the path selection process by proposing a novel path selection hybrid-algorithm relying on varying path length, controlled exit OR and real-time performance assessment functions. We also employ ORs parameters from a simulation of TOR to compare the proposed algorithm efficiency against.

In the current TOR implementation, ORs for circuit construction are selected at a uniformly random basis aiming to guarantee that ORs are selected uniformly and thus increases the probability and the uncertainty of an attacker trying to de-anonymise users by guessing the ORs used in a particular circuit. Although, because of the heterogeneity in resources caused by ORs of different capacity (computing power, bandwidth) and the emergence of a new classes of attacks, the selection algorithm was edited by TOR development team in the second generation of the network, the following changes were introduced in form of exception in the algorithm:

-

No OR should be used in the same circuit more than once,

-

ORs in the same circuit should belong to different class of TOR network,

-

A special treatment for co-administered ORs is introduced by marking them as the same family,

-

Directory Authorities will assign flags to ORs basing on the following parameters: performances, status, position and role.

Moreover, some important features were added following the attacks on TOR circuit selection in 2014. In fact, ORs selection algorithm was again changed in such way that entry OR (guard) is only selected from a subset of ORs classified as “entry guards” and which are particularly “trusted” and continuously authenticated to check the status. The entry guard subset is a group of ORs which are constantly active, having a bandwidth of at least 250 KB/s (Dingledine et al. 2014). In reality, the implemented selection algorithm allowed 3 ORs guard to be assigned for a user for a period of 30 to 60 days and used in combination for all circuits. However, due to the limit probability of attacks and the impact on the TOR overall traffic homogeneity, this algorithm was abandoned to allow client the use of only one entry OR for the same period of time (Dingledine & Mathewson, 2015).

On the other hand, current TOR circuit selection algorithm states that selecting the remaining ORs on the circuit (Middle and Exit) is proportional to the available bandwidth. This choice aims to ensure that powerful ORs are chosen more often. Nevertheless, the bandwidth information which TOR base on for making decision is being advertised by the ORs themselves which leave the opportunity for rogues ORs to advertise false data in order to acquire more traffic. Logically thinking, if a capable attacker with significant resources is able to inject an important number of rogue ORs having the best performance, it will be able to re-direct a significant amount of TOR traffic via these ORs (which will be middle ORs or exit OR of the selected circuits) and therefore being able to perform a time-analysis attack to determine the User as the Entry OR information will be already disclosed for the Middle OR (Steven et al., 2011).

a)

Proposed Improvement

Figure 27. TOR circuit selection scheme.

Figure 27. TOR circuit selection scheme.

The proposed improvement for the circuit selection algorithm is twofold:

First, we introduce a new sub-function in the section algorithm imposing the selection of the Exit OR from a pre-defined subset only. This subset will be completely different from the entry guard subset (no common ORs) and contain more ORs . This method is called during this work “Controlled Exit” which will be implemented into the emulation platform for test purpose. It is evident that such method will have an impact on traffic homogeneity, but the security enhancement will be greater than the overall performance. Moreover, the proposed method will help into protecting the TOR hidden- services from being disclosed during the attacks.

The second proposed improvement is related to the choice of the ORs basing on the advertised capacity (bandwidth). The misleading information that rogue (fake) ORs can provide during the selection process could be fatal for user security. Thus, the directory authority responsible of the collection of such information and processing should not trust this information and rather evaluate or estimate itself the capacity of each router and therefore faster ORs will not have any more a higher probability. In this work, the concept of prudential-processing is introduced in which the calculation of ORs’ capacities is done in a real-time basis relying on both provided information by the ORs, historical status and credibility. This method will be implemented and tested into the emulation platform.

Figure 28. the proposed controlled exit approach for TOR circuit selection.

Figure 28. the proposed controlled exit approach for TOR circuit selection.

b)

Dynamic circuit construction with traffic management

To tackle the delays and security issues related to the choice of circuit ORs, we introduced an enhanced circuit selection algorithm named Controlled exit with congestion-aware ORs Selection at Client side. In this work we tried to adopt and implement a circuit construction method proposed by (Wang et al.,2012) in which the multi-criteria circuit selection algorithm rely on both the status and performance data and real time indicator. First, TOR’s default bandwidth-weighted OR selection algorithm is used to construct circuits. Then, the proposed algorithm will use an opportunistic and active-probing function to calculate the circuit’s latency value.

4.4.5. Cells’ Multi-circuit routing (limited to three Circuits)

Multipath routing approach on TOR has been previously tackled by Snader et al. (2010) in context of improving TOR networking performances. The research simulated a case of downloading data fragment of 1MB each over a dedicated TOR simulation network. The files were divided into blocks of 512 Bytes and routed from the sources to destination over multiple circuits. The proposed mechanism was working as follow. An algorithm assign each Client (OP) two different Entry and Middle OR, the mechanism used the same Exit OR for both Circuit (Figure 29).

This research observed that the security and throughput of the routed traffic were significantly enhanced. However, two circuits performance was less well than single circuit as the chances of choosing a slow OR as part of the circuits double and thus the median transfer time increased for the two circuits. Nevertheless, the research highlighted the fact that the security enhancement of such proposition is also considerable and also that the risk of including a compromised OR will be certainly be affected if this function is used.

a)

Proposed Improvement

The current TOR deployment each Client (OP) is assigned by default three different Entry (guard) OR which will be the only Entry guard that this client can have (use) for a certain duration. This research will rely on this feature and implement an algorithm which will generate for each linked Traffic (having the same destination server) three different circuits. This Multipath routing has introduced to enhance security for TOR users and also the Entry and Exit OR themselves. TOR client starts by building a three different circuits using the following algorithm:

Figure 30. the proposed TOR multi-circuit routing mechanism.

Figure 30. the proposed TOR multi-circuit routing mechanism.

Chapter 5: Implementation, Testing and Results

5.2. ExperimenTOR platform

To perform real and accurate experimentation on TOR without affecting other users, this work will implement the proposed improvements and enhancements into a TOR simulation dedicated platform called “ExperimenTOR” developed by Bauer et al. (2011) for TOR research purposes. It is based on the Model Net network emulation test-bed and can be used locally or virtually but requires several FreeBSD machines to work as ORs along with emulator core server responsible for networking the TOR architecture (Bauer & Sherr, 2012). Client (OP) can be run on several emulators. ExperimenTOR run the original TOR network deployment and code and can simulate different size network varying from 2 to several hundred depending on the componential power and memory res resources. ExperimenTOR is used to generate a downscaled network of TOR (small TOR prototype) and incorporate module for measuring and comparing TOR performances. Several reputed research on TOR used ExperimenTOR for emulation and simulation, such as (Wacek et al., 2013) research which relied on ExperimenTOR to perform an analysis of the OR selection technique and impact on anonymity and performance properties (Bauer & Sherr, 2011).

Moreover, (AlSabah et al., 2015) research used ExperimenTOR for evaluating their research on improving and surveying security in TOR. ExperimenTOR prototypes were deployed at many research centres in the United States and Canada. The current version consist of several FreeBSD machine with the ModelNet emulator kernel module and other machines running Linux working as ORs, OPs (clients), and application processes within the emulated topology. ExperimenTOR is a combination of python and C++ codes and include experiment and performances measurement toolkits such as “torperf” written in C++ for performance measurement purpose (Bauer & Sherr, 2011). For our work, we adopted this virtual test-bed which will be running on VIRTUAL BOX machine with the following architecture:

Figure 31. ExperimenTOR emulation platform architecture.

Figure 31. ExperimenTOR emulation platform architecture.

5.3. TOR test-bed topology and deployment

The first step into implementing the proposed solution and before running experiments in the test-bed is to design a TOR network realistic topology to be diploid later into the emulator. This work uses information from a real TOR Directory Server (DA) and applied the deployment into a small size simulation network at the corresponding componential power and bandwidth capacity of the ORs, Host and Server within the virtual topology by assigning a real bandwidth value and realistic network latencies to each end-host. In this work, the test-bed topology is as follow:

Figure 32. the simulation virtual environment configuration.

Figure 32. the simulation virtual environment configuration.

5.3.1. Simulation network size

The number of ORs into the simulation network used for implementation and testing is a crucial, because a small network might not reflect the same deployment or capture the same network features and effects that the real TOR network can experience. Moreover, the Network parameters should be adjustable to reflect the real-world situation and being flexible to allow the gradual incorporation of the proposed improvements along with the performance change testing and measurement. Moreover the virtualization option which this research adopt is tricky, despite the fact that this option will help to avoid compromising legitimate used and unethical, but also to run experimentations is a controllable and scalable environment, but the virtualisation will affect the performance and therefore the results of the experimentation. Thus, for each improvement incorporation test during this work, a benchmarking test will precede it using the current TOR deployment and feature which will serve as a comparison reference. The testing platform include the following:

-

Twenty (20) FreeBSD Onion Routers including 3 dedicated Guard (Entry) ORs,

-

One Directory Server (DA),

-

Three (03) Onion Proxy (Clients),

-

One service server (destination),

-

Different size testing data

Figure 33. the simulation TOR network design.

Figure 33. the simulation TOR network design.

5.3.2. Test-bed Preparations and configuration:

Before the actual tests could be carried out, the ExperimenTOR platform require reconfigured and benchmarking. Then, the proposed improvement were implemented in C++ and incorporated into the different modules of the test-bed. Moreover, some modifications were introduced to the modules: torperf: the performance measurement module in which several code addition and modification will occur in this module to include new functions required for testing purposes.

code: several modification and new implementation will be incorporated especially into the “crypto function”, “test”, “config” and “or” source code. The proposed cryptographic and onion construction improvement were implemented in this module.

log: new logging and processing function will be included in this module.

lighttpd: This is the source code for a very light-weight web server. A customised web servers to host web objects for clients to download will be included.

routers: Each router is assigned new routing, capabilities and type information along with numbered data directory. Routers 1-5 are configured as Entry (guard), router 18-20 are configured as Exit and all other routers are middle. The proposed circuit construction algorithm (ORs selection and routing approach, multi path routing and dynamic circuit length).

tcpping: use ICMP pings to measure round-trip times between virtual ORs. We introduce a new TCP- based ping timing measurement along with TCP's SYN and RST packets to calculate RTT.

tools: several script modification are introduced especially the configuring, running, and stopping functions.

torperf: the TOR performance assessor module which will be modified to measure several new variable related to encryption, circuit construction and routing approach performances.

Figure 34. example of code modification within the adopted simulation platform.

Figure 34. example of code modification within the adopted simulation platform.

5.3.3. Logging and measurements

Native TOR implementation provides several measuring and logging features varying from a high-level error logs to a detailed performances measurement. However, these log still present crucial lack as the information does not include performance logging.

In this work, the lgging for tests and experiences is ensured by the embedded ExperimenTOR logging module called “TORPerf”. Though, several modification were introduced to deal with the edited module and function. Logging is performed at the network level (directory server), ORs level and at OP level (TOR software).

Figure 35. example of experiment setup and configuration in ExperimenTOR.

Figure 35. example of experiment setup and configuration in ExperimenTOR.

5.4. Testing and results

In this section, the testing of the implemented proposed improvements and enhancements will be performed several times and results will be logged in details

5.4.1. Testing the proposed ciphers and encapsulation approach

The NetBeans Platform is a reliable and flexible application architecture allowing a time-tested architecture and the componential power usage. In this work, the implementation (in java) of the proposed improvement (cipher modes and encapsulation) along with the TOR-like crypto-system is run on the NetBeans platform first. The aim of this step is to select the appropriate candidate to be implement in the TOR test-bed and also measure the cryptographic and power performance of each implementation. As benchmarking, this work will use different combinations of data with sizes varying from 16 to 5120 bytes in different scenarios. All measurements were taken on Platform running on Intel Core i7-2820QM CPU at 3.4 GHz and a restricted RAM memory of 2048 MB.

The second step, is to encode (implement) the selected algorithm mode (OCB) in C++ to be incorporated with ExperimenTOR module. In fact, we implemented the proposed improvement and enhancement function and algorithm along with preserving the current mode (original TOR) in order to produce a comparison. For each combination of parameters, the performance is measured several times depending on the experiment length. For the encryption algorithm performance assessment, the implementation and testing into the simulation platform will be preceded by testing all candidates AES modes (CBC+MAC, CTR+MAC, CCM, GCM and OCB) on JAVA NetBeans and we ran the experimentations using java debug and project profile mode to determine and measure the time spent on processing for encryption and decryption along with the resources usage.

-

AES-OCB-128,

-

AES-CCM-128,

-

AES-GCM-128,

-

AES-EAX-128,

-

Add a separate MAC calculation function to the existing CBC and CTR code.

During the third step, the proposed encapsulation and onion construction approach was implemented within a TOR-like light-weight cryptosystem for performance measurements purpose. The proposed onion construction approach (with encryption and structuration) is implemented on beside the current (Existing) TOR encapsulation approach and several testing scenarios of various Cells Format wrapping, padding and encrypting were performed to assess the efficiency and the improvement before incorporate the proposed improvement on the ExperimenTOR platform for validation.

Figure 36. the implementation of the AES modes candidates into the JAVA test-bed.

Figure 36. the implementation of the AES modes candidates into the JAVA test-bed.

Finally, after testing the proposed wrapping (onion construction) approach. The algorithm is implemented in Python (plus the Browser C++) and integrated in the TOR simulation platform (TOR browser and the ORs) to be tested in TOR condition, measure the performance enhancement and assess the suitability.

Figure 37. the implementation of the selected modes of AES in the ExperimenTOR platform.

Figure 37. the implementation of the selected modes of AES in the ExperimenTOR platform.

a)

Experimentation Results and Discussion

The results obtained initially Java implementation of AES encryption algorithm in three modes; CBC (first generation TOR), CTR (second generation) and OCB (with disabling the authentication TAG processing and only performing encryption) in order to pre-assess the efficiency of each mode for different data size varying from 16 to 5120 bytes. The results obtained were predicted and showed that CTR (without authentication) perform better than OCB and CBC. Thus, without the need of node-to- node authentication the current TOR adopted mode seems to be the perfect choice. The figure summarize the performance of each mode.

Table 2. the AES modes testing results on JAVA.

Table 2. the AES modes testing results on JAVA.

Input size (Bytes)	16	64	128	256	512	1024	2048	5120
Time Consumed (ms) per mode
CBC	64.11	102.31	198.34	344.76	634.21	1123.44	2011.54	4329.33
OCB	10.54	34.25	56.23	98.50	176.32	322.90	603.74	1488.60
CTR	5.82	20.58	36.77	65.88	129.98	245.34	468.13	1198.86

Figure 38. the comparative graph of the AES encryption only modes performances.

Figure 38. the comparative graph of the AES encryption only modes performances.

Then, we implemented (coded) an authentication processing function to CBC and CTR mode with preserving the same encryption implementation, where the OCB was implemented entirely by activating the authentication function. We tested the three implementation in the same way. Here, the results obtained (figure) were different. Regardless the slightly slowdown in OCB performance, it perform better then CBC+MAC and CTR+MAC. Therefore, to introduce the node-to-node authentication in TOR it is obvious that the classic implementation of encryption followed by authentication is a wrong decision.

Table 3. the performances of AES modes encryption plus authentication.

Table 3. the performances of AES modes encryption plus authentication.

Data Size	16	64	128	256	512	1024	2048	5120
Time Consumed (ms) per mode
CBC+MAC	84.11	122.31	218.34	364.76	674.21	1323.44	2191.54	4629.33
CTR+MAC	35.82	80.58	96.77	165.88	329.98	645.34	1068.13	2398.86
OCB	29.54	54.25	76.23	138.50	246.32	472.90	793.74	1578.60

Figure 39. the comparative graph of the AES authenticated encryption modes performances.

Figure 39. the comparative graph of the AES authenticated encryption modes performances.

Nevertheless, OCB is not the only AES implementation mode guaranteeing an integrated authentication. Three other modes; CCM, GCM and EAX should also be considered. Therefore, we implemented the six (06) mode together using the test-bed resources (javax.crypto.Cipher) in which the implementation is optimised and implemented natively. And the results obtained (figure) showed that three candidate could be replacement of the current TOR mode; CCM, GCM and OCB.

Table 4. the performance of all AE candidate in java compiler.

Table 4. the performance of all AE candidate in java compiler.

Data size (Bytes)	16	20	32	64	128	256	512	768	1024	1536	2048
Time consumed (ms) per Mode
CBC	136	167	207	232	248	259	269	278	286	299	312
CTR	89	109	140	162	193	225	246	261	269	275	282
EAX	91	98	123	133	162	177	193	216	228	257	268
CCM	52	59	79	83	102	129	148	157	160	167	174
GCM	45	51	73	75	88	104	116	127	131	139	153
OCB	36	48	65	73	89	101	113	120	127	135	148

Figure 40. graphic representation of the performances of all candidates inn JAVA.

Figure 40. graphic representation of the performances of all candidates inn JAVA.

b)

Encryption testing results

From the obtained results and the research carried on the authenticated-encryption, OCB is by far the best integrated mode as it perform both encryption and authentication in one round (single pass). OCB is patented in US in case of commercial use, however TOR is an open-source and free software/service and thus this restriction doesn’t apply. Moreover, OCB accomplishes the authentication processing without using the heavy-weight universal hashing computing which make it not only the best mode in term of performance but also in term of resources use and the implementation in both hardware and software. Nevertheless, the Nonce generation choice and use in online system can be tricky as Nonce require to be unique for every encryption (no need to be random as it is the case of IV in CTR, GMC and CCM modes).

c)

Resources use analysis

The Performance comparison is not enough to constitute a criteria for selecting an encryption algorithm or mode, in fact the componential power required/consumed by a cipher is also an important factor. In TOR context this power is limited and therefore precious. In term of Memory requirement, OCB has the smallest memory usage as it mainly relies on the block cipher operation and data with no use of other function. The memory required for GCM is the largest due to the Galois function and it uses more extra pre-computation table for speed acceleration. On the other hand, the computation cost of CCM is the highest compared with the OCB and GCM as it requires two cipher invocations for each block, while OCB mode require merely one cipher call for each block along with the special function which have a low computation complexity.

d)

Choice and Discussion

In the real world situation, encryption modes present various pitfalls due to the combined privacy and authenticity processing such as the failure of guarantee a proper key separation, the misuse of the MAC which open security breach into the cipher allowing cryptanalysis or brute-force attacks, mismanaging the IVs or Nonces. OCB and GCM are provably secure meet these required standards but remain dependant on the correct implementation especially on software which mean more vulnerabilities threats and enemies. On this work a high importance is accorded to mode selection, thus we tested all the potential authenticated-encryption schemes which are OCB, CCM and GCM. The tests conclusions are as follow:

-

CCM is inspired from the generic composition of CBC+MAC mode allowing a moderate performance by the use of integrated authentication scheme and optimize the implementation. However, it remains less efficient in term of performance than GCM and OCB,

-

GCM is an improved incorporation of CTR mode encryption mechanism with an integrated internal MAC allowing parallelizable operation and thus a better performances and resources efficiency. Nevertheless, GCM parallelization feature have a significant impact only on high-speed hardware-based applications. In TOR context, because the cryptographic operation are performed on software basis the GCM mode performance was not optimal and hence not as well as OCB.

Figure 41. performance and timing measurement example on JAVA platform.

Figure 41. performance and timing measurement example on JAVA platform.

5.4.2. The Onion construction (Encapsulation)

The implementation of the proposed encapsulation approach was implemented on the JAVA test-bed in a light-weight way by just including the cell construction, headers incorporation and dis-association, public key encryption symmetric keys exchanges, onion encryption. For testing purposes, this work eliminate system I/O and reading function use and was restricted to the minimum required. The results obtained for the proposed approach (figure) shows the clear performance enhancement brought by the proposed encapsulation approach. In fact, the proposed approach save two AES encryption round of data size equal to the initial data size (intended to be sent through TOR) which reduce significantly not only the time required for wrapping but also the un-wrapping (decryption) at ORs level. Therefore, the performance enhancement is not limited to the onion construction but extended to alighting the routing through TOR.

a)

Obtained results:

The testing of the proposed onion construction approach produced the following results:

Table 5. construction programs performances in JAVA platform.

Table 5. construction programs performances in JAVA platform.

Cell Size (Bytes)	512	1024	2048	5120
Current TOR Cryptosystem (ms)	834.81	1463.65	2390.03	4388.41
Proposed Cryptosystem (ms)	521.90	877.74	1730.11	2912.43

Figure 42. Time consumed to perform multi-layered encryption of TOR cells.

Figure 42. Time consumed to perform multi-layered encryption of TOR cells.

Moreover, the function of measuring the operations carried out during the execution of the cryptographic operations within the TOR-like cryptosystem produced the following results:

Figure 43. the time consumed per task on TOR cryptosystem.

Figure 43. the time consumed per task on TOR cryptosystem.

From the two above pie-charts it is clear and obvious that the proposed approach reduced considerably the time spent on Encryption and Decryption and also induced a slight improvement (time consumed reduction) for other operations such as encoding/ decoding. However, slight increase on the time consumed on checking, transmission and addressing was observed, nevertheless this small changes do not impact the overall performances improvement.

Finally, after confirming the efficiency of the proposed encryption mode. An implementation of AES-OCB was performed and replaced the current implementation into the TOR simulations platform (ExperimenTOR) has produced the following results (figure). Moreover, an implementation of AES- CTR mode with a separate authentication (MAC) computation was performed for comparison purposes.

Figure 44. AES encryption modes performances on ExperimenTOR.

Figure 44. AES encryption modes performances on ExperimenTOR.

b)

Discussion of the obtained results:

The two pie charts provide an overview of the performance enhancement brought by the proposed approach. In fact, to better explain and distinguish the different results we categorized the TOR cryptosystem mechanism into function and measured the CPU time consumed to complete each stage. Where the encryption and decryption seems to consume almost the half of the cryptosystem time, the proposed approach reduce this time significantly by around 23.5%. Furthermore, the remaining functions performances (transmission, checks, encoding, decoding, data preparation …etc.) were also slightly enhanced. In fact, regardless the importance of these functions for TOR, their impact on the overall performance is huge and it can be can observed that the encoding, decoding, addressing and check takes a lot of CPU time but no further improvement is unfortunately possible.

Despite the fact that the introduction of OCB mode will slightly affect the performances of TOR, the security assured by the authentication is crucial and therefore the OCB is the perfect balance between security and performances.

5.4.3. ORs Selection and Circuit Construction testing

In this work we implemented the algorithm of circuit selection into the ExperimenTOR system, the program is written in C++ within the TOR path simulator program. The code receive as input an existing consensus from the DA and generates circuits with specified constraints, such as the list of ORs and types, performances. The program compute the probability that each ORs part of the selected circuit is compromised and measures the time consumed to construct the circuit and the performance during the download of fixed size data. We compared two circuit (path) selection algorithms implemented into the ExperimenTOR in addition of the existing TOR circuit selection algorithm which will be used as a reference for evaluating the proposed improvements, the two implemented algorithm are:

-

Bandwidth-Weighted algorithm optimised by a combination of Dekjstra and A* algorithms,

-

Controlled Exit OR Algorithm with random intermediate selection.

The simulator generated several hundred of circuits (for both algorithm) and transmitted different data size throughout along with measuring the performances with the probability that fake (malicious) ORs are being part of the circuit in order to truly evaluating the possibility of successful FBI attack. Moreover, a specific attack evaluation algorithm was adopted (Steven et al., 2011) to determine and measurement the impact of misleading (false) bandwidth information share by the ORs.

Figure 45. circuit selection and routing algorithm implementation in ExperimenTOR.

Figure 45. circuit selection and routing algorithm implementation in ExperimenTOR.

c)

Obtained results:

In the first experiment, shown in Figure 1, where variant number of compromised ORs were injected into the simulation network and the measurement function determined the percentage of the occurrence of a successful FBI attack on the three algorithms. The results shows that the current TOR uniform ORs selection and the other TOR variant relying on capacity in assigning ORs leaves a high probability for an attacker who compromised a certain number of ORs to fully control the circuit (FBI Attack). Nevertheless, the current number of ORs in use into the real world TOR is about 6000 and the results of a simulation into the real world could lead to different results. On the other hand, the proposed circuit construction approach relying on the selection of the Exit ORs from a trusted (pre-defined) set of ORs shows its efficiency on dealing with such attacks. In fact, this approach guarantee that the selected Entry and Exit ORs are safe and prevent an attacker from influencing the process of selection by injecting powerful ORs which provide false and misleading information to the TOR Directory Authority (DA).

Figure 46. FBI attack occurrence probability by number of injected compromised ORs.

Figure 46. FBI attack occurrence probability by number of injected compromised ORs.

d)

Results discussion:

The analysis of the effectiveness of the different TOR circuit selection algorithms in term of performance and security which are in reality closely related as the TOR performance affect the security because many attack exploit the delays and the compromise made by TOR developer to maintain the required performance and thus the system usability. The following graph (Figure 47) illustrates the use of available bandwidth for each algorithm. In fact, despite the security enhancement brought by the controlled exit circuit construction approach, the impact on performance is significantly negative as the ORs will not be able to exploit at maximum the available bandwidth and thus reduce the performance. While the dynamic circuit construction seems to be the best in term of performance, this approach is risky as any attacker who possess the adequate resources can inject powerful compromised ORs and attract more traffic through these ORs and therefore compromise user anonymity. This attack was already carried out by researcher working for the FBI in 2015 and achieved its goals by de-anonymise users.

5.4.4. The Multi-circuit routing testing and results

The implementation of the multi-circuit routing function within the existing TOR routing approach (circuit ID) and the Proposed Approach (controlled Exit) produced unexpected results. The proposed approach performed better in the multi-circuit routing approach then the existing approach (figure). In fact, the multi-circuit approach registered les 22% in delays then the concurrent when the current TOR single circuit per session remains better in term of performance but vulnerable in term of security. Therefore, the proposed approach could be considered as the best balance security- performance. It is also recommended that the TOR incorporate the proposed approach along with preserving the existing one.

Figure 48. Delays during downloading data per algorithm.

Figure 48. Delays during downloading data per algorithm.

To summarize, the suitability of the proposed improvement are discussed on two major factors; the security and the performance. When it seems obvious that some proposed improvement could cause more performance slowdown on TOR, the security enhancement and enforcement which these improvement provide is significant. Nevertheless, the proposed improvement in routing and circuit selection have brought some performance enhancement and therefore, the TOR should allow the user the choice between better security or better performances.

5.4.5. The dynamic circuit length results and discussion

The variant length circuit algorithm was implemented into the ExperimenTOR platform and tested in two scenario to produce the following results:

Table 6. The TOR performance in downloading for variable circuit length.

Table 6. The TOR performance in downloading for variable circuit length.

Number of ORs in the circuit	0	1	2	3	4	5
TOR current deployment performance (KB/S)	65.5	39.1	25.3	22.1	19.7	17.4
Proposed enhancement performance (KB/S)	65.5	50.2	39.8	32.9	27.2	25.5

Figure 49. graph representing obtained results for dynamic length circuit usage.

Figure 49. graph representing obtained results for dynamic length circuit usage.

The obtained results, illustrates the performance enhancement of the proposed approach and their impact also on the TOR security. In other word, the proposed improvement produced almost the same performance in a circuit of 4 ORs length as the current TOR implementation for 3 ORs. This improvement have a huge impact on security as the use of 4 ORs circuits will enhance considerably the TOR security and resistance to several attack (FBI, Timing analysis, path selection …etc.) because the likelihood of selecting a malicious (compromised) OR in a specific position within the circuit remains the same. However, the possibility of choosing such OR in the given position into the circuit will decrease as the number of ORs in circuits increase and therefore the number of circuits. Thus, considering the proposed improvements together could strikes a good security-performance balance as the time gained by the proposed encapsulation approach could be later scarified for improving security by introducing the new circuits’ construction and routing approach.

Chapter 6: Conclusion

Frequently used terms and acronyms

References

1. AlSabah, M. and Goldberg, I. (2015). Performance and Security Improvements for Tor: A Survey. Available online: http://eprint.iacr.org/2015/235.
2. AlSabah, M., Bauer, K., Elahi, T. and Goldberg. (2013a). The Path Less Travelled: Overcoming Tor’s Bottlenecks with Traffic Splitting. In Privacy Enhancing Technologies - 13th International Symposium, PETS 2013, Bloomington, IN, USA, July 10-12, 2013. Proceedings. Springer, 143–163.
3. AlSabah, M. and Goldberg, I. (2013b). PCTCP: Per-Circuit TCP-over-IPsec Transport for Anonymous Communication Overlay Networks. In Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security, CCS’13, Berlin, Germany, 349–360.
4. AlSabah, M., Bauer, K., and Goldberg, I. (2012). Enhancing Tor’s Performance Using Real-Time Traffic Classification. In Proceedings of the 19th ACM Conference on Computer and Communications Security (CCS ’12). ACM, New York, NY, USA, 73–84.
5. AlSabah, M., Bauer, K., Goldberg, I., Grunwald, D., McCoy, D., Savage, S. and Voelker, G. (2011). DefenestraTor: Throwing Out Windows in Tor. In Privacy Enhancing Technologies. 11th International Symposium, PETS 2011, Waterloo, ON, Canada, July 27-29, 2011. Proceedings. Springer Berlin Heidelberg, 134–154.
6. Antonakakis, M., Edman, M. and Syverson, P. (2009). As-Awareness in TOR Path Selection. In Proceedings of the 16th ACM Conference on Computer and Communications Security, CCS 2009, Chicago, Illinois, USA, ACM 380–389.
7. Backes, M., Goldberg, I., Kate, A., & Mohammadi, E. (2012). Provably Secure and Practical Onion Routing.
8. Computer Security Foundations Symposium (CSF), 25, 369-385.
9. Bauer, K. and Sherr, M. (2011). ExperimenTor: A Testbed for Safe and Realistic Tor Experimentation. USENIX 2011. Available online: http://www.usenix.org/events/cset11.
10. Bauer, K., Mccoy, D., Sherr, M. and Grunwald, D. (2011). ExperimenTOR: A test-bed for safe and realistic tor experimentation. In Proceedings of the USENIX Workshop on Cyber Security Experimentation and Test (CSET). Bogdanov, A., Lauridsen, M. and Tischhauser, E. (2014). AES-Based Authenticated Encryption Modes in Parallel High-Performance Software. IEEE library.
11. Fu, X. and Ling, Z. (2009). One Cell is enough to break Tor’s Anonymity. White Paper for Black Hat DC 2009. Boyd, W. (2011). A Simulation of Circuit Creation in Tor. Master thesis, submitted at Wesleyan University, Connecticut April, 2011.
12. Benmeziane. S., Badache. N. & Bensimessaoud. S. (2011). Tor Network Limits. International Conference on Network Computing and Information Security, 1, 200-205.
13. Burstein, A. J. (2008). Conducting cyber security research legally and ethically. 1^st USENIX Workshop on Large- Scale Exploits and Emergent Threats, Berkeley, CA, USA, pages 1-8. USENIX Association.
14. Camenisch, J., Lysyanskaya, A. (2005). A formal treatment of onion routing. 25th Annual International Conference in Advances in Cryptology CRYPTO 2005, 169-187.
15. Carnielli, A. and Aiash, M. (2015). Will TOR Achieve its Goals in the Future Internet? An Empirical Study of using TOR with Cloud Computing. 2015 29th International Conference on Advanced Information Networking and Applications Workshops.
16. Casenove, M., Miraglia, A. (2014). Botnet over Tor: The Illusion of Hiding. 6^th International Conference on Cyber Conflict P.Brangetto, M.Maybaum, J.Stinissen (Eds.), NATO CCD COE Publications, Tallinn.
17. Castelluccia, C., De Cristofaro, E. and Perito, D. (2010). Private information disclosure from web searches. In Mikhail J. Atallah and Nicholas J. Hopper, editors, Privacy Enhancing Technologies, 6205 of Lecture Notes in Computer Science, 38-55.
18. Dahal, S., Lee, J., Kang, J. and Shin, S. (2015). Analysis on End-to-End Node Selection Probability in TOR Networking, IEEE ICOIN 2015. ISBN 978-1-4799-8342-1/15.
19. Danezis, G. Diaz, C. and Syverson, P. (2010). Systems for Anonymous Communication. In CRC Handbook of Financial Cryptography and Security, CRC Cryptography and Network Security Series, B. Rosenberg, and D. Stinson (Eds.), 341-390.
20. Darcie, W., Boggs, R., Sammons, J. and Fenger, T. (2013). Online Anonymity: Forensic Analysis of the Tor Browser Bundle. ICDFSC 2013.
21. Dingledine, R. and Mathewson, N. (2016a). TOR Directory Specification. Available online: https://gitweb.etorproject.org/torspec.git/tree/dir-spec.txt (accessed on March 2016).
22. Dingledine, R. and Mathewson, N. (2016b). TOR Protocol Specification. Available online: https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt (accessed on March 2016).
23. Dingledine, R., Mathewson, N. & Syverson, P. (2004). Tor: The Second-Generation Onion Router. 13^th Security Symposium (USENIX), 303–320.
24. Dingledine, R., Mathewson, N., Murdoch, S. & Syverson, P. (2014). Tor: The Second-Generation Onion Router Draft 2014. Available online: http://www.cl.cam.ac.uk/ (accessed on 11 February 2014).
25. Douceur, J. (2002). The Sybil Attack. In: Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS 2002). Volume 2429 of LNCS, Springer.
26. Feigenbaum, J., Johnson, A. and Syverson, P. F. (2007). Probabilistic analysis of onion routing in a black-box model. 6^th ACM Workshop on Privacy in the Electronic Society (WPES), 1–10.
27. Goldberg, I., Stebila, D. and Ustaoglu, B. (2012). Anonymity and one-way authentication in key exchange protocols. IEEE ICPA 2012.
28. Haraty, R.A. & Zantout, B. (2014). The TOR Data Communication System: A Survey. Journal of Communications and Networks, 16, 415-420.
29. Huhta, O. (2014). Linking Tor Circuits. MSc Information Security dissertation submitted to University College London.
30. Jansen, R., Geddes, J., Wacek, C., Sherr, M. and Syverson, P. (2014). US Never Been KIST: Tor’s Congestion Management Blossoms with Kernel-Informed Socket Transport. Proceedings of the 23rd USENIX Security Symposium, San Diego, CA ISBN 978-1-931971-15-7.
31. Johnson, A., Wacek, C., Jansen, R., Sherr, M. and Syverson, P. (2010). Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries, Association for Computing Machinery, ACM, US.
32. Kate, A. and Goldberg, I. (2010). Distributed Private-Key Generators for Identity-Based Cryptography. 7^th Conference on Security and Cryptography for Networks (SCN), 436–453.
33. Krovetz, T. and Rogaway, P. (2014).OCB implementation and performance analysis. IETF RFC publications. Lazzari, M. (2014). Systematic Testing of Tor. Submitted as Master Thesis, ETH Zurich.
34. Ling, Z., Luo, J., Yu, W. and Fu, X. (2011). Equal-sized Cells Mean Equal-sized Packets in TOR. IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings.
35. Marquis, M. (2013). For their eyes only. The Commercialization of Digital Spying citizen lab Canada global security research.
36. Mccoy, D., Bauer, K., Grunwald, D., Kohno, T. and Sicker, D. (2008). Shining light in dark places: Understanding the tor network. 8^th international symposium on Privacy Enhancing Technologies, PETS '08, 63-76, Berlin.
37. Murdoch, S. and Watson, R. (2007). Metrics for Security and Performance in Low-Latency Anonymity Systems. University of Cambridge, UK.
38. Nia, M.A., Karbasi, A.H. & Atani, R.E. (2014). Stop Tracking Me: An anti-detection type solution for anonymous data. 4^th International eConference on Computer and Knowledge Engineering (ICCKE), 14, 685-690.
39. Øverlier, L. and Syverson, P. (2006). Locating hidden servers. In Proceedings of the 2006 IEEE Symposium on Security and Privacy, Oakland, CA, US, IEEE Computer Society.
40. Perry, M. (2007). Securing the Tor Network, Black Hat USA 2007 Supplementary Handout.
41. Reardon, J. and Goldberg, I. (2010). Improving TOR using a TCP-over-DTLS Tunnel. TOR project research papers. Available online: https://gitweb.etorproject.org.
42. Schanck, J., Whyte, W. and Zhang, Z. (2015). A quantum-safe circuit-extension handshake for Tor. Security innovation white paper.
43. Singh, S. (2015). Large-Scale Emulation of Anonymous Communication Networks. Matser thesis presented to the University of Waterloo.
44. Snader, R. and Borisov, N. (2008). A tune-up for Tor: Improving security and performance in the Tor network. Network & Distributed System Security Symposium, Interne Society.
45. Soghoian, C. (2011). Enforced Community Standards for Research on Users of the Tor Anonymity Network.
46. Second Workshop on Ethics in Computer Security Research WECSR, 02, St. Lucia.
47. Stupples, D. (2013). Security Challenge of TOR and the Deep Web. The 8th International Conference for Internet Technology and Secured Transactions ICITST 2013.
48. Svenda, P. (2012). Basic comparison of Modes for Authenticated-Encryption (IAPM, XCBC, OCB, CCM, EAX, CWC, GCM, PCFB, CS). Masaryk University in Brno.
49. Syverson, S., Goldschlog, D. and Reeds, M. (1997). Anonymous connections and onion routing. Proceedings of the IEEE Symposium on Security and Privacy, USA, 482-494.
50. TOR Deployment. (2016). TOR network detailed deployment. Available online: https://abouttor.tor.org (accessed on April 2016).
51. TOR Flow. (2016). TOR flux across the world. Available online: https://torflow.uncharted.software (accessed on April 2016).
52. TOR Project. (2016). TOR active users number in UK. Available online: https://metrics.torproject.org (accessed on April 2016).
53. TOR Metrics. (2016). TOR Network overall bandwidth. Available online: https://metrics.torproject.org/bandwidth.html (accessed on April 2016).
54. Wacek, C., Tan, H., Bauer, K. and Sherr, M. (2013). An Empirical Evaluation of Relay Selection in TOR. In Proceedings of the Network and Distributed System Security Symposium - NDSS’13, The Internet Society.
55. Yenuguvanilanka, J. and Elkeelany, O. (2007). Performance Evaluation of Hardware Models of Advanced Encryption Standard (AES) Algorithm. Tennessee Tech University.
56. Zhang, Y. (2009). Effective attacks in the tor authentication protocol. 3^th International Conference on Network and System Security, 09, 81-86.