TPM Fundamentals

發行項
10/27/2013

Applies To: Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2

This topic for the IT professional provides a description of the components of the Trusted Platform Module (TPM 1.2 and TPM 2.0) and explains how they are used to mitigate dictionary attacks.

A Trusted Platform Module (TPM) is a microchip designed to provide basic security-related functions, primarily involving encryption keys. The TPM is usually installed on the motherboard of a computer, and it communicates with the remainder of the system by using a hardware bus.

Computers that incorporate a TPM can create cryptographic keys and encrypt them so that they can only be decrypted by the TPM. This process, often called wrapping or binding a key, can help protect the key from disclosure. Each TPM has a master wrapping key, called the storage root key, which is stored within the TPM itself. The private portion of a storage root key or endorsement key that is created in a TPM is never exposed to any other component, software, process, or user.

You can specify whether encryption keys that are created by the TPM can be migrated or not. If you specify that they can be migrated, the public and private portions of the key can be exposed to other components, software, processes, or users. If you specify that encryption keys cannot be migrated, the private portion of the key is never exposed outside the TPM.

Computers that incorporate a TPM can also create a key that has not only been wrapped, but is also tied to certain platform measurements. This type of key can be unwrapped only when those platform measurements have the same values that they had when the key was created. This process is referred to as “sealing the key to the TPM.” Decrypting the key is called unsealing. The TPM can also seal and unseal data that is generated outside the TPM. With this sealed key and software (such as BitLocker Drive Encryption), you can lock data until specific hardware or software conditions are met.

With a TPM, private portions of key pairs are kept separate from the memory that is controlled by the operating system. Keys can be sealed to the TPM, and certain assurances about the state of a system (assurances that define the trustworthiness of a system) can be made before the keys are unsealed and released for use. Because the TPM uses its own internal firmware and logic circuits to process instructions, it does not rely on the operating system, and it is not exposed to vulnerabilities that might exist in the operating system or application software.

For information about which versions of Windows support which versions of the TPM, see Supported versions. The features that are available in the versions are defined in specifications by the Trusted Computing Group (TCG). For more information, see the Trusted Platform Module page on the Trusted Computing Group website: Trusted Platform Module.

The following sections provide an overview of the technologies that support the TPM:

Physical presence interface
States of existence in a TPM
Endorsement keys
Key attestation
How the TPM mitigates dictionary attacks

The following topic describes the Trusted Platform Module (TPM) Services that can be controlled centrally by using Group Policy settings:

Trusted Platform Module Services Group Policy Settings

Physical presence interface

The Trusted Computing Group (TCG) specifications for TPMs require physical presence to perform some TPM administrative functions, such as turning on and turning off the TPM. Physical presence means a person must physically interact with the system and the TPM interface to confirm or reject changes to TPM status. This typically cannot be automated with scripts or other automation tools unless the individual OEM supplies them. Following are examples of TPM administrative tasks that require physical presence:

Activating the TPM
Clearing the existing owner information from the TPM without the owner’s password
Deactivating the TPM
Disabling the TPM temporarily without the owner’s password

States of existence in a TPM

For each of these Trusted Platform Module 1.2 states of existence, the TPM can transition into another state (for example, moving from disabled to enabled). The states are not exclusive.

These states of existence do not apply for Trusted Platform Module 2.0 because it cannot be turned off from within the operating system environment.

State	Description
Enabled	Most features of the TPM are available. The TPM can be enabled and disabled multiple times within a boot period, if ownership is taken.
Disabled	The TPM restricts most operations. Exceptions include the ability to report TPM capabilities, extend and reset Platform Configuration Register (PCR) functions, and perform hashing and basic initialization. The TPM can be enabled and disabled multiple times within a start-up period.
Activated	Most features of the TPM are available. The TPM can be activated and deactivated only through physical presence, which requires a restart.
Deactivated	Similar to the disabled state, with the exception that ownership can be taken when the TPM is deactivated and enabled. The TPM can be activated and deactivated only through physical presence, which requires a restart.
Owned	Most features of the TPM are available. The TPM has an endorsement key and storage root key, and the owner knows information about owner authorization data.
Unowned	The TPM does not have a storage root key, and it may or may not have an endorsement key.

Important

Applications cannot use the TPM until the state is enabled, activated, and owned. All operations are available only when the TPM is in this state.

The state of the TPM exists independently of the computer’s operating system. When the TPM is enabled, activated, and owned, the state of the TPM is preserved if the operating system is reinstalled.

Endorsement keys

For a TPM to be usable by a trusted application, it must contain an endorsement key, which is an RSA key pair. The private half of the key pair is held inside the TPM, and it is never revealed or accessible outside the TPM. If the TPM does not contain an endorsement key, the application might cause the TPM to generate one automatically as part of the setup.

An endorsement key can be created at various points in the TPM’s lifecycle, but it needs to be created only once for the lifetime of the TPM. The existence of an endorsement key is a requirement before TPM ownership can be taken.

Key attestation

