On Thu, 2013-09-26 at 02:27 +0200, Pavel Machek wrote: > On Wed 2013-09-25 15:16:54, James Bottomley wrote: > > On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote: > > > On Wed, 25 Sep 2013, David Howells wrote: > > > > > > > I have pushed some keyrings patches that will likely affect this to: > > > > > > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel > > > > > > > > I intend to ask James to pull these into his next branch. If he's happy to do > > > > so, I can look at pulling at least your asymmetric keys patch on top of them. > > > > > > This suggests a point that I raised at the Linux Plumbers conference: > > > > > > Why are asymmetric keys used for verifying the hibernation image? It > > > seems that a symmetric key would work just as well. And it would be a > > > lot quicker to generate, because it wouldn't need any high-precision > > > integer computations. > > > > The reason is the desire to validate that the previous kernel created > > something which it passed on to the current kernel (in this case, the > > hibernation image) untampered with. To do that, something must be > > passed to the prior kernel that can be validated but *not* recreated by > > the current kernel. > > 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 > Current kernel is not considered malicious (if it were, you have worse > problems). > > Pavel > > PS: And yes, it would be nice to have > Documentation/power/swsusp-uefi.txt (or something) explaining the > design. > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
