Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Sunday, September 15, 2013 08:56:46 AM Lee, Chun-Yi wrote: Hi experts, This patchset is the implementation for signature verification of hibernate snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader generate key-pair in UEFI secure boot environment, then pass it to kernel for sign/verify S4 image. Due to there have potential threat from the S4 image hacked, it may causes kernel lost the trust in UEFI secure boot. Hacker attack the S4 snapshot image in swap partition through whatever exploit from another trusted OS, and the exploit may don't need physical access machine. So, this patchset give the ability to kernel for parsing RSA private key from EFI bootloader, then using the private key to generate the signature of S4 snapshot image. Kernel put the signature to snapshot header, and verify the signature when kernel try to recover snapshot image to memory. I wonder what the status of this work is? Is it considered ready for inclusion or are you still going to work on it and resubmit? Rafael -- 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:
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
--
Jiri Kosina
SUSE Labs
--
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 於 10:19 +0800，joeyli 提到： 於 三，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 For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Thanks 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
Hi! For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote: For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Well, yes, one could skip the CRC when the signing is enabled to gain a little speedup. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. First, there is no encryption going on. Only doing a HMAC (digest (hash) using a key) of the image. Second, since NVRAM is accessible through efivarsfs, storing the hash in NVRAM wouldn't prevent an attacker from modifying the hash to match a modified image. There is a reason why the key for the HMAC is stored in the NVRAM in a BootServices variable that isn't accessible from the OS and is write-protected on hardware level from the OS. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... The HMAC approach isn't much more complicated, and it gives you all these benefits even with secure boot disabled. -- Vojtech Pavlik Director SUSE Labs -- 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, Sep 26, 2013 at 02:21:23PM +0200, Michal Marek wrote: Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. I think that part of the exercise is to minimize the number of writes to the NVRAM. The hash changes with every hibernation, obviously. The key should, too. -- Vojtech Pavlik Director SUSE Labs -- 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 於 14:06 +0200，Pavel Machek 提到： Hi! For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. In current kernel design, The crc32 is only for the LZO in-kernel hibernate, doesn't apply to non-compress hibernate and userspace hibernate. Put signature to snapshot header can support any kind of caller that's trigger hibernate. Any userspace hibernate tool will take the snapshot image from kernel, so, we need put the signature(or hash result) to snapshot header before userspace write it to anywhere. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. That speed of hash is calculated from non-compress snapshot image, does not overlap with crc32. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... Pavel The HMAC approach will not encrypt, just put the key of HMAC to boottime variable. If user doesn't enable UEFI secure boot, that's fine, the key of HMAC still cannot access in OS runtime. If user enable UEFI secure boot, then that's better! Because all EFI file will signed by the manufacturers or OSVs to make sure the code is secure, will not pass the key to runtime. 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-26 於 14:22 +0200，Vojtech Pavlik 提到： On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote: For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Well, yes, one could skip the CRC when the signing is enabled to gain a little speedup. In current kernel, CRC is for check the integrity of LZO compressed image, the purpose is different to check the integrity of snapshot image. So, CRC will not in non-compress hibernate or userspace hibernate code path On the other hand, attacker can easily change the CRC code in the header of LZO hibernate image. 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 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
--
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, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
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
I think this could be easily made optional, leaving the user with choice
of faster or safer boot.
Ideally, the key should be regenerated on each true reboot and kept the
same if it is just a resume. Unfortunately, I don't see a way to
distinguish those before we call ExitBootServices().
The reasoning behind that is that in the case of a kernel compromise, a
suspended-and-resumed kernel will still be compromised, so there is no
value in passing it a new key. A freshly booted kernel, though, should
get a new key, exactly because the attacker could have obtained a key
from the previous, compromised one.
This speeds up the ususal suspend-and-resume cycle, but provides full
security once the user performs a full reboot.
The question that remains is how to tell in advance.
2. No external agency other than the next kernel can do the
validation since the validating key has to be secret
This is true, but as you said, the relevance of this seems to be rather
questionable.
Indeed, it's hard to imagine a scenario that is also valid within the
secure boot threat model.
--
Vojtech Pavlik
Director SUSE Labs
--
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
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: [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
[RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
Hi experts, This patchset is the implementation for signature verification of hibernate snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader generate key-pair in UEFI secure boot environment, then pass it to kernel for sign/verify S4 image. Due to there have potential threat from the S4 image hacked, it may causes kernel lost the trust in UEFI secure boot. Hacker attack the S4 snapshot image in swap partition through whatever exploit from another trusted OS, and the exploit may don't need physical access machine. So, this patchset give the ability to kernel for parsing RSA private key from EFI bootloader, then using the private key to generate the signature of S4 snapshot image. Kernel put the signature to snapshot header, and verify the signature when kernel try to recover snapshot image to memory. How To Enable == Set CONFIG_SNAPSHOT_VERIFICATION kernel config to enable. And you can also choice which hash algorithm should snapshot be signed with. Then rebuild kernel. This function depends on EFI_STUB. Please note this function need UEFI bootloader's support to generate key-pair in UEFI secure boot environment, e.g. shim. Current shim implementation by Gary Lin: Git: https://github.com/lcp/shim/tree/s4-key-upstream RPM: https://build.opensuse.org/package/show/home:gary_lin:UEFI/shim Please use the shim from above URL if you want to try. Please remember add the hash of shim to db in UEFI BIOS because it didn't sign by Microsoft or any OSV key. The default behavior is taint kernel when signature check fail. If you want direct fail whole hibernate snapshot restore procedure when signature check does not pass, please use snapshot_sig_enforce kernel parameter or CONFIG_EFI_SECURE_BOOT_SNAPSHOT_SIG_ENFORCE config. If you want binding UEF secure boot with sig_enforce flag, then you can use CONFIG_EFI_SECURE_BOOT_SNAPSHOT_SIG_ENFORCE config. The sig_enforce flag will auto enabled when UEFI secure boot enabled. Behavior = The RSA key-pair are generated by EFI bootloader(e.g. shim) in UEFI secure boot environment, then put private key to S4SignKey, public key to S4WakeKey EFI variable. Kernel's behavior as following: + First, EFI stub kernel will check the following 2 EFI variable: S4SignKey-fe141863-c070-478e-b8a3-878a5dc9ef21[BootService] S4WakeKey-fe141863-c070-478e-b8a3-878a5dc9ef21[Runtime][Volatile] S4SignKey and S4WakeKey is a RSA key-pair: - S4SignKey is a private key that's used to generate signature of S4 snapshot. The blob format of S4SignKey is PKCS#8 _uncompressed_ format, it should packaged a RSA private key that's followed PKCS#1. - S4WakeKey is a public key that's used to verify signature of S4 snapshot. The blob format of S4WakeKey is X.509 format, it should packaged a RSA public key that's followed PKCS#1. + EFI stub kernel will load the S4SignKey blob to RAM before ExitBootServices, then copy to a memory page that's maintained by hibernate_key.c. This private key will be used to sign snapshot when hibernate launched. + When sig_enforce flag set to TRUE, means force check verification pass: - If kernel didn't find S4 key-pair, then kernel will block hibernate functions including kernel space and userspace hibernate. - If snapshot signature check fail when hibernate resume, the snapshot restore procedure will fail and running normal boot process. + When sig_enforce flag set to FALSE, means not force the verification pass: - If kernel didn't find S4 key-pair, then the hibernate function still available. But kernel will be tainted after hibernate resume. - If snapshot signature check fail when hibernate resume, the snapshot restore procedure will allow continue. But kernel will be tainted. On EFI bootloader side, the behavior as following: + EFI bootloader must generate RSA key-pair when: - First time boot, bootloader generate key-pair when didn't find it. - Bootloader need re-generate after found GenS4Key efi variable from OS: GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21 [Runtime][Non-Volatile] The size of GenS4Key is 1 byte, OS(kernel or userland tool) will set it to 1 for notify efi bootloader regenerate key-pair. - If re-generate key-pair, bootloader need store the new public key to EFI bootservices variable by itself, e.g. store to NextWakeKey variable When system resumed from hibernate, bootloader need copy public key from NextWakeKey to S4WakeKey, then kernel will use it to verify snapshot image. Implementation == Whole implementation including 3 parts: shim, asymmetric keys and hibernate: + shim: Current solution implemented by Gary Lin: https://github.com/lcp/shim/tree/s4-key-upstream Please use shim from the above URL if you want to try. Please remember add this shim to db because it didn't sign by Microsoft or any OSV
