Antarctica Starts Here.

As computers go these days, it is not unusual for the amount of free RAM to reach a critical level at which no other processes will fit into what little unused memory is left. Modern operating systems will then start swapping pages of memory to disk to make room; the data can be read back in later if necessary. This is a procedure called swapping, and it can take several forms. Windows maintains a large hidden file somewhere on the drive (usually in the root directory of C:) which it uses for this purpose. Linux, UNIX, and UNIX-alikes most often use whole disk partitions for this but are also capable of using files. Either way, the least often accessed pages of memory get copied to disk and freed from RAM.. however, this data often isn't overwritten later (because systems tend to have more swap than physical memory) which means that an attacker could later dig through these parts of the disk to see what you've been up to.

If you're curious about what might be hiding in your swap partition, the following command will be of interest to you, and will not damage your system in any way: sudo strings /bin/swapon -s | tail -1 | awk '{print $1}' | less (Temporarily assume root privileges. Use the swapon utility to list all of the swap devices in use; look at the last line of the output (most people only have one swap device); extract only the path to the device node. Run the strings utility (which prints only printable strings of text from whatever you run through it) on the swap device. Break the output down by pages.)

A lot of the output will look like junk, but if you're patient some interesting things will pop out at you, like parts of documents you've been working on, possibly bits of source code, copies of executing processes, temporary data, and encryption keys. Under certain circumstances, unprotected keying material can be dug out of swap and may be used to compromise encrypted data found elsewhere on the drive. Arguably just as bad is the fact that temporary copies of the data you were so carefully encrypting can sometimes be extracted from swap, so it doesn't matter if you've encrypted your plans for world domination if your adversary's plucky sidekick can run /usr/bin/strings on /dev/hda4 and pull out the plaintext.

For a couple of years now, OpenBSD has implemented transparently encrypted swap right out of the box - you don't know it's on all the time and you have to deliberately turn it off. In essence, every page of memory swapped out is encrypted with a randomly generated key which is conveniently forgotten when the page is deallocated, so there is no way of recovering the data later. In recent version of FreeBSD (since v5.3-RELEASE) and NetBSD encrypted swap is supported with varying levels of difficulty. The instructions for setting it up on FreeBSD are pretty straightforward: turn off your swap partitions, dd them full of junk from /dev/urandom and activate the geli(8) subsystem by editing the /etc/fstab file and appending ".eli" to the name of the swap device (for example, /dev/ad0s1b becomes /dev/ad0s1b.eli). By default, geli(8) uses AES with a 256-bit key to encrypt swap pages.

On the other hand, NetBSD uses a slightly baroque and counter-intuitive method of setting up encrypted swap - I'll not discuss it in detail here but you can read it in the official documentation. Call me a little crazy, but I find the idea of editing the disklabel of a special disk device (cgd), setting up the device, and patching an initscript by hand to restore the original disk label at boot-time a bit much. It certainly isn't a mature process, and as such I don't really recommend it.

Linux has a couple of ways of implementing encrypted swap - I used the dmcrypt instructions from the Gentoo Wiki to do so on my systems, but not everyone runs Gentoo Linux. If you want to set up encrypted swap manually it isn't difficult though you'll have to edit a couple of config files; for this reason, I highly recommend having some experience with Linux under your belt though I'll try to make this tutorial as straightforward as possible. To start with, you need to have device mapper support active in your kernel, either by compiling it in or having the modules loaded sometime during the boot process (before the swapon command is executed). To see if it's enabled in your system at the moment, execute the following command: gzip -dc /proc/config.gz | grep 'CONFIG_BLK_DEV_DM'. If the bit after the equals sign is a 'y' it means that it's compiled into your kernel, and you're home free. If you see an 'm' after the equals sign, it means that device mapper is compiled as a module which will have to be activated sometime during the boot process. If you don't get a result at all you'll have to follow your distribution's instructions for making use of it (Fedora Core has it out of the box, if I recall correctly; Ubuntu has documentation here).

You'll also need a recent version of cryptsetup - check your distro's package collection first, download and compile the source code if not. Chances are it'll be available in most distros these days. Log in as the root user and turn off your swap partition to keep from corrupting your system: swapoff -a will do this. Next, edit your /etc/fstab file and comment out all of the lines that have to do with swap space. They look something like this (substitute your swap partition as appropriate):

/dev/hda4 none swap sw 0 0

Save /etc/fstab and quit your text editor.

