[openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[James Bottomley]

On Thu, 2016-12-01 at 12:49 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote:
> 
> > >     > The point here is that because there's a pem file
> > > representation of the
> > >     > key, it can be used anywhere a PEM file can be *without*
> > > having
> > > to tell
> > >     > openssl what the engine is (the PEM guards being unique to
> > > the
> > > key
> > >     > type).
> > >     
> > > Well, I think I can see your point (except for the above 
> > > question), but frankly I don’t like this approach very much.
> > 
> > It's already a mechanism used by gnutls to load TPM keys, so it 
> > makes sense from a compatibility point of view that it should just 
> > work for openssl as well.  It doesn't preclude using a pkcs11 token 
> > approach as well, it's just a different mechanism for handling
> > keys. 
> 
> Note that gnutls' mechanism relies on the "tpmkey:" URLs to load 
> them, rather than loading via any other PEM mechanism. The URL 
> approach has the advantage that it provides a uniformity in handling 
> similar to PKCS#11 URLs (and it wouldn't matter whether these keys 
> are in file, in the TPM itself or in some other OS storage area - you 
> specify them all the same).
> 
> However, neither of URLs or file loading would survive the TPM 2.0
> thing.

Actually, I believe it will.  The main difference is that TPM2 has
multiple SRKs so you need to know which one, plus TSS2 will be
different from TSS1 so they can't be handled by the same engine: so the
format will have a new guard (TSS2 KEY BLOB probably) and the multiple
root can be coped with by specifying the root as a PEM parameter).

Incidentally, a similar problem does exist in TPM1: although everything
chains up to a single SRK, you can have multiple sub SRK storage keys
to which the keys are wrapped.  Right at the moment, the current
openssl_tpm_engine doesn't contemplate this possibility, but I'm
thinking of extending it to do so, because it's useful when doing TPM
tenancy (cloud container use case).

>  Most likely (and hopefully) the latter keys will be handled over
> PKCS#11 rather than directly.

I have reservations about scaling pkcs11 into a multi-tenant
environment, but I agree, in principle it is possible.  I'm looking at
trying to do it better for TPM now (well, it's the next thing to get to
on my list).

James