Tor—Key Management, Security,and Design

Tor key management

The only long-lived onion router keys in Tor are a router’s identity key pair. The identity verification key is stored by Tor’s centralized directory servers, which are the entities governing the Tor network. These are all run by independent parties whose primary role is to decide which onion routers can join the Tor network.

A router’s onion public key is signed (along with other data relating to its capabilities within the Tor network) using its identity signature key. The directory servers each check the validity of the onion public key and only make it available if they are confident it is valid and the router is able to accept connections as claimed. Directory servers publish the data they hold, and users of Tor accept the validity of this information only if a majority of directory servers agree. To minimize the impact of key compromise, each router regularly changes its onion key pair.

The other keys used by an onion router are all short-lived. A router’s connection key pair is changed daily. All symmetric keys used in Tor are ephemeral, meaning they are only established for particular Tor sessions and are then immediately discarded. It is also worth noting that Tor exhibits good key separation by having separate unidirectional keys for encryption and integrity checking.

Tor security issues

The cryptography used in Tor is mostly well recognized, although some slightly ad hoc techniques are used. The main security issues with Tor relate to limitations in the degree of anonymity it provides. However, it should be noted that these are all limitations by design and that Tor was never intended to overcome them.

The biggest security problem with Tor is that, while communication is well protected as it passes from router to router, anyone with access to both endpoints can analyze and try to match traffic entering and exiting the Tor network. They could do this by looking at, for example, the amount and timing of the information being exchanged. This is beyond the scope of Tor to prevent.

The distributed nature of the Tor network brings a degree of resilience since there are no single points of failure. However, any adversary who can control a substantial proportion of Tor routers will compromise the anonymity of some Tor users. The Tor network is governed in a way which tries to reduce the chances of this happening, but it cannot be completely prevented.

Tor design considerations

From a cryptographic perspective, several Tor design considerations are worth highlighting:

• Use of respected components: For the most part, Tor is built from respectable cryptographic components. As an open-source project designed to be widely trusted and used, the adoption (for the most part) of standard components is appropriate and arguably necessary.

• Efficiency over security: A critical design aspect of Tor is to make sure that Tor is efficient both to run (for Tor users) and support (for volunteer onion routers). Tor is thus deliberately designed to place low overhead costs on all parties, in some cases at the expense of security. One example of this is the use of reduced length integrity digests in the Tor communication protocol.

• Perfect forward secrecy: Tor is an example of an application where perfect forward secrecy is important from a design perspective. Tor provides this by using Diffie-Hellman key agreement both within SSL/TLS and during the Tor key establishment protocol, and regularly changing onion key pairs.

• Evolving design: Tor is an evolving project rather than a fixed design. One example of it’s evolution is the addition of a second key establishment method, which is more secure and more efficient than the original one. Another is the development of anti-censorship techniques for masking the fact that a user is deploying Tor.

• Engineered design: Overall, Tor has been well engineered. That said, certain aspects of the design seem somewhat inelegant. For example, each communication involves four separate layers of encryption (one by SSL/TLS and three by Tor), while data integrity is provided using two different techniques (one by SSL/TLS and one by Tor). This all works, but it is certainly conceivable that a more elegant, potentially more secure, and probably more efficient design could be produced in the future.