Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Sep 2012 16:00:22 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        Arthur Mesh <arthurmesh@gmail.com>
Cc:        freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org>, "David E. O'Brien" <obrien@FreeBSD.org>
Subject:   Re: svn commit: r239569 - head/etc/rc.d
Message-ID:  <50453686.9090100@FreeBSD.org>
In-Reply-To: <20120903214638.GO1464@x96.org>
References:  <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09/03/2012 14:46, Arthur Mesh wrote:
> On Mon, Sep 03, 2012 at 02:13:18PM -0700, Doug Barton wrote:
>>> Yes, except /entropy is generated after /var/db/entropy/* and old
>>> /entropy was fed in to yarrow. So I don't believe saying it's poorly
>>> seeded at that point is fair.
>>
>> It is certainly not likely to be well seeded at that point, especially
>> on low end systems.
> 
> Being seeded with /var/db/entropy/* and /entropy can be considered well
> seeded, unless you're talking about first boot time. /var/db/entropy/*
> and /entropy contain entropy from all the entropy collected throughout
> lifetime of the box. In the best case, they provide 4k + (8*2k) of entropy,
> assuming each bit provides a bit of entropy. That's plenty enough, given
> the fact that 128bit of entropy is what's recommended to be seeded with.

In an ideal world, that's true. However you brought up one case (first
boot) where it isn't. There is also the possibility that the existing
files may be of low quality, either due to an active attack, or due to
problems with how the device was seeded during the last boot, etc. that
we may not be able to rely on all of the assumptions you made above
being true.

The static files are provided as a means to stir the pool to unblock the
device at boot time. But it is "better" (for sufficiently paranoid
definitions of "better") to wait as long as possible after boot before
actually utilizing the device for something important (like creating a
new seed).

>>> On next reboot /entropy will get re-written anyway.
>>
>> ... which illustrates my point that at best the change is superfluous.
> 
> I don't believe it's superfluous. I've mentioned a real case where it is
> an improvement.

Sorry, I'm being particularly dense here ... can you elaborate on just
which case you're referring to?

>>>> IMO both of those are bad ideas, and lower both the quantity and quality
>>>> of the entropy available at the next boot, should that happen prior to
>>>> the (again, by default) 88 minutes it takes for the system to update
>>>> /var/db/entropy.
>>>
>>
>> You're still assuming that feeding the same entropy files in on
>> successive boots is a problem, which hasn't been proven yet.
> 
> Yes, in this case, I am assuming the worst case scenario. Perhaps it has
> not been proven, but I don't think waiting until it is proven is a good
> idea.

Ummm ... I think you have the logic backwards on this. :) We have a
system, designed with fairly thorough knowledge of how Yarrow works, and
taking all possible scenarios into account. It's stood the test of time
for many years now.

You are the one asserting that the system is deficient, the burden is on
you to demonstrate the truth of your claims. If you can, then certainly
we should take them seriously, and make changes accordingly. But "I
think this might be true, therefore we should change stuff" is not good
reasoning in any context. It's certainly very bad/dangerous thinking in
a security context.

> Also, please consider the fact that Schneier explicitly recommends
> against reusing same entropy seed files...

Yeah, I've covered that.

> Consider a system where hardware entropy is disabled (silly but could
> simulate a case of low-end systems). If I reuse same seed files, I will
> end up with same exact state of yarrow on both bootups. Bet you if you
> try to generate RSA SSH hostkeys, you'll end up with identical ones on
> as in previous boot.

... and I bet you're wrong. :)  Feel free to prove that I'm the one who
is actually wrong. Just make sure you preserve the "better than nothing"
seed as part of your test case.

>>> Also, our findings have shown that on some very low end systems, these
>>> seed files are pretty much the only source of entropy early during boot.
>>
>> But the fact that on these low end/embedded systems there is very little
>> entropy available at boot time actually makes it more important that we
>> don't delete what little we have.
> 
> I am not simply discarding "little we have". It's seeded in to yarrow
> before we generate a new /entropy. Thus, for attacker to replicate
> /entropy, she would probably need to reconstruct "little we had" in
> the first place.

I still think you're fundamentally wrong here, but I have an idea for a
compromise that takes your concerns into account without compromising mine.

What if, instead of replacing /entropy, we add an additional file in
/var/db/entropy at boot time that is numerically 1 higher than
$entropy_save_num ? (Note, I have to fix the rotation script to account
for this, but I have had "improve the rotation script" on my TODO list
for a long time now, and this is a good excuse for me to get a round
'tuit.) That way should the reboot happen before the default 11 minutes
that kicks in the cron job we still have fresh entropy to reseed with,
and we're not losing anything that we had already. When the rotation
script runs it will delete the (IMO) low quality file created at boot,
and saved-entropy.1 will be a fresh, clean file with (again, arguably)
higher quality entropy that will be used at the next boot time.

I briefly considered a different solution like appending to /entropy
instead of replacing it, but one of the reasons I'm queasy about
touching that file at boot time is that in the event that the system
crashes shortly after boot (which happens to those of us who track
-current rather often) I don't want the / file system to have been
written to. Having the /entropy file written out at shutdown time is a
"necessary evil" given that we can't be sure that /var is available in
the early stages of rc, I'm not thrilled about compounding the problem
by writing to it so early in the boot.

What do you think about the idea of adding a new file in /var/db/entropy?

Doug

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50453686.9090100>