Start up entropy gathering

[Dr Paul Dale]

Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy on boot and first boot problems.
Comment: PR#9084 removed such mitigation due to the negative side effects.

This vote has passed (two for, four abstain, none against):


The discussion now needs to turn to how this can be done.

The mitigation is for older Linux kernels only (and perhaps old Unix machines of other flavours).  So no Windows, getentropy(3), ….


I have a suggestion.  Two kind of.

Use a volatile mechanism for communicating between processes — a file in /tmp, a block of shared memory or whatever.
On system boot, the first instance of libcrypto that attempts to read /dev/urandom, first locks the shared resource and reads one byte from /dev/random.  It uses the shared resource to indicate that the read was successful and continues seeding from /dev/urandom.
Other instances of libcrypto start up, see that the shared resource is properly initialised and go straight to using /dev/urandom.
On system shutdown/reboot, the communication mechanism disappears and the entire process will repeat on the next boot.
There are some fine details but this is the gist of it.

This is more difficult to describe than code: see #9152 <https://github.com/openssl/openssl/pull/9152>.


Notes:

1. Reading the byte from /dev/random avoid problems on systems that cannot select(2) on /dev/random.

2. Early start up of /libcrypto will block until entropy is available (and consume eight bits of same).  Later starts have the overhead of the locking and resource access.  Importantly, no entropy will be drained from the system pool after start up.



The second suggestion is broadly similar but requires a file containing entropy that persists across reboots.  This alternative requires a more management: the entropy file once read needs to be rewritten immediately (and ideally on shutdown as well).  It also introduces a new attack vector against the entropy storage.  It also isn’t possible to skip the entropy file read/rewrite sequence because it is impossible to determine if /dev/urandom has actually been seeded.  I’ve not attempted to code this, persistent files containing seed material potentially introduce other problems.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190613/57460fa4/attachment-0001.html>