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: <YGUF0sArOSy2gdpS@kernel.org>
Date:   Thu, 1 Apr 2021 02:29:22 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc:     David Gstir <david@...ma-star.at>,
        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

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