Protecting keys using a TPM

[Stef Walter]

On 03/07/2013 07:44 PM, Ross McIlroy 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)

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?

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

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.

> p11-kit seems a good place to start to address (i) - if p11-kit becomes
> the standard for merging the system-wide pkcs11 modules, then apps only
> need to load a single well-known module to have access to all the keys
> provided, including those on the TPM.

Agreed.

> However, even with p11-kit, (ii) and (iii) still present a challenge.
>  It would be great to have a situation where the user specifies that
> they want keys to be stored on the TPM rather than on-disk, and the app
> could figure out how to do this without the user having to specify
> exactly which slot to use.  I'm not sure if it's possible within the
> constraints of PCKS#11, but has there been any thought on creating some
> kind of structured hierarchy of the slots/modules provided by p11-kit,
> whereby an app could decide on which slot to use based on its security
> properties?

Yes, this is an area that needs work. It may be that we explicitly mark
slots prefered for various operations by using PKCS#11 URIs. Or it may
be that we need to work within the PKCS#11 OASIS TC to define a standard
way to do this.

I know that we had a similar issue defining a place where to store trust
objects. The solution I came up with is based on PKCS#11 URIs, but it
may be inadequate going forward. See:

https://git.gnome.org/browse/gnome-keyring/tree/pkcs11/rpc-layer/gnome-keyring.module.in#n6

and:

https://git.gnome.org/browse/gcr/tree/gcr/gcr-library.c#n161

> Similarly, having to unlock the TPM using a pin which is separate from
> the users credentials seems unwieldy.  Would it be worth considering
> enabling p11-kit to handle login operations on behalf of it's delegate
> modules?  For example, p11-kit could be configured to load a TPM module
> with two slots - one of which p11-kit logs-in automatically on user
> login (perhaps using a pin based on the users login-credentials), while
> the other is only logged-in when an app requests it to be, at which
> point p11-kit throughs up a system prompt to request the users
> unix-credentials and uses these to derive the correct pin.  This might
> be something that would be better suited to being part of gnome-keyring,

Exactly. Looks like we've come up with the same concept. I like that.

The agent in use would be part of gnome-keyring when running on GNOME.
But the underlying implementation would be part of p11-kit.

So to implement this I first need to merge this branch:

http://cgit.freedesktop.org/p11-glue/p11-kit/commit/?h=managed

That contains the infrastructure needed for these features:

 * Call logging
 * Remote modules
 * Shared modules (in a daemon)
 * Authentication prompting

I'm working on these features as a way of moving code from gnome-keyring
into a more general purpose widely usable solution.

Cheers,

Stef