summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorJames Morris <james.morris@microsoft.com>2018-12-17 20:26:46 +0100
committerJames Morris <james.morris@microsoft.com>2018-12-17 20:26:46 +0100
commit5580b4a1a8ca85c53bd5b94c5d302e47dca3e5cb (patch)
tree69597129504be73e8826be9984e05d073a5c47b5 /Documentation
parentMerge tag 'v4.20-rc7' into next-general (diff)
parentima: Use inode_is_open_for_write (diff)
downloadlinux-5580b4a1a8ca85c53bd5b94c5d302e47dca3e5cb.tar.xz
linux-5580b4a1a8ca85c53bd5b94c5d302e47dca3e5cb.zip
Merge branch 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next-integrity
From Mimi: In Linux 4.19, a new LSM hook named security_kernel_load_data was upstreamed, allowing LSMs and IMA to prevent the kexec_load syscall.  Different signature verification methods exist for verifying the kexec'ed kernel image.  This pull request adds additional support in IMA to prevent loading unsigned kernel images via the kexec_load syscall, independently of the IMA policy rules, based on the runtime "secure boot" flag.  An initial IMA kselftest is included. In addition, this pull request defines a new, separate keyring named ".platform" for storing the preboot/firmware keys needed for verifying the kexec'ed kernel image's signature and includes the associated IMA kexec usage of the ".platform" keyring. (David Howell's and Josh Boyer's patches for reading the preboot/firmware keys, which were previously posted for a different use case scenario, are included here.)
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/security/keys/trusted-encrypted.rst31
1 files changed, 30 insertions, 1 deletions
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 3bb24e09a332..6ec6bb2ac497 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -18,10 +18,33 @@ integrity verifications match. A loaded Trusted Key can be updated with new
when the kernel and initramfs are updated. The same key can have many saved
blobs under different PCR values, so multiple boots are easily supported.
+TPM 1.2
+-------
+
By default, trusted keys are sealed under the SRK, which has the default
authorization value (20 zeros). This can be set at takeownership time with the
trouser's utility: "tpm_takeownership -u -z".
+TPM 2.0
+-------
+
+The user must first create a storage key and make it persistent, so the key is
+available after reboot. This can be done using the following commands.
+
+With the IBM TSS 2 stack::
+
+ #> tsscreateprimary -hi o -st
+ Handle 80000000
+ #> tssevictcontrol -hi o -ho 80000000 -hp 81000001
+
+Or with the Intel TSS 2 stack::
+
+ #> tpm2_createprimary --hierarchy o -G rsa2048 -o key.ctxt
+ [...]
+ handle: 0x800000FF
+ #> tpm2_evictcontrol -c key.ctxt -p 0x81000001
+ persistentHandle: 0x81000001
+
Usage::
keyctl add trusted name "new keylen [options]" ring
@@ -30,7 +53,9 @@ Usage::
keyctl print keyid
options:
- keyhandle= ascii hex value of sealing key default 0x40000000 (SRK)
+ keyhandle= ascii hex value of sealing key
+ TPM 1.2: default 0x40000000 (SRK)
+ TPM 2.0: no default; must be passed every time
keyauth= ascii hex auth for sealing key default 0x00...i
(40 ascii zeros)
blobauth= ascii hex auth for sealed data default 0x00...
@@ -84,6 +109,10 @@ Examples of trusted and encrypted key usage:
Create and save a trusted key named "kmk" of length 32 bytes::
+Note: When using a TPM 2.0 with a persistent key with handle 0x81000001,
+append 'keyhandle=0x81000001' to statements between quotes, such as
+"new 32 keyhandle=0x81000001".
+
$ keyctl add trusted kmk "new 32" @u
440502848