[EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
Pankaj Gupta
pankaj.gupta at nxp.com
Wed Sep 7 07:22:45 UTC 2022
> -----Original Message-----
> From: Michael Walle <michael at walle.cc>
> Sent: Tuesday, September 6, 2022 12:43 PM
> To: Pankaj Gupta <pankaj.gupta at nxp.com>
> Cc: jarkko at kernel.org; a.fatoum at pengutronix.de; Jason at zx2c4.com;
> jejb at linux.ibm.com; zohar at linux.ibm.com; dhowells at redhat.com;
> sumit.garg at linaro.org; david at sigma-star.at; john.ernberg at actia.se;
> jmorris at namei.org; serge at hallyn.com; herbert at gondor.apana.org.au;
> davem at davemloft.net; j.luebbe at pengutronix.de; ebiggers at kernel.org;
> richard at nod.at; keyrings at vger.kernel.org; linux-crypto at vger.kernel.org;
> linux-integrity at vger.kernel.org; linux-kernel at vger.kernel.org; linux-
> security-module at vger.kernel.org; Sahil Malhotra
> <sahil.malhotra at nxp.com>; Kshitiz Varshney <kshitiz.varshney at nxp.com>;
> Horia Geanta <horia.geanta at nxp.com>; Varun Sethi <V.Sethi at 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
More information about the Linux-security-module-archive
mailing list