[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:48 UTC 2022
> -----Original Message-----
> From: Jarkko Sakkinen <jarkko at kernel.org>
> Sent: Tuesday, September 6, 2022 2:28 PM
> To: Pankaj Gupta <pankaj.gupta at nxp.com>
> Cc: 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; michael at walle.cc; 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
>
> On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> > Hardware Bound key(HBK), is never acessible as plain key outside of
> > the
> ~~~~~~~~~
> accesible.
>
> > hardware boundary. Thus, it is un-usable, even if somehow fetched from
> > kernel memory. It ensures run-time security.
>
> Why is it called "HBK" here and "hw" in the context of keyctl?
It is HBK, because the key is bounded to the Hardware. As:
- Key is generated by hardware.
- Key can only be used by hardware.
- Stored as a blob by the hardware.
>
> > 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.
>
> CAAM is implementation of what exactly?
CAAM is the chip's cryptographic acceleration and offloading hardware and combines cryptographic and other mathematical
functions to create a modular and scalable hardware acceleration and assurance engine. In context to this patchset, CAAM implements the following functions:
- Generates HBK
- Generates key-blob, from HBK, for security at rest.
- Perform crypto operations, using HBK.
>
> I'm sorry but I don't know your definition of unusable.
Even if somehow the key is retrieved from the keyring, the retrieved key would be an encrypted key.
This encrypted key can only be decrypted by Hardware, which generated it.
Hence, the retrieved key is unusable outside of the hardware.
>
> BR, Jarkko
More information about the Linux-security-module-archive
mailing list