Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

On Thu, 2021-04-01 at 18:50 +0530, Sumit Garg wrote:

On Thu, 1 Apr 2021 at 15:36, Ahmad Fatoum [off-list ref]
wrote:

quoted

Hello Richard,

On 31.03.21 21:36, Richard Weinberger wrote:

quoted

James,

----- Ursprüngliche Mail -----

quoted

Von: "James Bottomley" [off-list ref]
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.

I like this idea.
Ahmad, what do you think?

That way we could also get rid off the kernel parameter and all
the fall back logic,
given that we find a way to reliable detect TEE blobs too...

Sounds good to me. Sumit, your thoughts on doing this for TEE as
well?

AFAIU, ASN.1 formating should be independent of trusted keys backends
which could be abstracted to trusted keys core layer so that every
backend could be plugged in seamlessly.

James,

Would it be possible to achieve this?

I'm not quite sure what you're asking.  The saved format of the keys is
particular to the underlying hardware.  The ASN.1 wraps this so we have
an identifier, some useful information to help load the key (like the
policy systemements) and then the blobs the hardware expects.

This makes the ASN.1 specific to the backend but having a
distinguishing OID that allows anyone to tell which backend it needs
from the file.

So you can call the ASN.1 format that begins with the type OID, the
"universal" format, but if you mean there should be a standard ASN.1
format for all keys that defines all the fields then that's not
possible because the fields after type are very specific to the
underlying hardware.

James