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