[RFC,HBK:,0/8] HW BOUND KEY as TRUSTED KEY

Message

Pankaj Gupta Sept. 6, 2022, 6:51 a.m. UTC

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.

Pankaj Gupta (8):
  keys-trusted: new cmd line option added
  hw-bound-key: flag-is_hbk added to the tfm
  sk_cipher: checking for hw bound operation
  keys-trusted: re-factored caam based trusted key
  caam blob-gen: moving blob_priv to caam_drv_private
  KEYS: trusted: caam based black key
  caam alg: symmetric key ciphers are updated
  dm-crypt: consumer-app setting the flag-is_hbk

 crypto/skcipher.c                         |   3 +-
 drivers/crypto/caam/blob_gen.c            | 242 ++++++++++++++++++++--
 drivers/crypto/caam/caamalg.c             |  37 +++-
 drivers/crypto/caam/caamalg_desc.c        |   8 +-
 drivers/crypto/caam/desc.h                |   8 +-
 drivers/crypto/caam/desc_constr.h         |   6 +-
 drivers/crypto/caam/intern.h              |   6 +-
 drivers/md/dm-crypt.c                     |   6 +-
 include/keys/trusted-type.h               |   2 +
 include/linux/crypto.h                    |   2 +
 include/soc/fsl/caam-blob.h               |  44 ++--
 security/keys/trusted-keys/trusted_caam.c |   6 +
 security/keys/trusted-keys/trusted_core.c |  14 ++
 13 files changed, 333 insertions(+), 51 deletions(-)

Comments

Michael Walle Sept. 6, 2022, 7:12 a.m. UTC | #1

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.

-michael

Jarkko Sakkinen Sept. 6, 2022, 8:58 a.m. UTC | #2

On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> Hardware Bound key(HBK), is never acessible as plain key outside of the
                                    ~~~~~~~~~
                                    accesible.

> hardware boundary. Thus, it is un-usable, even if somehow fetched
> from kernel memory. It ensures run-time security.

Why is it called "HBK" here and "hw" in the context of keyctl?

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

CAAM is implementation of what exactly?

I'm sorry but I don't know your definition of unusable.

BR, Jarkko

Pankaj Gupta Sept. 7, 2022, 7:22 a.m. UTC | #3

> -----Original Message-----
> From: Michael Walle <[e-mail]>
> Sent: Tuesday, September 6, 2022 12:43 PM
> To: Pankaj Gupta <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; Sahil Malhotra
> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
> 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

Pankaj Gupta Sept. 7, 2022, 7:22 a.m. UTC | #4

> -----Original Message-----
> From: Jarkko Sakkinen <[e-mail]>
> Sent: Tuesday, September 6, 2022 2:28 PM
> To: Pankaj Gupta <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; Sahil Malhotra
> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
> 
> Caution: EXT Email
> 
> On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> > Hardware Bound key(HBK), is never acessible as plain key outside of
> > the
>                                     ~~~~~~~~~
>                                     accesible.
> 
> > hardware boundary. Thus, it is un-usable, even if somehow fetched from
> > kernel memory. It ensures run-time security.
> 
> Why is it called "HBK" here and "hw" in the context of keyctl?
It is HBK, because the key is bounded to the Hardware. As:
- Key is generated by hardware.
- Key can only be used by hardware.
- Stored as a blob by the hardware.

> 
> > 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.
> 
> CAAM is implementation of what exactly?


CAAM is the chip's cryptographic acceleration and offloading hardware and combines cryptographic and other mathematical
functions to create a modular and scalable hardware acceleration and assurance engine. In context to this patchset, CAAM implements the following functions:
- Generates HBK
- Generates key-blob, from HBK, for security at rest.
- Perform crypto operations, using HBK. 

> 
> I'm sorry but I don't know your definition of unusable.

Even if somehow the key is retrieved from the keyring, the retrieved key  would be an encrypted key.
This encrypted key can only be decrypted by Hardware, which generated it.

Hence, the retrieved key is unusable outside of the hardware.

> 
> BR, Jarkko

