intrigeri:
> Hi,
>
> we're asked to install ekeyd to support EntropyKey:
> https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/
>
> The total installed size of the needed packages is a few hundred
> kilobytes. I think it's worth adding to improve cryptography -related
> hardware support. What do you think?
>
> Cheers,
>
I think it is a good idea. I regularly install it with Tails anyway.
It might also make sense to include rng-tools, randomsound, and haveged
for around of 1,098 kB on disk. Tails should really do everything
possible to collect entropy as often as possible; if the rng runs dry,
all the crypto fails badly... It might even be worth seeding the rng
from an unlocked persistence partition - it should be possible to drain
/dev/random of ~200 bits of entropy at any given point in time to ensure
that the rng never goes unseeded...
On a slightly related note...
I've been thinking quite a lot lately about low entropy systems that
create persistent encrypted storage. It seems like low entropy systems
that fail horribly for asymmetric keys are also likely to fail horribly
for symmetric keys.
On a modern system install a user may set up an encrypted disk. On a
recently installed laptop, I found that it had essentially zero sources
of entropy beyond the keyboard, the clock and the hostname. Of the
three, I think one could make an educated guess about the time the disk
was formatted and the hostname. The network driver wasn't working, so I
had no network traffic at all. I used the text installer, so until I
arrived at the disk encryption, my keyboard entry was essentially
setting the hostname and hitting return a half dozen times.
Basically, I think the installer calls cryptsetup like this:
cryptsetup --verbose --verify-passphrase luksFormat /dev/sda1
Internally, I think that cryptsetup calls _action_luksFormat_useMK() or
_action_luksFormat_generateMK(), which in turn calls crypt_format() or
crypt_luksFormat(). Eventually, LUKS_generate_masterkey() or
LUKS_alloc_masterkey() will be called. Internally this just opens
/dev/urandom. As we know from Nadia's latest work[0], disaster strikes
often with /dev/urandom and especially with embedded systems or
similarly entropy starved modern laptops with no moving parts...
This may or may not be an actual bug. It seems like it is debatable if
using /dev/urandom is a bug but using it with zero entropy is clearly a
bad idea... Debian apparently considered it to be a no problem in 2010,
so they use /dev/urandom (a change *from* /dev/random) according to the
cryptsetup debian/changelog file:
* change default for random key from /dev/random to /dev/urandom in
README.Debian, extend explanation. (closes: #579932)
... o_0 ...
I guess it would be interesting to collect actual LUKS masterkey disk
keys and look at the distribution of bits. My guess is that if the LUKS
password is collected *after* LUKS_generate_masterkey(), the entropy of
the system is basically close to zero. I think this happens only when
get_key() isn't called before crypt_format(). Though depending on how
the entropy pool is seeded, I guess the entropy of the key may still be
less than the actual bytes of the passphrase.
It may be that cryptsetup is called with /dev/random as a key file,
though I think that would mean that get_key() wouldn't be called. So it
might have less entropy than expected as there simply isn't really
anything that is actually well, entropic, for the attacker with the
computer/disk in hand. The answer is probably in the partman-crypto
package. It seems to create a key file by calling `cat $randfifo >
$keyfile` - strangely, create_random_keyfile() appears to call
call_entropy_plugin only after it starts reading from the randfifo.
Does anyone know offhand how cryptsetup is called from debian-installer?
All the best,
Jake
[0]
https://factorable.net/paper.html
