Protecting keys using a TPM

Fri Mar 15 14:49:37 PDT 2013

Hi Ross,

On Fri, Mar 8, 2013 at 6: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.

  If we care about where the key will sit in the TPM key hierarchy,
using pkcs11 isn't going to be the way to go, since p11's job is just
to be a general interface to crypto.  If you don't care about the
hierarchy issue, probably just querying a token through p11 and
checking whether the token's RSA keygen mechanism has the CKF_HW flag
set might be good enough.

  Maybe p11-kit can categorize the tokens it knows about using the
mechanism flags of the token?  That'd get exposed as some kind of a
p11-kit property so that users know that the keygen on token X will
get me an encrypted key instead of a software key.

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

  This isn't a tpm-p11 issue alone - any token accessible through
pkcs11 that has additional authentication required will run into this.
If p11-kit can close this gap that would be awesome. :-)

Kent

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