Messages in this thread | | | From | Pankaj Gupta <> | Subject | RE: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY | Date | Wed, 7 Sep 2022 07:22:45 +0000 |
| |
> -----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.
> -michael
| |