summaryrefslogtreecommitdiff
path: root/Documentation/security/keys/trusted-encrypted.rst
AgeCommit message (Collapse)Author
2024-05-09docs: trusted-encrypted: add DCP as new trust sourceDavid Gstir
Update the documentation for trusted and encrypted KEYS with DCP as new trust source: - Describe security properties of DCP trust source - Describe key usage - Document blob format Co-developed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Richard Weinberger <richard@nod.at> Co-developed-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at> Signed-off-by: David Gstir <david@sigma-star.at> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-12-08Documentation: Destage TEE subsystem documentationSumit Garg
Add a separate documentation directory for TEE subsystem since it is a standalone subsystem which already offers devices consumed by multiple different subsystem drivers. Split overall TEE subsystem documentation modularly where: - The userspace API has been moved to Documentation/userspace-api/tee.rst. - The driver API has been moved to Documentation/driver-api/tee.rst. - The first module covers the overview of TEE subsystem. - The further modules are dedicated to different TEE implementations like: - OP-TEE - AMD-TEE - and so on for future TEE implementation support. Acked-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20231128072352.866859-1-sumit.garg@linaro.org
2022-10-19KEYS: encrypted: fix key instantiation with user-provided dataNikolaus Voss
Commit cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") added key instantiation with user provided decrypted data. The user data is hex-ascii-encoded but was just memcpy'ed to the binary buffer. Fix this to use hex2bin instead. Old keys created from user provided decrypted data saved with "keyctl pipe" are still valid, however if the key is recreated from decrypted data the old key must be converted to the correct format. This can be done with a small shell script, e.g.: BROKENKEY=abcdefABCDEF1234567890aaaaaaaaaa NEWKEY=$(echo -ne $BROKENKEY | xxd -p -c32) keyctl add user masterkey "$(cat masterkey.bin)" @u keyctl add encrypted testkey "new user:masterkey 32 $NEWKEY" @u However, NEWKEY is still broken: If for BROKENKEY 32 bytes were specified, a brute force attacker knowing the key properties would only need to try at most 2^(16*8) keys, as if the key was only 16 bytes long. The security issue is a result of the combination of limiting the input range to hex-ascii and using memcpy() instead of hex2bin(). It could have been fixed either by allowing binary input or using hex2bin() (and doubling the ascii input key length). This patch implements the latter. The corresponding test for the Linux Test Project ltp has also been fixed (see link below). Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") Cc: stable@kernel.org Link: https://lore.kernel.org/ltp/20221006081709.92303897@mail.steuer-voss.de/ Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Nikolaus Voss <nikolaus.voss@haag-streit.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-05-23doc: trusted-encrypted: describe new CAAM trust sourceAhmad Fatoum
Update documentation for trusted key use with the Cryptographic Acceleration and Assurance Module (CAAM), an IP on NXP SoCs. Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23KEYS: trusted: allow use of kernel RNG for key materialAhmad Fatoum
The two existing trusted key sources don't make use of the kernel RNG, but instead let the hardware doing the sealing/unsealing also generate the random key material. However, both users and future backends may want to place less trust into the quality of the trust source's random number generator and instead reuse the kernel entropy pool, which can be seeded from multiple entropy sources. Make this possible by adding a new trusted.rng parameter, that will force use of the kernel RNG. In its absence, it's up to the trust source to decide, which random numbers to use, maintaining the existing behavior. Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Acked-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: David Gstir <david@sigma-star.at> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-02-21KEYS: encrypted: Instantiate key with user-provided decrypted dataYael Tzur
For availability and performance reasons master keys often need to be released outside of a Key Management Service (KMS) to clients. It would be beneficial to provide a mechanism where the wrapping/unwrapping of data encryption keys (DEKs) is not dependent on a remote call at runtime yet security is not (or only minimally) compromised. Master keys could be securely stored in the Kernel and be used to wrap/unwrap keys from Userspace. The encrypted.c class supports instantiation of encrypted keys with either an already-encrypted key material, or by generating new key material based on random numbers. This patch defines a new datablob format: [<format>] <master-key name> <decrypted data length> <decrypted data> that allows to inject and encrypt user-provided decrypted data. The decrypted data must be hex-ascii encoded. Signed-off-by: Yael Tzur <yaelt@google.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-04-14doc: trusted-encrypted: updates with TEE as a new trust sourceSumit Garg
Update documentation for Trusted and Encrypted Keys with TEE as a new trust source. Following is brief description of updates: - Add a section to demonstrate a list of supported devices along with their security properties/guarantees. - Add a key generation section. - Updates for usage section including differences specific to a trust source. Co-developed-by: Elaine Palmer <erpalmer@us.ibm.com> Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2021-04-14security: keys: trusted: use ASN.1 TPM2 key format for the blobsJames Bottomley
Modify the TPM2 key format blob output to export and import in the ASN.1 form for TPM2 sealed object keys. For compatibility with prior trusted keys, the importer will also accept two TPM2B quantities representing the public and private parts of the key. However, the export via keyctl pipe will only output the ASN.1 format. The benefit of the ASN.1 format is that it's a standard and thus the exported key can be used by userspace tools (openssl_tpm2_engine, openconnect and tpm2-tss-engine). The format includes policy specifications, thus it gets us out of having to construct policy handles in userspace and the format includes the parent meaning you don't have to keep passing it in each time. This patch only implements basic handling for the ASN.1 format, so keys with passwords but no policy. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2020-09-09docs: trusted-encrypted.rst: update parameters for command examplesColy Li
The parameters in command examples for tpm2_createprimary and tpm2_evictcontrol are outdated, people (like me) are not able to create trusted key by these command examples. This patch updates the parameters of command example tpm2_createprimary and tpm2_evictcontrol in trusted-encrypted.rst. With Linux kernel v5.8 and tpm2-tools-4.1, people can create a trusted key by following the examples in this document. Signed-off-by: Coly Li <colyli@suse.de> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Mimi Zohar <zohar@linux.ibm.com> Cc: Peter Huewe <peterhuewe@gmx.de> Link: https://lore.kernel.org/r/20200821135356.15737-1-colyli@suse.de Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-07-13Documentation: security/keys: eliminate duplicated wordRandy Dunlap
Drop the doubled word "in". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: Mimi Zohar <zohar@linux.ibm.com> Cc: linux-integrity@vger.kernel.org Cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20200707180414.10467-19-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-06-08docs: security: trusted-encrypted.rst: fix code-block tagMauro Carvalho Chehab
The code-block tag is at the wrong place, causing those warnings: Documentation/security/keys/trusted-encrypted.rst:112: WARNING: Literal block expected; none found. Documentation/security/keys/trusted-encrypted.rst:121: WARNING: Unexpected indentation. Documentation/security/keys/trusted-encrypted.rst:122: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/security/keys/trusted-encrypted.rst:123: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: James Morris <jamorris@linux.microsoft.com> Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-01-02Merge branch 'next-integrity' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull integrity updates from James Morris: "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 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)" * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: integrity: Remove references to module keyring ima: Use inode_is_open_for_write ima: Support platform keyring for kernel appraisal efi: Allow the "db" UEFI variable to be suppressed efi: Import certificates from UEFI Secure Boot efi: Add an EFI signature blob parser efi: Add EFI signature data types integrity: Load certs to the platform keyring integrity: Define a trusted platform keyring selftests/ima: kexec_load syscall test ima: don't measure/appraise files on efivarfs x86/ima: retry detecting secure boot mode docs: Extend trusted keys documentation for TPM 2.0 x86/ima: define arch_get_ima_policy() for x86 ima: add support for arch specific policies ima: refactor ima_init_policy() ima: prevent kexec_load syscall based on runtime secureboot flag x86/ima: define arch_ima_get_secureboot integrity: support new struct public_key_signature encoding field
2018-12-13keys-encrypted: add nvdimm key format type to encrypted keysDave Jiang
Adding nvdimm key format type to encrypted keys in order to limit the size of the key to 32bytes. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-12-11docs: Extend trusted keys documentation for TPM 2.0Stefan Berger
Extend the documentation for trusted keys with documentation for how to set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2017-08-24docs: Fix paths in security/keysJosh Holland
Several paths in the security/keys documentation were incorrect. Signed-off-by: Josh Holland <anowlcalledjosh@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2017-05-18doc: ReSTify keys-trusted-encrypted.txtKees Cook
Adjusts for ReST markup and moves under keys security devel index. Cc: David Howells <dhowells@redhat.com> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>