Disk Encryption HOWTO
Prev		Next

1. Introduction

I've got a laptop computer running Linux and I don't want to worry about someone reading the personal information it contains, in case it gets lost or stolen. My log on password may stop someone from booting it, but it won't prevent an attacker from removing the hard disk and reading its data. I need stronger protection.

Fortunately, it's relatively easy to use encryption so the hard disk data would be unreadable if it were to fall into the wrong hands. Encryption's not only useful for portable computers like laptops—it can be used to protect any computer with personal information. I protect my computer's files with encryption for the same reason I lock my filing cabinet at home. For further motivation, you may be interested in reading Michael Crawford's Why You Should Use Encryption.

I could encrypt only certain files, such as those in my home directory. This would protect the files but then I'd have to worry about information leaking out of them to other, unencrypted places on the disk. Instead I encrypt the whole disk so I don't have to manage this problem.

There are many encryption algorithms to choose from. I chose AES because it has been approved by the US government's National Institute of Standards and Technology and is well regarded by the cryptography community. I want my use of it to be resistant to dictionary attacks, so I use a long, randomly generated key. There's no way I'm going to memorize such a key so I keep it in a form I can carry with me easily: on a USB flash drive on my keychain. I encrypt the key with a passphrase so my data is protected in two ways: by a) what I have (the USB flash drive) and b) what I know (the passphrase). I can even give a friend access to my computer without giving away my passphrase—she uses her own USB flash drive and her own passphrase.

The operating system keeps the data encrypted on the disk at all times and decrypts it in RAM only as it's used. This way if the computer loses power suddenly the data will remain protected. The decryption key is loaded into RAM at boot time and kept there while the computer is on, so I don't need to keep the USB flash drive plugged in after starting the computer.

The procedure outlined in this HOWTO is written for version 2.4 of the Linux kernel. It will become less complicated with the release of Linux 2.6, which will have built-in support for encryption and do a better job of managing partitions within loopback devices.

This document assumes the reader has a moderate level of experience with Linux (you should be comfortable patching and compiling kernels as well as partitioning, mounting, and unmounting disks).

1.1. Technical Summary

The encryption is implemented through a special kind of loopback device. A loopback device doesn't store any data itself; instead it takes all the data storage and retrieval requests it receives and passes them along to a real storage device, such as a disk or a file. As the data passes through, it can be filtered, and in our case the filter used is encryption.

When the system is deployed, a removable medium (USB flash drive) boots using GRUB, a kernel, and an initrd. Both the key and the kernel are selected from the GRUB menu, allowing a single removable medium to be used with multiple computers. The initrd contains just enough tools to ask for a passphrase, set up an encrypted loopback device, and mount it. After mounting, pivot_root is used to resume the boot process from the encrypted device. Loopback device offsets are used, instead of partitions, to access separate swap and root file system spaces within the encrypted loopback device because the 2.4 kernel doesn't provide access to partitions within loopback devices. The offset method does not generalize to multiple partitions (unfortunately) because the maximum offset understood by losetup is 2GB.

1.2. Copyright and License

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in Appendix A.

Linux is a registered trademark of Linus Torvalds.®

1.3. Disclaimer

No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies that could be damaging to your system and you may lose important data. Proceed with caution, and although this is highly unlikely, the author does not take any responsibility.

All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.

I know you hate reading directions and want to skip to the meaty bit right away, but I advise you to read the whole document first before touching anything. I know all the HOWTOs say that, but I really mean it for this one. It's worth it; trust me. You may also want to run through the procedure first on a test system before tackling a production system.

1.4. Acknowledgments

Thanks to Linus Torvalds, Jari Ruusu, and all the developers who contributed to their software, without which this HOWTO would have been impossible.

Thanks to the National Institute of Standards and Technology for carefully selecting a strong, open encryption algorithm.

Thanks to Mark Garboden and others on the linux-crypto mailing list and The Linux Documentation Project mailing lists who took the time to critique my writing and offer suggestions.

Thanks to alert readers Ladislao Bastetti and Norris Pouhovitch for struggling through unusual hardware configurations, finding mistakes in the HOWTO, and suggesting good ideas.

1.5. Feedback

