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 key.
+ Asymmetric keys:
This patchset implemented uncompressed PKCS#8 and RSA private key parser,
it also implement the signature generation operation of RSASSA-PKCS1-v_5
in PKCS#1 spec. [RFC3447 sec 8.2.2]
Set CONFIG_PKCS8_PRIVATE_KEY_INFO_PARSER=y will give kernel the abilities
to parsing private key in uncompressed PKCS#8 blob and generate signature.
+ Hibernate:
Set CONFIG_SNAPSHOT_VERIFICATION=y will enable the function of snapshot
signature generation and verification. I reserved 512 byes size in snapshot
header for store the signature that's generated from the digest with SHA
algorithms.
For adapt S4 signature check to secure boot, It Base on Matthew Garrett's 2
patches in "[PATCH] Add additional security checks when module loading is
restricted" series: https://lkml.org/lkml/2013/8/19/331
[PATCH 01/10] Add secure_modules() call
[PATCH V3 11/11] Add option to automatically enforce module signatures when in Secure Boot mode
Please help review this RFC patchset! Appreciate for any comments!
V4:
- Cleaned source code, use helper functions to reduce #ifdef chunk.
- Introduced sig_enforce flag, taint kernel when signature check fail.
- Use forward_info structure to maintain the empty of forward information and
new sign key from boot kernel to resume target kernel.
- Use efivar API to access S4WakeKey variable.
- Call set_key_regen_flag() to set key-pair regeneration flag in hibernate.c
and user.c
V3:
- Load S4 sign key before ExitBootServices in efi stub.
- In Makefile, moved hibernate_keys.o before hibernate.o for load S4 sign
key before check hibernate image. It makes sure the new sign key will be
transfer to resume target kernel.
- Set "depends on EFI_STUB" in Kconfig.
V2:
- Moved SNAPSHOT_VERIFICATION kernel config to earlier patch.
- Add dummy functions to simplify the ifdef check.
- Sent to [email protected] for review:
http://lists.opensuse.org/opensuse-kernel/2013-08/msg00025.html
V1:
- Internal review
- github:
https://github.com/joeyli/linux-s4sign/commits/devel-s4sign
Lee, Chun-Yi (15):
asymmetric keys: add interface and skeleton for implement signature
generation
asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa
asymmetric keys: separate the length checking of octet string from
RSA_I2OSP
asymmetric keys: implement OS2IP in rsa
asymmetric keys: implement RSASP1
asymmetric keys: support parsing PKCS #8 private key information
asymmetric keys: explicitly add the leading zero byte to encoded
message
Hibernate: introduced RSA key-pair to verify signature of snapshot
Hibernate: generate and verify signature of snapshot
Hibernate: Avoid S4 sign key data included in snapshot image
Hibernate: taint kernel when signature check fail
Hibernate: show the verification time for monitor performance
Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash
algorithm
Hibernate: notify bootloader regenerate key-pair for snapshot
verification
Hibernate: adapt to UEFI secure boot with signature check
Documentation/kernel-parameters.txt | 7 +
arch/x86/Kconfig | 11 +
arch/x86/boot/compressed/eboot.c | 92 +++++++
arch/x86/include/asm/efi.h | 9 +
arch/x86/include/uapi/asm/bootparam.h | 1 +
arch/x86/kernel/setup.c | 7 +
arch/x86/platform/efi/efi.c | 68 +++++
crypto/asymmetric_keys/Kconfig | 11 +
crypto/asymmetric_keys/Makefile | 16 +
crypto/asymmetric_keys/pkcs8.asn1 | 19 ++
crypto/asymmetric_keys/pkcs8_info_parser.c | 152 ++++++++++
crypto/asymmetric_keys/pkcs8_parser.h | 23 ++
crypto/asymmetric_keys/pkcs8_private_key.c | 148 ++++++++++
crypto/asymmetric_keys/pkcs8_rsakey.asn1 | 29 ++
crypto/asymmetric_keys/private_key.h | 29 ++
crypto/asymmetric_keys/public_key.c | 32 +++
crypto/asymmetric_keys/rsa.c | 296 +++++++++++++++++++-
crypto/asymmetric_keys/signature.c | 28 ++
include/crypto/public_key.h | 28 ++
include/keys/asymmetric-subtype.h | 6 +
include/linux/efi.h | 25 ++
include/linux/kernel.h | 1 +
include/linux/suspend.h | 7 +
kernel/panic.c | 2 +
kernel/power/Kconfig | 77 +++++-
kernel/power/Makefile | 1 +
kernel/power/hibernate.c | 23 ++-
kernel/power/hibernate_keys.c | 410 ++++++++++++++++++++++++++++
kernel/power/main.c | 7 +-
kernel/power/power.h | 62 +++++
kernel/power/snapshot.c | 323 ++++++++++++++++++++++-
kernel/power/swap.c | 4 +
kernel/power/user.c | 14 +-
33 files changed, 1946 insertions(+), 22 deletions(-)
create mode 100644 crypto/asymmetric_keys/pkcs8.asn1
create mode 100644 crypto/asymmetric_keys/pkcs8_info_parser.c
create mode 100644 crypto/asymmetric_keys/pkcs8_parser.h
create mode 100644 crypto/asymmetric_keys/pkcs8_private_key.c
create mode 100644 crypto/asymmetric_keys/pkcs8_rsakey.asn1
create mode 100644 crypto/asymmetric_keys/private_key.h
create mode 100644 kernel/power/hibernate_keys.c
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
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
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
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).
Pavel
PS: And yes, it would be nice to have
Documentation/power/swsusp-uefi.txt (or something) explaining the
design.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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
於 三，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
於 三，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
於 三，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
於 三，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
於 三，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
於 三，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
於 三，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
於 三，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
於 三，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
於 三，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
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.
>
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
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
On 26.9.2013 14:06, Pavel Machek wrote:
> 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.
I think that part of the exercise is to minimize the number of writes to
the NVRAM. The hash changes with every hibernation, obviously.
Michal
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
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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
於 四，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
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
On Thu, 26 Sep 2013, James Bottomley wrote:
> > 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?
Exactly.
> 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.
> 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.
--
Jiri Kosina
SUSE Labs
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
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