Re: [PATCH v2 6/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Richard Weinberger <richard@nod.at>
Cc: Jonathan Corbet <corbet@lwn.net>,
	David Howells <dhowells@redhat.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	James Bottomley <jejb@linux.ibm.com>,
	Mimi Zohar <zohar@linux.ibm.com>, kernel <kernel@pengutronix.de>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	horia geanta <horia.geanta@nxp.com>,
	aymen sghaier <aymen.sghaier@nxp.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	davem <davem@davemloft.net>, Udit Agarwal <udit.agarwal@nxp.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Jan Luebbe <j.luebbe@pengutronix.de>, david <david@sigma-star.at>,
	Franck Lenormand <franck.lenormand@nxp.com>,
	Sumit Garg <sumit.garg@linaro.org>,
	"open list, ASYMMETRIC KEYS" <keyrings@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	LSM <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v2 6/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Date: Fri, 2 Jul 2021 14:33:52 +0200	[thread overview]
Message-ID: <ac8ef66f-4d57-ead0-d1b3-e97220463241@pengutronix.de> (raw)
In-Reply-To: <783613027.15909.1625223222889.JavaMail.zimbra@nod.at>

On 02.07.21 12:53, Richard Weinberger wrote:
> Ahmad,
> 
> ----- Ursprüngliche Mail -----
>> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
>>> I'm still think that hard coding the key modifier is not wise.
>>> As I said[0], there are folks out there that want to provide their own modifier,
>>> so it is not only about being binary compatible with other CAAM blob patches in
>>> the wild.
>>
>> I don't think the characterization as a salt is accurate. AFAIU it's more
>> of a namespace, so blobs being loaded are "type-checked" against the modifier.
> 
> Well, the CAAM programmer's reference manual states that the blob key is a 128 bit modifier
> and has two purposes:
> 1. It can be used as tag to provide separation between blobs to detect accidental replacement of blobs.
> 2. But it can also be treated as secret to provide additional protection. Because the blob encryption
> key derivation includes the key modifier.
> 
> While you have case 1 in mind, I care about case 2. :-)

Ah, using the key modifier as a passphrase didn't occur to me.

>>> I'll happily implement that feature after your patches got merged but IMHO we
>>> should first agree on an interface.
>>> How about allowing another optional parameter to Opt_new and Opt_load
>>
>> Sound good to me. pcrlock for TPM trusted keys has the same interface.
>>
>> I'd prefer the new option to accept strings, not hex though.
> 
> Both is possible. If the string starts with "0x" it needs to be decoded to a
> 128 bit key. Otherwise it has to be a up to 16 byte string.

Fine by me. Looking forward to your patches. :-)

Cheers,
Ahmad

> 
> Thanks,
> //richard
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |