Everybody needs help protecting secrets.

Usually the private RSA/ECC keys for identity

if these keys get stolen, the user can be impersonated.

Current state of the art is expensive (and often proprietary) Hardware Security Module (USB Key)

Most of which can only carry one key

Using a TPM instead of a dongle scales to thousands of keys.

A TPM is a separate processing module with shielded memory

They have been ubiquitous for a while now

But they have a horrifically bad programming experience

The mandated model is called the TCG (Trusted Computing Group) Secure Stack (TSS)

Linux TSS 1.2 Implementation is Trousers

For TPM 2.0 we can do much better ...

Actual TPM Functions:

1. Shielded Key Handling

2. Measurement

3. Data Sealing

4. Attestation

Only talking about shielded key handling today.

Keys in the TPM are "stored" in hierarchies with a well known key at the top.

Asymmetric Encryption keys (ECC/RSA) belong to the Storage Hierarchy

TPM 2.0 features algorithm agility (TPM 1.2 was sha1/rsa2048)

TPM 2.0 generates an internal seed for the storage root key.

TPM 2.0 goes from seed to key via key derivation function (KDF)

Input is just a random number (the seed) but output can be a key pair for any algorithm.

The same seed always generates the same public/private key pair

For RSA, KDF finds primes and can take a long (long) time

~> time tsscreateprimary -hi o -rsa -st
real 0m43.439s
user 0m0.097s
sys 0m0.024s

Elliptic Curve much faster

The storage seed changes if the TPM is reinitialised

Keys to be inserted into the TPM are encrypted based on a known public key (usually the parent).

Meaning only the TPM can decrypt them

Once a key is transferred to TPM form, it can only be understood by the specific TPM it was transferred to

And it can never be extracted

Like TPM 1.2, the TCG is writing a TSS for TPM 2.0

But it's still not complete

Note: A resource manager is now requried because TPM 2.0 has space for only 3 transient objects

As of Linux 4.12 the kernel has a TPM 2.0 resource manager

Intel is building a TSS to the TCG spec
github.com/intel/tpm2-tss

ESAPI required for encrypted sessions but only added in March 2018.

IBM has built a fully functional and complete TSS (since May 2015)
sourceforge.net/projects/ibmtpm20tss

But based on the TPM2 command manuals not on the API specs

Makes direct connection to the in-kernel resource manager (no daemons)

Until merger of ESAPI IBM TSS was only choice for secure crypto.

To build a secure crypto system you only need 5 (five) TPM2 commands

Both commands return two structures

A public key, which also has the visible parameters

A private key data blob which is only readable by the TPM

Public key is "bound" to private data blob by hash

Both public and private parts must be presented when using the key

TPM 2.0 keys are demand loaded, meaning they're not resident in the TPM (unlike USB keys)

The user is responsible for managing the public/private data blobs

TPM 2.0 can only load 3 keys at once => need Resource Manager (kernel 4.12)

Lots of sensitive information in the commands

Cannot be assured of a secure channel to the TPM

So must secure all data in transit (authority and private keys)

This is done by the missing ESAPI

Each session can be either simple, HMAC (with optional Parameter Decryption, Response Encryption) or audit.

And each command may have up to three sessions

A TPM bus snooping attack called TPM Genie was recently published

Meaning all TPM commands must be cryptographically protected to prevent snooping and tampering

Including those issued by the kernel itself

Makes TPM_RS_PW useless (and dangerous: never use).

Parameter and Response encryption require encrypted salt.

meaning there must be a known salt key to get the public parameters from

Recently published TCG Provisioning guidance now says must be RSA storage seed KDF at 8100001

Only the first parameter is encrypted

Problem with some commands if secrets aren't first parameter

How to hide all this complexity from the average user?

Existing crypto systems mostly use password protected key files

These key files could contain TPM key blobs with password as key authority

Then, as long as the cryptosystem recognises the TPM key, everything would "just work"

Only requirement is conversion of an existing key format to the TPM one

Plus some discipline around handling key backup

Now only need to trust the TPM

Key cannot ever be stolen (even if the authority can be misused)

Apart from key conversion, no changes to workflow

Key is tied to a single physical TPM Which is part of your laptop

Keys all need to be re-converted when you change laptops

TPM 2.0 requires the in-kernel resource manager (kernel 4.12+)

TPM is slow => can't process hundreds of key ops per second

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

comes with create_tpm2_key utility for key conversion

Elliptic Curve Issues

TPM enabling works just fine

But TPMs don't have generic EC handling

So curve must be known to the TPM

Currently mandated curves are BN-256 and NIST P-256

25519 not even on the TCG radar

Problem: OpenSSL uses separate API to load engine keys ENGINE_load_private_key()

However, usually only a couple of extra lines in most openssl consumer code

openvpn: converted to use engine keys

openssh: converted to use engine keys but additional patching required for agent

gnupg: not openssl based code, so wrote new tpm module

gnupg: key conversion via edit-key command keytotpm