Secure key handling using the TPM

Trusted Computing has not had the best reputation over the years — Richard Stallman dubbing it "Treacherous Computing" probably hasn't helped — though those fears of taking away users' control of their computers have not proven to be founded, at least yet. But the Trusted Platform Module, or TPM, inside your computer can do more than just potentially enable lockdown. In our second report from Kernel Recipes 2018, we look at a talk from James Bottomley about how the TPM works, how to talk to it, and how he's using it to improve his key handling.

Everyone wants to protect their secrets and, in a modern cryptographic context, this means protecting private keys. In the most common use of asymmetric cryptography, private keys are used to prove identity online, so control of a private key means control of that online identity. How damaging this can be depends on how much trust is placed in a particular key: in some cases those keys are used to sign contracts, in which case someone who absconds with a private key can impersonate someone on legal documents — this is bad.

The usual solution to this is hardware security modules, nearly all of which are USB dongles or smart cards accessed via USB. Bottomley sees the problem with these as capacity: most USB devices can only cope with one or two key pairs, and smart cards tend to only hold three. His poster child in this regard is Ted Ts'o, whose physical keyring apparently has about eleven YubiKeys on it. Bottomley's laptop has two VPN keys, four SSH keys, three GPG keys (because of the way he uses subkeys) and about three other keys. Twelve keys is beyond the capacity of any USB device that he knows of.

But nearly all modern general-purpose computing hardware has a TPM in it; laptops have had them for over ten years. The only modern computers that don't have one, said Bottomley, are Apple devices "and nobody here would use one of those". The TPM is a small integrated circuit on the motherboard that the CPU can talk to, which can perform cryptographic operations. The advantage of using the TPM for key management is that the TPM can scale to thousands of keys, though the mechanism by which it does this is, as we shall see, interesting. Most of the TPMs currently in the field are TPM 1.2 compliant. Thanks largely to Microsoft, he added, TPM 2.0 is the up-and-coming standard; some modern Dell laptops are already shipping with TPM 2.0, even though the standard isn't actually finalized yet.

The main problem with TPMs under Linux is that accessing them has been a "horrifically bad" experience; anyone who tried to use them has ended up never wanting to deal with them again. The mandated model for dealing with TPMs is the Trusted Computing Group (TCG) Software Stack (TSS), which is "pretty complicated". The Linux implementation of TSS 1.2 is TrouSerS; it was completed in 2012, and has "bit-rotted naturally since then", but remains the only way to use TPM 1.2 under Linux. The architecture involves a TrouSerS library that is linked to any relevant application, which talks to a user-space daemon (tcsd), which in turn talks to the TPM through a kernel driver. One of the many issues Bottomley has with this is that the daemon is a natural point of attack for anyone looking to run off with TPM secrets. For his day job, which is running containers in the cloud, the design is completely unacceptable: cloud tenants will not tolerate "anything daft in security terms", and a single daemon through which the secrets of all the system's tenants pass is certainly that.

The added functionality in TPM 2.0 means we can do much better than the TCG model. For many people in the industry, departure from the TCG model is heresy, but fortunately, said Bottomley, there are large free-wheeling sections of the industry (i.e. Linux people) who are happy to use any programming model that actually works. As with 1.2, the TCG is writing a software stack, but it's naturally even more complex than 1.2's TSS. IBM has had a fully-functional TPM 2.0 stack since May 2015 and Intel is writing its own. As of 4.12, the Linux kernel has a TPM 2.0 resource manager.

Under TPM 1.2, the asymmetric encryption algorithm was 2048-bit RSA (RSA2048), which is still good enough today. The hashing function was SHA-1, which isn't good enough any more. To avoid falling into the trap of mandating an algorithm that ages badly, TPM 2.0 features "algorithm agility", whereby it can support multiple hashing functions and encryption algorithms, and will use whichever the user requests. In practice, this usually means that in addition to SHA-1 and RSA2048, SHA-256 and a few elliptic curves are supported, and this is good enough for another few years. When SHA-256 starts to show its age, TPM 2 can support a move to, for example, the SHA-3 family of algorithms.

There are problems with elliptic curves, however; most TPMs support only BN-256 and NIST P-256, but nobody uses the former, and the NSA had a hand in the creation of the latter, so nobody trusts it. Attempts to get more curves added tend to run into borders; some nations don't like crypto being exported, and others will only allow it to be imported if it's crypto they like. Curve25519 has not apparently even been on the TCG's radar, although Bottomley said there's now a request into the TCG to approve it, and since it's already been published worldwide, there is some chance that it may be generally approved as a standard addition to the TPM.

