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

[Jarkko Sakkinen]

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