Protecting keys using a TPM

[David Woodhouse]

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.

> 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.

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. 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.

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

That might be useful, if we'd be happy with the subset of TPM
functionality that can sanely be exported that way. If indeed it *is* a
subset.

> 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? :)

-- 
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/6ce4d35f/attachment.bin>