Messages in this thread | | | From | Pankaj Gupta <> | Subject | RE: [EXT] [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY | Date | Wed, 7 Sep 2022 09:57:50 +0000 |
| |
> -----Original Message----- > From: Michael Walle <michael@walle.cc> > Sent: Wednesday, September 7, 2022 1:42 PM > To: David Gstir <david@sigma-star.at> > Cc: Pankaj Gupta <pankaj.gupta@nxp.com>; Ahmad Fatoum > <a.fatoum@pengutronix.de>; Jarkko Sakkinen <jarkko@kernel.org>; > Jason@zx2c4.com; James Bottomley <jejb@linux.ibm.com>; Mimi Zohar > <zohar@linux.ibm.com>; David Howells <dhowells@redhat.com>; Sumit > Garg <sumit.garg@linaro.org>; john.ernberg@actia.se; James Morris > <jmorris@namei.org>; Serge E. Hallyn <serge@hallyn.com>; Herbert Xu > <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>; > Jan Luebbe <j.luebbe@pengutronix.de>; Eric Biggers <ebiggers@kernel.org>; > Richard Weinberger <richard@nod.at>; keyrings@vger.kernel.org; linux- > crypto@vger.kernel.org; linux-integrity@vger.kernel.org; linux- > kernel@vger.kernel.org; linux-security-module@vger.kernel.org; Sahil > Malhotra <sahil.malhotra@nxp.com>; Kshitiz Varshney > <kshitiz.varshney@nxp.com>; Horia Geanta <horia.geanta@nxp.com>; > Varun Sethi <V.Sethi@nxp.com> > Subject: Re: [EXT] [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY > > Caution: EXT Email > > Hi David, > > Am 2022-09-07 09:46, schrieb David Gstir: > >> On 07.09.2022, at 09:29, Michael Walle <michael@walle.cc> wrote: > >> > >> Am 2022-09-07 09:22, schrieb Pankaj Gupta: > >>>> -----Original Message----- > >>>> From: Michael Walle <michael@walle.cc> > >>>> Sent: Tuesday, September 6, 2022 12:43 PM > >>>> To: Pankaj Gupta <pankaj.gupta@nxp.com> > >>>> Cc: jarkko@kernel.org; a.fatoum@pengutronix.de; Jason@zx2c4.com; > >>>> jejb@linux.ibm.com; zohar@linux.ibm.com; dhowells@redhat.com; > >>>> sumit.garg@linaro.org; david@sigma-star.at; john.ernberg@actia.se; > >>>> jmorris@namei.org; serge@hallyn.com; herbert@gondor.apana.org.au; > >>>> davem@davemloft.net; j.luebbe@pengutronix.de; > ebiggers@kernel.org; > >>>> richard@nod.at; keyrings@vger.kernel.org; > >>>> linux-crypto@vger.kernel.org; linux-integrity@vger.kernel.org; > >>>> linux-kernel@vger.kernel.org; > >>>> linux- > >>>> security-module@vger.kernel.org; Sahil Malhotra > >>>> <sahil.malhotra@nxp.com>; Kshitiz Varshney > >>>> <kshitiz.varshney@nxp.com>; Horia Geanta <horia.geanta@nxp.com>; > >>>> Varun Sethi <V.Sethi@nxp.com> > >>>> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED > KEY > >>>> Caution: EXT Email > >>>> Hi, > >>>> Am 2022-09-06 08:51, schrieb Pankaj Gupta: > >>>> > Hardware Bound key(HBK), is never acessible as plain key outside > >>>> > of the hardware boundary. Thus, it is un-usable, even if somehow > >>>> > fetched from kernel memory. It ensures run-time security. > >>>> > > >>>> > This patchset adds generic support for classing the Hardware > >>>> > Bound Key, based on: > >>>> > > >>>> > - Newly added flag-'is_hbk', added to the tfm. > >>>> > > >>>> > Consumer of the kernel crypto api, after allocating > >>>> > the transformation, sets this flag based on the basis > >>>> > of the type of key consumer has. > >>>> > > >>>> > - This helps to influence the core processing logic > >>>> > for the encapsulated algorithm. > >>>> > > >>>> > - This flag is set by the consumer after allocating > >>>> > the tfm and before calling the function crypto_xxx_setkey(). > >>>> > > >>>> > First implementation is based on CAAM. > >>>> > > >>>> > NXP built CAAM IP is the Cryptographic Acceleration and Assurance > >>>> > Module. > >>>> > This is contain by the i.MX and QorIQ SoCs by NXP. > >>>> > > >>>> > CAAM is a suitable backend (source) for kernel trusted keys. > >>>> > This backend source can be used for run-time security as well by > >>>> > generating the hardware bound key. > >>>> > > >>>> > Along with plain key, the CAAM generates black key. A black key > >>>> > is an encrypted key, which can only be decrypted inside CAAM. > >>>> > Hence, CAAM's black key can only be used by CAAM. Thus it is > >>>> > declared as a hardware bound key. > >>>> What is the difference to the current trusted keys with CAAM? > >>>> When I tested the patch series back then, I wasn't able to import a > >>>> sealed key on another board with the same SoC. > >>> Currently, keys that are part of trusted key-ring, contains plain > >>> key. > >>> With this patch-set, these key will become Hw Bound Key, which is > >>> not a plain key anymore. > >>> After this patch-set, if somehow the HB-key is retrieved from the > >>> keyring, the retrieved key would be un-usable without hw. > >> > >> This doesn't answer my question why I couldn't import one key on > >> another board with the same SoC. > > > > I don’t believe this is intended to work this way. Each key blob > > created by CAAM is bound to a specific device. Being able to decrypt > > the same blob on another SoC would open up some attack vectors: Think > > of a locked down device where I’m able to extract this key blob. > > Simply buying a board with the same Soc would allow me to decrypt this > > blob by copying it over to my board. > > I agree, thus my first question here was, what this series is adding, if the key > is already "bound" to the hardware. That is what I don't understand. > > -michael
Just one correction in above statement. "Key-Blob" is bound to the hardware, not the plain key that is added to the job-ring, after de-blobification. Security at rest is ensured here. But not at the runtime.
This patch-set goes a step further and ensures runtime security as well.
> > > Roughly speaking, CAAM key blobs are secure using a key derived from > > the device’s master key. This master key can be programmed via eFUSEs. > > So you’d have to burn the same master key on both SoCs and it should > > work. > > > > In any way, check the security reference manual for your SoC. It > > should explain this in more detail.
| |