#
28c5f596 |
|
03-Apr-2024 |
David Gstir <david@sigma-star.at> |
docs: trusted-encrypted: add DCP as new trust source 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>
|
#
50709576 |
|
27-Nov-2023 |
Sumit Garg <sumit.garg@linaro.org> |
Documentation: Destage TEE subsystem documentation 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
|
#
5adedd42 |
|
19-Oct-2022 |
Nikolaus Voss <nikolaus.voss@haag-streit.com> |
KEYS: encrypted: fix key instantiation with user-provided data 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>
|
#
5002426e |
|
13-May-2022 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
doc: trusted-encrypted: describe new CAAM trust source 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>
|
#
fcd7c269 |
|
13-May-2022 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
KEYS: trusted: allow use of kernel RNG for key material 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>
|
#
cd3bc044 |
|
15-Feb-2022 |
Yael Tzur <yaelt@google.com> |
KEYS: encrypted: Instantiate key with user-provided decrypted data 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>
|
#
c429805f |
|
01-Mar-2021 |
Sumit Garg <sumit.garg@linaro.org> |
doc: trusted-encrypted: updates with TEE as a new trust source 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>
|
#
f2219745 |
|
27-Jan-2021 |
James Bottomley <James.Bottomley@HansenPartnership.com> |
security: keys: trusted: use ASN.1 TPM2 key format for the blobs 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>
|
#
bb84bc51 |
|
21-Aug-2020 |
Coly Li <colyli@suse.de> |
docs: trusted-encrypted.rst: update parameters for command examples 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>
|
#
b216685b |
|
07-Jul-2020 |
Randy Dunlap <rdunlap@infradead.org> |
Documentation: security/keys: eliminate duplicated word 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>
|
#
6ad8b216 |
|
07-Jun-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
docs: security: trusted-encrypted.rst: fix code-block tag 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>
|
#
9db67581 |
|
04-Dec-2018 |
Dave Jiang <dave.jiang@intel.com> |
keys-encrypted: add nvdimm key format type to encrypted keys 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>
|
#
4264f27a |
|
19-Oct-2018 |
Stefan Berger <stefanb@linux.ibm.com> |
docs: Extend trusted keys documentation for TPM 2.0 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>
|
#
adf31eeb |
|
19-Aug-2017 |
Josh Holland <anowlcalledjosh@gmail.com> |
docs: Fix paths in security/keys 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>
|
#
5395d312 |
|
13-May-2017 |
Kees Cook <keescook@chromium.org> |
doc: ReSTify keys-trusted-encrypted.txt 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>
|