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 10:11:40 +0200
From:   Michael Walle <michael@walle.cc>
To:     David Gstir <david@sigma-star.at>
Cc:     Pankaj Gupta <pankaj.gupta@nxp.com>,
        Ahmad Fatoum <a.fatoum@pengutronix.de>,
        Jarkko Sakkinen <jarkko@kernel.org>, Jason@zx2c4.com,
        James Bottomley <jejb@linux.ibm.com>,
        Mimi Zohar <zohar@linux.ibm.com>,
        David Howells <dhowells@redhat.com>,
        Sumit Garg <sumit.garg@linaro.org>, john.ernberg@actia.se,
        James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Jan Luebbe <j.luebbe@pengutronix.de>,
        Eric Biggers <ebiggers@kernel.org>,
        Richard Weinberger <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>,
        =?UTF-8?Q?Horia_Geant=C4=83?= <horia.geanta@nxp.com>,
        Varun Sethi <V.Sethi@nxp.com>
Subject: Re: [EXT] [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
In-Reply-To: <1E73DC47-9494-453C-899D-CE386336EF8D@sigma-star.at>
References: <20220906065157.10662-1-pankaj.gupta@nxp.com>
 <047746e1134d5bdce699d8c021f849b6@walle.cc>
 <DU2PR04MB8630C63609D6D785F12DEC6E95419@DU2PR04MB8630.eurprd04.prod.outlook.com>
 <5d67b4d45aa1b2a3d2738c93edaeffdd@walle.cc>
 <1E73DC47-9494-453C-899D-CE386336EF8D@sigma-star.at>
User-Agent: Roundcube Webmail/1.4.13
Message-ID: <9f6fbc2b549fe8bca8a442a5bcaa1942@walle.cc>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi David,

Am 2022-09-07 09:46, schrieb David Gstir:
>> On 07.09.2022, at 09:29, Michael Walle <michael@walle.cc> wrote:
>> 
>> 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.
> 
> 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

> 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.