RE: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY

[Pankaj Gupta <pankaj.gupta@nxp.com>]

> -----Original Message-----
> From: Jarkko Sakkinen <jarkko@kernel.org>
> Sent: Tuesday, September 6, 2022 2:28 PM
> To: Pankaj Gupta <pankaj.gupta@nxp.com>
> Cc: 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; michael@walle.cc; 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
> 
> 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