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

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