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
7. PKI EditionPKI Edition
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 Hibernate Matt Fleming EFI Dmitry
Kasatkin 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
16. HMAC EditionHMAC Edition
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
