Solving the TPM key provisioning problem with Fortanix Data Security Manager

For the last decade, smart devices have become increasingly integrated into our society. But as our reliance on these devices grows, so does the probability and potential impact of security breaches.

In a move towards improving platform security, smart device manufacturers have started integrating Trusted Platform Modules (TPM) into their products. These modules are small, low-cost crypto processors that, amongst other security features, provide secure storage of cryptographic keys.

TPMs operate in isolation from the main CPU and can only be accessed via a standardized, safe API, set out by the Trusted Computing Group (TCG). Whenever a cryptographic operation is to be performed with a TPM-resident key, the main CPU asks the TPM via the API to perform that operation and return the result.

Since the key never leaves the TPM, attackers cannot steal it, even if they have bypassed every operating system protection measure and have gained full control over the main CPU.

An interesting use case for the TPM’s key vault is for storing a device identity key, a key that the device can use to authenticate itself to a remote service. Consider, for instance, a typical connected device such as a smart home controller that, in order to deliver its full set of smart features, must connect over the internet to a backend server, managed by its manufacturer.

Since the services provided by this backend represent an added value for the customer in comparison to competing products, the manufacturer will want to ensure that only its own genuine devices have access to it.

Furthermore, since personal data of the customer might be associated with each device in the backend, the manufacturer must ensure that one genuine device cannot masquerade as another.

Both problems can be solved by provisioning the TPMs of genuine devices with a device identity key, certified by a Certificate Authority (CA) under the control of the manufacturer. Each device can then use its own personal identity key to set up a mutually authenticated TLS connection to the backend, once the device is out in the field.

This however raises the question of how the identity key and its certificate can be securely installed onto the TPM. The identity CA will need to ensure that it only creates certificates for genuine devices, but how can it identify a genuine device?

Even when the device is manufactured in-house and we want to provision the TPM at manufacturing time, it would be insecure to trust the unencrypted network connection between the TPM and the CA, let alone when hardware manufacturing is outsourced to a third party or if the device needs to be provisioned when it is already out in the field.

Fortunately, the TCG has designed the TPM spec to accommodate this scenario. Every TPM ships from the factory with a random Endorsement Primary Seed (EPS). From this seed, the TPM can generate an asymmetric Endorsement Key (EK) pair.

Since the EPS is random, the EK will be unique for every TPM. Additionally, the TPM manufacturer will provide, for each individual EK, a certificate signed by one of the manufacturer’s TPM Root CAs (or a sub-CA thereof). This certificate is known as the Endorsement Key Certificate (EKC) and can be used to uniquely identify the TPM.

The most straightforward approach would now be to directly use the EK as the device identity key, since it is unique per TPM and we have a chain of trust from this key up to the TPM Root CA, via the EKC.

Unfortunately, this approach won’t work, because, due to privacy concerns, the TCG has specified that the default EK is a restricted decryption key [1] instead of a signing key, which makes it impossible to use this key for setting up a TLS connection [2].

The EK can still help us achieve our goal, by using it to bootstrap a process called credential activation, to provision the TPM with a fresh identity key with signing capabilities and get that key certified by the identity CA.

The following three components will play a key role in the credential activation process:

1. The TPM inside the device to provision.
2. A provisioning script running on the device itself.
3. A Fortanix Data Security Manager (DSM) account, running the Fortanix TPM Key Provisioning Plugin. This plugin will take on the role of identity CA.

During device setup, the device will start executing the provisioning script, which will orchestrate an exchange of data between the TPM and DSM, leading to the installation of a unique identity key into the TPM and a certificate for that key (issued by DSM) onto the device. The provisioning script has six distinct steps (1-6).

Step 1: Create the necessary TPM key material by instructing the TPM to (re-) create the EK from its endorsement primary seed and create a new RSA key pair, persisted to the TPM’s NVRAM. This key pair will become the device’s identity key (IK).

Step 2: Retrieve the so-called, public area of the IK, the public area of the EK, and the EKC from the TPM. Note that the public area of a TPM key pair contains, apart from the public key, all metadata about the key pair stored by the TPM and hence completely characterizes the key pair.

