[PATCH v3 0/5] Add TPM2 support to gnupg 2.3

[James Bottomley]

On Thu, 2021-03-11 at 09:19 +0100, Werner Koch wrote:
> On Wed, 10 Mar 2021 10:04, James Bottomley said:
> 
> > Unfortunately debian doesn't package a software TPM ... I don't
> > know why, most other distributions do.  I have one here in deb
> > format:
> > 
> > https://build.opensuse.org/package/show/home:jejb1:TPM/swtpm2
> 
> Thanks.
> 
> > For the Intel TSS on debian you need libtss2-dev from the tpm2-tss
> > source package.  The version on stable is too old (2.1.0) but the
> > version in testing will work (3.0.3).
> 
> I deinstalled the IBM stack and the Intel code works with the opther
> patch.
> 
> > But I own copyright in all the base files I've added to your repo,
> > so I'm happy for them to remain under GPLv3 going forward.  Since
> > they had to be modified to support gcrypt, I don't think there's
> > much direct reuse outside of the GPLv3 licence.
> 
> If there is ever a need we can easily chnage back to LGPL for tehse
> parts.  I pushed my proposed patch with a link to your mail.

Yes, that looks fine.

> We plan to do Debian packages; do you have any advise which stack we
> should prefer?  I guess IBM, becuase that one is tried first in
> configure.

The Intel TSS is very new.  I've actually been using the IBM TSS
version of the patches with gnupg-2.2 for several years, so it's fairly
well tested.  I thought once I had a testing infrastructure it would be
easy to verify the Intel TSS patch, which I did in my local
environment.  However, when I pushed the Intel TSS build to the
openSUSE build servers, it exploded on pretty much every non-current
distro because of API mutations.  I think the configure.ac check I
added catches all the problems, but I wouldn't necessarily bet the farm
on it.

So the bottom line is the most reliable build is with the IBM TSS
although the Intel TSS in debian testing seems to work fine as well.

> > Well, stuff takes a while, thanks for adding it.  Since it was
> > always targetted at 2.3, there's no real delay anyway.
> 
> Now with TPM support in place, do you think that we could now go
> after the passpharse caching code which states:
> 
> /* The encryption context.  This is the only place where the
>    encryption key for all cached entries is available.  It would be
> nice
>    to keep this (or just the key) in some hardware device, for
> example
>    a TPM.  Libgcrypt could be extended to provide such a service.
>    With the current scheme it is easy to retrieve the cached entries
>    if access to Libgcrypt's memory is available.  The encryption
>    merely avoids grepping for clear texts in the
> memory.  Nevertheless
>    the encryption provides the necessary infrastructure to make it
>    more secure.  */
> static gcry_cipher_hd_t encryption_handle;
> 
> It would be sufficent if we could limit the time this symmetric
> encryption key is exposed in memory to a minimum by encrypting the
> key with the tpm.  Any ideas how to best integrate this?

It's certainly possible.  The TPM API you're after is called the
sealing one.  What happens is that the TPM can encrypt a blob of data
up to 128 bytes with a TPM internal key and give it back to you when
you call TPM2_Unseal().  For safety, since the password cache isn't
expected to survive a reboot, the parent of the seal operation should
be the NULL seed, so the sealed data becomes unextractable after a TPM
restart (the NULL seed changes on every restart).  You could seal the
password when it's added to the cache and unseal it just before use. 
The safety you get is that an attacker who steals memory pages can't
unseal the password unless they also can access the TPM on your laptop.
However, if the threat model is an attacker who can steal memory pages
in real time, they can likely snoop the unseal operation as well and
extract the password that way.

I can investigate coding this if you like.  Unfortunately the Intel TSS
has yet another bug around NULL seed handling, which we'll then need a
configure.ac test for:

https://github.com/intel/tpm2-tss/issues/1993

> And a last thing: It would be supercool if you could do a short
> writeup on how to use the system in practise; for example as an
> article in our blob.  Just if you can find some spare time (good
> joke, I know).

Adding documentation is on my list of things to do, so a blog entry
shouldn't be too much of a stretch.

Regards,

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210311/f2881a24/attachment.sig>