Solving Bigger Problems with the TPM 2.0
Throughout this book, we have described examples of how you can use particular TPM commands in programs. This chapter looks at how some of those commands can be combined to create programs that use multiple features of the TPM. These ideas couldn't be implemented easily with TPM 1.2, but TPM 2.0 has added features that make it easy to solve these problems.
Remote Provisioning of PCs with IDevIDs Using the EK
Each client's TPM comes with an endorsement key (EK). This is a storage key, and it comes with a certificate indicating that it's from an authentic TPM. An enterprise may also have a list of EK certificates, corresponding to client machines it has bought. Enterprises would like to have a unique signing key on each system (usually called a device identity [IDevID]), which can be used to initiate a VPN connection. But, being a storage key, the EK can't be used as a VPN key. TPM 1.2 had a complicated protocol that could be used to create a certificate for a signing key created in the TPM, which proved that the key was generated in a TPM. However, no commercially available CAs followed that protocol.
TPM 2.0 has an EK that is slightly more robust than the 1.2 EK. A 2.0 EK can be used to wrap other keys. In particular, it's possible for an enterprise to create a restricted signing key and encrypt it such in a way that only the TPM that has that EK can import it. This is similar to (although more secure than) the “send a PKCS #12 file” technique used today to provision keys. Using this approach, PKCS #12 files that contain the private key are created and sent to clients. Clients are then given a password through a side channel, which they use to decrypt the PK12 file; they then store the private portion in a (hopefully) secure place. This technique exposes the private key at some point and is only as secure as the password. The TPM protocols are much more secure.
There are basically three ways you can name the signing key that is being created as an IDevID:
• Technique 1: Create the IDevID in a server-side TPM or TPM emulator, and use the standard CA to create a certificate for it. Then duplicate this key so that it can be imported into a system that has the client's EK resident. This is called duplicating the key so that its new parent is the EK.
• Technique 2: Create the IDevID and certify it. Wrap it up so that it looks like a duplicated TPM key and can be imported into the client's EK.
• Technique 3: Create the IDevID and certify it. Import it locally into a TPM or TPM emulator, and then duplicate it to have its new parent be the client TPM's EK.
These three techniques are implemented slightly differently, as discussed in the following sections.