Subject: Re: zero'd swap & encrypted swap
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 06/04/2001 20:06:52
[ On Monday, June 4, 2001 at 18:48:29 (-0400), Lord Isildur wrote: ]
> Subject: Re: zero'd swap & encrypted swap
> actually, that time is spent on other processes if there are any. the
> time is only really wasted if theres only one process running. because
> this time is _not_ going to waste, to consume it is _not_ free.
Well, if you're lucky it is. However if you're machine is very nearly
thrashing then no other process can run until the pages it needs are
swapped in. :-)
But you're right about non-RAM-starved configs -- the CPU time during
swap I/Os should go to any other process that's runnable, and I wouldn't
want to give that up on anything less than about a Pentium-200 or so! ;-)
> having nonvolatile storage encrypted all the time
> protects you from physiucal compromise at any time , including the
> drastic 'bad guys rush in unexcpectedly and forcefully take the machine'
> scenario. In this case, the encryption shoudl be to block devices in general
> and not swap in specific, and activated or disable don a device by device
> basis, and the keys not be stored anywhere in the system except in
> nonpaged space in the kernel while running.
Absolutely! However even with such a scheme on a physically insecure
machine I'd still have to wonder about the risks of using it to process
or store really sensitive information.
> feed the keys in from outside
> the box at boot time, either by hand, over a serial line, etc, if you really
> want to be secure about it.
I'd say that's a "must" too, but I'm still not sure it gets you very far.
> generally speaking, anything less than complete
> will not be very secure against this attack, and pretty much any lesser
> attack will either not involve this kind of risk, or else presupposes a
> different kind of risk which makes this kind of protection moot.
I think the remaining problem here is that even if you make sure all of
your persistent storage is encrypted there's still the issue of key
longevity. Presumably the attacker will know which algorithm you're
using and so a compromise of the machine gives the attacker enormous
volumes of highly predictable information to assist in a key search
attempt. Not that I know very much about cryptoanalysis (except what I
read about in places like this and in books by the likes of Bruce
Schneier! :-) I'd bet that even with a 128-bit triple-DES key the data
on an encrypted disk would only be safe for a matter of a very few days
at most (at least for a determined and resourceful attacker).
I don't know how you could protect your laptop in this case. Maybe add
cryptography to the disk layout algorithms and make the sector size
small, or even variable and controlled by some crypto too. But that's
really just one more level of protection and if you can crack that then
you can crack the inner key too. It's all just a game and by always
encrypting absolutely everything you make it ever so much more fun and
interesting and easy for the attacker.
I think it boils down to the best approach for protecting data on a
physically insecure machine (eg. a laptop or desktop) to only ever
encrypt the most important data and hope that analysis of external
factors won't be of too much help in cracking the key used to protect
it. As for the system paging space, well you either have to make sure
the programs you use to manipulate that secret data can never be paged
out, or you have to resort to writing really random bits to the swap
device(s) on shutdown (which hopefully will be long enough since boot to
allow the system to have collected sufficient entropy to make those bits
Sometimes the best place to hide stuff is in plain view. ;-) I think
the real trick to keeping secrets is mis-direction (even when you do
have half-decent physical security).
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>