Re: [PATCH encrypted swsusp 1/3] core functionality

[Matt Mackall <mpm@selenic.com>]

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.
 
> So we would need to zero out the suspend image in swap to prevent the
> retrieval of this data from the running machine (imagine a
> remote-root-hole).
>
> Zeroing out the suspend image means "write lots of megabytes to the
> disk" which takes a lot of time.

Zero only the mlocked regions. This should take essentially no time at
all. Swsusp knows which these are because they have to be mlocked
after resume as well. If it's not mlocked, it's liable to be swapped
out anyway.

Again:

Use dm-crypt swap with password prompt to handle "stolen while
suspended"

Zero out mlocked regions on resume for "stolen while running".

Reinitialize swap or use a different swap session keys for "booting
without resume".

There are more refinements here, like generating session keys per boot
for swap. We want to do this anyway. We can encrypt the session key
with the user password for suspend purposes. Booting without resume
loses the old (encrypted) session key.

But this is all solvable without resorting to yet another encrypted
block device scheme. Such a scheme shouldn't even be considered until
all the other options are thoroughly explored. Any scheme that's
encrypting the suspend image and then storing the key in the clear is
either obviously broken or obviously doesn't actually need encryption.

-- 
Mathematics is the supreme nostalgia of our time.