Feedback is solicited for this document. Please send additions, comments, and criticisms to the author.

1.6. Approaches

There are three different approaches we can take to encrypt the disk: encrypt the whole thing, a single partition, or a single file. I strongly recommend the first approach for best security. The first two approaches assume you'll be booting from removable media, such as a USB flash drive or a business card size CD-ROM. If you don't want to do this, you may modify the method to boot from the disk instead by making a small, unencrypted boot partition. If you want to use a USB flash drive to boot your computer, be sure your motherboard can do it first. At the time of this writing many cannot.

To avoid having to enumerate all three approaches everywhere I'm going to refer to what you're protecting as the asset. I will refer to the removable medium used to store the key as the keychain. I call it the keychain instead of the key because we can store lots of keys, each for different computers, on the same medium.

1.6.1. Whole Disk

A problem with keeping data secret with encryption is that the data likes to move around. Imagine the encryption is like a fence around your data. While the data's inside the fence, it's safe. To be most useful, however, data likes to be transmitted on networks, put on removable disks like CD-ROMs, and shared with friends. Any time your data leaves the fenced area it's unprotected. We can't put an encryption fence around all possible locations where our data might play but we do want to make the fence as large as practical. By putting the encryption fence around your whole hard disk, you won't have to worry about data becoming unprotected if it jumps to another part of the disk.

In this approach, we create one swap space and one root file system. Some people want more than a single encrypted partition for the root file system. Unfortunately, the method detailed here relies on the offset parameter of losetup to create "subpartitions" within the asset. The offset parameter is limited to a maximum value of 2GB, limiting the size of all but the last partition to 2GB. This works nicely for swap, which is already limited to 2GB on the i386 architecture, but I'm guessing it won't be practical for other uses. Using it to create multiple partitions smaller than 2GB is left as an exercise for the reader.

Another way to handle multiple partitions is to encrypt each partition separately (using the same key) to avoid the technical limitation above. This isn't secure as encrypting the whole disk because the partition table is exposed. When an attacker attempts to break encryption, the first thing he does is try to figure out what it's encrypting. A partition table listing Linux partitions is a big hint. For this reason I discourage encrypting multiple partitions separately, but arguably it's a good compromise for getting around the current losetup limitation. Another option is simply to wait for the release of Linux 2.6 because it is expected to make the offset parameter unnecessary.

1.6.2. Partition (for multiboot systems)

Encrypting the whole disk is fine if Linux is the only operating system on it, but this won't work for people who have set up their computer to boot multiple operating systems, e.g., Linux, NetBSD, and Darwin. In this case we can encrypt just the Linux partition and leave the others alone. Since we're booting from a removable medium, we won't even need to include the Linux partition in the multiboot menu with the others. To see why this isn't as secure as encrypting the whole disk, read Table 1.

1.6.3. File (for home directories)

You may want to encrypt only a file on a file system. Once you've encrypted it you can put into it whatever you want, including other file systems. You might want to use this approach to encrypt only your home directory, for example. This is the least secure of the three approaches and not recommended. If you choose this approach you will notice instructions below to skip whole sections. This is because I'm assuming you've already booted an operating system and have your swap issues handled, so those sections don't apply to you. This HOWTO may be overkill for your needs and you can probably get away with just reading the fine README that comes with loop-AES. If you do, be sure to read Section 1.7 before you finish here.

1.7. Threat Model

In order to protect our asset well, we must first understand what we're protecting it against. The general idea is that you've got a laptop which is vulnerable to being stolen or lost, and have a USB flash drive on your keychain that isn't, so this system is designed to handle the case that your laptop is stolen. I'm guessing your keychain won't be as easily stolen because it's in your pocket, and because an attacker won't know that it's important. If you pull your USB flash drive out of your pocket and someone non-technical exclaims, "What's that?", tell them it's a Pez dispenser.

This system falls short when it comes to plausible deniability, which means there's no way to hide the fact that your personal data is encrypted. This is like locking your jewels in a safe and keeping the safe in plain sight in the middle of your living room. Only you can open the safe, but a man with a gun can tell you to open the safe for him. So if you're worried about your computer being subpoenaed and being told to hand over your laptop, keychain, and passphrase, you'd better look at other solutions such as StegFS.

