Keeping Secrets [LWN.net]

[This article was contributed by Tom Owen]

Information contained on hard drives is often of the type that should not fall into the wrong hands. After all, being on the wrong end of a Canadian class action lawsuit for releasing personal information counts as one of the rougher server administrator nightmares. It's not clear whether the Canadian disk drive was stolen or retired, but it doesn't look like an isolated case. Responsible equipment dealers and recyclers use special tools to sanitize disks that come into their hands. But it doesn't always happen, and there's always the risk of simple theft.

Being sued is one possible outcome. In Europe, criminal charges are possible, though unlikely. Even if all you have to worry about is an embarrassingly public gap between your privacy policy and your real operations, it may be time to look more closely at what might emerge if your data partitions ended up on eBay.

The problem is that the ordinary techniques of host security are useless against an explorer who can install your disks in a lab machine. 0600 modes won't be noticed by an attacker who is root already. Wipes and sanitizers won't have been used if the equipment was stolen. The only option is to encrypt the information you don't want to leak. If you do it right you can publish the contents of your disks without a qualm. Encryption is doubly important for Linux administrators because the range of software is so great that failure to encrypt is that much less excusable. The only plausible objections relate to performance and convenience issues.

In the past, the US imposed export restrictions on cryptographic software. Those rules obliged Linux kernels from kernel.org to exclude cryptographic software. Something like that never stops hackers, and the kernel code for encrypted disks and networks was hosted and has continued outside the US. The 2.5 kernel has crypto built in, but users of the current stable kernels must get their encryption code from another source. Incorporating crypto code into a standard kernel is well documented but it's simpler to use a distribution like SuSE which includes crypto out of the box.

Beyond the offerings from your distribution the broad choice is rather daunting. The standard approach uses encryption in the loopback device to create a secure partition "hosted" in a big contiguous file. A filesystem can be created on that device and mounted as the data directory. The host file is unintelligible without the passphrase.

Encrypted loopback can't handle swapfiles, and so there's a risk of leaving decrypted application information on the disk. If you can't configure enough memory, ppdd, which layers encryption on top of the plain loopback device does support swap files.

Other approaches like CFS don't use loopback, instead running a userspace daemon to encrypt on a file by file basis. These suffer under I/O load and wouldn't be a good choice to host a database.

All of this is relatively well documented. But the manuals seem to skate around the hard problems:

Passwords are hard to manage. Changing the password involves backup and restore, too much trouble to do often, so it has to be closely guarded. Even worse, the passphrase can't be held anywhere on the machine, so an unattended start isn't possible.
It's surprisingly tricky to backup encrypted data. The loopback host file can be sensitive to absolute location on the disk, and getting data securely off the machine requires more encryption.

It's unfortunate that the commonest server setup, remote hosting, is one of the toughest operational security challenges. But if remote servers are the only possible answer, then encryption security is still possible. Linux is solid enough that unattended restart isn't strictly necessary. Instead, the machine can boot far enough to page the admin to ssh in and mount the loopback devices. And a backup can be prepared on the encrypted volume and once it's re-encrypted with the admin's public key any transfer method will do.

This is all convoluted to say the least. It's not standard, and it goes beyond what's commonly done. It's easy to feel that keeping the site going and current is challenge enough. But if you take privacy seriously there are no other choices. Once your hosts are as secure as you can make them against attacks from the network, it's time to move up a level. If you have other people's personal data, you should probably encrypt it.

to post comments

Nitpick

Posted Feb 13, 2003 2:23 UTC (Thu) by spiv (guest, #9031) [Link] (1 responses)

"0x600 modes won't be noticed by an attacker who is root already"

I think you meant "0600" (i.e. the usual octal notation for unix permissions), not 0x600, which is hexadecimal and thus rather different :)

Nitpick

