UPDATE - 20170327 - Truecrypt was disconnected in 2014.ev when Microsoft stopped supporting Windows XP. DO NOT USE IT. This blog post must be considered historical in nature.
If you've been following the news media for the past year or so, stores have been cropping up with frightening regularity about travelers who are detained at the border while customs agents demand the login credentials for their notebook computers so that they can be examined for gods-know-what kind of information. From time to time, the hard drives of computers are actually imaged for later analysis. As if that weren't enough, the United States Supreme Court has stated the opinion that this is permissible and a legally defensible thing to do, regardless of whether or not you are an American citizens, regardless of whether or not you're actually up to no good. Just a few days ago, it came out that Canada is trying to push through the Anti-Counterfeiting Trade Agreement, which would make it legal for Canadian border authorities to search not only portable computers, but USB keys, cellular phones, and MP3 players for information (specifically, pirated MP3 files)... the very act of searching one's personal and corporate storage media constitutes a potential information spillage situation because it may not be possible to prove in a court of law that data wasn't copied during the search. You can't necessarily prove a negative when you're dealing with file systems.
As one might imagine, not a few companies and government agencies (funny, that) are starting to get nervous about this because it means the potential leakage of sensitive information. Many companies put their employees under non-disclosure agreements that specifically forbid the disclosure of corporate information, and it's possible that they could lose their jobs if their computers are examined by the border patrol, even if they could prove that nothing sensitive was copied. On top of this, they can and have demanded the passwords to full-disk encryption software to facilitate their searches, which pretty much throws the "because it's encrypted, you can't prove that you have anything at all" argument to the dogs. As if that weren't enough to make important people sweat, there are now federal laws in effect that mandate hefty fines in the event that there is a data spillage - HIPAA comes immediately to mind.
These developments have so many people concerned that some companies are beginning to roll out policies in which laptops are issued to people in the field that have only a basic operating system images pressed onto them. Aside from a web browser and a basic office suite, there a VPN client is also installed. The person on field assignment connects back into their employer's network using the VPN client, and either uses Remote Desktop to access a server to get work done (which minimizes the possibility of data leakage) or copies data back to their issued laptop. Changes are pushed back later, usually just before the return trip. Secure erasure of data is performed to eliminate the possibility of data leakage in the event that the officials at the airport feel a burning desire to check out the laptop.
There are still people out there who espouse the "if you're not doing anything wrong, you have nothing to hide" party line, and by now if people far more erudite than I still can't convince them, I certainly can't. However, one thing that I wish to point out is how often laptop computers are stolen along with all of the data inside of them. How many of you out there manage your budgets and accounts with the same laptop that you take on the road? How many of you out there do your taxes every year on the same laptop that you take on the road? Aside from being easily sold on eBay or the black market, laptop computers contain lots of information that thieves (or accomplices of thieves with a decent amount of technical acumen) can pull off of the computer's hard drive and abuse. Stolen identities can go for as little as $0.40us on the black market these days, but being able to take out a $8kus line of credit that can be abused for a few months makes that handful of pennies worth their weight in platinum, if I may bend a metaphor until it breaks. Just because your laptop requires a password to get into doesn't mean that the hard drive can't be extracted, and the contents mined with a few minutes of effort. It is due to the fact that most security countermeasures are worthless once the attacker gets their hands on the hardware that disk and file-level encryption technologies are beneficial to set up on portable machines. I'm very much a fan of using such software as GnuPG and PGP to protect files of data on the hard drive, but there are a couple of subtle problems in doing this. Firstly, by default these packages add the extension '.gpg' and '.pgp' (respectively) to the filenames of encrypted files. That in itself would tell an attacker that there is encrypted data present, and then could come the lawsuits over not forking over your keyring and passphrase, jail time, and possibly rubber hose cryptanalysis, which isn't that far fetched an idea anymore when you consider what's going on in Guantanamo Bay and certain Eastern European countries. Of course, both of these packages can be configured to a) delete the plaintext file after encryption (though possibly not securely) and b) not use a standardized file extension. The trick in this case lies in getting the end user to tweak the configs of their software a little, which vanishingly few do these days. On the other hand, it's a point of consternation when you try to load your personal notepad file into a text editor and can't figure out for the life of you why it's full of junk...
Yes, it happens to me occasionally. I'm not perfect.
A couple of weeks ago, Bruce Schneier wrote an entry on much the same topic as this post, and goes into detail on using Truecrypt to protect one's data while in transit (surprise, surprise). He also raises an interesting couple of points in that not all sensitive data on your laptop is all that visible, such as the files maintained by your e-mail client that contain cached messages and attachments (possibly in decrypted form), your web browser's cache directories and browsing history, and system logs (which sometimes leak sensitive information). I noticed that he doesn't make any mention of Truecrypt's ability to create hidden volumes, encrypted volumes inside of encrypted volumes that can't be detected unless the user spills the beans. I have to admit, while I've been using Truecrypt for a while and find it an essential tool, I've never used the hidden volume support and so can't state an opinion of it. Having said that, I also cannot, in truth, state what happens if you make heavy use of a Truecrypt volume but don't turn on support for protecting a hidden volume (if there is one). I also don't know what happens if you turn on the 'protect the hidden volume' feature when one isn't actually present.
A couple of Linux distributions either directly support (i.e., by putting it in the installer) or have instructions in some form for installing either directly to or making use of encrypted partitions for extra security. The alternate installation disk for Ubuntu Linux v7.10 includes support for doing so; I'm not so sure about v8.04 of Ubuntu, not being a user or following the community (though if anyone knows for sure, please leave a comment and I'll update this post). I've seen instances of Fedora Core 7 and 8 installed on encrypted drives, though I don't know exactly how it was done. I know that Fedora Core 9 explicitly includes support for installing to encrypted partitions. Gentoo, my distribution of choice these days has ample documentation for doing just this. Debian GNU/Linux v4.0 also includes support for encrypted partitions in the installer, though not on all platforms yet (x86 is a given). Having not kept up with Slackware, I don't know if encrypted partition support has been added to the installer. If you use a persistent datastore with Puppy Linux (either by putting it on a USB key or by installing the OS to a USB key), you can configure strong encryption that protects not only your settings but whatever files you make use of while Puppy is booted.
I won't go over all of the methods of setting up encrypted partitions. I posted a few weeks ago about how I did it following the instructions in the Gentoo Wiki, and if you follow the directions for your distribution of choice you can do the same thing without much trouble - just remember to back up your data, first. For Windows users, I suggest making use of Truecrypt v5.x's whole-disk encryption feature. I know a couple of people who are using it, and they're very satisfied with it. I'll warn you, it takes a while to finish encrypting your drive, so read the instructions three times (just to be sure), be patient, and as with any radical course of action, for pete's sake, make backups!
I also won't go over what it takes to configure GRUB to dual-boot a system running Linux and Windows. Again, that's been documented time and again even though it's often done automatically by the installer. What I will discuss, however, is how to configure GRUB in such a way that it will boot into the OS of your choice on the drive while giving away as few clues as possible that other operating systems are present, and thus there are other filesystems that could be compromised.
Let's assume, for the sake of demonstration, that you have a laptop computer with Microsoft Windows XP on the first disk partition (/dev/hda1), an /boot partition for Linux on the second partition (/dev/hda2), an encrypted partition containing Linux and data for at least one user on the third partition (/dev/hda3), and a fourth partition that is used as encrypted swap by the Linux partition (/dev/hda4) (this is important because it keeps sensitive information and cryptographic keys from being extractable using forensics techniques if it's paged to disk). GNU GRUB is installed as the default boot-loader, and the file /boot/grub/grub.conf on /dev/hda2 contains the following:
# Global GRUB configs.
fallback 0 # OS-specific stanzas.
title Windows XP
chainloader +1 title Linux
kernel /boot/vmlinuz root=/dev/hda3
GRUB allows the user or admin of a system (with a personal Linux machine, the distinction is kind of fuzzy) to set a password that has to be entered before the user has the ability to edit the commands that pertain to a particular operating system (GRUB allows the user to tweak an OS' stanzas for the purposes of testing or fixing mistakes, and can also allow someone to boot into single-user mode). Also, if there are any OS stanzas in the config file that have the lock directive associated with them (I'll get to that in a moment), they will not boot until the password is entered on the console. While the operating system is running, log in as the root user and run the grub command. At the grub> prompt, execute the following commands:
grub> md5crypt Password:
Highlight the MD5 hash displayed with the mouse, copy it, and hang onto it. Using the output of the md5sum command from the shell won't actually work for this. Now, still as the root user, edit the /boot/grub/grub.conf file and add the following line near the top:
password --md5 $1$sXQsW$8mDuhhBpuElUX0WcqNmb6/
Save grub.conf and quit.
When next you reboot, you will find that you will only be able to select and boot an operating system from the GRUB menu; you won't be able to edit any of the OS' stanzas (by highlighting them and pressing 'e') until you press the 'p' key and enter the password.
After rebooting, log in as the root user again and edit the /boot/grub/grub.conf file again. This time, beneath the 'title' directive of each configured operating system, insert a line containing only the word lock, like so:
kernel /boot/vmlinuz root=/dev/hda3
Save and quit.
Now, for each operating system that's been covered by the lock directive, if you try to boot it, you will find that the boot loader will error out:
Booting 'Linux' lock Error 32: Must be authenticated Press any key to continue...
However, if you press the 'p' key and enter your password, you will find that GRUB will start the OS normally.
It is also possible to configure GRUB so that you don't know it's there unless you specifically trigger it. When left to its own devices, the boot loader will pause for a few seconds and then start the default OS for the machine (in this case, the copy of Windows XP). This is done by first configuring a timeout (let's say five seconds) and then marking the first OS in the config file as the default (Windows). Once again logged in as the root user, open /boot/grub/grub.conf in your favorite text editor and again near the top of the file change a few things:
Save the grub.conf file and quit.
Now reboot your machine.. what will happen is that you'll see the boot-splash screen from the BIOS (if you have one), and then you'll see the following screen:
GRUB loading, please wait...
Press 'ESC' to enter the menu...
The machine will wait for five seconds and then it'll boot into the first OS in the config file (remember, numbering starts at 0 and not 1). During that five second delay, however, if you hit the escape key on the keyboard GRUB will display the boot menu, and you can pick the OS to boot into normally. If you have a password configured, you'll still have to enter it to start any locked entries. The problem with using the hiddenmenu directive is that it's not subtle - you still know that there's something there, so if you're trying to not draw attention to the Linux install, this probably isn't a good way of going about it.
Now, you're probably saying to yourself, "Doc? Isn't this a royal pain in the ass? Aren't you being just a bit paranoid? Are you drinking too much coffee these days?"
You're right. If you go through this method step by step, you're looking at entering a password, selecting Linux from the boot menu, entering another passphrase to unlock your encrypted partition, logging in, and potentially unlocking an encrypted datastore or two using Truecrypt every time you boot your notebook. This is a lot of work to keep a Linux install safe on your laptop. However, I've written this missive in such a way that it describes the best disk security practices that I can come up with in a modular form. You can scale back what I've described to best fit your personal paranoia quotient and data security needs. If you think that having a hidden boot menu is too much, then don't do that. If you're more comfortable with having a single boot loader password rather than a BIOS password, then don't do that. If you feel that having a single passphrase to unlock your root partition to boot is sufficient, then stick with encrypted partitions only. All I ask is that you ask yourself honestly how sensitive the information on your notebook computer is, and what the impact of your personal data being posted to a BitTorrent tracker or a message forum someplace would be. If you think that it would result in identity theft, your family being harassed, or losing your job, then look into setting up disk or file encryption of some kind. If having a secure data deletion system in place would make more sense, then install one and make religious use of it. If, after doing a cost-benefit analysis, you feel that setting up a Citrix Metaframe, VNC, or a Remote Desktop box on your corporate LAN and installing an OpenVPN server, coupled with mostly blank laptops and a VPN client are the way to go, then by all means, do so.
Notice: I disclaim and and all liability for legal difficulties, harassment, arrest, damages, data loss, and other bad stuff that may happen as a result of following the instructions in this post (or any derivative therof). You're smart: You should know enough to not only back up your systems, but sit down and think about the consequences of your actions. If you're going to break the law, you do so at your own peril. If you're willing to take on the authorities head-on because you won't tell them your passwords (and haven't taken other measures to protect your data), that's on your head, too. If you act like a dick towards The Man, expect to be treated like one by The Man.
This work by The Doctor [412/724/301/703] is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.