Likes: 0
I recently installed Red Hat Linux 9 and noticed on the first boot a
message about generating ssh host keys. Isn't that a dangerous thing
to do on the first boot? Where is the installation going to get
enough good entropy so early in its life?
Maybe the paranoid thing to do is, as part of configuring a machine,
to regenerate those keys once user interaction (or other entropy
source) has had time to really stir the Linux entropy pool.
-kb
On Fri, Jul 25, 2003 at 11:29:51AM -0700, Crispin Cowan wrote:
> SSH is likely getting it's entropy from /dev/random. The kernel will
> decide whether there is enough entropy in the /dev/random entropy pool,
> and block reads until the pool fills.
The last time I looked at SSH and OpenSSL, their random number
generation was disappointing. It seemed that OpenSSL generated random
numbers (and even keys) by grabbing a single 16 byte seed at startup
(!) from /dev/urandom (!). Then this seed was run through OpenSSL's
MD5-based random number generator.
I don't know if this is still true. I found the following comment in
OpenSSL's CHANGES file:
*) Change the Unix RAND_poll() variant to be able to poll several random devices, as specified by DEVRANDOM, until a sufficient amount
of data has been collected. We spend at most 10 ms on each file
(select timeout) and read in non-blocking mode. DEVRANDOM now
defaults to the list "/dev/urandom", "/dev/random", "/dev/srandom"
(previously it was just the string "/dev/urandom"), so on typical
platforms the 10 ms delay will never occur.
Also separate out the Unix variant to its own file, rand_unix.c.
For VMS, there's a currently-empty rand_vms.c.
[Richard Levitte]
I also found this comment in rand_unix.c:
/* Use a random entropy pool device. Linux, FreeBSD and OpenBSD
* have this. Use /dev/urandom if you can as /dev/random may block
* if it runs out of random entries. */
Looking back over the codebases, it appears that OpenSSH uses
arc4random() extensively. The version of arc4random provided with this
Linux port of OpenSSH uses OpenSSL's RNG for seeding. However, the
only time sshd ever seeds the OpenSSL RNG is with arc4random! OpenSSL
only seeds itself once, at initialization. As mentioned above, OpenSSL
prefers /dev/urandom for entropy. To initialize itself, it only uses
32 bytes (ENTROPY_NEEDED) of random data.
The OpenSSL RNG, and especially its seeding and use in OpenSSH, merit
review and auditing.
Kent Borg wrote:
>I recently installed Red Hat Linux 9 and noticed on the first boot a
>message about generating ssh host keys. Isn't that a dangerous thing
>to do on the first boot? Where is the installation going to get
>enough good entropy so early in its life?
>
>Maybe the paranoid thing to do is, as part of configuring a machine,
>to regenerate those keys once user interaction (or other entropy
>source) has had time to really stir the Linux entropy pool.
>
SSH is likely getting it's entropy from /dev/random. The kernel will
decide whether there is enough entropy in the /dev/random entropy pool,
and block reads until the pool fills.
This pool, in turn, is going to have pleanty of entropy generated by
timing jitter in disk I/O interrupts.
To experiment with this, run the command:
cat /dev/random | od -cx
It will dump for a while and then stop. Then type a key. Then move your
mouse. Wait for a cron job to start up and watch what it does. Etc. etc.
Disclaimer: there is dispute in the crypto community about the hashing
done in /dev/urandom (note the 'u') which never blocks. /dev/urandom
just recycles the entropy pool with a PRNG, and people have variable
faith in the quality of PRNG's.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/
--82WbDBJhFeTAYH8j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> SSH is likely getting it's entropy from /dev/random. The kernel will=20
> decide whether there is enough entropy in the /dev/random entropy pool,=
=20
> and block reads until the pool fills.
>=20
> This pool, in turn, is going to have pleanty of entropy generated by=20
> timing jitter in disk I/O interrupts.
>=20
> To experiment with this, run the command:
>=20
> cat /dev/random | od -cx
You can also see how much 'pure entropy' is available without depeleting
it by checking /proc:
$ cat /proc/sys/kernel/random/entropy_avail
215
> Disclaimer: there is dispute in the crypto community about the hashing=20
> done in /dev/urandom (note the 'u') which never blocks. /dev/urandom=20
> just recycles the entropy pool with a PRNG, and people have variable=20
> faith in the quality of PRNG's.
Incidentally, many Linux distros will dump a chunk from /dev/urandom
on reboot and write that chunk back on bootup, s.t. even /dev/urandom
has something available from the get-go, based on the previous state.
(The previous state hopefully had user interaction, etc.) Now this
depends on us trusting the previous PRNG too, I'm not commenting on that.)
The server on which I'm writing this has no keyboard for random
input. In the time it took me to write this email (via SSH),=20
it's gathered about 500 bytes of entropy, as seen through the
aforemeantioned /proc entry.
I just modified the bootup init.d scripts on a UML kernel I have. The
very first thing rc does is cat entropy_avail to the screen, before any
of the S?? scripts are run. It reported 23 bytes available, so even
the execution of init =3D> rc is sufficient to get some randomness in
there. Not the best in the world, but it's a start.
Even without user interaction, you're likely to get some entropy from
the kernel.
--
Brian Hatch "I see. So, you feel like
Systems and you've been symbolically
Security Engineer cast... in a bad light."
http://www.ifokr.org/bri/ "Well put."
Every message PGP signed
--82WbDBJhFeTAYH8j
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/IYkLidaA3abfMooRAtemAJ9dczz/lNjkP5f0pNXqhA7tUzZ9AwCeMYUP
hy7GJMUp0ySNXw1WfMk4Eog=
=Cn2D
-----END PGP SIGNATURE-----
--82WbDBJhFeTAYH8j--
It has been pointed out that the Linux random driver will block if it
computes there is no entropy available, and this is correct.
However, last August there were bugs discovered in entropy accounting
that caused it to overestimate current entropy, and the Red Hat
2.4.20-19.9 kernel still doesn't seem to have the fix. If one has a
lot of faith in md5, this isn't a problem on an up-and-running machine
with ~some~ source of entropy, but at very early points in the entropy
pool's life, the amount does matter when something very important is
being generating early on, such as ssh keys. (Ironically, would
adopting the random fix, lock up a Red Hat first boot?)
Also, not everyone is comfortable with disk or network timings as
entropy sources. Again, on a running machine, having too many entropy
sources, some of which might not actually have much entropy in them,
isn't a problem, but a fresh entropy pool is different.
Solution? One approach is to delay creation of ssh keys. (Or, as I
did, manually create new keys after one is certain there is enough
entropy available.) Even if disk jitter is the only available entropy
source, waiting for more of it to accumulate would help.
And don't forget embedded Linux cases, such as routers, wireless
access points, etc., where there might not be a mechanical disk. It
is not hard to imagine really getting hard up for entropy in a
factory-fresh box. One idea I had recently is to hash the power up
state of a reasonable portion of RAM. By no means are the initial
contents of RAM completely random, but RAM *is* volatile, I am pretty
sure it has some entropy in it. Even if there is little entropy from
one power up to another power up of a given DRAM chip, there must be
some entropy between different physical chips. A warm boot might have
extremely little to no entropy in RAM contents, but by that point some
entropy could have been stored from previously. It is the really,
really cold boot that is the problem.
-kb, the Kent who wiggles the mouse on his basement server whenever he
walks by, a bit like a stroking rabbit's foot.
P.S. A few months ago I wrote a RAM entropy grabber for embedded PPC,
but it is too groady in how it passes it to the kernel.
On Fri, Jul 25, 2003 at 11:29:51AM -0700, Crispin Cowan wrote:
> SSH is likely getting it's entropy from /dev/random. The kernel will
> decide whether there is enough entropy in the /dev/random entropy pool,
> and block reads until the pool fills.
The last time I looked at SSH and OpenSSL, their random number
generation was disappointing. It seemed that OpenSSL generated random
numbers (and even keys) by grabbing a single 16 byte seed at startup
(!) from /dev/urandom (!). Then this seed was run through OpenSSL's
MD5-based random number generator.
I don't know if this is still true. I found the following comment in
OpenSSL's CHANGES file:
*) Change the Unix RAND_poll() variant to be able to poll several random devices, as specified by DEVRANDOM, until a sufficient amount
of data has been collected. We spend at most 10 ms on each file
(select timeout) and read in non-blocking mode. DEVRANDOM now
defaults to the list "/dev/urandom", "/dev/random", "/dev/srandom"
(previously it was just the string "/dev/urandom"), so on typical
platforms the 10 ms delay will never occur.
Also separate out the Unix variant to its own file, rand_unix.c.
For VMS, there's a currently-empty rand_vms.c.
[Richard Levitte]
I also found this comment in rand_unix.c:
/* Use a random entropy pool device. Linux, FreeBSD and OpenBSD
* have this. Use /dev/urandom if you can as /dev/random may block
* if it runs out of random entries. */
Looking back over the codebases, it appears that OpenSSH uses
arc4random() extensively. The version of arc4random provided with this
Linux port of OpenSSH uses OpenSSL's RNG for seeding. However, the
only time sshd ever seeds the OpenSSL RNG is with arc4random! OpenSSL
only seeds itself once, at initialization. As mentioned above, OpenSSL
prefers /dev/urandom for entropy. To initialize itself, it only uses
32 bytes (ENTROPY_NEEDED) of random data.
The OpenSSL RNG, and especially its seeding and use in OpenSSH, merit
review and auditing.
Quote