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.
