Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
Date:   Wed, 07 Sep 2022 09:29:01 +0200
From:   Michael Walle <michael@walle.cc>
To:     Pankaj Gupta <pankaj.gupta@nxp.com>, a.fatoum@pengutronix.de
Cc:     jarkko@kernel.org, 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: Re: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
In-Reply-To: <DU2PR04MB8630C63609D6D785F12DEC6E95419@DU2PR04MB8630.eurprd04.prod.outlook.com>
References: <20220906065157.10662-1-pankaj.gupta@nxp.com>
 <047746e1134d5bdce699d8c021f849b6@walle.cc>
 <DU2PR04MB8630C63609D6D785F12DEC6E95419@DU2PR04MB8630.eurprd04.prod.outlook.com>
User-Agent: Roundcube Webmail/1.4.13
Message-ID: <5d67b4d45aa1b2a3d2738c93edaeffdd@walle.cc>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>> -----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.

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