Protecting keys using a TPM

Stef Walter stefw at
Fri Mar 8 02:31:26 PST 2013

On 03/08/2013 10:14 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, Mar 7, 2013 at 7:44 PM, Ross McIlroy <rmcilroy at> wrote:
>> Hi,
>> I'm currently looking into improving the end-to-end support for storing and
>> accessing private keys / certificates on TPM devices on Linux.  At present
>> it is possible to use OpenCryptoKI to provide a PKCS#11 interface to the
>> TPM, however, there are a number of issues which make doing so inconvenient:
>>    - (i) Applications need to be configured to explicitly dlopen the
>> OpenCryptoKI pcsk11 module library
>>    - (ii) They need to discover which slot holds the TPM token (if any)
>>    - (iii) They need to provide a pin to OpenCryptoKI to login to the TPM
>> token to perform any operations (e.g., signing, encryption, etc.) with the
>> private keys stored there or to add new keys.  Since this pin is not linked
>> to the users login credentials, it's an added complication for them, as well
>> as an added complication for developers who need to provide some gui /
>> command-line pin input mechanism.
> I was looking at the same issue a while ago. The OpenCryptoKI TPM-PKCS
> #11 module was so hard to setup for that didn't seem like a solution
> one could suggest to its users. I gave up and made a special type of
> URI, "tpmkey". It is simple and directly maps into TPM expected
> properties. This key type is now supported by gnutls 3.1.x.

With the caveat that it can't be enabled due to license
incompatibilities? [1]

Solving these kind of things once per crypto library (and application,
like openconnect) is a bummer. Solving it once and for all is really the
way to go, and that's the goal of PKCS#11.

Should we try and make the opencryptoki PKCS#11 module easier to use? Is
it opencryptoki that is broken here? Or did you run into some limitation
in PKCS#11?

Should we write a simple PKCS#11 read-only TPM module which just works?
I wouldn't mind giving that a shot.

What are the requirements? Obviously there's these file based keys. If
we have a standard location for them (where they live or are symlinked
to), we can easily represent them in a PKCS#11 module.




More information about the p11-glue mailing list