Protecting keys using a TPM

[Stef Walter]

On 03/08/2013 01:54 PM, Martin Paljak wrote:
> 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).

Right so:

p11-kit provides a standard system for module location. rpms install
modules and their p11-kit module conf files to a standard location [1],
and it's picked up by any application using p11-kit or the
p11-kit-proxy.so module.

BTW ... poke, poke, do you know why opensc still doesn't ship [2] a
p11-kit module conf file? Downstream packagers do [3].

Although not all crypto libraries load these configured modules by
default, the goal is to have this happen.

As far as the module itself needing configuration, a general purpose
PKCS#11 software module shouldn't need configuration by default. In the
case of the TPM module we would:

 * Use a standard location for keys loaded automatically. This solves
   the issue that Ross brought up about having TPM keys that apps can
   just use without muss or fuss.

 * 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

Cheers,

Stef

[1] http://p11-glue.freedesktop.org/doc/p11-kit/pkcs11.conf.html

[2] https://www.opensc-project.org/opensc/ticket/390

[3] http://pkgs.fedoraproject.org/cgit/opensc.git/tree/opensc-module