Protecting keys using a TPM
dwmw2 at infradead.org
Fri Mar 8 03:46:29 PST 2013
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? 
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,
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
> 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? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6171 bytes
Desc: not available
More information about the p11-glue