Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' lastfew uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Sun, May 18, 2008 at 12:13:35PM +0200, Andi Kleen wrote:
> We don't use it for most long term keys, e.g. ssh host keys. That is
> because even on high entropy systems /dev/random usually doesn't work
> during distribution installation because the system has not run long
> enough to collect significant entropy yet.

One thing which I'm not sure most people understand is that there
isn't that much difference between /dev/random and /dev/urandom.  They
are fed by the same sources, at the high level.  There is a single
large entropy pool which gets fed by whatever entropy sources the
kernel can get its hands on, which periodically catastrophically seeds
separate smaller pools used by /dev/random and /dev/urandom.  The only
difference is that /dev/random does entropy tracking; /dev/urandom
doesn't.

Hence, if you don't think the system hasn't run long enough to collect
significant entropy, you need to distinguish between "has run long
enough to collect entropy which is causes the entropy credits using a
somewhat estimation system where we try to be conservative such that
/dev/random will let you extract the number of bits you need", and
"has run long enough to collect entropy which is unpredictable by an
outside attacker such that host keys generated by /dev/urandom really
are secure".

See why the qualifying statements is so important?  If you really
believe that there isn't enough entropy after installing a
distribution, THEN YOU SHOULDN'T BE GENERATING SSH HOST KEYS.  The
problem is that the server scenario with no keyboard case is a really
nasty one.

> See also the distinction between "user controlled visible cryptography"
> and "background cryptography" I introduced in a earlier mail on that
> topic. gpg can only get away with it because they rely on a high level
> of user education (so requiring banging on keys is ok), but that's
> not really an option for your normal "everyday background crypto",
> including longer term keys.

No, this distinction is a specious one, I think.  It's really more a
level of paranoia.  People tend to be much more paranoid about their
own personal keys, at leasts if they are well trained.  Most people
don't bother verifying ssh host keys the first time they contact a
host, making them subject to a man-in-the-middle attack.  But most
people don't mind, by which we can deduce that most folks aren't as
careful about their ssh key.

If distributions really cared, they could very well introduce keyboard
banging as part of the install process; but no, being able to do an
unmanned, "turnkey" install is considered more important.  That says
something about how much they care about security right there.  (By
the way, if you are at least forcing the user to type in a root
password, having the distribution installer mix in the root password
into /dev/random would be a Really Good Idea; also, mixing in whatever
randomness it can get from the mouse during the install is also a
Really Good Idea.)

> Instead I think just both urandom and random should try to rely
> on TPMs and other hardware rngs and always get high quality bit noise.

Sure, if you can get access to a TPM or a hardware rng, that's
*always* a better choice.  But the reason for /dev/random and
/dev/urandom's existence is that hardware manufacturers have either
not included a real hardware RNG, or made it impossible to get to it.
(I *still* haven't figured out how to access my TPM on my Lenovo
laptops.  Anyone who can send me turn-key instructions, let me know
off-line.)  Intel used to provide a true hardware RNG in their
chipsets a few years ago (props to them), but then stopped after one
generation (boo, hiss).

If there is a way that we can at least seed /dev/random from the TPM
(without needing any magic enabling keys, etc.) once at boot time, and
then rely on what we can get from the environment, maybe we can do it
in the kernel without needing to move all of the TPM access/contention
control logic from userspace into the kernel.

Of course, even if we did this, it wouldn't solve the distro problem
(at least for distro's who truly care about the security of ssh host
keys), since not all systems have TPM's.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/