openmind ☃   November 21, 2009  ☃  Archlinux: Encrypting Existing Partitions With Luks  (, , , )

This is a first draft until I figure out how to get the /dev/mapper to open up automatically upon boot

[Edit: Sat Dec 12 12:04:23 CST 2009]

Auto-mount is easy. Make an /etc/fstab entry:

/dev/mapper/label /drum/label ext3 defaults,user 0 1

And a corresponding /etc/crypttab entry:

# NAME      SOURCE DEVICE       PASSWORD        OPTIONS
label       /dev/sdd1           ASK

Introduction

The Ubuntu community documentation freely admits that disk encryption is a topic intended “for commandline-loving and experienced users.”

For a while now, I have been intending to try LUKS, as numerous Internet sources cite it as the de facto standard for Linux volume encryption. Loop-AES is a competing encryption standard.

Rationale

My inital goal has been to enable LUKS on some of my non-root partitions and copy some various (ahem!) media over. In all seriousness, however, there are amply documented reasons for using encryption that are beyond the scope of this post.

Practically speaking, I am particularly interested in two issues:

  1. How much does encryption slow down I/O?
  2. Does encryption cause me to lose data (is LUKS reasonably stable)?

I plan to answer these questions with anecdotal evidence over the next six months or so, and if favorable, I’ll make LUKS more of a central part of my system.

[Edit: Sat Dec 12 12:12:56 CST 2009]

So far, so good. No data loss, and it’s not noticeably slow. Only problem I have experienced so far is that my inadequately-cooled P4 shuts down sua sponte. That said, I hesitate to go all-in (/root, /boot, swap, etc) until I have more stable hardware.

Research

I zipped through the ArchWiki LUKS encryption guide until I hit the following section on applying LUKS encryption to non-root partitions:

You might get tempted to apply all this fancy [LUKS] stuff to a non-root partition. Arch does not support [non-root LUKS partitions] out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt . . . Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.

Cringe. I had a gander at that file; the first few lines read:

2 # TODO this one needs some work to work with lots of different
3 #       encryption schemes

Yes, and non-root partitions. Turns out this is going to need major work.

“Further hacking” is the “preferred solution” if and only if one has time and motivation to go poking around in the initcpio hooks (which just so happen to be subject to overwrite during upgrade!).

Caveats

The following method cheats by first copying existing data to another partition, so it assumes at least as much free space (on the second partition) as is occupied by the data on the existing partition.

You should always make a backup of your data before attempting any major change (like this one). Also, ensure that you get the /dev/sd** device names right; that can be really tricky.

Also, if you are using gnu screen, make sure you are executing these commands in the correct terminal window ;)

Steps

Here’s the process to convert an existing partition to cryptsetup-luks:

First, move the existing data to another partition, unmount the existing partition, check the existing partition, and overwrite existing blocks with zeroes (assume /dev/sdd1 is initially mounted at /mnt/mydir):

# mv /mnt/mydir/* /mnt/mybackupdir
# umount /mnt/mydir
# e2fsck /dev/sdd1
# dd if=/dev/zero of=/dev/sdd1 bs=1M

N.B.: dd may take a few minutes to run. Mine did an 180G drive in about 10 minutes.

Second, create a new (journaled, ext3) partition:

# mke2fs -j /dev/sdd1

N.B.: If you use UUID to identify devices in /etc/fstab, yours will change when you unmount and re-partition the existing drive. You can obtain the new UUID by typing # blkid /dev/sdd1 or # ls -alh /dev/disk/by-uuid/.

Third, load some kernel modules:

# modprobe dm-crypt 
# modprobe aes-i586

Fourth, create and open the LUKS partition:

# cryptsetup --cipher aes-xts-plain --verify-passphrase --key-size 512 luksFormat /dev/sdd1
# cryptsetup luksOpen /dev/sdd1 label

It will ask for your passphrase twice and then say “key slot 0 unlocked.” /dev/mapper/ will also contain an entry for “label”.

Two good diagnostics to run at this point are:

# cryptsetup isLuks /dev/sdd1 && echo Success
# cryptsetup luksDump /dev/sdd1

Fifth, create a filesystem on the mapped partition. This is exciting, we are actually writing encrypted data at this point!

# mke2fs -j /dev/mapper/label

Sixth, mount it:

# mount /dev/mapper/label /mnt/label

Now /mnt/label can be used like any mounted drive.

References

Encrypted Devices Using LUKS (saout.de)

Encrypted Filesystem Howto (help.ubuntu.com)

LUKS dm-crypt:unlock multiple volumes by one password at boot? (bbs.archlinux.org)

Crypt non-root (bbs.archlinux.org)

Disk Encryption Guide (ha.redhat.com)

blog comments powered by Disqus