The cost effective architecture of TPM
Reading Time: 15 minutes
The current generation of TPMs (version 1.2) are chips that are usually surface mounted onto the motherboard of a PC or integrated into a custom PCB. The TPM process reports the state of the system, from the moment of power-on right through to the execution of applications on a modern graphical operating system.
Monitoring has limited uses but combined with access control for secrets based on state monitoring, it becomes easy to execute many security practices. For example, if a PC is booted into a state where only select apps are installed, the TPM could then grant access to data storage and encryption keys for secure email.
Additionally, the TPM can manage third-party connections, be it the owner of a device wanting to remotely manage it, or a device manufacturer giving it to an untrusted party. To support requirements for availability, and to guard against equipment failure, the TPM can manage the migration of data between trusted devices, and for use of third parties as privacy or migration brokers.
Upon creation of the data, it can be designated as either migratable or non-migratable, depending upon the protection model required.
In short, the TPM makes it easy for operating system designers to protect themselves from attackers who may have access to the physical computers in their environments (swapping out a hard drive for example).
A Cost-Effective Architecture
The TPM architecture and data format was designed to achieve the desired functionality. It can be difficult for companies to integrate the hardware for perhaps thousands of computers and other devices, but the TPM is a cheap encryption solution that can be easily implemented with a minor impact on a company’s budget.
For example, using entirely asymmetric encryption would be a more cost-effective option, even though a symmetric encryption algorithm such as a block cipher would be better suited. Therefore, a TPM need only contain an RSA modular exponentiation accelerator and not an implementation of AES or 3DES.
Obviously, it can store any of these key types, but instead, any symmetric keys are sealed to a configuration and released for use in a trustworthy OS configuration. This means that TPM internal data storage formats are limited by the maximum size of data that can be encrypted using RSA operations of a certain key length. As a result, the efficiency of asymmetric encryption is taken advantage of while still maintaining compatibility with symmetric encryption.
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 which 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.
To solve this problem, every data structure in the TPM is signed with a “TPM Proof”, which in essence is a special secret hash that is matched with an existing root RSA Key in a special register.
So even though an attacker may access the public key, they cannot know the TPM Proof, which is needed to access data. Essentially, the asymmetric cryptosystem is converted into a symmetric one, with a composite key consisting of the private half of the root storage key and the TPM proof.
A TPM is usually programmed with high-functioning cryptographic hashing algorithms, most often using SHA-1. Using the Platform Config Registers (PCR) values, the algorithm further encrypts the key and, in a way, “extends” the values to improve security. This also prevents the modification of data, key identification, and improved command chaining. Hashing command parameters together with the help of the TPM Proof secret value can be very useful when considering command chaining in a TPM, as it creates a 160-bit capability string that attackers cannot forge. This can cause major performance improvements for Third Party Migration for example, where the authentication and authorization certificate is produced by a third party and processed by the TPM.
This introduces some performance decreases for the sake of authentication since in order to protect from the possibility of malicious attacks in this situation, a migration certificate must be verified before each key is transferred.
This problem is solved by the TPM Proof, which can run a single check using the compatibility string, which can make things much faster.
The physical design of these chips is also a crucial factor for their security and cost-effectiveness. Since they were designed to be a cheap solution, even though the security of the system is well thought out, it does not protect against some attacks and protects against others.
One of the most significant weaknesses of the TPM platform is its physical vulnerability. Most TPMs used to be mountable and separable from motherboards, which raises a lot of questions about the security of a physically removable device, now they are usually mounted inseparably to the motherboard. Removing a soldered chip from a device might sound easy but it is up to the organization to put in place man traps, smart cards, and other security procedures to ensure only authorized persons have access to the physical machines. If a malicious person had access to the device, aside from removing it, not much else is possible; however, proposals have been made regarding other ways to trick TPMs.
These different ways include using a simulation of reset, using dual-ported memory, or modification of bus signals. Soon new chip technologies will be released further improving security in this regard. But since hardware attacks are few and far between, the major focus remains on the software and firmware security of these devices, so sacrificing physical security isn’t necessarily so bad of an idea. Operating system integrity dominates proposed threat models when TPMs are deployed. Hardware state monitoring plus improved operating system security working in tandem can help prevent rootkit and Trojan Horse attacks.
The one area where the TPM architecture has gone out on a limb in the trade-off between cost and functionality is the area of privacy. Any sophisticated architectural features 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 that can be managed locally and registered with trusted third parties (authorized not to reveal a user’s identity).
An implementation of a zero-knowledge proving protocol is designed to allow a TPM to attest to a particular configuration without revealing this identity to anyone. This protocol is highly advanced and does not allow for any identifying information to be leaked and is a testament to the designer’s unwillingness to allow any compromises of privacy. Even though the device is on the cheaper end of the market, it can handle private operations as securely as can be.
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, and has the services needed to run these advanced features.
TPM Application Space
Many modern laptops 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.
Since the average user will not need sophisticated security procedures, it is up to an organization or knowledgeable user to enable hardware monitoring. Once activated software such as Microsoft BitLocker disk encryption software, released with professional and enterprise versions of Windows, can be configured to use the TPM for secure storage of top-level cryptographic keys.
Whilst BitLocker has become generally the mainstream form of desktop encryption, the more ambitious functionality of the TPM such as remote attestation can only really be leveraged in tandem with a specially designed operating system. New releases of Windows could introduce newer functionality, but with that comes untested vulnerabilities. Simply put – if the trusted code has bugs, then the remote attestation proves nothing.
In order to make sense of remote attestation, an OS more akin to SE Linux is required. If OS could be created and a usable work environment for desktop computing developed, there would be many security safeguards. The platform could restrict installation to only approved software, using a predetermined list of allowed operations help to eliminate many avenues a virus could take. This is a commonly envisaged use case of the TPM – for helping system administrators of IT systems in large corporations keep users’ workstations locked down from unauthorized tampering. Be it a virus, or a seemingly harmless program installed by a user, strict administration is required to prevent breaches.
The success 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. Encryption Consulting offers training to better understand the hardware and software components of these processes.
For example, building a PKI with machines using integrated TPMs is essential to a robust infrastructure for any company. But it is not necessarily large companies who will benefit the most, it is the availability of this hardware-assisted security to smaller companies and even individuals which is essential for the IT industry.
So, there is a bright future ahead both on the desktop and for embedded and ubiquitous computing using TPM technology, which can sustain secure key storage and further web development.