[Cryptography] /dev/random is not robust

David Mercer radix42 at gmail.com
Thu Oct 17 15:43:08 EDT 2013


On Fri, Oct 18, 2013 at 1:05 AM, Kent Borg <kentborg at borg.org> wrote:

> On 10/17/2013 08:32 AM, Adam Back wrote:
>
>> I think the more worrying case is a freshly imaged rack mount server,
>> immediately generating keys or outputting random numbers to the network
or
>> in response to network queries.
>>
>
> There are certainly larger system issues, and anyone doing
> auto-provisioning of servers and generating keys before any entropy has
> accumulated could get burned.  Though to be fair to /dev/random, isn't
this
> a larger Linux distribution issue?  Don't automatically generate keys on
> first boot.  RNGs that need seed data should not be run empty.
>
> But is this something that /dev/urandom might do better?  Should blocking
> be added to /dev/urandom immediately after boot until some reasonable
> threshold has been reached at least once?  Or on first boot are common
> distributions restoring a bad seed file and /dev/random can't tell?
 Arrgh,
> I am starting to think that the RNG is the wrong place to fix it.
>
> Should RNGs attempt to detect uninitialized states and refuse to run?


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).

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. 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 /dev/urandom seed.

Quequeing up pre-provisioned system images with the one liner to re-seed
/dev/urandom from outside the image itself (other per-system security
related config can happen here, too) takes care of it, but then you get
people whining about shuffling around image files rather than quick copy on
write delployments of VM images.

Then someone at that provider has to realize you just do the queueing
per-storage system used by each hypervisor host against copy-on-write
images. This chain of logic and refinements thereto have not, to my
knowledge, been written up in any widely known best practices document. I'd
love to be shown somewhere they have to point people at if it exists.

-David Mercer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131018/a0a3d746/attachment.html>


More information about the cryptography mailing list