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

[Michael Walle]

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

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