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

[James Bottomley]

On Wed, 2016-12-14 at 09:07 +0000, David Woodhouse wrote:
> On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
> > 
> > So the proposal is to have a TPM specific value for 
> > PrivateKeyAlgorithm (which would have to be proposed as an OID) and 
> > use PrivateKeyInfo for the key?  That could be made to work.
> 
> Right.
> 
> > The slight fly in the ointment that's worrying me is that I need a 
> > key format that works for pkcs#11 tokens as well.  The problem here 
> > is that TPM keys don't have an id or a label and that's pretty much 
> > a requirement of using a pkcs#11 token, so the pkcs#11 code has to 
> > be able to set these attributes on the key files.  I was originally
> > thinking of putting them into the PEM header with a pkcs11- prefix.
> >   I suppose I can do the same with the attributes and some 
> > manufactured OID prefix with the CKA_ parameters we're interested 
> > in as a suffix but it's messy.
> 
> Hm, this seems odd. If something is stored in a file then exposing it
> through PKCS#11 doesn't make sense at all. Do not attempt to use
> PKCS#11 for any file access.

OK, so the horse has already left the stable on that one with TPM
enabling gnome-keyring for ssh keys because it exports *every* key over
pkcs11.  Since it does, I thought I'd play about with it a bit to see
how it would work.  The below is what I found out playing around.

> Seriously, if you have any doubts about that at all, go read nss-pem
> and ponder its operation. Then drink until you've forgotten most of 
> it, but remember that PKCS#11 isn't to be used for accessing stuff 
> that you have in a file.
> 
> PKCS#11 can sanely be used for keys which are persistently stored 
> *in* the TPM storage, which *do* have a UUID which can be used as 
> CKA_ID. (Or maybe as CKA_LABEL since CKA_ID really SHOULD be the 
> pubkey hash, if we can manage that).

So this is the actual problem: the TPM only stores private keys.  The
public key thing (can be simple, cert or something more fancy) isn't
known to it.  All pkcs11 searchers find the public key in the public
objects and then look for the private key by id and label (this is what
the standard recommends).  The problem is that the label they use isn't
going to be the UUID, so we need the private key to be labelled by what
its public counterpart expects to use the TPM for arbitrary keys, like
certificate private keys (or even gpg or ssh private keys).  The UUID
thing works for stuff that expects separate private and public key
descriptions, like gnutls and openssl, but not for anything that uses
the full pkcs11 protocol (like netscape).

The second problem is that C_FindObject expects to be able to search
all the keys.  Unfortunately, neither the TPM nor Trousers has an
enumeration protocol for TPM objects (we could hack trousers to do it,
becuase it knows every key it inserted in an internal database, but
there's no TSS API for it).  Without enumeration, searching fails.

Based on this, I think offline keys are a better format for pkcs11
because we have all the data present and can make it searchable.  ssh,
for instance, internally finds the private key using CKA_MODULUS and
CKA_PUBLIC_EXPONENT, which we can't do if the key is inside the TPM,
before exporting it by id (md5 fingerprint) and label (ssh comment).

Plus there's the unsolved resource issue, of course: we can only fit
about 10 keys in the TPM, whereas offline is infinitely expandable.

My vision of how this would work is that we probably need a database of
attributes.  For certificates it's going to look something like the
keyring gnome2 one, so there's no way to base any sophisticated pkcs11
implementation on something that doesn't have files at its core
(regardless of where the TPM key resides).  I'm agnostic over whether
we have two files (one for the private and one for the public key) or a
single one.  I'm actually starting to think that a vanilla private key
coupled with an attribute search on CKA_MODULUS,CKA_PUBLIC_EXPONENT is
the best thing to do (except it won't work with TPM loaded keys).

James


> If you're talking about a PKCS#11 token which has its *own* storage 
> of wrapped keys, then sure — you can keep whatever metadata you like.
> But you don't need that to be part of the PKCS#8 standard format. In 
> fact if you want this you're probably better off extending SoftHSM to
> stored wrapped keys and use the TPM for operating them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161214/e6bcc269/attachment.bin>