Enabling, Activating, and Owning a TPM
The justification for three separate controls or flags (Enable, Activate, and Ownership) is not immediately obvious. A good way to introduce them is to distinguish between the situation in which a TPM doesn't have an owner and the situation in which a TPM does have an owner. Enable and Activate are useful both with and without a TPM owner, whereas Ownership governs attempts to become a TPM's owner and has no effect after a TPM owner has been established:
If a TPM does not yet have an owner, these controls have the following status:
- Enable-OFF is a master control that prevents any remote attempt whatsoever to become a TPM's owner. The strength of the Enable-OFF control lies in the fact that the Enable flag is asserted at the TPM by hardware. The downside is that resetting the value of the Enable flag to Enable-ON is probably inconvenient, because changes probably cannot be done via a computer's normal controls.
- The Ownership control should be used instead of Enable if absolute reassurance is unnecessary when stopping remote attempts to become a TPM's owner. The Ownership control is intended to be more convenient than the Enable control, so the Ownership control can be changed using a computer's normal controls (a keyboard, for example). The Ownership mechanism is obstructive rather than absolute (it isn't guaranteed to prevent remote access).
- The Activate control is designed for use in conjunction with the Ownership control to prevent an obscure attack where a remote rogue manages to take ownership of a platform just before the genuine owner. Its use in taking ownership is probably unnecessary in many situations. Without an Activate control, the genuine owner who intends to take ownership must set Ownership-ON, but rogue software could then take ownership of the TPM before the genuine owner, and immediately use the full range of TPM functions. Using the Activate control, the genuine owner can turn on the take ownership process (Ownership-ON, Activate-OFF), execute the process of taking ownership, and then turn on the remaining TPM functions (Activate-ON). This permits an owner to verify that he is the TPM owner before turning on the remaining TPM functions. The Activate control has strength similar to Ownership: It is designed to be convenient to use and obstructive (it is not guaranteed to prevent remote access).
After a TPM has an owner, these controls have the following status:
- Enable can be used by anyone with physical access to turn the TPM on or off at will. The TPM owner can cryptographically authorize Enable to (locally or remotely) turn the TPM on or off at will. It is impossible to subvert physical access mechanisms to remotely use Enable to turn on a TPM. There is less protection (in theory, but probably not in practice) against using physical access mechanisms to use Enable remotely to turn off a TPM.
- Activate can be used by anyone with physical access to turn off a TPM for entire boot cycles, and it can be used by any software to turn off a TPM for the remainder of a boot cycle. This maintains the privacy of any user of a TP, at the expense of exposing another denial-of-service attack.
The detailed properties of Enable, Activate, and Ownership are as follows:
Enable is implemented with a single non-volatile TPM flag, whose value is changed by a TPM owner authorized command or by physical presence commands (authorization is discussed later in this chapter). Enable can repeatedly be turned on and off by TPM owner (cryptographically) authorized commands or physical presence commands, and the effects of both methods persist between boot cycles. When Enable is on (Enable-ON), the TPM is permitted to operate as normal, even after a period of Enable-OFF in the current boot cycle. When Enable is off (Enable-OFF), all of the “real work” TPM functions are blocked, apart from tracking of PCR values, so that the TPM always has an accurate record of the platform's state. The TPM owner authorized command permits remote control of Enable as soon as an owner has been installed in a TPM. The physical presence commands permit the TPM to be turned on or off even before an owner has been installed. Turning on a TPM can't be subverted by software.
Activate is implemented with a volatile TPM flag, whose value can be set at any time, by anyone, to Activate-OFF. Activate can be turned off (Activate-OFF) without authorization, will remain Activate-OFF until the next boot cycle, and can be kept off over multiple boot cycles by physical presence commands. Activate-OFF prevents the TPM from operating for the remainder of a boot cycle. Activate can be considered to be the same as Enable except that (1) Activate-OFF persists at least until the end of the current boot cycle and (2) taking ownership of the TPM is permitted. At TPM switch-on, Activate is set to the same value as a non-volatile shadow flag (shadow-activate), whose value is changed by physical presence commands.
Ownership is implemented with a single non-volatile TPM flag, whose value is changed by physical presence commands. Ownership can be repeatedly turned on (Ownership-ON) and off (Ownership-OFF) by physical presence commands whose effect persists between boot cycles. Ownership-ON permits the process of taking ownership of a TPM. Ownership-OFF will stop the process of taking ownership of a TPM (and has no effect if a TPM has an owner). The physical presence commands permit the taking of ownership to be turned on or off before an owner has been installed.
Tables 4-1 and 4-2 summarize the effects of these controls:
| Enable | Shadow Activate | Ownership | Privacy/Security Guard Mechanisms in Place |
|---|---|---|---|
| on | on | on | None (but the TPM's endorsement key still provides some protection; see the following section “TPM Ownership”) |
| – | – | off | Obstruct local and remote taking of ownership |
| – | off | – | Obstruct local and remote turn on of TPM |
| off | – | – | Prevent remote turn on of TPM and taking of ownership. Obstruct local turn on of TPM and taking of ownership. |
| Enable | Activate | Shadow Activate | TPM State now | TPM state next boot cycle |
|---|---|---|---|---|
| on | on | on | working | working |
| on | on | off | working | off for entire boot cycle |
| on | off | on | off for entire boot cycle | working |
| – | off | off | off for entire boot cycle | off for entire boot cycle |
| off | on | on | off | off |
| off | on | off | off | off for entire boot cycle |
| off | off | on | off for entire boot cycle | off |
It should be noted that, even when off, the TPM always reports its capabilities and performs self-tests. This is because such information is not considered sensitive and might be essential in deciding whether to turn on a TPM.
Demonstrating Privilege
The common method for proving sufficient privilege to execute a capability is to send cryptographically authorized commands to the TPM. This method implicitly demonstrates privilege. It can be used either locally or remotely (and is described in great detail later in this chapter).
There is, however, a need to demonstrate privilege without use of cryptographic authorization. One drawback of cryptographically authorized commands is that the host platform must have sufficient processing ability to receive the authorization data and present it to the TPM. But this isn't always the case; in a PC, for example, the platform has limited capabilities until the OS has booted. Another drawback is that some controls must operate when there is no TPM owner or when the TPM owner isn't available. Hence, there is a need for alternative methods of demonstrating privilege.
Physical presence is the method used when proof of owner privilege is required but cryptographic authorization is unavailable. The commands that use physical presence are those that control a TPM before an owner has been installed, or when the owner has lost his crypto authorization information, or when the host platform cannot pass crypto authorization to the TPM (for whatever reason). Physical access to a platform implicitly demonstrates privilege, but complete confidence that access was physical is likely to be (financially) expensive to provide because of the need for dedicated controls. Such expense is counter to the spirit of TCPA, so the TCPA specification compromises with a best-effort verification (rather than uncompromising verification) of physical presence at the platform. The compromise permits the use of software processes to prove physical presence, even though there is always a possibility that such software processes can be subverted remotely.
In a PC, physical presence commands will probably be provided during the Power-On Self-Test (POST) sequence during the boot process. This is a natural and convenient time for the user of a PC to perform physical presence functions, it is cheap because it could use the normal keyboard, and it proves physical presence because keys on the keyboard must be pressed. Although it is possible that remote or rogue software can operate during the POST period, the platform can be designed to minimize that probability. All that remains is to notify a TPM when the POST period has finished, to make it ignore any further physical presence commands. Of course, nothing prevents a PC manufacturer from implementing physical presence commands in a way that completely prevents remote operation in all circumstances, but such implementations are unlikely because of their cost.
Only one command—the command for physically enabling a TPM—is an exception to the best-effort physical presence rule. Turning on a TPM is so privacy-sensitive that the TCPA specification mandates full protection for this one specific command, no ifs, buts, or maybes. The capability TPM_PhysicalEnable must be implemented in such a way that it cannot be subverted by software. This does not prevent the involvement of software when generating a TPM_PhysicalEnable command, but it probably means that TPM_PhysicalEnable will involve a physical switch, electrically connected to the TPM. In a PC, this switch will probably be implemented as a motherboard jumper, both to reduce costs and to discourage casual operation. In one switch position, the software command TPM_PhysicalEnable is permitted to operate. In the other switch position, the software command TPM_PhysicalEnable will fail.
Some commands don't demonstrate any privilege at all. These commands operate capabilities that don't use private data. The main examples are the self-test commands (which test that the TPM is operational) and the capability commands (which report the generic capabilities of a TPM).
Only one command doesn't demonstrate any privilege, yet it performs an operation that is arguably sensitive. That is the command TPM_SetTempDeactivated, which can be used by anyone at anytime without authorization. It turns off the TPM, but only until the next time that the platform is booted. A command of this type is necessary to maintain the privacy of the arbitrary user who doesn't want the TPM to operate—for example, to prevent the platform from identifying itself to a remote party while the user is using it. Unfortunately, it causes a need for the inverse function: enabling an arbitrary user to turn on the TPM. Such a command is incompatible with the exclusive privilege of the TPM owner in this regard, so to avoid such a command, the temporal scope of TPM_SetTempDeactivated is limited to that of the current boot cycle.
The accompanying sidebar summarizes the techniques used to control a TPM.
TPM Ownership
This section discusses the notion of TPM ownership. Note that we use interchangeable terms when we talk about the owner of a TPM and the owner of the TP that contains this TPM. In Chapter 2, the high degree of control that the owner is given over his TP has already been highlighted. Here we describe how TPM functionality becomes available only through an active opt-in decision of the TPM owner. We also briefly list the capabilities that give a TPM owner control over the platform's behavior.
For details of owner responsibility in TP migration and maintenance processes, see Chapter 8.
The Concept of TPM Ownership
The TPM owner has exclusive access to TPM capabilities that initialize the TPM and capabilities that control important aspects of TPM operation. The real TPM capabilities won't operate unless the TPM has an owner, and even then a user can't use instances of those capabilities unless the TPM owner has passed some degree of control to that user. Critically, a TPM will never obtain a TPM identity (see Chapter 5) without explicit cooperation of the TPM owner.
When a TP is shipped to a customer, its default state is to have no owner. When a TPM doesn't have an owner, it discards all secrets that may have been installed by any previous owner, and it waits for someone to take ownership. A TPM is designed to accept only one owner at any given time. Therefore, in order to use the TPM and to prevent someone else from taking ownership, a prospective TPM owner should take ownership as soon as he can. The proper owner could then withhold the authorization information that is necessary to use the TPM. Because a TPM can have only one owner, this prevents any use of the TPM until the proper owner is ready.
The process of taking ownership inserts a secret into the TPM. This secret is shared between the owner and the TPM, and for all future operations, proof of knowledge of the shared secret is proof of ownership. When the owner wishes to perform an owner operation (i.e., one that requires ownership authorization), the owner must use an authorization protocol to prove knowledge of the shared owner's secret. These authorization protocols are introduced in a later section in this chapter.
The previous section of this chapter introduced the Enable and Ownership functions that are used to obstruct and prevent various types of attempts to take ownership of a TPM. Even when these controls are fully enabled, a further barrier is that a prospective owner must know the public endorsement key (defined in Chapter 5) of the target TPM. The prospective owner must encrypt the owner's authorization data under the public endorsement key of the target TPM and send it to the TPM. This alone provides a high degree of protection against rogues trawling a network for TPMs that are enabled for remote ownership and opportunistically trying to become the owner. It also permits a prospective owner to take ownership remotely (over a network), because the owner's authorization data is rendered confidential by the encryption process. During the process of taking ownership, the prospective owner tells the TPM the type of cryptographic asymmetric key to create at the root of the hierarchy (which must be equivalent to a 2048-bit RSA key in cryptographic strength) used by the TPM to store protected data. For obvious reasons, this key is called the storage root key (SRK). The authorization secret for the SRK is sent to the TPM after being encrypted using the TPM's public endorsement key (just like the owner's authorization secret). This process causes the TPM to create a nonce, called tpmProof, that the TPM will use as the authorization secret for all non-migratable data created by that TPM. (This nonce is the TPM's only real method of checking that data really is non-migratable. The concepts of migratable and non-migratable keys and data are presented in Chapter 8.) The owner's authorization secret, the private part of the SRK, the SRK's authorization secret, and tpmProof are all kept by the TPM in protected non-volatile storage inside the TPM. The public part of the SRK is returned to the TPM owner.
At this stage, the TPM has an owner and will refuse to install another owner unless the current owner is uninstalled. (Removing an owner from the TPM is described in Chapter 9.) Only the TPM owner can use the TPM, because only the TPM owner knows the authorization secrets. If an entity other than the TPM owner is to use the TPM, the TPM owner can pass the SRK authorization secret to those entities, so that they can start to build a Protected Storage hierarchy. Alternatively, the TPM owner could create a hierarchy of TPM key objects and pass the keys' authorization secrets to the appropriate entities (people, software, or hardware components). These entities can, if they wish, change the values of authorization secrets and can even change them in a way that is guaranteed to conceal the new secret from a prying TPM owner (although this requires the cooperation of the TPM owner). Note, however, that the SRK authorization secret almost always must be known to all entities that use Protected Storage. This is because the SRK is the only Protected Storage key that the TPM guarantees to have in all conditions. (Protected Storage is described in more detail in Chapter 7.)
The TPM owner always retains exclusive control of some capabilities. Probably the most important is the privilege of creating TPM identities (described in Chapter 5), whose commands always require proof of TPM ownership. If a TPM owner wishes to give a TPM identity to a user, the TPM owner must create the identity and then pass the authorization secret to the user. As before, the user can change the value of an authorization secret if he wishes.
The other capabilities under exclusive control of the TPM owner include the following:
Writing a value to the data integrity registers (TPM_DirWriteAuth): The DIR contains a value used for verification that a boot process is proceeding according to plan.
Authorizing a migration key (TPM_AuthorizeMigrationKey): This permits the copying of migratable data in the Protected Storage hierarchy to other TPMs and other systems.
Preventing creation of a maintenance archive (TPM_KillMaintenanceFeature): This prevents the copying of non-migratable Protected Storage data to another TPM.
Uninstalling the TPM owner (TPM_OwnerClear): This enables an owner to remotely uninstall himself.
Preventing remote uninstallation of the TPM owner (TPM_DisableOwnerClear)
Reading the flags that describe the current state of the TPM (TPM_GetCapabilityOwner)
Setting the TPM capabilities that must be audited (TPM_SetOrdinalAuditStatus)
Preventing users from reading the public endorsement key (TPM_DisablePubekRead, see the privacy discussion in Chapter 1)
Using TPM owner privilege to read the public endorsement key (TPM_OwnerReadPubek)
Changing the authorization secret of the TPM owner or the SRK (TPM_ChangeAuthOwner)