Trusted Platform Module

In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM.

Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM.

What is TPM?

TPM is (generally) a chip designed to provide security related functions. It provides functionality such as generating cryptographic keys, recording and verification of system state integrity and a very limited storage (for storing security keys). So essentially TPM is a secure cryptoprocessor. TPM forms “root of trust” and hence acts as a starting point in the “chain of trust”.

TPM is a passive component – it doesn’t initiate any computation, nor does it alter or influence execution of code. It just responds to the queries initiated by other (hardware/software) components. TPM is generally a SMD on motherboard (TPM standard version 1.2), however as per latest standard (2.0), implementation range can span from hardware to Cloud (software). Once added, TPM becomes a permanent component of the platform.

Components of TPM

There are two essential components of a TPM – cryptographic engine and a set of registers.

Cryptograhic engine provides encryption-decryption capabilities, digital signatures and hashing functionality. The set of registers called Platform Configuration Registers are used to store representation of platform state.

Apart from these essential components, TPM also provides a limited memory to store keys or data. TPM provides a monotonic counter, and a mechanism to exchange data securely with TPM. Using these facilities,TPM provides platform attestation (reporting platform state) and sealing (using platform state to authorize access to keys and other data).

TPM provides platform integrity measurements and cryptographically binds secrets with a platform.

Standards, features and the TCG

TPM standard is maintained by the TCG – Trusted Computing Group. TPM standard version 1.2 is in wide use. Latest revision of version 2.0 became available in September 2016. Following table gives a comparative summary of both versions.

	TPM 1.2	TPM 2.0
Architecture	One size fits all	Platform specific 4-part
Algorithms	SHA-1, RSA, MGF1 (PKCS#1), Optional: AES	SHA-1, SHA-256, RSA, ECC, HMAC, AES 128-bit, MGF1 (PKCS#1)
Crypto primitives	Random number generator public key crypto algorithm crypto hash function mask generator digital signature generator and verifier direct anonymous attestation key generator (optional) symmetric key	Random number generator Public key crypto algorithms Crypto hash functions Mask generator Digital signature generator and verifier Direct anonymous attestation Symmetric key generator Exclusive-or Key derivation functions
Hierarchy	One (storage)	Three (platform, storage, endorsement)
Root keys	One (RSA-2048)	Multiple keys and algorithms
Authorization	HMAC, PCR, locality, physical presence	Password, HMAC, policy (covers HMAC, PCR, locality and physical presence)
NV RAM	Unstructured data	Unstructured data, counter, bitmap

How TPM works

Each TPM has a unique and secret RSA key burned in by the manufacturer. This key is used by TPM in further computing.

Platform initialization and state measurement

BIOS can take advantage of TPM. TPM along with UEFI BIOS forms a “Root of Trust”. At the time of boot up platform state is “measured” and stored in the TPM PCRs. Platform state is represented in TPM as hashes. TPM’s own RSA key is used to calculate the hashes. Just to give some idea, following are some of the items stored in TPM’s PCRs:

• BIOS, ROM, Memory Block register
• OS loaders
• OS
• Localities, Trusted OS
• Applications specific information

This is used to provide “Measured Boot” functionality. Measured Boot is a process by which pre-boot software (e.g. firmware) uses TPM to verify nothing has changed in the pre-boot environment. Starting from power-on, each piece of code that is executed measures (hashes) next piece of code and extends PCR before executing it. The first piece of code that is executed (BIOS) is write-protected hence guarantees that nobody can spoof this sequence of measurements. This forms the “Root of Trust”.

Transaction validation

Once the “Root of Trust” is created, it is used in establishing “Chain of Trust”, which provides Trusted Execution Environment. It goes without saying that in order to take advantage of TPM, OS and applications should equally capable of utilizing TPM’s features. Applications need to be designed/enhanced to leverage TPM’s power. Typically all these applications rely on the keys generated by TPM to enforce secure execution environment.

When a software requests generation of a key, TPM generates a new RSA key, concatenates it with a value known only to TPM (“proof”), adds authorization data and encrypts all this information, returning this encrypted “blob” to requesting software. When the software wants to use the key, it sends “key load” command and the encrypted “blob” to TPM. TPM verifies the blob by checking that the “proof” is its own and then loads the RSA key into TPM memory. Software then can use this loaded key into further transactions.

Types of TPM

Version 1.2 of the standard defined a single type for everything. Version 2.0 defines 5 different types suitable for different kinds of platforms. Following table lists different types of TPM and compares different aspects like level of security, price and typical use scenarios.

TPM type	Security level	Security feature	Relative cost	Typical application
Discrete	Highest	Chip, tamper proof	100	Critical systems
Integrated	Higher	Hardware	10	Gateways
Firmware	High	Trusted Execution Environment	1	Infotainment
Software	NA	Same as OS platform	0.1	Testing/prototyping
Virtual	High	Hypervisor	0.01	Cloud environment

Concerns

There has been some resistance to whole-hearted acceptance of TPM from Open Source community as well as some corporates due to few concerns.

One of the concern is ability to abuse of remote validation software by which selective software can be allowed to execute, there by gaining an edge over competition.

Second concern is in case somebody gains physical or administrative access to TPM, security of the entire platform can be compromised.

Types of attacks

Like any other connected platform, TPM is also vulnerable for attacks. These attacks can be grouped in to four categories.

• Software attacks – which exploit implementation flaws.
• Fault attacks – which take advantage of design flaws (e.g. Voltage ranges, clock frequencies, UV light etc.)
• Side channel attacks – like monitoring analogue signals. CIA claims to have hacked TPM using differential power analysis in 2010.
• Invasive attacks – in which attacker gains physical access to the platform. In 2010, TPM was hacked by probing an internal bus. Cold-boot attacks are also possible with physical access to hardware.

References

• Wikipedia https://en.wikipedia.org/wiki/Trusted_Platform_Module
• TCG https://trustedcomputinggroup.org/