Protecting keys using a TPM

[Stef Walter]

On 03/08/2013 04:31 PM, Nikos Mavrogiannopoulos wrote:
> On 03/08/2013 03:16 PM, Stef Walter wrote:
> 
> 
>>  * Have the TPM PKCS#11 module support a C_Unwrap mechanism which
>>    allows bringing in a key from a blob of data (whether in PEM or DER)
>>    format. This becomes a session key, which the app can then use.
>>    This solves David's use case, and requires a bit more involvement
>>    from the application. David has a thing for keys at specific paths :P
> 
> 
> How could that work, I mean as simply as loading a PKCS #11 URL? 

Well it wouldn't work as URL. PKCS#11 URLs refer to stuff in tokens.

It doesn't work in the same way that you can't (at least not today,
correct me if I'm wrong) pass a PKCS#11 URL pointing to an RSA key
sitting in a PEM encoded file on your disk to gnutls and have it work.

> Would
> the user specify the file, and the application should load the
> tpm-pkcs11 module, unwrap the key, and then use operations on the PKCS
> #11 key? That is a big deviation from the simplicity of pkcs11 urls, and
> files in TPM are not a corner case, but rather the main use case.

Yes, that's why we should define the files to live in a standard
location by default. The URI's then refer to the PKCS#11 objects that
the p11-tpm module exposes for these files.

But because some applications will want to have keys live in other
locations, or in their own configuration storage, database, etc. they
(or the crypto library, like gnutls) would C_Unwrap them into the module
before usage.

> Maybe extending the URLs to specify a wrapped key like tpmkey urls
> support stored keys?

Perhaps I guess. If you really wanted to you could just use file:// URLs
in some form. That's what we do in glib-networking.

This is really about how to tell gnutls to load a file instead of use a
key in a standard store, right?  Only supporting files isn't a general
purpose solution here anyway. So I would assume that these callers with
keys in future non-standard locations (files or otherwise) would just
import the key (as you would with an RSA key today) and then use it. The
only difference being is that in order to use the TSS blob, gnutls has
to turn around and have TSS involved (via a TPM PKCS#11 module's
C_Unwrap, in the future).

Cheers,

Stef