The Trusted Platform Module Explained

Introducing the TPM

The Trusted Platform Module (TPM) is a special purpose microcontroller designed by the Trusted Computing Group, which interfaces with a standard hardware/software platform in order to allow it to be secured to serve the interests of just one party - the system designer.

The current generation of TPMs (version 1.2) are stand-alone chips that are usually surface mounted onto the motherboard of a PC or integrated into a custom PCB for an embedded device. The TPM can monitor and access the main bus of the computer, which allows it to keep track of and report on the configuration state of the entire computer, from the moment of power-on right through -- potentially -- to the execution of applications on a modern graphical operating system. Monitoring in itself has limited uses, but when combined with access control for secrets based on the monitoring of states, all sorts of interesting applications become possible. For example, if a PC is booted into a certain trustworthy state where only a fixed set of applications are installed, the monitoring TPM could then grant access to data storage and encryption keys for high security email. Additionally, the TPM can attest to the configuration of the computer to external third parties, be it the owner of a device wishing to remotely manage it, or a device manufacturer leaving a device in the hands of an untrusted third party. Finally, in order to support requirements for availability and to guard against equipment failure, the TPM includes command infrastructure and protocols for migration of data between trusted devices, and for the use of third parties as privacy or migration brokers. At the time of creation, data can be designated as either migrateable or non-migrateable, depending on the protection model required.

In short, the TPM puts tools in the hands of operating system designers to protect themselves from attackers with logical access to low-level parts of the computer (for instance, attackers who can swap out a hard drive).

A Cost-Effective Architecture

The TPM architecture and data format have been designed to achieve the desired functionality while always observing and maintaining cost-effectiveness—to keep it suitable for incorporation into millions of computers at little additional cost. For example, consider the cost-saving decision to use entirely asymmetric encryption for all data storage, even though a symmetric encryption algorithm such as a block cipher would be better suited. The TPM thus needs only to contain an RSA modular exponentiation accelerator and not an implementation of AES or 3DES. Of course, this does not mean that the TPM cannot store such keys; it simply does not perform cryptography using them. Instead, symmetric keys are sealed to a configuration and released for use with a trustworthy OS configuration. TPM internal data storage formats are thus limited by the maximum size of data that can be encrypted using an RSA operation with a particular key length. But how does the TPM deal with false key injection, as the public half of the storage key will be available to all? The ability to insert false keys may seem irrelevant (after all, it cannot gain access to existing storage keys that govern protected content), but it is crucial, as without it, it would be possible to create a key that is designated as non-migratable (can never be removed from a specific TPM) and yet with a value known to the attacker. If a content provider were to issue content to be protected under this key, a breach would occur. The TPM solves this problem by maintaining a special random secret, known as "TPM Proof," which is inserted into every data structure encrypted under the TPM's root storage RSA key and is checked for a match against the master copy of TPM Proof held in a special register. This ensures that false keys cannot be inserted into the key hierarchy: whilst anyone can of course encrypt plaintext under a public key, they do not have access to the clear value of the TPM proof. Essentially, the asymmetric crypto system is converted into a symmetric one with a composite key consisting of the private half of the root storage key and TPM proof.

The TPM does use cryptographic hash operations a lot, and it uses the SHA-1 hash algorithm at the moment. This hash algorithm is used to "extend" the values in the Platform Configuration Registers (PCRs), to detect and prevent data modification, identify keys, and create "capabilities" used to improve the efficiency of command chaining. Capabilities are created by hashing particular command parameters together with the secret value TPM Proof in order to create a 160-bit capability string that cannot be forged by an adversary. This is useful in improving the performance of (for example) third-party-approved migrations, where the third-party produces an authorisation certificate processed by the TPM. Keeping track of more state between API commands would make the TPM architecture more complicated. On the other hand, requiring the migration certificate to be verified before each key is moved would slow things down. The use of capabilities based on TPM proof allows the check to be done once only and a capability to be issued, which is much quicker to check at subsequent invocations of migrate commands.

