Installing Debian on encrypted block devices (partman-crypto)

This page describes the development of DebianInstaller support for encrypted block devices. The aim is to allow users to setup [http://loop-aes.sf.net/ loop-AES], [http://www.saout.de/misc/dm-crypt/ dm-crypt] and [http://luks.endorphin.org/ LUKS] encrypted partitions for the system and data parts during the installation of a Debian system. partman-crypto is intended to use secure defaults while allowing experienced users to change settings as they require.

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

/!\ waiting for libpopt0-udeb ([http://bugs.debian.org/358422 #358422])

libpopt0-udeb

add libpopt0 udeb

/!\ patch in BTS ([http://bugs.debian.org/358671 #358671])

libgpg-error0-udeb

add libgpg-error0 udeb

(./) not necessary (was [http://bugs.debian.org/358672 #358672])

libgcrypt11-udeb

add libgcrypt11 udeb

(./) not necessary (was [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

/!\ fix is now in SVN, but blocked by initramfs-tools ([http://bugs.debian.org/358452 #358452])

initramfs-tools

support for cryptroot

/!\ fix will be included in next version ([http://bugs.debian.org/348147 #348147])

Resources

/!\ 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.

Contributing

People working on partman-crypto currently include

If you would like to contribute, send feedback, suggestions or criticism, get in touch with us on the Debian Boot mailinglist <debian-boot@lists.debian.org>

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 the maintainer of rng-tools (hmh@d.o) if this approach is sound and practically feasible.

History