Mailing List Archive: [PATCH 0/5] Add TPM2 support to gnupg

[PATCH 0/5] Add TPM2 support to gnupg

Jun 14, 2020, 10:26 AM

Post #1 of 3 (594 views)

I based these patches on the stable-2-2 branch so people can take them
for a spin easily. They seem to upport to master quite well, if that
would be the preferred destination? They also completely supersede
the old tpm-work branch because the code is fully restructured to
segregate all the TPM handling into its own daemon.

The first two patches are code rearrangement precursors. They expose
the shadow key handling functions to the broad code (we need this
because TPM keys become a new type of shadow key and now we need to
change handling based on which type of key we have) and they
restructure the daemon infrastructure. Today, there's only really one
kind of key handling subsidiary: scdaemon, but I need to introduce a
new one (tpm2daemon) and it's much easier to do this if there's a
reusable infrastructure.

The final 3 patches add the actual TPM code itself. To use this you
need to have a copy of the ibmtss library installed. Currently the
configure.ac can use the older tss2 package in sid:

https://packages.debian.org/sid/admin/tss2

But hopefully the new ibmtss package will replace it shortly.
openSUSE and fedora already have the ibmtss version of the package.

To use this you need your PC provisioned with a NV storage key.
Apparently this is falling out of favour and most of the TSS code now
derives an elliptic curve primary if it can't find the NV storage key.
I'll update the code to do this on the next go around. You can see if
you have the NV storage key provisioned by doing

tssreadpublic -ho 0x81000001

If that succeeds, you're fine. If it doesn't you can create one by doing:

key=`tsscreateprimary -hi o -st -rsa|sed 's/Handle //'`
tssevictcontrol -hi o -ho ${key} -hp 81000001
tssflushcontext -ha ${key}

Once created it will persist across reboots, but the complexity of
this is why we've all agreed to move to the rederivation method.

James

---

James Bottomley (5):
agent: expose shadow key type
agent: separate out daemon handling infrastructure for reuse
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

Makefile.am | 7 +-
agent/Makefile.am | 6 +
agent/agent.h | 97 ++-
agent/call-daemon.c | 583 +++++++++++++++++
agent/call-scd.c | 552 +---------------
agent/call-tpm2d.c | 248 ++++++++
agent/command-ssh.c | 10 +-
agent/command.c | 82 ++-
agent/divert-tpm2.c | 143 +++++
agent/findkey.c | 5 +-
agent/gpg-agent.c | 26 +-
agent/keyformat.txt | 12 +-
agent/pkdecrypt.c | 8 +-
agent/pksign.c | 14 +-
agent/protect.c | 72 ++-
am/cmacros.am | 3 +
common/homedir.c | 7 +
common/util.h | 1 +
configure.ac | 37 ++
g10/call-agent.c | 22 +
g10/call-agent.h | 3 +
g10/keyedit.c | 45 +-
tools/gpgconf-comp.c | 15 +
tpm2d/Makefile.am | 18 +
tpm2d/command.c | 570 +++++++++++++++++
tpm2d/tpm2.c | 969 ++++++++++++++++++++++++++++
tpm2d/tpm2.h | 39 ++
tpm2d/tpm2daemon.c | 1434 ++++++++++++++++++++++++++++++++++++++++++
tpm2d/tpm2daemon.h | 130 ++++
29 files changed, 4573 insertions(+), 585 deletions(-)
create mode 100644 agent/call-daemon.c
create mode 100644 agent/call-tpm2d.c
create mode 100644 agent/divert-tpm2.c
create mode 100644 tpm2d/Makefile.am
create mode 100644 tpm2d/command.c
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 0/5] Add TPM2 support to gnupg [ In reply to ]

gnupg-devel at gnupg

Jun 24, 2020, 3:53 AM

Post #2 of 3 (587 views)

Permalink

Hi!

thanks for the patches. They are quite large and thus I don not want to
have them in our 2.2 LTS branch. Instead I started to port them to
master (2.3). There are a couple of changes how scdaemon is managed in
master and thus part 2 of your packages requires quiet some changes.

I really liked your changes to separate things as far as possible.

I have pushed part 1 and part 2 as a start and will look into adding the
remaining patches as time permits. To avoid build problems and also
because we do not want to include the TPM thing into our regular tests,
the TPM support will need to be hidden" behind a configure option; I
hope that is okay for you.

Salam-Shalom,

Werner

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

Re: [PATCH 0/5] Add TPM2 support to gnupg [ In reply to ]

gnupg-devel at gnupg

Jun 24, 2020, 9:42 AM

Post #3 of 3 (587 views)

Permalink

On Wed, 2020-06-24 at 12:53 +0200, Werner Koch wrote:
> Hi!
>
> thanks for the patches. They are quite large and thus I don not want
> to have them in our 2.2 LTS branch. Instead I started to port them
> to master (2.3).

Thanks. I've actually got a v2 coming that strips out more of the
scdaemon pieces that were copied over. It also adds support for
systems which don't have the persistent storage key provisioned, which
seems like it's going to be all of them.

> There are a couple of changes how scdaemon is managed in master and
> thus part 2 of your packages requires quiet some changes.
>
> I really liked your changes to separate things as far as possible.
>
> I have pushed part 1 and part 2 as a start and will look into adding
> the remaining patches as time permits.

OK, I can base off that. I have a minor update ... some pieces of
patches 1 and 2 managed to stray into the later series which I noticed
after I'd sent it, but I can do an explicit interdiff.

> To avoid build problems and also because we do not want to include
> the TPM thing into our regular tests, the TPM support will need to be
> hidden" behind a configure option; I hope that is okay for you.

I'm fairly ambivalent. I like systems that just build according to the
capabilities, but it is nice to have autoconf tell you why the --with-
tpm you selected can't work without X packages. However, for testing
there's no reason why TPM support should impact the regular tests at
all. As long as you don't have a TPM format key and never exercise
keytotpm, the TPM side will never get used.

I can also give you a test harness based on the software TPM emulator
that can run TPM based tests. You can see how I use it here:

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

Although I bet I should have used a test runner to start and stop the
software TPM.

James

Mailing List Archive

Attached Files:

Attached Files: