From: James Bottomley Subject: Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot Date: Thu, 26 Sep 2013 07:44:14 -0700 Message-ID: <1380206654.18835.56.camel@dabdike.int.hansenpartnership.com> References: <1380147414.18835.36.camel@dabdike.int.hansenpartnership.com> <20130926002730.GA26857@amd.pavel.ucw.cz> <1380162771.18835.47.camel@dabdike.int.hansenpartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Cc: Pavel Machek , Alan Stern , David Howells , "Lee, Chun-Yi" , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org, linux-pm@vger.kernel.org, linux-crypto@vger.kernel.org, opensuse-kernel@opensuse.org, "Rafael J. Wysocki" , Matthew Garrett , Len Brown , Josh Boyer , Vojtech Pavlik , Matt Fleming , Greg KH , Rusty Russell , Herbert Xu , "David S. Miller" , "H. Peter Anvin" , Michal Marek , Gary Lin , Vivek Goyal , "Lee, Chun-Yi" To: Jiri Kosina Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Thu, 2013-09-26 at 08:24 +0200, Jiri Kosina wrote: > On Wed, 25 Sep 2013, James Bottomley wrote: > > > > 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