> -----Original Message----- > From: Michael Walle <michael@xxxxxxxx> > Sent: Wednesday, September 7, 2022 1:42 PM > To: David Gstir <david@xxxxxxxxxxxxx> > Cc: Pankaj Gupta <pankaj.gupta@xxxxxxx>; Ahmad Fatoum > <a.fatoum@xxxxxxxxxxxxxx>; Jarkko Sakkinen <jarkko@xxxxxxxxxx>; > Jason@xxxxxxxxx; James Bottomley <jejb@xxxxxxxxxxxxx>; Mimi Zohar > <zohar@xxxxxxxxxxxxx>; David Howells <dhowells@xxxxxxxxxx>; Sumit > Garg <sumit.garg@xxxxxxxxxx>; john.ernberg@xxxxxxxx; James Morris > <jmorris@xxxxxxxxx>; Serge E. Hallyn <serge@xxxxxxxxxx>; Herbert Xu > <herbert@xxxxxxxxxxxxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; > Jan Luebbe <j.luebbe@xxxxxxxxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; > Richard Weinberger <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: Re: [EXT] [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY > > Caution: EXT Email > > Hi David, > > Am 2022-09-07 09:46, schrieb David Gstir: > >> 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. > > I agree, thus my first question here was, what this series is adding, if the key > is already "bound" to the hardware. That is what I don't understand. > > -michael Just one correction in above statement. "Key-Blob" is bound to the hardware, not the plain key that is added to the job-ring, after de-blobification. Security at rest is ensured here. But not at the runtime. This patch-set goes a step further and ensures runtime security as well. > > > 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.
