What's in a Trusted Computing Platform?

By Graeme Proudler

Date: Aug 23, 2002

Article is provided courtesy of Prentice Hall Professional.

Return to the article

Learn what a Trusted Platform is (including the reason for its name), along with the various enhancements that differentiate a Trusted Platform from a conventional platform.

Introduction

In this tutorial, Graeme Proudler, an IT researcher specializing in trust and security, introduces the nature of Trusted Computing Platforms based on the specification of the Trusted Computing Platform Alliance (TCPA), and then walks through the recipe for a Trusted Computing Platform. (TCPA is promoted by HP, IBM, Intel, and Microsoft. TCPA specifications can be downloaded anonymously and free of charge from www.trustedcomputing.org.)

What Is a Trusted Computing Platform?

The term Trusted Computing Platform arises from the ability of a Trusted Computing Platform to provide reliable information about itself and its current software processes, and provide attestation to its construction and attestation to operation of its software processes. This ability is under the explicit control of the platform's owner. Recipients of such information from a Trusted Computing Platform, including the user of the platform, can use the information to decide whether it's safe to interact with the platform for their particular purpose. In other words, they can decide whether to trust the platform.

Trusted Computing Platforms are not typical "secure" platforms, although they unavoidably use information security mechanisms: The basis of Trusted Computing is provision of reliable evidence about the current computing environment, and attestation of selected computing environments. When a Trusted Computing Platform reports a given environment and supplies attestation that that environment has sufficient functions, protections, and integrity for some particular purpose, a Trusted Computing Platform can (in that session) be considered to be safe for that purpose. This is critical to an understanding of Trusted Computing Platforms, and worthwhile reiterating: If a user is performing a task on sensitive data that requires protection, he or she should perform that task on a platform only when its software environment is in a state that protects the data. A safe computing environment provided by a Trusted Platform could eventually be as safe as that of a dedicated and isolated coprocessor, depending on the choice of software environment. The choice of safe environment rests entirely with the data owner, although he or she may rely on the recommendations of others.

The Trusted Platform provides reliable evidence that the safe environment actually exists. The decision to instantiate the safe environment rests entirely with the owner or user of a platform. Once a platform has safe environments, those environments can be used to manipulate all kinds of important information, while minimizing the risk to that sensitive—or private, or even secret—information. A user can maintain the privacy of his own personal data and, of course, can assure others that any sensitive material supplied by them will be treated with the same respect as his own personal data. This supports more adventurous and higher-value Internet interactions for personal and commercial purposes.

The Components of a Trusted Computing Platform

Architecturally, Trusted Computing Platforms are typically platforms modified by the addition of a small amount of extra hardware (roughly equivalent to a smart card chip), extra firmware and extra software, and an enhanced operating system. The fundamental functional alteration is the insertion of a root-of-trust into a platform. (A root-of-trust is a set of unconditionally trusted functions.) But a root-of-trust is not the whole story; commercial factors, political factors, and other requirements must all be addressed.

The Trusted Computing Platform Alliance's version of a Trusted Computing Platform uses the following (to first approximation):

The remainder of this tutorial introduces the particular set of critical functions that are present in a TCPA-style Trusted Computing Platform.

Root-of-Trust

A root-of-trust is a set of unconditionally trusted functions and must be a computing engine, because it must perform actions. It must work properly no matter what software is executing on the platform, in order to be immune to software attacks. Ideally, it should also be immune to physical attack, to avoid the need to trust an owner or user of a platform (who might otherwise physically meddle with it). Otherwise, a third party cannot unreservedly trust a remote platform. Unfortunately, physical immunity is impossible, and we have to settle for mere physical protection. (It's the same for smart cards and crypto-coprocessors.) For most commercial purposes, it's sufficient to have a root-of-trust that's built to resist a modest level of physical attack.

Of course, anything that one person can make, another person can break—given enough time, money, and opportunity. The art lies in selecting a root-of-trust price/protection point where the cost of breaking the root-of-trust is more than the value of the information that's revealed. At the end of the day, however, any hardware protection can be broken, so a global secret is just asking for trouble. It follows that each platform should have its own individual secrets in order that a successful attack cannot reveal secrets belonging to any platform other than the cracked platform. If the data in a Trusted Platform is so valuable that embedded forms of physical protection are insufficient, locked rooms and/or human guards must protect the platform from physical interference.

The components that instantiate a root-of-trust should be attached to a platform in a way that enforces a 1:1 relationship between the root-of-trust and the platform. But any attachment method can be overcome, given enough perseverance. The sensible course of action is to use an attachment method that's appropriate for the expected user and usage of a platform. Ordinary soldering of devices on a motherboard (or an equivalent method with at least the same strength of safeguards) is considered sufficient in most commercial cases. But it's critical to understand that subversion of the root-of-trust or its attachment to the platform inevitably destroys many Trusted Platform properties, and the only way to know whether a platform has been physically subverted is to physically check it. A local user can do this, although it might be inconvenient. A remote user can't do this. So the level of remote trust in a platform ultimately depends on a willingness to believe that the person or organization represented by the platform can be trusted not to physically interfere with the root-of-trust in the platform.

Privacy Controls

All sensitive aspects of a root-of-trust are always under the express and exclusive control of the platform's owner until and unless the owner delegates the authority for selected operations. The owner can blanket turn-on or turn-off the root-of-trust at will. Anyone can blanket turn-off the root-of-trust until the platform is next rebooted.

Measurement Software

Reporting the software state of a platform requires a computing engine to measure software before that software is loaded, and to store the measurement in the root of trust. A generic Trusted Platform does this with nested loader software, starting with the root-of-trust, each of which computes a digest of the next loader and stores the digest in the root-of-trust before passing control to the next loader. As long as software is measured and the result stored before execution, the software cannot hide itself. This builds a "chain of trust" starting from the root-of-trust.

Information Security Functions

A root-of-trust needs at least a random number generator, a hash function, and an encryption/decryption engine, because a remote user needs to 1) verify evidence that a platform contains a root-of-trust, and 2) verify evidence gathered by that root-of-trust (about the software state of the platform). This is probably impossible without the use of information security mechanisms.