The TPM's functions include shielded key handling, things related to trusted operating systems including measurement and attestation, and data sealing; Bottomley focused on the key-handling capabilities. The TPM organizes keys in hierarchies with a well-known key at the top; this is a key, generated by the TPM, the private half of which is known only to the TPM itself, and the public half of which it will give to anyone who asks. This enables the secure exchange of secrets with the TPM. If the TPM is reinitialized, the random internal seed from which the TPM derives its well-known key is regenerated, and anything the TPM has ever encrypted becomes unusable. This is important in terms of decommissioning devices; reinitializing the TPM is enough to render it, and anything it has ever encrypted, harmless.

Bottomley said that the TPM is capable of scaling to thousands of keys. While that's not exactly false, the TPM accomplishes this by not storing any of your keys at all. The TPM has very little memory and can only hold around three transient keys at any one time. Key handling is initially a matter of feeding a secret key to the TPM, which encrypts it into a "key blob" that only the TPM can read, which the TPM then gives back to you. Key storage is your responsibility, but with the safety net that these key blobs are meaningless to any TPM save yours, so they are not the difficult-to-store dynamite that an unprotected private key is. You can safely pass the blob in plaintext to the TPM any time you want the TPM to perform a key operation. The TPM will not decrypt a blob and give you the private key inside it; it will only perform operations with such a key. This also means that if you want to make backups of a private key, it is quite important to do it before you feed it to the TPM. If you ever get a new system, migrating your identity to it will not be possible unless you have these backups stored safely.

Prior to about March 2018, it was generally thought the the physical closeness of the CPU and the TPM made the channel between them effectively secure, at least without physical access to the hardware. Unfortunately, this has turned out not to be true, and a software tool called TPM Genie, which can attack this channel, was released. TCG's response was to develop the Enhanced System API (ESAPI), which allows for encrypted parameters in communication with the TPM (and for those of a suspicious mindset, it also allows the TPM to prove it's really a TPM).

ESAPI has its wrinkles: encrypted commands support only one encrypted argument, which must be the first, but some secret-handling commands, such as the one to import a private key in the first place, pass that key as the second argument, which was apparently overlooked by the TCG. But these problems were solved (in that specific case, by modifying the import command so that a randomly generated single-use symmetric key was used to encrypt the private key, and passed in the secure first field so that the TPM can decrypt the private key).

Having hardware support is all very well, but if user space can't easily come to grips with it, it's useless. Support in user space has come by recognizing that existing cryptosystems tend to use passphrase-protected (i.e. passphrase-encrypted) key files. With fairly small modifications, these can be passphrase-protected key blobs; possession of the passphrase allowing you to enable the OS to feed the blob to the TPM. This turns key-file-based systems into full two-factor authentication: if your laptop is stolen, each blob is passphrase-encrypted and cannot be fed to the TPM without that passphrase, and if your passphrase is compromised it is of no use to an attacker without your physical laptop.

OpenSSL now has a TPM 2.0 engine, though there is a problem in that many projects that use OpenSSL don't load the engine part of the API, thus cannot use engine-based keys. However, the fix is usually just a couple of lines of extra code in any program that uses OpenSSL, to ensure that the engine is loaded when OpenSSL is initialized. OpenVPN, for example, has been converted this way and can use the TPM. OpenSSH has been converted, though the agent requires additional patching. GnuPG uses libgcrypt, not OpenSSL, but after discussion at last year's Kernel Recipes, Bottomley has written a TPM module for GnuPG, which he demonstrated as part of the talk. Sbsigntools and gnome-keyring also now have TPM support. Some use cases remain unsupported: the TPM is a slow, low-power device that cannot handle hundreds of key operations per second, so it will likely remain unusable for things like full-disk encryption.

In response to an audience question about audit, Bottomley accepted that TPM 1.2 was poor in this regard. This allowed a number of issues to slip through the net, such as weak prime generation for Infineon TPMs. For TPM 2.0, the TCG has upped its game; there is a certification program involving a standardized test suite to check correct operation. There is also a reference implementation, written by Microsoft, but available under a BSD license, though apparently it is not widely used by TPM vendors.

The days of practical username/password authentication have already gone. The more we can support two-factor authentication, the more secure a future we can reasonably expect. The TPM is by no means the only way of doing this — I shall continue to use my YubiKey over NFC, and my GPG smartcard — but as TPM 2.0 hardware becomes more widespread it's an increasingly practical way of doing it, and it gets utility from a part of your computer that until now may have largely been looked on with disdain.

[We would like to thank LWN's travel sponsor, The Linux Foundation, for assistance with travel funding for Kernel Recipes.]