Step 3: Use the public area of the IK and identifying information about the device (e.g., its serial number) to generate a Certificate Signing Request (CSR) for the IK. The script instructs the TPM to generate the signature on the CSR, using the IK.

Step 4: Pass the CSR and the three pieces of information retrieved in step 2 as parameters to the getChallenge endpoint of the Fortanix Key Provisioning Plugin. The plugin will return a credential blob in response to this call, consisting of an EK-encrypted ticket and some metadata that cryptographically links that encrypted ticket to the public area of the IK.

The TPM takes the credential as input in its credential activation operation, in which the TPM extracts the plaintext ticket from the credential, by decrypting it using the private part of the EK. Since only our specific TPM possesses the private part of the EK, only that TPM can activate the credential.

Furthermore, the TPM is programmed to only complete the activation operation in case the metadata inside the credential identifies a key pair stored inside the TPM’s internal key vault. These two properties ensure that the plaintext ticket can only ever be retrieved when the TPM identified by the EK contains the IK.

Step 5: Instruct the TPM to activate the received credential, thereby retrieving the plaintext ticket.

Step 6: Call the getCertificate endpoint of the Fortanix Key Provisioning Plugin, passing all of the parameters sent to the getChallenge endpoint in step 3 as input, in addition to the plaintext ticket. The plugin will validate the ticket, sign the CSR and return the resulting IK certificate in response.

The device now has a unique identity key pair —the private part of which has never left the TPM— and a certificate for that key pair, signed by the identity CA. This key pair and certificate can be used to set up a mutually authenticated TLS connection from the device to the manufacturer’s backend, which is exactly what we set out to achieve.

When the Fortanix TPM Key Provisioning Plugin receives a getChallenge call from the provisioning script containing the parameters described in step 4 above, it performs a number of validations to ensure it only issues tickets for genuine devices.

Firstly, the plugin checks the signature on the received CSR and verifies that the public key inside the CSR matches the key in the public area of the IK.

Secondly, the plugin validates that the key inside the EK public area belongs to a genuine device. There are several ways in which the plugin can perform this validation step, for instance by referencing the key against a set of trusted EKCs uploaded by the device manufacturer, obtained from the specific TPMs built into its devices.

Finally, the plugin also inspects the metadata inside the public area of the IK, to verify that the IK has acceptable security properties for a device identity key.

Since the plugin now knows that it is dealing with the EK of an approved TPM, it creates the activation credential containing the encrypted ticket. The plugin calculates the ticket value as the HMAC over the parameters sent to the getChallenge endpoint, using a secret key known only to the plugin.

When the plugin later receives the plaintext ticket back in a call to its getCertificate endpoint, it recalculates the HMAC over the original request parameters and verifies that the result matches the received ticket value.

The plugin can then safely issue a certificate for the IK, in the knowledge that the ticket could have only been decrypted in case the certified IK is stored securely inside the key vault of the TPM identified by the EK.

In conclusion, TPMs are an increasingly popular solution for improving the security of smart, connected devices. By using them to store a certified device identity key, each device will be able to authenticate itself to online services.

The problem is how such device identity keys can be securely provisioned onto TPMs, when there is no secure communication path between the TPM and the certificate authority. Fortanix Data Security Manager, together with its TPM Key Provisioning Plugin, provides a solution to this problem, by taking on the role of identity CA and employing the credential activation process supported by the TPM.

Apart from providing a useful service in its own right, the TPM Provisioning Plugin also demonstrates the power and flexibility of the Fortanix DSM plugin system, which allows arbitrary extensions to the core DSM functionality to be implemented in a secure and modular way.

List of References

1. Trusted Computing Group, “TCG EK Credential Profile for TPM Family 2.0, Level 0, Specification Version 2.0, Revision 20,” 3 May 2017. [Online]. Section B.3. Available: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/. [Accessed 11 May 2021].

2. Trusted Computing Group, “Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.38,”, September 2016. [Online]. Section 25.1.4. Available: https://trustedcomputinggroup.org/tpm-library-specification. [Accessed 11 May 2021].