Now you need to prep the swap partition by overwriting it with random data so that the encrypted data can't be readily distinguished from the garbage. The command dd if=/dev/urandom of=/dev/hda4 bs=4k (again, assuming your swap partition is /dev/hda4) should do the trick. Be absolutely certain that you're junking the correct partition, otherwise you could hose your machine and have to reinstall.

Edit your /etc/rc.d/rc.local or /etc/rc.local script and add the following commands as close to the top of the file as possible:

(Note: rc.local is the one initscript that you're encouraged to edit for your own purposes. It's deliberately left alone by practically everything to be fully end-user controllable.)

(Note the second: if your distribution doesn't have device mapper support active by default, in the line right before the cryptsetup invocation add the line modprobe dm-mod to load the kernel module. Otherwise you'll get a "Command failed: Incompatible libdevmapper" error.) cryptsetup -c blowfish -h sha256 -d /dev/urandom create swap /dev/hda4 mkswap /dev/mapper/swap swapon /dev/mapper/swap Reboot your system. What will happen is that every time your system starts up, the swap partition that you junked will be set up with cryptsetup; the Blowfish algorithm will be used to encrypt the data paged out; the SHA-256 hash is used to grind up the password given (which is pulled from /dev/urandom by the -d option) for use as keying material. You don't have to re-overwrite your swap partition every time you reboot because the key used for encryption and decryption is a blob of random data pulled from /dev/urandom whenever it's set up. By rebooting your machine, the key is lost so the old contents can't be decrypted, which is functionally just as good. You have a couple of options as to which algorithms to choose, but in my experimentation the example above works well and is reasonably fast to both set up and use. On Windbringer (Intel Core 2 Duo running at 2.2 GHz) the whole process takes less than a second.

It should be noted that more and more distributions of Linux these days support installing to encrypted file systems right out of the box (Fedora Core and Ubuntu come immediately to mind). In particular, the installers support setting up a single encrypted logical volume, inside of which virtual partitions are created (don't worry about what this means; as far as we're concerned they're disk partitions). This means that your swap space would be encrypted along with the rest of your system but an attacker gaining access to the encrypted logical volume would also gain access to your swap partition. On the other hand, how concerned do you really have to be about that?

This is much more difficult to do in Windows, unfortunately. There is a setting that you can turn on in Group Policy (or change this registry key) that will cause Windows to erase the contents of the swap file on a clean shutdown. In my experience, this is impractical due to the length of time required to overwrite this file. During testing, it's taken anywhere from one to three hours dependent upon the size of the swap file, which pretty much rules out laptop computers, and it's not much better on servers when it comes time to install patches (and the number of reboots involved could make using this measure prohibitive).

A little research shows that Jetico has incorporated Windows page file encryption into their BestCrypt for Windows suite. Reading their documentation shows that they've implemented a device driver which sits like a shim between the file access system calls and the disk device drivers. Read and write calls are intercepted and if they have anything to do with accessing the page file they transparently encrypt or decrypt (whichever is appropriate) the data en route. I haven't tried it personally but I plan on giving it a spin in one of my test machines; I'll post my results at a later date.

Reading up on Bitlocker from Microsoft wasn't terribly helpful: while you can encrypt your drive with it, it treats the Windows page file like any other file, so as long as the system is running an attacker with access could still dig around inside the file for interesting things. The Technet docs for EFS specifically state that EFS isn't designed to protect the page file, so this really isn't the appropriate tool for the job. On the whole, I'd suggest going with a third-party solution that you trust.

A third possibility, regardless of your OS is to max out the RAM installed in your system and don't use swap at all. Modern 32-bit systems tend to top out at two to four gigabytes of RAM; 64-bit systems at four gigs or higher. RAM is pretty cheap these days so it's not that much of a stretch and unless you're doing a lot of hardcore work with Photoshop or video editing you might not notice. If you're interested in experimenting with turning off paging under Windows XP, right-click on the My Computer icon (or Start -> Control Panel -> System) to open the system preferences, Advanced tab, Settings button under Performance, Advanced tab, Change button under Virtual Memory, and click the "No paging file" radio button. Click the Set button, click the Ok button, and reboot your system. The process is the same for Windows Vista. You can do this in BSD or Linux by editing the /etc/fstab file and commenting out the lines fo your swap devices, shutting down, adding more RAM to your system (if you so choose), and then starting back up. At least, this was how I did it (by accident) a couple of years ago when upgrading Leandra.

13 April 2009: Thanks to Kevin for pointing out that not everyone has device mapper support turned on in their boxen.

This work by The Doctor [412/724/301/703] is licensed under a Creative Commons Attribution / Noncommercial / Share Alike 3.0 License.