[Cryptography] /dev/random is not robust

[Stephan Mueller]

Am Donnerstag, 24. Oktober 2013, 05:06:16 schrieb Alon Ziv:

Hi Alon, Ted,


>Theodore Ts'o <tytso <at> mit.edu> writes:

>> On Thu, Oct 17, 2013 at 01:05:52PM -0400, Kent Borg wrote:

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

>> 
>> The major problem which could be considered a "Linux distribution
>> issue" is ssh host key generation, which is done by the boot scripts
>> if the ssh host keys do not exist.  It would be much better if this
>> was done on the first TCP connection to the ssh server, but that
>> would
>> require changes to sshd.

>
>Can't this be solved (in some distros at least...) by switching SSHD to
>use on-demand activation (a la inetd / systemd)? [I know the SSHD
>manpage claims this is inadvisable, but I suspect the reason -
>response "may take tens of seconds" - is decades out of date even for
>small devices...]

This issue is larger than SSHD, it covers dm_crypt too. Especially 
dm_crypt is vulnerable to this problem in case it is configured for full 
disk encryption. In this case, the installer generates the volume key as 
one of the first things during the initial installation. As this volume 
key cannot be changed for the lifetime of the system, it is highly 
important to have that generated properly (read: with good entropy).

Of course, you can say: well, installers have a graphical UI and 
therefore there is lots of mouse movements, etc. for /dev/random. But 
this is not always the case. Almost all distros allow an automated 
installation (anaconda allows that, the Debian/Ubuntu installer allows 
that, YaST too, ...), you can define automated installations with full 
disk encryption which only interrupt at the time when you have to 
provide the passphrase to protect the key. At that time, the key is 
already generated by libcryptsetup. But there was no real user 
interaction, no hard disk interaction and only limited interrupts to add 
entropy to /dev/random.

Using console-based installers is a bit better, but the user only needs 
to hit some keys before the volume key is to be created.

Now, you can say that is the responsibility of the Distros to catch that 
(e.g. require the user to hit a number of keys before generating the 
key), but I guess that approach is fragile.

I guess you can find many more examples of the issue where we need 
entropy at the time the current /dev/random code cannot provide that. I 
guess the only solution is to open up new entropy sources for that.

Ciao
Stephan