Michael Walle Sept. 7, 2022, 7:29 a.m. UTC | #5

Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>> -----Original Message-----
>> From: Michael Walle <[e-mail]>
>> Sent: Tuesday, September 6, 2022 12:43 PM
>> To: Pankaj Gupta <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; 
>> [e-mail];
>> [e-mail]; [e-mail]; linux-
>> [e-mail]; Sahil Malhotra
>> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
>> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
>> 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.

Ahmad (as you were the author of the original series), is this supposed
to work or is the seal export already encrypted with the per SoC key?

-michael

David Gstir Sept. 7, 2022, 7:46 a.m. UTC | #6

Hi Michael,

> On 07.09.2022, at 09:29, Michael Walle <[e-mail]> wrote:
> 
> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>>> -----Original Message-----
>>> From: Michael Walle <[e-mail]>
>>> Sent: Tuesday, September 6, 2022 12:43 PM
>>> To: Pankaj Gupta <[e-mail]>
>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; linux-
>>> [e-mail]; Sahil Malhotra
>>> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
>>> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
>>> 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

Jan Lübbe Sept. 7, 2022, 8:10 a.m. UTC | #7

On Wed, 2022-09-07 at 07:22 +0000, Pankaj Gupta wrote:
> Even if somehow the key is retrieved from the keyring, the retrieved key 
> would be an encrypted key.
> This encrypted key can only be decrypted by Hardware, which generated it.
> 
> Hence, the retrieved key is unusable outside of the hardware.

NXP's CAAM unit (i.e. on i.MX6) supports several modes of sealed/encrypted keys.
The (un)sealing process uses a key that is normally derived from a per-device
key in eFUSES. One aspect of these modes is whether the plaintext key material
is accessible to the kernel or not.

Ahmad's patch set added support for a mode where the CAAM is used to seal
plaintext known to the kernel to a "blob" (in CAAM terminology) on export to
userspace and the reverse on import. This mode allows the kernel to use the
plaintext for dm-crypt, to encrypt other keyrings and similar.

The CAAM has another sealing mode, where it will not allow writing of the
plaintext key to memory. Instead, it is kept in one of the CAAM-internal key
registers. There, it can be used for cryptographic operations (i.e. AES). This
way, the plaintext key is protected even from the kernel. The kernel could keep
a copy of in sealed form, so it can reload the CAAM's key register when needed.


Pankaj, is that the mode you intend to support with this series?

Could you describe the high-level use-cases this would be need for, compared to
the existing mode where plaintext keys are accessible to the kernel? In which
cases would you use each mode?

Regards,
Jan

Michael Walle Sept. 7, 2022, 8:11 a.m. UTC | #8

Hi David,

Am 2022-09-07 09:46, schrieb David Gstir:
>> On 07.09.2022, at 09:29, Michael Walle <[e-mail]> wrote:
>> 
>> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>>>> -----Original Message-----
>>>> From: Michael Walle <[e-mail]>
>>>> Sent: Tuesday, September 6, 2022 12:43 PM
>>>> To: Pankaj Gupta <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; 
>>>> [e-mail];
>>>> [e-mail]; [e-mail]; 
>>>> linux-
>>>> [e-mail]; Sahil Malhotra
>>>> <[e-mail]>; Kshitiz Varshney 
>>>> <[e-mail]>;
>>>> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
>>>> 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.

Pankaj Gupta Sept. 7, 2022, 9:57 a.m. UTC | #9

