Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot

On Thu, 2013-09-26 at 08:24 +0200, Jiri Kosina wrote:

On Wed, 25 Sep 2013, James Bottomley wrote:

quoted

quoted

I don't get this. Why is it important that current kernel can't
recreate the signature?

The thread model is an attack on the saved information (i.e. the suspend
image) between it being saved by the old kernel and used by the new one.
The important point isn't that the new kernel doesn't have access to
K_{N-1} it's that no-one does: the key is destroyed as soon as the old
kernel terminates however the verification public part P_{N-1} survives.

James,

could you please describe the exact scenario you think that the symmetric 
keys aproach doesn't protect against, while the assymetric key aproach 
does?

The crucial points, which I believe make the symmetric key aproach work 
(and I feel quite embarassed by the fact that I haven't realized this 
initially when coming up with the assymetric keys aproach) are:

- the kernel that is performing the actual resumption is trusted in the 
  secure boot model, i.e. you trust it to perform proper verification

- potentially malicious userspace (which is what we are protecting against 
  -- malicious root creating fake hibernation image and issuing reboot) 
  doesn't have access to the symmetric key

OK, so the scheme is to keep a symmetric key in BS that is passed into
the kernel each time (effectively a secret key) for signing and
validation?

The only two problems I see are

     1. The key isn't generational (any compromise obtains it).  This
        can be fixed by using a set of keys generated on each boot and
        passing in both K_{N-1} and K_N
     2. No external agency other than the next kernel can do the
        validation since the validating key has to be secret

The importance of 2 is just tripwire like detection ... perhaps it
doesn't really matter in a personal computer situation.  It would matter
in an enterprise where images are stored and re-used but until servers
have UEFI secure boot, that's not going to be an issue.

James