[147714] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (David Mercer)
Thu Oct 17 17:14:48 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <5D9D1764-5578-42A4-BBB1-4586B5F167D3@lrw.com>
Date: Fri, 18 Oct 2013 03:43:08 +0800
From: David Mercer <radix42@gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7796844969630257588==
Content-Type: multipart/alternative; boundary=089e0160d0eafb975e04e8f506af
--089e0160d0eafb975e04e8f506af
Content-Type: text/plain; charset=UTF-8
On Fri, Oct 18, 2013 at 1:05 AM, Kent Borg <kentborg@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
--089e0160d0eafb975e04e8f506af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>On Fri, Oct 18, 2013 at 1:05 AM, Kent Borg <<=
a href=3D"mailto:kentborg@borg.org">kentborg@borg.org</a>> wrote:</div><=
div><br></div><div>> On 10/17/2013 08:32 AM, Adam Back wrote:</div><div>=
></div>
<div>>> I think the more worrying case is a freshly imaged rack mount=
server,</div><div>>> immediately generating keys or outputting rando=
m numbers to the network or</div><div>>> in response to network queri=
es.</div>
<div>>></div><div>></div><div>> There are certainly larger syst=
em issues, and anyone doing</div><div>> auto-provisioning of servers and=
generating keys before any entropy has</div><div>> accumulated could ge=
t burned. =C2=A0Though to be fair to /dev/random, isn't this</div>
<div>> a larger Linux distribution issue? =C2=A0Don't automatically =
generate keys on</div><div>> first boot. =C2=A0RNGs that need seed data =
should not be run empty.</div><div>></div><div>> But is this somethin=
g that /dev/urandom might do better? =C2=A0Should blocking</div>
<div>> be added to /dev/urandom immediately after boot until some reason=
able</div><div>> threshold has been reached at least once? =C2=A0Or on f=
irst boot are common</div><div>> distributions restoring a bad seed file=
and /dev/random can't tell? =C2=A0Arrgh,</div>
<div>> I am starting to think that the RNG is the wrong place to fix it.=
</div><div>></div><div>> Should RNGs attempt to detect uninitialized =
states and refuse to run?</div><div><br></div><div><br></div><div>Sometime =
in the last two months I described the somewhat widespread issue</div>
<div>at VM hosting/cloud providers of provisioning VM's with the same</=
div><div>/dev/urandom seed from the image template. firstboot scripts typic=
ally only</div><div>get run at image generation, and then the urandom seed =
is frozen in amber,</div>
<div>as it were, in the VM image template file. It is a fairly trivial fix =
to</div><div>re-seed it from /dev/random (one line in the right place).</di=
v><div><br></div><div>The obvious place to do that, when the VM is actually=
provisioned, ends up</div>
<div>hurting deployment time due to sometimes blocking on /dev/random reads=
to</div><div>re-seed /dev/urandom. This has led people to toss up their ha=
nds and do the</div><div>Wrong Thing of just provisioning, sometimes thousa=
nds, of VM's with the</div>
<div>same /dev/urandom seed.</div><div><br></div><div>Quequeing up pre-prov=
isioned system images with the one liner to re-seed</div><div>/dev/urandom =
from outside the image itself (other per-system security</div><div>related =
config can happen here, too) takes care of it, but then you get</div>
<div>people whining about shuffling around image files rather than quick co=
py on</div><div>write delployments of VM images.</div><div><br></div><div>T=
hen someone at that provider has to realize you just do the queueing</div>
<div>per-storage system used by each hypervisor host against copy-on-write<=
/div><div>images. This chain of logic and refinements thereto have not, to =
my</div><div>knowledge, been written up in any widely known best practices =
document. I'd</div>
<div>love to be shown somewhere they have to point people at if it exists.<=
/div><div><br></div><div>-David Mercer</div></div></div>
--089e0160d0eafb975e04e8f506af--
--===============7796844969630257588==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7796844969630257588==--
