Chapter 4. Access Control—Ownership, Enabling, and Authorization

In this chapter, we introduce the mechanisms enabling control of a Trusted Platform Module (TPM). TCPA technology is designed for a world in which all platforms are Trusted Platforms (TPs), where some owners of a TP want to immediately and remotely take ownership of their platform (in the TCPA sense, as introduced in this chapter). Some want to immediately take ownership but want to prevent it being done remotely; others want the TPM turned off for now but want to take ownership later; and the rest want the TPM turned off as long as they own the machine. Even those who normally use TPM capabilities want to turn them off on occasion, and then turn them back on again. Any user of a TP, not just the TPM owner, should be able to turn a TPM off when he needs neither a record of his activities nor the protections afforded by a TP. And, of course, private data must be available only to the owner of that data.

TCPA provides controls that enable all of these conflicting requirements. These controls expose a denial-of-service attack, but this was considered in TCPA to be a worthwhile price to pay for an improved user experience. Customers are all different, but they all want that “out-of-the-box” experience. They want their new platform to do what they want, immediately upon delivery. The TPM controls permit a manufacturer to deliver a platform to a customer in the “trust condition” wanted by that customer, without preventing that customer from changing his mind in the future.

Whenever possible, TCPA protected capabilities (in the sense of commands or functions) can be remotely activated. When that is not possible, the capability requires the physical presence of a person at the platform. Not all TPM capabilities are available to all users. Most are barred to anyone except to holders of the appropriate authorization information, and only the owner of the TPM is allowed to access some functionality. A few capabilities do not use authorization information at all, either because authorization is impossible in the circumstances in which the capability is used or because authorization is simply unnecessary. Often, more than one authorization value is required to use a capability.

The general model of access to TPM capabilities differentiates between two classes of users: (1) the TPM owner and (2) any user who has been provided with authorization by the TPM owner to use the TPM. The TPM's normal authorization mechanisms rely on the ability of the user or owner to prove knowledge of authorization information corresponding to a given instance of a TPM capability. These normal mechanisms use shared values as inputs to TCPA-defined authorization protocols, to prove knowledge of these values without revealing the values themselves. This is to allow a TPM user or owner to authorize use of a TPM capability across an untrusted network, without revealing his authorization information to potential eavesdroppers on that network.

Other TPM authorization mechanisms use “proof of physical presence.” This form of authorization is used by capabilities that should really be authorized by the TPM owner, but that must operate in circumstances in which it is impossible to use the normal authorization mechanism (because the TPM doesn't have the owner's authorization value or because the platform can't perform the normal authentication method). The only choice, therefore, is to use some sort of physical interaction with the platform. Most of these physical presence interactions can be implemented in software, provided that the software likely can't be executed without a physical human presence at the platform. (The correct level of protection for these physical presence commands depends on the context in which the TP is used. A rogue cannot use physical presence commands to subvert the platform's trust mechanisms, but it can use them to mount a denial-of-service attack.) The exception to this general physical presence rule is one specific physical presence capability (a TPM “turn on” override), which is so privacy-critical that it must be impossible to operate it without physical presence. This particular capability will probably require physical operation of a switch or jumper inside a platform.

Access to using TPM functionality involves three other mechanisms: enabling a TPM, activating a TPM, and taking ownership of a TPM. These are discussed in this chapter. All five mechanisms (normal authorization, physical presence, enabling, activating, and taking ownership) combine to provide a rich variety of access control.

The remainder of this chapter introduces access controls approximately in the order that a typical customer will encounter them on taking delivery of a TP. A TP will probably be delivered without a TPM owner (because of privacy), but it cannot provide trust features until someone becomes the TPM owner. The platform could be delivered “ready for ownership,” but the customer might want to “turn off” the TPM. Or the platform could be delivered with the TPM “turned off,” but the customer wants to use TP facilities. So the first section describes the options of enabling and activating a TPM in a TP and enabling ownership of a TP. The second section describes physical presence controls, which are the only ways of controlling a TPM until an owner has been installed. The third section describes the process of taking ownership, after which the normal authorization mechanisms are active. The fourth section describes normal authorization, the choice of authorization values, and authorization protocols. Finally, this chapter briefly describes the actual TPM capabilities that implement all these features.