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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DU2PR04MB8630FBA525FB560E3604447195239@DU2PR04MB8630.eurprd04.prod.outlook.com>
Date:   Tue, 11 Oct 2022 11:05:49 +0000
From:   Pankaj Gupta <pankaj.gupta@....com>
To:     "'Jason A. Donenfeld'" <Jason@...c4.com>
CC:     'Herbert Xu' <herbert@...dor.apana.org.au>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "a.fatoum@...gutronix.de" <a.fatoum@...gutronix.de>,
        "gilad@...yossef.com" <gilad@...yossef.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "sumit.garg@...aro.org" <sumit.garg@...aro.org>,
        "david@...ma-star.at" <david@...ma-star.at>,
        "michael@...le.cc" <michael@...le.cc>,
        "john.ernberg@...ia.se" <john.ernberg@...ia.se>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "j.luebbe@...gutronix.de" <j.luebbe@...gutronix.de>,
        "ebiggers@...nel.org" <ebiggers@...nel.org>,
        "richard@....at" <richard@....at>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...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>,
        Sahil Malhotra <sahil.malhotra@....com>,
        Kshitiz Varshney <kshitiz.varshney@....com>,
        Horia Geanta <horia.geanta@....com>,
        Varun Sethi <V.Sethi@....com>
Subject: RE: [EXT] Re: [PATCH v0 3/8] crypto: hbk flags & info added to the
 tfm

> -----Original Message-----
> From: Jason A. Donenfeld <Jason@...c4.com>
> Sent: Monday, October 10, 2022 8:46 PM
> To: Pankaj Gupta <pankaj.gupta@....com>
> Cc: 'Herbert Xu' <herbert@...dor.apana.org.au>; jarkko@...nel.org;
> a.fatoum@...gutronix.de; gilad@...yossef.com; jejb@...ux.ibm.com;
> zohar@...ux.ibm.com; dhowells@...hat.com; sumit.garg@...aro.org;
> david@...ma-star.at; michael@...le.cc; john.ernberg@...ia.se;
> jmorris@...ei.org; serge@...lyn.com; davem@...emloft.net;
> j.luebbe@...gutronix.de; ebiggers@...nel.org; richard@....at;
> keyrings@...r.kernel.org; linux-crypto@...r.kernel.org; linux-
> integrity@...r.kernel.org; linux-kernel@...r.kernel.org; linux-security-
> module@...r.kernel.org; Sahil Malhotra <sahil.malhotra@....com>; Kshitiz
> Varshney <kshitiz.varshney@....com>; Horia Geanta
> <horia.geanta@....com>; Varun Sethi <V.Sethi@....com>
> Subject: Re: [EXT] Re: [PATCH v0 3/8] crypto: hbk flags & info added to the
> tfm
> 
> Caution: EXT Email
> 
> On Mon, Oct 10, 2022 at 11:15:00AM +0000, Pankaj Gupta wrote:
> > > Nack.  You still have not provided a convincing argument why this is
> > > necessary since there are plenty of existing drivers in the kernel
> > > already providing similar features.
> > >
> > CAAM is used as a trusted source for trusted keyring. CAAM can expose
> > these keys either as plain key or HBK(hardware bound key- managed by
> > the hardware only and never visible in plain outside of hardware).
> >
> > Thus, Keys that are inside CAAM-backed-trusted-keyring, can either be
> > plain key or HBK. So the trusted-key-payload requires additional flag
> > & info(key-encryption-protocol)  to help differentiate it from each
> > other. Now when CAAM trusted-key is presented to the kernel crypto
> > framework, the additional information associated with the key, needs
> > to be passed to the hardware driver. Currently the kernel keyring and
> > kernel crypto frameworks are associated for plain key, but completely
> > dis-associated for HBK. This patch addresses this problem.
> >
> > Similar capabilities (trusted source), are there in other crypto
> > accelerators on NXP SoC(s). Having hardware specific crypto algorithm
> > name, does not seems to be a scalable solution.
> 
> Do you mean to say that other drivers that use hardware-backed keys do so
> by setting "cra_name" to something particular? 

Yes.

> Like instead of "aes"
> it'd be "aes-but-special-for-this-driver"?

For example: ARM-Crypto-Cell prepends 'p':
- xts(paes) for xts(aes)
- xts(paes) for xts(aes)...etc.

 > If so, that would seem to break the
> design of the crypto API. Which driver did you see that does this?  Or perhaps,
> more generally, what are the drivers that Herbert is talking about when he
> mentions the "plenty of existing drivers" that already do this?
I could find this driver " drivers/crypto/ccree/".
Reference file name is " drivers/crypto/ccree/cc_cipher.c"

Likewise, CAAM being a trust source, new cra_name would be need to deal with CAAM generated HBKs too.
We need to come up with something unique like: for eg:   p(xts(aes)) for xts(aes)             
   
Another trust source from NXP called DCP(drivers/crypto/mxs-dcp.c),  new cra_name would be needed for that too.
There are work in progress for other trust sources from NXP.

So, our approach is too provide generic solution, which can be extended to any trust source generating HBK.


> 
> Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