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.

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

Comments

Comment viewing options

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

thanks. even after over 5

thanks. even after over 5 years still very good guidance!

One of the reasons I love Debian!

There are plenty of security options available to the cryptographer on debian and what really upset's the state is that most of those options where approved for use only in *.gov departments.

If a forensic anailyst expects they can just sieze your hard-disks and then decrypt and read the contents when the contents have been secured with algorithms that are stronger than some of those available under NIST standards, then they really do not have much of a leg to stand on.

Some nice tools to add to your cryptograhic toolkit;

SECCURE - in Repo
WIPE - in Repo
YAOTP - yet another one time pad (available from the hackers choice)
GnuPG - in Repo
mCrypt - in Repo
Steghide - in Repo
etc, etc...

Just type in encryption in the synaptic package manager then go to town and party!

seccure -c nistp521 -F pwfile seccure-encrypt -i document.msg -o document.enc '2@DupCaCKykHBe-QHpAP%d%B[yeeehAw!]'

PARTY!

TrueCrypt & LUKS

If you want LUKS support native to the desktop there is an excellent tool available called gnome-luks-format available from;

www.flyn.org/projects/luks-tools/index.html

If your looking to encrypt more than one disk, then I recommend TrueCrypt.

In July 2008, several TrueCrypt-secured hard drives were seized from a Brazilian banker Daniel Dantas, who was suspected of financial crimes. The Brazilian National Institute of Criminology (INC) tried unsuccessfully for five months to obtain access to TrueCrypt-protected disks owned by the banker, after which they enlisted the help of the FBI. The FBI used dictionary attacks against Dantas' disks for over 12 months, but were still unable to decrypt them.

So in retrospect you need an ultrahigh secure password for most encryption something along the lines of 64 bit's or random bytes.

ie: 75FBAC56C3C60AEF8FE3FFEBD36E7DA1C7D0E4EAA38C67B78F17EAC8AAA3CBDB

TrueCrypt has the option to create a hidden container, however this is buggy at best and if you've got linux it's just as easy to create your own hidden container by simply including a . (dot) in front of the file name.

So .trash is a perfect example and while TrueCrypt volumes do not contain known file headers and their content is indistinguishable from random data, it is theoretically impossible to identify such files as being TrueCrypt volumes without knowing their passwords.

I use both the LvM2 Cryptsetup with AES-256&SHA512 with the Grub boot-loader protected with a SHA512 passphrase. Then any additional disks maintain a Garbage file. Accessing the disk's requires Mounting the disk before mounting the container after which only the root user can read - write content to those drives which are automatically dismounted on a reboot.

WARNING: Encryption of a 250Gb HDD TrueCrypt Container will probably take 4 to 5 hours to complete. So be patient! Individual algorithms supported by TrueCrypt are AES, Serpent, and Twofish.

Additionally, five different combinations of cascaded algorithms are available: AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES and Twofish-Serpent. The cryptographic hash functions used by TrueCrypt are RIPEMD-160, SHA-512, and Whirlpool. <-- You get to choose, just remember to shake the mouse for at least 60 seconds.

hashalot package

Why is the hashalot package installed? You don't use it in your instructions.

hashalot

Yeah, I think you're right, it's not used or needed. I removed it from the article. Thanks!

Howto for Debian Squeeze

I've written up a small tutorial on how to use lib-pammount to automatically mount LUKS loopback images at login: Automatically mounted loopback images with dm-crypt, LUKS, pam_mount

Maybe someone is interested in this...

Even though the Debian

Even though the Debian installer can set up encrypted partitions, it is optimized for systems with a single data partition, unless you want to enter multiple pass-phrases when the system boots. Several people have pointed out to me that one can simply create a single encrypted “physical volume” with the Debian installer and place “logical volumes” for the various file-systems in there. I like partitioning my disks and use different file-systems for /tmp, /home, /var, and /usr/local for a number of reasons. This method is much cleaner and to be preferred. It’s quite likely that it also improves the speed. Thanks for the great stuff...!!!

yast