Introduced in Windows Server 2012 R2 and Windows 8.1, TPM key attestation allows a certification authority to verify that a private key is actually protected by a TPM and that the TPM is one that the certification authority trusts. Endorsement keys which have been proven valid can be used to bind the user identity to a device. Moreover, the user certificate with a TPM attested key provides higher security assurance backed up by the non-exportability, anti-hammering, and isolation of keys provided by a TPM.

How the TPM mitigates dictionary attacks

When a TPM processes a command, it does so in a protected environment, for example, a dedicated microcontroller on a discrete chip or a special hardware-protected mode on the main CPU. A TPM can be used to create a cryptographic key that is not disclosed outside the TPM, but is able to be used in the TPM after the correct authorization value is provided.

TPMs have dictionary attack logic that is designed to prevent brute force attacks that attempt to determine authorization values for using a key. The basic approach is for the TPM to allow only a limited number of authorization failures before it prevents more attempts to use keys and locks. Providing a failure count for individual keys is not technically practical, so TPMs have a global lockout when too many authorization failures occur.

Because many entities can use the TPM, a single authorization success cannot reset the TPM’s dictionary attack logic. This prevents an attacker from creating a key with a known authorization value and then using it to reset the TPM’s dictionary attack logic. Generally TPMs are designed to forget about authorization failures after a period of time so the TPM does not enter a lockout state unnecessarily. A TPM owner password can be used to reset the TPM’s lockout logic.

TPM 2.0 dictionary attack behavior

TPM 2.0 has well defined dictionary attack logic behavior. This is in contrast to TPM 1.2 for which the dictionary attack logic was set by the manufacturer, and the logic varied widely throughout the industry.

Warning

For the purposes of this topic, Windows 8 Certified Hardware also pertains to Windows 8.1 systems. The following references to “Windows” include these supported Windows versions.

For Windows 8 Certified Hardware systems with TPM 2.0, the TPM is configured by Windows to lock after 32 authorization failures and to forget one authorization failure every two hours. This means that a user could quickly attempt to use a key with the wrong authorization value 32 times. For each of the 32 attempts, the TPM records if the authorization value was correct or not. This inadvertently causes the TPM to enter a locked state after 32 failed attempts.

Attempts to use a key with an authorization value for the next two hours would not return success or failure; instead the response indicates that the TPM is locked. After two hours, one authorization failure is forgotten and the number of authorization failures remembered by the TPM drops to 31, so the TPM leaves the locked state and returns to normal operation. With the correct authorization value, keys could be used normally if no authorization failures occur during the next two hours. If a period of 64 hours elapses with no authorization failures, the TPM does not remember any authorization failures, and 32 failed attempts could occur again.

Windows 8 Certification does not require TPM 2.0 systems to forget about authorization failures when the system is fully powered off or when the system has hibernated. Windows does require that authorization failures are forgotten when the system is running normally, in a sleep mode, or in low power states other than off. If a Windows system with TPM 2.0 is locked, the TPM leaves lockout mode if the system is left on for two hours.

The dictionary attack logic for TPM 2.0 can be fully reset immediately by sending a reset lockout command to the TPM and providing the TPM owner password. By default, Windows automatically provisions TPM 2.0 and stores the TPM owner password for use by system administrators.

In some enterprise situations, the TPM owner authorization value is configured to be stored centrally in Active Directory, and it is not stored on the local system. An administrator can launch the TPM MMC and choose to reset the TPM lockout time. If the TPM owner password is stored locally, it is used to reset the lockout time. If the TPM owner password is not available on the local system, the administrator needs to provide it. If an administrator attempts to reset the TPM lockout state with the wrong TPM owner password, the TPM does not allow another attempt to reset the lockout state for 24 hours.

TPM 2.0 allows some keys to be created without an authorization value associated with them. These keys can be used when the TPM is locked. For example, BitLocker with a default TPM-only configuration is able to use a key in the TPM to start Windows, even when the TPM is locked.

Rationale behind the Windows 8.1 and Windows 8 defaults

Windows relies on the TPM 2.0 dictionary attack protection for multiple features. The defaults that are selected for Windows 8 balance trade-offs for different scenarios.

For example, when BitLocker is used with a TPM plus PIN configuration, it needs the number of PIN guesses to be limited over time. If the computer is lost, someone could make only 32 PIN guesses immediately, and then only one more guess every two hours. This totals about 4415 guesses per year. This makes a good standard for system administrators to determine how many PIN characters to use for BitLocker deployments.

The Windows TPM-based smart card, which is a virtual smart card, can be configured to allow sign in to the system. In contrast with physical smart cards, the sign-in process uses a TPM-based key with an authorization value. The following list shows the advantages of virtual smart cards:

Physical smart cards can enforce lockout for only the physical smart card PIN, and they can reset the lockout after the correct PIN is entered. With a virtual smart card, the TPM’s dictionary attack is not reset after a successful authentication. The allowed number of authorization failures before the TPM enters lockout includes many factors.
Hardware manufacturers and software developers have the option to use the security features of the TPM to meet their requirements.
The intent of selecting 32 failures as the lock-out threshold is so users rarely lock the TPM (even when learning to type new passwords or if they frequently lock and unlock their computers). If users lock the TPM, they must to wait two hours or use some other credential to sign in, such as a user name and password.