Installing Debian on encrypted block devices

This page describes the development of DebianInstaller support for encrypted block devices. The aim is to allow users to setup loop-AES, dm-crypt or LUKS encrypted partitions for the system and data parts of a Debian system during the installation.

/!\ IMPORTANT: partman-crypto is still pre-beta and has not been audited for weak keys, leaking of key data or other implementation flaws. Please don't use it for production before the beta release.

Status

The upload of partman-crypto is waiting for loop-AES or LUKS support to work reliably with only packages in the Debian archive. loop-AES support still has some show-stopper bugs. Support for dm-crypt and LUKS is in progress but unfinished. See also: partman-crypto [http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/TODO?op=file TODO] and [http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/BUGS?op=file BUGS]

First stage

partman-crypto

general

{X} needs upload

cdebconf-entropy

key generation

(./) in unstable

gnupg-udeb

loop-AES keyfiles

(./) in unstable

loop-aes-$KVERS-di

loop-AES kernel support

(./) in unstable (working out build problems on some archs)

cryptsetup-udeb

add cryptsetup udeb

{X} not fixed ([http://bugs.debian.org/358422 #358422])

libpopt0-udeb

add libpopt0 udeb

{X} not fixed ([http://bugs.debian.org/358671 #358671])

libgpg-error0-udeb

add libgpg-error0 udeb

{X} not fixed ([http://bugs.debian.org/358672 #358672])

libgcrypt11-udeb

add libgcrypt11 udeb

{X} not fixed ([http://bugs.debian.org/358675 #358675])

crypto-modules-$KVERS-di

kernel crypto modules

(./) in unstable

Second stage

loop-aes-$KVERS

loop-AES kernel support

(./) in unstable

cryptsetup

support for cryptroot

{X} not fixed ([http://bugs.debian.org/358452 #358452])

initramfs-tools

support for cryptroot

{X} not fixed ([http://bugs.debian.org/348147 #348147])

TODO before beta

Plans for v1.0+

Building a partman-crypto enabled iso image

The following steps are currently necessary to build a partman-crypto enabled d-i image (for development purposes only):

$ mkdir crypto-d-i
$ cd crypto-d-i
$ svn co svn://svn.debian.org/d-i/trunk d-i
$ cd d-i/installer/
$ dpkg-checkbuilddeps || echo "Some build-dep packages missing, please install (see list above)"
$ cd build
$ cat > pkg-lists/local <<EOF
partman-crypto
cdebconf-newt-entropy
loop-aes-\${kernel:Version} [2.6]
crypto-modules-\${kernel:Version} [2.6]
mount-aes-udeb
gnupg-udeb
cryptsetup-udeb
EOF
$ cd ../../packages/partman/partman-crypto/
$ dpkg-buildpackage -I.svn -us -uc -rfakeroot
$ cp ../partman-crypto*.udeb ../../../installer/build/localudebs/
$ cd ../../../installer/build/localudebs/
$ wget http://people.debian.org/~mejo/cryptsetup/cryptsetup-udeb_1.0.2+1.0.3-rc3-2_i386.udeb
$ cd ..
$ fakeroot make build_netboot
$ ls -al dest/netboot/mini.iso

Key generation in d-i

Encryption keys for loop-AES are created from /dev/random. It is important that we have a good source of entropy to allow us to extract the required amount of key data from /dev/random (each loop-AES v3 key requires 2925 bytes of random data). Currently the low amount of entropy in the kernel pool causes the key generation to block for a long time.

There are some ideas for how to solve this:

The current idea is to check if rngd (package rng-tools) could be extended to read from one or more FIFOs and character devices, do FIPS tests and feed the kernel entropy pool. If this is feasible audio-entropyd, video-entropyd, software for collecting network traffic timings etc. could be packaged and be made to feed rngd. TODO: Ask hmh@d.o if this approach makes sense and is feasible.

History