Re: [tpm2] Conflicting TPM2 engines and storage formats

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]



> -----Original Message-----
> From: tpm2 [mailto:tpm2-bounces(a)lists.01.org] On Behalf Of David Woodhouse
> Sent: Wednesday, October 3, 2018 7:06 AM
> To: James Bottomley <James.Bottomley(a)Hansenpartnership.com>; Fuchs,
> Andreas <andreas.fuchs(a)sit.fraunhofer.de>; tpm2(a)lists.01.org; Nikos
> Mavrogiannopoulos <n.mavrogiannopoulos(a)gmail.com>
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
> 
> On Wed, 2018-10-03 at 13:00 +0200, James Bottomley wrote:
> > On October 3, 2018 12:47:15 PM CEST, David Woodhouse
> <dwmw2(a)infradead.org> wrote:
> > > On Wed, 2018-10-03 at 12:40 +0200, James Bottomley wrote:
> > > > > --- a/src/tpm2-tss-engine-common.h
> > > > > +++ b/src/tpm2-tss-engine-common.h
> > > > > @@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx,
> > > > > ESYS_TR *keyHandle,
> > > > >          .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \
> > > > >                               TPMA_OBJECT_RESTRICTED | \
> > > > >                               TPMA_OBJECT_DECRYPT | \
> > > > > -                             TPMA_OBJECT_FIXEDTPM | \
> > > > > -                             TPMA_OBJECT_FIXEDPARENT | \
> > > > > +                             TPMA_OBJECT_NODA | \
> > > >
> > > > This is the only troubling change, the rest looks fine to me.  The
> > > > template for a TPM created key *must* contain those two flags.
> > > > NODA
> > >
> > > is
> > > > one of those things which should be specified on the command line
> > > > rather than hard coded as well.  So to be exact, you need an extra
> > > > command line flag for whether or not you want TPMA_OBJECT_NODA
> > > > (some keys would like DA protection, especially private VPN ones,
> > > > but the creator of the key should ultimately decide) and if you
> > > > have a TPM create key you need TPMA_OBJECT_FIXEDTPM and
> > > > TPMA_OBJECT_FIXEDPARENT but if you're wrapping an existing key they
> have to be clear.

You could rip off the attribute parsing code from tpm2-tools if you wanted, lets you do things like:
--<option-name> 'restricted|decrypt|ficedtpm|noda'

Granted, it's not the most user-friendly if all you care about is toggling noda, but it is
flexible.

> > >
> > > This is for generating the primary key. It looks like your code
> > > always sets NODA, but *not* FIXEDTPM and FIXEDPARENT.
> > >
> > > The tpm2-tss engine does set FIXEDTPM and FIXEDPARENT, but not NODA.
> > >
> > > As noted, the above patch comes from blindly making tpm2-tss-engine
> > > look like your code, without even looking at what the flags mean :)
> > >
> > > I don't see why you set NODA on the primary key which has no auth
> > > anyway, and you seem to be saying that the lack of FIXED{TPM,PARENT}
> > > on your side is also problematic?
> >
> > For createprimary, noda is correct because it has no password.  Let me
> > check the fixeds. The primary should have them.  I'm boarding in Paris
> > at the moment but will check in-flight.
> >
> > > Does that mean we should be changing your code to match what's in
> > > tpm2-tss-engine?
> >
> > I think for the fixeds yes but likely it doesn't matter for the
> > primary because it will be assumed.
> 
> Whether it's assumed or not, changing it does appear to change the resulting
> primary so that it can no longer unwrap the previously- wrapped keys.

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

tpm2-tss-engine only supports P256 and P384. no other curves yet.
However, it should of course not SEGV; i.e. loadkey returns NULL back to OpenSSL
but that's the expected return for an error.
Could you trace the code line that SEGVs ? Whether it's the engine or OpenSSL ?
(I like to use valgrind for this)

cool; would it also make sense to export some symbols for GnuTLS and OpenConnect
to bind against; i.e. an engine that supports OpenSSL and GnuTLS at the same time ?
or 2 front ends and two back ends ?
________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Friday, October 12, 2018 17:19
To: Fuchs, Andreas; tpm2(a)lists.01.org; James Bottomley; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Fri, 2018-10-12 at 09:16 +0000, Fuchs, Andreas wrote:
> Thanks a lot for the effort and PR. I've reviewed it already with a
> slight change request.
>
> 0x1df means "Integrity Check failed". This could have to do with the
> manipulation of the public area, see my comment on the PR...

Doh. Sorry, yes that was it; can I blame the jet lag? I had originally
just hacked that with the  …exponent?:0x10001 GCC'ism, and was trying
to clean it up a little. A better variant in the PR now.

This works for my RSA key and for the ECC key from the OpenConnect test
suite — I can import them with either engine's tool, then use them from
all three.

With your engine I still see a SEGV when using a bnp256 key from
James's engine, but nistp256 is OK. I choose to declare that that one
Not My Fault™, but I'll try to reproduce with tpm2tss-genkey and file a
bug.

> Other than that: I'd be more than willing to join both engines under
> one project as long as it's BSD-3 and not (L)GPL.
> (the only reason we have a second engine to begin with)

I do like that idea, so the ENGINE interface is unified and only the
TPM back end varies. Otherwise we'll both be chasing STORE interface
stuff and "how do I tell OpenSSL not to negotiate SHA512" and other
crap, and dealing with the UI callbacks for various passwords in
different ways.

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Fri, 2018-10-12 at 09:16 +0000, Fuchs, Andreas wrote:
> Thanks a lot for the effort and PR. I've reviewed it already with a
> slight change request.
> 
> 0x1df means "Integrity Check failed". This could have to do with the
> manipulation of the public area, see my comment on the PR...

Doh. Sorry, yes that was it; can I blame the jet lag? I had originally
just hacked that with the  …exponent?:0x10001 GCC'ism, and was trying
to clean it up a little. A better variant in the PR now.

This works for my RSA key and for the ECC key from the OpenConnect test
suite — I can import them with either engine's tool, then use them from
all three.

With your engine I still see a SEGV when using a bnp256 key from
James's engine, but nistp256 is OK. I choose to declare that that one
Not My Fault™, but I'll try to reproduce with tpm2tss-genkey and file a
bug.

> Other than that: I'd be more than willing to join both engines under
> one project as long as it's BSD-3 and not (L)GPL.
> (the only reason we have a second engine to begin with)

I do like that idea, so the ENGINE interface is unified and only the
TPM back end varies. Otherwise we'll both be chasing STORE interface
stuff and "how do I tell OpenSSL not to negotiate SHA512" and other
crap, and dealing with the UI callbacks for various passwords in
different ways.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

Thanks a lot for the effort and PR. I've reviewed it already with a slight change request.

0x1df means "Integrity Check failed". This could have to do with the manipulation of the public area, see my comment on the PR...

Other than that: I'd be more than willing to join both engines under one project as long as it's BSD-3 and not (L)GPL.
(the only reason we have a second engine to begin with)

Cheers,
Andreas
________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Friday, October 12, 2018 07:55
To: Fuchs, Andreas; tpm2(a)lists.01.org; James Bottomley; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

I've now sent patches to James, submitted a PR to tpm2-tss-engine, and
modified my own OpenConnect code to support the same format:

TPMKey ::= SEQUENCE {
        type            OBJECT IDENTIFIER,
        emptyAuth       [0] EXPLICIT BOOLEAN OPTIONAL,
        parent          INTEGER,
        pubkey          OCTET STRING,
        privkey         OCTET STRING
 }

Both tpm2 and tpm2tss engines can read key files created with the
latter. However, I have not got it working the other way round. My
GnuTLS code can read files created by James's tpm2 engine but the
tpm2tss engine doesn't work...

Creating primary key under owner.
Loading key blob.
WARNING:esys:src/tss2-esys/api/Esys_Load.c:324:Esys_Load_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_Load.c:117:Esys_Load() Esys Finish ErrorCode (0x000001df)
WARNING:esys:src/tss2-esys/esys_context.c:117:Esys_Finalize() Finalizing NULL context.
140278476894656:error:8007106D:tpm2-tss-engine:init_tpm_key:Unknown TPM error occured. Please check tpm2tss logs:src/tpm2-tss-engine-common.c:292:
140278476894656:error:8008C06D:tpm2-tss-engine:rsa_priv_enc:Unknown TPM error occured. Please check tpm2tss logs:src/tpm2-tss-engine-rsa.c:161:
140278476894656:error:0D0DC006:asn1 encoding routines:ASN1_item_sign_ctx:EVP lib:../crypto/asn1/a_sign.c:208:

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

On Thu, 2018-10-11 at 22:55 -0700, David Woodhouse wrote:
> My
> 
> GnuTLS code can read files created by James's tpm2 engine but the
> 
> tpm2tss engine doesn't work...

Verbose logs from both:

http://david.woodhou.se/oc.txt (works)
http://david.woodhou.se/engine.txt (fails)




[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 685 bytes --]

