-----Original Message-----
From: Michael Walle <michael@xxxxxxxx>
Sent: Tuesday, September 6, 2022 12:43 PM
To: Pankaj Gupta <pankaj.gupta@xxxxxxx>
Cc: jarkko@xxxxxxxxxx; a.fatoum@xxxxxxxxxxxxxx; Jason@xxxxxxxxx;
jejb@xxxxxxxxxxxxx; zohar@xxxxxxxxxxxxx; dhowells@xxxxxxxxxx;
sumit.garg@xxxxxxxxxx; david@xxxxxxxxxxxxx; john.ernberg@xxxxxxxx;
jmorris@xxxxxxxxx; serge@xxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx;
davem@xxxxxxxxxxxxx; j.luebbe@xxxxxxxxxxxxxx; ebiggers@xxxxxxxxxx;
richard@xxxxxx; keyrings@xxxxxxxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx;
linux-integrity@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
security-module@xxxxxxxxxxxxxxx; Sahil Malhotra
<sahil.malhotra@xxxxxxx>; Kshitiz Varshney <kshitiz.varshney@xxxxxxx>;
Horia Geanta <horia.geanta@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>
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.