Mailing List Archive

[PATCH v3 0/5] Add TPM2 support to gnupg 2.3
This is a set of patches adding TPM support to gnupg-2.3

The architecture of the patches is that they build if the TSS
libraries are present, but all of the TPM specific code and libraries
is sequestered in tpm2daemon. If this daemon isn't present, gpg will
just run normally except it won't understand TPM keys and the
'keytotpm' command won't work. The reason for this design is so that
distributions can package tpm2daemon separately for gnupg with TPM
support.

These patches also add a testing infrastructure which uses a software
TPM to run the tpm2daemon through its usual operations.

Changes from v2 are

* add a check for a leading 0 in the rsa signature
* refactor the tpm2 support to make for easy TSS porting. Initial code
is for the IBM TSS
* add tests
* add experimental support for the Intel TSS. This is the last patch and
can be dropped without affecting any functionality.

For those who want to try it out, I've created a git tree with these
patches in at

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/gnupg.git

The master-tpm-daemon branch is current 2.3 with the TPM patches

James

---

James Bottomley (5):
tpm2d: Add tpm2daemon code
agent: Add new shadow key type and functions to call tpm2daemon
g10: add new command keytotpm to convert a private key to TPM format
tpm2d: add tests for the tpm2daemon
Add Support for the Intel TSS

Makefile.am | 7 +-
agent/Makefile.am | 5 +
agent/agent.h | 50 ++
agent/call-daemon.c | 3 +-
agent/call-tpm2d.c | 248 ++++++
agent/command.c | 57 ++
agent/divert-tpm2.c | 144 +++
agent/gpg-agent.c | 4 +
agent/keyformat.txt | 12 +-
agent/pkdecrypt.c | 8 +-
agent/pksign.c | 16 +-
am/cmacros.am | 3 +
common/homedir.c | 7 +
common/mapstrings.c | 1 +
common/util.h | 1 +
configure.ac | 76 ++
g10/call-agent.c | 22 +
g10/call-agent.h | 3 +
g10/keyedit.c | 45 +-
tests/Makefile.am | 3 +
tests/tpm2dtests/Makefile.am | 79 ++
tests/tpm2dtests/all-tests.scm | 81 ++
tests/tpm2dtests/defs.scm | 473 ++++++++++
tests/tpm2dtests/ecc.scm | 23 +
tests/tpm2dtests/longpassphrase.scm | 36 +
tests/tpm2dtests/rsa.scm | 13 +
tests/tpm2dtests/run-tests.scm | 43 +
tests/tpm2dtests/setup.scm | 48 +
tests/tpm2dtests/shell.scm | 51 ++
tests/tpm2dtests/unimportable.scm | 28 +
tools/gpgconf-comp.c | 62 +-
tools/gpgconf.h | 3 +
tpm2d/Makefile.am | 18 +
tpm2d/command.c | 508 +++++++++++
tpm2d/ibm-tss.h | 378 ++++++++
tpm2d/intel-tss.h | 667 ++++++++++++++
tpm2d/tpm2.c | 985 ++++++++++++++++++++
tpm2d/tpm2.h | 38 +
tpm2d/tpm2daemon.c | 1289 +++++++++++++++++++++++++++
tpm2d/tpm2daemon.h | 104 +++
40 files changed, 5629 insertions(+), 13 deletions(-)
create mode 100644 agent/call-tpm2d.c
create mode 100644 agent/divert-tpm2.c
create mode 100644 tests/tpm2dtests/Makefile.am
create mode 100644 tests/tpm2dtests/all-tests.scm
create mode 100644 tests/tpm2dtests/defs.scm
create mode 100644 tests/tpm2dtests/ecc.scm
create mode 100644 tests/tpm2dtests/longpassphrase.scm
create mode 100644 tests/tpm2dtests/rsa.scm
create mode 100644 tests/tpm2dtests/run-tests.scm
create mode 100644 tests/tpm2dtests/setup.scm
create mode 100644 tests/tpm2dtests/shell.scm
create mode 100644 tests/tpm2dtests/unimportable.scm
create mode 100644 tpm2d/Makefile.am
create mode 100644 tpm2d/command.c
create mode 100644 tpm2d/ibm-tss.h
create mode 100644 tpm2d/intel-tss.h
create mode 100644 tpm2d/tpm2.c
create mode 100644 tpm2d/tpm2.h
create mode 100644 tpm2d/tpm2daemon.c
create mode 100644 tpm2d/tpm2daemon.h

