Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
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. It'd be helpful if you could see if you need to make any updates. David -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
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. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
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.
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
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.
This scheme doesn't work with symmetric keys unless you have a
modification I haven't seen?
James
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
於 三，2013-09-25 於 22:04 +0100，David Howells 提到： 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 Thanks for your point out, I will respin my asymmetric keys patch base on this tree. 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. It'd be helpful if you could see if you need to make any updates. David In LPC, Alan and Vojtech raised another thinking is using symmetric key to protect the hash of snapshot. It's simpler then using RSA private key to sign it. Even finally we use the symmetric key solution, I will still respin and resent the patch for add the leading zero byte: [PATCH V4 07/15] asymmetric keys: explicitly add the leading zero byte to encoded message I think keys-devel tree need it. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到： On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. This series is big enough already... and who is going to test it? The hash config not just for testing, it's relate to the performance and secure between different hash algorithms. There have person raised in LPC say he don't like SHA algorithm. There's no need to make hash configurable. Just select one that works. Pavel SHA1 has good performance, and SHA512 has better security, which one you like it? Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到： 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. Alan Stern Per my understood, it's like add salt to snapshot when generate signature, then remove the salt when store the snapshot to swap. (or pass snapshot to userland). Let me explain the symmetric key solution base on my understand: + EFI stub kernel generate a hash value from a random seed, then store it to EFi boot varaible. It should protected by UEFI secure boot environment. + When hibernate launched: - Kernel create the snapshot image of memory. It's included the random hash value(salt) that generated in EFI stub stage. - Then kernel hash the snapshot image, put the hash to snapshot header, just like current asymmetric keys solution. - Kernel erase the salt in snapshot image before it go to swap or pass to userspace tool. + When hibernate resume: - Kernel or userspace tool load the snapshot(without salt) from swap to temporary memory space. - Kernel fill the salt back to snapshot image in memory, hash it. - Kernel compare the hash with the hash that put in snapshot header. - Verification done! The follow-up action as current solution. Please current me if I missed anything. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
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-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
於 四，2013-09-26 於 02:27 +0200，Pavel Machek 提到： 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? Current kernel is not considered malicious (if it were, you have worse problems). Current boot kernel should not malicious especially when UEFI secure boot enabled. Pavel PS: And yes, it would be nice to have Documentation/power/swsusp-uefi.txt (or something) explaining the design. Thanks for your suggestion, I will write the swsusp-uefi.txt to explaining the design in next version. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
