Windows 8 : Creating Trusted Platforms (part 1) - The Essentials, Management and Policies

Windows 8 includes the Encrypting File System (EFS) for encrypting files and folders. By using EFS, users can protect sensitive data so that it can be accessed only with their public key certificate. Encryption certificates are stored as part of the data in a user’s profile. So long as users have access to their profiles and the encryption keys they contain, they can access their encrypted files.

Although EFS offers excellent data protection, it doesn’t safeguard a computer from attack by someone who has direct physical access. In a situation in which a user loses a computer, a computer is stolen, or an attacker is logging on to a computer, EFS might not protect the data because the attacker might be able to gain access to the computer before it boots. He could then access the computer from another operating system and change the computer’s configuration. He might then be able to hack into a logon account on the original operating system and log on as the user, or configure the computer so that he can log on as a local administrator. Either way, the attacker could eventually gain full access to a computer and its data.

To seal a computer from physical attack and wrap it in an additional layer of protection, Windows 8 includes the TPM Services architecture. TPM Services protect a computer by using a dedicated hardware component called a TPM. A TPM is a microchip that is usually installed on the motherboard of a computer, where it communicates with the rest of the system by using a hardware bus. Computers running Windows 8 can use a TPM to provide enhanced protection for data, to ensure early validation of the boot file’s integrity, and to guarantee that a disk has not been tampered with while the operating system was offline.

A TPM has the ability to create cryptographic keys and encrypt them so that they can be decrypted only by the TPM. This process, referred to as wrapping or binding, protects the key from disclosure. A TPM has a master “wrapping” key called the Storage Root Key (SRK). The SRK is stored within the TPM to ensure that the private portion of the key is secure.

Computers that have a TPM can create a key that has been not only wrapped but sealed. The process of sealing the key ensures that the key is tied to specific platform measurements and can be unwrapped only when those platform measurements have the same values they had when the key was created. This is what gives TPM-equipped computers increased resistance to attack.

Because TPM stores private portions of key pairs separately from memory controlled by the operating system, keys can be sealed to the TPM to provide absolute assurances about the state of a system and its trustworthiness. TPM keys are unsealed only when the integrity of the system is intact. Further, because the TPM uses its own internal firmware and logic circuits for processing instructions, it does not rely on the operating system and is not subject to external software vulnerabilities.

The TPM can also be used to seal and unseal data that is generated outside the TPM, and this is where the true power of the TPM lies. In Windows 8, the feature that accesses the TPM and uses it to seal a computer is called BitLocker Drive Encryption. Although BitLocker Drive Encryption can be used in both TPM and non-TPM configurations, the most secure method is to use TPM.

When you use BitLocker Drive Encryption and a TPM to seal the boot manager and boot files of a computer, the boot manager and boot files can be unsealed only if they are unchanged since they were last sealed. This means that you can use the TPM to validate a computer’s boot files in the pre–operating system environment. When you seal a hard disk using TPM, the hard disk can be unsealed only if the data on the disk is unchanged since it was last sealed. This guarantees that a disk has not been tampered with while the operating system was offline.

When you use BitLocker Drive Encryption but do not use a TPM to seal the boot manager and boot files of a computer, TPM cannot be used to validate a computer’s boot files in the pre–operating system environment. This means that in this instance, there is no way to guarantee the integrity of the boot manager and boot files of a computer.

Windows 8 provides several tools for working with a TPM, including these:

To perform TPM management tasks on a local computer, you must be a member of the local computer’s Administrators group or be logged on as the local computer administrator. When you are working with Trusted Platform Module Management, you can determine the exact state of the TPM. If you try to start Trusted Platform Module Management without turning on TPM, you’ll see an error stating this. You’ll also see an error if you try to run the Initialize The TPM Security Hardware Wizard without turning on TPM.

Only when you’ve turned on TPM in firmware will you be able to perform management tasks with the TPM tools. When you are working with the Trusted Platform Module Management console, shown in Figure 1, you should note the TPM status and the TPM manufacturer information. The TPM status indicates the exact state of the TPM (see Table 1). The TPM manufacturer information shows whether the TPM supports specification version 1.2 or 2.0. Support for TPM version 1.2 or later is required.

Figure 1. Use the Trusted Platform Module Management console to initialize and manage TPM.

By default, Windows 8 and Windows Server 2012 store full TPM owner authorization information in the registry of the local computer. This significant change allows administrators of the local computer to perform TPM management tasks without having to provide the TPM owner password.

The Configure The Level Of TPM Owner Authorization Information Available To The Operating System policy controls the level of authorization information stored in the registry. This policy is found in the Administrative Templates policies for Computer Configuration under System\Trusted Platform Module Services. This policy has three enabled settings:

When this policy is set to Delegated or None, you’ll be prompted for the TPM owner password before you are able to perform most TPM administration tasks (see Figure 2).

With earlier releases of Windows, Microsoft recommended remotely storing the TPM owner authorization in Active Directory for domain-joined computers, which could be accomplished by enabling the Turn On TPM Backup To Active Directory Domain Services policy, extending schema for the directory, and setting appropriate access controls.

Figure 2. Supply the TPM owner password, if prompted for one.

Enabling backup to Active Directory changes the default way TPM owner information is stored. Specifically, when Turn On TPM Backup To Active Directory Domain Services is enabled and Configure The Level Of TPM Owner Authorization Information Available To The Operating System is disabled or not configured, only the TPM administrative delegation blob and the TPM user delegation blob are stored in the registry. Here, to store the full TPM owner information, you must use the enabled setting of Full (or disable Active Directory backup of the TPM owner authorization).

Related policies under System\Trusted Platform Module Services include:

These policies control the way command block lists are used and when lockout is triggered after multiple failed authorization attempts. An administrator can fully reset all lockout-related parameters in the Trusted Platform Module Management console. On the Action menu, tap or click Reset TPM Lockout. When the full TPM owner authorization is stored in the registry, you don’t need to provide the TPM owner password. Otherwise, follow the prompts to provide the owner password or select the file containing the TPM owner password.