Copyright © 2004 David Braun
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.
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.
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.®
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.
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 alert readers Ladislao Bastetti and Norris Pouhovitch for struggling through unusual hardware configurations, finding mistakes in the HOWTO, and suggesting good ideas.
Feedback is solicited for this document. Please send additions, comments, and criticisms to the author.
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.
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.
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.
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.
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.
Table 1. Attack Tree
There are many choices on the market. When I bought mine, I found one which fit the following requirements:
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:
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):
Stop and ponder that last line for a while.
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.
Meet new people