Physical tamper-resistance is another area where the TPM architecture has been carefully thought out. In principle, there is no limit to the security of a system built when cost is not a factor. The question, as always, is: who is willing to pay for it? For this reason, the TPM is like most other commercial security measures: it protects against certain attacks but not others. Specifically, as the TPM was envisaged as a low cost secure microcontroller, one of the most significant compromises has been limited protection against physical attacks. The first generation of TPMs were separate chips that were physically separable from the devices they were monitoring. Current TPMs are usually surface mounted on the motherboard. Even though it's not easy for a beginner to de-solder and replace chip components, it wasn't made to withstand physical attacks. For example, selective modification of bus signals to the TPM, simulation of a reset, and use of dual-ported memory have all been proposed as ways to trick a TPM into erroneously releasing access to cryptographic keys while the system is in an unapproved state. That said, the TPM specification does not require it to be a separate chip, and there are plans underway to release specialized hardware with more tightly integrated TPMs.

But such a trade-off is not necessarily a bad choice: hardware attacks are rarely within the threat model when TPM-based systems are deployed. There are scenarios, such as Digital Rights Management (DRM), where the operator of a computer is the target, but more often it is logical attacks -- in particular Trojan Horse and rootkit attacks -- where TPM monitoring of operating system integrity really aims to make a difference. Together with improved operating system design, hardware-assisted state monitoring is an important component of systems to protect the integrity of user input and display, a concept introduced almost 10 years ago as a bi-product of the European ESPRIT project on electronic commerce, SEMPER, namely WYSIWYS: What You See Is What You Sign.

The one area where the TPM architecture has gone out on a limb in the trade-off between cost and functionality is in the area of privacy. Many sophisticated architectural features and layers of indirection in the design exist purely to enable online services to use TPMs without forcing the compromise of a user's privacy. This operates through a system of pseudonymous identities, which can be managed locally and registered with trusted third parties (trusted not to reveal a user's identity), and also via direct anonymous attestation, an implementation of a zero knowledge proving protocol that is designed to allow a TPM to attest to a particular configuration without revealing this identity to anyone. This is an extremely advanced protocol in comparison with other deployed systems, and it shows that whilst the TPM is generally aimed at the low-cost market, compromises have not been made in the area of privacy. The only caveat to be considered is that the inclusion of advanced architectural features does not necessarily mean that applications and systems will take advantage of these features; ultimately, it will depend on whether the final online service provider is economically motivated to protect the user's privacy.

TPM Application Space

Many modern laptops (for example, those from Lenovo, IBM, and HP) have Trusted Platform Modules already integrated; however, the chip lies dormant by default and must be enabled (usually in the BIOS) before it can begin monitoring. Once activated, software such as Microsoft’s BitLocker disk encryption software, released as part of Windows Vista Business and Ultimate editions, can be configured to use the TPM for secure storage of top-level cryptographic keys. Whilst BitLocker and disk encryption in general can be seen as the flagship deployed applications, the more ambitious functionality of the TPM, such as remote attestation, can only really be leveraged in tandem with a specially designed operating system. Simply put, if the trusted code has bugs, then the remote attestation proves nothing, for it can be compromised after keys have been surrendered to it. Vista may have made a substantial leap forward for Windows security, but in order to really make sense of remote attestation, an OS more akin to SE Linux is required. If such an operating system could be made and a good desktop work environment could be made, there would be some interesting benefits. The platform could restrict installation to only approved software, so virus and spyware protection would no longer be a challenge. This is a commonly envisaged use case of the TPM: helping system administrators of IT systems in large corporations keep users workstations locked down from unauthorised tampering, be it a virus or a theoretically benign application installed by the user, but which might damage reliability and complicate technical support.

One of the major deployment areas for the TPM in the future may be in monitoring and securing mobile phone embedded computers, as they support more and more advanced services (e.g., GPS mapping, MP3 playing, media streaming). Interestingly, while the push to secure the low-level software in the platform is undoubtedly aided by the TPM, user programmability and interactivity are not suffering so badly, as such features are migrating to higher and higher software layers, for instance Javascript and interactive web services—all of which will be supported on a modern mobile.

The arrival of the TPM secure microcontroller has largely been due to an open cooperative effort between major IT hardware and software players, including Microsoft, Intel, Infineon, IBM, and Sun Microsystems, but it is not necessarily large companies such as these that will benefit the most from the TPM (Sony, for example, already has proprietary secure microcontrollers used in all its products for enforcing security policies); it is the affordance of this hardware-assisted security to smaller companies and even individuals that is most exciting. So there is a bright future ahead, both on the desktop and for embedded and ubiquitous computing, in which the TPM can play a major role, whether within or alongside the eternally ubiquitous general-purpose computer.

Previously published in Cryptomathic NewsOnInk, 2008