Protecting keys using a TPM

[Ben Laurie]

On 8 March 2013 14:09, David Woodhouse <dwmw2 at infradead.org> wrote:
> 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.

BTW, I am happy to contemplate changes to OpenSSL if they would help.