lkml.org 
[lkml]   [2022]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
    Date


    > -----Original Message-----
    > From: Michael Walle <michael@walle.cc>
    > Sent: Tuesday, September 6, 2022 12:43 PM
    > To: Pankaj Gupta <pankaj.gupta@nxp.com>
    > Cc: jarkko@kernel.org; a.fatoum@pengutronix.de; Jason@zx2c4.com;
    > jejb@linux.ibm.com; zohar@linux.ibm.com; dhowells@redhat.com;
    > sumit.garg@linaro.org; david@sigma-star.at; john.ernberg@actia.se;
    > jmorris@namei.org; serge@hallyn.com; herbert@gondor.apana.org.au;
    > davem@davemloft.net; j.luebbe@pengutronix.de; ebiggers@kernel.org;
    > richard@nod.at; keyrings@vger.kernel.org; linux-crypto@vger.kernel.org;
    > linux-integrity@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
    > security-module@vger.kernel.org; Sahil Malhotra
    > <sahil.malhotra@nxp.com>; Kshitiz Varshney <kshitiz.varshney@nxp.com>;
    > Horia Geanta <horia.geanta@nxp.com>; Varun Sethi <V.Sethi@nxp.com>
    > 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

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