On Wed, 2021-03-31 at 20:36 +0200, Richard Weinberger wrote: > James, > > ----- Ursprüngliche Mail ----- > > Von: "James Bottomley" <jejb@xxxxxxxxxxxxx> > > > On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum < > > > a.fatoum@xxxxxxxxxxxxxx wrote: > > > > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s > > > > > > Is there a reason why we can't pass the desired backend name in > > > the > > > trusted key parameters? > > > e.g. > > > keyctl add trusted $KEYNAME "backendtype caam load $(cat > > > ~/kmk.blob)" > > > @s > > > > Why would you want to in the load? The blob should be type > > specific, so a TPM key shouldn't load as a CAAM key and vice versa > > ... and if they're not they need to be made so before the patches > > go upstream. > > I fear right now there is no good way to detect whether a blob is > desired for CAAM or TPM. At least for the TPM the old format is two TPM2B structures, and the new one is ASN.1 so either should be completely distinguishable over what CAAM does. > > I could possibly see that you might want to be type specific in the > > create, but once you're simply loading an already created key, the > > trusted key subsystem should be able to figure what to do on its > > own. > > So you have some kind of container format in mind which denotes the > type of the blob? Well, yes. For the TPM, there's a defined ASN.1 format for the keys: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-asn.h and part of the design of the file is that it's distinguishable either in DER or PEM (by the guards) format so any crypto application can know it's dealing with a TPM key simply by inspecting the file. I think you need the same thing for CAAM and any other format. We're encouraging new ASN.1 formats to be of the form SEQUENCE { type OBJECT IDENTIFIER ... key specific fields ... } Where you choose a defined OID to represent the key and that means every key even in DER form begins with a unique binary signature. James
