Mailing List Archive

Hi James,

I'm very interested in your TPM patches (as a user).

Could I ask you some questions on how does it work?

I would like to have keys wrapped by TPM in such a way that the change
in system configuration would render the key useless. As far as I've
seen it's possible to do that by utilizing Platform Configuration
Registers (PCRs). Would keys created by your TPM code have this property?

Thanks in advance for answer!

Kind regards,
Wiktor

> Sorry this has taken so long. For some reason, I found assuan really
> hard to get on with and the documentation somewhat perfunctory, so I
> had to actually go the libassuan sources a lot to figure out what was
> going on. Being incredibly lazy, the first patch in the series
> actually abstracts out most of the scdaemon handling code so it can be
> re-used for the tpm2daemon. Patch 2 actually does the shift and patch
> 3 tidies up the linking. I'm sure I got a lot wrong, but it's a start.
> There's obviously a large amount of documentation that would need
> writing as well.
>
> James
>
> ---
>
> James Bottomley (3):
> agent: separate out daemon handling infrastructure for reuse
> tpm2: handle via a new assuan connected daemon
> tpm2: Make libtss directly linked
>
> Makefile.am | 7 +-
> agent/Makefile.am | 5 +-
> agent/agent.h | 46 +-
> agent/call-daemon.c | 570 +++++++++++++++++++
> agent/call-scd.c | 543 +-----------------
> agent/call-tpm2d.c | 272 +++++++++
> agent/command-ssh.c | 10 +-
> agent/command.c | 4 +-
> agent/divert-tpm2.c | 62 +-
> agent/gpg-agent.c | 22 +-
> common/homedir.c | 7 +
> common/util.h | 1 +
> configure.ac | 12 +-
> tools/gpgconf-comp.c | 2 +
> tpm2d/Makefile.am | 18 +
> tpm2d/command.c | 574 +++++++++++++++++++
> {agent => tpm2d}/tpm2.c | 239 +++-----
> {agent => tpm2d}/tpm2.h | 15 +-
> tpm2d/tpm2daemon.c | 1432 +++++++++++++++++++++++++++++++++++++++++++++++
> tpm2d/tpm2daemon.h | 130 +++++
> 20 files changed, 3218 insertions(+), 753 deletions(-)
> create mode 100644 agent/call-daemon.c
> create mode 100644 agent/call-tpm2d.c
> create mode 100644 tpm2d/Makefile.am
> create mode 100644 tpm2d/command.c
> rename {agent => tpm2d}/tpm2.c (79%)
> rename {agent => tpm2d}/tpm2.h (64%)
> create mode 100644 tpm2d/tpm2daemon.c
> create mode 100644 tpm2d/tpm2daemon.h
>

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

It turns out that this code works in my test environment where I
specify the tpm2daemon location but it fails on a production build for
openSUSE where they try to reconfigure the default daemon locations
(largely because the config code doesn't exist in my current copy).

The below is the patch I needed to plumb it in properly and get the
openSUSE gpg2 build working.

James

---

From 41b2c2df461cd54813ba951a4fe7a97bdce29e74 Mon Sep 17 00:00:00 2001
From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Mon, 30 Jul 2018 08:39:26 -0700
Subject: [PATCH] Fix tpm2 daemon configs and gpgconf

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
agent/call-daemon.c | 9 ++++++++-
am/cmacros.am | 3 +++
configure.ac | 10 ++++++++++
tools/gpgconf-comp.c | 17 +++++++++++++++--
4 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/agent/call-daemon.c b/agent/call-daemon.c
index 8b5bae955..472ab0635 100644
--- a/agent/call-daemon.c
+++ b/agent/call-daemon.c
@@ -239,7 +239,14 @@ daemon_start (enum daemon_type type, ctrl_t ctrl)
}