[-- Attachment #3: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

I've now sent patches to James, submitted a PR to tpm2-tss-engine, and
modified my own OpenConnect code to support the same format:

TPMKey ::= SEQUENCE {
	type		OBJECT IDENTIFIER,
	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL,
	parent		INTEGER,
	pubkey		OCTET STRING,
	privkey		OCTET STRING
 }

Both tpm2 and tpm2tss engines can read key files created with the
latter. However, I have not got it working the other way round. My
GnuTLS code can read files created by James's tpm2 engine but the
tpm2tss engine doesn't work...

Creating primary key under owner.
Loading key blob.
WARNING:esys:src/tss2-esys/api/Esys_Load.c:324:Esys_Load_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_Load.c:117:Esys_Load() Esys Finish ErrorCode (0x000001df) 
WARNING:esys:src/tss2-esys/esys_context.c:117:Esys_Finalize() Finalizing NULL context. 
140278476894656:error:8007106D:tpm2-tss-engine:init_tpm_key:Unknown TPM error occured. Please check tpm2tss logs:src/tpm2-tss-engine-common.c:292:
140278476894656:error:8008C06D:tpm2-tss-engine:rsa_priv_enc:Unknown TPM error occured. Please check tpm2tss logs:src/tpm2-tss-engine-rsa.c:161:
140278476894656:error:0D0DC006:asn1 encoding routines:ASN1_item_sign_ctx:EVP lib:../crypto/asn1/a_sign.c:208:



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Tue, 2018-10-02 at 17:18 +0000, Fuchs, Andreas wrote:
> I'm still a bit confused about the TPM2LoadableKey vs TPM2ImportableKey.
> I don't know what the use for the latter would be, since I'd assume we just
> import such a key into the TPM and then use the Loadable derivate from it.
> 
> Also what's the OID that ended up in the actual fomat ?

Coming back to this part, as I reminded James about it by sending him a
patch that removed the 'type' field from his engine...


The TPM2ImportableKey type (says James) is an importable form of the
key that can be created without having access to the actual TPM. Each
time they're used, they need to be imported then loaded.

It seems to make sense to keep this in the same kind of PEM file as the
TPM2LoadableKey type that we're already using.

So... do we properly assign those OIDs and retain a type field? Or
could we have a simple 'loadable' optional boolean instead? Or even
(ab)use the parent field, since there are only a handful of valid
values for that (0x81xxxxxx and precisely four hierarchies).

For the loadable key type, is there any *additional* information that
needs to be stored? 


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

On Thu, 2018-10-11 at 21:40 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Oct 11, 2018 at 8:48 PM David Woodhouse <dwmw2(a)infradead.org>
> wrote:
> > On Thu, 2018-10-11 at 20:41 +0200, Nikos Mavrogiannopoulos wrote:
> > > As a distribution representative for rhel/fedora, I really second
> > > that. There is no reason to create code for auto-detection as a
> > > typical application writer or app user would want to use "tpm2"
> > > rather a specific engine. In fact we are even hiding the engine
> > > loading when we can as this is a detail the user shouldn't
> > > bother.
> > 
> > In an ideal world I'd go even further and suggest we should have
> > just one engine — all the ASN.1 parsing and OpenSSL interfacing,
> > and the STORE bits I'd like to add, could exist just once. Likewise
> > the policy parsing, in fact.
> > 
> > And the back end which actually talks to the TPM could have two
> > variants, for both TSS stacks. Much like the code I've put into
> > OpenConnect, which I'm hoping to palm off onto Nikos for GnuTLS...
> > :)
> 
> I'd really appreciate a PR!
>  

I haven't even pushed it to my own master branch yet :)

As well as finalising the discussion we're having here, I would very
much appreciate some review from James for 

http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_ibm.c
and from Andreas for

http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c

Going further with my fantasies about an ideal world, it would actually
be great to have a single "use a key from a TPM" library that has the
two implementations for each TSS, and is used *both* from a single
OpenSSL ENGINE implementation and also from GnuTLS....

Realistically speaking, I suspect we'll end up with separate but very
similar implementations as we have now. I'll settle for bashing heads
together and making sure they all interoperate and we publish the specs
in a sane form.






[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3007 bytes --]

[-- Attachment #3: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Thu, 2018-10-11 at 20:41 +0200, Nikos Mavrogiannopoulos wrote:
> As a distribution representative for rhel/fedora, I really second
> that. There is no reason to create code for auto-detection as a
> typical application writer or app user would want to use "tpm2"
> rather a specific engine. In fact we are even hiding the engine
> loading when we can as this is a detail the user shouldn't bother.

In an ideal world I'd go even further and suggest we should have just
one engine — all the ASN.1 parsing and OpenSSL interfacing, and the
STORE bits I'd like to add, could exist just once. Likewise the policy
parsing, in fact.

And the back end which actually talks to the TPM could have two
variants, for both TSS stacks. Much like the code I've put into
OpenConnect, which I'm hoping to palm off onto Nikos for GnuTLS... :)


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1130 bytes --]

