LWN: Comments on "Keeping Secrets"

Encrypted Swap works for me

watersb — Fri, 21 Mar 2003 02:23:33 +0000

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

Loopback encryption

Odinson — Sun, 16 Feb 2003 09:45:44 +0000

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.

Nitpick typo/thinko: ppdd is not over loop

AnswerGuy — Fri, 14 Feb 2003 14:32:48 +0000

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

Keeping Secrets

iabervon — Thu, 13 Feb 2003 19:27:13 +0000

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

nicku — Thu, 13 Feb 2003 19:26:18 +0000

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

Keeping Secrets

rwmj — Thu, 13 Feb 2003 16:41:46 +0000

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.

Unattended reboots.

brugolsky — Thu, 13 Feb 2003 16:22:29 +0000

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.

Nitpick

corbet — Thu, 13 Feb 2003 03:08:21 +0000

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

Nitpick

spiv — Thu, 13 Feb 2003 02:23:28 +0000

"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 :)