John Denker writes:
> 1b') When the pool is depleted, /dev/urandom acts like a PRNG but reseeds
> itself in dribs and drabs as TRNG entropy becomes available. This leaves
> it vulnerable to an iterated guessing attack.
The question is whether this is a realistic attack.
> 2a) Suppose some poor sysadmin leaves a *widely-readable* copy of the
> keyfile around somewhere, then fixes it by making it root-readable only,
> without being smart enough to totally reseed at that point.
The system is shipped with the /dev/random state file protected 600,
at least on Red Hat (see /etc/rc.d/init.d/random). It is reset to that
state every startup and shutdown. A sysadmin would have to manually
change that file's permissions after startup and then get his machine
hacked. This seems pretty far-fetched.
> 2b) Suppose the attacker briefly gets root access. Such an attacker
> *could* do something much worse than merely reading the keyfile -- but
> might be afraid to. Altering the system has to be done very carefully or
> it will leave fingerprints.
It's not really a matter of reading a "key file". The state file,
/var/run/random-seed, saves random state from shutdown to startup.
If an attacker read this shortly after boot he might be able to infer
the present state, if little randomness had been added so far. However
if the machine has been booted long enough ago that considerable
randomness has come in, reading this file will not help.
What he can do as root is to read the kernel memory and dump out the
internal /dev/random pool itself. This is up to date, so he can then
use the state-following attack if enough random data is being exposed
to him and randomness comes in slowly enough.
Given that he is doing this, he could probably patch the kernel in
memory as well. Granted this takes a little more work, but if he is
able to find the random pool in memory he can probably also find the
kernel code. There are a number of changes he could make which would
disable adding more entropy into the pool, for example, like patching a
return instruction onto the entropy point for the function that actually
adds entropy.
It's questionable whether a redesign of /dev/random is necessary to deal
with an attack where we have to assume that the attacker is pulling his
punches like this. The ability to find the random pool in memory and
dump it out is not that much less than the ability to patch out a few
instructions. You're not raising the bar by much with this quantized
reseeding layer.
If it's really easy, okay, but don't kid yourself that you're gaining
much safety.
