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

[David Gstir]

Hi Michael,

> On 07.09.2022, at 09:29, Michael Walle <michael at walle.cc> wrote:
> 
> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>>> -----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.
> 
> 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.

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.

- David