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

[David Woodhouse]

On Fri, 2016-12-02 at 08:03 -0800, James Bottomley wrote:
> >   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).

There are two problems with PKCS#11 and TPM.

Firstly, PKCS#11 only supports one PIN per PKCS#11 provider. If each
key can have its *own* PIN, that doesn't work so well. You can play
deprecated tricks and have a separate slot for each key, but that
quickly gets horrid, and more so when you consider the second
problem...

Secondly, wrapped keys don't actually exist in the TPM so there's no
'URI' that you can refer to them by; they are ephemeral. The encrypted
key is actually *in* the PEM file, and gets loaded into the TPM for it
to decrypt and use.

So to cope with this through PKCS#11 you'd need some kind of nasty hack
where it loads the PEM file and a new token magically "hotplugs" into
existence. We already have something that's *almost* this horrid, with
the nss-pem abomination that NSS uses to load PEM files; you call the
C_CreateObject() method using an object 'label' which is actually a
file name.... it's vile, and it's not really a model we want to follow.

I think we really do need native support for loading these PEM files,
and not to attempt to make it work through PKCS#11.

-- 
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/20161205/17aed257/attachment-0001.bin>