O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
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. 
• 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. 
Key and payload
- A serial number
- A type
- A description (for maching a key in a search)
- Access control information
- An expiry time
- A payload
Kernel Key Retention Service 
Trusted and Encrypted Keys
• Introduced since v2.6.38 kernel
– Contribued by IBM
● Mimi Zohar <email@example.com>
● Roberto Sassu <firstname.lastname@example.org>
● David Safford <email@example.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. 
• 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. 
• The same key can have many saved blobs under
different PCR values, so multiple boots are easily
Create trusted key (flow)
00. request from
1, 2, 3...
(Storage Root Key)
01. read from(option)
(plaintext + TPM_STORED_DATA)
03. request from(option)
04. Extend a PCR for capping
Format in trusted key
• "keyctl print" returns an ascii hex copy of the sealed
key, which is in standard TPM_STORED_DATA
• 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
Create a trusted key
• Encrypted keys do not depend on a TPM, and are
faster, as they use AES for encryption/decryption.
• 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. 
• The decrypted portion of encrypted keys can contain
either a simple symmetric key or a more complex
Create/Pipe encrypted key (flow)
(encrypted key or user key)
04. hash with
02. hash with
01. request from
(ciphertext + signature)
Encrypted key payload
address points to datablob
length of data
unsigned short datablob_len
unsigned short decrypted_datalen
unsigned short payload_datalen
(decrypted data + datablob + hmac)
Encrypted key payload_data
(default or encryptfs)
(master key name
Trusted: or user:)
(decrypted key length string)
(signature of datablob)
save to userland
Create a encrypted key
<format> <master-key name> <decrypted data length> <iv + encrypted data + hmac>
Kernel lockdown and keys
• [GIT PULL] Kernel lockdown for secure boot
– David Howells<firstname.lastname@example.org>
– 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.
Kernel lockdown and keys (cont.)
• The sensitive data should not be accessed when root be
– 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
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. 
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.
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.
– 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
+49 911 740 53 0 (Worldwide)
Join us on:
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.
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.