TPM Enabling the Crypto Ecosystem
For Enhanced Security
Open Source Advocate
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
3. Data Sealing
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
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
ESAPI required for encrypted sessions but only added in March 2018.
IBM has built a fully functional and complete TSS (since May 2015)
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
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