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

[David Woodhouse]

On Wed, 2016-12-14 at 18:03 -0500, James Bottomley wrote:
> > I think we're talking about two different things. What I mean is that 
> > a given application shall never have to deal with files and PKCS#11 
> > for a given single object.
> 
> Sure (as in I thought that went without saying).

If only :)

> Yes ... I was mostly reacting against your statement that the keys
> needed to be inside the TPM for PKCS11 use.

Ok. I didn't (mean to) say that.

> > And you'll note that none of those examples need extensions to the
> > PKCS#8 format to store arbitrary PKCS#11 attributes such as 
> > CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because 
> > it's their own database and they can do what they like; they don't 
> > have to store it in a PKCS#8 or similar file.
> 
> OK, so as long as you're happy with pkcs11 being used on TPM key files
> which are then loaded as needed via the pkcs11 interface, I think we're
> on the same page. 

I think so, but *ick*, don't say "files".

I'm happy with PKCS#11 being used, where the PKCS#11 provider keeps its
own database (completely separate from the application, like NSS
softokn, SoftHSM, GNOME Keyring already do it).

We don't normally use the word "files" when we talk of high-level
concepts involving those three examples, even though SoftHSM actually
does use individual files for storage. So let's avoid confusion by not
talking about 'files' for the TPM one either. In this usage model, the
application never sees a file.

The application uses a PKCS#11 token. That token has its own storage
which as far as the application is concerned, is magical.


There is *another* usage model, where the application actually sees a
file akin to the existing -----BEGIN TSS KEY BLOB----- files (and for
which we ought to extend PKCS#8 to do it properly). That usage model
should also be supported.

>  I'm coming to the conclusion that we need the files
> in pairs and the public key can supply the attributes ... it's more or
> less how gnome keyring currently does it.

You want it *exactly* how GKR (or the other examples I gave) do it,
with the sole exception that RSA keys can be wrapped by the TPM
instead. I had also been talking about using Skylake's SGX software
enclaves to do a similar augmentation to software tokens.

> > The example you give with GNOME keyring doing SSH keys is a 
> > *different* special case. There it's automatically discovering the 
> > files in a known location (~/.ssh/id_*) and has to infer what it can 
> > from them, but still it's only exposing them over PKCS#11 in a 
> > standard way. There's none of the horridness for 'here, load *this* 
> > file into the token', is there? You can do that with ssh-add perhaps, 
> > but that's mostly orthogonal to what we're talking about here.
> 
> OK, so a token can be writeable as well, but I expect the object to be
> loaded into the token to be correctly serialised according to the
> protocol and also possibly wrapped.
> 
> > > 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).
> > 
> > Which part of the standard are you referring to? It isn't really that
> > prescriptive about how you look things up, as far as I was aware.
> 
> Section 4.8 in the current OASIS base spec:
> 
>     The CKA_ID field is intended to distinguish among multiple keys. In
>     the case of public and private keys, this field assists in handling
>     multiple keys held by the same subject; the key identifier for a
>     public key and its corresponding private key should be the same. The
>     key identifier should also be the same as for the corresponding
>     certificate, if one exists.
> 
> In practice it seems that most things use CKA_ID and CKA_LABEL if they
> both exist.

OK, right. So it isn't just NSS; *most* things will automatically try
to find a private key once they've already been pointed at the cert, by
matching CKA_ID and/or CKA_LABEL. Sure, you *can* explicitly point at
separate cert and privkey, but you generally shouldn't need to.

> > All of the above is for *wrapped* keys, of course. Not keys stored
> > persistently in the TPM.
> 
> I'm starting to think keys permanently loaded into the TPM aren't the
> right way to go ... 

Right, which is why I stopped there at the observation that we weren't
talking about that :)

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