lkml.org 
[lkml]   [2022]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
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

\
 
 \ /
  Last update: 2022-09-06 09:14    [W:0.296 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site