Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote: But if you don't generate fresh keys on every boot, the persistent keys are mor exposed to other UEFI applications. Correct me if I'm wrong, but I don't think UEFI variables are segregated between different UEFI applications, so if anyone gets a generic UEFI variable dumper (or setter) signed by the trusted key, this cryptographic validation of hibernate snapshots is bypassable. If anyone can execute arbitrary code in your UEFI environment then you've already lost. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
* Matthew Garrett: On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote: But if you don't generate fresh keys on every boot, the persistent keys are mor exposed to other UEFI applications. Correct me if I'm wrong, but I don't think UEFI variables are segregated between different UEFI applications, so if anyone gets a generic UEFI variable dumper (or setter) signed by the trusted key, this cryptographic validation of hibernate snapshots is bypassable. If anyone can execute arbitrary code in your UEFI environment then you've already lost. This is not about arbitrary code execution. The problematic applications which conflict with this proposed functionality are not necessarily malicious by themselves and even potentially useful. For example, if you want to provision a bunch of machines and you have to set certain UEFI variables, it might be helpful to do so in an unattended fashion, just by booting from a USB stick with a suitable UEFI application. Is this evil? I don't think so. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
On Sun, Sep 01, 2013 at 06:40:41PM +0200, Florian Weimer wrote: * Matthew Garrett: On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote: But if you don't generate fresh keys on every boot, the persistent keys are mor exposed to other UEFI applications. Correct me if I'm wrong, but I don't think UEFI variables are segregated between different UEFI applications, so if anyone gets a generic UEFI variable dumper (or setter) signed by the trusted key, this cryptographic validation of hibernate snapshots is bypassable. If anyone can execute arbitrary code in your UEFI environment then you've already lost. This is not about arbitrary code execution. The problematic applications which conflict with this proposed functionality are not necessarily malicious by themselves and even potentially useful. A signed application that permits the modification of arbitrary boot services variables *is* malicious. No implementation is designed to be safe in that scenario. Why bother with modifying encryption keys when you can just modify MOK instead? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
於 日，2013-09-01 於 18:40 +0200，Florian Weimer 提到： * Matthew Garrett: On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote: But if you don't generate fresh keys on every boot, the persistent keys are mor exposed to other UEFI applications. Correct me if I'm wrong, but I don't think UEFI variables are segregated between different UEFI applications, so if anyone gets a generic UEFI variable dumper (or setter) signed by the trusted key, this cryptographic validation of hibernate snapshots is bypassable. If anyone can execute arbitrary code in your UEFI environment then you've already lost. This is not about arbitrary code execution. The problematic applications which conflict with this proposed functionality are not necessarily malicious by themselves and even potentially useful. For example, if you want to provision a bunch of machines and you have to set certain UEFI variables, it might be helpful to do so in an unattended fashion, just by booting from a USB stick with a suitable UEFI application. Is this evil? I don't think so. -- Yes, if there have the kind of UEFI tools like you said, and it leak to attacker, then we lost. Even we re-generate key-pair for every S4, the tool, if it can set variable, means it can replace the public key that was stored by efi bootloader in bootservices variable. Then we still lost. When the tool can only dump variable but not set, then re-generate key-pair to every S4 can prevent it. If the tool can also set variable, then I don't think there have any way to protect key-pair in UEFI variables. Using TPM is a way to protect key-pair, but user need key-in password when generate and use key to sign stuff. It noises to user, but the best way to keep the password is in brain. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
於 四，2013-08-29 於 23:32 +0200，Pavel Machek 提到： Hi! - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. Is the UEFI NVRAM really suited for such regular updates? Yes, Matthew raised this concern at before. I modified patch to load private key in efi stub kernel, before ExitBootServices(), that means we don't need generate key-pair at every system boot. So, the above procedure of efi bootloader will only run one time. User can enable SNAPSHOT_REGEN_KEYS kernel config to notify efi booloader regenerate key-pair for every S4 to improve security if he want. So, the key-pair re-generate procedure will only launched when S4 resume, not every system boot. How many writes can UEFI NVRAM survive? (Is it NOR?) Currently doesn't have enough information for normal. Yes, I don't know. every S4 resume may be approximately every boot for some users... Pavel Yes, it's possible. So, this option will be disabled by default. Default will only generate one key-pair for every hibernate. If re-generate key-pair for every S4 is still hurt lift of UEFI NVRAM too much, then another thinking for re-generate key-pair are: + Re-generate key-pair after a number of hibernates. e.g. after 5, 10, 20... times or + Random re-generate key-pair? On the other hand... In current design, GenS4Key EFI variable could be write by userland hibernate tool, kernel will respect GenS4Key value from userland when hibernate launch. So, userland can tell bootloader to lunch the key-pair regeneration procedure. Thanks a lot! Joey LEe -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
* Chun-Yi Lee: + EFI bootloader must generate RSA key-pair when system boot: - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. Is the UEFI NVRAM really suited for such regular updates? -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18 v3] 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 the 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 enable the CONFIG_SNAPSHOT_VERIFICATION kernel config. And you can also choice which hash algorithm should snapshot be signed with. Then rebuild kernel. 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. = Behavior = The RSA key-pair are generated by EFI bootloader(e.g. shim) in UEFI secure boot environment, so this function binding with EFI secure boot enabled. The kernel behavior is: + UEFI Secure Boot ON. Kernel found private key from shim: Kernel will run the signature check when S4. + UEFI Secure Boot ON. Kernel didn't find key from shim: Kernel will lock down S4 function. + UEFI Secure Boot OFF Kernel will disable S4 signature check, and ignore any keys from EFI bootloader. Unconditional allow hibernate launch. On EFI bootloader side, the behavior as following: + First, 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 bootloader must generate RSA key-pair when system boot: - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. + EFI stub kernel will load the S4SignKey blob to RAM before ExitBootServices, then copy to a memory page to maintain by hibernate_key.c. This private key will used to sign snapshot when S4. + When machine resume from hibernate: - EFI bootloader should copy the public key from boottime variable to S4WakeKey EFI variable. - Bootloader need generates a new key-pair for next round S4 usage. It should put new private key to S4SignKey variable. + EFI bootlaoder need check the following EFI runtime variable for regenerate new key-pair: GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21 The size of GenS4Key is 1 byte, OS(kernel or userland tool) will set it to 1 for notify efi bootloader regenerate key-pair. == 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, I have porting 3 patches from Fedora kernel, authors are Josh Boyer and Matthew Garrett. I also add Cc. to them. Please help review this RFC patchset! Appreciate for any comments!
[RFC PATCH 00/18 v3] 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 the 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 enable the CONFIG_SNAPSHOT_VERIFICATION kernel config. And you can also choice which hash algorithm should snapshot be signed with. Then rebuild kernel. 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. = Behavior = The RSA key-pair are generated by EFI bootloader(e.g. shim) in UEFI secure boot environment, so this function binding with EFI secure boot enabled. The kernel behavior is: + UEFI Secure Boot ON. Kernel found private key from shim: Kernel will run the signature check when S4. + UEFI Secure Boot ON. Kernel didn't find key from shim: Kernel will lock down S4 function. + UEFI Secure Boot OFF Kernel will disable S4 signature check, and ignore any keys from EFI bootloader. Unconditional allow hibernate launch. On EFI bootloader side, the behavior as following: + First, 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 bootloader must generate RSA key-pair when system boot: - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. + EFI stub kernel will load the S4SignKey blob to RAM before ExitBootServices, then copy to a memory page to maintain by hibernate_key.c. This private key will used to sign snapshot when S4. + When machine resume from hibernate: - EFI bootloader should copy the public key from boottime variable to S4WakeKey EFI variable. - Bootloader need generates a new key-pair for next round S4 usage. It should put new private key to S4SignKey variable. + EFI bootlaoder need check the following EFI runtime variable for regenerate new key-pair: GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21 The size of GenS4Key is 1 byte, OS(kernel or userland tool) will set it to 1 for notify efi bootloader regenerate key-pair. == 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, I have porting 3 patches from Fedora kernel, authors are Josh Boyer and Matthew Garrett. I also add Cc. to them. Please help review this RFC patchset! Appreciate for any comments!
