Lots of Applications need secrets

Usually the private RSA/ECC keys for X509 certificates

Big use cases are VPN endpoints, Encrypted Disks, SSH and GPG

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

or all supposedly secure traffic can be eavesdropped

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

Most of which can only carry one key

TPM 2.0 features RSA and ECC for PK TPM 1.2 is RSA2048 only

RSA/ECC is a public/private key model based in elementary ring theory

∀n|m   (n^d)^e = n mod m

d = e^-1 mod φ(m)

public key is (e,m) private key is (d,m)

signatures and authentication challenges are encrypted with the private key

Current industry practice recommends 2048 bits for RSA or 224 for ECC

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

Actual TPM Functions:

1. Shielded Key Handling

2. Measurement

3. Data Sealing

4. Attestation

Only talking about shielded key handling today.

TPM 1.2 generates an internal Storage Root Key (SRK) and publishes the public part

TPM 2.0 generates an internal storage seed (SPS)

TPM 2.0 goes from seed to key via key derivation function

Algorithm Agility requires this

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

jejb@jarvis:~> time tsscreateprimary
real 0m43.439s
user 0m0.097s
sys 0m0.024s

ECC much faster

SRK/SPS changes if the TPM is reinitialised

Keys to be inserted into the TPM are encrypted (wrapped) to the public root key

Meaning only the TPM can decrypt them

TPM 1.2 has reasonable temporary key storage => keys can be loaded and used

TPM 2.0 usually only loads 3 keys before running out of space => storage must be managed

Means for TPM 2.0 keys must always be loaded, used and unloaded.

Also means that TPM 2.0 cannot be used without a "Resource Manager"

Essentially TPM "Virtualization"

When you send a command, all your resident keys are loaded

When your command completes, all your resident keys are saved and the tpm is flushed

=> every connection via the resource manager seems to have their own TPM device

Fortunately from kernel 4.12 Linux contains a kernel resident TPM 2.0 resource manager

Now that we have in-kernel resource manager, applications can connect directly to the TPM (no tcsd)

Direct connection done via resource manager device being crw-rw-rw

Direct connection TSS is here
https://sourceforge.net/projects/ibmtpm20tss/

TPM will generate a signature for a loaded key when presented with correct authority

A wrapped key contains the authority (20 byte number)

Parent (ultimate root is the SRK or KDF(SPS))

Clearing the TPM regenerates the SRK/SPS => all prior keys are lost.

Because they cannot now be loaded into any TPM.

Tools exist for openssl and gnome-keyring

openssl via tpm2 engine
https://build.opensuse.org/package/show
/home:jejb1:Tumbleweed/openssl_tpm_engine

Adds capability of handling TPM keys to openssl

Gnome keyring
https://build.opensuse.org/package/show
/home:jejb1:Tumbleweed:gnome-3-20/gnome-keyring

Makes gnome keyring understand TPM resident ssh keys

Now only need to trust the TPM

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

RSA 2048 is usually the keys we use today

TPM Shielded Key Handling is now built into the SSL libraries

Means that all SSL based applications “just work” without modification

Key is tied to a single physical TPM

Keys all need to be regenerated when you change laptops

TPM 2.0 requires the in-kernel resource manager

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

Trousers is buggy; central daemon is a problem

TSS2.0 has no central daemon; each operation connects directly to kernel resource manager.

Model is not TCG standard (yet)