Protecting keys using a TPM

[Kent Yoder]

Hi Ross, now that I'm back from vacation I'll respond with a little
more detail that might help.

On Thu, Mar 7, 2013 at 12: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.
>
> 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.

  i, ii, and iii are all pkcs11-only issues, unrelated to the TPM.
IMHO it sounds like p11-kit would be a good place to try to solve
them.

  For some background on opencryptoki's tpm token - one of the things
we wanted to accomplish there was migration support. If your TPM dies
we wanted to be able to take the entire opencryptoki TPM token data
store and move it to a new machine. To do this we created 2 new keys
which serve as the roots of the TPM key hierarchy for pkcs11 public
objects and pkcs11 private objects.  We create these 2 keys using
openssl in software, then wrap them both using the SRK.  These are
stored internally to opencryptoki and are the parents of all keys
created through pkcs11.

  Because of the migration support, key importing becomes an issue. If
you've got a key lying around on your filesystem who's parent is the
SRK, we have no way to import it into opencryptoki and guarantee
migration support.

  Perhaps we could hack opencryptoki so that it can accept keys whos
parent is the SRK.  We have no plans to do this atm, but it might be
worthwhile in the interests of creating a single centralized keystore.
 On the other hand it sounds like several people have already added
native TSS support.

Kent