[tor-dev] is the consensus document unpredictable / unique?

Tue Jun 28 23:22:49 UTC 2016

> On 28 Jun 2016, at 21:36, Razvan Dragomirescu <razvan.dragomirescu at veri.fi> wrote:
> 
> Thank you Tim,
> 
> I've been thinking about it and it looks like an easy fix for the problem would be to prevent the rogue DA from farming out the hash calculations or generating a lot of them in the 5 min voting window. If the hash only depends on public info (consensus data, current date, etc), you can't prevent this. But if the hash includes a shared secret key _inside the smartcard_, the attacker has to ask the smartcard to compute the hash and that's orders of magnitude slower than a computer (and can be made artificially slower by burning some CPU cycles inside the card doing RSA key generations or something - it has no internal clock so you can't just "sleep", but you can give it something time-consuming to do before it computes the hash).
> 
> So here's the new setup I have in mind:
> 
> 1. Each card can be provisioned with a "network key". This is a value that all cards (and nodes) that are part of a given network share. It can only be set, not read and can be used in the computation of the Descriptor Cookie.
> 
> 2. The descriptor cookie will be calculated as H ( network-key | timestamp (rounded down to a full hour) | H (consensus) )
> 
> The terminal provides the current consensus hash and a timestamp. The card checks that the timestamp is greater than the last timestamp it has used. It then concatenates the secret network-key, the given timestamp and the consensus hash and returns the hash of the result.
> 
> This means a few things:
> 
> 1. An attacker can no longer generate a hash independently or farm it out to other computers. It has to ask a smartcard to do it. We can make this arbitrarily slow since the operation is only meant to be done once an hour, so I could make it take a minute per hash inside the card.
> 
> 2. Generating a hash for a future date would lock you out until that date/time (since decreasing timestamps will be refused by the card). You could compute the correct hash for the current timestamp and consensus on another card, but you would not be able to generate a signed descriptor with that correct hash (you can't inject a hash computed somewhere else into the signed descriptor).
> 
> 3. The card doesn't have to parse the consensus - it just uses it as a shared random value (the hash of the consensus).
> 
> Makes sense?

There are now so many moving parts in this scheme, I think you need to specify it all in one place, and then convince a cryptographer to review it. (I am not a cryptographer.) And then have your implementation reviewed against the spec.

How is the card you're using for side-channels?
Keys have beed extracted using power usage information, or electromagnetic emissions, or even audio.

Tim

> 
> Thank you,
> Razvan
> 
> 
> On Tue, Jun 28, 2016 at 6:02 AM, Tim Wilson-Brown - teor <teor2345 at gmail.com> wrote:
> 
> > On 28 Jun 2016, at 05:30, Razvan Dragomirescu <razvan.dragomirescu at veri.fi> wrote:
> >
> > Thank you Tim,
> >
> > As long as a malicious authority cannot choose a hash that is identical to an older consensus hash, I think the system should be fine. In addition, I can have the the smartcard look at one of the valid-* dates in the consensus and hash that into the descriptor cookie as well - I'm guessing a rogue authority can mess with the consensus hash but cannot change the valid-after, valid-until, etc dates. If I enforce increasing dates (so that you cannot go back in time, once you've seen a consensus for Jan 2017 for instance you cannot sign another one from June 2016), if you attempt to pre-generate a signature for a future date, you lose connectivity until that particular date.
> 
> >
> > On 28 Jun 2016, at 06:16, Razvan Dragomirescu <razvan.dragomirescu at veri.fi> wrote:
> >
> > 1. I've just realized that hashing the current valid-* dates into the descriptor cookie doesn't help - those values are known to the attacker and he can tweak his vote to generate a certain hash regardless of that date. The rest of what I've said applies just fine.
> 
> You could have your smart card parse a consensus and check the dates are on or after previous signed dates, before signing a descriptor for those dates. But text parsing is error-prone.
> 
> > I also plan to enforce an upper limit on the number of RSA signatures the card can perform with a given key. SIM cards already do this to prevent brute force attacks.
> 
> You might actually want to limit the number of signatures per-hour as well.
> But no-one has statistics for the number of hidden service descriptors per service per hour, as far as I know.
> It's likely somewhere between 0 and 10.
> 
> > If you don't have access to the smartcard and if you've somehow pre-generated some signed descriptors, those will only work for 1 hour (a very specific hour in the future that you've simulated consensus for and somehow tricked an authority into making the consensus hash be exactly the one you're expecting).
> >
> > What I like about the consensus (vs shared random value) is that it's regenerated every hour, so a successful attack would have very limited impact (1 hour sometime in the future). Shared random values are generated once per day, so if the attacker somehow guesses them successfully, he can pretend to be another node for a full day.
> 
> An hour is enough to de-anonymise a lot of clients.
> 
> The shared random value lasts for a day, because all clients and hidden services and hidden service directories need to agree on it, and need to cache valid descriptors for a reasonable period of time.
> 
> If an attacker is capable of guessing a 256-bit random value… seems exceedingly unlikely.
> If an attacker is capable of calculating a 256-bit shared random value, which depends on the private state of the 9 directory authorities, and even that state is only created 24 hours in advance…  again, seems unlikely, and it only works 24 hours in advance.
> 
> > As a second security layer, once the communication is established, the two nodes can negotiate a shared symmetrical key (based on the same RSA keypairs they use as permanent keys for hidden services or a different keypair). This way, a successful attacker can only launch a Denial of Service type of attack (preventing the legitimate node from getting the traffic) but cannot decrypt or encrypt traffic from/to that node.
> 
> An attacker can prevent the node from getting some of the traffic. Typically, the attacker will control the descriptor on each of the 6 hidden service directories until the hidden service uploads a new one. All connections made by clients using attacker-controlled descriptors will go to the attacker's introduction points.
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> ricochet:ekmygaiu4rzgsk6n
> 
> 
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n

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