Posted Feb 13, 2003 3:08 UTC (Thu) by corbet (editor, #1) [Link]

Yeah, that's what he meant...though it is true that 0x600 modes would also be fairly unhelpful... I've fixed it.

Unattended reboots.

Posted Feb 13, 2003 16:22 UTC (Thu) by brugolsky (guest, #28) [Link]

1. The server could contact a key oracle. This would be most useful in concert with an event counter on the server (e.g., IPMI).

2. Kexec could be used in panic/watchdog/etc. handling to pass a key in RAM across reboots.

3. Depending on the trust relationship involved in physical security of the server, an inexpensive RSA-capable dongle hanging off the USB port might be useful.

Of course, there are attacks against all of these -- which to use depends on the threat model.

Keeping Secrets

Posted Feb 13, 2003 16:41 UTC (Thu) by rwmj (subscriber, #5474) [Link] (1 responses)

Ironically, I suppose, TCPA actually solves the key storage problems nicely,
allowing for an unattended boot, no passphrases, and full security for
the disks if they are separated from the chassis containing the "Fritz" chip.

Rich.

Keeping Secrets

Posted Feb 13, 2003 19:27 UTC (Thu) by iabervon (subscriber, #722) [Link]

That is what TPCA is intended for: you want the machine you've built to be able to read the hard drive only if it is booting from the hard drive and not compromised in any way that wouldn't come to the attention of the people monitoring the server room.

Keeping Secrets

Posted Feb 13, 2003 19:26 UTC (Thu) by nicku (subscriber, #777) [Link]

Dear folks,
a more up-to-date howto than the one linked to in this interesting article is at http://encryptionhowto.sourceforge.net/

Nitpick typo/thinko: ppdd is not over loop

Posted Feb 14, 2003 14:32 UTC (Fri) by AnswerGuy (guest, #1256) [Link]

ppdd doesn't "layer encryption over the loop" device --- rather it layers
the encryption between the low-level (hardware) block drivers and the logical (fileystem/swap) block level.

It's a nitpick and I suspect that Tom actually meant that. The distinction
is that the ppdd layer is inserted between the low-level block device and
the filesystem or swap layers as with the md (software RAID) and LVM
code. (I don't know whether ppdd could be further layered over
md or LVM --- it probably would not be difficult to fix the code to allow
this, if it doesn't work already).

As with most encryption the real devil is in the key management.

One could imagine (as one of the other comments suggested) that servers
booting and trying to automount ppdd devices might have to run
some custom bit of software such that they would have to connect to keyserver on the local LAN segment (the keyserver being firewalled off such
that it would be unreachable from outside of the server room, for example)
and perform a host authentication in order to get the ppdd key/passphrase).
This would simply enforce the policy that the protected system (or it's
hard drive) had to be booted in the server room (subject to the limitations
of your firewalling). That might not be much extra assurance (given that the primary risk we're trying to mitigate is the theft of the computer or
it's hard drive which already required physical access by the culprit).

I suspect that most companies will continue not to use ppdd even if it
because included in the mainstream kernel, and even if mainstream or
"enterprise" distributions support it, and a good key management client/server package) out of the box. The reasoning will probably
hinge on the perceived cost (risk) vs. benefit analysis (the extra CPU and memory overhead being the costs; the complexity and additional POF (points of failure) adding to the risk). In fact, I would have a fairly hard time
justifying the use of ppdd or similar systems the case of any of my
clients (except on laptops). It's something that Lawrence Livermore, Sandia and similar research facilities (with notorious well publicised concerns of lost and stolen hard drive incidents in some cases) might need
but unlikely at "dot com" and even in banks or more mundane government agencies.

However, this is a VERY useful article! I've known about encrypted loop, ppdd, and CFS (and the TCFS derivative) for several years; but I've yet to
see any company making regular use of any of these tools. Perhaps with
more people becoming aware of the tools the business world will surprise me
and actually use them! Besides, just protected the /home volumes on
laptop drives would be a HUGE advance in the general security of
confidential data.

JimD

Loopback encryption

Posted Feb 16, 2003 9:45 UTC (Sun) by Odinson (guest, #1402) [Link]

I just did a talk about this last week for my LUG. Weird.

For protection against some scenerios (hostile machine shutdown by pulling the plug) Disk encryption is pointless without swap encryption because some system info, greatly easing sinister decryption, can be pulled from the swap space.

There has been a solution since Sept 2001 though. Considering the month I'm not suprised it got missed.

http://mail.nl.linux.org/linux-crypto/2001-09/msg00006.html

If you are willing to use the AES algorithm Loop-AES should do swap just fine.

Encrypted Swap works for me

Posted Mar 21, 2003 2:23 UTC (Fri) by watersb (guest, #10230) [Link]

> Encrypted loopback can't handle swapfiles.

Hmm... I've been using encrypted swap on my laptop since last August, using the kerneli patch which is based on the crypto-AES, I think.

I have never been restricted to just AES. There are a number of encryption ciphers available. This is pacakged as a standard kernel option for the Gentoo Linux distribution, which is the only one I know about. Certainly you could run such a kernel on any Linux, I think.

Encrypting the swap is far easier than encrypting root; you don't have to worry about backups.

I have been using the find | cpio backup method between encrtyped partitions; I am not familiar with the complexities that would be introduced by encrypting tape backups.

This added wrinkle of swap and backups reinforces the point that ENCRYPTION is a TECHNOLOGY ---- but that SECURITY is a PROCESS... And reasonable-and-prudent-behaviour-in-the-eyes-of-the-court is another thing alltogether. Who knows if any of this will do what it is supposed to -- which is to protect you and your customers. From bad guys. Nothing can protect you from litigation...