--
2.26.2


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [PATCH v3 0/5] Add TPM2 support to gnupg 2.3 [ In reply to ]
Hi James,

> This is a set of patches adding TPM support to gnupg-2.3

Thanks for the patches. I was already considering when to add your old
patches. So these reworked patches really came in time for a new beta.
Thanks.

> tpm2d: Add tpm2daemon code
> agent: Add new shadow key type and functions to call tpm2daemon
> g10: add new command keytotpm to convert a private key to TPM format
> tpm2d: add tests for the tpm2daemon

I applied all these patches with a few minor changes. However, I have
not yet tested anything, just made sure that it builds fine.

The tests duplicate quite some some code but I guess we better live with
this until we could rework the test framework. header blurbs are
missing but there is an SPDX line thus this should be okay.


> Add Support for the Intel TSS

I am not sure about this one and whether this needs to be applied right
now. My installed libtss-dev version is the 2 years old 1045-1.2.

The files in tpm2d/ are missing the usual header blurb. I assume they
are all meant to be GPL-3. I attach a patch adding them. Would you
mind to sign this off and send a fixed patch? In fact I am not sure were
you use the code too and thus a different license version might be
desired.

The whole gpg with TPM thing sounds interesting. I took quite a while
to add this to master since you first showed be it at some FOSDEM.
Sorry.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [PATCH v3 0/5] Add TPM2 support to gnupg 2.3 [ In reply to ]
On Wed, 2021-03-10 at 15:06 +0100, Werner Koch wrote:
> Hi James,
>
> > This is a set of patches adding TPM support to gnupg-2.3
>
> Thanks for the patches. I was already considering when to add your
> old patches. So these reworked patches really came in time for a new
> beta. Thanks.

You're welcome.

> > tpm2d: Add tpm2daemon code
> > agent: Add new shadow key type and functions to call tpm2daemon
> > g10: add new command keytotpm to convert a private key to TPM
> > format
> > tpm2d: add tests for the tpm2daemon
>
> I applied all these patches with a few minor changes. However, I
> have not yet tested anything, just made sure that it builds fine.

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

> The tests duplicate quite some some code but I guess we better live
> with this until we could rework the test framework. header blurbs
> are missing but there is an SPDX line thus this should be okay.

Yes, there's also doc missing, but I thought we could add that after
the fact if you agree to the keytotpm command. It's basically just
that to convert an existing key to TPM format. After that everything
should just work (except once the key is converted it can't be
unconverted and it will stop operating if you lose your TPM or clear
it).

>
> > Add Support for the Intel TSS
>
> I am not sure about this one and whether this needs to be applied
> right now. My installed libtss-dev version is the 2 years old 1045-
> 1.2.

It doesn't need to be applied immediately. Your libtss-dev is an IBM
version number and the above patches, without this one, should work
with every IBM TSS however old.

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).

> The files in tpm2d/ are missing the usual header blurb. I assume
> they are all meant to be GPL-3.

Yes, that was the intention ... I always forget header files, sorry.

> I attach a patch adding them. Would you mind to sign this off and
> send a fixed patch? In fact I am not sure were you use the code too
> and thus a different license version might be desired.

I copied the code with modifications from a different project which is
under LGPL:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/

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.

I am contemplating helping gnutls add TPM2 support using the same
framework, but their crypto system will require different modifications
of the base files.

> The whole gpg with TPM thing sounds interesting. I took quite a
> while to add this to master since you first showed be it at some
> FOSDEM.

> Sorry.

Well, stuff takes a while, thanks for adding it. Since it was always
targetted at 2.3, there's no real delay anyway.

James
Re: [PATCH v3 0/5] Add TPM2 support to gnupg 2.3 [ In reply to ]
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.

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.

> 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?


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).


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [PATCH v3 0/5] Add TPM2 support to gnupg 2.3 [ In reply to ]
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
Re: [PATCH v3 0/5] Add TPM2 support to gnupg 2.3 [ In reply to ]
On Thu, 2021-03-11 at 09:19 +0100, Werner Koch wrote:
[...]
> 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).

I sent the doc update as a separate patch

How about this for the blog entry:

https://blog.hansenpartnership.com/?p=1223&shareadraft=baba1223_604b8ffac6d44

It's written in wordpress so it should simply cut and paste into your
blog.

James
Re: [PATCH v3 0/5] Add TPM2 support to gnupg 2.3 [ In reply to ]
On Thu, 11 Mar 2021 08:51, James Bottomley said:

> 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

Okay, stuff for packaging folks ;-)

> 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.

Thanks for explaining. I see when we can add this.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.