This document discusses trusted and encrypted keys in the Linux kernel key retention service. It describes how trusted keys use the TPM to generate and seal keys, while encrypted keys encrypt keys using an AES master key. It also outlines plans to introduce an EFI kernel master key and further lock down the kernel to protect sensitive key material from compromise.

1. Looking into trusted and
encrypted keys
April, 2018, SUSE Labs Taipei technology sharing day, Taipei
Joey Lee
SUSE Labs Taipei

2. 2
Agenda
• Key Retention Service
• Trusted Key
• Encrypted key
• TODO
– Reads protection of keyring, kernel lockdown
– EFI kernel master key
• Q&A

3. Key Retention Service

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
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
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 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. Trusted Key

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
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
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
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
Create a trusted key
TPM_STORED_DATA [3]
serial number

14. 14
Save/Load a trusted key

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
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. Encrypted Key

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
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
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
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
Create a encrypted key
serial number
<format> <master-key name> <decrypted data length> <iv + encrypted data + hmac>

23. 23
Save/Load a encrypted key

24. TODO

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
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
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
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. Q&A

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. Thank you.
31
Feedback to
jlee@suse.com

33. Corporate Headquarters
Maxfeldstrasse 5
90409 Nuremberg
Germany
+49 911 740 53 0 (Worldwide)
www.suse.com
Join us on:
www.opensuse.org
33

34. 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.