> -----Original Message-----
> From: Michael Walle <[e-mail]>
> Sent: Wednesday, September 7, 2022 1:42 PM
> To: David Gstir <[e-mail]>
> Cc: Pankaj Gupta <[e-mail]>; Ahmad Fatoum
> <[e-mail]>; Jarkko Sakkinen <[e-mail]>;
> [e-mail]; James Bottomley <[e-mail]>; Mimi Zohar
> <[e-mail]>; David Howells <[e-mail]>; Sumit
> Garg <[e-mail]>; [e-mail]; James Morris
> <[e-mail]>; Serge E. Hallyn <[e-mail]>; Herbert Xu
> <[e-mail]>; David S. Miller <[e-mail]>;
> Jan Luebbe <[e-mail]>; Eric Biggers <[e-mail]>;
> Richard Weinberger <[e-mail]>; [e-mail]; linux-
> [e-mail]; [e-mail]; linux-
> [e-mail]; [e-mail]; Sahil
> Malhotra <[e-mail]>; Kshitiz Varshney
> <[e-mail]>; Horia Geanta <[e-mail]>;
> Varun Sethi <[e-mail]>
> 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 <[e-mail]> wrote:
> >>
> >> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
> >>>> -----Original Message-----
> >>>> From: Michael Walle <[e-mail]>
> >>>> Sent: Tuesday, September 6, 2022 12:43 PM
> >>>> To: Pankaj Gupta <[e-mail]>
> >>>> Cc: [e-mail]; [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail];
> [e-mail];
> >>>> [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail];
> >>>> [e-mail];
> >>>> linux-
> >>>> [e-mail]; Sahil Malhotra
> >>>> <[e-mail]>; Kshitiz Varshney
> >>>> <[e-mail]>; Horia Geanta <[e-mail]>;
> >>>> Varun Sethi <[e-mail]>
> >>>> 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.

Pankaj Gupta Sept. 7, 2022, 9:57 a.m. UTC | #10

> -----Original Message-----
> From: Jan Lübbe <[e-mail]>
> Sent: Wednesday, September 7, 2022 1:41 PM
> To: Pankaj Gupta <[e-mail]>; Jarkko Sakkinen
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]; Sahil Malhotra
> <[e-mail]>; Kshitiz Varshney <[e-mail]>;
> Horia Geanta <[e-mail]>; Varun Sethi <[e-mail]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
> 
> Caution: EXT Email
> 
> On Wed, 2022-09-07 at 07:22 +0000, Pankaj Gupta wrote:
> > Even if somehow the key is retrieved from the keyring, the retrieved
> > key would be an encrypted key.
> > This encrypted key can only be decrypted by Hardware, which generated it.
> >
> > Hence, the retrieved key is unusable outside of the hardware.
> 
> NXP's CAAM unit (i.e. on i.MX6) supports several modes of sealed/encrypted
> keys.
> The (un)sealing process uses a key that is normally derived from a per-device
> key in eFUSES. One aspect of these modes is whether the plaintext key
> material is accessible to the kernel or not.
> 
> Ahmad's patch set added support for a mode where the CAAM is used to
> seal plaintext known to the kernel to a "blob" (in CAAM terminology) on
> export to userspace and the reverse on import. This mode allows the kernel
> to use the plaintext for dm-crypt, to encrypt other keyrings and similar.
> 
> The CAAM has another sealing mode, where it will not allow writing of the
> plaintext key to memory. Instead, it is kept in one of the CAAM-internal key
> registers. There, it can be used for cryptographic operations (i.e. AES). This
> way, the plaintext key is protected even from the kernel. The kernel could
> keep a copy of in sealed form, so it can reload the CAAM's key register when
> needed.
> 
> 
> Pankaj, is that the mode you intend to support with this series?
Yes, this is what is called as "black key", in CAAM terminology.
Black key is nothing but a HBK key.
This is what I am trying to achieve with this patch-set.

> 
> Could you describe the high-level use-cases this would be need for,
> compared to the existing mode where plaintext keys are accessible to the
> kernel? In which cases would you use each mode?
> 

High-level Use-case is to ensure runtime security.
By runtime security, I mean, key that is added to keyring after blob-decapsulation, 
- if get  stolen, then being plain key, security can be compromised.
- After this patch-set, if key get stolen, then being HBK(encrypted by H/W), will not be of any use without HW. Security is not   compromised.

> Regards,
> Jan
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=05%7C01%7Cpankaj.gupta%40nxp.com%7Cb
> 1335df185404e02df1108da90a8886c%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637981350763081319%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&amp;sdata=aNxEETFYLc74F%2BOq9IK3p63tniVfczpgslG3LYe
> ZzAo%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: [phone]    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   [phone]-5555 |