How I can mount my home directory encrypted by yast in opensuse without yast? (my system cann't start!, now I install kubuntu)
I have:
/home/user
/home/user.img (2Gb)
/home/user.key (288b)
?

data corruption

Q: what if HDD get some bad blocks/sectors, or any other corruption after being encrypted? How widespread the error will be on the unencrypted view? Will all my data lost or just a file or two?

Thx, Dolfy

corruption

Good question, I was planning on testing just that on some test image. I guess only some blocks will be affected, but it probably also depends on the type of cipher and mode you use.

If anybody else does tests, please leave a comment and let us know.

Thanks

Thanks for this howto, I have aplied it to an external harddrive in Fedora 10 without any problems.

Anonymous

dd if=/dev/urandom of=/dev/sdb
is VERY slow.

I use this command:

shred -n 1 /dev/sdb

This work 100x faster.

this is even slower dd

this is even slower
dd if=/dev/random of=/dev/sda

and this is far too fast
shred -n 1 /dev/sda

this is a good compromise
shred -n 12 /dev/sda

Try ATA over ethernet

If you are installing on a slow laptop and have a fast machine on the local network, try ATA over ethernet:

ATA Over Ethernet On Debian

Here it depends on the speed of my 100Mb ethernet. I run the urandom on a quad core AMD64 machine and fill the disk partition on a Pentium-M 1.6 GHz laptop.

Hans

I find it strange, because

I find it strange, because shred is by default using exactly the same /dev/urandom, which is almost sure to be a bottleneck. Actually, in my case, there's really no noticeable difference. Maybe if you tell dd to copy more blocks at once, it will go faster?
e.g.
dd if=/dev/urandom of=/dev/sdb bs=10240
(10MiB at once)

or wipe /dev/sdb

or

wipe /dev/sdb

HOWTO do this without formatting the drive?

Thanks for the tutorial...it was the easiest I have seen yet!

But, I want to do this without formatting my drive. Can it be done as easily? I have seen tutorials but they seem a bit vague, so when I found your site I thought I'd ask you as you seem to be in the know...

I installed Debian Etch on a server and I have an external firewire WD MyBook 320GB attached to it. Debian is using dmcrypt and LVM at the moment for all partitions except /boot so I think I have everything on the server to be able to do this.

I saw somewhere on an Ubuntu forum that this could be accomplished by using dd to copy the contents of the drive back to itself by going via the mapper device and it was basically two commands to run, one to setup the mapper and the other to run dd with 'if' as the /dev/sda1 and 'of' as the mapper device. Does this seem safe?

dm-crypt

Hi, first of all, the latest Debian installer already has an option to automatically setup all of this stuff for you, no command line hacking needed anymore.

I'm not sure I entirely understand what you're trying to do (or how the proposed dd hack is supposed to work). I don't know any easy way to make a dm-crypted disk out of an unencrypted disk. The only way is to make backups on some other disk/medium, install a fresh Debian with dm-crypt (via installer or manually) and then copy the backups (your data) on the new, encrypted disk.

HTH, Uwe.

HOWTO encrypt existing partition with dd

I found the link (not ubuntuforums) that explains how to do this on http://www.richardneill.org/a22p-mdk11-0.php#encrypt2 ...

[5] An aside on dm-crypt/cryptsetup

Actually, dm-crypt is the most promising way, but it involves too much fighting with Mandrake's init-scripts. Also, diskdrake doesn't understand, and I would guess that drakupdate_fstab won't. There is no need to use it (loop-AES is fine), but since I attempted it, here are some brief notes.
Here is how to Encrypt an existing device using the device-mapper.
init 3
umount /home
modprobe dm-crypt
cryptsetup -yv -c aes -s 256 create hda9-aes /dev/hda9 #hda9 = /home. Passphrase = usually 256 = max key size.
dd if=/dev/hda9 of=/dev/mapper/hda9-aes bs=64k #this should encrypt the data in place.
reiserfsck /dev/mapper/hda9-aes #check the filesystem.

off topic

this is not the LUKS way
it's just the normal crypt_dm way, which cannot change key or have more than 1 key

It all went to h*ll

Hi Uwe,

I decided to follow your guide after having mailed the debian-users list and been advised against the dd copy method :)

I followed your guide to the letter and it seemed to work perfectly, but I now have some serious issues with weird behaviour and serious performance issues.

