Just been doing some reading about Tor (http://www.torproject.org/) – an open source anonymizing network implementation.  Anonymous in the sense that, for example, the identity (IP address, platform/version info) of a browser client on one end of the network could be hidden from a web server on the other end.  That information, as well as the association between the client and the resource requested, is also theoretically hidden from eavesdroppers. 

Tor is based on “onion routing” (http://en.wikipedia.org/wiki/Onion_routing) research funded (at least partially) by the US Navy.  More on the onion metaphor below.

Check out the Tor Usenix paper (http://www.torproject.org/svn/trunk/doc/design-paper/tor-design.pdf), especially if you’re a crypto weenie like me (although that’s not a requirement for appreciating the paper).  In summary, Tor is cool because it attempts to provide anonymity via the following mechanisms:

1.       A client application-layer proxy which strips identifying information from outbound requests.
2.       A list of nodes, or Onion Routers (OR), which are available to form dynamic circuits via which traffic is routed.  As each circuit is built (for example by a client that wishes to contact a web server), the client performs a key exchange with the included nodes, which are selected more or less randomly.  Once the circuit is established, it’s relatively short lived (say, a minute), and the client wraps each request (e.g. for the page from the web server) in a message, or “cell,” successively encrypted to each node in the circuit.  The inner-most message is encrypted to the last node in the circuit and the outer-most message is encrypted to the first node in the circuit.  Think of those encrypted, or wrapped, messages as layers of an onion …
3.       A list of trusted directory servers, which provides the list of ORs.

Admittedly, I’m not doing the whole system justice with such a short description; read the paper.

There are some concerns among the security community regarding such networks.  Overall, I’ve heard two main ones:

1.       The critical mass – in terms of number of OR nodes required in order to provide reasonable, practical anonymity – exceeds the current deployment.  Too few ORs means that one compromised node is more likely to be the entry or exit node in a given circuit.  This betrays the requester in the entry case, or the resource requested (as well as all of the data, if a separate application layer security solution, such as TLS, isn’t in use) in the exit case.  For more information, in the Usenix paper, see “Run a hostile OR,” 2nd colomn, page 12.
2.       The tradeoff of providing tools for the good guys is that the bad guys use them too.  This seem argument gets used against encrypted email and pentesting tools.  For Tor, OR exit policies are claimed to be one mitigation (in the Usenix paper, see the bottom of first colomn, page 10) – in other words, OR operators can elect whether to be an exit node at all, and if so, what resources are allowed to be requested through the node. 

Actually, my biggest concern is the question of control of the directory servers.  Again, the purpose of the directory servers is to list which ORs are available and trusted.  Supposing that the servers might disagree on that list, a threshold system has been implemented (in Tor).  That is, the directory list must be digitally signed and agreed-upon across a minimum number of servers.  But caching of that list is also a supported feature, and that raises questions about key revocation (and then time-stamping, etc).

No Comments »