[-- Attachment #3: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Thu, 2018-10-11 at 11:38 -0700, James Bottomley wrote:
> Yes, it modifies the EK ECC template with
> 
> noDA = 0
> userWithAuth = 1
> userWithPolicy = 0
> 
> And authPolicy must be an empty buffer as defined by zero in size and
> NULL in the entire buffer.  Everything else follows the EK ECC
> provisioning guide.

You mean NODA=1, but yes.

So I believe that means you need to add FIXEDPARENT and FIXEDTPM, and
Andreas needs to add NODA, and then we're aligned.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

On Thu, 2018-10-11 at 11:17 -0700, James Bottomley wrote:
> > > > thanks for the summary. I agree with all of them. Some more
> > > > things to agree on:
> > > > 
> > > > Primarykeys.publicArea:
> > > > -  .type = TPM2_ALG_ECC,
> > > >   .nameAlg = TPM2_ALG_SHA256
> > > > - .objectAttributes = (TPMA_OBJECT_USERWITHAUTH |
> > > > TPMA_OBJECT_RESTRICTED | TPMA_OBJECT_DECRYPT |
> > > > TPMA_OBJECT_FIXEDTPM |
> > > > TPMA_OBJECT_FIXEDPARENT | TPMA_OBJECT_SENSITIVEDATAORIGIN)
> > > 
> > > Actually, this is way too little.  In fact we don't care about the
> > > asymmetric key at all because it's the derived symmetric key that's
> > > used to encrypt the private blob (so you're missing its
> > > parameters). Unfortunately the type and all the asymmetric
> > > parameters (including a lot you haven't show here) are part of the
> > > name which is input to KDFa for the symmetric key.  Let's just
> > > follow all the provisioning guidance because it does outline them
> > > in a table, so just say "The ECC Template from the EK and TPM
> > > provisioning guides".
> > 
> > That seems to make sense. Other than the objectAttributes, what else
> > have we done *differently* to the template in the provisioning
> > guides?
> 
> Nothing, everything else seems to match including the symmetric
> parameters, the curve and the unique point.  The annoying thing is the
> name as input to KDFa. It's the sha256 sum of the entire public area,
> so every single parameter has to match to get the KDFa to spit back the
> same symmetric key.

The provisioning guide says to set TPMA_OBJECT_NODA, doesn't it?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]

On Thu, 2018-10-11 at 10:27 -0700, James Bottomley wrote:
> On Thu, 2018-10-11 at 15:41 +0000, Fuchs, Andreas wrote:
> > Hi David,
> > 
> > thanks for the summary. I agree with all of them. Some more things to
> > agree on:
> > 
> > Primarykeys.publicArea:
> > -  .type = TPM2_ALG_ECC,
> >  .nameAlg = TPM2_ALG_SHA256
> > - .objectAttributes = (TPMA_OBJECT_USERWITHAUTH |
> > TPMA_OBJECT_RESTRICTED | TPMA_OBJECT_DECRYPT | TPMA_OBJECT_FIXEDTPM |
> > TPMA_OBJECT_FIXEDPARENT | TPMA_OBJECT_SENSITIVEDATAORIGIN)
> 
> Actually, this is way too little.  In fact we don't care about the
> asymmetric key at all because it's the derived symmetric key that's
> used to encrypt the private blob (so you're missing its parameters). 
> Unfortunately the type and all the asymmetric parameters (including a
> lot you haven't show here) are part of the name which is input to KDFa
> for the symmetric key.  Let's just follow all the provisioning guidance
> because it does outline them in a table, so just say "The ECC Template
> from the EK and TPM provisioning guides".

That seems to make sense. Other than the objectAttributes, what else
have we done *differently* to the template in the provisioning guides?

> > For the On-Disk-Format:
> > We need to keep a placeholder for the (optional) policy I think.
> 
> We already have.  It's explicit element [3] of the key which is a
> sequence of TPMPolicy.  If you mean you want a different policy format,
> the elements of TPMPolicy are also explicits so they can be expanded.
> 
> > If we want to allow different formats in the future, we need to add
> > some idetifier for the format type in there as well.
> 
> It can be added later without disturbing the current format ... that's
> the point of ASN.1 EXPLICITs.

Ack.

> > Would you both agree ?
> > 
> > Regarding the engine naming:
> > Won't we run into a naming problem with the engine names if we name
> > them similarly 
> 
> To be honest perhaps the user shouldn't care about this: if they take
> the same key files, it's an implementation choice, not a fundamental
> one, so perhaps the user should simply decide on installation.

This stuff should JustWork™. People should be able to use any key they
happen to have — PKCS#11 URIs, files in various PEM and DER formats
including PKCS#12, PKCS#8, PKCS#1 and TSS blobs. I am utterly anal
about this in OpenConnect, and it *does* work for fairly much
everything under the sun. I've written this up in 
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html and
have started making at least Fedora packaging guidelines move in that
direction, saying that anything that takes a certificate+key SHOULD at
least accept PKCS#11 URIs. I should go further and incorporate the
whole of my draft, which also wants to be updated to talk about the new
TPM2 PEM format we're defining here.

So with that in mind... what advice do we give to application authors
to help them get this right? Remember, it actually needs to be hard for
them to get it *wrong*. The advice to actual users should always be "it
should Just Work. Else file bugs".

I think that having a single engine name, and having both engine
implementation install themselves to be loaded the same way, makes most
sense.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 4940 bytes --]

On Thu, 2018-10-11 at 15:41 +0000, Fuchs, Andreas wrote:
> Hi David,
> 
> thanks for the summary. I agree with all of them. Some more things to
> agree on:
> 
> Primarykeys.publicArea:
> -  .type = TPM2_ALG_ECC, .nameAlg = TPM2_ALG_SHA256
> - .objectAttributes = (TPMA_OBJECT_USERWITHAUTH |
> TPMA_OBJECT_RESTRICTED | TPMA_OBJECT_DECRYPT | TPMA_OBJECT_FIXEDTPM |
> TPMA_OBJECT_FIXEDPARENT | TPMA_OBJECT_SENSITIVEDATAORIGIN)

Agreed. As James switches to the new PEM tag with 'PRIVATE KEY' he can
change those too, and if he wants he can use the old objectAttributes
for compatibility with files using his old PEM tag.

I'm in Seattle this week, and I have my GnuTLS OpenConnect code working
with both TSS libraries. I'm hoping to sit down with James at the
weekend and get this all working.

> For the On-Disk-Format:
> We need to keep a placeholder for the (optional) policy I think.
> If we want to allow different formats in the future, we need to add
> some idetifier for the format type in there as well.

I think we have this already, as the fields are already optional and
explicitly tagged. So James's policy field has a tag of (IIRC) 4. An
implementation which doesn't recognise that will not accept the file.
If we introduce a policy format which is different, it can have a
different tag.

It would be nice to define the format for the policy, of course, but
right now it's OK and we have a compatibility plan.

> Regarding the engine naming:
> Won't we run into a naming problem with the engine names if we name
> them similarly ?
> 
> P.S. The reason I did not call the engine "openssl-something-engine"
> is that this
> is prohibited by the OpenSSL code license, unless openssl-core@
> agrees, but
> they never answered... ;-)

We're looking at the "tpm2" vs. "tpm2tss" naming for the engines here;
the OpenSSL part is purely cosmetic. See my code where I have to choose
the engine to load:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/openssl.c#l949

With both engines supporting the same PEM format, apps end up having to
try one and then the next?

It would be better to have both engines install with the same engine
name. We don't expect people to install *both* at the same time, but to
choose one TSS stack or the other. Distributions can use their
'alternatives' mechanisms to allow one or the other package to end up
in the right place as the "tpm2" engine. Perhaps we do that with a
symlink, and people can also explicitly load 'tpm2-ibm' or 'tpm2-tss'
engines if they have some reason to specifically want one or the other
(but let's avoid there being a reason for them to want that).

Of course, making it all work automatically using the STORE interface
makes it go away because applications won't need to explicitly know
about engines, but realistically speaking that's for the future.




> Cheers,
> Andreas
> 
> ________________________________________
> From: David Woodhouse [dwmw2(a)infradead.org]
> Sent: Monday, October 08, 2018 12:15
> To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos
> Mavrogiannopoulos
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
> 
> 
> It would be good to reach a conclusion on what the PEM format should
> be, so that I can push this to the OpenConnect master branch in
> preparation for a release.
> 
> Let me attempt to summarise some of the discussions and create a
> definition / TODO list.
> 
>  • We all change to use all three of NODA/FIXEDTPM/FIXEDPARENT
>    objectAttributes for creating the primary key.
> 
>  • PEM file tag changes to 'BEGIN TSS2 PRIVATE KEY'. James can
> continue
>    to use the old objectAttributes when loading files with the old
> PEM
>    tag for compatibility reasons, if he wants to.
> 
>  • Drop the TPMv1.2 compatibility via '12Key' and the 'importableKey'
>    object types, which in fact means we can drop the 'type' field
> from
>    the ASN.1 definition altogether.
> 
>  • Make the pubkey field non-optional.
> 
>  • Ignore policy for now; we can define that later. We won't use the
>    [3] EXPLICIT tag for anything incompatible with James's existing
>    definition, and if we settle on something else we'll use a
> different
>    explicit tag.
> 
>  • We produce a draft specifying the ASN.1 format and tpmkey: URI
>    scheme.
> 
> 
> That's probably enough for me to do a release of the GnuTLS code. On
> the OpenSSL side I also recommend that:
> 
>  • Both engines should use the same engine name so that applications
>    which match the PEM tag and load an engine don't have to try both.
> 
>  • Both engines should register the ASN.1 parser so that keys can be
>    used transparently by applications without having to explicitly
>    reference the engine at all (see
>    https://github.com/openssl/openssl/issues/7354 )
> 
> 


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

Hi David,

thanks for the summary. I agree with all of them. Some more things to agree on:

Primarykeys.publicArea:
-  .type = TPM2_ALG_ECC, .nameAlg = TPM2_ALG_SHA256
- .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | TPMA_OBJECT_RESTRICTED | TPMA_OBJECT_DECRYPT | TPMA_OBJECT_FIXEDTPM | TPMA_OBJECT_FIXEDPARENT | TPMA_OBJECT_SENSITIVEDATAORIGIN)

For the On-Disk-Format:
We need to keep a placeholder for the (optional) policy I think.
If we want to allow different formats in the future, we need to add some
idetifier for the format type in there as well.

Would you both agree ?

Regarding the engine naming:
Won't we run into a naming problem with the engine names if we name them similarly ?

P.S. The reason I did not call the engine "openssl-something-engine" is that this
is prohibited by the OpenSSL code license, unless openssl-core@ agrees, but
they never answered... ;-)

Cheers,
Andreas

________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Monday, October 08, 2018 12:15
To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats


It would be good to reach a conclusion on what the PEM format should
be, so that I can push this to the OpenConnect master branch in
preparation for a release.

Let me attempt to summarise some of the discussions and create a
definition / TODO list.

 • We all change to use all three of NODA/FIXEDTPM/FIXEDPARENT
   objectAttributes for creating the primary key.

 • PEM file tag changes to 'BEGIN TSS2 PRIVATE KEY'. James can continue
   to use the old objectAttributes when loading files with the old PEM
   tag for compatibility reasons, if he wants to.

 • Drop the TPMv1.2 compatibility via '12Key' and the 'importableKey'
   object types, which in fact means we can drop the 'type' field from
   the ASN.1 definition altogether.

 • Make the pubkey field non-optional.

 • Ignore policy for now; we can define that later. We won't use the
   [3] EXPLICIT tag for anything incompatible with James's existing
   definition, and if we settle on something else we'll use a different
   explicit tag.

 • We produce a draft specifying the ASN.1 format and tpmkey: URI
   scheme.


That's probably enough for me to do a release of the GnuTLS code. On
the OpenSSL side I also recommend that:

 • Both engines should use the same engine name so that applications
   which match the PEM tag and load an engine don't have to try both.

 • Both engines should register the ASN.1 parser so that keys can be
   used transparently by applications without having to explicitly
   reference the engine at all (see
   https://github.com/openssl/openssl/issues/7354 )

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 4042 bytes --]

On Wed, 2018-10-03 at 13:00 +0200, James Bottomley wrote:
> On October 3, 2018 12:47:15 PM CEST, David Woodhouse <dwmw2(a)infradead.org> wrote:
> > On Wed, 2018-10-03 at 12:40 +0200, James Bottomley wrote:
> > > > --- a/src/tpm2-tss-engine-common.h
> > > > +++ b/src/tpm2-tss-engine-common.h
> > > > @@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx, ESYS_TR
> > > > *keyHandle,
> > > >           .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \
> > > >                                TPMA_OBJECT_RESTRICTED | \
> > > >                                TPMA_OBJECT_DECRYPT | \
> > > > -                             TPMA_OBJECT_FIXEDTPM | \
> > > > -                             TPMA_OBJECT_FIXEDPARENT | \
> > > > +                             TPMA_OBJECT_NODA | \
> > > 
> > > This is the only troubling change, the rest looks fine to me.  The
> > > template for a TPM created key *must* contain those two flags. NODA is
> > > one of those things which should be specified on the command line
> > > rather than hard coded as well.  So to be exact, you need an extra
> > > command line flag for whether or not you want TPMA_OBJECT_NODA (some
> > > keys would like DA protection, especially private VPN ones, but the
> > > creator of the key should ultimately decide) and if you have a TPM
> > > create key you need TPMA_OBJECT_FIXEDTPM and TPMA_OBJECT_FIXEDPARENT
> > > but if you're wrapping an existing key they have to be clear.
> > 
> > This is for generating the primary key. It looks like your code always
> > sets NODA, but *not* FIXEDTPM and FIXEDPARENT.
> > 
> > The tpm2-tss engine does set FIXEDTPM and FIXEDPARENT, but not NODA.
> > 
> > As noted, the above patch comes from blindly making tpm2-tss-engine
> > look like your code, without even looking at what the flags mean :)
> > 
> > I don't see why you set NODA on the primary key which has no auth
> > anyway, and you seem to be saying that the lack of FIXED{TPM,PARENT} on
> > your side is also problematic?
> 
> For createprimary, noda is correct because it has no password.  Let
> me check the fixeds. The primary should have them.  I'm boarding in
> Paris at the moment but will check in-flight. 
> 
> > Does that mean we should be changing
> > your code to match what's in tpm2-tss-engine?
> 
> I think for the fixeds yes but likely it doesn't matter for the
> primary because it will be assumed.

It would be good to reach a conclusion on what the PEM format should
be, so that I can push this to the OpenConnect master branch in
preparation for a release.

Let me attempt to summarise some of the discussions and create a
definition / TODO list.

 • We all change to use all three of NODA/FIXEDTPM/FIXEDPARENT
   objectAttributes for creating the primary key.

 • PEM file tag changes to 'BEGIN TSS2 PRIVATE KEY'. James can continue
   to use the old objectAttributes when loading files with the old PEM
   tag for compatibility reasons, if he wants to.

 • Drop the TPMv1.2 compatibility via '12Key' and the 'importableKey' 
   object types, which in fact means we can drop the 'type' field from
   the ASN.1 definition altogether.

 • Make the pubkey field non-optional.

 • Ignore policy for now; we can define that later. We won't use the
   [3] EXPLICIT tag for anything incompatible with James's existing 
   definition, and if we settle on something else we'll use a different
   explicit tag.

 • We produce a draft specifying the ASN.1 format and tpmkey: URI
   scheme.


That's probably enough for me to do a release of the GnuTLS code. On
the OpenSSL side I also recommend that:

 • Both engines should use the same engine name so that applications
   which match the PEM tag and load an engine don't have to try both.

 • Both engines should register the ASN.1 parser so that keys can be
   used transparently by applications without having to explicitly
   reference the engine at all (see 
   https://github.com/openssl/openssl/issues/7354 )



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Fri, 2018-10-05 at 15:34 +0000, Fuchs, Andreas wrote:
> We can tag -----BEGIN TSS2 PRIVATE KEY----- vs -----BEGIN TSS1
> PRIVATE KEY-----
> then the contents can be completely different...
> What do you say ?

I have no objection to that. In practice, anyone using TPMv1 keys is
currently using the with -----BEGIN TSS KEY BLOB----- anyway. I don't
think anyone ever actually implemented James's idea of putting a TPMv1
blob into his ASN.1 structure. And even if his engine ends up
supporting both, doing both PEM tags is also fine.

But conversely, I don't see any problem with the 'pubkey' element being
marked optional in the ASN.1 structure definition, even if it actually
has to be there in practice.

It's not like there aren't an infinite number of *other* ways you can
make a blob which matches the ASN.1 definition but won't actually
work...

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

We can tag -----BEGIN TSS2 PRIVATE KEY----- vs -----BEGIN TSS1 PRIVATE KEY-----
then the contents can be completely different...
What do you say ?
________________________________________
From: James Bottomley [James.Bottomley(a)hansenpartnership.com]
Sent: Friday, October 05, 2018 17:29
To: Fuchs, Andreas; David Woodhouse; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Cc: Richard Levitte
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Fri, 2018-10-05 at 15:24 +0000, Fuchs, Andreas wrote:
> Actually, I like the TSS2 PEM Tag.
> We could then also get rid of the OPTIONAL for publicKey, since we
> won't support TPMv1.2 anymore.

Actually, we might.  It seems a lot of embedded is still 1.2 and
they're having huge difficulty with trousers, so the ibmtss is growing
a small 1.2 part that makes a direct tpm connection as well.

There's no harm to 2.0 in keeping it optional and it preserves the 1.2
compatibility just in case.

James

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Fri, 2018-10-05 at 15:22 +0000, Fuchs, Andreas wrote:
> Hi David,
> 
> are you sure this is about the (default) parent, i.e. primary key ?
> 
> I assume you're talking about the actual key, which I left out for
> the specification.
> Can this be ?

James's code uses the 'parent' handle from the ASN.1 directly if it
matches 0x81xxxxxx. If it doesn't, then he has a function equivalent to
your init_tpm_primary() function, except that the value used for
in.primaryHandle is the one from the ASN.1. Which seems like it's
designed to allow the user of other hierarchies. It defaults to
RH_OWNER, while yours is hard-coded to that.

But I see James is awake now, so I'll defer to him...

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

Actually, I like the TSS2 PEM Tag.
We could then also get rid of the OPTIONAL for publicKey, since we won't support TPMv1.2 anymore.
________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Friday, October 05, 2018 13:59
To: Fuchs, Andreas; James Bottomley; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Cc: Richard Levitte
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Fri, 2018-10-05 at 09:44 +0000, Fuchs, Andreas wrote:
> Hi James, Hi David,
>
> I put together a Wiki-Page with the most relevant information at
> https://github.com/tpm2-software/tpm2-tss-engine/wiki/Key-templates-and-on-disk-format
> Also including things like nameAlg for the primary key and such,
> since maybe that's where we are differing right now.
>
> There are a bunch of ??? about the tss2-engine where I'd need input from you.
>
> And a bunch of tbds of the tpm2-tss-engine where I'll have to do some coding.
>
> Thanks a lot,

Can we change the PEM tag too, to -----BEGIN TSS2 PRIVATE KEY----- ?

Ending with "PRIVATE KEY" is needed for OpenSSL 1.1.1 to be able to
automatically load it without having to hack *every* application to
recognise the strings and try the appropriate engine.

See https://github.com/openssl/openssl/issues/7354

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

Hi David,

are you sure this is about the (default) parent, i.e. primary key ?

I assume you're talking about the actual key, which I left out for the specification.
Can this be ?

Cheers,
Andreas
________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Friday, October 05, 2018 12:27
To: Fuchs, Andreas; James Bottomley; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Fri, 2018-10-05 at 09:44 +0000, Fuchs, Andreas wrote:
> Hi James, Hi David,
>
> I put together a Wiki-Page with the most relevant information at
> https://github.com/tpm2-software/tpm2-tss-engine/wiki/Key-templates-and-on-disk-format
> Also including things like nameAlg for the primary key and such,
> since maybe that's where we are differing right now.
>
> There are a bunch of ??? about the tss2-engine where I'd need input from you.

My GnuTLS code mostly follows tpm2-tss-engine here, except for the
different objectAttributes when generating the parent key. That differs
in the NODA, FIXEDTPM and FIXEDPARENT flags, as discussed — and I
follow James's version here so that I can actually test VPN connections
with a valid key (which I have on disk, and has to be wrapped).

Every other part of the default parent key generation, is the same
between the engines. It's only the objectAttributes I had to change.


I'm not sure you have the 'Parent key is 0x81000001 if it exists' part
right.

The parent key is encoded in the PEM ASN.1.

If it matches 0x81xxxxxx, it's used as a key handle directly.

If not, it identifies the hierarchy under which the EC primary key is
generated. James's version defaults to TPM_RH_OWNER, but I think other
hierarchies can be specified.

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Fri, 2018-10-05 at 14:36 +0000, Fuchs, Andreas wrote:
> @James: Looking over this, I was wondering, why is the publicKey optional ?
> I think the TPM won't load the private key without the public key, or will it ?

I believe that's to allow the TPMv1 format.

The idea is that the TPMv1 TCPA_KEY structure goes in a single OCTET-
STRING in the 'privkey' field of the new format, using the OID
2.23.133.10.1 as the 'type' field.

I made the original openssl_tpm_engine store just that same OCTET-
STRING in a '-----BEGIN TSS KEY BLOB-----' PEM format, but for TPMv2 we
needed the additional structure.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 4481 bytes --]

@James: Looking over this, I was wondering, why is the publicKey optional ?
I think the TPM won't load the private key without the public key, or will it ?

Thanks,
Andreas
________________________________
From: Fuchs, Andreas
Sent: Friday, October 05, 2018 12:19
To: Nikos Mavrogiannopoulos; David Woodhouse
Cc: James Bottomley; tpm2(a)lists.01.org
Subject: RE: [tpm2] Conflicting TPM2 engines and storage formats

That's a good point actually.

However, TSS2 FAPI will not use the "weird" UUIDs for keys anymore, but path-like strings.

See https://trustedcomputinggroup.org/wp-content/uploads/TSS-Feature-API-version-.12_Review.pdf
page 16 (examples) and all of section 4 for explanation.
Note that that was a very early version and has been revised since then, but the general concept still sticks.

Thus, the URI-Scheme will have to change anyways.

The biggest point for the URI-Scheme IMHO was that it allowed system vs user keys, which was otherwise not possible. The path-scheme of FAPI now already encodes this from TSS side.

My personal idea was:
- prefixes 0x81 (persistent) and 0x01 (NV-Space) will point to TPM-internal (as applicable one or the other)
- If not it looks for a FAPI keystore path
- If not it looks if a file of this name exists

We could of course prefix all of it, but question is, whether it's worth it ?

What do people think ?

Cheers,
Andreas

________________________________
From: Nikos Mavrogiannopoulos [n.mavrogiannopoulos(a)gmail.com]
Sent: Friday, October 05, 2018 11:54
To: David Woodhouse
Cc: Fuchs, Andreas; James Bottomley; tpm2(a)lists.01.org
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

It would certainly be good to have a standard, unambiguous way to reference items in a TPM rather than just hex numbers. We were are that situation with HSMs 5 years ago, and the switch to pkcs11: URIs helped improve software interfaces greatly (in apache today you specify a file or a smart card object interchangeably). The tpmuri scheme that David pointed could be a good starting point.

regards,
Nikos

On Thu, Oct 4, 2018 at 6:17 PM David Woodhouse <dwmw2(a)infradead.org<mailto:dwmw2(a)infradead.org>> wrote:

FWIW I have the GnuTLS code also working, including with EC keys (and I
think I know how to tell GnuTLS not to ask me to do SHA512). I should
be able to adjust it to conform to whatever consensus we reach.

cf. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01


On Thu, 2018-10-04 at 16:04 +0000, Fuchs, Andreas wrote:
> Should we try to setup a wiki or markdown to start converging into a single form ?
> I think we can also easily set NODA for the primary, because they have to auth value anyways.
>
> @James: how do you handle the key-ids ? Allways assume them to be files ?
> I have a PR for persistent TPM keys, where all key ids starting with 0x are interpreted as TPM keys.
> For the future I'll also want to reference FAPI keys (path-like format).
> Thus, any clues on how to handle things consistently here ?
>
> tpm2-tss-engine will propably not support policies from your format then, but wait until FAPI (with integrated policy engine) is available.
> ________________________________________
> From: David Woodhouse [dwmw2(a)infradead.org<mailto:dwmw2(a)infradead.org>]
> Sent: Wednesday, October 03, 2018 22:47
> To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org<mailto:tpm2(a)lists.01.org>; Nikos Mavrogiannopoulos
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
>
> On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
> >
> >
> > Full patch below, for reference. Don't heckle too hard; it exists
> > mostly to document the current incompatibilities. I'll let the two of
> > you come to an agreement on the correct way to resolve them, while I
> > throw together some GnuTLS code to use the same PEM files.
>
> OK... OpenConnect now supports both OpenSSL engines, and I've thrown
> together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
> gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
> no auth, no policy, only the default parent, ...).
>
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c
>
> I'd love *not* to have to fix all those caveats, and for this to live
> in a library somewhere instead. :)


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7039 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Fri, 2018-10-05 at 09:44 +0000, Fuchs, Andreas wrote:
> Hi James, Hi David,
> 
> I put together a Wiki-Page with the most relevant information at 
> https://github.com/tpm2-software/tpm2-tss-engine/wiki/Key-templates-and-on-disk-format
> Also including things like nameAlg for the primary key and such,
> since maybe that's where we are differing right now.
> 
> There are a bunch of ??? about the tss2-engine where I'd need input from you.
> 
> And a bunch of tbds of the tpm2-tss-engine where I'll have to do some coding.
> 
> Thanks a lot,

