VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Dr Paul Dale]

Storing entropy has risks — cloning attacks, reading the file attacks, etc.  It is better trying than doing nothing.  Counting such stored entropy as additional data is good but many systems have no alternative entropy available.  I have had to introduce such storing schemes (with generation during fulfilment) when devices would take well over ten minutes to find enough entropy to generate their initial (long term) key material.  There are ways to mitigate the reuse risk — lock the entropy file, read it, add the contents to the kernel, regenerate the file and finally unlock it.  Plus regenerating the contents and storing them on shutdown (if not periodically).  A cloned VM would still be vulnerable (at least for a while).

Also agreed for an option to disable this.  I’d prefer that it is on by default (i.e. secure by default and requiring a decision to not be secure).


I’m expecting a somewhat lively discussion about a sensitive topic :)


Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



> On 7 Jun 2019, at 6:18 pm, Tomas Mraz <tmraz at redhat.com> wrote:
> 
> On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
>> Mark, I agree that the project area would be better for this
>> discussion.
>> 
>> For those not involved, this revolves around the vote to merge
>> PR#9084 and possible alternate mitigations for the underlying
>> problem.
>> 
>> 
>> Tim’s explanatory message is:
>> 
>>> For the record, I think we need to do a better job of tackling the
>>> underlying issue.
>>> Dealing with systems on first boot with no entropy is an issue for
>>> a class of systems.
>>> However we should be distinguishing between contexts where we have
>>> decent seeding material (from having had reasonable entropy) from
>>> those where we haven't.
>>> We also should be able to persist seeding across boots and have
>>> recommendations for how vendors should do that.
>>> We should be able to fall back to handling it at the user level
>>> (i.e. non-root user, persisted in the file system).
>>> We need knowledge of install state (for FIPS) and that can also act
>>> as a first-boot state effectively.
>>> 
>>> And this applies equally to getentropy usage - it is only a problem
>>> in very limited contexts where blocking actually makes sense to
>>> perform.
>>> That the kernel has no additional entropy available is not
>>> necessarily an issue - except in a very limited context (first time
>>> boot with no other entropy available from previous contexts). 
> 
> The previous context can easily provide false entropy - for example due
> to the booting system being a cloned virtual machine. Or boot image for
> a small router device which contains such saved entropy which is
> distributed to millions of devices worldwide.
> 
> This was the reason why systemd guys rejected the idea to actually seed
> the kernel rng with such entropy with the call that counts this seed
> entropy. They just use it as additional seed with no accounting for the
> entropy it would provide if it was not reused.
> 
>> 
>> Viktor replied:
>> 
>>> I just want to make sure we don't lock ourselves in to a single
>>> potentially clumsy solution in the library.  Various strategies
>>> may be appropriate depending on the platform, and ultimately the
>>> cooperation of the system administrator to enable the required
>>> mechanisms.
>>> 
>>> Potential additional sources for initial entropy on systems
>>> without getrandom(2) might include:
>>> 
>>>  RDSEED/RDRAND
>>>  TPM (or Virtualized TPM which is sometimes better!)
>>>  RNG state saved across reboots.
>>>  ...
>>> 
>>> This requires knowledge of various platforms, and potential
>>> help from the platform vendors.  It might, for example, make
>>> sense to delegate initial seeding to systemd on platforms
>>> that use systemd, and work with the systemd maintainers to
>>> provide a set of sensible entropy sources for initial boot.
>>> 
>>> Exposing a decent RNG to virtual guests and containers is
>>> would be another area of focus.
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> no real problems for us.
> 
> However I can understand that when OpenSSL is built and installed
> separately by application vendors on some legacy system that they do
> not have control of they might appreciate that the library itself tries
> to solve the hard problems related to the entropy gathering for them.
> 
> So I would just ask for one thing - all this additional stuff should be
> optional - I do not of course care wheter it is opt-in or opt-out as
> that is easily handled in our builds.
> 
>> 
>> My suggestion as a fallback would be Stephan Müller’s CPU Jitter.
>> He’s collected a large corpus of data from many processors and the
>> scheme works relatively quickly.
> 
> +1 to that.
> 
> -- 
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>                                              Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190607/27e78c67/attachment-0001.html>