[tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

[Jeff Burdges]

On 12 May 2015, at 10:39, Michael Rogers <michael at briarproject.org> wrote:
> Something like this was suggested last May, and a concern was raised
> about a malicious IP repeatedly killing the long-term circuit in order
> to cause the HS to rebuild it. If the HS were ever to rebuild the
> circuit through a malicious middle node, the adversary would learn the
> identity of the HS's guard.
> 
> I don't know whether that's a serious enough threat to outweigh the
> benefits of this idea, but I thought it should be mentioned.

Just to clarify :

In any HS redesign, the issue a malicious IP could always tear down a circuit to force selecting a new middle node.  If that’s done enough, then the middle node could be pushed into a desired of malicious middle nodes.  A malicious IP is potentially prevented from doing this in 224 because the HS could choose another IP to publish the HSDirs if circuits to an IP keep collapsing.  There is no way for the HS to choose another IP in John Brooks proposal though.

As I understand it, an IP is the fourth hop from the HS so the IP won’t see the middle node directly, but the malicious IP and malicious middle node set can do a correlation attack.  It’s an advanced attack, but very doable.  In particular, the malicious IP and middle node set need not coordinate in real time.  I donno if anything prevents a large malicious node set form surveying many HS guards.

Two alternatives come to mind :

(1)  A HS could simply possess more IPs and drop a suspicious one or two.  I donno if this places an undo burden on the network.  Not the spec/code to drop a suspicious IP is as almost complex as the code to replace a suspicious IP.

(2)  A HS could trust its IP less by using a longer circuit and partially pinning the second hop (first middle node) similarly to how it pins guards now.  Again this places slightly more burden on the network, but not necessarily much.  This might be quite simple to do.


Also, what prevents a malicious client and malicious middle node set from doing the same correlation attack only over the rendezvous circuit rather than the IP circuit?  Is there anything besides partially pinning the second hop ala (2) that’d achieve that?  Except, the rendezvous circuit carries heavy traffic, unlike the introduction circuit, so we’re presumably less willing to lengthen it.


Alright, what if we collaboratively select the RP as follows :

Drop the HSDirs and select IPs the way 224 selects HSDirs, like John Brooks suggests.  Protect HSs from malicious IPs by partially pinning their second hop, ala (2).

An HS opening a circuit to an IP shares with it a new random number y.  I donno if y could be a hash of an existing shared random value, maybe, maybe not.

A client contacts a hidden services as follows :
- Select an IP for the HS and open a circuit to it.
- Send HS a random number w, encrypted so the IP cannot see it.
- Send IP a ReqRand packet identifying the HS connection.

An IP responds to ReqRand packet as follows :
- We define a function h_c(x,y) = hash(x++y++c), or maybe some hmac-like construction, where c is a value dependent upon the current consensus.
- Generate z = h_c(x,y) where x is a new random number.
- Send the client z and send the HS both x and z.

An HS verifies that z = h_c(x,y).

Finally, the client and HS determine the RP to build the circuit using h_c(z,w) similarly to how 224 selects HSDirs.

In this way, both client and HS are confident that the RP was selected randomly, buying us an extra hop on the rendezvous circuit that the HS can use to partially pin its second hop on RP circuits.  In other words, the HS can select its third hop more like it’d currently select its middle node.

There are attacks on this scheme if the IP can (a) break the encryption used for w and (b) very quickly attack the hash function used in h_c, but that’s probably fine.

Jeff

p.s.  I donno if all this hop pinning creates observable traffic characteristics that lead to other attacks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150512/d9fb7a2b/attachment.sig>