Protecting keys using a TPM

[Stef Walter]

On 03/08/2013 12:46 PM, David Woodhouse wrote:
> On Fri, 2013-03-08 at 11:31 +0100, Stef Walter wrote:
>> On 03/08/2013 10:14 AM, Nikos Mavrogiannopoulos wrote:
>>> On Thu, Mar 7, 2013 at 7:44 PM, Ross McIlroy <rmcilroy at google.com> 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]
> 
> Someone at IBM really ought to be shot for that. Releasing the TSS
> library under a licence which prevents people from using it in GPL'd
> programs is insane.
> 
> Kent, is there anything we can do about that?
> 
>> 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.
> 
> Well, yes. I resent fairly much *every* line of code I have in
> OpenConnect's openssl.c and gnutls*.c. All I'm trying to do is load and
> use a client SSL certificate that the user specifies on the command
> line, and validate the server's certificate. Fairly basic requirements,
> but still:
> 
>   2142 gnutls.c
>    532 gnutls_pkcs12.c
>    340 gnutls_tpm.c
>   1508 openssl.c
>   4522 total
> 
> There is *more* to that problem than can be solved by PKCS#11 alone.

Yes, I believe attestation and various other advanced modes of TPM
cannot currently be modeled in PKCS#11. This was touched on in the newly
formed OASIS PKCS#11 TC.

But in any case, what all of us here want to use it for is as a simple
smart card (with actual user keys stored awkwardly in files,
notwithstanding). I think this is doable.

>> 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?
> 
> There's a little of both IIRC, although I personally got stuck on the
> first. It turned out to be *easier* to just write code to make GnuTLS
> support the TPM directly, than it was to make the whole baroque
> opencryptoki thing work. I tried to get opencryptoki working, and I
> failed. And I decided I couldn't inflict it on my users.

Fair enough.

> I believe the full security model of the TPM can't easily by represented
> by PKCS#11. I don't remember which *part* was problematic, offhand. It
> has separate SRK and user PIN storage of its own for keys, and internal
> storage for both classes too. 

PKCS#11 actually has three possible PIN types, CK_SO, CK_USER, and
CK_CONTEXT_SPECIFIC (the last of which is essentially a per key PIN,
usually equal to CK_USER, but nothing prevents it from being different).

> And it can operate using a key that
> *isn't* stored internally, where the user has a file containing a key
> that's encrypted with the TPM's internal key. When you want to *use*
> that key, you hand the encrypted blob to the TPM and ask nicely.

That's easy to model in one of two ways:

 * Have files in a standard location automatically exposed.
 * Have applications that want to use random files, import (ie:
   with C_Unwrap) the TSS keys before hand as PKCS#11 session (ie: not
   stored on the token) keys.

Both model what we want to do pretty nicely.

In addition there can be separate tokens for system/user/file keys.

>> 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.
> 
> Can we have full absolute file paths? :)

That is something that's ugly about PKCS#11 (i never said it was pretty,
only that it was standard :D) is the lack of dynamically created tokens.

But as noted above, there's a simple solution for modeling this.

Anyway, the reason I'm interested in all of this is because I want to be
able to leverage TPM chips in gnome-keyring to automatically unlock the
keyring when the user is using auto-login.

Cheers,

Stef