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.
Signature verification ofSignature verification of
hibernate snapshothibernate snapshot
MayMay, 2015, GNOME.Asia 2015, Dep...
2
Agenda
• Motivation
• Idea
• PKI Edition
• HMAC Edition
• Fundamental Challenges
• Entropy
• Performance
• TODO
• Q&A
3
Motivation
• UEFI secure boot provides a trusted boot environment to
verify the integrity of bootloader and kernel.
• Tr...
4
Idea
• Jiri Kosina: Let EFI bootloader generates key-pair then
forwarding it to kernel for signing hibernate snapshot
im...
5
6
PKI EditionPKI Edition
8
Hibernating
• In UEFI boot time environment:
• shim bootloader generates key-pair and stores keys in
to non-volatile boo...
9
10
11
Restoring
• After the snapshot image be loaded from swap to temporary
memory space, kernel will use public key that's s...
12
When does shim re-generate key-pair?
• Key generating introduces longer boot time. So, an idea is
re-generate key-pair ...
13
Implemented Components
• Key-pair generator in shim
• Author: Gary Lin
• https://github.com/lcp/shim/tree/s4-key-upstre...
14
RFC Patches status
• RFC patches sent to kernel upstream and openSUSE kernel for
reviewing:
• [RFC V4 PATCH 00/15] Sign...
15
Got Suggestions
• Implement Symmetric key edition:
• bootloader don't need involve.
• Generating HMAC key in EFI stub
•...
HMAC EditionHMAC Edition
17
18
HMAC Edition
• Keyed-hash message authentication code (HMAC), RFC2104
• In UEFI boot time environment:
• EFI stub gener...
EntropyEntropy
20
Boot-Time Entropy
• When system booting, the UEFI boot time environment is too early so there
have no enough entropy fo...
PerformancePerformance
22
Performance of hash (machine 1)
• CPU:
• Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz
• x86_64, ssse3
• Normal
• SHA1: 150.80...
23
Performance of hash (machine 2)
• CPU:
• Intel(R) CPU @ 2.60GHz
• x86_64, ssse3, avx, avx2
• Normal
• SHA1: 436.42 MB/s...
24
Performance of hash (summary)
• Speed between SHA1, SHA256, SHA512
• SHA1 has 2.5 times speed of SHA256
• SHA1 has 1.8 ...
25
Performance of hash (summary)
• Machine 1 (3.20GHz, ssse3):
• Best performance
• SHA1: 195.60 MB/s with ssse3
• snapsho...
26
TODO
• Finish the HMAC Edition and send to kernel upstream
• Choosing HMAC-SHA1
• SHA1 is the fastest algorithm in SHA ...
Q&AQ&A
openSUSE.AsiaopenSUSE.Asia
29
30
OpenSUSE.Asia 2014
• Location: Beijing
• 11 weekly meetings, hundreds of mails for communication,
137 cards in Trello t...
31
32
33
34
35
36
37
38
39
Join us on:
www.opensuse.org
40
Upcoming SlideShare
Loading in …5
×

Signature verification of hibernate snapshot

935 views

Published on

presentation for GNOME.Asia 2015 - Signature verification of hibernate snapshot

Published in: Software
  • Be the first to comment

  • Be the first to like this

Signature verification of hibernate snapshot

  1. 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. 2 Agenda • Motivation • Idea • PKI Edition • HMAC Edition • Fundamental Challenges • Entropy • Performance • TODO • Q&A
  3. 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. 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. 5
  6. 6. 6
  7. 7. PKI EditionPKI Edition
  8. 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. 9
  10. 10. 10
  11. 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. 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. 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. 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
  15. 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
  16. 16. HMAC EditionHMAC Edition
  17. 17. 17
  18. 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. 19. EntropyEntropy
  20. 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
  21. 21. PerformancePerformance
  22. 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. 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. 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. 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. 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. 27. Q&AQ&A
  28. 28. openSUSE.AsiaopenSUSE.Asia
  29. 29. 29
  30. 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. 31
  32. 32. 32
  33. 33. 33
  34. 34. 34
  35. 35. 35
  36. 36. 36
  37. 37. 37
  38. 38. 38
  39. 39. 39 Join us on: www.opensuse.org
  40. 40. 40

×