Securely Store Your Credentials And Cryptographic Keys In TPM 2.0

A Trusted Platform Module (TPM) can securely store cryptographic keys that are specific to the host system and provide restricted access to the stored keys and secrets. You can never read out private keys, or in other words retrieve them as is from the TPM. Let’s say you need to generate a signature: you can indicate the private key you wish to use from the TPM to sign the message. You can then verify the signature with the corresponding public key. This way keys remain secure in TPM even if the host system is infected with malware.

Now let us look at the two categories of keys in a TPM:

1. Non-migratable keys

These are the unique keys that are bound to a specific TPM and cannot be migrated outside of a TPM. We saw in a previous blog that persistent hierarchies (endorsement, platform and storage) of TPM have a seed of their own. We can create a unique primary key in a hierarchy using its seed and a template, as shown in figure 1 below. This primary key will be the root key for all keys generated thereafter and effectively links those keys in a key hierarchy.

The template specifies the key type, size, algorithms and unique data that the user provides. The generated primary key remains in the volatile memory until the user makes it persistent. The Key Derivation Function (KDF) is fixed, which means that the same seed and the same template will generate the same key. Multiple primary keys can be generated by changing the unique data of the template. This way, we can always regenerate the keys rather than storing them persistently in the TPM.

Fig. 1: Primary key generation in TPM 2.0.

TPM 2.0 is shipped with a set of unique endorsement keys (ECC and RSA key pairs) that are maintained inside the chip. The private part of the key cannot be accessed by the user or the software. These endorsement keys are pre-provisioned by the manufacturer and are unique to every TPM and cannot be exported or migrated from the TPM. This forms the basis of endorsement key hierarchy.

2. Migratable keys

These are the keys that are not specific to a TPM and can be migrated outside of a TPM with right owner authorization. The public and private portions of the key can be exposed to other components such as software, processes and users. Primary keys for restricted storage, encryption and signing can be generated from the storage primary seed and can be used to encrypt other non-root keys. This hierarchical implementation can be used by the user to create a key store containing different keys for different use cases with a single initial root key.

‘tpm2_createprimary’ command is used to derive primary keys from the seed of corresponding hierarchy and ‘tpm2_evictcontrol’ command can make the key persistent.

Additionally, we can store 7 persistent keys (permanent until flushed by the user) and 3 transient keys on OPTIGA TPM 2.0 (SLB9670). So 7 keys, each 2048 bit, can be stored within Non-Volatile Memory (NVM) and 3 keys, each 2048 bit, can be stored within Random Access Memory (RAM) of the TPM.

NVM is the general-purpose memory in TPM that can be used to store user credentials, user data and X.509 certificates. Each area in NVRAM is addressed by a handle/index. There are a few reserved handles as defined in the TCG specification for accessing TPM manufacturer-installed Endorsement Key (EK) certificates. Handle 0x1c00002 stores the RSA EK certificate while 0x1c0000a stores the ECC EK certificate in NVM. OPTIGA TPM 2.0 (SLB9670) has an additional space of 6962 bytes for storing anything the user wishes to store.

Refer to the following link for examples on NVM definition and writing data into it.