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: <766a68a95e6c095bb202f430b8b091d008002205.camel@linux.ibm.com>
Date:   Wed, 24 Mar 2021 14:58:30 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        Horia Geantă <horia.geanta@....com>,
        Jonathan Corbet <corbet@....net>,
        David Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>
Cc:     "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>,
        David Gstir <david@...ma-star.at>,
        Franck Lenormand <franck.lenormand@....com>,
        Sumit Garg <sumit.garg@...aro.org>,
        "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>,
        Pascal Van Leeuwen <pvanleeuwen@...imatrix.com>
Subject: Re: [PATCH v1 3/3] KEYS: trusted: Introduce support for NXP
 CAAM-based trusted keys

On Wed, 2021-03-24 at 16:49 -0400, Mimi Zohar wrote:
> On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote:
> > On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:
> > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> > > > Hello Horia,
> > > > 
> > > > On 21.03.21 21:48, Horia Geantă wrote:
> > > > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> > > > > [...]
> > > > > > +struct trusted_key_ops caam_trusted_key_ops = {
> > > > > > +	.migratable = 0, /* non-migratable */
> > > > > > +	.init = trusted_caam_init,
> > > > > > +	.seal = trusted_caam_seal,
> > > > > > +	.unseal = trusted_caam_unseal,
> > > > > > +	.exit = trusted_caam_exit,
> > > > > > +};
> > > > > caam has random number generation capabilities, so it's worth
> > > > > using that
> > > > > by implementing .get_random.
> > > > 
> > > > If the CAAM HWRNG is already seeding the kernel RNG, why not
> > > > use
> > > > the kernel's?
> > > > 
> > > > Makes for less code duplication IMO.
> > > 
> > > Using kernel RNG, in general, for trusted keys has been discussed
> > > before.   Please refer to Dave Safford's detailed explanation for
> > > not
> > > using it [1].
> > > 
> > > [1] 
> > > https://lore.kernel.org/linux-integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A38B@ALPMBAPA12.e2k.ad.ge.com/
> > 
> > I still don't think relying on one source of randomness to be
> > cryptographically secure is a good idea.  The fear of bugs in the
> > kernel entropy pool is reasonable, but since it's widely used
> > they're
> > unlikely to persist very long.  Studies have shown that some TPMs
> > (notably the chinese manufactured ones) have suspicious failures in
> > their RNGs:
> > 
> > https://www.researchgate.net/publication/45934562_Benchmarking_the_True_Random_Number_Generator_of_TPM_Chips
> > 
> > And most cryptograhpers recommend using a TPM for entropy mixing
> > rather
> > than directly:
> > 
> > https://blog.cryptographyengineering.com/category/rngs/
> > 
> > The TPMFail paper also shows that in spite of NIST certification
> > things can go wrong with a TPM:
> > 
> > https://tpm.fail/
> 
> We already had a lengthy discussion on replacing the TPM RNG with the
> kernel RNG for trusted keys, when TEE was being introduced
> [2,3].  I'm not interested in re-hashing that discussion here.   The
> only difference now is that CAAM is a new trust source.  I suspect
> the same concerns/issues persist, but at least in this case using the
> kernel RNG would not be a regression.

Upstreaming the ASN.1 parser gives us a way to create trusted keys
outside the kernel and so choose any RNG that suits the user, so I
don't think there's any need to rehash for TPM based keys either.

However CaaM doesn't have the ability to create keys outside the kernel
yet, so they do need to consider the problem.

James


> [2] Pascal Van Leeuwen on mixing different sources of entropy and
> certification -
>  
> https://lore.kernel.org/linux-integrity/MN2PR20MB29732A856A40131A671F949FCA950@MN2PR20MB2973.namprd20.prod.outlook.com/
> [3] Jarrko on "regression" and tpm_asym.c - 
> https://lore.kernel.org/linux-integrity/20191014190033.GA15552@linux.intel.com/ 
> 
> Mimi
>