HOWTO: Disk encryption with dm-crypt / LUKS and Debian [Update]

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.


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


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This is the paper that

This is the paper that inspired wipe:

Peter Gutmann: Secure Deletion of Data from Magnetic and Solid-State Memory

In this (1996) paper, Gutmann suggests a 35-pass wiping technique that makes it much harder for a well-equipped adversary to read data off the disk. However, the epilogue notes the following:

In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now.

Looking at this from the other point of view, with the ever-increasing data density on disk platters and a corresponding reduction in feature size and use of exotic techniques to record data on the medium, it's unlikely that anything can be recovered from any recent drive except perhaps one or two levels via basic error-cancelling techniques. In particular the the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don't apply any more. Conversely, with modern high-density drives, even if you've got 10KB of sensitive data on a drive and can't erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.

So for practical purposes, a couple passes over the drive with dd if=/dev/urandom is probably the best that can be hoped for.

Why use multiple passes at all?

I also can't imagine how it would be possible to recover data from a disk that was (physically) overwritten (with a random pattern). Not even for these old MFM and RLL drives which Gutmann is talking about in his article from 1996. Just imagine you know that a 1 (or 0) is stored somewhere and you would be able to detect the kind of bit that was stored before, what does it tell you? You would not know whether this previous bit was stored by the erase process or by any of the other (hundreds or thousands) of storage processes applied to this bit. So why waste time with multiple overwrite passes if even one would be sufficient?

re: multiple passes

The reason behind multiple passes has to do with the physical properties of the storage medium.

On a hard drive you have physical platters that are coated in a material that holds information through polarization.

For most intents and purposes the information stored is a true binary data (N or S polarization), but because the density is not 1 bit per molecule, there is a possibility that a particular bit may only be partially polarized, meaning that some of the field may actually be polarized with the old data, meaning that should someone either use specialized forensic software or physically dissect the drive, it may be possible to recover the original information. Each new pass of random information reduces this possibility of recovering the information by compounding the magnetic 'echos' to the point that, which echo is valid, becomes nearly impossible to determine. How many passes are taken should be directly related to the sensitivity of the information that was in that area of the disk being wiped. The multiple pass approach normally includes either all 0's and/or all 1's as one or more of the passes, before or mixed in with the random passes (not the last pass), just to ensure that every bit changes polarity at least once and in such a way to make it more difficult to recover the information.

Anything beyond 26 passes is just overkill, and unless the information is TS-SCI, even 26 passes is going to be a bit excessive.

Many Thanks

Good, now I can do this and shut up my Vista
bigoted friends.

The only sticking point for me is the kernel option related stuff but there's no time like the present to learn how.

Thanks again!
Citizen Jimserac
Using Debian Unstable

Encrypted Filesystem

Worked beautifully.

There were a few other things I had to install
before being able to do my make xconfig
but no kernel options needed to be
set up as they were already at the
correct settings.

I've been dreaming about having this ever
since I read "Cryptonomicon" years ago
and now I have it. The whole thing took
about 20 minutes to set up.

Its fast too.

Citizen Jimserac

Tutorial for encrypting a working disk with remote access only?

Newbie here that has been looking for a 'complete' tutorial how to encrypt a drive that:
1. Only have remote access to, login is done via SSH, no GUI.
2. Already existing programs and users on the site
3. Just want to encrypt sensitive areas not entire disk as told that to do would make it almost impossible for a newbie to do and still be able to login remotely via SSH.
Sensitive areas?:
and logs, etc, don't really know?

I've been told cryptsetup is great for this and that one would need to make partitions, containers, etc.. completely lost and scared to try anything without a complete tutorial including the partition parts.

Any chance of this? :D
Thank you!