Protecting keys using a TPM
stefw at redhat.com
Fri Mar 8 06:16:05 PST 2013
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).
p11-kit provides a standard system for module location. rpms install
modules and their p11-kit module conf files to a standard location ,
and it's picked up by any application using p11-kit or the
BTW ... poke, poke, do you know why opensc still doesn't ship  a
p11-kit module conf file? Downstream packagers do .
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
More information about the p11-glue