Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

Hello Jarkko,

On 28.03.21 22:37, Jarkko Sakkinen wrote:

On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote:

quoted

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

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