7139
Comment: Update URL for daily builds, status of crypto-modules-$KVERS
|
7053
wohoo!! James has done it. gnupg-udeb! :-)
|
Deletions are marked like this. | Additions are marked like this. |
Line 25: | Line 25: |
|| partman-crypto || general || {X} needs upload, blocked by gnupg-udeb || | || partman-crypto || general || {X} needs upload || |
Line 27: | Line 27: |
|| gnupg-udeb || loop-AES keyfiles || {X} ''missing'' ([http://bugs.debian.org/321948 #321948]) || | || gnupg-udeb || loop-AES keyfiles || (./) in unstable || |
Installing Debian on encrypted block devices
This page describes the development of d-i support for installing on 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.
partman-crypto
IMPORTANT: The current implementation is still pre-beta and has not been audited for flaws that could produce weak keys, leak key data or otherwise introduce weaknesses in the encryption. Please don't use it for any confidential data before the beta release. |
[http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto SVN repository]
[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/README?op=file Documentation for hackers]
[http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-crypto/TODO?op=file TODO]
Status
loop-AES support in partman-crypto requires gnupg-udeb which is not available in the Debian archive. Work on dm-crypt and LUKS support has only just started (See [http://lists.debian.org/debian-boot/2006/03/msg00235.html this thread]). The upload of partman-crypto is blocked on getting one of loop-AES or LUKS working with only packages in the Debian archive.
First stage |
||
partman-crypto |
general |
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 |
not fixed ([http://bugs.debian.org/358422 #358422]) |
libpopt0-udeb |
add libpopt0 udeb |
not fixed ([http://bugs.debian.org/358671 #358671]) |
libgpg-error0-udeb |
add libgpg-error0 udeb |
not fixed ([http://bugs.debian.org/358672 #358672]) |
libgcrypt11-udeb |
add libgcrypt11 udeb |
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 |
not fixed ([http://bugs.debian.org/358452 #358452]) |
initramfs-tools |
support for cryptroot |
not fixed ([http://bugs.debian.org/348147 #348147]) |
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]
TODO before beta
- Upload required packages
- Audit for leaks of keydata or weak implementation
- Find good sources of entropy
- Test
Plans for v1.0+
- Support for dm-crypt
- Support for dm-crypt LUKS
- loop-AES keyfiles on removable media
- Existing (pre-generated) loop-AES keyfiles
- Encrypted root partition
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] 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 ../../../../ $ apt-get source gnupg $ cd gnupg-* $ wget "http://bugs.debian.org/cgi-bin/bugreport.cgi/gnupg-1.4.1_build_udeb.diff?bug=321948;msg=5;att=1" -O gnupg-udeb.patch $ patch -p1 < gnupg-udeb.patch $ dpkg-checkbuilddeps $ dpkg-buildpackage -us -uc -rfakeroot $ cp ../gnupg*.udeb ../d-i/installer/build/localudebs/ $ cd ../d-i/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:
- 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 hmh@d.o if this approach makes sense and is 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/