Re: [swsusp] encrypt suspend data for easy wiping

[Matt Mackall <mpm@selenic.com>]

On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > the attached patches are acked by Pavel and signed off by me
> > > 
> > > OK, well I queued this up, without a changelog.  Because you didn't send
> > > one.  Please do so.  As it adds a new feature, quite a bit of info is
> > > relevant.
> > 
> > I don't like this patch. It reinvents a fair amount of dm_crypt and
> > cryptoloop but badly. 
> > 
> > Further, the model of security it's using is silly. In case anyone
> > hasn't noticed, it stores the password on disk in the clear. This is
> > so it can erase it after resume and thereby make recovery of the
> > suspend image hard.
> > 
> > But laptops get stolen while they're suspended, not while they're up
> > and running. And if your box is up and running and an attacker gains
> > access, the contents of your suspend partition are the least of your
> > worries. It makes no sense to expend any effort defending against this
> > case, especially as it's liable to become a barrier to doing this
> > right, namely with real dm_crypt encrypted swap.
> 
> Well, "how long are my keys going to stay in swap after
> swsusp"... that's pretty scary.

Either they're likely in RAM _anyway_ and are thus already trivially
accessible to the attacker (for things like dm_crypt or IPSEC or
ssh-agent), or the application took care to zero them out, or the
application has a security bug.

There are about 4 attack cases, in order of likelihood:

1) An attacker steals your suspended laptop. He has access to all your
suspended data. This patch gets us exactly nothing.

2) An attacker breaks into your machine remotely while you're using
it. He has access to all your RAM, which if you're actually using it,
very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
are saved on suspend. Further, he can trivially capture your
keystrokes and thus capture any keys you use from that point forward.
This patch gets us very close to nothing.

3) An attacker steals your unsuspended laptop. He has access to all
your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
ssh-agent keys. Odds are good that he invokes swsusp by closing the
laptop. This patch gets us very close to nothing.

4) You suspend your laptop between typing your GPG key password and
hitting enter, thus leaving your password in memory when it would
otherwise be cleared. Then you resume your laptop and hit enter, thus
clearing the password from RAM but leaving it on the suspend
partition. Then an attacker steals your machine (without re-suspending
it!) and manages to recover the swsusp image which contains the
password. But with this patch, he's foiled because the password is
encrypted and the key's been erased! He's got all your other data
though, including all the aforementioned long-lived keys.

The right fix for case 1 is dm_crypt with a password prompt. The right
fix for 2 is beyond the scope of this email, but probably begins with
the letters s and e. The fix for 1 goes a long way towards fixing 3 as
well, provided the attacker suspends your machine. And I claim that
anyone who is paranoid enough to actually care about corner cases like
4 should damn well care about case 1 too, and should be more than
willing to type a password on resume, otherwise they're just fooling
themselves.

Together with the fact that this reimplements dm_crypt functionality
with an unreviewed and cryptographically naive replacement, I don't
think this patch makes any sense at all.

-- 
Mathematics is the supreme nostalgia of our time.