Differences between revisions 52 and 53
Revision 52 as of 2006-05-21 19:17:50
Size: 7012
Comment: cryptsetup deb/udeb accepted by ftp-master today
Revision 53 as of 2006-05-22 02:32:49
Size: 7002
Editor: MaxVozeler
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
The first version of partman-crypto has been uploaded to the Debian archive. Support for loop-AES is mostly complete and tested. Support for dm-crypt/LUKS is waiting for an updated libpopt0 package. 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. 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 an updated libpopt0 package. 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.

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 an updated libpopt0 package. 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

/!\ awaiting ftp-master

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

d-i

crypto-modules-$KVERS-di

dm-crypt kernel support

(./) in unstable

n/a

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]

  • 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)
    • Support root-on-LVM-on-encrypted-volume

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:

  • 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.

History