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 your Debian system during the initial install. partman-crypto is intended to use secure defaults while allowing experienced users to change settings as they require.

?TableOfContents

Status

partman-crypto is now included in daily builds of DebianInstaller. Support for loop-AES is mostly complete and tested. Support for dm-crypt/LUKS is waiting for some package updates. For more details see the table below and also [http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/TODO?op=file TODO]/[http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/BUGS?op=file BUGS] in SVN.

Stage

Package

Description

Status

Bug no

d-i

partman-crypto

crypto setup UI for d-i

(./) in unstable

n/a

d-i

cdebconf-newt-entropy

key generation

(./) in unstable

n/a

d-i

gnupg-udeb

loop-AES keyfiles

(./) in testing

n/a

d-i

loop-aes-$KVERS-di

loop-AES kernel support

(./) in testing

n/a

d-i

cryptsetup-udeb

dm-crypt/LUKS support

(./) in unstable

[http://bugs.debian.org/358422 #358422]

d-i

libpopt0-udeb

dm-crypt/LUKS support

(./) in unstable

[http://bugs.debian.org/358671 #358671]

d-i

crypto-modules-$KVERS-di

dm-crypt kernel support

(./) in unstable

n/a

d-i

parted

fix lvm-on-crypt error

(./) in unstable

[http://bugs.debian.org/367965 #367965]

d-i

partman-crypto

get version 5 into archive

/!\ awaiting FTP-master

see [http://ftp-master.debian.org/new.html NEW queue]

post-d-i

loop-aes-$KVERS

loop-AES kernel support

(./) in testing

n/a

post-d-i

cryptsetup

support for cryptroot

(./) in unstable

[http://bugs.debian.org/358452 #358452]

post-d-i

initramfs-tools

support for cryptroot

(./) in testing

[http://bugs.debian.org/348147 #348147]

post-d-i

base-installer

create dm-crypt nodes

(./) in unstable

[http://bugs.debian.org/365747 #365747]

post-d-i

cryptsetup

root-on-lvm-on-crypt fix

(./) in unstable

[http://bugs.debian.org/362564 #362564]

For further details, see the [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] files in SVN.

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 d-i iso image

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

$ svn co svn://svn.debian.org/d-i/trunk d-i
$ cd d-i/packages/partman/partman-crypto/
$ dpkg-buildpackage -I.svn -us -uc -rfakeroot
$ cp ../partman-crypto*.udeb ../../../installer/build/localudebs/
$ cd ../../../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
$ fakeroot make build_netboot

Once the build is done, your brand new d-i image (mini.iso) can be found in ./dest/netboot/

Key generation in d-i (loop-AES specific)

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