if (!opt.daemon_program[type] || !*opt.daemon_program[type])
- opt.daemon_program[type] = gnupg_module_name (GNUPG_MODULE_NAME_SCDAEMON);
+ {
+ int map_types[] = {
+ [DAEMON_SCD] = GNUPG_MODULE_NAME_SCDAEMON,
+ [DAEMON_TPM2D] = GNUPG_MODULE_NAME_TPM2DAEMON,
+ };
+
+ opt.daemon_program[type] = gnupg_module_name (map_types[type]);
+ }
if ( !(pgmname = strrchr (opt.daemon_program[type], '/')))
pgmname = opt.daemon_program[type];
else
diff --git a/am/cmacros.am b/am/cmacros.am
index 9610e4efe..e71bc4e9d 100644
--- a/am/cmacros.am
+++ b/am/cmacros.am
@@ -44,6 +44,9 @@ endif
if GNUPG_SCDAEMON_PGM
AM_CPPFLAGS += -DGNUPG_DEFAULT_SCDAEMON="\"@GNUPG_SCDAEMON_PGM@\""
endif
+if GNUPG_TPM2DAEMON_PGM
+AM_CPPFLAGS += -DGNUPG_DEFAULT_TPM2DAEMON="\"@GNUPG_TPM2DAEMON_PGM@\""
+endif
if GNUPG_DIRMNGR_PGM
AM_CPPFLAGS += -DGNUPG_DEFAULT_DIRMNGR="\"@GNUPG_DIRMNGR_PGM@\""
endif
diff --git a/configure.ac b/configure.ac
index ce3145a36..1fe5ba33c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -181,6 +181,15 @@ show_gnupg_scdaemon_pgm="(default)"
test -n "$GNUPG_SCDAEMON_PGM" && show_gnupg_scdaemon_pgm="$GNUPG_SCDAEMON_PGM"


+AC_ARG_WITH(tpm2daemon-pgm,
+ [ --with-tpm2daemon-pgm=PATH Use PATH as the default for the tpm2daemon)],
+ GNUPG_TPM2DAEMON_PGM="$withval", GNUPG_TPM2DAEMON_PGM="" )
+AC_SUBST(GNUPG_TPM2DAEMON_PGM)
+AM_CONDITIONAL(GNUPG_TPM2DAEMON_PGM, test -n "$GNUPG_TPM2DAEMON_PGM")
+show_gnupg_tpm2daemon_pgm="(default)"
+test -n "$GNUPG_TPM2DAEMON_PGM" && show_gnupg_tpm2daemon_pgm="$GNUPG_TPM2DAEMON_PGM"
+
+
AC_ARG_WITH(dirmngr-pgm,
[ --with-dirmngr-pgm=PATH Use PATH as the default for the dirmngr)],
GNUPG_DIRMNGR_PGM="$withval", GNUPG_DIRMNGR_PGM="" )
@@ -2071,6 +2080,7 @@ echo "
Default agent: $show_gnupg_agent_pgm
Default pinentry: $show_gnupg_pinentry_pgm
Default scdaemon: $show_gnupg_scdaemon_pgm
+ Default tpm2daemon: $show_gnupg_tpm2daemon_pgm
Default dirmngr: $show_gnupg_dirmngr_pgm

Dirmngr auto start: $dirmngr_auto_start
diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c
index 799154c83..d3f52dd68 100644
--- a/tools/gpgconf-comp.c
+++ b/tools/gpgconf-comp.c
@@ -134,6 +134,9 @@ typedef enum
/* The GnuPG SCDaemon. */
GC_BACKEND_SCDAEMON,

+ /* The TPM2 daemon */
+ GC_BACKEND_TPM2DAEMON,
+
/* The GnuPG directory manager. */
GC_BACKEND_DIRMNGR,

@@ -188,10 +191,10 @@ static const struct
NULL, GPGCONF_NAME "-" GPGSM_NAME ".conf" },
{ GPG_AGENT_DISP_NAME, GPG_AGENT_NAME, GNUPG_MODULE_NAME_AGENT,
gpg_agent_runtime_change, GPGCONF_NAME"-" GPG_AGENT_NAME ".conf" },
- { TPM2DAEMON_DISP_NAME, TPM2DAEMON_NAME, GNUPG_MODULE_NAME_TPM2DAEMON,
- NULL, GPGCONF_NAME"-" TPM2DAEMON_NAME ".conf" },
{ SCDAEMON_DISP_NAME, SCDAEMON_NAME, GNUPG_MODULE_NAME_SCDAEMON,
scdaemon_runtime_change, GPGCONF_NAME"-" SCDAEMON_NAME ".conf" },
+ { TPM2DAEMON_DISP_NAME, TPM2DAEMON_NAME, GNUPG_MODULE_NAME_TPM2DAEMON,
+ NULL, GPGCONF_NAME"-" TPM2DAEMON_NAME ".conf" },
{ DIRMNGR_DISP_NAME, DIRMNGR_NAME, GNUPG_MODULE_NAME_DIRMNGR,
dirmngr_runtime_change, GPGCONF_NAME "-" DIRMNGR_NAME ".conf" },
{ DIRMNGR_DISP_NAME " LDAP Server List", NULL, 0,
@@ -602,6 +605,15 @@ static gc_option_t gc_options_gpg_agent[] =
};
#endif /*BUILD_WITH_AGENT*/

