[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 06:58 -0800, James Bottomley wrote:
> > 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.

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. Like the nss-pem horridness, where we create an
object whose CKA_LABEL is the filename, and we want the soft token to
go and load that file.

You seem to be talking about software-based PKCS#11 tokens which happen
to use their *own* files behind the scenes, but all the *application*
ever knows about is sane PKCS#11 operations. That is absolutely fine.
There's plenty of examples of that — including SoftHSM, GNOME keyring,
and NSS's softokn.

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.

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.

> 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.

>   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).

Right, you need a full software token for stuff like NSS. But didn't
you already do that in GNOME keyring? It stores the CKO_CERTIFICATE
objects just like it always did, and now it's capable of storing the
actual private key of a CKO_PRIVATE object in TSS-wrapped form, but the
other attributes are still stored in its database just as they always
were?

And we could make SofTHSM and NSS support the same things.

None of *that* needs to touch on the PKCS#8 storage format at all. That
is *only* relevant to the case where the application is given a *file*
with the private key it's supposed to use, and there is no PKCS#11 in
sight.

All of the above is for *wrapped* keys, of course. Not keys stored
persistently in the TPM.

-- 
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/a0e4e99e/attachment.bin>