[Cryptography] provisioning a seed for /dev/urandom

John Denker jsd at av8n.com
Thu Oct 24 16:14:25 EDT 2013


On 10/17/2013 12:43 PM, David Mercer wrote:

> Sometime in the last two months I described the somewhat widespread issue
> at VM hosting/cloud providers of provisioning VM's with the same
> /dev/urandom seed from the image template. firstboot scripts typically only
> get run at image generation, and then the urandom seed is frozen in amber,
> as it were, in the VM image template file. It is a fairly trivial fix to
> re-seed it from /dev/random (one line in the right place).

I reckon that in most cases, it would be better to obtain the 
seed from the host's /dev/urandom (rather than /dev/random) to 
avoid problems with blocking, as discussed below.

  The exception is in cases where you know you have a copious
  supply of high-quality randomness available via /dev/random,
  so that blocking is not an issue.  Hint: turbid.

> The obvious place to do that, when the VM is actually provisioned, ends up
> hurting deployment time due to sometimes blocking on /dev/random reads to
> re-seed /dev/urandom.

I'm mystified by that.  We're talking about Linux /dev/urandom 
aren't we?  That never blocks, not for reseeding or for anything
else.  There have been proposals to change this, but that would
be a Bad Idea™ and I've never seen any blocking urandom device
actually get distributed ... although perhaps I have overlooked 
something.

>  This has led people to toss up their hands and do the
> Wrong Thing of just provisioning, sometimes thousands, of VM's with the
> same ... seed.

That's a bizarre overreaction.  
 ++ It would make sense to switch from /dev/random to /dev/urandom,
  since the latter never blocks.
 -- It makes no sense to switch from /dev/random to a constant.

Note that the seed in question is being used to initialize the 
guest's PRNG, so there is no reason to go overboard with the quality 
of the seed.  If the guest wanted hard-core industrial-strength 
entropy, it wouldn't be using its PRNG for that anyway.

If you are provisioning large numbers of VMs and/or hardware
devices, the per-unit cost of provisioning a proper seed is 
essentially zero.

======

Tangential remark:  /dev/urandom never blocks.  Occasionally I see
proposals to make it "better" by allowing it to block under some
conditions, but IMHO this is a terrible idea, for reasons that should
be clear from the story related above.  If given a source that blocks,
users will just not use it.  They will do something else instead, and 
the results will almost certainly be worse, not better.

The key is to make sure that /dev/urandom is always sufficiently
well seeded, so that it is always ready to use (for the appropriate
class of purposes).

===============

Theodore Ts'o <tytso <at> mit.edu> wrote:

>>> The major problem which could be considered a "Linux distribution
>>> issue" is ssh host key generation, which is done by the boot scripts
>>> if the ssh host keys do not exist.  It would be much better if this
>>> was done on the first TCP connection to the ssh server, but that would
>>> require changes to sshd.

On 10/23/2013 10:06 PM, Alon Ziv asked:

>> Can't this be solved (in some distros at least...) by switching SSHD to use 
>> on-demand activation (a la inetd / systemd)? [I know the SSHD manpage claims 
>> this is inadvisable, but I suspect the reason - response "may take tens of 
>> seconds" - is decades out of date even for small devices...]

ssh is built on openssl which prefers to initialize itself from
/dev/urandom (although it "can" use other sources).

So once again the key to making the problem go away is to make 
sure that /dev/urandom is properly seeded and ready to use.

When provisioning VMs or anything else, this should not be hard
to do.  It is already necessary to provision things like the
hostname and MAC address, and it is not rocket science to provision 
the seed-file at the same time.

There are additional issues that arise when booting from a genuinely
read-only system image, such as a CDROM, but there are other ways of
addressing these issues.  Options include:
  -- mounting a second disk containing the seed file ... and teaching
   the guest system to find this and use it properly.
  -- passing a seed on the kernel cmdline.

========================
Constructive suggestion:

It would help to have sort of best-practices document that explains 
to VM providers and device manufacturers the importance of provisioning 
a unique seed ... and tells them how to do it properly.



More information about the cryptography mailing list