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.

Looking into trusted and encrypted keys

404 Aufrufe

Veröffentlicht am

The trusted and encrypted keys in Linux kernel keyring

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

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

Looking into trusted and encrypted keys

  1. 1. Looking into trusted and encrypted keys April, 2018, SUSE Labs Taipei technology sharing day, Taipei Joey Lee SUSE Labs Taipei
  2. 2. 2 Agenda • Key Retention Service • Trusted Key • Encrypted key • TODO – Reads protection of keyring, kernel lockdown – EFI kernel master key • 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. 7 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]
  8. 8. Trusted Key
  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
  12. 12. 12 Format in trusted key • "keyctl print" returns an ascii hex copy of the sealed key, which is in standard TPM_STORED_DATA format. [4] • The key length for new keys are always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding. [4]
  13. 13. 13 Create a trusted key TPM_STORED_DATA [3] serial number
  14. 14. 14 Save/Load a trusted key
  15. 15. 15 Create a trusted key (in kernel) • keyctl add trusted kmk "new 32" @u security/keys drivers/char/tpm 04. tpm_get_random 05. tpm_seal_trusted (TPM 2.0) 06-1. tpm_get_random 06-2. tpm_pcr_extend 00. trusted_instantiate 01. trusted_options_alloc 02. trusted_payload_alloc 03. datablob_parse 05. key_seal (TPM 1.0) 06. pcrlock V4.17-rc
  16. 16. 16 Load a trusted key (in kernel) • keyctl add trusted kmk "load `cat kmk.blob`" @u security/keys drivers/char/tpm 04. tpm_unseal_trusted (TPM 2.0) 05-1. tpm_get_random 05-2. tpm_pcr_extend 00. trusted_instantiate 01. trusted_options_alloc 02. trusted_payload_alloc 03. datablob_parse 04. key_unseal (TPM 1.0) 05. pcrlock V4.17-rc
  17. 17. Encrypted Key
  18. 18. 18 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]
  19. 19. 19 Create/Pipe encrypted key (flow) Authentication Key KMK (encrypted 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)
  20. 20. 20 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
  21. 21. 21 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) save to userland V4.17-rc
  22. 22. 22 Create a encrypted key serial number <format> <master-key name> <decrypted data length> <iv + encrypted data + hmac>
  23. 23. 23 Save/Load a encrypted key
  24. 24. TODO
  25. 25. 25 Kernel lockdown and keys • [GIT PULL] Kernel lockdown for secure boot – David Howells<dhowells@redhat.com> – The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded. – Kees Cook: Chrome OS does not use UEFI, and we still want this patch series, as it plugs all the known "intentional" escalation paths from uid-0 to ring-0. – Linus said that the lockdown mechanism should not be binded with secure boot.
  26. 26. 26 Kernel lockdown and keys (cont.) • The sensitive data should not be accessed when root be compromised. – plaintext in trusted key – decrypted data in encrypted key – EVM key – dm-encrypt key … • Lockdown the reads functions – /dev/mem, /dev/kmem, /dev/kcore – bpf, kprobes, perf – Hibernation – Kexec/Kdump ...
  27. 27. 27 EFI kernel master key • Current two master key types: – User key: The master user key should therefore be loaded in as secure a way as possible, preferably early in boot. [4] The user space environment needs authorization. – Encrypted key: It needs TPM. And it should be sealed to specific boot PCR values against boot and offline attacks.
  28. 28. 28 EFI kernel master key (cont.) • A New KEK type • EFI stub generates key and stores in EFI boot services variable. Kernel loads the key when booting. • 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
  29. 29. Q&A
  30. 30. 30 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
  31. 31. Thank you. 31 Feedback to jlee@suse.com
  32. 32. Corporate Headquarters Maxfeldstrasse 5 90409 Nuremberg Germany +49 911 740 53 0 (Worldwide) www.suse.com Join us on: www.opensuse.org 33
  33. 33. 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.