Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

EFI Secure Key

136 Aufrufe

Veröffentlicht am

A new master key type for encrypted key
and Why is it not accepted by mainline

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

EFI Secure Key

  1. 1. EFI secure key August, 2018, openSUSE.Asia 2018, Taipei Joey Lee SUSE Labs Taipei
  2. 2. 2 Agenda • Key Retention Service • Trusted Key and Encrypted key • EFI Secure Key • Why is it not accepted by mainline? • Q&A
  3. 3. Key Retention Service
  4. 4. 4 Kernel Key Retention Service • This service allows cryptographic keys, authentication tokens, cross-domain user mappings, and similar to be cached in the kernel for the use of filesystems and other kernel services. [1] • Any kind of authentication or access information can be stored as a key; it is essentially an opaque chunk of data that is only interpreted by the kernel subsystem that is interested in it. [2]
  5. 5. 5 Key Retention Service Keyrings (system, session, user...) Kernel Userspace TPM (option) eCryptfs VFS xfs ext4 jfs ... keyctl syscalls (add, update, read, reoke...) IMA/EVM device mapper request key kernel modulesnetwork dm-crypt seal/unseal Initrd keyctl (add, update, read, reoke...) syscalls
  6. 6. 6 Key and payload struct key - A serial number - A type - A description (for maching a key in a search) - Access control information - An expiry time - A payload - State Kernel Key Retention Service [1] KEY Payload user_key_payload trusted_key_payload encrypted_key_payload ... [union key_payload]
  7. 7. Trusted Key and Encrypted Key
  8. 8. 8 Trusted and Encrypted Keys • Introduced since v2.6.38 kernel ‒ Contribued by IBM ‒ Mimi Zohar <zohar@us.ibm.com> ‒ Roberto Sassu <roberto.sassu@polito.it> ‒ David Safford <safford@us.ibm.com> … • Both of these new types are variable length symmetric keys, and in both cases all keys are created in the kernel, and user space sees, stores, and loads only encrypted blobs. [4]
  9. 9. 9 Trusted key • Trusted Keys use a TPM both to generate and to seal the keys. Keys are sealed under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR (integrity measurement) values, and only unsealed by the TPM, if PCRs and blob integrity verifications match. [4] • The same key can have many saved blobs under different PCR values, so multiple boots are easily supported. [4]
  10. 10. 10 Create trusted key (flow) New key (random plaintext) 00. request from PCR 1, 2, 3... SRK (Storage Root Key) TPM PCR_INFO[3] 01. read from(option) 02.seal Trusted key (plaintext + TPM_STORED_DATA) TPM_STORED_DATA[3] random byes 03. request from(option) 04. Extend a PCR for capping (option)RNG
  11. 11. 11 Trusted key payload key_len rcu trusted_key_payload blob_len Migratable (0|1 permission to reseal) key (unsealed plaintext) blob (sealed blob) (TPM_STORED_DATA) key_len blob_len V4.17-rc dump to userland
  12. 12. 12 Encrypted key • Encrypted keys do not depend on a TPM, and are faster, as they use AES for encryption/decryption. [4] • New keys are created from kernel generated random numbers, and are encrypted/decrypted using a specified 'master' key. The 'master' key can either be a trusted-key or user-key type. [4] • The decrypted portion of encrypted keys can contain either a simple symmetric key or a more complex structure. [4]
  13. 13. 13 Create/Pipe encrypted key (flow) Authentication Key KMK (trusted key or user key) Encryption Key 04. hash with AUTH_KEY string 02. hash with ENC_KEY string System/User Keyring derive New key (plaintext) IV (initialization vector) Random Pool derive 00.getfrom 00.getfrom 01. request from 03. encrypt 03. New key (ciphertext) 05. signing AES encrypt HMAC sign 05. signing Encrypted key (ciphertext + signature)
  14. 14. 14 Encrypted key payload rcu encrypted_key_payload address points to datablob char *format char *master_desc char *datalen u8 *iv u8 *encrypted_data length of data unsigned short datablob_len unsigned short decrypted_datalen unsigned short payload_datalen encrypted_key_format decrypted_data point payload_data (decrypted data + datablob + hmac) datablob decrypted data hmac V4.17-rc dump to userland
  15. 15. 15 Encrypted key payload_data payload_data[0] descrypted data encrypted_data decrypted_datalen datablob_len datablob format (default or encryptfs) master_desc (master key name Trusted: or user:) datalen (decrypted key length string) iv (initialization vector) hmac (signature of datablob) dump to userland V4.17-rc
  16. 16. EFI Secure Key
  17. 17. 17 EFI Secure Key • A new kernel key type • A new master key type for encrypted key • Pros ‒ It doesn’t rely on user space. ‒ It doesn’t need TPM. ‒ Can be loaded by kernel in early boot stage. • Cons: It relies on firmware layer and secure boot ‒ Consumed limited NVRAM space ‒ Buggy firmware may earse or break the key
  18. 18. 18 The Code of EFI Secure Key • https://lkml.org/lkml/2018/8/5/10 ‒ From "Lee, Chun-Yi" <> Subject [PATCH 0/6][RFC] Add EFI secure key to key retention service Date Sun, 5 Aug 2018 11:21:13 +0800 • https://github.com/joeyli/linux-s4sign/tree/efi-master- key-v0.2-v4.18-rc7-devel
  19. 19. 19 EFI Root Key • When secure boot is enabled, only signed EFI binary can access EFI boot service variable before ExitBootService. Which means that the EFI boot service variable is secure. • ERK (EFI Root Key) ‒ EFI boot stub generates a 512-bit random number and stores in EFI boot service variable. ‒ The random number can be a root key for encryption and authentication.
  20. 20. 20 ERK and EFI Secure Key • ERK can be used to encrypt/authenticate a random number to generate EFI secure key. The EFI secure key can be a new master key type for encrypted key. It’s useful for hibernation or evm. • Compare with User key and TPM trused key: User key-in --create--> User key --encrypt--> Encrypted key TPM SRK ---seal----> Trusted key --encrypt--> Encrypted key ERK --encrypt--> EFI key --encrypt--> Encrypted key
  21. 21. 21 EFI Secure Key (flow) ERK Kernel Space ENC_KEY Random Pool EFI KEY sign encrypt EFI KEY Blob ERK EFI Secure Boot AUTH_KEY derive
  22. 22. 22 EFI secure key payload rcu efi_key_payload address points to datablob u8 *key u8 *datablob char *key_len_str u8 *erk_hash u8 *iv u8 *encrypted_key u8 *hmac length of data unsigned int key_len unsigned int datablob_len payload_data (decrypted key + datablob + hmac) Datablob key_len_str ERK hash iv Encrypted key decrypted key hmac dump to userland
  23. 23. 23 EFI Secure Key and keyctl tool • Create a 128 bytes EFI key in kernel ‒ keyctl add efi kmk-efi "new 128" @u • Dump a EFI key to a EFI key blob ‒ keyctl pipe $NUMBER > kmk-efi.blob • Load a EFI key blob to kernel ‒ keyctl add efi kmk-efi "load `cat kmk-efi.blob`" @u • Create a 32 bytes encrypted key base on EFI key ‒ keyctl add encrypted evm-key "new efi:kmk-efi 32" @u
  24. 24. Why is it not accepted by mainline?
  25. 25. 25 Low entropy inputs in EFI boot stage • https://lkml.org/lkml/2018/8/5/40 ‒ Ard Biesheuvel <ard.biesheuvel@linaro.org> • Only a few entopy sources in EFI boot stage. • RDTSC or i8254 not qualify for symmetric key. • RDRAND (x86) or EFI_RNG_PROTOCOL must be available.
  26. 26. 26 Secure boot does not mean “Secure” • https://lkml.org/lkml/2018/8/5/31 ‒ Ard Biesheuvel <ard.biesheuvel@linaro.org> • https://lkml.org/lkml/2018/8/5/135 ‒ James Bottomley <James.Bottomley@HansenPartnership.com> • 'Secure boot' should be called 'authenticated boot'. • The UEFI variable store was not designed with confidentiality in mind. • The reputation of EFI on the implementation side is… • Secure boot relies on Microsoft's Business interests. • Microsoft doesn't use UEFI variables for confidentiality, so we shouldn't either.
  27. 27. Q&A
  28. 28. 28 Reference • [1] Documentation/security/keys/core.rst, Linux Kernel v4.17-rc • [2] Kernel key management, Jake Edge, LWN.net, November 21, 2006 • [3] TPM Main Part 2 TPM Structures Specification version 1.2 Level 2 Revision 116, TCG Published, 1 March 2011 • [4] Documentation/security/keys/trusted- encrypted.rst, Linux Kernel v4.17-rc
  29. 29. Thank you. 29 Feedback to jlee@suse.com
  30. 30. Corporate Headquarters Maxfeldstrasse 5 90409 Nuremberg Germany +49 911 740 53 0 (Worldwide) www.suse.com Join us on: www.opensuse.org 31
  31. 31. 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.