Hello,

it seems that upon initialization of encrypted volumes, the LUKS master
key is created by reading "entropy" from /dev/urandom which means that
in case the kernel is low on entropy at the time of volume creation,
the volume will be vulnerable to cryptanalysis.  This is very, very
bad, it puts our users at risk.

Sadly, this insecure method for creating the master key is the default
and cryptsetup requires explicit specification of the "--use-random"
switch for /dev/random to be used instead, cf.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714331

I understand that machines without entropy sources will block when
reading from /dev/random, but I sincerely believe that it is
irresponsible to cover that up by silently degrading encryption,
instead of alerting the user to that fact.

Thus I propose to change setup_luks() to:
1. By default, run cryptsetup with "--use-random" in a backgrounded
   job.
2. In case the job doesn't return within a couple of seconds, instruct
   the user to a) either press keys until enough entropy has been
   gathered or b) select "Cancel" and continue in unsafe manner. If the
   user choses b), kill cryptsetup and re-run it with "--use-urandom".
3. In case of unattended installs, abort the installation if cryptsetup
   doesn't return within say 60 seconds.
4. Add a config option ("allow unsafe master key") to allow pre-seeding
   of "--use-urandom".

Best regards,
Thiemo

Quoting Thiemo Nagel (thiemo.nagel@gmail.com):


Don't we have such things?

I'm sure I translated screens where users are prompted to type keys,
move the mouse and do other stuff in order to generate entropy.

I don't really know much abou tpartman-crypto internals, but you might
want to check this first.

I faintly remember something like that, too. But I can't see it in the
code. Have a look at (what I believe to be) the relevant snippet in
setup_luks() from crypto-base.sh:

    log-output -t partman-crypto \
    /sbin/cryptsetup -c $cipher-$iv -s $size luksFormat $device $pass
    if [ $? -ne 0 ]; then
        log "luksFormat failed"
        return 2
    fi

Quoting Regis Boudin (regis@boudin.name):

(let's answer to the bug report)

OK, then it seems that we "only" need someone to use cdebconf-entropy
widgets from partman-crypto, then.

Thiemo, you seem to have great intereste in partman-crypto......:-)

Dear Christian,

I really appreciate your confidence in me... ;-)

BTW: I found this gem in man urandom (emphasis mine): "As a general
rule, /dev/urandom should be used for everything *except* long-lived
GPG/SSL/SSH keys." As the md-crypt master key probably is a prime
example for a long-lived cryptographic key: do you think it would be
adequate to tag the bug "security" and/or to increase its severity?
Which (point) release would you like to aim for to resolve the issue?

Thank you and best regards,
Thiemo

Quoting Thiemo Nagel (thiemo.nagel@gmail.com):


Probably none. I think it's quite unlikely that we go and fix this for
wheezy, and more likely that it's addressed only in jessie.

Sad, but probably realistic..:-)

Christian PERRIER <bubulle@debian.org> (2013-09-23):

We could think of fixing it in wheezy, but surely not before it has been
exposed to unstable/testing users for a while; meaning not the next
point release in any cases.

Mraw,
KiBi.

urandom also is used in crypto-volume wiping. This should be changed,
too. (And a grep for further occurrences might be sensible.)

Hi Thiemo,

Good to have someone reviewing this code.  Use of --use-urandom by
default is a very good catch and fully agree with changing that.

The wipe is already done with a potentially lower level of security,
because it forces AES-128 in XTS mode regardless of what the user chose
for encryption of allocated data:

http://anonscm.debian.org/gitweb/?p=d-i/partman-crypto.git;a=blob;f=lib/crypto-base.sh;h=e0f8e77900d05346a6beddec19b0adc3c9535d12;hb=HEAD#l341

I think that's wrong, and not what a user expects.  If the user is
patient enough to wait for a wipe to complete, at least use their chosen
algorithm and key size instead of something arbitrary?  And then it
makes sense to use /dev/random too.

Or, if they don't care about protecting unallocated blocks, they can
already skip this step.

Sometimes people want to erase quickly whatever's already on disk, but
that's an almost completely different use case perhaps not involving
crypto, where writing all zeroes or some kind of TRIM might be adequate
and even faster.  (AES-128 + XTS was probably used above because it
tends to be fast, but not necessarily on all platforms).

Regards,

Hi Steven,

I share your concerns about the potentially less secure wipe. It has
been addressed yesterday. :-)

http://bugs.debian.org/726448

Cheers,
Thiemo