My setup is:

Acer Aspire AMD Turion ML-28 1.6GHz 512MB running Etch 4.0r1 fully encrypted with LVM created using the guided partitioner.

Western Digital Firewire400 MyBook 320GB formatted as per your guide.

issues:

1. performance is at 50% normal compared to before encrypting the external drive. SCP from another ethernet connected laptop to MyBook gives very varying speeds from 2.9MB/s to 7.2MB/s instead of normal constant 11.5MB/s without encryption. Read performance is just as bad over wireless at 1.5MB/s instead of 2.5MB/s.

2. SCP constantly "stalls" (in the CLI it says -Stalled-) quite often so that copies take much much longer than they should *at that transfer rate*. I have never seen scp stall before.

3. If I copy a file from the host laptop to the MyBook using cp from terminal then CPU goes to over 90% with kjournald and kcryptd/0 using the CPU. If I time the copy with /usr/bin/time then after copying it only reports having used ~2% CPU!?

4. If I move the focus to another window other than the terminal window whilst copying, then CPU drops to zero, disk activity stops and "nothing happens" until I re-focus on that terminal window. Same bahaviour if I shut laptop lid (its set to blank screen) or if screensaver becomes active.

Just to re-iterate; I installed Etch last week, standard net install with laptop, base and desktop options. Other than that, no changes from default install. I have since enabled CPU frequency stepping as it did not work OOTB. Everything else is from the standard install.

I would really appreciate if you could give me some tips or ideas as to what the issue could be and whether this performance hit is normal.

--andrew

This is probably better

This is probably better posted in debian-user, but here are some ideas. The problems seem more network-related than dm-crypt related to me. The slowness may have to do with the CPU frequency scaling, make sure you don't put it into "powersave" mode or similar (where the slowest frequency will be used).

I use dm-crypt on quite a number of PC and I don't see any noticable slow-down.

dmcrypt issues with Etch standard kernel

I fixed the problem by compiling and running kernel 2.6.23.9. disk activity is now fast and constant but CPU usage is still high. Seems like kernel supplied with Etch is not suitable for usage with dmcrypt.

Of course CPU usage is high,

Of course CPU usage is high, the CPU is being used to run the encryption and decryption algorithms. When combined with SCP, it has to do the usual SSH encryption/decryption, plus the LUKS encryption/decryption. If you want that done fast, it needs clock cycles. Duuhhh!!

To do what so that the content can be read out in other machines

I have a question that if I wanna the contents on an encrypted partition can be read out on another computer, what should I do? Just use cryptsetup to build another mapping device and mount it?

Yes, wipe would be another

Yes, wipe would be another option. Or shred. I'll try to find a comparison of all these tools and their effectiveness in regard to "real" random garbage and their speed.

cryptsetup on another computer

I'm not sure that this is what you're looking for, but yes, you can rip out the hard drive from computer A, put it in computer B and use cryptsetup (either from the hard drive you just moved, or from another drive on computer B or from a live CD in computer B) to mount the encrypted volume (given you know the passphrase, of course).

HTH, Uwe.

Security of LUKS vs. loop-AES

Although I'm not a cryptographer either, if the loop-aes image resides on a filesystem on which journaling has been enabled (pretty common these days), that can give attackers information on how the encrypted file system has changed over time. This might only be relevant for weak cipher feedback modes. From http://en.wikipedia.org/wiki/Disk_encryption_theory:

----
Despite the fact that it is possible in practice to use the counter (CTR) mode with a single IV per volume, such uses are insecure if an adversary is able to gather several encrypted versions of the same sector (e.g., snapshots taken at different times).
----

luksClose

where you have cryptsetup luksClose /dev/mapper/<name>, I found that did not work, I had to use cryptsetup luksClose <name> instead.

Ciao

luksClose

That's strange, both should work. I just tested both variants and both work fine. This is cryptsetup-luks 1.0.5.

Uwe.

thanks!

Works like a charm. Thank you!

OTP

How to add one-time password support to an encrypted device?

luks, xfs, hardware raid..... issue

When I try to format xfs partitions above 2-3gb my opteron experiences heavy io wait; the mkfs.xfs fails, and I receive the following....

