On Wed, 25 Sep 2013, James Bottomley wrote:
> > 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.
As Pavel pointed out, this seems like a futile approach. If the
current kernel is going to do the validating, then of course it can
create something that it will validate.
Or to put it another way, how come you don't trust the current kernel
not to modify the image but you do trust it to validate the image?
> The scheme for doing this is a public/private key pair generated for
> each boot incarnation N as a pair P_N (public key) and K_N (private
> key). Then the Nth boot incarnation gets P_{N-1} and K_N (the boot
Where does it get them from? Some place in the firmware, presumably.
> environment holds P_N in inaccessible BS variables for passing into the
> next kernel) so the Nth kernel can validate information from the N-1th
> kernel using P_{N-1} and create information for passing on in a
> validated fashion to the next kernel using K_N.
So kernel N gets P_{N-1} and an image that has been signed by K_{N-1}.
What's to prevent kernel N from creating a bogus pair of keys (K',P')
and a bogus image, signing that image with K', and then pretending it
got P' from the firmware instead of P_{N-1}?
However... Let's assume that you _do_ trust kernel N. Then consider
this alternative approach:
A symmetric key S_N is created for boot incarnation N. Kernel N
receives S_{N-1} from the firmware and uses it to verify the signature
attached to the hibernation image. When kernel N wants to create the
next hibernation image, it signs the image with S_N (also obtained
from the firmware).
> This scheme doesn't work with symmetric keys unless you have a
> modification I haven't seen?
Obviously these two schemes are different. Do these differences have
any security implications?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
