Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

S4 sig-check-lpc-20130918

2,651 views

Published on

Signature Verification fo Hibernate Snapshot - Joey Lee, Suse
Linux Plumbers Conference 2013

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

S4 sig-check-lpc-20130918

  1. 1. Signature verification of hibernate snapshot September, 2013, LPC 2013, New Orleans Joey Lee
  2. 2. Problem ● ● On a multi-boot machine, hacker use any hole in another UEFI trusted OS to modify the hibernate snapshot image in swap partition. Through uswsusp, userspace can take the snapshot of memory then modify it. Upload it back to memory then trigger the restore. © SUSE, All rights reserved.
  3. 3. Idea ● ● ● Jiri Kosina: Let EFI bootloader generates keypair then pass to kernel for sign hibernate image. Fundamental point: Trust the boot time variable is secure when UEFI secure boot enabled. Attempt to protect snapshot image integrity. © SUSE, All rights reserved.
  4. 4. Steps (when hibernate) ● ● ● ● shim bootloader geneates key-pair and put keys to non-volatile boot time varaibles. EFI stub kernel loads private key before ExitBootServices(). Hibernate subsystem copy the private key to a empty page to keep it for sign snapshot when hibernate launched. Kernel generates signature of snapshot image then put the signature to snapshot header. Current reserved max size of signature is 512 bytes. © SUSE, All rights reserved.
  5. 5. Steps (when hibernate restore) ● ● After hibernate loaded snapshot image from swap to temporary memory space, kernel uses the public key from runtime volatile variable to verify the signature that's stored in snapshot header. Then depend on sig_enforce ● ● OFF: taint kernel and produce complain log when signature check fail ON: fail the hiberntae restore, then finish boot process when signature check fail. © SUSE, All rights reserved.
  6. 6. How to enable sig_enforce? ● ● Use snapshot_sig_enforce kernel parameter. Set kernel config then enable UEFI secure boot: EFI_SECURE_BOOT_SNAPSHOT_SIG_ENFO RCE © SUSE, All rights reserved.
  7. 7. EFI variable name and GUID ● GUID: ● ● S4SignKey [BT][NV]→ private key ● ● fe141863-c070-478e-b8a3-878a5dc9ef21 PKCS#8 _uncompressed_ private key format S4WakeKey [RT][V] → public key ● X.509 format © SUSE, All rights reserved.
  8. 8. When shim should generate keys? ● ● When system boot, and shim didn't find key-pair When shim found GenS4Key EFI variable from kernel: ● ● ● GenS4Key-fe141863-c070-478e-b8a3878a5dc9ef21 [RT][NV] Kernel or userspace write GenS4Key variable to '1' when hibernate launched. Kernel will delete GenS4Key in system boot. © SUSE, All rights reserved.
  9. 9. Implementation Parts ● Key-pair generator in shim ● ● ● Author: Gary Lin https://github.com/lcp/shim/tree/s4-key-upstream Asymmetric Keys in Kernel: ● ● ● Implemented PKCS#8 and PKCS#1 RSA private key parser Add signature generation API and implement signature generation logic in PKCS#1 (RFC3447 sec 8.2.2) Hibernate in Kernel: ● CONFIG_SNAPSHOT_VERIFICATION=y ● Maintain and forward private key. ● Avoid private key included in snapshot image.s ● Sign snapshot image: generate signature then put it to snapshot header. © SUSE, All rights reserved.
  10. 10. Performance of hash (machine 1) ● CPU: ● ● ● Intel(R) Core(TM) i5 CPU x86_64, ssse3 Normal ● SHA1: 150.80 MB/s ● SHA256: 59.19 MB/s ● ● 650 @ 3.20GHz SHA512: 78.44 MB/s Builded ssse3 support (v3.10 later) ● SHA1: 195.60 MB/s ● SHA256: 82.76 MB/s ● SHA512: 120.60 MB/s © SUSE, All rights reserved.
  11. 11. Performance of hash (machine 2) ● CPU: ● ● ● Intel(R) CPU @ 2.60GHz x86_64, ssse3, avx, avx2 Normal ● ● SHA256: 163.23 MB/s ● ● SHA1: 436.42 MB/s SHA512: 228.67 MB/s Builded ssse3, avx, avx2 support (v3.10 later) ● SHA1: 609.66 MB/s <=== fastest ● SHA256: 242.03 MB/s ● SHA512: 344.87 MB/s <=== more secure © SUSE, All rights reserved.
  12. 12. Performance of hash (summary) ● Speed between SHA1, SHA256, SHA512 ● ● SHA1 is 1.8 times of SHA512 ● ● SHA1 is 2.5 times of SHA256 SHA512 is 1.4 times of SHA256 Enabled ssse3 ● ● 39% improved on SHA256 ● ● 29% improved on SHA1 53% improved on SHA512 Enabled ssse3, avx, avx2 ● 39% improved on SHA1 ● 48% improved on SHA256 ● 50% improved on SHA512 © SUSE, All rights reserved.
  13. 13. Performance of hash (summary) ● Machine 1: ● Best performance – – ● SHA1: 195.60 MB/s on ssse3, avx, avx2 snapshot image grown to 3GB, then need 15.7 seconds for hash SHA512's best performance – – ● 120.60 MB/s on ssse3, avx, avx2 snapshot image grown to 3GB, then need 25.4 seconds for hash Machine 2: ● Best performance – – ● SHA1: 609.66 MB/s on ssse3, avx, avx2 snapshot image grown to 3GB, then need 5 seconds for hash SHA512's best performasnce – 344.87 MB/s on ssse3, avx, avx2 – snapshot image grown to 3GB, then need 8.9 seconds for hash © SUSE, All rights reserved.
  14. 14. Patch status ● V4 RFC patches sent to kernel upstream and openSUSE kernel for reviewing: ● ● ● [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot https://lkml.org/lkml/2013/9/14/183 Following kernel experts gave suggestions: ● Hibernate ● Matt Fleming <matt@console-pimps.org> EFI ● ● Pavel Machek <pavel@ucw.cz> Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Asymmetric keys Followed Pavel and Matt's suggestions, already fix in V2, V3 patches © SUSE, All rights reserved.
  15. 15. TODO ● V5 patches: ● ● ● Implement Dmitry Kasatkin's suggestions to Asymmetric keys. Should we remove the kernel config to user for select hash algorithms? Function add: ● ● Kernel pass random number seed by EFI variable to shim. Encript snapshot image before sign it? © SUSE, All rights reserved.
  16. 16. Corporate Headquarters Maxfeldstrasse 5 90409 Nuremberg Germany © SUSE, All rights reserved. +49 911 740 53 0 (Worldwide) +www.suse.com Join us on: www.opensuse.org
  17. 17. Unpublished Work of SUSE. All Rights Reserved. This work is an unpublished work and contains confidential, proprietary, and trade secret information of SUSE. Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability. General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for SUSE products remains at the sole discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

×