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

Ahmad Fatoum
2021-03-29T10:12:14Z

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
>

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