Protecting keys using a TPM

Fri Mar 8 10:32:42 PST 2013

On Fri, Mar 8, 2013 at 4:44 AM, Ross McIlroy <rmcilroy at google.com> wrote:
>> >    - (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.

Consider this a hearty +1 for Chaps.

In working with ChromeOS from the perspective of a client browser, I
can see TPMs are largely of the devil when it comes to user
experience. They're understandably slow as all get out, have limited
memory for keys, the previously mentioned interactivity concerns, and
- most notably - do not play well with multi-process.

Chaps acts as a system daemon to broker interaction with the TPM, and
in a way that allows Chaps to (more efficiently) provide access to the
services provided by the TPM. It does so by providing a shim PKCS#11
module that talks to the Chaps daemon, and then the Chaps daemon
interacts with the TPM (via OpenSSL, IIRC, although previous
iterations shim'd OpenCryptoki).

Our performance experiences and expectations with respect to
ChromiumOS (both the browser and for other services, such as
wpa_supplicant) lead us to believe this sort of approach is a superior
design than the existing alternatives.

I'm not sure whether such a daemon fits within the scope of p11-kit
and what it tries to provide, or if it makes more sense as a
standalone daemon that provides a p11-kit config file, but I suspect
it's much more preferable than directly integrating TPM interactions
(or OpenCryptoki) to p11-kit.

Just my $.02 of experience on this.

>
> 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
>
>
>
> _______________________________________________
> p11-glue mailing list
> p11-glue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/p11-glue
>