linux-kernel - RE: [EXT] [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]
Message-ID: <DU2PR04MB86307A87D2D1870C55E7E0D595419@DU2PR04MB8630.eurprd04.prod.outlook.com>
Date:   Wed, 7 Sep 2022 09:57:50 +0000
From:   Pankaj Gupta <pankaj.gupta@....com>
To:     Michael Walle <michael@...le.cc>, David Gstir <david@...ma-star.at>
CC:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        "Jason@...c4.com" <Jason@...c4.com>,
        James Bottomley <jejb@...ux.ibm.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Sumit Garg <sumit.garg@...aro.org>,
        "john.ernberg@...ia.se" <john.ernberg@...ia.se>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Jan Luebbe <j.luebbe@...gutronix.de>,
        Eric Biggers <ebiggers@...nel.org>,
        Richard Weinberger <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] [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY



> -----Original Message-----
> From: Michael Walle <michael@...le.cc>
> Sent: Wednesday, September 7, 2022 1:42 PM
> To: David Gstir <david@...ma-star.at>
> Cc: Pankaj Gupta <pankaj.gupta@....com>; Ahmad Fatoum
> <a.fatoum@...gutronix.de>; Jarkko Sakkinen <jarkko@...nel.org>;
> Jason@...c4.com; James Bottomley <jejb@...ux.ibm.com>; Mimi Zohar
> <zohar@...ux.ibm.com>; David Howells <dhowells@...hat.com>; Sumit
> Garg <sumit.garg@...aro.org>; john.ernberg@...ia.se; James Morris
> <jmorris@...ei.org>; Serge E. Hallyn <serge@...lyn.com>; Herbert Xu
> <herbert@...dor.apana.org.au>; David S. Miller <davem@...emloft.net>;
> Jan Luebbe <j.luebbe@...gutronix.de>; Eric Biggers <ebiggers@...nel.org>;
> Richard Weinberger <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: 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 <michael@...le.cc> wrote:
> >>
> >> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
> >>>> -----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.
> >>
> >> 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.