Can we change the PEM tag too, to -----BEGIN TSS2 PRIVATE KEY----- ? 

Ending with "PRIVATE KEY" is needed for OpenSSL 1.1.1 to be able to
automatically load it without having to hack *every* application to
recognise the strings and try the appropriate engine.

See https://github.com/openssl/openssl/issues/7354

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On Fri, 2018-10-05 at 09:44 +0000, Fuchs, Andreas wrote:
> Hi James, Hi David,
> 
> I put together a Wiki-Page with the most relevant information at 
> https://github.com/tpm2-software/tpm2-tss-engine/wiki/Key-templates-and-on-disk-format
> Also including things like nameAlg for the primary key and such,
> since maybe that's where we are differing right now.
> 
> There are a bunch of ??? about the tss2-engine where I'd need input from you.

My GnuTLS code mostly follows tpm2-tss-engine here, except for the
different objectAttributes when generating the parent key. That differs
in the NODA, FIXEDTPM and FIXEDPARENT flags, as discussed — and I
follow James's version here so that I can actually test VPN connections
with a valid key (which I have on disk, and has to be wrapped).

Every other part of the default parent key generation, is the same
between the engines. It's only the objectAttributes I had to change.


I'm not sure you have the 'Parent key is 0x81000001 if it exists' part
right.

