On Wed, 2021-03-24 at 16:49 -0400, Mimi Zohar wrote:

On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote:

quoted

On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:

quoted

On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:

quoted

Hello Horia,

On 21.03.21 21:48, Horia Geantă wrote:

quoted

On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
[...]

quoted

+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/ (local)

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/ (local)
[3] Jarrko on "regression" and tpm_asym.c - 
https://lore.kernel.org/linux-integrity/20191014190033.GA15552@linux.intel.com/ (local) 

Mimi