[PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon

[James Bottomley]

On Tue, 2018-07-31 at 09:31 +0200, Wiktor Kwapisiewicz wrote:
> > The difficulty I have with adding PCR policy to TPM protected gpg
> > keys
> > is that PCR policy handling is a very esoteric function and it's
> > difficult to see value beyond the current platform locking the TPM
> > already does since the user would have to understand when the PCR
> > values changed and how to update the keys with new PCR values,
> > which
> > would really put a kink in usability.
> 
> I agree this is more esoteric and probably not that useful for the 
> majority of users.
> 
> For my use case I'm thinking on full disk encryption with keys copied
> to TPM where I'd like it to break if the configuration changes. If I 
> changed it I would copy the keys again, if I didn't do the
> configuration change I'd see it.

OK, so there's a problem here: disk encryption has to be done with a
symmetric key because asymmetric operations are too slow.  The TPM can
do symmetric key operations, but certainly not fast enough for bulk
data, so the only viable mechanism for disk encryption is for something
to release the symmetric key to a software encrypt/decrypt system.  In
the LUKS model (and the TPM trusted keys model in the kernel), the TPM
does this by a data unseal operation which can be linked to PCRs.

Gnupg does have a sort of equivalent in the way it encrypts and
decrypts messages: it generates a temporary symmetric key and wraps
that symmetric key with the recipient public keys but to preserve
forward secrecy, the symmetric key is different for every message.  So
while one could imagine using the gnupg wrapping mechanism for key
unsealing it's a bit of a stretch use case.

> One way or another TPM keys are already big improvement for secure 
> storage of keys so thank you for working on it!

You're welcome,

James