Changes in Kconfig

2e8a0f40 - KEYS: trusted: Introduce NXP DCP-backed trusted keys

Wed, 03 Apr 2024 07:21:19 +0000

KEYS: trusted: Introduce NXP DCP-backed trusted keysDCP (Data Co-Processor) is the little brother of NXP's CAAM IP.Beside of accelerated crypto operations, it also offers support forhardware-bound keys. Using this feature it is possible to implement a blobmechanism similar to what CAAM offers. Unlike on CAAM, constructing andparsing the blob has to happen in software (i.e. the kernel).The software-based blob format used by DCP trusted keys encryptsthe payload using AES-128-GCM with a freshly generated random key and nonce.The random key itself is AES-128-ECB encrypted using the DCP uniqueor OTP key.The DCP trusted key blob format is:/* * struct dcp_blob_fmt - DCP BLOB format. * * @fmt_version: Format version, currently being %1 * @blob_key: Random AES 128 key which is used to encrypt @payload, * @blob_key itself is encrypted with OTP or UNIQUE device key in * AES-128-ECB mode by DCP. * @nonce: Random nonce used for @payload encryption. * @payload_len: Length of the plain text @payload. * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key, * GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it. * * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len + * AES_BLOCK_SIZE. */struct dcp_blob_fmt { __u8 fmt_version; __u8 blob_key[AES_KEYSIZE_128]; __u8 nonce[AES_KEYSIZE_128]; __le32 payload_len; __u8 payload[];} __packed;By default the unique key is used. It is also possible to use theOTP key. While the unique key should be unique it is not documented howthis key is derived. Therefore selection the OTP key is supported aswell via the use_otp_key module parameter.Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/security/keys/trusted-keys/Kconfig

633cb72f - KEYS: trusted: improve scalability of trust source config

Wed, 03 Apr 2024 07:21:18 +0000

KEYS: trusted: improve scalability of trust source configEnabling trusted keys requires at least one trust source implementation(currently TPM, TEE or CAAM) to be enabled. Currently, this isdone by checking each trust source's config option individually.This does not scale when more trust sources like the one for DCPare added, because the condition will get long and hard to read.Add config HAVE_TRUSTED_KEYS which is set to true by each trust sourceonce its enabled and adapt the check for having at least one active trustsource to use this option. Whenever a new trust source is added, it nowneeds to select HAVE_TRUSTED_KEYS.Signed-off-by: David Gstir Tested-by: Jarkko Sakkinen # for TRUSTED_KEYS_TPMReviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/security/keys/trusted-keys/Kconfig

e9c5048c - KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

Fri, 13 May 2022 14:57:03 +0000

KEYS: trusted: Introduce support for NXP CAAM-based trusted keysThe Cryptographic Acceleration and Assurance Module (CAAM) is an IP corebuilt into many newer i.MX and QorIQ SoCs by NXP.The CAAM does crypto acceleration, hardware number generation andhas a blob mechanism for encapsulation/decapsulation of sensitive material.This blob mechanism depends on a device specific random 256-bit One TimeProgrammable Master Key that is fused in each SoC at manufacturingtime. This key is unreadable and can only be used by the CAAM for AESencryption/decryption of user data.This makes it a suitable backend (source) for kernel trusted keys.Previous commits generalized trusted keys to support multiple backendsand added an API to access the CAAM blob mechanism. Based on these,provide the necessary glue to use the CAAM for trusted keys.Reviewed-by: David Gstir Reviewed-by: Pankaj Gupta Reviewed-by: Jarkko Sakkinen Tested-by: Tim Harvey Tested-by: Matthias Schiffer Tested-by: Pankaj Gupta Tested-by: Michael Walle # on ls1028a (non-E and E)Tested-by: John Ernberg # iMX8QXPSigned-off-by: Ahmad Fatoum Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/security/keys/trusted-keys/Kconfig

be07858f - KEYS: trusted: allow use of TEE as backend without TCG_TPM support

Fri, 13 May 2022 14:56:59 +0000

KEYS: trusted: allow use of TEE as backend without TCG_TPM supportWith recent rework, trusted keys are no longer limited to TPM as trustsource. The Kconfig symbol is unchanged however leading to a few issues: - TCG_TPM is required, even if only TEE is to be used - Enabling TCG_TPM, but excluding it from available trusted sources is not possible - TEE=m && TRUSTED_KEYS=y will lead to TEE support being silently dropped, which is not the best user experienceRemedy these issues by introducing two new boolean Kconfig symbols:TRUSTED_KEYS_TPM and TRUSTED_KEYS_TEE with the appropriatedependencies.Any new code depending on the TPM trusted key backend in particularor symbols exported by it will now need to explicitly state that it depends on TRUSTED_KEYS && TRUSTED_KEYS_TPMThe latter to ensure the dependency is built and the former to ensureit's reachable for module builds. There are no such users yet.Reviewed-by: Sumit Garg Reviewed-by: Jarkko Sakkinen Reviewed-by: Pankaj Gupta Tested-by: Pankaj Gupta Tested-by: Andreas Rammhold Tested-by: Tim Harvey Tested-by: Michael Walle # on ls1028a (non-E and E)Tested-by: John Ernberg # iMX8QXPSigned-off-by: Ahmad Fatoum Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/security/keys/trusted-keys/Kconfig