Uwe Hermann | A slightly paranoid Debian developer

A few weeks ago I published a small HOWTO for using loop-aes to encrypt your hard drive, usb thumb drive etc.

As I have bought a new 300 GB external USB disk drive on Friday, I have tried something new this time: disk encryption using dm-crypt / LUKS. It has been suggested to me multiple times that dm-crypt is superior to loop-aes, however I didn't get a real reason. Yes, it doesn't require any kernel patches and is easier to setup. But has any serious cryptographer looked at it sharply, yet? Did it withhold his eye contact?

Anyways, here's how I encrypted my 300 GB drive. I largely followed the guide at the EncryptedDeviceUsingLUKS wiki page...

1. Make sure you run Linux 2.6.16 or better. Previous versions suffer from an implementation problem which affects the security of dm-crypt, see Linux Kernel dm-crypt Local Cryptographic Key Disclosure.
2. Enable the following options in your kernel:
   • Code maturity level options
     • Prompt for development and/or incomplete code/drivers
   • Device Drivers -> Multi-device support (RAID and LVM)
     • Device mapper support
     • Crypt target support
   • Cryptographic options
     • AES cipher algorithms
3. Overwrite the whole drive with random data in order to slow down attacks on the encryption. At the same time perform a bad blocks scan to make sure the hard drive is not going to die too soon:
   badblocks -c 10240 -s -w -t random -v /dev/sdb
   Replace /dev/sdb with whatever is correct on your system. If you're really paranoid, and are willing to wait one or two days, do this:
   dd if=/dev/urandom of=/dev/sdb
4. Install the required packages:
   apt-get install cryptsetup
   The current cryptsetup in Debian unstable already supports LUKS, which was not the case a while ago, if I'm not mistaken. So Debian testing or stable will most probably not work!
5. Create one or more partitions on the drive:
   cfdisk /dev/sdb
   I created one big 300 GB partition, /dev/sdb1.
6. Setup LUKS:
   cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1
   Enter a good passphrase here. Don't spoil the whole endeavour by chosing a stupid or short passphrase.
7. Open the encrypted device and assign it to a virtual /dev/mapper/samsung300gb device:
   cryptsetup luksOpen /dev/sdb1 samsung300gb
8. Create a filesystem on the encrypted device:
   mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/samsung300gb
   I used ext3 with some optimizations, see mke2fs(8).
9. Mount the encrypted partition:
   mkdir /mnt/samsung300gb
mount /dev/mapper/samsung300gb /mnt/samsung300gb
   That's it. Everything you write to /mnt/samsung300gb will be encrypted transparently.
10. For unmounting use:
    umount /mnt/samsung300gb
cryptsetup luksClose /dev/mapper/samsung300gb

After unmounting, nobody will be able to see your data without knowing the correct passphrase. Drive is stolen? No problem. Drive is broken, and you want to send it in for repair without the guys there poking in your data? No problem. You leave the USB drive at home and some jerk breaks into your house, steals your drive, rapes your wife, and kills your kids? No problem. Well, sort of, but you get the idea ;-)

There's more things you can do, thanks to LUKS: have multiple passphrases which unlock your data, change/add/remove passphrases as you see fit, etc.

Comments?

Update 2006-04-17: You have to use cryptsetup from unstable if you want LUKS support. cryptsetup in testing does not support this (thanks Ariel).

I have upgraded my kernel to Linux 2.6.16 today with some consequences:

• The "SysKonnect Yukon2 support (EXPERIMENTAL)" option supports my network card just fine now, no need for external sk98lin drivers anymore (gah, I bet this URL will break in a few hours). For googling purposes: I have the following card: Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10).
• As I have reported before, my disk drive cannot be talked into using DMA without this kernel patch. The patch does not apply to 2.6.16 anymore, so I have fixed it. May I present: my first Linux kernel patch (IIRC), sent off to the LKML today. Let's see if this gets in the kernel...
• The kernel now includes the ipw2200 driver (not the most recent version, though), which allows me to use my Intel PRO/Wireless 2200BG wireless network card without having to use external drivers. However, the driver does not allow you to put the card into monitor mode. The code is there, it just isn't enabled, for whatever reason. I have created a trivial patch, but it seems that someone else has already fixed this issue. Just in case anyone cares, here's my patch:

  diff -Naur linux-2.6.16.orig/drivers/net/wireless/ipw2200.c linux-2.6.16/drivers/net/wireless/ipw2200.c
  --- linux-2.6.16.orig/drivers/net/wireless/ipw2200.c    2006-03-20 06:53:29.000000000 +0100
  +++ linux-2.6.16/drivers/net/wireless/ipw2200.c 2006-03-24 01:27:15.000000000 +0100
  @@ -38,6 +38,9 @@
   #define DRV_COPYRIGHT  "Copyright(c) 2003-2005 Intel Corporation"
   #define DRV_VERSION     IPW2200_VERSION
  
  +#define CONFIG_IPW2200_MONITOR "y"
  +
  +
   #define ETH_P_80211_STATS (ETH_P_80211_RAW + 1)
  
   MODULE_DESCRIPTION(DRV_DESCRIPTION);
  

  You should better copy+paste the patch from the HTML source or it might break...

• There doesn't seem to be a loop-aes patch for 2.6.16, so I probably cannot mount my encrypted volumes. I'll try the latest release (for 2.6.15-*) tomorrow, if I'm lucky the patches still apply to 2.6.16...
• If you have an NVIDIA graphics card, you need this cumulative patch against the 1.0-8178 NVIDIA Linux x86 drivers, or else they won't compile.

Update 2006-03-24: The loop-aes v3.1c patches apply just fine. I almost forgot to mention the NVIDIA changes...

Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives.

I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too.

Here's a quick HOWTO:

1. Get the loop-AES kernel patches, apply them, enable "AES encrypted loop device support" in "Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.
   I also enabled "loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).
   If you're using the Debian kernel packages, apt-get install loop-aes-2.6-686 (or a similar package) should suffice.
2. Get a loop-aes enabled losetup, mount etc.:
   apt-get install loop-aes-utils
3. Securely delete the target partition: shred -n 1 -v /dev/sda3.
   Use -n 25 or higher if you want more security and have a few days time to wait for the thing to finish...
4. Setup the loopback device: losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.
   Notes:
   • I used AES-256 as cipher, but others are possible.
   • The -C 3 means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see losetup(8)). This is supposed to be more secure.
   • Using -S 'seed' (replace "seed" with a secret string like "g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!
   • You'll be asked for a passphrase > 20 characters. Choose a good one. Don't forget it!
5. Create the filesystem (I used ext3): mke2fs -j /dev/loop0
6. Detach the loopback device: losetup -d /dev/loop0
7. Add this to /etc/fstab:
   /dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
8. Mount the (now encrypted) partition by supplying the seed and entering the chosen password: mount -o pseed=seed /mnt/crypted_sda3
9. Done. You can now copy stuff to /mnt/crypted_sda3 which will be encrypted automatically.

For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...