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

[Michael Walle]

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.

Ahmad (as you were the author of the original series), is this supposed
to work or is the seal export already encrypted with the per SoC key?

-michael