The following solution to the deniability problem has been suggested by Norris Pouhovitch. It should be possible to install a minimal Windows partition at the front of the disk and to encrypt the remainder. When the computer is turned on without the keychain, it boots Windows normally. When the keychain is booted, it skips the Windows partition, decrypts the remainder of the disk, and boots Linux.

The advantage of this scheme is that if the laptop is stolen and turned on, it will look like what a casual attacker is expecting to see (a Windows computer). On the other hand, a serious attacker could notice the unusually small partition and become suspicious. I will flesh out this idea further in a future version of the HOWTO.

Table 1. Attack Tree

Attack				Reaction	Notes
attacker steals laptop	while it is on			SOL	The asset is unprotected while the computer is running because the encryption key is in RAM. You can lower the risk by using an idle logout (Section 2.6.3), but if you think your laptop is about to be stolen, turn off the power immediately and quickly read the Aikido HOWTO.
	while it is off	attacker doesn't steal keychain		new key
		attacker steals keychain	attacker knows your passphrase	SOL
		attacker steals keychain	attacker doesn't know your passphrase	new key
attacker steals keychain but doesn't have laptop	attacker knows passphrase			new key	Your asset is at risk because the attacker can decrypt it.
	attacker doesn't know passphrase	you're feeling lazy or you're convinced the keychain was lost, not stolen		new passphrase	You're probably OK without changing the asset key because the attacker can't decrypt the asset without the passphrase.
	attacker doesn't know passphrase	you're feeling paranoid		new key
attacker convinces you to send data over network				SOL
attacker convinces you to copy data to removable medium				SOL
you encrypt only a partition and a process writes data to a different partition				SOL
you encrypt only a file and a process copies data from RAM to the unencrypted swap, or to a file in `/tmp`, or elsewhere on the unencrypted disk				SOL
attacker demands you hand over laptop, keychain, and passphrase while waving a rubber hose menacingly				SOL	There is no plausible deniability built into the system.

new passphrase: Restore the keychain backup and choose a new passphrase.
new key: Generate a new random key to re-encrypt the asset, choose a new passphrase, and restore the asset backup.
SOL: Sorry Over your Loss

1.8. Caveats

This method won't work (yet) with Software Suspend for Linux.
Encrypting the disk will undoubtedly slow it down. I don't know by how much. If anyone has done some benchmarks, please send them to me.
There is nothing in this method to support plausible deniability (see Section 1.7).
It won't prevent information leaks via networks and removable disks.
Encrypting backups is beyond the scope of this HOWTO.

1.9. Requirements

a computer with an easily accessible removable medium reader (such as a USB port or a CD-ROM drive)
a motherboard which supports booting from removable media (check carefully for USB, not all do)
removable medium (such as a USB flash drive) to be used as the keychain
Linux 2.4
loop-AES

1.9.1. A Digression about USB Flash Drives

There are many choices on the market. When I bought mine, I found one which fit the following requirements:

physically small (I carry it on my physical keychain)
supports USB 2.0 at full speed
has a write-protect switch, so I don't clobber my encryption keys by accident

You might be tempted to get one with a fingerprint reader. I strongly encourage you not to. It might initially seem like a good idea, because by adding the biometric, your security protection expands to:

something you have (the USB flash drive)
something you know (the passphrase)
something you are (your fingerprint, or whatever)

However, suppose something goes wrong. If you are now asking yourself, "What could go wrong?", then why are you reading this HOWTO? If something goes wrong, you make a change (see Corrective Reactions):

Change what you have by using a different USB flash drive.
Change what you know by learning a new passphrase.
You can't change what you are.

Stop and ponder that last line for a while.

1.10. Looking to the Future

I wrote this document while using the 2.4 kernel. Linux 2.6 introduces the Device-mapper which we will be able to use to avoid playing games with losetup offsets. Linux 2.6 also introduces dm-crypt, an encryption layer for the Device-mapper which looks quite elegant. Unfortunately, it's not safe! Hopefully someday it will be fixed, but in the mean time the best course is to stick with loop-AES.

A future version of this HOWTO will explain how to use the Device-mapper with Linux 2.6.