[Cryptography] /dev/random is not robust

[Yuriy Kaminskiy]

Stephan Mueller wrote:
> Am Donnerstag, 24. Oktober 2013, 05:06:16 schrieb Alon Ziv:
>> 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.

It is not only *installer* issue, it also affects popular "ephemeral swap" (or
"ephemeral temporary fs") setup,

=== /etc/crypttab ===
cryptoswap	/dev/[...]	/dev/urandom	swap
=== /etc/fstab ===
/dev/mapper/cryptoswap	none	swap	sw	0	0
=== end ===

It is even more problematic, as those crypto-disks are mounted on *early* boot
stage, even *before* /etc/init.d/urandom executed (= before saved random state
re-feeded to kernel), and before network setup, and with very
small amount of disk/keyboard/mouse activity (even smaller than in installer), etc.

And if you just replace /dev/urandom with /dev/random, this can turn into sudden
stall at boot time (likely without any hint for user - like "moving mouse or
randomly typing on keyboard should help"). As at this stage there are no or very
little background daemons running, there are no chance to gather randomness from
disk activity, and there are no network activity, so it likely *won't* resolve
itself without user help. That's *totally* no-go for servers ("unattended
reboot" for them is not "possibility", but "most likely scenario").

Oh, and init.d/urandom also cannot be moved *before* that early-boot mounting
crypto-disks, as /var (where random-seed saved) can be also separate partition
*and* encrypted.

This looks quite ... troubling.

[...]

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