Swap should be encrypted by default

There are a variety of tools that offer encrypted filesystems for the various OSs. None of them are as easy to use as we would like, and none have reached the goal of “Zero User Interface” (ZUI) that is the only thing which causes successful deployment of encryption (ie. Skype, SSH and SSL.)

Many of these tools have a risk of failure if you don’t also encrypt your swap/paging space, because your swap file will contain fragments of memory, including encrypted files and even in some cases decryption keys. There is a lot of other confidential data which can end up in swap — web banking passwords and just about anything else.

It’s not too hard to encrypt your swap on linux, and the ecryptfs tools package includes a tool to set up encrypted swap (which is not done with ecryptfs, but rather with dm-crypt, the block-device encryptor, but it sets it up for you.)

However, I would propose that swap be encrypted by default, even if the user does nothing. When you boot, the system would generate a random key for that session, and use it to encrypt all writes and reads to the swap space. That key of course would never be swapped out, and furthermore, the kernel could even try to move it around in memory to avoid the attacks the EFF recently demonstrated where the RAM of a computer that’s been turned off for a short time is still frequently readable. (In the future, computers will probably come with special small blocks of RAM in which to store keys which are guaranteed — as much as that’s possible — to be wiped in a power failure, and also hard to access.)

The automatic encryption of swap does bring up a couple of issues. First of all, it’s not secure with hibernation, where your computer is suspended to disk. Indeed, to make hibernation work, you would have to save the key at the start of the hibernation file. Hibernation would thus eliminate all security on the data — but this is no worse than the situation today, where all swap is insecure. And many people never hibernate.

For full operation, it does need some APIs and UI. If a more involved disk encryption system is installed on the machine, it would need to talk to the swap encrypter. For example, it could tell the swap system to use keys managed by the master disk encrypter, so when you boot/unsuspend, you would enter a pass phrase that would enable access to both swap and other disks. This would make hibernation secure. Many systems already demand a password to restore from hibernate (though usually after it is restored) so the UI could be combined.

Another API would allow a command to disable the swap encryption. It would, after all, have a small CPU cost, and those who feel they have no security risks in swap might want to do so. But give them the UI to disable it, and leave it enabled if they don’t explicitly turn it off.

While the system is alive, root programs that can examine memory and swap would still be able to do so, if you want to have such programs. It would be people who stole your laptop after you had shut it down or emergency reset it who would get nothing from the swap space. (As well as if you hibernated it after enabling a restore passphrase.)

Of course, a full disk encryption system with minimal UI is also something that would be good to make easy to install or even installed by default. However, due to the need for the key, it’s harder to do with ZUI. One way to do it is to have a small flashcard slot on the laptop, and store keys there, as well as in a good escrow location. In this case the UI is simply to remember to pull out the card when worried about laptop theft or confiscation, or even deliberately wiping the card (knowing you can get the keys again from your web service with a secret password.)

Even more secure, but harder to do by default, would be a system where your bluetooth phone holds the keys, demanding you be nearby for boot — also entering a passphrase for those who want full security against those who would steal the phone and the computer.) There are a few tricks here to give near-ZUI with security though:

  • If the phone or computer is connected to the network, it might fetch what it needs to provide keys from a server. You can then remotely disable that server, blocking access after your device is stolen. And tell the phone and computer to report what it know about its location of course.
  • You could also program the server to take special steps when you know you are going to be in a high-risk situation, such as at a border station. In fact, using the phone’s GPS or other location sensing, it could know you are at a border station, and go into paranoid mode until a trusted friend (not you) commands it not to.
  • If the phone or computer are not on the network, it can still provide keys if you enter a passphrase on the computer, or provide the key on a card.
  • Of course, if the phone is not available, you may want to be able to still booth with a passphrase, though this runs the risk of being compelled to do so.

This plan sounds ok, but I'd

This plan sounds ok, but I'd go for the cheaper-to-implement 'shutdown and wipe the swap disk' option. People would pick that slower shutdown mode if they think their laptops will be at risk.

As to the CPU cost of encrypted swap, it sounds like a very rare use case where all CPUs are busy AND you're swapping and you could notice an additional slowdown. Surely in normal cases, the disk io totally dominates the runtime. Maybe e-swap uses a noticeable amount of additional battery life, though.

CPU cost of swap

I agree that it is rare that this would be an issue, since of course when swapping you are rarely CPU bound as you say.

However, wiping the swap on shutdown is not a suitable answer.

  • You might well have gigs of swap. I have 8b of swap and have seen gigs used. This can take quite a long time to wipe
  • Even wiping a disk does not mean the data can’t be recovered, though that requires a more advanced threat
  • This doesn’t help you if you want to suddenly decide to power off your computer because somebody wants to take it.

Of course, sudden power-off of laptops is not usually easy (it means hold down power button for about 5 seconds or yank the battery) but it’s often very easy for desktops.

As noted in the future I expect computers to come with a function to wipe the special key-holding memory during emergency shutdowns. A computer actually can do vast numbers of instructions between the time it detects power failure and the power is actually truly gone, due to the capacitors. Of course if doing a shutdown via a button you have even more time.

My main point is, you can do encrypted swap with ZUI, so it should be done. ZUI does not mean there is no UI for complex stuff, it just means that something useful occurs with no UI.

Fast wiping the swap is easy

Just corrupting/overwriting the first few MB plus the key will make it very hard to decrypt. You're dealing with random-ish snippets written to disk in random-ish order, only now you don't have the index or the decryption key. So quite tricky to decrypt and very quick to perform, which is about all you can ask for from an "instant wipe". It's only a 20% solution but I think it'll cover 80% of the situations.

I'm not into ZUI, but I prefer one or two solid systems over dozens. Two long, ugly passphrases should be enough. I stack a password manager on top of disk encryption for the sensitive stuff that I don't want to have always available, and hopefully one day TrueCrypt will support recovery on my laptop (which has either a hard disk or a DVD drive, but never both coz they live in the same bay - the original hard disk died some time after they stopped making small enough hard disks for the controller to cope with, but the "second disk" bay takes SATA disks of arbitrary size and I can boot off it). TrueCrypt recovery CD doesn't work if hacked onto a bootable USB key. For me anyway. Which is another point - not needing ZUI doesn't mean "will accept any amount of hassle"...

Wipe

I’m not sure what you mean here. If the swap is encrypted, there is no need to wipe it. If the swap is not encrypted, there is no key (unless you mean other keys to other disk encryption systems) that would be in the swap. If the swap is not encrypted however, any block could contain a useful page of memory, including pages with passwords not just to encrypted disks and accounts but also web sites, browser password vaults etc. You thus must wipe it all.

The ZUI here is that you have no need to know or deal with the key encrypting your swap. It is OK to generate it randomly each time and just use it. The user does not even have to know it exists. The ZUI means there is no reason not to do it by default, so everybody is protected.

If you are going to the trouble of installing another disk encryption scheme — which very few people do — you can have it manage your swap and hibernation encryption so you don’t have extra passwords to manage. Or you can leave the swap encryption with its own key — but you must make sure that key is stored, but not in the clear, during hibernation. (Most hibernation systems make use of the swap or leave swapped-out-pages on disk where they are.)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

His name is Brad Templeton. You figure it out.
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
Personal home pages only. Posts with biz home pages get deleted and search engines ignore all links
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options