Protecting keys using a TPM

[Stef Walter]

On 08.03.2013 19:32, Ryan Sleevi wrote:
> 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.

Cool. I'll play with Chaps a bit and see how it could be used.

On the other hand, a ton of PKCS#11 modules have the same limitations
you've noted above about TPMs. So I've been working on doing sorta the
same thing in p11-kit (daemon with shared modules loaded) but usable in
a generic sense for any PKCS#11 module.

This is a larger part of the remoting PKCS#11 effort, which solves this
and several other issues nicely.

But I'll to take a look at Chaps and see what's already been done.

Cheers,

Stef