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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Sep 2022 07:22:45 +0000
From:   Pankaj Gupta <pankaj.gupta@....com>
To:     Michael Walle <michael@...le.cc>
CC:     "jarkko@...nel.org" <jarkko@...nel.org>,
        "a.fatoum@...gutronix.de" <a.fatoum@...gutronix.de>,
        "Jason@...c4.com" <Jason@...c4.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "sumit.garg@...aro.org" <sumit.garg@...aro.org>,
        "david@...ma-star.at" <david@...ma-star.at>,
        "john.ernberg@...ia.se" <john.ernberg@...ia.se>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "j.luebbe@...gutronix.de" <j.luebbe@...gutronix.de>,
        "ebiggers@...nel.org" <ebiggers@...nel.org>,
        "richard@....at" <richard@....at>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        Sahil Malhotra <sahil.malhotra@....com>,
        Kshitiz Varshney <kshitiz.varshney@....com>,
        Horia Geanta <horia.geanta@....com>,
        Varun Sethi <V.Sethi@....com>
Subject: RE: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY



> -----Original Message-----
> From: Michael Walle <michael@...le.cc>
> Sent: Tuesday, September 6, 2022 12:43 PM
> To: Pankaj Gupta <pankaj.gupta@....com>
> Cc: jarkko@...nel.org; a.fatoum@...gutronix.de; Jason@...c4.com;
> jejb@...ux.ibm.com; zohar@...ux.ibm.com; dhowells@...hat.com;
> sumit.garg@...aro.org; david@...ma-star.at; john.ernberg@...ia.se;
> jmorris@...ei.org; serge@...lyn.com; herbert@...dor.apana.org.au;
> davem@...emloft.net; j.luebbe@...gutronix.de; ebiggers@...nel.org;
> richard@....at; keyrings@...r.kernel.org; linux-crypto@...r.kernel.org;
> linux-integrity@...r.kernel.org; linux-kernel@...r.kernel.org; linux-
> security-module@...r.kernel.org; Sahil Malhotra
> <sahil.malhotra@....com>; Kshitiz Varshney <kshitiz.varshney@....com>;
> Horia Geanta <horia.geanta@....com>; Varun Sethi <V.Sethi@....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