Home GnuPG
Diffusion GnuPG 1a4a4a8f5fa5

agent: plumb in TPM handling

Unpublished Commit · Learn More

Not On Permanent Ref: This commit is not an ancestor of any permanent ref.


agent: plumb in TPM handling

* agent/divert-tpm2.c: New.
* Makefile.am (gpg_agent_SOURCES): Add it.
* agent/command.c (do_one_keyinfo): Fake serialno for TPM.
(cmd_keytotpm): New.
(register_commands): Register KEYTOTPM command.
* agent/pkdecrypt.c (agent_pkdecrypt): Divert to TPM.
* agent/pksign.c (agent_pksign_do): Divert to TPM.

This code installs diversions for pksign and pkdecrypt to do the
operations via the TPM if a TPM shadowed key is present. It also adds
an extra assuan command KEYTOTPM which moves an existing private key
to a TPM shadowed key.

The way TPM shadowing works is that the public and private key parts
are fed in to the TPM command TPM2_Import. The output of this command
is a TPM specific public and private key data where the private key
data is symmetrically encrypted using a TPM internal key. If this
physical TPM is ever lost or cleared, that TPM internal key will
likewise be lost and nothing will ever be able to read the private
key. Once the import is done, the shadow information for the key is
updated to be a three part list consisting of the parent key (hard
coded to 81000001 which is the Microsoft preferred RSA incarnation of
the storage seed) and the public and private TPM data blobs.

Now when a TPM shadowed key is used, the data blobs must be loaded
into the TPM with TPM2_Load before any operation can be performed.

  • Added ChangeLog entries
  • Signed-off-by: Werner Koch <wk@gnupg.org>


James Bottomley <James.Bottomley@HansenPartnership.com>Authored on Mar 5 2018, 8:15 PM
wernerCommitted on Mar 9 2018, 10:01 AM
rG144cceec7ca1: agent: add tpm specific functions

Event Timeline

werner committed rG1a4a4a8f5fa5: agent: plumb in TPM handling (authored by James Bottomley <James.Bottomley@HansenPartnership.com>).Mar 9 2018, 10:01 AM

IMO the parent key should not be hard coded to 81000001 (Microsoft preferred RSA incarnation of the storage seed), as this prevents the use other configurations (although deployed TPM2's and fTPM2's all seem to carry this storage seed).

Furthermore this appears to be a politically awkward design decision, as it cements the fact that trust is originating in cryptographic keys (rsp. their "seeds" from which they are calculated) coming from Microsoft, when using a TPM2.

Hence please reconsider this design.