Given that a Trusted Platform must contain information security mechanisms, it's a no-brainer to decide that a Trusted Platform could (and should) provide basic information security services to users of the platform. Those basic services are as follows:

This latter aspect of access control is possible only because of the unique behavior of Trusted Platforms: they report measurements of the software state of a platform. It's therefore possible to incorporate values of measurements of the software state of a platform into access control information. A Trusted Platform can then refuse to reveal a secret if the current software state is not the expected state into which the secret should be revealed. This is valuable because a Trusted Platform executing the wrong software (such as a hacker script) has a means to decide not to release keys (for example). This prevents digital signing and the release of confidential data in the wrong software environment, even if the correct password is presented.

There are also other important auxiliary information security services, including a means for the root-of-trust to attest that keys belong to a Trusted Platform (giving some degree of confidence that keys are being protected while they are being used).

A Trusted Platform needs both asymmetric and symmetric encryption algorithms, because they have different properties and different usages. These asymmetric and symmetric algorithms are preferably implemented in different ways:

Identifying a Platform

The root-of-trust in a platform needs to be able to prove that it exists, and needs to prove that it supplied the evidence about the software state of a platform. The obvious way to do this is to give a separate cryptographic identity to each root-of-trust, so the root-of-trust can sign data. To provide the highest levels of privacy, however, we need some way to identify a root-of-trust while preventing that identification from being used to correlate actions of a Trusted Platform (unless such correlation is actually desired). The TCPA's solution to this conundrum is to enable a platform to have an arbitrary number of uncorrelated so-called "attestation identities," each of which can prove that it identifies a genuine Trusted Platform. The process of generating an attestation identity is too complex to describe here, but involves the platform's owner making a Trusted Platform generate a new cryptographic identity, submit a certification request to a Certification Authority (CA) along with information about a particular Trusted Platform, and request that the CA create a certificate for that identity which can be revealed only in that particular Trusted Platform. (Only the platform's owner can trigger this process.) The properties of the CA determine the correlation properties of the attestation identities. If the CA retains information, it can correlate transactions involving different identities. If the CA doesn't retain information, no one other than the owner of the identities can correlate transactions involving different identities. (Or, at least, no one can use a Trusted Computing Platform identity to correlate transactions involving different identities.) Critically, however, the same identity always identifies the same platform.

Any and all identities can completely hide the true identity of the owner of a platform, if the owner wishes. But presumably the platform owner will create some identities that will (directly or indirectly) be meaningful. This is because, as mentioned before, the level of remote trust in a platform ultimately depends on a willingness by the remote party to believe that the owner of the platform can be trusted not to physically interfere with the root-of-trust in the platform. This requires a meaningful identity.

An Enhanced Operating System

Even with a standard operating system (OS), a Trusted Platform can use its information security mechanisms to store and protect secrets, it can have an arbitrary number of attestation identities, and it can report what OS was loaded. (This phased availability of benefits is a deliberate design decision, because it was anticipated that Trusted Platform hardware would be available before an enhanced OS.) These features on their own enable enhanced applications and services, certainly significantly better than can be provided by conventional platforms, so this class of platforms are very worthwhile in their own right.

Without OS enhancements, however, a platform doesn't have full Trusted Computing Platform functionality. Such a platform can't report on the state of the OS, or on the applications that have been loaded by the OS, so it's more difficult for a user to decide whether to trust the platform with a sensitive task. Obviously, the more of the software stack that can be reported, the more confidence the user can have in the state of the platform. For example, it's good to know that a corporate financial application is running but a connection to an unapproved ISP is not.

Reporting the state of the OS and applications requires operating systems that are augmented to measure executables before loading them. Critically, it also requires that enhanced operating systems be modified to minimize the opportunity to bypass the measurement software. OS writers are encouraged to step up to the task!

User Services

Trusted Platforms must solve known problems that people want solved, or enable people to do desirable things that they can't do with ordinary platforms. Trusted Platforms were therefore designed to support three main phases of functionality, each requiring more support investment than the previous stage:

  1. A Trusted Platform must at least provide an application programming interface (API) to its trusted functions. This alone will justify the purchase of a Trusted Platform by sophisticated customers, because it allows a knowledgeable user to develop his or her own trusted applications, and permits any application that uses standard crypto APIs to use a Trusted Platform's hardware-enforced digital signature and confidentiality functions.

  2. If the platform has an OS that measures the loading of executables, the platform's signing and confidential storage trusted functions can be augmented to take into account the software state of the OS and applications. This provides a measure of defense against hacker scripts and the like, and against inadvertent exposure of sensitive data. Of course, applications may have to be altered to take explicit advantage of this extra protection. Little or no infrastructure change is required.

  3. If the platform is provided with an OS or application that can also interpret platform identities and the trust state of a platform, electronic services can make use of the trusted state of a platform and take appropriate action. This requires some network infrastructure with Certificate Authorities to attest to platform identities.

Implementation Options

How should a Trusted Platform be implemented? What parts of a Trusted Platform should be protected via hardware instantiation and what should not? TCPA avoids the issue, saying only that sensitive data must be held in "shielded locations" while it's capable of being viewed or manipulated, and only "trusted capabilities" can access data in such shielded locations. This avoidance is deliberate, because TCPA doesn't want to predicate any particular solution to the problem.

Of course, it's best to sidestep the issue and do as much as possible with functions that don't need to be trusted. (Normal software processes can do untrusted processing.) This approach is obviously illogical for primitives such as digital signing, for example, but advantageous when implementing more complex functions. (TCPA used this approach in its protocol to obtain "attestation identities" for a Trusted Platform. Both the start of the protocol [sending data to a CA] and the end of that protocol [receiving data from a CA] were split into two separate functions. In each case, one function does all the processing that must be trusted, and the other function does the remaining processing that doesn't have to be trusted.)

Once unnecessary functions have been eliminated, any remaining trusted functions form the root-of-trust and must be protected somehow. Protection mechanisms should be as straightforward as possible; the more convoluted a mechanism is, the harder it is to be confident that it will do what it's intended to do. And "less hardware is more" because hardware cost is the irreducible cost of a platform, even if functions and data in dedicated hardware are easier to protect from software attack and physical attack. So it's difficult but critical (both commercially and for security) to make a good implementation choice for a trusted function. An obvious choice is to put all the root-of-trust in a self-contained microcontroller or customized device, so that secrets don't appear on device pins or on circuit board traces. These devices can be considered to be derivatives of smart cards, which use proven techniques to try to resist chip peeling and other attacks. Essentially the same device can be used on many different platform types, benefiting from increased volume of manufacture and hence reduced cost of individual devices.

On the other hand, it would be nice to avoid the extra cost of an additional chip if at all possible. A normal computer platform (a PC, for example) has a distributed computing engine, in the sense that the components that constitute the engine are usually physically distributed on the motherboard. That distributed computing engine can execute trusted functions if:

  1. Secrets are only revealed to trusted functions.

  2. Trusted functions cannot be subverted or arbitrarily created

  3. The computer platform provides sufficient protection against physical attack on trusted functions.

Some types of existing processors are built with physical support for than one level of processing privilege, whereby the processor's hardware stops lower-level instructions from accessing resources available to the higher level. A higher privilege level could be used to execute trusted functions while a lower privilege level is used for executing normal functions. Then normal software processes cannot interfere with trusted processes and their secrets. This approach satisfies requirements 1 and 2 above. Unfortunately, requirement 3 requires other alterations. Anyone with physical access to the motherboard, for example, has access to whatever signals appear on pins of devices, or on traces between devices. Unless such access can be prevented (by locked enclosures or rooms, or human guards), sensitive information passing between devices must be encrypted to prevent its revelation while in transit. This means that all devices dealing with secrets need to be able to encrypt and decrypt signals. Then the problem becomes one of distribution of secrets between devices, to be able to identify the source and destination of encrypted secrets.

Summary

A Trusted Computing Platform contains unconditionally trustworthy functions, providing safe digital signing and cryptographic protection of data, plus an arbitrary number of uncorrelated cryptographic platform identities. A Trusted Platform can emulate a protected processing environment to maintain the privacy of sensitive, private, or secret information. A protected environment is specified by the owner of data in terms of measurements of that environment. The presence of such an environment is verified by comparison of actual measurements with expected measurements, and verification that the actual measurements were provided by a genuine root-of-trust.