Protecting keys using a TPM

Fri Mar 8 04:44:16 PST 2013

>
> >    - (ii) They need to discover which slot holds the TPM token (if any)
> We could use a PKCS#11 URIs for this. Is this a TPM specific problem?
> Usually callers (ie: crypto libraries) look through all available slots
> for keys which apply. But the TPM use case may be different. Could you
> elaborate on it?

As below, I was more thinking about the case where the app (e.g.,
ssh-keygen) want's to store a key with certain security properties.  This
probably isn't as big of an issue as simply accessing the keys on the TPM
sanely though.

Yes, prompting is a sore point of using PKCS#11 modules. I'm working on
> a feature in p11-kit which allows prompting to be done by an agent.
> This overrides the C_Login and related calls, and changes its behavior
> to that of CKF_PROTECTED_AUTHENTICATION_PATH. This indicates to the
> caller of the module that it does not need to prompt for a PIN but rely
> on the module to do the prompting. p11-kit intercepts the call and does
> the prompting (calling into the GUI) and then passes the prompted PIN
> into the underlying module.

This should be a good improvement from the app developers side (at least
for GUI programs - how would this work with command-line
tools?), although it still relies on the users knowing what the pin is for
their TPM device (and even knowing what it means when they get a pop-up
stating "Enter pin for TPM device").  It seems to me that it would be
better to have Linux distros setup the TPM with a SRK / user-pin which is
known or can be derived by (or stored in) p11-kit or gnome-keyring - that
way, p11-kit (using managed modules) can be in charge of locking-unlocking
the TPM based upon it's own knowledge of whether the user is logged in or
not, or requires additional password prompting.  I'm not sure how this
would work, and might end up being quite OpenCryptoKI specific, but it
might be worth a go

I agreed with Nikolas that the internals of OpenCryptoKI are really complex
complex, but I still think it would be nice to have a single interface to a
users credentials for all apps, and PKCS#11 could provide that.  One other
thing I have been looking at is the Chaps library which is part of ChromeOS:
  http://www.chromium.org/developers/design-documents/chaps-technical-design
  http://git.chromium.org/gitweb/?p=chromiumos/platform/chaps.git;a=summary

This is much simpler that OpenCryptoKI and provides a PKCS#11 interface to
the TPM, but it is currently quite ChromeOS specific, and its unclear how
easily it could be ported to Linux.  I'm going to have a look into this
though.

As David says though, there are some aspects of the TPM security model that
don't map well onto the PKCS#11 interface.  One I can think of off-hand is
the consept of whether a Key is stored on the non-volatile RAM of the TPM,
or on disk but wrapped in the TPMs internal key.  AFAIK, OpenCryptoKI
stores everything on disk wrapped.

I think a good aim would be to make it possible for apps which support
PKCS#11 to access TPM protected keys without masses of configuration.  The
other use-cases (e.g., key-generation, etc.), are maybe better solved using
TPM specific tools.

Cheers,
Ross

On 8 March 2013 11:46, David Woodhouse <dwmw2 at infradead.org> 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.
>
> > 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20130308/6cea1a5b/attachment-0001.html>