[Cryptography] TRNG related review: rngd and /dev/random

[Jason Cooper]

Hey Bill,

On Wed, Jan 20, 2016 at 08:09:03AM -0800, Bill Cox wrote:
> On Wed, Jan 20, 2016 at 6:01 AM, Jason Cooper <cryptography at lakedaemon.net>
> wrote:
> 
> > This isn't a realistic scenario.  An attacker "who knows the initial
> > state of the entropy pool (which is a file on disk)" either has physical
> > access to the system or root.  In either case, it's game over, she can
> > just read the keys.
> 
> 
> I may be wrong about this, but the threat-case where I think this matters
> is when an attacker gets access to the machine, learns the state of the
> entropy pool, and then loses access.  Can the machine recover?

Why?  What is the target of the attacker?  If it's the longterm keys,
then she reads them.  Damage is done.  Again we need to presume she has
root access.

If the goal is longterm access, then she lays a backdoor that survives
reboots.

If the goal is to passively decrypt traffic originating from the box
*without* future access to the box, then there might be something to
this scenario.

  - she reads random_seed
  - wait for reboot
  - attempt to decrypt traffic she captures

I'm going to say that in most situations, this will fail.  The first
reason is that environmental entropy (interrupt/timer derived) will stir
the pool enough that by the time the known random_seed is added, the
pool state is unguessable to the attacker.

The second is that /etc/init.d/urandom overwrites random_seed on clean
*shutdown* as well.  The known random_seed would never be used in this
case.

The third is that in modern systems (containing RDRAND), random.c mixes
in data from RDRAND, see drivers/char/random.c:894
(add_interrupt_randomness())

        /*
         * If we have architectural seed generator, produce a seed and
         * add it to the pool.  For the sake of paranoia don't let the
         * architectural seed generator dominate the input from the
         * interrupt noise.
         */
        if (arch_get_random_seed_long(&seed)) {
                __mix_pool_bytes(r, &seed, sizeof(seed));
                credit = 1;
        }

Wether you choose to trust RDRAND or not, mixing it with /other/ sources
of entropy makes for a much more un-guessable pool state.

> If only 1 random bit per second is fed into /dev/random, but keys and IVs
> are extracted from /dev/urandom at a bit-rate far higher than this, and if
> the attacker remains as an eavesdropper on the network and can see the
> results of every read to /dev/urandom, then the attacker needs only to make
> a few guesses per second to keep the attacker's copy of the entropy pool
> synced to the server's.  Is this right?

I think the addition of arch_get_random_seed_long() thwarts this
scenario.  But please take a closer look to see if I've made a bad
assumption.

Note: in the scenario above, she /could/ hard reboot the box, since she
has root access.  But I'm pretty sure someone would notice that.  Then
there's the rabbit hole of "well, she could re-write the urandom init
script", or "... favorite root access change ...".  It all boils down to
physical access/root access trumps all.

thx,

Jason.