Protecting keys using a TPM

[David Woodhouse]

On Fri, 2013-03-08 at 14:03 +0000, Ross McIlroy wrote:
> 
> 
> > For PKCS#11 (the API) it is still a "simple" implementation detail:
> > take HSM-s, which store their key blobs the same way and work (almost)
> > flawlessly. PKCS#11, by the nature of it, will anyway require a "fixed
> > location" somewhere in the filesystem with a fixed module to be loaded
> > by the application, which needs installation (and possible a question
> > or two answered to configure it).
> 
> 
> I'm not sure what you mean by PKCS#11 requiring a fixed location on the
> filesystem.  Sure, it requires the app to load the correct module (which I
> hope p11-kit can help), but once you have the slots, you access them based
> on their attributes, not any fixed location AFAICT.  Am I misunderstanding
> something?

Once you have the slots...

An existing use case for the TPM is as follows. We have scripts which
use our corporate SOAP-based PKI infrastructure to provision SSL
certificates for VPN and wifi access. These scripts will give you a PEM
file containing your cert. They will *optionally* work with a TPM, and
give you a PEM file which looks like this:

-----BEGIN ENCRYPTED TSS BLOB-----

It contains an encrypted version of the key. It's not stored in the
TPM's own storage (which may be very limited). The *user* has to store
it somewhere, and hand it to the TPM when we want to *use* it. The TPM
will then decrypt it and use it on our behalf. And never give us back
the key in is decrypted form, of course.

That's the use model which OpenConnect supports at the moment, as it was
the *only* use model which worked with the OpenSSL TPM Engine and
therefore that's what I implemented for GnuTLS too.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20130308/2534e31c/attachment.bin>