The parent key is encoded in the PEM ASN.1.

If it matches 0x81xxxxxx, it's used as a key handle directly.

If not, it identifies the hierarchy under which the EC primary key is
generated. James's version defaults to TPM_RH_OWNER, but I think other
hierarchies can be specified.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 4053 bytes --]

That's a good point actually.

However, TSS2 FAPI will not use the "weird" UUIDs for keys anymore, but path-like strings.

See https://trustedcomputinggroup.org/wp-content/uploads/TSS-Feature-API-version-.12_Review.pdf
page 16 (examples) and all of section 4 for explanation.
Note that that was a very early version and has been revised since then, but the general concept still sticks.

Thus, the URI-Scheme will have to change anyways.

The biggest point for the URI-Scheme IMHO was that it allowed system vs user keys, which was otherwise not possible. The path-scheme of FAPI now already encodes this from TSS side.

My personal idea was:
- prefixes 0x81 (persistent) and 0x01 (NV-Space) will point to TPM-internal (as applicable one or the other)
- If not it looks for a FAPI keystore path
- If not it looks if a file of this name exists

We could of course prefix all of it, but question is, whether it's worth it ?

What do people think ?

Cheers,
Andreas

________________________________
From: Nikos Mavrogiannopoulos [n.mavrogiannopoulos(a)gmail.com]
Sent: Friday, October 05, 2018 11:54
To: David Woodhouse
Cc: Fuchs, Andreas; James Bottomley; tpm2(a)lists.01.org
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

It would certainly be good to have a standard, unambiguous way to reference items in a TPM rather than just hex numbers. We were are that situation with HSMs 5 years ago, and the switch to pkcs11: URIs helped improve software interfaces greatly (in apache today you specify a file or a smart card object interchangeably). The tpmuri scheme that David pointed could be a good starting point.

regards,
Nikos

On Thu, Oct 4, 2018 at 6:17 PM David Woodhouse <dwmw2(a)infradead.org<mailto:dwmw2(a)infradead.org>> wrote:

FWIW I have the GnuTLS code also working, including with EC keys (and I
think I know how to tell GnuTLS not to ask me to do SHA512). I should
be able to adjust it to conform to whatever consensus we reach.

cf. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01


On Thu, 2018-10-04 at 16:04 +0000, Fuchs, Andreas wrote:
> Should we try to setup a wiki or markdown to start converging into a single form ?
> I think we can also easily set NODA for the primary, because they have to auth value anyways.
>
> @James: how do you handle the key-ids ? Allways assume them to be files ?
> I have a PR for persistent TPM keys, where all key ids starting with 0x are interpreted as TPM keys.
> For the future I'll also want to reference FAPI keys (path-like format).
> Thus, any clues on how to handle things consistently here ?
>
> tpm2-tss-engine will propably not support policies from your format then, but wait until FAPI (with integrated policy engine) is available.
> ________________________________________
> From: David Woodhouse [dwmw2(a)infradead.org<mailto:dwmw2(a)infradead.org>]
> Sent: Wednesday, October 03, 2018 22:47
> To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org<mailto:tpm2(a)lists.01.org>; Nikos Mavrogiannopoulos
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
>
> On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
> >
> >
> > Full patch below, for reference. Don't heckle too hard; it exists
> > mostly to document the current incompatibilities. I'll let the two of
> > you come to an agreement on the correct way to resolve them, while I
> > throw together some GnuTLS code to use the same PEM files.
>
> OK... OpenConnect now supports both OpenSSL engines, and I've thrown
> together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
> gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
> no auth, no policy, only the default parent, ...).
>
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c
>
> I'd love *not* to have to fix all those caveats, and for this to live
> in a library somewhere instead. :)


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6148 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

Hi James, Hi David,

I put together a Wiki-Page with the most relevant information at https://github.com/tpm2-software/tpm2-tss-engine/wiki/Key-templates-and-on-disk-format
Also including things like nameAlg for the primary key and such, since maybe that's where we are differing right now.

There are a bunch of ??? about the tss2-engine where I'd need input from you.

And a bunch of tbds of the tpm2-tss-engine where I'll have to do some coding.

Thanks a lot,
Andreas
________________________________________
From: James Bottomley [James.Bottomley(a)hansenpartnership.com]
Sent: Thursday, October 04, 2018 18:15
To: Fuchs, Andreas; David Woodhouse; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Thu, 2018-10-04 at 16:04 +0000, Fuchs, Andreas wrote:
> Should we try to setup a wiki or markdown to start converging into a
> single form ?
> I think we can also easily set NODA for the primary, because they
> have to auth value anyways.
>
> @James: how do you handle the key-ids ? Allways assume them to be
> files ?

