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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1171de9c-97b9-3936-707b-16ec34cf94d5@pengutronix.de>
Date:   Mon, 29 Mar 2021 12:11:24 +0200
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Jarkko Sakkinen <jarkko@...nel.org>,
        David Gstir <david@...ma-star.at>
Cc:     Sumit Garg <sumit.garg@...aro.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Horia Geantă <horia.geanta@....com>,
        Jonathan Corbet <corbet@....net>,
        David Howells <dhowells@...hat.com>,
        James Bottomley <jejb@...ux.ibm.com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Aymen Sghaier <aymen.sghaier@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Udit Agarwal <udit.agarwal@....com>,
        Jan Luebbe <j.luebbe@...gutronix.de>,
        Franck Lenormand <franck.lenormand@....com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
Subject: 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:
>> 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 |