Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

* Proposal for the ASN.1 form of TPM1.2 and TPM2 keys
@ 2016-12-23 18:06 James Bottomley
  2016-12-23 20:12 ` Richard Levitte
  2016-12-24 13:25 ` Nikos Mavrogiannopoulos
  0 siblings, 2 replies; 15+ messages in thread
From: James Bottomley @ 2016-12-23 18:06 UTC (permalink / raw
  To: openssl-dev-MCmKBN63+BlAfugRpC6u6w,
	gnutls-devel-f8S/fY/i+OXSWulAQ3bEYg,
	tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	trousers-tech-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
  Cc: David Woodhouse

The reason this comes about is because we already have a standard form
for TPM 1.2 keys here:

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm

However, since I'm working on TPM2 enabling for openssl and gnutls, I
need to come up with a new key format because TPM2 requires some extra
parameters and the original TSS KEY BLOB, being a single
ASN1_OCTET_STRING isn't expandable.

As a digression, the extra parameters that TPM2 needs are:

   1. A public key blob.  In TPM12 the key complex was a joint
      public/private part.  In TPM2, the public and private key structures
      have variable length and are supplied separately.
   2. a boolean for emptyAuth.  In TPM12 there's a way to tell if a
      structure has no authorization.  In TPM2 there's no such thing as no
      authorization, but there's a conventional empty authorization to
      replace it but no way of querying whether any given key is using it,
      so we need to know explicitly whether to prompt for a password or
      not.
   3. There are different forms a TPM private key could be in.  One is
      symmetrically encrypted with a TPM private key, which makes it
      loadable, meaning it must be produced on the TPM itself and the
      other is asymmetrically encrypted meaning it can be produced away
      from the TPM but must be imported before being loaded.

I think there's value in having a universal structure for the key
representations, so I'm proposing an ASN1 representation that will work
for both TPM1.2 and TPM2 keys.  I'd also like it to be self describing,
so I think we should use an OID as the initial parameter of the
sequence.  With that, I think the format that works is

TPMKey ::= SEQUENCE {
	type		OBJECT IDENTIFIER
	version		[0] IMPLICIT INTEGER OPTIONAL
	emptyAuth	[1] IMPLICIT BOOLEAN OPTIONAL
	parent		[2] IMPLICIT INTEGER OPTIONAL
	publicKey	[3] IMPLICIT OCTET STRING OPTIONAL
	privateKey	OCTET STRING
}

Where TPM12 keys would have a TPM12Key type and use no optional fields
(meaning only privateKey) and TPM2 keys would have type TPM2LoadableKey
or TPM2ImportableKey type and then make use of all the optional fields
(except version).

Version is there for future expansion, but is unused in the initial
incarnation.

I'm torn on where to get the OIDs from.  Since this is a TPM key, it
might make sense to use the TCG OID (2.23.133) and just add something
they haven't already used, like 10 for key formats, or we could go with
a pkcs OID (1.2.840.113549.1)

If we can agree on this, we can update David's document and make it a
formal RFC.

Thoughts?

James

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread