Hi, my name is El Mostafa IDRASSI, and welcome to the ‘DiscoverIT Series’. Throughout this new series, I will be presenting some of the IT topics that have emerged during my work as CTO @PrestaLab.

In this first episode, I will be digging into the Trusted Platform Modules (TPMs). I will be answering some questions that I myself was asking when I had to work on this subject. So, buckle up, we’re in for a good ride!

I- What are TPMs ?

A Trusted Platform Module (TPM) is nothing more than a microprocessor that can perform cryptographic operations. But, unlike other microprocessors, it comes with many security features and measures that guarantee its tamper resistance. As a result, a malicious entity cannot tamper with its functionalities and components.

Physically, a TPM chip consists of 3 parts :

1. A Crypto Processor
   • Responsible for performing crypto operations (e.g. key generation, signature, hashing, decryption, random number generation…).
2. A Persistent Non-Volatile Memory (NVRAM)
   • Responsible for storing reboot-persistent entities.
3. A Transient Volatile Memory
   • Responsible for storing transient non-persistent entities. A platform reboot flushes all of its content.

II- What are the use cases of TPMs ?

Following this definition, one might not see what distinguishes a TPM from other crypto-processors (e.g. Smart-Cards). Like most of them, a TPM chip comes with a high quality RNG and facilities for signing, hashing and decrypting data. But what makes it special are 4 exclusive features that it provides to the platform it is linked to :

– Device Authentication

The platform can authenticate itself to a third-party using a TPM-backed key.
It can achieve this in 2 fashions :

• Using a Privacy-focused Key Attestation process (e.g. DAA).
• Using a Privacy-invasive Key Attestation process (e.g. PCA).

Both processes allow the platform to prove to the third-party that the key truly originated from its genuine TPM chip. The only difference between the two is that the first one does not reveal any information that can trace the key back to that specific TPM chip, while the second one does.

– System Integrity

The platform can prove to a third-party that it is running in a specific state. It can achieve this using a Remote Attestation process. What this means is that the platform collects security measurements and metrics from both the machine and the TPM chip and sends them to the third-party as proof of its state.

– Data Binding

The platform can guarantee to a third-party that some data is bound to its TPM chip. It achieves this by encrypting the data using a key created inside of its TPM chip. As a result, only its TPM chip can decrypt it.

– Data Sealing

The platform can guarantee to a third-party that some data is bound to its TPM chip and to a specific state of the platform. It achieves this by, first, sealing the data to the platform state (e.g. by adding the platform’s security measurements to the data), then encrypting the result using a key created inside of its TPM chip. As a result, only its TPM chip can decrypt it, with the additional condition that the platform state matches the one specified during the encryption.

III- What are the types of TPMs ?

Now that I have explained to you the 4 main use-cases of a TPM, I will talk now for a little bit about its variations.
Currently, there are 5 types of TPMs offering different trade-offs between cost, features and security. Nowadays, Firmware TPMs (fTPMs) and Discrete TPMs can be found in a lot of mainstream motherboards.

The TCG (the consortium responsible for the conception of TPMs) have come up with the following great table which describes these variations :

Also, TPMs come in 3 versions : TPM v1.1b, TPM v1.2 and TPM v2.0.
In all the following, I’ll be exclusively talking about TPM v2.0 chips, since this version is the newest iteration of the three and it is gaining in popularity as well.

But, before going any further, I need to define some key concepts and terms that you need to understand in order to get a better grasp on TPMs.

IV – What are some of the key concepts and terms related to TPMs ?

– Entity

A TPM entity is simply an item in the TPM. It can be a key, some data, a session or some other TPM-specific entity (e.g. PCRs). An entity is always referenced by a handle.

– Handle

A handle represents a reference to an entity in the TPM. Think of it as the address of that entity in the TPM’s memory.
There are 3 types of handles : Transient, Persistent and Permanent handles.

A Transient Handle refers to an entity that lives in the Volatile Memory of the TPM. Such handles are valid until they are manually flushed or until the platform is rebooted. They refer to transient keys, authorization sessions and session contexts.

A Persistent Handle, on the other hand, refers to an entity that lives in the Non-Volatile Memory of the TPM, also known as the NVRAM. Such handles persist through the platform’s reboot, and can be evicted out of the NVRAM by their owner. They refer to persistent keys and data.

Finally, a Permanent Handle is one that the TPM specification defines. Such handles refer to entities that live in the Non-Volatile Memory of the TPM, but cannot be evicted out of it as opposed to Persistent Handles. They refer to permanent TPM components that are not deletable, like the PCRs and the hierarchies.

The following flow chart showcases how a key becomes persistent in the TPM’s NVRAM:

– Hierarchy

A hierarchy is a collection of entities that are related and managed as a group. A TPM chip consists of 4 hierarchies : Null, Platform, Storage and Endorsement hierarchies. They can be enabled and disabled independently of one another.

All 4 hierarchies are permanent : they have permanent handles and are never deletable.

The Platform, Storage and Endorsement hierarchies are persistent hierarchies. This means that keys created and loaded into one of these hierarchies can still be loaded once again after a platform reboot.
On the other hand, the Null hierarchy is ephemeral : all its keys are erased and invalidated after a platform reboot.

Finally, each hierarchy has a seed that sits at its top.

– Seed

A seed is a large non-deterministic number generated by the TPM’s RNG. It is never exposed outside of the TPM and lives in its NVRAM. It is unique to each TPM chip and is used to create the Primary Keys.

The Platform, Storage and Endorsement hierarchies all have persistent seeds : this is the reason why they persist after a reboot. However, these seeds can be recreated by the hierarchy owner, although such manipulation is rarely performed in practice since it results in voiding the whole hierarchy.

On the other hand, the Null hierarchy has an ephemeral seed : a reboot resets it, leading to a reset of the whole hierarchy.

– Primary Key

A Primary Key represents the root of all the keys in a hierarchy. It is usually created in a deterministic way by feeding the hierarchy seed, a known creation template and some unique data into the TPM’s Key Derivation function (KDF). This means that, with the seed being a constant, providing the same creation template and unique data to the KDF always yields the same primary key.

A TPM can create an infinite number of primary keys by varying the creation template and the unique data fed to the KDF. However, because of the finite amount of memory a TPM chip has, not all of the primary keys can be evicted into persistent storage.

Primary keys are usually restricted : this means that they can perform cryptographic operations only on internal TPM data. Also, they come in 2 shapes :

• Primary “Storage” Keys which have the “decrypt” ability. These are the most commonly created as they allow for the creation of wrapped children keys.
• Primary “Signing” Keys which have the “sign” ability. These are used for specific use cases, like Key Attestation. They can only sign TPM-related structures and cannot have children keys.

– Child Key

A Child Key represents a key under a primary or another child key. Unlike a primary key, a child key can be non-restricted. This means that it can perform cryptographic operations on arbitrary data. This is why children keys are used to sign and decrypt external data. If a child key has the “decrypt” ability, it can have its own wrapped children keys, leading to a more complex hierarchy.

– Authorization Policy

A TPM key can be created in a way so that it can only be used when some conditions are fulfilled. We call these conditions assertions, and they can be one or a combination of the following :

• Passwords.
• HMACs.
• Machine state (e.g. Platform Configuration Registers (PCRs) values).
• TPM state (e.g. counters, time).

That’s about it for this episode! I believe this was a decent introduction to TPMs. I hope this was helpful for those of you who have just started working with TPMs and also for those of you who are just curious about such technologies.
See you in the second part where I’ll be talking more in detail about the TPM hierarchies, PCRs and TPM’s use cases.

References

Will Arthur and David Challener, 2015 – A Practical Guide to TPM 2.0
Trusted Computing Group (TCG) TPM 2.0 Library