| Message ID | 319e558e1bd19b80ad6447c167a2c3942bdafea2.1615914058.git-series.a.fatoum@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KEYS: trusted: Introduce support for NXP CAAM-based trusted keys | expand |
On Tue, Mar 16, 2021 at 06:01:18PM +0100, Ahmad Fatoum wrote: > The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core > built into many newer i.MX and QorIQ SoCs by NXP. > > The CAAM does crypto acceleration, hardware number generation and > has a blob mechanism for encapsulation/decapsulation of sensitive material. > > This blob mechanism depends on a device specific random 256-bit One Time > Programmable Master Key that is fused in each SoC at manufacturing > time. This key is unreadable and can only be used by the CAAM for AES > encryption/decryption of user data. > > This makes it a suitable backend (source) for kernel trusted keys. > > Previous commits generalized trusted keys to support multiple backends > and added an API to access the CAAM blob mechanism. Based on these, > provide the necessary glue to use the CAAM for trusted keys. > > Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > --- > To: Jonathan Corbet <corbet@lwn.net> > To: David Howells <dhowells@redhat.com> > To: Jarkko Sakkinen <jarkko@kernel.org> > To: James Bottomley <jejb@linux.ibm.com> > To: Mimi Zohar <zohar@linux.ibm.com> > Cc: James Morris <jmorris@namei.org> > Cc: "Serge E. Hallyn" <serge@hallyn.com> > Cc: "Horia Geantă" <horia.geanta@nxp.com> > Cc: Aymen Sghaier <aymen.sghaier@nxp.com> > Cc: Herbert Xu <herbert@gondor.apana.org.au> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Udit Agarwal <udit.agarwal@nxp.com> > Cc: Jan Luebbe <j.luebbe@penutronix.de> > Cc: David Gstir <david@sigma-star.at> > Cc: Franck LENORMAND <franck.lenormand@nxp.com> > Cc: Sumit Garg <sumit.garg@linaro.org> > Cc: keyrings@vger.kernel.org > Cc: linux-crypto@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-integrity@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-security-module@vger.kernel.org > --- > Documentation/admin-guide/kernel-parameters.txt | 1 +- > include/keys/trusted_caam.h | 11 +++- > security/keys/trusted-keys/Makefile | 1 +- > security/keys/trusted-keys/trusted_caam.c | 74 ++++++++++++++++++- > security/keys/trusted-keys/trusted_core.c | 6 +- > 5 files changed, 92 insertions(+), 1 deletion(-) > create mode 100644 include/keys/trusted_caam.h > create mode 100644 security/keys/trusted-keys/trusted_caam.c > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index c8bad1762cba..382e911389aa 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5469,6 +5469,7 @@ > sources: > - "tpm" > - "tee" > + - "caam" > If not specified then it defaults to iterating through > the trust source list starting with TPM and assigns the > first trust source as a backend which is initialized > diff --git a/include/keys/trusted_caam.h b/include/keys/trusted_caam.h > new file mode 100644 > index 000000000000..2fba0996b0b0 > --- /dev/null > +++ b/include/keys/trusted_caam.h > @@ -0,0 +1,11 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de> > + */ > + > +#ifndef __CAAM_TRUSTED_KEY_H > +#define __CAAM_TRUSTED_KEY_H > + > +extern struct trusted_key_ops caam_trusted_key_ops; > + > +#endif > diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile > index feb8b6c3cc79..050370690abd 100644 > --- a/security/keys/trusted-keys/Makefile > +++ b/security/keys/trusted-keys/Makefile > @@ -12,3 +12,4 @@ trusted-y += trusted_tpm2.o > trusted-y += tpm2key.asn1.o > > trusted-$(CONFIG_TEE) += trusted_tee.o > +trusted-$(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) += trusted_caam.o > diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c > new file mode 100644 > index 000000000000..fc2e3dde9e06 > --- /dev/null > +++ b/security/keys/trusted-keys/trusted_caam.c > @@ -0,0 +1,74 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de> > + */ > + > +#include <keys/trusted_caam.h> > +#include <keys/trusted-type.h> > +#include <linux/build_bug.h> > +#include <linux/key-type.h> > +#include <soc/fsl/caam-blob.h> > + > +struct caam_blob_priv *blobifier; > + > +#define KEYMOD "kernel:trusted" > + > +static_assert(MAX_KEY_SIZE + CAAM_BLOB_OVERHEAD <= CAAM_BLOB_MAX_LEN); > +static_assert(MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN); > + > +static int trusted_caam_seal(struct trusted_key_payload *p, char *datablob) > +{ > + int length = p->key_len + CAAM_BLOB_OVERHEAD; > + int ret; > + > + ret = caam_encap_blob(blobifier, KEYMOD, p->key, p->blob, length); > + if (ret) > + return ret; > + > + p->blob_len = length; > + return 0; > +} > + > +static int trusted_caam_unseal(struct trusted_key_payload *p, char *datablob) > +{ > + int length = p->blob_len; > + int ret; > + > + ret = caam_decap_blob(blobifier, KEYMOD, p->blob, p->key, length); > + if (ret) > + return ret; > + > + p->key_len = length - CAAM_BLOB_OVERHEAD; > + return 0; > +} > + > +static int trusted_caam_init(void) > +{ > + int ret; > + > + blobifier = caam_blob_gen_init(); > + if (IS_ERR(blobifier)) { > + pr_err("Job Ring Device allocation for transform failed\n"); > + return PTR_ERR(blobifier); > + } > + > + ret = register_key_type(&key_type_trusted); > + if (ret) > + caam_blob_gen_exit(blobifier); > + > + return ret; > +} > + > +static void trusted_caam_exit(void) > +{ > + unregister_key_type(&key_type_trusted); > + caam_blob_gen_exit(blobifier); > +} > + > +struct trusted_key_ops caam_trusted_key_ops = { > + .migratable = 0, /* non-migratable */ > + .init = trusted_caam_init, > + .seal = trusted_caam_seal, > + .unseal = trusted_caam_unseal, > + .exit = trusted_caam_exit, > +}; > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c > index 5f92323efedf..e9bfb1bbc014 100644 > --- a/security/keys/trusted-keys/trusted_core.c > +++ b/security/keys/trusted-keys/trusted_core.c > @@ -9,6 +9,7 @@ > #include <keys/user-type.h> > #include <keys/trusted-type.h> > #include <keys/trusted_tee.h> > +#include <keys/trusted_caam.h> > #include <keys/trusted_tpm.h> > #include <linux/capability.h> > #include <linux/err.h> > @@ -25,7 +26,7 @@ > > static char *trusted_key_source; > module_param_named(source, trusted_key_source, charp, 0); > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); > > static const struct trusted_key_source trusted_key_sources[] = { > #if defined(CONFIG_TCG_TPM) > @@ -34,6 +35,9 @@ static const struct trusted_key_source trusted_key_sources[] = { > #if defined(CONFIG_TEE) > { "tee", &trusted_key_tee_ops }, > #endif > +#if defined(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) > + { "caam", &caam_trusted_key_ops }, > +#endif > }; > > DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init); > -- > git-series 0.9.1 > Too early to ack, as I've not included the TEE thing to any PR yet. /Jarkko
Ahmad, On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > +#include <keys/trusted_caam.h> > +#include <keys/trusted-type.h> > +#include <linux/build_bug.h> > +#include <linux/key-type.h> > +#include <soc/fsl/caam-blob.h> > + > +struct caam_blob_priv *blobifier; Who is using this pointer too? Otherwise I'd suggest marking it static. > module_param_named(source, trusted_key_source, charp, 0); > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); I didn't closely follow the previous discussions, but is a module parameter really the right approach? Is there also a way to set it via something like device tree?
Hi Richard, On Wed, 17 Mar 2021 at 04:45, Richard Weinberger <richard.weinberger@gmail.com> wrote: > > Ahmad, > > On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > +#include <keys/trusted_caam.h> > > +#include <keys/trusted-type.h> > > +#include <linux/build_bug.h> > > +#include <linux/key-type.h> > > +#include <soc/fsl/caam-blob.h> > > + > > +struct caam_blob_priv *blobifier; > > Who is using this pointer too? > Otherwise I'd suggest marking it static. > > > module_param_named(source, trusted_key_source, charp, 0); > > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); > > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); > > I didn't closely follow the previous discussions, but is a module > parameter really the right approach? > Is there also a way to set it via something like device tree? > It's there to support a platform which possesses multiple trusted keys backends. So that a user is able to select during boot which one to use as a backend. -Sumit > -- > Thanks, > //richard
Sumit, ----- Ursprüngliche Mail ----- >> > module_param_named(source, trusted_key_source, charp, 0); >> > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); >> > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); >> >> I didn't closely follow the previous discussions, but is a module >> parameter really the right approach? >> Is there also a way to set it via something like device tree? >> > > It's there to support a platform which possesses multiple trusted keys > backends. So that a user is able to select during boot which one to > use as a backend. I understand the use case, my question was whether it makes actually sense to have a module parameter for it, or additionally another way to define the preferred backend. Thanks, //richard
Hello Jarkko, On 16.03.21 20:22, Jarkko Sakkinen wrote: > On Tue, Mar 16, 2021 at 06:01:18PM +0100, Ahmad Fatoum wrote: >> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core >> built into many newer i.MX and QorIQ SoCs by NXP. >> >> The CAAM does crypto acceleration, hardware number generation and >> has a blob mechanism for encapsulation/decapsulation of sensitive material. >> >> This blob mechanism depends on a device specific random 256-bit One Time >> Programmable Master Key that is fused in each SoC at manufacturing >> time. This key is unreadable and can only be used by the CAAM for AES >> encryption/decryption of user data. >> >> This makes it a suitable backend (source) for kernel trusted keys. >> >> Previous commits generalized trusted keys to support multiple backends >> and added an API to access the CAAM blob mechanism. Based on these, >> provide the necessary glue to use the CAAM for trusted keys. >> >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > Too early to ack, as I've not included the TEE thing to any PR yet. No problem. I'd be happy to incorporate the feedback I receive in the meantime. Cheers, Ahmad
Hello Richard, On 17.03.21 00:14, Richard Weinberger wrote: > Ahmad, > > On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: >> +#include <keys/trusted_caam.h> >> +#include <keys/trusted-type.h> >> +#include <linux/build_bug.h> >> +#include <linux/key-type.h> >> +#include <soc/fsl/caam-blob.h> >> + >> +struct caam_blob_priv *blobifier; > > Who is using this pointer too? > Otherwise I'd suggest marking it static. You're right. Will do in v2. >> module_param_named(source, trusted_key_source, charp, 0); >> -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); >> +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); > > I didn't closely follow the previous discussions, but is a module > parameter really the right approach? > Is there also a way to set it via something like device tree? Compiled-on sources are considered in the order: tpm, tee then caam. Module parameters are the only override currently available.
On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: [...] > +struct trusted_key_ops caam_trusted_key_ops = { > + .migratable = 0, /* non-migratable */ > + .init = trusted_caam_init, > + .seal = trusted_caam_seal, > + .unseal = trusted_caam_unseal, > + .exit = trusted_caam_exit, > +}; caam has random number generation capabilities, so it's worth using that by implementing .get_random. Horia
Hello Horia, On 21.03.21 21:48, Horia Geantă wrote: > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: > [...] >> +struct trusted_key_ops caam_trusted_key_ops = { >> + .migratable = 0, /* non-migratable */ >> + .init = trusted_caam_init, >> + .seal = trusted_caam_seal, >> + .unseal = trusted_caam_unseal, >> + .exit = trusted_caam_exit, >> +}; > caam has random number generation capabilities, so it's worth using that > by implementing .get_random. If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? Makes for less code duplication IMO. > > Horia >
On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > Hello Horia, > > On 21.03.21 21:48, Horia Geantă wrote: > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: > > [...] > >> +struct trusted_key_ops caam_trusted_key_ops = { > >> + .migratable = 0, /* non-migratable */ > >> + .init = trusted_caam_init, > >> + .seal = trusted_caam_seal, > >> + .unseal = trusted_caam_unseal, > >> + .exit = trusted_caam_exit, > >> +}; > > caam has random number generation capabilities, so it's worth using that > > by implementing .get_random. > > If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? > > Makes for less code duplication IMO. Using kernel RNG, in general, for trusted keys has been discussed before. Please refer to Dave Safford's detailed explanation for not using it [1]. thanks, Mimi [1] https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/
Hello Mimi, On 23.03.21 19:07, Mimi Zohar wrote: > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: >> On 21.03.21 21:48, Horia Geantă wrote: >>> caam has random number generation capabilities, so it's worth using that >>> by implementing .get_random. >> >> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? >> >> Makes for less code duplication IMO. > > Using kernel RNG, in general, for trusted keys has been discussed > before. Please refer to Dave Safford's detailed explanation for not > using it [1]. The argument seems to boil down to: - TPM RNG are known to be of good quality - Trusted keys always used it so far Both are fine by me for TPMs, but the CAAM backend is new code and neither point really applies. get_random_bytes_wait is already used for generating key material elsewhere. Why shouldn't new trusted key backends be able to do the same thing? Cheers, Ahmad > > thanks, > > Mimi > > [1] > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ > > >
On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > Hello Mimi, > > On 23.03.21 19:07, Mimi Zohar wrote: > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > >> On 21.03.21 21:48, Horia Geantă wrote: > >>> caam has random number generation capabilities, so it's worth using that > >>> by implementing .get_random. > >> > >> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? > >> > >> Makes for less code duplication IMO. > > > > Using kernel RNG, in general, for trusted keys has been discussed > > before. Please refer to Dave Safford's detailed explanation for not > > using it [1]. > > The argument seems to boil down to: > > - TPM RNG are known to be of good quality > - Trusted keys always used it so far > > Both are fine by me for TPMs, but the CAAM backend is new code and neither point > really applies. > > get_random_bytes_wait is already used for generating key material elsewhere. > Why shouldn't new trusted key backends be able to do the same thing? > Please refer to documented trusted keys behaviour here [1]. New trusted key backends should align to this behaviour and in your case CAAM offers HWRNG so we should be better using that. Also, do update documentation corresponding to CAAM as a trusted keys backend. [1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/Documentation/security/keys/trusted-encrypted.rst#n87 -Sumit > Cheers, > Ahmad > > > > > thanks, > > > > Mimi > > > > [1] > > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ > > > > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hello Sumit, On 24.03.21 11:47, Sumit Garg wrote: > On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: >> >> Hello Mimi, >> >> On 23.03.21 19:07, Mimi Zohar wrote: >>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: >>>> On 21.03.21 21:48, Horia Geantă wrote: >>>>> caam has random number generation capabilities, so it's worth using that >>>>> by implementing .get_random. >>>> >>>> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? >>>> >>>> Makes for less code duplication IMO. >>> >>> Using kernel RNG, in general, for trusted keys has been discussed >>> before. Please refer to Dave Safford's detailed explanation for not >>> using it [1]. >> >> The argument seems to boil down to: >> >> - TPM RNG are known to be of good quality >> - Trusted keys always used it so far >> >> Both are fine by me for TPMs, but the CAAM backend is new code and neither point >> really applies. >> >> get_random_bytes_wait is already used for generating key material elsewhere. >> Why shouldn't new trusted key backends be able to do the same thing? >> > > Please refer to documented trusted keys behaviour here [1]. New > trusted key backends should align to this behaviour and in your case > CAAM offers HWRNG so we should be better using that. Why is it better? Can you explain what benefit a CAAM user would have if the trusted key randomness comes directly out of the CAAM instead of indirectly from the kernel entropy pool that is seeded by it? > Also, do update documentation corresponding to CAAM as a trusted keys backend. Yes. The documentation should be updated for CAAM and it should describe how the key material is derived. Will do so for v2. Cheers, Ahmad > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/Documentation/security/keys/trusted-encrypted.rst#n87 > > -Sumit > >> Cheers, >> Ahmad >> >>> >>> thanks, >>> >>> Mimi >>> >>> [1] >>> https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ >>> >>> >>> >> >> -- >> Pengutronix e.K. | | >> Steuerwalder Str. 21 | http://www.pengutronix.de/ | >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | >
On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote: > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > > Hello Horia, > > > > On 21.03.21 21:48, Horia Geantă wrote: > > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: > > > [...] > > > > +struct trusted_key_ops caam_trusted_key_ops = { > > > > + .migratable = 0, /* non-migratable */ > > > > + .init = trusted_caam_init, > > > > + .seal = trusted_caam_seal, > > > > + .unseal = trusted_caam_unseal, > > > > + .exit = trusted_caam_exit, > > > > +}; > > > caam has random number generation capabilities, so it's worth > > > using that > > > by implementing .get_random. > > > > If the CAAM HWRNG is already seeding the kernel RNG, why not use > > the kernel's? > > > > Makes for less code duplication IMO. > > Using kernel RNG, in general, for trusted keys has been discussed > before. Please refer to Dave Safford's detailed explanation for not > using it [1]. > > thanks, > > Mimi > > [1] > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ I still don't think relying on one source of randomness to be cryptographically secure is a good idea. The fear of bugs in the kernel entropy pool is reasonable, but since it's widely used they're unlikely to persist very long. Studies have shown that some TPMs (notably the chinese manufactured ones) have suspicious failures in their RNGs: https://www.researchgate.net/publication/45934562_Benchmarking_the_True_Random_Number_Generator_of_TPM_Chips And most cryptograhpers recommend using a TPM for entropy mixing rather than directly: https://blog.cryptographyengineering.com/category/rngs/ The TPMFail paper also shows that in spite of NIST certification things can go wrong with a TPM: https://tpm.fail/ James
On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote: > On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote: > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > > > Hello Horia, > > > > > > On 21.03.21 21:48, Horia Geantă wrote: > > > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: > > > > [...] > > > > > +struct trusted_key_ops caam_trusted_key_ops = { > > > > > + .migratable = 0, /* non-migratable */ > > > > > + .init = trusted_caam_init, > > > > > + .seal = trusted_caam_seal, > > > > > + .unseal = trusted_caam_unseal, > > > > > + .exit = trusted_caam_exit, > > > > > +}; > > > > caam has random number generation capabilities, so it's worth > > > > using that > > > > by implementing .get_random. > > > > > > If the CAAM HWRNG is already seeding the kernel RNG, why not use > > > the kernel's? > > > > > > Makes for less code duplication IMO. > > > > Using kernel RNG, in general, for trusted keys has been discussed > > before. Please refer to Dave Safford's detailed explanation for not > > using it [1]. > > > > [1] > > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ > > I still don't think relying on one source of randomness to be > cryptographically secure is a good idea. The fear of bugs in the > kernel entropy pool is reasonable, but since it's widely used they're > unlikely to persist very long. Studies have shown that some TPMs > (notably the chinese manufactured ones) have suspicious failures in > their RNGs: > > https://www.researchgate.net/publication/45934562_Benchmarking_the_True_Random_Number_Generator_of_TPM_Chips > > And most cryptograhpers recommend using a TPM for entropy mixing rather > than directly: > > https://blog.cryptographyengineering.com/category/rngs/ > > The TPMFail paper also shows that in spite of NIST certification > things can go wrong with a TPM: > > https://tpm.fail/ We already had a lengthy discussion on replacing the TPM RNG with the kernel RNG for trusted keys, when TEE was being introduced [2,3]. I'm not interested in re-hashing that discussion here. The only difference now is that CAAM is a new trust source. I suspect the same concerns/issues persist, but at least in this case using the kernel RNG would not be a regression. [2] Pascal Van Leeuwen on mixing different sources of entropy and certification - https://lore.kernel.org/linux-integrity/MN2PR20MB29732A856A40131A671F949FCA950@MN2PR20MB2973.namprd20.prod.outlook.com/ [3] Jarrko on "regression" and tpm_asym.c - https://lore.kernel.org/linux-integrity/20191014190033.GA15552@linux.intel.com/ Mimi
On Wed, 2021-03-24 at 16:49 -0400, Mimi Zohar wrote: > On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote: > > On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote: > > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > > > > Hello Horia, > > > > > > > > On 21.03.21 21:48, Horia Geantă wrote: > > > > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: > > > > > [...] > > > > > > +struct trusted_key_ops caam_trusted_key_ops = { > > > > > > + .migratable = 0, /* non-migratable */ > > > > > > + .init = trusted_caam_init, > > > > > > + .seal = trusted_caam_seal, > > > > > > + .unseal = trusted_caam_unseal, > > > > > > + .exit = trusted_caam_exit, > > > > > > +}; > > > > > caam has random number generation capabilities, so it's worth > > > > > using that > > > > > by implementing .get_random. > > > > > > > > If the CAAM HWRNG is already seeding the kernel RNG, why not > > > > use > > > > the kernel's? > > > > > > > > Makes for less code duplication IMO. > > > > > > Using kernel RNG, in general, for trusted keys has been discussed > > > before. Please refer to Dave Safford's detailed explanation for > > > not > > > using it [1]. > > > > > > [1] > > > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ > > > > I still don't think relying on one source of randomness to be > > cryptographically secure is a good idea. The fear of bugs in the > > kernel entropy pool is reasonable, but since it's widely used > > they're > > unlikely to persist very long. Studies have shown that some TPMs > > (notably the chinese manufactured ones) have suspicious failures in > > their RNGs: > > > > https://www.researchgate.net/publication/45934562_Benchmarking_the_True_Random_Number_Generator_of_TPM_Chips > > > > And most cryptograhpers recommend using a TPM for entropy mixing > > rather > > than directly: > > > > https://blog.cryptographyengineering.com/category/rngs/ > > > > The TPMFail paper also shows that in spite of NIST certification > > things can go wrong with a TPM: > > > > https://tpm.fail/ > > We already had a lengthy discussion on replacing the TPM RNG with the > kernel RNG for trusted keys, when TEE was being introduced > [2,3]. I'm not interested in re-hashing that discussion here. The > only difference now is that CAAM is a new trust source. I suspect > the same concerns/issues persist, but at least in this case using the > kernel RNG would not be a regression. Upstreaming the ASN.1 parser gives us a way to create trusted keys outside the kernel and so choose any RNG that suits the user, so I don't think there's any need to rehash for TPM based keys either. However CaaM doesn't have the ability to create keys outside the kernel yet, so they do need to consider the problem. James > [2] Pascal Van Leeuwen on mixing different sources of entropy and > certification - > > https://lore.kernel.org/linux-integrity/MN2PR20MB29732A856A40131A671F949FCA950@MN2PR20MB2973.namprd20.prod.outlook.com/ > [3] Jarrko on "regression" and tpm_asym.c - > https://lore.kernel.org/linux-integrity/20191014190033.GA15552@linux.intel.com/ > > Mimi >
On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > Hello Sumit, > > On 24.03.21 11:47, Sumit Garg wrote: > > On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > >> > >> Hello Mimi, > >> > >> On 23.03.21 19:07, Mimi Zohar wrote: > >>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > >>>> On 21.03.21 21:48, Horia Geantă wrote: > >>>>> caam has random number generation capabilities, so it's worth using that > >>>>> by implementing .get_random. > >>>> > >>>> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? > >>>> > >>>> Makes for less code duplication IMO. > >>> > >>> Using kernel RNG, in general, for trusted keys has been discussed > >>> before. Please refer to Dave Safford's detailed explanation for not > >>> using it [1]. > >> > >> The argument seems to boil down to: > >> > >> - TPM RNG are known to be of good quality > >> - Trusted keys always used it so far > >> > >> Both are fine by me for TPMs, but the CAAM backend is new code and neither point > >> really applies. > >> > >> get_random_bytes_wait is already used for generating key material elsewhere. > >> Why shouldn't new trusted key backends be able to do the same thing? > >> > > > > Please refer to documented trusted keys behaviour here [1]. New > > trusted key backends should align to this behaviour and in your case > > CAAM offers HWRNG so we should be better using that. > > Why is it better? > > Can you explain what benefit a CAAM user would have if the trusted key > randomness comes directly out of the CAAM instead of indirectly from > the kernel entropy pool that is seeded by it? IMO, user trust in case of trusted keys comes from trusted keys backend which is CAAM here. If a user doesn't trust that CAAM would act as a reliable source for RNG then CAAM shouldn't be used as a trust source in the first place. And I think building user's trust for kernel RNG implementation with multiple entropy contributions is pretty difficult when compared with CAAM HWRNG implementation. -Sumit > > > Also, do update documentation corresponding to CAAM as a trusted keys backend. > > Yes. The documentation should be updated for CAAM and it should describe > how the key material is derived. Will do so for v2. > > Cheers, > Ahmad > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/Documentation/security/keys/trusted-encrypted.rst#n87 > > > > -Sumit > > > >> Cheers, > >> Ahmad > >> > >>> > >>> thanks, > >>> > >>> Mimi > >>> > >>> [1] > >>> https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ > >>> > >>> > >>> > >> > >> -- > >> Pengutronix e.K. | | > >> Steuerwalder Str. 21 | http://www.pengutronix.de/ | > >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi! > On 25.03.2021, at 06:26, Sumit Garg <sumit.garg@linaro.org> wrote: > > On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: >> >> Hello Sumit, >> >> On 24.03.21 11:47, Sumit Garg wrote: >>> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: >>>> >>>> Hello Mimi, >>>> >>>> On 23.03.21 19:07, Mimi Zohar wrote: >>>>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: >>>>>> On 21.03.21 21:48, Horia Geantă wrote: >>>>>>> caam has random number generation capabilities, so it's worth using that >>>>>>> by implementing .get_random. >>>>>> >>>>>> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? >>>>>> >>>>>> Makes for less code duplication IMO. >>>>> >>>>> Using kernel RNG, in general, for trusted keys has been discussed >>>>> before. Please refer to Dave Safford's detailed explanation for not >>>>> using it [1]. >>>> >>>> The argument seems to boil down to: >>>> >>>> - TPM RNG are known to be of good quality >>>> - Trusted keys always used it so far >>>> >>>> Both are fine by me for TPMs, but the CAAM backend is new code and neither point >>>> really applies. >>>> >>>> get_random_bytes_wait is already used for generating key material elsewhere. >>>> Why shouldn't new trusted key backends be able to do the same thing? >>>> >>> >>> Please refer to documented trusted keys behaviour here [1]. New >>> trusted key backends should align to this behaviour and in your case >>> CAAM offers HWRNG so we should be better using that. >> >> Why is it better? >> >> Can you explain what benefit a CAAM user would have if the trusted key >> randomness comes directly out of the CAAM instead of indirectly from >> the kernel entropy pool that is seeded by it? > > IMO, user trust in case of trusted keys comes from trusted keys > backend which is CAAM here. If a user doesn't trust that CAAM would > act as a reliable source for RNG then CAAM shouldn't be used as a > trust source in the first place. > > And I think building user's trust for kernel RNG implementation with > multiple entropy contributions is pretty difficult when compared with > CAAM HWRNG implementation. Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s other features are two separate things. However, reading through the CAAM key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s content) are generated using its internal RNG. So I’d save if the CAAM RNG is insecure, so are generated key blobs. Maybe somebody with more insight into the CAAM internals can verify that, but I don’t see any point in using the kernel’s RNG as long as we let CAAM generate the key blob keys for us. Cheers, dave
On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote: > Hi! > > > On 25.03.2021, at 06:26, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > >> > >> Hello Sumit, > >> > >> On 24.03.21 11:47, Sumit Garg wrote: > >>> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > >>>> > >>>> Hello Mimi, > >>>> > >>>> On 23.03.21 19:07, Mimi Zohar wrote: > >>>>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > >>>>>> On 21.03.21 21:48, Horia Geantă wrote: > >>>>>>> caam has random number generation capabilities, so it's worth using that > >>>>>>> by implementing .get_random. > >>>>>> > >>>>>> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? > >>>>>> > >>>>>> Makes for less code duplication IMO. > >>>>> > >>>>> Using kernel RNG, in general, for trusted keys has been discussed > >>>>> before. Please refer to Dave Safford's detailed explanation for not > >>>>> using it [1]. > >>>> > >>>> The argument seems to boil down to: > >>>> > >>>> - TPM RNG are known to be of good quality > >>>> - Trusted keys always used it so far > >>>> > >>>> Both are fine by me for TPMs, but the CAAM backend is new code and neither point > >>>> really applies. > >>>> > >>>> get_random_bytes_wait is already used for generating key material elsewhere. > >>>> Why shouldn't new trusted key backends be able to do the same thing? > >>>> > >>> > >>> Please refer to documented trusted keys behaviour here [1]. New > >>> trusted key backends should align to this behaviour and in your case > >>> CAAM offers HWRNG so we should be better using that. > >> > >> Why is it better? > >> > >> Can you explain what benefit a CAAM user would have if the trusted key > >> randomness comes directly out of the CAAM instead of indirectly from > >> the kernel entropy pool that is seeded by it? > > > > IMO, user trust in case of trusted keys comes from trusted keys > > backend which is CAAM here. If a user doesn't trust that CAAM would > > act as a reliable source for RNG then CAAM shouldn't be used as a > > trust source in the first place. > > > > And I think building user's trust for kernel RNG implementation with > > multiple entropy contributions is pretty difficult when compared with > > CAAM HWRNG implementation. > > Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s > other features are two separate things. However, reading through the CAAM > key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s > content) are generated using its internal RNG. So I’d save if the CAAM RNG > is insecure, so are generated key blobs. Maybe somebody with more insight > into the CAAM internals can verify that, but I don’t see any point in using > the kernel’s RNG as long as we let CAAM generate the key blob keys for us. Here's my long'ish analysis. Please read it to the end if by ever means possible, and apologies, I usually try to keep usually my comms short, but this requires some more meat than the usual. The Bad News ============ Now that we add multiple hardware trust sources for trusted keys, will there ever be a scenario where a trusted key is originally sealed with a backing hardware A, unsealed, and resealed with hardware B? The hardware and vendor neutral way to generate the key material would be unconditionally always just the kernel RNG. CAAM is actually worse than TCG because it's not even a standards body, if I got it right. Not a lot but at least a tiny fraction. This brings an open item in TEE patches: trusted_tee_get_random() is an issue in generating kernel material. I would rather replace that with kernel RNG *for now*, because the same open question applies also to ARM TEE. It's also a single company controlled backing technology. By all practical means, I do trust ARM TEE in my personal life but this is not important. CAAM *and* TEE backends break the golden rule of putting as little trust as possible to anything, even not anything weird is clear at sight, as security is essentially a game of known unknowns and unknown unknowns. Unfortunately, TPM trusted keys started this bad security practice, and obviously it cannot be fixed without breaking uapi backwards compatibility. This leaves me exactly two rational options: A. Add a patch to remove trusted_tee_get_random() and use kernel RNG instead. B. Drop the whole TEE patch set up until I have good reasons to believe that it's the best possible idea ever to use TEE RNG. Doing does (A) does not disclude of doing (B) later on, if someone some day sends a patch with sound reasoning. It's also good to understand that when some day a vendor D, other than TCG, CAAM or ARM, comes up, we need to go again this lenghty and messy discussion. Now this already puts an already accepted patch set into a risk, because by being a responsible maintainer I would have legit reasons just simply to drop it. OK, but.... The GOOD News ============= So there's actually option (C) that also fixes the TPM trustd keys issue: Add a new kernel patch, which: 1. Adds the use of kernel RNG as a boot option. 2. If this boot option is not active, the subsystem will print a warning to klog denoting this. 3. Default is of course vendor RNG given the bad design issue in the TPM trusted keys, but the warning in klog will help to address it at least a bit. 4. Document all this to Documentation/security/keys/trusted-encrypted.rst. I'd prefer the choice between A, B and C be concluded rather sooner than later. /Jarkko
Hello Jarkko, On 28.03.21 22:37, Jarkko Sakkinen wrote: > On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote: >> Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s >> other features are two separate things. However, reading through the CAAM >> key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s >> content) are generated using its internal RNG. So I’d save if the CAAM RNG >> is insecure, so are generated key blobs. Maybe somebody with more insight >> into the CAAM internals can verify that, but I don’t see any point in using >> the kernel’s RNG as long as we let CAAM generate the key blob keys for us. > > Here's my long'ish analysis. Please read it to the end if by ever means > possible, and apologies, I usually try to keep usually my comms short, but > this requires some more meat than the usual. Thanks for the write-up! > The Bad News > ============ > > Now that we add multiple hardware trust sources for trusted keys, will > there ever be a scenario where a trusted key is originally sealed with a > backing hardware A, unsealed, and resealed with hardware B? > > The hardware and vendor neutral way to generate the key material would be > unconditionally always just the kernel RNG. > > CAAM is actually worse than TCG because it's not even a standards body, if > I got it right. Not a lot but at least a tiny fraction. CAAM is how NXP calls the crypto accelerator built into some of its SoCs. > This brings an open item in TEE patches: trusted_tee_get_random() is an > issue in generating kernel material. I would rather replace that with > kernel RNG *for now*, because the same open question applies also to ARM > TEE. It's also a single company controlled backing technology. > > By all practical means, I do trust ARM TEE in my personal life but this is > not important. > > CAAM *and* TEE backends break the golden rule of putting as little trust as > possible to anything, even not anything weird is clear at sight, as > security is essentially a game of known unknowns and unknown unknowns. Agreed. > The GOOD News > ============= > > So there's actually option (C) that also fixes the TPM trustd keys issue: > > Add a new kernel patch, which: > > 1. Adds the use of kernel RNG as a boot option. > 2. If this boot option is not active, the subsystem will print a warning > to klog denoting this. > 3. Default is of course vendor RNG given the bad design issue in the TPM > trusted keys, but the warning in klog will help to address it at least > a bit. Why should the TPM backend's choice influence later backends? We could add a new option for key creation time, e.g.: keyctl add trusted kmk "new keylen rng=kernel" @s The default would be rng=vendor if available with a fallback to rng=kernel, which should always be available. > 4. Document all this to Documentation/security/keys/trusted-encrypted.rst. Yes, backends would then document whether they support a rng=vendor or not. > I'd prefer the choice between A, B and C be concluded rather sooner than > later. FWIW, my vote is for option C, with the change described above. Cheers, Ahmad > > /Jarkko >
On Mon, 29 Mar 2021 at 01:07, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote: > > Hi! > > > > > On 25.03.2021, at 06:26, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > >> > > >> Hello Sumit, > > >> > > >> On 24.03.21 11:47, Sumit Garg wrote: > > >>> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > >>>> > > >>>> Hello Mimi, > > >>>> > > >>>> On 23.03.21 19:07, Mimi Zohar wrote: > > >>>>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > > >>>>>> On 21.03.21 21:48, Horia Geantă wrote: > > >>>>>>> caam has random number generation capabilities, so it's worth using that > > >>>>>>> by implementing .get_random. > > >>>>>> > > >>>>>> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? > > >>>>>> > > >>>>>> Makes for less code duplication IMO. > > >>>>> > > >>>>> Using kernel RNG, in general, for trusted keys has been discussed > > >>>>> before. Please refer to Dave Safford's detailed explanation for not > > >>>>> using it [1]. > > >>>> > > >>>> The argument seems to boil down to: > > >>>> > > >>>> - TPM RNG are known to be of good quality > > >>>> - Trusted keys always used it so far > > >>>> > > >>>> Both are fine by me for TPMs, but the CAAM backend is new code and neither point > > >>>> really applies. > > >>>> > > >>>> get_random_bytes_wait is already used for generating key material elsewhere. > > >>>> Why shouldn't new trusted key backends be able to do the same thing? > > >>>> > > >>> > > >>> Please refer to documented trusted keys behaviour here [1]. New > > >>> trusted key backends should align to this behaviour and in your case > > >>> CAAM offers HWRNG so we should be better using that. > > >> > > >> Why is it better? > > >> > > >> Can you explain what benefit a CAAM user would have if the trusted key > > >> randomness comes directly out of the CAAM instead of indirectly from > > >> the kernel entropy pool that is seeded by it? > > > > > > IMO, user trust in case of trusted keys comes from trusted keys > > > backend which is CAAM here. If a user doesn't trust that CAAM would > > > act as a reliable source for RNG then CAAM shouldn't be used as a > > > trust source in the first place. > > > > > > And I think building user's trust for kernel RNG implementation with > > > multiple entropy contributions is pretty difficult when compared with > > > CAAM HWRNG implementation. > > > > Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s > > other features are two separate things. However, reading through the CAAM > > key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s > > content) are generated using its internal RNG. So I’d save if the CAAM RNG > > is insecure, so are generated key blobs. Maybe somebody with more insight > > into the CAAM internals can verify that, but I don’t see any point in using > > the kernel’s RNG as long as we let CAAM generate the key blob keys for us. > > Here's my long'ish analysis. Please read it to the end if by ever means > possible, and apologies, I usually try to keep usually my comms short, but > this requires some more meat than the usual. > > The Bad News > ============ > > Now that we add multiple hardware trust sources for trusted keys, will > there ever be a scenario where a trusted key is originally sealed with a > backing hardware A, unsealed, and resealed with hardware B? > > The hardware and vendor neutral way to generate the key material would be > unconditionally always just the kernel RNG. > > CAAM is actually worse than TCG because it's not even a standards body, if > I got it right. Not a lot but at least a tiny fraction. > > This brings an open item in TEE patches: trusted_tee_get_random() is an > issue in generating kernel material. I would rather replace that with > kernel RNG *for now*, because the same open question applies also to ARM > TEE. It's also a single company controlled backing technology. > > By all practical means, I do trust ARM TEE in my personal life but this is > not important. > > CAAM *and* TEE backends break the golden rule of putting as little trust as > possible to anything, even not anything weird is clear at sight, as > security is essentially a game of known unknowns and unknown unknowns. > > Unfortunately, TPM trusted keys started this bad security practice, and > obviously it cannot be fixed without breaking uapi backwards compatibility. > > This leaves me exactly two rational options: > > A. Add a patch to remove trusted_tee_get_random() and use kernel RNG > instead. > B. Drop the whole TEE patch set up until I have good reasons to believe > that it's the best possible idea ever to use TEE RNG. > > Doing does (A) does not disclude of doing (B) later on, if someone some > day sends a patch with sound reasoning. > > It's also good to understand that when some day a vendor D, other than TCG, > CAAM or ARM, comes up, we need to go again this lenghty and messy > discussion. Now this already puts an already accepted patch set into a > risk, because by being a responsible maintainer I would have legit reasons > just simply to drop it. > > OK, but.... > > The GOOD News > ============= > > So there's actually option (C) that also fixes the TPM trustd keys issue: > > Add a new kernel patch, which: > > 1. Adds the use of kernel RNG as a boot option. > 2. If this boot option is not active, the subsystem will print a warning > to klog denoting this. > 3. Default is of course vendor RNG given the bad design issue in the TPM > trusted keys, but the warning in klog will help to address it at least > a bit. > 4. Document all this to Documentation/security/keys/trusted-encrypted.rst. > > I'd prefer the choice between A, B and C be concluded rather sooner than > later. Option (C) sounds reasonable to me but I would rather prefer an info message rather than warning as otherwise it would reflect that we are enforcing kernel RNG choice for a user to trust upon. -Sumit > > /Jarkko
Ahmad, On Wed, Mar 17, 2021 at 3:03 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > I didn't closely follow the previous discussions, but is a module > > parameter really the right approach? > > Is there also a way to set it via something like device tree? > > Compiled-on sources are considered in the order: tpm, tee then caam. > Module parameters are the only override currently available. Okay. So in the ideal case only one of these backends is compiled in, but the list can get long. I'm asking because David and I currently port another caam-like mechanism to the most recent kernel which will also hook in there. Out driver adds trusted keys support (with caam alike blobs) for i.mx SoCs that come with DCP instead of CAAM. Patches will hopefully materialize soon.
On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote: > > Unfortunately, TPM trusted keys started this bad security practice, and > obviously it cannot be fixed without breaking uapi backwards compatibility. > The whole point of a randomness source is that it is random. So userspace can't be depending on any particular output, and the randomness source can be changed without breaking backwards compatibility. So IMO, trusted keys should simply be fixed to use get_random_bytes(). - Eric
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> +#define KEYMOD "kernel:trusted"
why is the CAAM key modifier hard coded?
I'd love to have way to pass my own modifier.
That way existing blobs can also be used with this implementation.
IIRC the NXP vendor tree uses "SECURE_KEY" as default modifier.
On Mon, Mar 29, 2021 at 12:11:24PM +0200, Ahmad Fatoum wrote: > Hello Jarkko, > > On 28.03.21 22:37, Jarkko Sakkinen wrote: > > On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote: > >> Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s > >> other features are two separate things. However, reading through the CAAM > >> key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s > >> content) are generated using its internal RNG. So I’d save if the CAAM RNG > >> is insecure, so are generated key blobs. Maybe somebody with more insight > >> into the CAAM internals can verify that, but I don’t see any point in using > >> the kernel’s RNG as long as we let CAAM generate the key blob keys for us. > > > > Here's my long'ish analysis. Please read it to the end if by ever means > > possible, and apologies, I usually try to keep usually my comms short, but > > this requires some more meat than the usual. > > Thanks for the write-up! > > > The Bad News > > ============ > > > > Now that we add multiple hardware trust sources for trusted keys, will > > there ever be a scenario where a trusted key is originally sealed with a > > backing hardware A, unsealed, and resealed with hardware B? > > > > The hardware and vendor neutral way to generate the key material would be > > unconditionally always just the kernel RNG. > > > > CAAM is actually worse than TCG because it's not even a standards body, if > > I got it right. Not a lot but at least a tiny fraction. > > CAAM is how NXP calls the crypto accelerator built into some of its SoCs. > > > This brings an open item in TEE patches: trusted_tee_get_random() is an > > issue in generating kernel material. I would rather replace that with > > kernel RNG *for now*, because the same open question applies also to ARM > > TEE. It's also a single company controlled backing technology. > > > > By all practical means, I do trust ARM TEE in my personal life but this is > > not important. > > > > CAAM *and* TEE backends break the golden rule of putting as little trust as > > possible to anything, even not anything weird is clear at sight, as > > security is essentially a game of known unknowns and unknown unknowns. > > Agreed. > > > The GOOD News > > ============= > > > > So there's actually option (C) that also fixes the TPM trustd keys issue: > > > > Add a new kernel patch, which: > > > > 1. Adds the use of kernel RNG as a boot option. > > 2. If this boot option is not active, the subsystem will print a warning > > to klog denoting this. > > 3. Default is of course vendor RNG given the bad design issue in the TPM > > trusted keys, but the warning in klog will help to address it at least > > a bit. > > Why should the TPM backend's choice influence later backends? We could add > a new option for key creation time, e.g.: > > keyctl add trusted kmk "new keylen rng=kernel" @s > > The default would be rng=vendor if available with a fallback to rng=kernel, > which should always be available. It matters a lot because it is existing ABI - for better or worse. I think a new option is a bad idea, because it cannot easily enforced. Kernel command-line on the other hand can be even signed. /Jarkko
On Tue, Mar 30, 2021 at 12:56:41PM +0530, Sumit Garg wrote: > On Mon, 29 Mar 2021 at 01:07, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote: > > > Hi! > > > > > > > On 25.03.2021, at 06:26, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > > > On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > > >> > > > >> Hello Sumit, > > > >> > > > >> On 24.03.21 11:47, Sumit Garg wrote: > > > >>> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > > >>>> > > > >>>> Hello Mimi, > > > >>>> > > > >>>> On 23.03.21 19:07, Mimi Zohar wrote: > > > >>>>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > > > >>>>>> On 21.03.21 21:48, Horia Geantă wrote: > > > >>>>>>> caam has random number generation capabilities, so it's worth using that > > > >>>>>>> by implementing .get_random. > > > >>>>>> > > > >>>>>> If the CAAM HWRNG is already seeding the kernel RNG, why not use the kernel's? > > > >>>>>> > > > >>>>>> Makes for less code duplication IMO. > > > >>>>> > > > >>>>> Using kernel RNG, in general, for trusted keys has been discussed > > > >>>>> before. Please refer to Dave Safford's detailed explanation for not > > > >>>>> using it [1]. > > > >>>> > > > >>>> The argument seems to boil down to: > > > >>>> > > > >>>> - TPM RNG are known to be of good quality > > > >>>> - Trusted keys always used it so far > > > >>>> > > > >>>> Both are fine by me for TPMs, but the CAAM backend is new code and neither point > > > >>>> really applies. > > > >>>> > > > >>>> get_random_bytes_wait is already used for generating key material elsewhere. > > > >>>> Why shouldn't new trusted key backends be able to do the same thing? > > > >>>> > > > >>> > > > >>> Please refer to documented trusted keys behaviour here [1]. New > > > >>> trusted key backends should align to this behaviour and in your case > > > >>> CAAM offers HWRNG so we should be better using that. > > > >> > > > >> Why is it better? > > > >> > > > >> Can you explain what benefit a CAAM user would have if the trusted key > > > >> randomness comes directly out of the CAAM instead of indirectly from > > > >> the kernel entropy pool that is seeded by it? > > > > > > > > IMO, user trust in case of trusted keys comes from trusted keys > > > > backend which is CAAM here. If a user doesn't trust that CAAM would > > > > act as a reliable source for RNG then CAAM shouldn't be used as a > > > > trust source in the first place. > > > > > > > > And I think building user's trust for kernel RNG implementation with > > > > multiple entropy contributions is pretty difficult when compared with > > > > CAAM HWRNG implementation. > > > > > > Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s > > > other features are two separate things. However, reading through the CAAM > > > key blob spec I’ve got here, CAAM key blob keys (the keys that secure a blob’s > > > content) are generated using its internal RNG. So I’d save if the CAAM RNG > > > is insecure, so are generated key blobs. Maybe somebody with more insight > > > into the CAAM internals can verify that, but I don’t see any point in using > > > the kernel’s RNG as long as we let CAAM generate the key blob keys for us. > > > > Here's my long'ish analysis. Please read it to the end if by ever means > > possible, and apologies, I usually try to keep usually my comms short, but > > this requires some more meat than the usual. > > > > The Bad News > > ============ > > > > Now that we add multiple hardware trust sources for trusted keys, will > > there ever be a scenario where a trusted key is originally sealed with a > > backing hardware A, unsealed, and resealed with hardware B? > > > > The hardware and vendor neutral way to generate the key material would be > > unconditionally always just the kernel RNG. > > > > CAAM is actually worse than TCG because it's not even a standards body, if > > I got it right. Not a lot but at least a tiny fraction. > > > > This brings an open item in TEE patches: trusted_tee_get_random() is an > > issue in generating kernel material. I would rather replace that with > > kernel RNG *for now*, because the same open question applies also to ARM > > TEE. It's also a single company controlled backing technology. > > > > By all practical means, I do trust ARM TEE in my personal life but this is > > not important. > > > > CAAM *and* TEE backends break the golden rule of putting as little trust as > > possible to anything, even not anything weird is clear at sight, as > > security is essentially a game of known unknowns and unknown unknowns. > > > > Unfortunately, TPM trusted keys started this bad security practice, and > > obviously it cannot be fixed without breaking uapi backwards compatibility. > > > > This leaves me exactly two rational options: > > > > A. Add a patch to remove trusted_tee_get_random() and use kernel RNG > > instead. > > B. Drop the whole TEE patch set up until I have good reasons to believe > > that it's the best possible idea ever to use TEE RNG. > > > > Doing does (A) does not disclude of doing (B) later on, if someone some > > day sends a patch with sound reasoning. > > > > It's also good to understand that when some day a vendor D, other than TCG, > > CAAM or ARM, comes up, we need to go again this lenghty and messy > > discussion. Now this already puts an already accepted patch set into a > > risk, because by being a responsible maintainer I would have legit reasons > > just simply to drop it. > > > > OK, but.... > > > > The GOOD News > > ============= > > > > So there's actually option (C) that also fixes the TPM trustd keys issue: > > > > Add a new kernel patch, which: > > > > 1. Adds the use of kernel RNG as a boot option. > > 2. If this boot option is not active, the subsystem will print a warning > > to klog denoting this. > > 3. Default is of course vendor RNG given the bad design issue in the TPM > > trusted keys, but the warning in klog will help to address it at least > > a bit. > > 4. Document all this to Documentation/security/keys/trusted-encrypted.rst. > > > > I'd prefer the choice between A, B and C be concluded rather sooner than > > later. > > Option (C) sounds reasonable to me but I would rather prefer an info > message rather than warning as otherwise it would reflect that we are > enforcing kernel RNG choice for a user to trust upon. I gave some though on this. I take TEE as it is but I'd expect the CAAM patch set sort out this option with some patch. /Jarkko
On Tue, Mar 30, 2021 at 02:47:18PM -0700, Eric Biggers wrote: > On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote: > > > > Unfortunately, TPM trusted keys started this bad security practice, and > > obviously it cannot be fixed without breaking uapi backwards compatibility. > > > > The whole point of a randomness source is that it is random. So userspace can't > be depending on any particular output, and the randomness source can be changed > without breaking backwards compatibility. > > So IMO, trusted keys should simply be fixed to use get_random_bytes(). > > - Eric It's a bummer but uapi is the god in the end. Since TPM does not do it today, that behaviour must be supported forever. That's why a boot option AND a warning would be the best compromise. /Jarkko
On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote: > > It's a bummer but uapi is the god in the end. Since TPM does not do it > today, that behaviour must be supported forever. That's why a boot option > AND a warning would be the best compromise. > It's not UAPI if there is no way for userspace to tell if it changed. - Eric
On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote: > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote: > > > > It's a bummer but uapi is the god in the end. Since TPM does not do it > > today, that behaviour must be supported forever. That's why a boot option > > AND a warning would be the best compromise. > > It's not UAPI if there is no way for userspace to tell if it changed. Exactly. UAPI is only an issue if something *breaks*. Cheers,
On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote: > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote: > > > > It's a bummer but uapi is the god in the end. Since TPM does not do it > > today, that behaviour must be supported forever. That's why a boot option > > AND a warning would be the best compromise. > > > > It's not UAPI if there is no way for userspace to tell if it changed. > > - Eric It's enough uapi for me. People might assume that the entropy source is TPM for this, since it has been so far. /Jarkko
On Thu, Apr 01, 2021 at 12:11:32PM +1100, Herbert Xu wrote: > On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote: > > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote: > > > > > > It's a bummer but uapi is the god in the end. Since TPM does not do it > > > today, that behaviour must be supported forever. That's why a boot option > > > AND a warning would be the best compromise. > > > > It's not UAPI if there is no way for userspace to tell if it changed. > > Exactly. UAPI is only an issue if something *breaks*. If there's even one user that comes shouting that he has a user space configuration, where e.g. rng entropy is consumed constantly and the code assumes that trusted keys does not add to that, then something would break. It would be a crap user space yes, but I don't want to go on reverting because of that. I think there is small but still existing chance that something could break. Why not just add a boot parameter instead of making brutal enforcing changes, indirectly visible to the user space? /Jarkko
On Thu, Apr 01, 2021 at 08:50:05AM +0300, Jarkko Sakkinen wrote: > On Thu, Apr 01, 2021 at 12:11:32PM +1100, Herbert Xu wrote: > > On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote: > > > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote: > > > > > > > > It's a bummer but uapi is the god in the end. Since TPM does not do it > > > > today, that behaviour must be supported forever. That's why a boot option > > > > AND a warning would be the best compromise. > > > > > > It's not UAPI if there is no way for userspace to tell if it changed. > > > > Exactly. UAPI is only an issue if something *breaks*. > > If there's even one user that comes shouting that he has a user space > configuration, where e.g. rng entropy is consumed constantly and the > code assumes that trusted keys does not add to that, then something > would break. > > It would be a crap user space yes, but I don't want to go on reverting > because of that. I think there is small but still existing chance that > something could break. random.c no longer provides any interfaces that subtract entropy credits, as that was never something that made sense. So "consuming" all the entropy from random.c isn't a thing anymore. > > Why not just add a boot parameter instead of making brutal enforcing > changes, indirectly visible to the user space? Why not just fix this bug instead of providing an option to fix it that everyone will need to remember to provide? - Eric
Hello Jarkko, On 01.04.21 01:30, Jarkko Sakkinen wrote: >> Option (C) sounds reasonable to me but I would rather prefer an info >> message rather than warning as otherwise it would reflect that we are >> enforcing kernel RNG choice for a user to trust upon. > > I gave some though on this. > > I take TEE as it is but I'd expect the CAAM patch set sort out this option > with some patch. Is it ok to warn if a user requests vendor RNG with CAAM and default to the kernel RNG? Cheers, Ahmad
Hello Richard, On 31.03.21 20:35, Richard Weinberger wrote: > Ahmad, > > On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: >> +#define KEYMOD "kernel:trusted" > > why is the CAAM key modifier hard coded? > I'd love to have way to pass my own modifier. > > That way existing blobs can also be used with this implementation. > IIRC the NXP vendor tree uses "SECURE_KEY" as default modifier. Being binary compatible with other implementations is not an objective for this patch set. If you need to migrate I'd suggest to get out a clear text password and side-load it into the trusted key framework. Jan and Mimi discussed this some weeks back: https://lore.kernel.org/linux-integrity/e8f149cddce55a4e4615396108e4c900cbec75a8.camel@pengutronix.de/ There's no code to implement this yet though. Cheers, Ahmad
Ahmad, ----- Ursprüngliche Mail ----- > Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de> >> That way existing blobs can also be used with this implementation. >> IIRC the NXP vendor tree uses "SECURE_KEY" as default modifier. > > Being binary compatible with other implementations is not an objective > for this patch set. If you need to migrate I'd suggest to get out a > clear text password and side-load it into the trusted key framework. Compatibility is only one argument, IMHO the much stronger argument is that there are people out there that want to salt the CAAM blob with a key modifier of their own choice. Thanks, //richard
On Wed, Mar 24, 2021 at 09:14:02AM -0700, James Bottomley wrote: > On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote: > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote: > > > Hello Horia, > > > > > > On 21.03.21 21:48, Horia Geantă wrote: > > > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote: > > > > [...] > > > > > +struct trusted_key_ops caam_trusted_key_ops = { > > > > > + .migratable = 0, /* non-migratable */ > > > > > + .init = trusted_caam_init, > > > > > + .seal = trusted_caam_seal, > > > > > + .unseal = trusted_caam_unseal, > > > > > + .exit = trusted_caam_exit, > > > > > +}; > > > > caam has random number generation capabilities, so it's worth > > > > using that > > > > by implementing .get_random. > > > > > > If the CAAM HWRNG is already seeding the kernel RNG, why not use > > > the kernel's? > > > > > > Makes for less code duplication IMO. > > > > Using kernel RNG, in general, for trusted keys has been discussed > > before. Please refer to Dave Safford's detailed explanation for not > > using it [1]. > > > > thanks, > > > > Mimi > > > > [1] > > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/ > > I still don't think relying on one source of randomness to be > cryptographically secure is a good idea. The fear of bugs in the > kernel entropy pool is reasonable, but since it's widely used they're > unlikely to persist very long. I'm not sure I agree - remember https://www.schneier.com/blog/archives/2008/05/random_number_b.html ? You'd surely expect that to have been found quickly. > Studies have shown that some TPMs > (notably the chinese manufactured ones) have suspicious failures in > their RNGs: > > https://www.researchgate.net/publication/45934562_Benchmarking_the_True_Random_Number_Generator_of_TPM_Chips > > And most cryptograhpers recommend using a TPM for entropy mixing rather > than directly: > > https://blog.cryptographyengineering.com/category/rngs/ > > The TPMFail paper also shows that in spite of NIST certification > things can go wrong with a TPM: > > https://tpm.fail/ In this thread I've seen argument over "which is better" and "which is user api", but noone's mentioned fips. Unfortunately, so long as kernel rng refuses to be fips-friendly (cf https://lkml.org/lkml/2020/9/21/157), making CAAM based trusted keys depend on kernel rng would make them impossible to use in fips certified applications without a forked kernel. So I definitely am in favor of a config or kernel command line option to drive which rng to use.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c8bad1762cba..382e911389aa 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5469,6 +5469,7 @@ sources: - "tpm" - "tee" + - "caam" If not specified then it defaults to iterating through the trust source list starting with TPM and assigns the first trust source as a backend which is initialized diff --git a/include/keys/trusted_caam.h b/include/keys/trusted_caam.h new file mode 100644 index 000000000000..2fba0996b0b0 --- /dev/null +++ b/include/keys/trusted_caam.h @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de> + */ + +#ifndef __CAAM_TRUSTED_KEY_H +#define __CAAM_TRUSTED_KEY_H + +extern struct trusted_key_ops caam_trusted_key_ops; + +#endif diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile index feb8b6c3cc79..050370690abd 100644 --- a/security/keys/trusted-keys/Makefile +++ b/security/keys/trusted-keys/Makefile @@ -12,3 +12,4 @@ trusted-y += trusted_tpm2.o trusted-y += tpm2key.asn1.o trusted-$(CONFIG_TEE) += trusted_tee.o +trusted-$(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) += trusted_caam.o diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c new file mode 100644 index 000000000000..fc2e3dde9e06 --- /dev/null +++ b/security/keys/trusted-keys/trusted_caam.c @@ -0,0 +1,74 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de> + */ + +#include <keys/trusted_caam.h> +#include <keys/trusted-type.h> +#include <linux/build_bug.h> +#include <linux/key-type.h> +#include <soc/fsl/caam-blob.h> + +struct caam_blob_priv *blobifier; + +#define KEYMOD "kernel:trusted" + +static_assert(MAX_KEY_SIZE + CAAM_BLOB_OVERHEAD <= CAAM_BLOB_MAX_LEN); +static_assert(MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN); + +static int trusted_caam_seal(struct trusted_key_payload *p, char *datablob) +{ + int length = p->key_len + CAAM_BLOB_OVERHEAD; + int ret; + + ret = caam_encap_blob(blobifier, KEYMOD, p->key, p->blob, length); + if (ret) + return ret; + + p->blob_len = length; + return 0; +} + +static int trusted_caam_unseal(struct trusted_key_payload *p, char *datablob) +{ + int length = p->blob_len; + int ret; + + ret = caam_decap_blob(blobifier, KEYMOD, p->blob, p->key, length); + if (ret) + return ret; + + p->key_len = length - CAAM_BLOB_OVERHEAD; + return 0; +} + +static int trusted_caam_init(void) +{ + int ret; + + blobifier = caam_blob_gen_init(); + if (IS_ERR(blobifier)) { + pr_err("Job Ring Device allocation for transform failed\n"); + return PTR_ERR(blobifier); + } + + ret = register_key_type(&key_type_trusted); + if (ret) + caam_blob_gen_exit(blobifier); + + return ret; +} + +static void trusted_caam_exit(void) +{ + unregister_key_type(&key_type_trusted); + caam_blob_gen_exit(blobifier); +} + +struct trusted_key_ops caam_trusted_key_ops = { + .migratable = 0, /* non-migratable */ + .init = trusted_caam_init, + .seal = trusted_caam_seal, + .unseal = trusted_caam_unseal, + .exit = trusted_caam_exit, +}; diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c index 5f92323efedf..e9bfb1bbc014 100644 --- a/security/keys/trusted-keys/trusted_core.c +++ b/security/keys/trusted-keys/trusted_core.c @@ -9,6 +9,7 @@ #include <keys/user-type.h> #include <keys/trusted-type.h> #include <keys/trusted_tee.h> +#include <keys/trusted_caam.h> #include <keys/trusted_tpm.h> #include <linux/capability.h> #include <linux/err.h> @@ -25,7 +26,7 @@ static char *trusted_key_source; module_param_named(source, trusted_key_source, charp, 0); -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)"); +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)"); static const struct trusted_key_source trusted_key_sources[] = { #if defined(CONFIG_TCG_TPM) @@ -34,6 +35,9 @@ static const struct trusted_key_source trusted_key_sources[] = { #if defined(CONFIG_TEE) { "tee", &trusted_key_tee_ops }, #endif +#if defined(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) + { "caam", &caam_trusted_key_ops }, +#endif }; DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core built into many newer i.MX and QorIQ SoCs by NXP. The CAAM does crypto acceleration, hardware number generation and has a blob mechanism for encapsulation/decapsulation of sensitive material. This blob mechanism depends on a device specific random 256-bit One Time Programmable Master Key that is fused in each SoC at manufacturing time. This key is unreadable and can only be used by the CAAM for AES encryption/decryption of user data. This makes it a suitable backend (source) for kernel trusted keys. Previous commits generalized trusted keys to support multiple backends and added an API to access the CAAM blob mechanism. Based on these, provide the necessary glue to use the CAAM for trusted keys. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> --- To: Jonathan Corbet <corbet@lwn.net> To: David Howells <dhowells@redhat.com> To: Jarkko Sakkinen <jarkko@kernel.org> To: James Bottomley <jejb@linux.ibm.com> To: Mimi Zohar <zohar@linux.ibm.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: "Horia Geantă" <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Udit Agarwal <udit.agarwal@nxp.com> Cc: Jan Luebbe <j.luebbe@penutronix.de> Cc: David Gstir <david@sigma-star.at> Cc: Franck LENORMAND <franck.lenormand@nxp.com> Cc: Sumit Garg <sumit.garg@linaro.org> Cc: keyrings@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-integrity@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org --- Documentation/admin-guide/kernel-parameters.txt | 1 +- include/keys/trusted_caam.h | 11 +++- security/keys/trusted-keys/Makefile | 1 +- security/keys/trusted-keys/trusted_caam.c | 74 ++++++++++++++++++- security/keys/trusted-keys/trusted_core.c | 6 +- 5 files changed, 92 insertions(+), 1 deletion(-) create mode 100644 include/keys/trusted_caam.h create mode 100644 security/keys/trusted-keys/trusted_caam.c