Contents
Looking to know What is a TPM? Let us read further to know more about it.
TPM (Trusted Platform Module) is a computer chip (microcontroller) that can securely store artifacts used to authenticate the platform (your PC or laptop). These artifacts can include passwords, certificates, or encryption keys.
A TPM can also be used to store platform measurements that help ensure that the platform remains trustworthy.
Authentication (ensuring that the platform can prove that it is what it claims to be) and attestation (a process helping to prove that a platform is trustworthy and has not been breached) are necessary steps to ensure safer computing in all environments.
Trusted modules can be used in computing devices other than PCs, such as mobile phones or network equipment.
the current generation of TPMs (version 1.2) is 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 combined with access control for secrets based on the monitoring of state, 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 use of third parties as to privacy or migration brokers.
At the time of creation, data can be designated as either migratable or non-migratable, depending upon 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 – What is a TPM
The TPM architecture and data format have been designed to achieve the desired functionality, whilst 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 an asymmetric encryption algorithm such as a block cipher would be better suited. The TPM thus need only 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 – simply that it does not perform cryptography using them. Instead, symmetric keys are sealed to a configuration and released for use to 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 of 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 which govern protected content), but 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 TPM proof. Essentially, the asymmetric cryptosystem is converted into an asymmetric one, with a composite key consisting of the private half of the root storage key and TPM proof.
The TPM does make extensive use of cryptographic hash operations, however, and currently uses the SHA-1 hash algorithm.
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 migration, where the third party produces an authorization certificate processed by the TPM.
The TPM architecture would be complicated by storing additional states between API commands, but on the other hand, requiring the migration certificate to be verified before the migration of every individual key incurs a performance penalty.
The use of capabilities based on TPM Proof allows the check to be done once only, and a capability issued, which is much quicker to check at subsequent invocations of migrating commands.
Physical tamper resistance is another area where the TPM architecture has been thought out carefully. In principle, there is no limit to the security of a system built when the cost is not a factor.
The question as always is – who is willing to pay for it? For this reason, the TPM is alike most other commercial security measures: it protects against certain attacks and 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 is separate chips, which are physically separable from the devices they are monitoring. Current TPMs are generally surface mounted onto the motherboard, and whilst it is a non-trivial operation for an amateur to de-solder and replaces chip components, it has not been designed to resist active physical attacks.
For example, selective modification of bus signals to the TPM, simulation of reset, and use of dual-ported memory have all been proposed as ways to trick a TPM into erroneously releasing access to cryptographic keys whilst 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.
Scenarios such as Digital Rights Management (DRM) exist where the operator of a computer is the attack, 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 WYSIWYG: 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 which 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 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 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 application, 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 ahead for Windows security, but in order to really make sense of remote attestation, an OS more akin to SE Linux is required.
Supposing such an OS could be created and a usable work environment for the desktop developed, 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 – for helping system administrators of IT systems in large corporations keep users’ workstations locked down from unauthorized 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 is 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 who 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 which is most exciting.
So there is a bright future ahead both on the desktop and for embedded and ubiquitous computing, which the TPM can play a major role in – whether within or alongside the eternally ubiquitous general-purpose computer.
