diff options
author | James Morris <james.morris@microsoft.com> | 2018-12-17 20:26:46 +0100 |
---|---|---|
committer | James Morris <james.morris@microsoft.com> | 2018-12-17 20:26:46 +0100 |
commit | 5580b4a1a8ca85c53bd5b94c5d302e47dca3e5cb (patch) | |
tree | 69597129504be73e8826be9984e05d073a5c47b5 /Documentation | |
parent | Merge tag 'v4.20-rc7' into next-general (diff) | |
parent | ima: Use inode_is_open_for_write (diff) | |
download | linux-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.rst | 31 |
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 |