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:     Jarkko Sakkinen <jarkko@kernel.org>
CC:     "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>,
        "michael@walle.cc" <michael@walle.cc>,
        "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+zrvSafpZt0K3SGjKAgAFFWYA=
Date:   Wed, 7 Sep 2022 07:22:48 +0000
Message-ID: <DU2PR04MB86303DE3507B6FF37BD5B6A595419@DU2PR04MB8630.eurprd04.prod.outlook.com>
References: <20220906065157.10662-1-pankaj.gupta@nxp.com>
 <YxcLqepquOuOOjvq@kernel.org>
In-Reply-To: <YxcLqepquOuOOjvq@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NqSdpXSNtGMRmspYUbEbaIc+g3Q+awrdQ2itfCx4pQ2oHbycze1b4lxfNbBw?=
 =?us-ascii?Q?WQSaA6PMnWMiNwEQCkCv3w4Z4g0KqkKNVmK9dzADImQucSoE0PJ3oLgi9Dlz?=
 =?us-ascii?Q?cEt1TXE209YjZ9B+NfosAl00hx5NK6MH42XGvqro3hmhIpRLjm0pv6si2uqn?=
 =?us-ascii?Q?t7EFTKbkT68aGGiNxZY0RFapcUlDE9nvp6iIawGV0Z38Pu1uOOQEZlOTCOaW?=
 =?us-ascii?Q?m2JYB+JkRL5LNmyxhH8FGnGnqfFmyaORkHAWBXHTSZRW94xlTi7ks1uNZRDj?=
 =?us-ascii?Q?uDOReqYpJwD+cMlFNHDkYdJKLY9kGpybb7eHLZBKiSWWKiV7MmIsqBO5IrF+?=
 =?us-ascii?Q?N+WEvGBqI/kpQn3Cec8naEcuacT2CnVWz9ZAtR+VIcmm79OWquFsb+lEKH+o?=
 =?us-ascii?Q?HUnPC1+xfglgSxPMJqRuHLEFQQTR8Yp0t+8u2J9a3N4RoxL5WzfZcPXE9ler?=
 =?us-ascii?Q?D82XpT3zgT3Vm7Dm+krRKmGC0mBv49HDJr53SPQchGGmcft14iOdZBcPbQYO?=
 =?us-ascii?Q?30W+TpFI8JQgxNrAotsNb5cnB1WSr0tZUJVbMDQhiRMj6vnJbLVXOpLwRsfl?=
 =?us-ascii?Q?Rdf/LCfO+IvJYb968YzQdp8boyF5NQm6Q4kbabWMTSYGSwMv9pemmOv3iRqv?=
 =?us-ascii?Q?DW0sa2PnfOuxQyoOX4IhboTL34m9FChZOFW9MYvXtqSuDDKZZIziwh48JGLA?=
 =?us-ascii?Q?vhywUfElEd+j/MtCoo7CSk83FxA3euGN7IGix3s2EAOoUHe8prJjgtwIgFBy?=
 =?us-ascii?Q?CHY9evxmeST8kKmGPZpkPNOXp3OdBG8tZcehLGj5FOMT4ICwQzRPjapfvBYQ?=
 =?us-ascii?Q?+FOuC7eEVipX+q9NCF6o+Kq/HisCN42CTsWkFBbAOs4p1c+C4/VhzatjEivr?=
 =?us-ascii?Q?Yy0brIdqydlf+KRLuj0BUeCUCZZXxmU/niKapJ3wo8Mjands6XuTgXhdmOIS?=
 =?us-ascii?Q?BBDfdO0A2IuPsIppsOAWgkMbCcBoEkd+xuah/CeTDexLQFfnUSBixS/eeLBQ?=
 =?us-ascii?Q?a/NF/vCp7Moe/q0+anOgHSxTDABgDdHCcd+iiI/Tf7PUrN730iAegTwxiMpf?=
 =?us-ascii?Q?vUc58gFU7oZXxnkujEfgBDMfd3uzvFA1o27ehA32h26HTiUEb8uJmCMPurSp?=
 =?us-ascii?Q?xqe5wObD9RdlahqzQalaFbA5ufBwmKmnyrVCZHlSTy2dr2B5hjiMYPieC+Dq?=
 =?us-ascii?Q?XH9JcRxQnST0ABrwZnXMIgh6g2KOOT527PmTwbHazjIUE9Em81O3DY/E2hVz?=
 =?us-ascii?Q?npSAB1P2F1WVue+g9uvCYORuvjtMEescRR3dl+Cb1LBuv0+TVBRxgeidVgcZ?=
 =?us-ascii?Q?J+FD/Mm37OPexwfUdFJtCtHE7Zoxb6XS/uHVfXoOcz6rpqTr4LQptVFKzpCA?=
 =?us-ascii?Q?NZ3E0XSAgHor/76F5zStIy5TzYU2SjVYVnx5Zvqi+74yq2lhsbnCQtGL5R3I?=
 =?us-ascii?Q?Ggn7dYZfO0I2XovPw4xy9KLdf2exPVyME/Qt3wvs0zB4BMPEqXifMfYkQgRk?=
 =?us-ascii?Q?8fuZwQPR9fnw5tKiuSrztTCj/JUaJAYt/MhYxuQ6WrEfjk2my27KagAUIeIm?=
 =?us-ascii?Q?uBY++U7VmFovzoNlLXFcJUaWWTHi7LaxAgd//M+Y?=
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: 18644122-35f9-4231-5e57-08da90a1c441
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2022 07:22:48.2787
 (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: 8yEmJZ2JrUa4E8J86O/SEMsXrxyYAU5IgVr8U3RlD+y2FYt5F078Z50csZTnAnleO95+OuZBq+ljKfMhtsm8Sw==
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: Jarkko Sakkinen <jarkko@kernel.org>
> Sent: Tuesday, September 6, 2022 2:28 PM
> To: Pankaj Gupta <pankaj.gupta@nxp.com>
> Cc: 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; michael@walle.cc; 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
> On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> > Hardware Bound key(HBK), is never acessible as plain key outside of
> > the
>                                     ~~~~~~~~~
>                                     accesible.
>=20
> > hardware boundary. Thus, it is un-usable, even if somehow fetched from
> > kernel memory. It ensures run-time security.
>=20
> Why is it called "HBK" here and "hw" in the context of keyctl?
It is HBK, because the key is bounded to the Hardware. As:
- Key is generated by hardware.
- Key can only be used by hardware.
- Stored as a blob by the hardware.

>=20
> > 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.
>=20
> CAAM is implementation of what exactly?


CAAM is the chip's cryptographic acceleration and offloading hardware and c=
ombines cryptographic and other mathematical
functions to create a modular and scalable hardware acceleration and assura=
nce engine. In context to this patchset, CAAM implements the following func=
tions:
- Generates HBK
- Generates key-blob, from HBK, for security at rest.
- Perform crypto operations, using HBK.=20

>=20
> I'm sorry but I don't know your definition of unusable.

Even if somehow the key is retrieved from the keyring, the retrieved key  w=
ould be an encrypted key.
This encrypted key can only be decrypted by Hardware, which generated it.

Hence, the retrieved key is unusable outside of the hardware.

>=20
> BR, Jarkko