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] |
- TODO before beta
- Have all required packages in the Debian archive
- Find good sources of entropy for key creation
- Audit
- Plans for the future
- Keyfiles on removable media
- Existing (pre-generated) keyfiles
- Encrypted root partition (for loop-AES, already supported by dm-crypt/LUKS)
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. |
[http://nusquama.org/~max/d-i/crypto/ Daily builds] ( not ready for use)
[http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto SVN repository]
[http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/README?op=file Documentation for hackers]
[http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/TODO?op=file TODO]
Contributing
People working on partman-crypto currently include
Max Vozeler <max@nusquama.org>
David Härdeman <david@2gen.com>
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:
- Don't create keys from inside d-i; Ask users to create them on another system and provide them to partman-crypto on a removable device.
- Ask the user to type randomly on the keyboard. This is done by cdebconf-entropy. It turned out that typing alone requires too many key presses to be user-friendly. The plugin is still used to show a progressbar during key creation.
- Use a hardware RNG if available. One problem with doing this is that not many systems actually have a usable hardware RNG and that detecting them is very difficult. There is also the issue of bad HWRNGs that produce low-quality output. Packages like rng-tools implement FIPS-140-2 tests before feeding the kernel pool to protect against this.
- Use non-RNG hardware devices that may produce random output. Examples of this are audio and video devices which can be sourced using audio-entropyd or video-entropyd. Here the problem of low-quality randomness exists as well.
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.
[http://csrc.nist.gov/cryptval/140-2.htm FIPS 140-2]
[http://rfc.net/rfc4086.html RFC4086 - Randomness Requirements for Security]
History
Initial announcement (thread starting at http://lists.debian.org/debian-boot/2005/08/msg00195.html)
First code snapshot with mini.iso (2005-08-05) http://decl.org/~max/debian-installer/