"mkfs.xfs: libxfs_device_zero write failed: Input/output error"

When I format partitions below 2-3gb, there is no problem whatsoever. I can mkfs.xfs on a +2-3GB non-luks formated partition without a problem. I can format above 2-3gb luks partitions using ext3 without a problem. I like xfs, I like luks, but why don't they like each other? ...any thoughts?

(the xfs gurus suggested I pose my question to the luks gurus, due to the fact that xfs formatting works on the same partitions without luks)

Thanks man, Great article

Thanks man, Great article

mounting as normal user

Hi
Are you able to open (luksOpen) and/or mount as a normal user?

I ran this command as root
cryptsetup luksOpen /dev/sda1 sda1

and mounted my partition as normal user but then, the partition becomes "READONLY". Only root can write onto it...

My /etc/fstab:

/dev/mapper/sda1 /mnt/sda1 ext3 noauto,rw,users,nosuid,exec 0 0

Any suggestions...

Try changing the permissions

Try changing the permissions or ownership of the mount directory (ie. /mnt/sda1). Eg, change owner to the user who will use it, or change permissions to 777.

UPDATE?

Hello, Uwe!
According to this:
http://packages.debian.org/testing/admin/cryptsetup
LUKS is supported now in 'testing'.
~Cheers~

Enable the following options in your kernel??????

> Enable the following options in your kernel:

As more & more Linux users; not programmers nor hobbyists--but users, like myself, install Linux using a single disk: MEPIS, Knoppix or Ubuntu; all of which are Debian based. Many of us have absolutely no idea how to make kernel changes. Can you point to a reference that explains this part from the absolute ground-up?

Thanks,

Lance

Derek

You have a very nice site and good guestbook, thank you.

Then wait until distributions pick up the technology

Fedore Core 5 seems to include Luks support already, with user-friendly GUI tools.

Take cryptsetup from unstable

In the item 4, it should be noted that currently Luks support is only in the cryptsetup package in unstable, not in the testing one...

backports

You may also use :

deb http://www.backports.org/debian/ sarge-backports main

in your /etc/apt/sources.list if you want to have Luks support in the cryptsetup package in stable.

P.S. thanks for your mini how-to !

Thanks, I have clarified

Thanks, I have clarified this in the article.

Tyson

keep up the good work

Seems unsafe

Unless I remember incorrectly, "badblocks -t random" will generate one random pattern (one block, default 1k)....and write that repeatedly to the drive.

This defeats the purpose of the random write. Instead, a dd if=/dev/urandom of=/dev/sdb should be performed (which will take several hours or even days depending on disk size and processor speed)

badblocks and random numbers

Yes, the badblocks randomizing method should not be considered very secure, those are no "real" random numbers. But I guess it's better than nothing (i.e., better than a disk full of zeros).

dd with /dev/urandom takes 2-3 days on my Pentium M 1.6 GHz and a 300 GB USB hard drive. And the CPU load is at 100% constantly, both my laptop and the drive get quite hot...

Not better than zero

Well...the problem is that it would be just as easy to distinguish unused blocks.

Find any commonly recurring block, and there you go...

A better, asm-optimized solution would be to setup a temporary cryptmount (for example with a random key from /dev/random and using aes256 cipher) and dd /dev/zero to that.

Provided that aes is not a weak cipher, which seems unlikely, the output should be indistinguishable from random data, and the operation should be quite a bit faster than urandom.

How about using wipe

I remember there are specialized apps for secure deletion of a drive.
E.g. wipe. Maybe these could help here? They might contain a fast way to generate useful random patterns.

make sure you understand what is happening

before you use a tool such as shred!!!!! You cannot leave the drive blank (all zeroes). If you use a tool that zeroes out the drive, while the erased data will be obscured at the least, your new data will be very vulnerable. You have to have random data (or as close as you can get within your time constraints) when setting up the partition, zeroes are not random! Go with the badblocks, or /dev/urandom methods commonly used.

wipe

Yes, wipe would be another option. Or shred. I'll try to find a comparison of all these tools and their effectiveness in regard to "real" random garbage and their speed.

If you know such a study (no ad hoc tests please, only scientific papers from some serious cryptographer), please let me know.

Uwe.