Protecting keys using a TPM
stefw at redhat.com
Fri Mar 8 00:07:35 PST 2013
On 03/07/2013 07:44 PM, Ross McIlroy wrote:
> 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.
> 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
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:
> 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:
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.
More information about the p11-glue