Quasi una fantasia (Mac's Blog)

Why this article?

I wanted to encrypt my netbook (running Arch Linux). Using the Arch Linux wiki as my primary source, I didn’t find the process to be too straightforward. In particular, the LUKS article seems to assume you’re doing a fresh install, which isn’t necessary. I hope to make the process easier for others and clarify my own thinking about it.

Who is this article meant for, and how do I read it?

This is meant for someone who doesn’t know how to do encryption on their computer (ideally an Arch Linux system, although I think it’s pretty Linux generic). It’s intended to be read linearly. I’d welcome any feedback/suggestions/clarifications/amendments, etc. There’s a lot of really cool stuff you can do that’s not mentioned here.The wiki links below are excellent sources of information.

Why encrypt?

There are a number of reasons why you might want to encrypt your data. In thinking about what kind of security I need, my imaginary “adversary” is an airport agent who can seize my laptop, copy the data off it, and pass the data on to a buddy who specializes in identity theft or stealing credit card numbers. Since I plan on international travel, and since I have this kind of information on my netbook, this is an actual concern for me.

What are the options for encryption?

1. GnuPG. Good for emails and possibly if you want to encrypt a few files. Not what we’re looking for here (I want to encrypt at least my entire home directory).
2. TrueCrypt. Can be used for full partition encryption or for creating an encrypted file or directory. This would be an acceptable tool for the job. However, I was told in IRC that TrueCrypt is “easier but not as professional.” In my experience with it, it can be kind of opaque, and the authors’ website is really sketch. So those marginal factors are what let me to go with option 3. Note that TrueCrypt can give you plausible deniability (see section below), which isn’t something I’m interested in at the moment.
3. LUKS for dm-crypt. This seems to be the “professional” way to do it, and seemed to be “acceptably” well-documented. This is what I settled on. I’ve been really happy with this so far. I imagine you can get plausible deniability with it somehow, but I haven’t looked into it.

What is this “plausible deniability” issue?

What if somebody points a gun at you and tells you to decrypt your data for them? Or what if you just want to not look suspicious? Or what if you’re leaving/entering a country that does not allow you to take/bring in encryption, and you’re worried they’ll actually catch you and enforce the rules? You woul want to hide the encrypted data by making sure it looks like random data, and then making sure the rest of your data looks legit and “normal.” You could even have a secret encrypted partition inside an “obvious” encrypted partition. This isn’t really a concern of mine right now, and so is outside the scope of this article.

What needs to be encrypted?

Ideally, you keep all your private data in your home directory. So you don’t need to encrypt the root partition. Some people do, but I personally would like to avoid that. You also don’t want to encrypt your boot partition, unless you want to make your computer only bootable from an external USB drive. That’s a pain, and probably not worth it unless you really want to (mostly) defend against the Evil Made Attack, which I’ve written about before. I’m not that paranoid. Additionally, there is concern about /tmp. If you set up /tmp to be a separate partition from / and to use tmpfs, the data is lost whenever you reboot, so there’s no concern. I actually don’t have this setup, but I’m not worried that any programs I use will write sensitive data to /tmp. So that issue isn’t further covered in this article.

What do you need to encrypt? /home, and the swap partition. The swap partition stores data that won’t fit in main memory, if all your memory gets used up. So if you don’t encrypt it, open file in /home could leak into swap space and onto your hard drive. A determined attacker (e.g. computer-savvy criminal) would be able to retrieve it with a tool like Foremost.

How do I figure out how my partitions are set up?

You can do this by catting /etc/fstab. Typically, partitions are given names like /dev/(s|h)daX (where X is an integer) by the Linux kernel. Under normal conditions, they don’t change numbering. However, there are some circumstances in which they may. Arch Linux by default now uses UUIDs for each disk in the /etc/fstab. If you want to correlate these UUIDs to the normal partition names, run the command blkid as root.

Under Arch Linux, /home is on its own partition by default, so I’m going to assume you have that setup already.

Do I need to back up?

YES. In my case, I’d been using my netbook for a while, so I just backed up my home directory, and then after I had an empty encrypted home partition, I copied it back over from an external USB drive.

How do I clear out any old, possibly sensitive data that has been written to /home or swap?

dd if=/dev/zero of=/dev/sdaX, replacing X with the appropriate partition. For me, /dev/sda2 is swap and /dev/sda4 is /home. This wries zeroes over the entire partition, destroying it. There are other options (e.g. /dev/urandom to write random bits), and they are documented in other places (not here).

What software do I need to install?

With Arch Linux, at least in my case, I already had everything I need. The cryptsetup package is part of the ‘base’ Arch Linux package group. I don’t know where the dm-crypt and aes-i586 modules come from (NOTE: plase let me know if you can tell me how to find out this information…). If it turns out you don’t have something, you can probably get it pretty easily with your package manager.

OK, how do I set it up, already?

Load the necessary modules (I’m assuming aes encrpytion):

# modprobe dm-crypt
# modprobe aes-i586

Write a LUKS (Linux Unified Key System) header to your /home partition. You’ll be prompted for a passphrase, which you will have to supply in order to use the encrypted partition in the future. It’s also possible to use a keyfile, but that’s not covered in this article.

# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sdaX

Mount the partition. This will create a device at /dev/mapper/home which is what you actually read to/write from (i.e. it performs the encryption and decryption). You’ll be prompted for your passphrase.

# cryptsetup luksOpen /dev/sdaX home

Create an ext4 filesystem (or some other filesystem of your choice) in the partition.

# mkfs.ext4 /dev/mapper/home

Update /etc/crypttab, which will be checked automatically at boot time. The following entry should work for you. It tells dm_crypt to ask for a passphrase to mount /dev/sdaX as /dev/mapper/home, and to create a new swap partition at /dev/sdaY with a random key.

home /dev/sdaX ASK
swap /dev/sdaY SWAP -c aes-xts-plain -h whirlpool -s 512

Update your fstab to reflect the /dev/mapper devices, instead of /dev/sdaX (or possibly UUID=) devices.

/dev/mapper/swap swap swap defaults 0 0
/dev/mapper/home /home ext4 defaults 0 1

What else do I need to do?

You need to add dm_crypt and aes_i586 to the MODULES list in /etc/rc.conf.

That’s it. When you boot up, you should be asked for your passphrase.

Are there any pitfalls?

The only problem I had was that I originally set up my swap partition to be a LUKS encrypted partition with a passphrase. dm_crypt will not create a swap device for a partition that already has a LUKS header, so I had to re-zero the swap partition.

What if I need to change my passphrase?

This might happen if you accidentally reveal your passphrase. Fortunately, it’s not a problem.

You can have multiple passphrases for each encrypted partition.

To add a new passphrase, do this:

# cryptsetup luksAddKey /dev/sdaX

To remove an existing passphrase, do this:

# cryptsetup luksRemoveKey /dev/sdaX

In either case, user-friendly prompts will guide you through the process.

Special thanks

Contributors to the Arch Linux wiki (which is pretty much where I figured all this stuff out, although there were some non-obvious stumbling blocks for me), and the #archlinux IRC channel, which proved helpful.

Is this article a work in progress?

I’m sure it could use some more editing, and may receive some, but I think it’s reasonably complete, in that I don’t believe I’ve left out anything important and non-obvious.