34

Me -> Node A -> Node B -> Node C -> destination

The documentation on Tor always states that only the exit node C can see plain text data. How is this possible without me talking to Node C directly?

If I have some plain text data, and want to send it encrypted to Node A, I'd usually do a Diffie-Hellman key exchange, and send the data over. But with that scheme, Node A could decrypt the data.

If Node C was somehow sharing its public key with me, couldn't Node B or Node A MITM the key?

How exactly does Tor manage its PKI? What keys are used to encrypt data where?

Rahil Arora
  • 4,307
  • 2
  • 23
  • 41
Petey B
  • 607
  • 1
  • 6
  • 8
  • [This Answer](http://security.stackexchange.com/questions/27845/how-is-tor-secure/27851#27851) gives a slightly different analogy. In answer to your question: Node C is able to open the red box, in which is contained the plain text 'Nasty Letter'. – lynks May 28 '13 at 16:20

3 Answers3

58

Tor uses a routing method called Onion routing. Much like an onion, each message (the core of the onion) is covered with layers of encryption. attrib:wikipediaimage attribution

Your message is encrypted several times before it leaves your device. Node A can only decrypt (peel) the layer A, under which it would see the address of the next node. After the packet reaches the next node, it can only decrypt (peel) layer B, and so on. For each layer, you use the respective node's public key, so only that exact node can decrypt the layer with its own private key.

When the message reaches the exit node, all of the layers have been decrypted and message is now in plaintext (it could also be encrypted if you're communicating with the server under SSL).

Adi
  • 43,953
  • 16
  • 137
  • 168
  • 19
    Bloody marvelous image, looks like a nuclear reactor core with a fuel rod inserted into it! – TildalWave May 28 '13 at 15:34
  • 2
    +1 just for the image. I've been looking for a good visual representation of Tor onion routing for a long time. – Polynomial May 28 '13 at 16:09
  • Okay so TOR relies on a PKI directory to hold all public keys? The public keys for each router are pulled by the client and used to encrypt the data. How about on the return trip? Does the exit node pull all keys down from the directory and perform the same operation in reverse? How does router C get the client public key? Are client keys stored in the PKI directory as well? – Petey B May 28 '13 at 16:09
  • 3
    @PeteyB There is no "return trip". The routing creates a TCP connection chain, which is full-duplex. – Polynomial May 28 '13 at 16:16
  • 1
    @PeteyB TOR does not use PKI in the sense of global CAs. TOR keys and Node IPs are distributed by the TOR project. This distribution is protected by hard-coded public keys in the TOR software. – lynks May 28 '13 at 16:17
  • 4
    I agree with Petey B, the return path of the TCP connection is kind of "hand waved" away. Could you update your answer to give a better explanation of how a reply packet (even something as simple as the `SYN-ACK` packet of the 3 way handshake) on the TCP connection is sent back through the tor network and get to the original sender? – Scott Chamberlain May 29 '13 at 00:44
  • 2
    @ScottChamberlain There is no end-to-end TCP connection. Tor handles data in logical Streams, so each hop is free to fragment or combine data as it sees fit (though for intermediate hops this would likely break the crypto). In other words, the client only establishes a TCP session with the first hop. Everything from there out is a Stream, just like using a SOCKS proxy. – bonsaiviking Jun 23 '13 at 00:44
  • 1
    @bonsaiviking Ahh, I see. You are the first person ever to be able to explain that. So its `Me<--(TCP connection 1)-->Tor Entry point<--(Tor Protocol Stream)-->Tor Server<--(Tor Protocol Stream)-->Tor Server<--(Tor Protocol Stream)->Tor Exit Point<--(TCP connection 2)-->Destination Server` So I only have a TCP connection to the entry point and the final destination only has a TCP connection to the exit point. – Scott Chamberlain Jun 23 '13 at 00:47
  • 1
    @ScottChamberlain right. Naturally there are TCP connections between each of the hops, but it's not really relevant; that's just the transport that TLS uses. Same reason you don't have to know whether packets between UK and US use a sub-oceanic cable or satellite, ATM or SONET or whatever, because it's at a lower protocol level. – bonsaiviking Jun 23 '13 at 00:52
  • This is a brilliant way of clarifying why an exit node can identify the destination and not the origin. Thanks! – Mirodinho Dec 07 '17 at 23:52
  • @ScottChamberlain And the Tor entry point is your own computer! (if you're not stupid). So there is nobody else who sees that TCP connection. – user253751 Apr 14 '21 at 13:53
17

TOR uses the principle of onion routing. Let us say there are 3 TOR nodes A,B and C involved (selected randomly by client) and the message is m. We assume the corresponding public keys of these nodes to be Pa,Pb and Pc.

The message is repeatedly encrypted by the client starting with the public key of the exit node (Pc) followed by Pb and in the end Pa (Onion Routing).

Data received by node A: Pa(Pb(Pc(m))) 
Data received by node B: Pb(Pc(m)) 
Data received by node C: Pc(m)

The data is decrypted at each node by using their corresponding private key. After decryption each node gets some plain-text information about where to forward the remaining data. This makes sure that no single node knows the entire path. Each node only knows about the previous and the next node.

p.s. There is a very good article on TOR in our community blog but somehow I am not able to find it. If anybody finds the link please add it to the answer.

Shurmajee
  • 7,335
  • 5
  • 28
  • 59
  • +1 for the pseudocode. Makes it much clearer. – Adi May 28 '13 at 16:07
  • Commenting on both answers for visibility: Okay so TOR relies on a PKI directory to hold all public keys? The public keys for each router are pulled by the client and used to encrypt the data. How about on the return trip? Does the exit node pull all keys down from the directory and perform the same operation in reverse? How does router C get the client public key? Are client keys stored in the PKI directory as well? – Petey B May 28 '13 at 16:11
  • @PeteyB router C does not need the client's public key.The onion routing involves the public keys of the nodes and not the client. as mentioned in another comment a TCP connection is created by routing. – Shurmajee May 28 '13 at 16:20
  • 1
    @MayankSharma Maybe I'm being silly: So how are packets encrypted on the return path? If they're simply encrypted with the nodes' private keys, then any packet caught between two nodes could be decrypted rather easily by anyone with a snapshot of the node pubkeys at that time?! – us2012 May 28 '13 at 23:11
  • @us2012 No,NO,NO the packets are encrypted using public keys of the nodes so that only the respective nodes can decrypt them. Please re-read the answer :) – Shurmajee May 29 '13 at 04:19
  • @MayankSharma I get that, but how does that work for the data *on the return path*, i.e. on the way from node C back to the client?! How is the data that is going from node A to the client encrypted? – us2012 May 31 '13 at 11:41
  • @us2012: Perhaps it uses the same public keys in reverse order? – szx Jun 01 '13 at 17:02
  • @szx How would that help? If you, as a client, received data encrypted with a node's *public* key, you could not decrypt it. – us2012 Jun 01 '13 at 20:31
  • 1
    @us2012 The crypto involved is TLS. Public-key crypto is only used to establish a symmetric session key between two endpoints. When the whole chain is complete, the client has separate TLS connections with each of the 3 hops, most of which are tunneled through the others. – bonsaiviking Jun 23 '13 at 00:49
1

There are two different question here :
1- how do we send data and how nodes decrypt each layer of encryption?
2- how do we get data from exit node?
About first question, I can say there is no public key encryption for sending data to destination, But Shared Secrets. Before this you should know enough about D-H.
D-H steps:

  1. Alice and Bob agree on a finite cyclic group G and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) We will write the group G multiplicatively.
  2. Alice picks a random natural number a and sends g^a to Bob.
  3. Bob picks a random natural number b and sends g^b to Alice.
  4. Alice computes (g^b)^a.
  5. Bob computes (g^a)^b.

After these steps Alice and Bob have a Shared Secret s and no one knows about this Shared Secret.

Tor Steps :

  1. OP(onion proxy or source) sends g^a to Node1(onion router).(but encrypted by Node1's public key)
  2. Node1 decrypts data with private key and then sends g^b to OP.(in clear text. because if OP's public key known to ORs then where is privacy!!).
  3. Now OP and Node1 have a Shared Secret.[e.g: SS1 = OP & Node1 = 2].
  4. OP sends g^a to Node1 which Node1 should send that to Node2.('a' is a new random number)
    OP encrypts g^a with Node2 Public Key, and encrypts data(en(g^a) and Node2 address) with SS1.
  5. Node1 decrypts data with SS1 and gets Node2 address, and sends remaining encrypted g^a to Node2.
  6. Node2 decrypts data with her private key, and then sends g^b to Node1 again.(clear text)
  7. Node1 encrypts g^b with SS1 and sends to OP.
  8. OP decrypts data with SS1.
  9. Now OP and Node2 have a Shared Secret which Node1 doesn't know.[e.g: SS2 = OP & Node2 = 5].

This will be continued until the circuit complete.now OP can send request for destination through Nodes with (SS1, SS2 , ...). last sending request should be like this :

OP to Node1 => encryptSS1(send to Node2, encryptSS2(send to destination, "hello server"))

And about second question receiving response should be like this :

  1. Dest to Node2 => "hello client"
  2. Node2 to Node1 => encryptSS2("hello client")
  3. Node1 to OP => encryptSS1(encryptSS2("hello client"))
  4. OP decryptSS1(decryptSS2(data)).

Take a look at an image on this page :
Onion routing - pikneek

M Rostami
  • 111
  • 2