My engine assumes it's a file unless it's convertible to a hex number
and the first octet is 0x81 (which is the persistent key MSO); so I
don't do the 0x prefix and with this form you specify, say the template
primary as 81000001.  Anything that doesn't look like a persistent key
hex number is treated as a file name.

James


> I have a PR for persistent TPM keys, where all key ids starting with
> 0x are interpreted as TPM keys. For the future I'll also want to
> reference FAPI keys (path-like format).
> Thus, any clues on how to handle things consistently here ?
>
> tpm2-tss-engine will propably not support policies from your format
> then, but wait until FAPI (with integrated policy engine) is
> available.

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]


FWIW I have the GnuTLS code also working, including with EC keys (and I
think I know how to tell GnuTLS not to ask me to do SHA512). I should
be able to adjust it to conform to whatever consensus we reach.

cf. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01


On Thu, 2018-10-04 at 16:04 +0000, Fuchs, Andreas wrote:
> Should we try to setup a wiki or markdown to start converging into a single form ?
> I think we can also easily set NODA for the primary, because they have to auth value anyways.
> 
> @James: how do you handle the key-ids ? Allways assume them to be files ?
> I have a PR for persistent TPM keys, where all key ids starting with 0x are interpreted as TPM keys.
> For the future I'll also want to reference FAPI keys (path-like format).
> Thus, any clues on how to handle things consistently here ?
> 
> tpm2-tss-engine will propably not support policies from your format then, but wait until FAPI (with integrated policy engine) is available.
> ________________________________________
> From: David Woodhouse [dwmw2(a)infradead.org]
> Sent: Wednesday, October 03, 2018 22:47
> To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
> 
> On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
> > 
> > 
> > Full patch below, for reference. Don't heckle too hard; it exists
> > mostly to document the current incompatibilities. I'll let the two of
> > you come to an agreement on the correct way to resolve them, while I
> > throw together some GnuTLS code to use the same PEM files.
> 
> OK... OpenConnect now supports both OpenSSL engines, and I've thrown
> together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
> gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
> no auth, no policy, only the default parent, ...).
> 
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c
> 
> I'd love *not* to have to fix all those caveats, and for this to live
> in a library somewhere instead. :)


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Should we try to setup a wiki or markdown to start converging into a single form ?
I think we can also easily set NODA for the primary, because they have to auth value anyways.

@James: how do you handle the key-ids ? Allways assume them to be files ?
I have a PR for persistent TPM keys, where all key ids starting with 0x are interpreted as TPM keys.
For the future I'll also want to reference FAPI keys (path-like format).
Thus, any clues on how to handle things consistently here ?

tpm2-tss-engine will propably not support policies from your format then, but wait until FAPI (with integrated policy engine) is available.
________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Wednesday, October 03, 2018 22:47
To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
>
>
> Full patch below, for reference. Don't heckle too hard; it exists
> mostly to document the current incompatibilities. I'll let the two of
> you come to an agreement on the correct way to resolve them, while I
> throw together some GnuTLS code to use the same PEM files.

OK... OpenConnect now supports both OpenSSL engines, and I've thrown
together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
no auth, no policy, only the default parent, ...).

http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c

I'd love *not* to have to fix all those caveats, and for this to live
in a library somewhere instead. :)

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
> 
> 
> Full patch below, for reference. Don't heckle too hard; it exists
> mostly to document the current incompatibilities. I'll let the two of
> you come to an agreement on the correct way to resolve them, while I
> throw together some GnuTLS code to use the same PEM files.

OK... OpenConnect now supports both OpenSSL engines, and I've thrown
together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
no auth, no policy, only the default parent, ...).

http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c

I'd love *not* to have to fix all those caveats, and for this to live
in a library somewhere instead. :)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]

On Wed, 2018-10-03 at 13:00 +0200, James Bottomley wrote:
> On October 3, 2018 12:47:15 PM CEST, David Woodhouse <dwmw2(a)infradead.org> wrote:
> > On Wed, 2018-10-03 at 12:40 +0200, James Bottomley wrote:
> > > > --- a/src/tpm2-tss-engine-common.h
> > > > +++ b/src/tpm2-tss-engine-common.h
> > > > @@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx, ESYS_TR
> > > > *keyHandle,
> > > >          .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \
> > > >                               TPMA_OBJECT_RESTRICTED | \
> > > >                               TPMA_OBJECT_DECRYPT | \
> > > > -                             TPMA_OBJECT_FIXEDTPM | \
> > > > -                             TPMA_OBJECT_FIXEDPARENT | \
> > > > +                             TPMA_OBJECT_NODA | \
> > > 
> > > This is the only troubling change, the rest looks fine to me.  The
> > > template for a TPM created key *must* contain those two flags.  NODA
> > 
> > is
> > > one of those things which should be specified on the command line
> > > rather than hard coded as well.  So to be exact, you need an extra
> > > command line flag for whether or not you want TPMA_OBJECT_NODA (some
> > > keys would like DA protection, especially private VPN ones, but the
> > > creator of the key should ultimately decide) and if you have a TPM
> > > create key you need TPMA_OBJECT_FIXEDTPM and TPMA_OBJECT_FIXEDPARENT
> > > but if you're wrapping an existing key they have to be clear.
> > 
> > This is for generating the primary key. It looks like your code always
> > sets NODA, but *not* FIXEDTPM and FIXEDPARENT.
> > 
> > The tpm2-tss engine does set FIXEDTPM and FIXEDPARENT, but not NODA.
> > 
> > As noted, the above patch comes from blindly making tpm2-tss-engine
> > look like your code, without even looking at what the flags mean :)
> > 
> > I don't see why you set NODA on the primary key which has no auth
> > anyway, and you seem to be saying that the lack of FIXED{TPM,PARENT} on
> > your side is also problematic?
> 
> For createprimary, noda is correct because it has no password.  Let
> me check the fixeds. The primary should have them.  I'm boarding in
> Paris at the moment but will check in-flight. 
> 
> > Does that mean we should be changing
> > your code to match what's in tpm2-tss-engine?
> 
> I think for the fixeds yes but likely it doesn't matter for the
> primary because it will be assumed.

Whether it's assumed or not, changing it does appear to change the
resulting primary so that it can no longer unwrap the previously-
wrapped keys.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

On Wed, 2018-10-03 at 12:40 +0200, James Bottomley wrote:
> > --- a/src/tpm2-tss-engine-common.h
> > +++ b/src/tpm2-tss-engine-common.h
> > @@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx, ESYS_TR
> > *keyHandle,
> >          .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \
> >                               TPMA_OBJECT_RESTRICTED | \
> >                               TPMA_OBJECT_DECRYPT | \
> > -                             TPMA_OBJECT_FIXEDTPM | \
> > -                             TPMA_OBJECT_FIXEDPARENT | \
> > +                             TPMA_OBJECT_NODA | \
> 
> This is the only troubling change, the rest looks fine to me.  The
> template for a TPM created key *must* contain those two flags.  NODA is
> one of those things which should be specified on the command line
> rather than hard coded as well.  So to be exact, you need an extra
> command line flag for whether or not you want TPMA_OBJECT_NODA (some
> keys would like DA protection, especially private VPN ones, but the
> creator of the key should ultimately decide) and if you have a TPM
> create key you need TPMA_OBJECT_FIXEDTPM and TPMA_OBJECT_FIXEDPARENT
> but if you're wrapping an existing key they have to be clear.

This is for generating the primary key. It looks like your code always
sets NODA, but *not* FIXEDTPM and FIXEDPARENT.

The tpm2-tss engine does set FIXEDTPM and FIXEDPARENT, but not NODA.

As noted, the above patch comes from blindly making tpm2-tss-engine
look like your code, without even looking at what the flags mean :)

I don't see why you set NODA on the primary key which has no auth
anyway, and you seem to be saying that the lack of FIXED{TPM,PARENT} on
your side is also problematic? Does that mean we should be changing
your code to match what's in tpm2-tss-engine?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3904 bytes --]

On Tue, 2018-10-02 at 19:58 +0100, David Woodhouse wrote:
> 
> So... that now *is* working for signing. However, while the
> corresponding 'rsautl -verify' works fine with James's tpm2 engine, it
> fails with tpm2tss:
> 
> $ openssl rsautl -verify -engine tpm2tss -inkey ../openssl_tpm2_engine/tpm2-engine.tss -keyform engine -in testsig.tpm2tss
> Initializing
> engine "tpm2tss" set.
> Loading private key ../openssl_tpm2_engine/tpm2-engine.tss
> get_auth called for object user key with ui_method 0x55ced253fdc0
> Enter password for user key:
> password is 
> Loaded key uses alg-id 1
> Creating RSA key object.
> Created RSA key object.
> TPM2 Key loaded
> RSA operation error
> 140407559393728:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:../crypto/rsa/rsa_pk1.c:75:
> 140407559393728:error:04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed:../crypto/rsa/rsa_ossl.c:586:
> 
> 
> So... is it the public key that I've misconverted somehow?

I've resolved that one too. James explicitly sets the exponent in 
tpm2Data->pub.publicArea.parameters.rsaDetail.exponent to zero if it's
0x10001, with a comment saying "zero means standard exponent. Some TPM
chips will reject a non standard exponent".

So now I do have OpenConnect using my wrapped VPN key, with both
engines (although tpm2-tss-engine stills asks me for an empty
password).

