From: Matt Mackall <mpm@selenic.com>
To: Andy Isaacson <adi@hexapodia.org>
Cc: Stefan Seyfried <seife@suse.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
Pavel Machek <pavel@ucw.cz>, Andreas Steinmetz <ast@domdv.de>,
linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH encrypted swsusp 1/3] core functionality
Date: Thu, 14 Apr 2005 15:48:46 -0700 [thread overview]
Message-ID: <20050414224846.GQ3174@waste.org> (raw)
In-Reply-To: <20050414221153.GE27881@hexapodia.org>
On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote:
> On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> > On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > > Matt Mackall wrote:
> > > > Any sensible solution here is going to require remembering passwords.
> > > > And arguably anywhere the user needs encrypted suspend, they'll want
> > > > encrypted swap as well.
> > >
> > > But after entering the password and resuming, the encrypted swap is
> > > accessible again and my ssh-key may be lying around in it, right?
> >
> > No. Because it's been zeroed in the resume process.
>
> Zeroing the entire swsusp region is a big job, especially if you want to
> do it in a FIPS-conformant manner. Hard to test that you've done it
> right and not missed any bits.
>
> Much much easier to securely erase just the key storage.
>
> And unless I'm missing something, you meant to say "it will have been
> zeroed" (after the patch under discussion is merged), right? The
> current state of the art (as of 2.6.12-rc2) is that mlocked regions are
> written to the swsusp region and may linger there indefinitely after
> resume.
I was referring not to the current implementation but to an ideal
solution. Which is:
- use dm-crypt for swap and suspend
- overwrite mlocked regions on resume
- use per-boot session keys for the swap partition
- password protect the session key on suspend
This doesn't have great FIPS-secure deletion properties if the
attacker can steal the box after resume but while it's still running
(though it's not too bad). As we currently have no solution for
protecting the in-memory ssh-agent, as opposed to the one in the
suspend image, this attack vector is not all that important.
A much more likely vector is stealing the laptop while it's suspended.
And the encrypted swsusp patch has -zero- security here: it writes the
key in the header in the clear. It's rather odd that everyone's hung
up on the "box rooted after resume" attack and completely ignoring the
much more common "stole my laptop" attack.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2005-04-14 22:49 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-10 23:19 [PATCH encrypted swsusp 1/3] core functionality Andreas Steinmetz
2005-04-11 10:25 ` Pavel Machek
2005-04-11 10:36 ` folkert
2005-04-11 11:01 ` Pavel Machek
2005-04-11 11:38 ` folkert
2005-04-11 16:28 ` Andreas Steinmetz
2005-04-11 16:36 ` Pavel Machek
2005-04-11 13:08 ` Andreas Steinmetz
2005-04-11 11:08 ` Pavel Machek
2005-04-11 13:11 ` Andreas Steinmetz
2005-04-11 16:11 ` Andreas Steinmetz
2005-04-11 20:57 ` Rafael J. Wysocki
2005-04-11 21:08 ` Pavel Machek
2005-04-11 21:35 ` Rafael J. Wysocki
2005-04-12 10:07 ` Andreas Steinmetz
2005-04-12 10:52 ` Andreas Steinmetz
2005-04-12 13:17 ` Andreas Steinmetz
2005-04-13 11:59 ` Herbert Xu
2005-04-13 12:59 ` Andreas Steinmetz
2005-04-13 21:27 ` Herbert Xu
2005-04-13 22:29 ` Andreas Steinmetz
2005-04-13 23:10 ` Herbert Xu
2005-04-13 23:24 ` Pavel Machek
2005-04-13 23:39 ` Herbert Xu
2005-04-13 23:46 ` Pavel Machek
2005-04-14 0:35 ` Matt Mackall
2005-04-14 6:51 ` Pavel Machek
2005-04-14 8:08 ` Herbert Xu
2005-04-14 9:04 ` Rafael J. Wysocki
2005-04-14 17:11 ` Matt Mackall
2005-04-14 19:27 ` Stefan Seyfried
2005-04-14 19:53 ` Matt Mackall
2005-04-14 20:18 ` Pavel Machek
2005-04-14 22:27 ` Matt Mackall
2005-04-14 22:11 ` Andy Isaacson
2005-04-14 22:48 ` Matt Mackall [this message]
2005-04-15 9:44 ` Andreas Steinmetz
2005-04-15 9:44 ` Andreas Steinmetz
2005-04-15 17:00 ` Matt Mackall
2005-04-14 20:13 ` Pavel Machek
2005-04-14 9:05 ` Pavel Machek
2005-04-15 9:44 ` Andreas Steinmetz
2005-04-15 9:47 ` Pavel Machek
2005-04-14 1:13 ` Bernd Eckenfels
2005-04-14 8:27 ` Pavel Machek
2005-04-14 8:31 ` encrypted swap (was Re: [PATCH encrypted swsusp 1/3] core functionality) Andy Isaacson
2005-04-14 8:38 ` Herbert Xu
2005-04-14 8:49 ` Arjan van de Ven
2005-04-14 1:11 ` [PATCH encrypted swsusp 1/3] core functionality Bernd Eckenfels
2005-04-13 13:22 ` Pavel Machek
2005-04-13 14:45 ` Andreas Steinmetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050414224846.GQ3174@waste.org \
--to=mpm@selenic.com \
--cc=adi@hexapodia.org \
--cc=ast@domdv.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=seife@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox