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:

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].

thanks,

Mimi

[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.

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.