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

Tue Jun 28 11:36:38 UTC 2016

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?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160628/638ff9f8/attachment.html>