Protecting keys using a TPM

[Martin Paljak]

On Fri, Mar 8, 2013 at 2:44 PM, Ross McIlroy <rmcilroy at google.com> wrote:

>> 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?),
Like installing things on Mac OS X: You get a "system prompt" telling
you that something somewhere is asking for your password/PIN. Or when
installing some wrapped MSI on Windows and UAC steps in.

In practice, the command line tool (if used interactively) can be
helpful and say "you get prompted now to make change X to the system".

> As David says though, there are some aspects of the TPM security model that
> don't map well onto the PKCS#11 interface.  One I can think of off-hand is
> the consept of whether a Key is stored on the non-volatile RAM of the TPM,
> or on disk but wrapped in the TPMs internal key.

For PKCS#11 (the API) it is still a "simple" implementation detail:
take HSM-s, which store their key blobs the same way and work (almost)
flawlessly. PKCS#11, by the nature of it, will anyway require a "fixed
location" somewhere in the filesystem with a fixed module to be loaded
by the application, which needs installation (and possible a question
or two answered to configure it).

Martin