> -----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. > -michael