By setting objectAttributes when creating a key, I can make
tpm2tss-genkey work again too.

Full patch below, for reference. Don't heckle too hard; it exists
mostly to document the current incompatibilities. I'll let the two of
you come to an agreement on the correct way to resolve them, while I
throw together some GnuTLS code to use the same PEM files.

(Since the tpm2-tss-engine code is under a licence which lets me crib
from it, and the libraries actually have pkgconfig etc., I suppose
that's made this application author's implementation choice fairly much
a no-brainer...)




--- a/src/tpm2-tss-engine-common.h
+++ b/src/tpm2-tss-engine-common.h
@@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx, ESYS_TR *keyHandle,
         .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \
                              TPMA_OBJECT_RESTRICTED | \
                              TPMA_OBJECT_DECRYPT | \
-                             TPMA_OBJECT_FIXEDTPM | \
-                             TPMA_OBJECT_FIXEDPARENT | \
+                             TPMA_OBJECT_NODA | \
                              TPMA_OBJECT_SENSITIVEDATAORIGIN), \
         .authPolicy = { \
              .size = 0, \
--- a/src/tpm2-tss-engine-rsa.c
+++ b/src/tpm2-tss-engine-rsa.c
@@ -304,7 +304,7 @@ populate_rsa(RSA *rsa) {
         ERR(populate_rsa, ERR_R_MALLOC_FAILURE);
         goto error;
     }
-    BN_set_word(rsa->e, tpm2Data->pub.publicArea.parameters.rsaDetail.exponent);
+    BN_set_word(rsa->e, tpm2Data->pub.publicArea.parameters.rsaDetail.exponent ? : 0x10001);
 
     /* Setting private portions to 0 values so the public key can be extracted
        from the keyfile if this is desired. */
@@ -366,7 +366,7 @@ populate_rsa(RSA *rsa) {
         goto error;
     }
 
-    BN_set_word(e, tpm2Data->pub.publicArea.parameters.rsaDetail.exponent);
+    BN_set_word(e, tpm2Data->pub.publicArea.parameters.rsaDetail.exponent ? : 0x10001);
     BN_set_word(d, 0);
     BN_set_word(p, 0);
     BN_set_word(q, 0);
@@ -485,6 +485,8 @@ tpm2tss_rsa_genkey(RSA *rsa, int bits, BIGNUM *e, char *password)
     if (e)
         inPublic.publicArea.parameters.rsaDetail.exponent = BN_get_word(e);
 
+    inPublic.publicArea.objectAttributes = TPMA_OBJECT_SENSITIVEDATAORIGIN | TPMA_OBJECT_NODA;
+
     if (password) {
         DBG("Setting a password for the created key.\n");
         if (strlen(password) > sizeof(tpm2Data->userauth.buffer) - 1) {


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 5166 bytes --]

OK.. I think this makes a difference:


--- a/src/tpm2-tss-engine-common.h
+++ b/src/tpm2-tss-engine-common.h
@@ -55,8 +55,7 @@ TSS2_RC init_tpm_key(ESYS_CONTEXT **ctx, ESYS_TR *keyHandle,
         .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | \
                              TPMA_OBJECT_RESTRICTED | \
                              TPMA_OBJECT_DECRYPT | \
-                             TPMA_OBJECT_FIXEDTPM | \
-                             TPMA_OBJECT_FIXEDPARENT | \
+                             TPMA_OBJECT_NODA | \
                              TPMA_OBJECT_SENSITIVEDATAORIGIN), \
         .authPolicy = { \
              .size = 0, \


Now, I have two PEM files, one 'machine.tss' created with James's tpm2
engine, and a second 'tpm2-engine.tss' which is converted manually as
described in issue #11 to be used with the tpm2tss engine.


$ openssl rsautl -sign -engine tpm2tss -inkey tpm2-engine.tss -keyform engine < testfile > testsig.tpm2tss
$ openssl rsautl -sign -engine tpm2 -inkey machine.tss -keyform engine < testfile > testsig.tpm2
$ sha1sum testsig.tpm*
fb9e8c1f4a1872f4144fd760af1740af75a9a8b2  testsig.tpm2
fb9e8c1f4a1872f4144fd760af1740af75a9a8b2  testsig.tpm2tss

So... that now *is* working for signing. However, while the
corresponding 'rsautl -verify' works fine with James's tpm2 engine, it
fails with tpm2tss:

$ openssl rsautl -verify -engine tpm2tss -inkey ../openssl_tpm2_engine/tpm2-engine.tss -keyform engine -in testsig.tpm2tss
Initializing
engine "tpm2tss" set.
Loading private key ../openssl_tpm2_engine/tpm2-engine.tss
get_auth called for object user key with ui_method 0x55ced253fdc0
Enter password for user key:
password is 
Loaded key uses alg-id 1
Creating RSA key object.
Created RSA key object.
TPM2 Key loaded
RSA operation error
140407559393728:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:../crypto/rsa/rsa_pk1.c:75:
140407559393728:error:04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed:../crypto/rsa/rsa_ossl.c:586:


So... is it the public key that I've misconverted somehow?

 $ openssl asn1parse -in machine.tss 
    0:d=0  hl=4 l= 503 cons: SEQUENCE          
    4:d=1  hl=2 l=   5 prim: OBJECT            :2.23.133.10.2
   11:d=1  hl=2 l=   3 cons: cont [ 0 ]        
   13:d=2  hl=2 l=   1 prim: BOOLEAN           :1
   16:d=1  hl=2 l=   6 cons: cont [ 1 ]        
   18:d=2  hl=2 l=   4 prim: INTEGER           :40000001
   24:d=1  hl=4 l= 284 cons: cont [ 2 ]        
   28:d=2  hl=4 l= 280 prim: OCTET STRING      [HEX DUMP]:01160001000B000204400000001000100800000000000100C696B23A22C1516E22352CD1309A48BD7E6F054EE10BB7265BFC3BC85B622E75B658A03E15BB74CD9C542C4CEA22337467913058B3711E6EF6CB4C8DA9B496E5888346B058426D645398613BF9BCE907947E63B5B4CD4ABA1FFC2EA396BEC0A7F3F1FEDF022966CED43C070B2000BEEEE7BB82375A4E1C1558E7FC7139DCEE9C6055C3332D50572E14A0747B907440598C93B77F356689EE71ACDAECA9C1FF33C74106CD8C23ACA4613F4D234A4C10A1D7AA3E469493A541838D40A065B17FD23F7D75A5F9BD29F59566BB7D450E970269FD90F914FFF0CE44D526D4914C32F35AD9A2C6BAF7F77BAAA0B4B77F80C29C683764BAFADEAFC397D344DB2ABF996D
  312:d=1  hl=3 l= 192 prim: OCTET STRING      [HEX DUMP]:00BE00204463515A27FC3B773B53F28C04C147D78991B02E7B2FAFE0E96FA11E79692FCA0010DE02ADCCECCADBA51D1C71283A37FFD608D0979B994054031FF7475505EBC0D45CB6808A93D83C64051CA06043721D55D8FE514BDD997CB8B26199B62D2E8517C1DE5293AC6ED97EF278F648B072855B73B2D32CB2B39315FA40FA6AAF618038D6F880465083A1140DF9792448F6D888C912A797EE943912E0EC78B9576748822580ABECE5D02B973DAF1C0F7CE15DC56D3BB15E9AE7FADDB7C2

 $ tail -8 tpm2-engine.tss | openssl asn1parse
    0:d=0  hl=4 l= 280 prim: OCTET STRING      [HEX DUMP]:01160001000B000204400000001000100800000000000100C696B23A22C1516E22352CD1309A48BD7E6F054EE10BB7265BFC3BC85B622E75B658A03E15BB74CD9C542C4CEA22337467913058B3711E6EF6CB4C8DA9B496E5888346B058426D645398613BF9BCE907947E63B5B4CD4ABA1FFC2EA396BEC0A7F3F1FEDF022966CED43C070B2000BEEEE7BB82375A4E1C1558E7FC7139DCEE9C6055C3332D50572E14A0747B907440598C93B77F356689EE71ACDAECA9C1FF33C74106CD8C23ACA4613F4D234A4C10A1D7AA3E469493A541838D40A065B17FD23F7D75A5F9BD29F59566BB7D450E970269FD90F914FFF0CE44D526D4914C32F35AD9A2C6BAF7F77BAAA0B4B77F80C29C683764BAFADEAFC397D344DB2ABF996D


I note that 'tpm2tss-genkey' stopped working with the change I made at
the beginning of this mail. I confess I haven't even looked up what any
of those flags mean...

$ ./tpm2tss-genkey  new.tss
Initializing
Setting owner auth to empty auth.
Generating RSA key for 2048 bits keysize.
Establishing connection with TPM.
WARNING:esys:src/tss2-esys/esys_tcti_default.c:137:tcti_from_file() Could not load TCTI file: libtss2-tcti-default.so 
WARNING:esys:src/tss2-esys/esys_tcti_default.c:137:tcti_from_file() Could not load TCTI file: libtss2-tcti-tabrmd.so 
Creating primary key under owner.
Generating the RSA key inside the TPM.
WARNING:esys:src/tss2-esys/api/Esys_Create.c:411:Esys_Create_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_Create.c:155:Esys_Create() Esys Finish ErrorCode (0x000002c2) 
Error: Generating key failed
Key could not be generated.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

Hi James,

thanks for joining it.

What do you put into the octet strings for public and private key ?
The marshalled TPM2Bs according to TPM spec or a different encoding ?

What's the template for the primary key ?

What's the content of the CommandPolicy octet string ?

Thanks,
Andreas
________________________________________
From: James Bottomley [James.Bottomley(a)hansenpartnership.com]
Sent: Tuesday, October 02, 2018 18:47
To: David Woodhouse; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

On Tue, 2018-10-02 at 17:38 +0100, David Woodhouse wrote:
> On Tue, 2018-10-02 at 16:20 +0000, Fuchs, Andreas wrote:
> > Hi David,
> >
> > unfortuantely, the engines are diferent as much as their license
> > and underlying TSSes.
> > tpm2-tss (which is TCG spec conformant) and IBM's proprietary
> > OpenSource TSS.
> >
> > The tpm2-tss-engine is newer and BSD-license, whilst James's is
> > (L?)GPL.
> > Thus, we could not just take his and add a second underlying TSS
> > but had to
> > implement a completely new one to get rid of the license terms.
> > So we had to come up with our own storage format.
> > I also cannot look at James's codebase to not become tainted with
> > GPL copyleft.
> >
> > That's why we chose a different engine name and made sure to label
> > PEM differently,
> > so we don't get compatibility messes.
> >
> > If you'd like to propose a different storage format for tpm2-tss-
> > engine, please
> > provide me with a format. Maybe we can fit it into the first 0.1
> > release.
> > (but that would have to happen VERY quickly, i.e. the next 2
> > weeks).
>
> Ultimately, our aim should be for people to be able to use the same
> PEM
> file regardless of which software stack they're using. I'll be fixing
> up GnuTLS client code to use the same files, much as I did for TPMv1
> PEM files a while ago.
>
> https://mta.openssl.org/pipermail/openssl-dev/2016-December/008936.ht
> ml
>  covers the format that James implemented.

Actually, there's been an extension for policy since then (and a
removal of one of the superfluous optionals) so this is the current
ASN.1 format:

TPMKey ::= SEQUENCE {
        type            OBJECT IDENTIFIER
        emptyAuth       [0] EXPLICIT BOOLEAN OPTIONAL
        parent          [1] EXPLICIT INTEGER OPTIONAL
        pubkey
        [2] EXPLICIT OCTET STRING OPTIONAL
        policy          [3] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
        privkey         OCTET STRING
}

TPMPolicy ::= SEQUENCE {
        CommandCode             [0] EXPLICIT INTEGER
        CommandPolicy           [1] EXPLICIT OCTET STRING
}

> I think we also need to agree on which key is used as the parent by
> default. I'm guessing that's the reason I couldn't get my manual PEM
> file conversion to work in Github issue #11.

The idea of using an RSA parent at 81000001 is documented in the PC
provisioning guide issued by the TCG.  That's the one I've used in the
past.  However, most modern TPMs aren't provisioned this way yet, so:

> I believe openssl_tpm2_engine generates a P-256 primary key and uses
> that as the parent.

If you don't specify a parent in create_tpm2_key then we assume the
storage primary (which we deposit in the key file as TPM_RH_OWNER
[40000001]) and derive the P-256 EC key from it with TPM2_CreatePrimary
every time its used.

James

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

> Ultimately, our aim should be for people to be able to use the same PEM
> file regardless of which software stack they're using. I'll be fixing
> up GnuTLS client code to use the same files, much as I did for TPMv1
> PEM files a while ago.

Agreed

> https://mta.openssl.org/pipermail/openssl-dev/2016-December/008936.html
>  covers the format that James implemented.
> 
> I think we also need to agree on which key is used as the parent by
> default. I'm guessing that's the reason I couldn't get my manual PEM
> file conversion to work in Github issue #11.

From what I see it looks ok. tpm2-tss-engine does not support the optional
parent though, but that's about all functional difference

I'm still a bit confused about the TPM2LoadableKey vs TPM2ImportableKey.
I don't know what the use for the latter would be, since I'd assume we just
import such a key into the TPM and then use the Loadable derivate from it.

Also what's the OID that ended up in the actual fomat ?

> I believe openssl_tpm2_engine generates a P-256 primary key and uses
> that as the parent.

That's interesting. tpm2-tss-engine also uses a P256 primary key:
https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-common.h#L51
https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-common.c#L172
Could you point out the differences for the primary key template ?

Also I wonder about the encoding of the TPMKey->publicKey and TPMKey->privateKey.
tpm2-tss-engine uses TPM2B_PUBLIC and TPM2B_PRIVATE marshalled according to
the TPM library spec.

Cheers,
Andreas

Re: [tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On Tue, 2018-10-02 at 16:20 +0000, Fuchs, Andreas wrote:
> Hi David,
> 
> unfortuantely, the engines are diferent as much as their license and underlying TSSes.
> tpm2-tss (which is TCG spec conformant) and IBM's proprietary OpenSource TSS.
> 
> The tpm2-tss-engine is newer and BSD-license, whilst James's is (L?)GPL.
> Thus, we could not just take his and add a second underlying TSS but had to
> implement a completely new one to get rid of the license terms.
> So we had to come up with our own storage format.
> I also cannot look at James's codebase to not become tainted with GPL copyleft.
> 
> That's why we chose a different engine name and made sure to label PEM differently,
> so we don't get compatibility messes.
> 
> If you'd like to propose a different storage format for tpm2-tss-engine, please
> provide me with a format. Maybe we can fit it into the first 0.1 release.
> (but that would have to happen VERY quickly, i.e. the next 2 weeks).

Ultimately, our aim should be for people to be able to use the same PEM
file regardless of which software stack they're using. I'll be fixing
up GnuTLS client code to use the same files, much as I did for TPMv1
PEM files a while ago.

https://mta.openssl.org/pipermail/openssl-dev/2016-December/008936.html
 covers the format that James implemented.

I think we also need to agree on which key is used as the parent by
default. I'm guessing that's the reason I couldn't get my manual PEM
file conversion to work in Github issue #11.

I believe openssl_tpm2_engine generates a P-256 primary key and uses
that as the parent. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

Hi David,

unfortuantely, the engines are diferent as much as their license and underlying TSSes.
tpm2-tss (which is TCG spec conformant) and IBM's proprietary OpenSource TSS.

The tpm2-tss-engine is newer and BSD-license, whilst James's is (L?)GPL.
Thus, we could not just take his and add a second underlying TSS but had to
implement a completely new one to get rid of the license terms.
So we had to come up with our own storage format.
I also cannot look at James's codebase to not become tainted with GPL copyleft.

That's why we chose a different engine name and made sure to label PEM differently,
so we don't get compatibility messes.

If you'd like to propose a different storage format for tpm2-tss-engine, please
provide me with a format. Maybe we can fit it into the first 0.1 release.
(but that would have to happen VERY quickly, i.e. the next 2 weeks).

Cheers,
Andreas
________________________________________
From: tpm2 [tpm2-bounces(a)lists.01.org] on behalf of David Woodhouse [dwmw2(a)infradead.org]
Sent: Monday, October 01, 2018 22:10
To: tpm2(a)lists.01.org; James Bottomley; Nikos Mavrogiannopoulos
Subject: [tpm2] Conflicting TPM2 engines and storage formats

I'd like to add TPMv2 support to the OpenConnect VPN client. It's had
TPMv1.2 support since 2008, and I'm a bit late to the party with TPMv2.

For the OpenSSL build, it was trivial to support James's engine at
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/

That was as simple as this:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/7edab6c6c

However, I've now discovered there's another, incompatible TPM2 engine
at https://github.com/tpm2-software/tpm2-tss-engine

Not only does the engine name seem to be different, but the label of
the PEM file ('BEGIN TSS2 KEY BLOB') is different. And possibly the
ASN.1 therein? Neither seem to have a definition outside the source
code, as far as I can tell.

I was actually looking for some code I could re-use to implement the
support in the GnuTLS build, much as I did the TPMv1.2 version¹ some
time ago. I'd settle for getting some consensus on what a wrapped key
actually looks like on the disk first, though....

--
dwmw2


¹ http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c

[tpm2] Conflicting TPM2 engines and storage formats

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

I'd like to add TPMv2 support to the OpenConnect VPN client. It's had
TPMv1.2 support since 2008, and I'm a bit late to the party with TPMv2.

For the OpenSSL build, it was trivial to support James's engine at
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/

That was as simple as this:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/7edab6c6c

However, I've now discovered there's another, incompatible TPM2 engine
at https://github.com/tpm2-software/tpm2-tss-engine

Not only does the engine name seem to be different, but the label of
the PEM file ('BEGIN TSS2 KEY BLOB') is different. And possibly the
ASN.1 therein? Neither seem to have a definition outside the source
code, as far as I can tell.

I was actually looking for some code I could re-use to implement the
support in the GnuTLS build, much as I did the TPMv1.2 version¹ some
time ago. I'd settle for getting some consensus on what a wrapped key
actually looks like on the disk first, though....

-- 
dwmw2


¹ http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]