+static gc_option_t gc_options_tpm2daemon[] =
+ {
+ /* The configuration file to which we write the changes. */
+ { GPGCONF_NAME"-"TPM2DAEMON_NAME".conf",
+ GC_OPT_FLAG_NONE, GC_LEVEL_INTERNAL,
+ NULL, NULL, GC_ARG_TYPE_FILENAME, GC_BACKEND_TPM2DAEMON },
+
+ GC_OPTION_NULL,
+ };

#ifndef BUILD_WITH_SCDAEMON
#define gc_options_scdaemon NULL
@@ -1118,6 +1130,7 @@ static const struct
{ "gpg", "gnupg", N_("OpenPGP"), gc_options_gpg },
{ "gpg-agent","gnupg", N_("Private Keys"), gc_options_gpg_agent },
{ "scdaemon", "gnupg", N_("Smartcards"), gc_options_scdaemon },
+ { "tpm2daemon", "gnupg", N_("TPM2"), gc_options_tpm2daemon },
{ "gpgsm", "gnupg", N_("S/MIME"), gc_options_gpgsm },
{ "dirmngr", "gnupg", N_("Network"), gc_options_dirmngr },
{ "pinentry", "gnupg", N_("Passphrase Entry"), gc_options_pinentry }
--
2.13.7


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Mon, 2018-07-30 at 21:44 +0200, Wiktor Kwapisiewicz via Gnupg-devel
wrote:
> Hi James,
>
> I'm very interested in your TPM patches (as a user).
>
> Could I ask you some questions on how does it work?
>
> I would like to have keys wrapped by TPM in such a way that the
> change  in system configuration would render the key useless. As far
> as I've  seen it's possible to do that by utilizing Platform
> Configuration Registers (PCRs). Would keys created by your TPM code
> have this property?

The current gpg2 code just does secure handling for the key, meaning it
ties the key to being only released on a single platform, so it
currently doesn't do a policy based on the PCR values. That said,
there's no reason why it couldn't and if you look at the
openssl_tpm2_engine code, it does precisely do this (you can specify a
PCR and password policy for the key):

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

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.

James


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

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

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

Have a nice day.

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

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


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi James,

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

Agreed, in my setup that I'm... setting up, I'll be using GnuPG to
decrypt the keyfile (that's on an unencrypted disk or initramfs) using
OpenPGP smartcard. All of this will happen very early in the boot
process, that requires some GnuPG binaries to be available by then.

The idea is not new and there are already projects that implement that:

https://github.com/xdbob/mkinitcpio-gpg-encrypt#configuration-process

The TPM could give me additional advantage of knowing the system state
did not change and although there are projects for that too...

https://github.com/electrickite/luks-tpm

...I'd be very happy if I could have the same key wrapped by TPM and on
a smartcard (for recovery purposes).

But that's another issue. TPM keys, as an alternative for
always-connected smartcard, are very useful on their own in my opinion.

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi James,

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

Agreed, in my setup that I'm... setting up, I'll be using GnuPG to
decrypt the keyfile (that's on an unencrypted disk or initramfs) using
OpenPGP smartcard. All of this will happen very early in the boot
process, that requires some GnuPG binaries to be available by then.

The idea is not new and there are already projects that implement that:

https://github.com/xdbob/mkinitcpio-gpg-encrypt#configuration-process

The TPM could give me additional advantage of knowing the system state
did not change and although there are projects for that too...

https://github.com/electrickite/luks-tpm

...I'd be very happy if I could have the same key wrapped by TPM and on
a smartcard (for recovery purposes).

But that's another issue. TPM keys, as an alternative for
always-connected smartcard, are very useful on their own in my opinion.

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel