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;
From:   Pankaj Gupta <pankaj.gupta@nxp.com>
To:     Michael Walle <michael@walle.cc>
CC:     "jarkko@kernel.org" <jarkko@kernel.org>,
        "a.fatoum@pengutronix.de" <a.fatoum@pengutronix.de>,
        "Jason@zx2c4.com" <Jason@zx2c4.com>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "zohar@linux.ibm.com" <zohar@linux.ibm.com>,
        "dhowells@redhat.com" <dhowells@redhat.com>,
        "sumit.garg@linaro.org" <sumit.garg@linaro.org>,
        "david@sigma-star.at" <david@sigma-star.at>,
        "john.ernberg@actia.se" <john.ernberg@actia.se>,
        "jmorris@namei.org" <jmorris@namei.org>,
        "serge@hallyn.com" <serge@hallyn.com>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "j.luebbe@pengutronix.de" <j.luebbe@pengutronix.de>,
        "ebiggers@kernel.org" <ebiggers@kernel.org>,
        "richard@nod.at" <richard@nod.at>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-security-module@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
Thread-Topic: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
Thread-Index: AQHYwbSICZxhOSR7uk+zrvSafpZt0K3R/KiAgAFrQaA=
Date:   Wed, 7 Sep 2022 07:22:45 +0000
Message-ID: <DU2PR04MB8630C63609D6D785F12DEC6E95419@DU2PR04MB8630.eurprd04.prod.outlook.com>
References: <20220906065157.10662-1-pankaj.gupta@nxp.com>
 <047746e1134d5bdce699d8c021f849b6@walle.cc>
In-Reply-To: <047746e1134d5bdce699d8c021f849b6@walle.cc>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SQ2dVF7LrlUSSS7pGU6p8m/eI5eg1fkV8hV04Sv31WPwalYhiE2ICOCb2Aj+?=
 =?us-ascii?Q?8aR/oTU4c+hQUSlQ2axR82lQmrsJdlFtUicVRPp0QtN8zr45EtPsL8XwSLfT?=
 =?us-ascii?Q?nyb/WRijwgjFS1ShXREDVDL63SIo1CMst8wHSnGk49w6fI7nBQKx0R+vou14?=
 =?us-ascii?Q?zH7OhNQkFapRj75e1AcCjAP2I3iXYnPtgu3dFTlexpDypCKWCNOL1eGuJWFO?=
 =?us-ascii?Q?zDalOVQvsSNWan5M/UOXxtkRJBuSStrpu0gWLU+iqTCV6r2ovQ5JsERRht8w?=
 =?us-ascii?Q?NUjce55BfkrMDwsJq/Qnff6jVMk6QykbxUqWoNQ/aZ4nB+aQk/MvCW9E+Chx?=
 =?us-ascii?Q?pViTTgpYgVH9zH2V3edZ1hyBhx+eczaWcDrX6AhZE8mlMCaT5Zv3jjXvEAe9?=
 =?us-ascii?Q?TiYs0VqnXgL11SXkFdo2XuntdU5UAvjdEpFHfuvQcVfhecjV3IQ24hdnuFHY?=
 =?us-ascii?Q?r6Tah/f83KJvSvEw0YSmz0u91zVH6eMsMsMhi7BWCNIMbdflIP73MkMrDWdb?=
 =?us-ascii?Q?3HsuMxm12Feg+cmYwSuy9brKHwKlRzFNdVFlmFL4HbqWWyfLWjdqoA5MxnmE?=
 =?us-ascii?Q?yBH0rXb6Xbsf7YY41vqjAXahYXxwzJVE6vIdOyxhM5MxpoP8EwhPvXM7FSIs?=
 =?us-ascii?Q?hyys3S2/cKk7dNHkXWFt6opKCvtf8jgRoLNsfX9nGcDCTQFPEOHpj11d+T14?=
 =?us-ascii?Q?95r83KLkPXExfFMf8bVhdHOJpAVWY/7vznWKRF7prpjiDYb36vzhPdWJqwo2?=
 =?us-ascii?Q?/TgSfYPAQRrHUVcaVLO/lmyApr/+dah5Qcg3zwEgfm5RZiaXijakEp11F16E?=
 =?us-ascii?Q?bxHtoRKZBhlipCCLRGBCvU7ccuL7tKXZP67JnB1FPtJ/1AnT/svxr/4yB2Np?=
 =?us-ascii?Q?KXpoD5kD0Jb9wSYS7fFPEly4kKyBJ471UMrnqcIgIZuerr8wzOpCDzJLJdAa?=
 =?us-ascii?Q?0IPv+DQpCcmrzz97gJKPaKDTIqGpRgddZvC8ocpFIbZZvz0oLH8R04qM31oc?=
 =?us-ascii?Q?X6Ty9vv+qMAhid1v7NJFBVlEwWveK3HXDrb3pioVv84PKoGn9rlrV9+oAtVr?=
 =?us-ascii?Q?SgO97o1VNAjz8k3g5+ArgjDtyu4QHYOjO2pFS4mLVy9ISsUk4W4qpVeQ+SBa?=
 =?us-ascii?Q?4kmciece3Q1YHiXsV+hiYkYVNQ8sg3PDvyDB14FPSQJQs5ehv4WqNGXtqu7s?=
 =?us-ascii?Q?3WUBIPzsPLU9TOMAUKGvVTb+NFXrfZDYFBUyKL9oExCOBiYHQvrvamoB5CyL?=
 =?us-ascii?Q?ozb4CFWorNvgmdDlBtHJDG3PRi/t1/I7L5/bVeYI59sEP5VNKTbaQjipX8I1?=
 =?us-ascii?Q?chE+6ok1tdVfDMrniGYKSZ7v0sAWPA8UHnU2kxwgD6+CBlr6swcOtn4JZdbP?=
 =?us-ascii?Q?fAMuuht70AlHKYtblvP273TCt1a6VJDHsWenliPvXEOGHvsDhBS64UU4oWiH?=
 =?us-ascii?Q?PugG3hYKbkQrbbGXoKNLtEx1WQXZf/wiqEbAAe9gDORTOnukEjImyE0aFJ0t?=
 =?us-ascii?Q?9gQIXc5aKUwl8xClQdI/b6woCXaWLIZlDh71cG5PChoruiLOyfkYbEuQBxzR?=
 =?us-ascii?Q?9mOaGwDpwiqqIIVwZqcyHR0eD8ObdXjKrkS0mk3y?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8630.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cbc5f80-4018-432f-eb47-08da90a1c274
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2022 07:22:45.2454
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lmISo6ei1cjbQynwu0JQuNYT2hw4oqSWIW72A/C9zOmiSvHTxM3fuobLaOiI+uZe9Tk3wsaAz0wr1T82OO0yqg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB4004
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> -----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
>=20
> Caution: EXT Email
>=20
> Hi,
>=20
> 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.
>=20
> 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 seale=
d
> key on another board with the same SoC.
>=20

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 pla=
in 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.
=20

> -michael