Signature verification of hibernate snapshot
0 likes1,244 views
This document discusses signature verification of hibernate snapshots to ensure integrity when resuming from hibernation in a multi-boot environment. It proposes using either a PKI or HMAC approach to sign snapshots before hibernation and verify signatures when restoring. It discusses implementing key generation in the bootloader and signature generation/verification in the kernel, and addresses challenges around entropy, performance, and status of patches.
![12
When does shim re-generate key-pair?
• Key generating introduces longer boot time. So, an idea is
re-generate key-pair only after hibernating.
• Shim generates keys if didn't find them when booting.
• When shim saw GenS4Key EFI variable set by kernel:
• GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21
[RT][NV]
• Kernel or userspace create GenS4Key variable to '1'
when hibernate process launched.
• Kernel will delete GenS4Key in system boot for reset.](https://image.slidesharecdn.com/s4-sig-check-gnome-asia-20150509-150526101800-lva1-app6892/85/Signature-verification-of-hibernate-snapshot-12-320.jpg)
![14
RFC Patches status
• 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:
• Pavel Machek <pavel@ucw.cz> Hibernate
• Matt Fleming <matt@console-pimps.org> EFI
• Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Asymmetric keys
• Launched discussion in Linux Plumbers Conference 2013:
• https://www.youtube.com/watch?v=snXZIP2JJtg](https://image.slidesharecdn.com/s4-sig-check-gnome-asia-20150509-150526101800-lva1-app6892/85/Signature-verification-of-hibernate-snapshot-14-320.jpg)
More Related Content
What's hot (20)
Similar to Signature verification of hibernate snapshot (20)
![[HES2013] Virtually secure, analysis to remote root 0day on an industry leadi...](https://cdn.slidesharecdn.com/ss_thumbnails/day1-04-140412114404-phpapp02-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (20)
Signature verification of hibernate snapshot
- 1. Signature verification ofSignature verification of hibernate snapshothibernate snapshot MayMay, 2015, GNOME.Asia 2015, Depok, 2015, GNOME.Asia 2015, Depok Joey Lee, SUS Labs Taipei
- 2. 2 Agenda • Motivation • Idea • PKI Edition • HMAC Edition • Fundamental Challenges • Entropy • Performance • TODO • Q&A
- 3. 3 Motivation • UEFI secure boot provides a trusted boot environment to verify the integrity of bootloader and kernel. • Trusted kernel patchset • https://lkml.org/lkml/2015/3/13/771 • Enable kernel module signature checkings • Lock down IO port, /dev/mem, kexec, uswsusp... • In multi-boot environment, cracker may use any vulnerabilities in another UEFI trusted OS to modify the hibernate snapshot image in swap partition. • Through uswsusp, user space can take the snapshot of memory, modify it, upload it back to memory then trigger the restoring.
- 4. 4 Idea • Jiri Kosina: Let EFI bootloader generates key-pair then forwarding it to kernel for signing hibernate snapshot image. • Fundamental: • Only signed .efi executable could be running in UEFI environment when secure boot ON. • That means we can trust the boot time variable that should be secure when UEFI secure boot ON. • Base on the trust, we checking the integrity of snapshot image.
- 5. 5
- 6. 6
- 8. 8 Hibernating • In UEFI boot time environment: • shim bootloader generates key-pair and stores keys in to non-volatile boot time variables. • EFI stub loads private key before ExitBootServices(). • In UEFI runtime environment: • Hibernate subsystem keeps the private key that's from boot time for signing snapshot when hibernating. • Kernel generates signature of snapshot image and store it into snapshot header. Reserved space of signature is 64 bytes.
- 9. 9
- 10. 10
- 11. 11 Restoring • After the snapshot image be loaded from swap to temporary memory space, kernel will use public key that's stored in runtime volatile variable to verify the signature in snapshot header. • The subsequent behavior depend on sig_enforce flag • OFF: Taint kernel and produce complain log when signature checking fail. • ON: Block hibernate restoring, turn to normal booting process when signature check fail. • How to enable sig_enforce? • Set kernel config then enable UEFI secure boot: EFI_SECURE_BOOT_SNAPSHOT_SIG_ENFORCE
- 12. 12 When does shim re-generate key-pair? • Key generating introduces longer boot time. So, an idea is re-generate key-pair only after hibernating. • Shim generates keys if didn't find them when booting. • When shim saw GenS4Key EFI variable set by kernel: • GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21 [RT][NV] • Kernel or userspace create GenS4Key variable to '1' when hibernate process launched. • Kernel will delete GenS4Key in system boot for reset.
- 13. 13 Implemented Components • Key-pair generator in shim • Author: Gary Lin • https://github.com/lcp/shim/tree/s4-key-upstream • Private key parser and signature generator in Kernel: • Author: Joey Lee • 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 signature check in Kernel: • Author: Joey Lee • CONFIG_SNAPSHOT_VERIFICATION=y • Sign snapshot image, Verify it.
- 14. 14 RFC Patches status • 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: • Pavel Machek <[email protected]> Hibernate • Matt Fleming <[email protected]> EFI • Dmitry Kasatkin <[email protected]> Asymmetric keys • Launched discussion in Linux Plumbers Conference 2013: • https://www.youtube.com/watch?v=snXZIP2JJtg
- 15. 15 Got Suggestions • Implement Symmetric key edition: • bootloader don't need involve. • Generating HMAC key in EFI stub • Forwarding the entropy from runtime environment to EFI stub for generating next key. • Interstellar Hackweek project: • https://hackweek.suse.com/projects/160
- 17. 17
- 18. 18 HMAC Edition • Keyed-hash message authentication code (HMAC), RFC2104 • In UEFI boot time environment: • EFI stub generates 20 bytes length HMAC-SHA1 keys. Storing keys in to non-volatile boot time variables. • In UEFI runtime environment: • Kernel generates digest of snapshot image by HMAC-SHA1 and stores it in to snapshot header. Reserved space of signature is 20 bytes. • Pros: • Simpler than PKI edition, boot loader doesn't involve. • Don't need implement RSA private key parser in KEYS subsystem.
- 19. EntropyEntropy
- 20. 20 Boot-Time Entropy • When system booting, the UEFI boot time environment is too early so there have no enough entropy for generating keys. • rdtsc: • It counts the number of cycles since reset • Only running one time is not random enough, may got close result on the same machine when booting • RdRand: Could not fully trust RdRand because it's packaged in CPU. • Shim: rdtsc (collect many times), RdRand, mess by sha256 in openSSL in EDK2 <=== Unfortunately, NO openSSL in EFI stub • KASLR: a653f3563 patch, v3.14, Kees Cook • KASLR(Kernel address space layout randomization) • Starting entropy = build-time versions string rotate_xor boot-time boot_params structure • Starting entropy XOR RdRand XOR rdtsc
- 22. 22 Performance of hash (machine 1) • CPU: • Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz • x86_64, ssse3 • Normal • SHA1: 150.80 MB/s • SHA256: 59.19 MB/s • SHA512: 78.44 MB/s • Build ssse3 support (since v3.10) • SHA1: 195.60 MB/s • SHA256: 82.76 MB/s • SHA512: 120.60 MB/s
- 23. 23 Performance of hash (machine 2) • CPU: • Intel(R) CPU @ 2.60GHz • x86_64, ssse3, avx, avx2 • Normal • SHA1: 436.42 MB/s • SHA256: 163.23 MB/s • SHA512: 228.67 MB/s • Build ssse3, avx, avx2 support (since v3.10) • SHA1: 609.66 MB/s <=== fastest record • SHA256: 242.03 MB/s • SHA512: 344.87 MB/s <=== more secure
- 24. 24 Performance of hash (summary) • Speed between SHA1, SHA256, SHA512 • SHA1 has 2.5 times speed of SHA256 • SHA1 has 1.8 times speed of SHA512 • SHA512 has 1.4 times speed of SHA256 • Enabled ssse3 • 29% improvement on SHA1 • 39% improvement on SHA256 • 53% improvement on SHA512 • Enabled ssse3, avx, avx2 • 39% improvement on SHA1 • 48% improvement on SHA256 • 50% improvement on SHA512
- 25. 25 Performance of hash (summary) • Machine 1 (3.20GHz, ssse3): • Best performance • SHA1: 195.60 MB/s with ssse3 • snapshot image grown to 3GB, means need 15.7 seconds for hashing • SHA512's best performance • 120.60 MB/s with ssse3 • snapshot image grown to 3GB, means need 25.4 seconds for hashing • Machine 2 (2.60GHz, ssse3, avx, avx2): • Best performance • SHA1: 609.66 MB/s with ssse3, avx, avx2 • snapshot image grown to 3GB, means need 5 seconds for hashing • SHA512's best performance • 344.87 MB/s with ssse3, avx, avx2 • snapshot image grown to 3GB, means need 8.9 seconds for hashing
- 26. 26 TODO • Finish the HMAC Edition and send to kernel upstream • Choosing HMAC-SHA1 • SHA1 is the fastest algorithm in SHA family, and still secure on practice. • Using the random number generator from KASLR.
- 27. Q&AQ&A
- 29. 29
- 30. 30 OpenSUSE.Asia 2014 • Location: Beijing • 11 weekly meetings, hundreds of mails for communication, 137 cards in Trello to follow up • More than 50 proposals, 10 long talks, 14 short talks and 8 workshops • 118 online registrants and 52 on-site registrants • 8 sponsors • Speakers are mostly from Asia. • Sessions, Workshop, Lightning talk, Meet with friends... • openSUSE.Asia 2015 is in planning • 855 pictures on flickr
- 31. 31
- 32. 32
- 33. 33
- 34. 34
- 35. 35
- 36. 36
- 37. 37
- 38. 38
- 40. 40