Microsoft Vista: Trusted Platform Module Services

Windows IT Pro

- Advertise

Microsoft Vista: Trusted Platform Module Services
View the book table of contents

Author:	Tony Piltzecker
Published:	February 2007
Copyright:	2007
Publisher:	Syngress Publishing

Solutions in this chapter:

Understanding the TPM
Configuring and Managing the TPM on a Stand-Alone System
Configuring and Managing the TPM in an Enterprise Environment
TPM Applications
Understanding the Security Implications of the TPM

INTRODUCTION

The Trusted Computing Group (TCG) was formed in 2003 with the goal of developing and promoting open standards for trusted computing. The group was founded by Advanced Micro Devices, Hewlett-Packard, IBM, Infineon, Intel, Lenovo, Microsoft, and Sun Microsystems, and currently has 135 members. The main product to come out of the TCG so far is the specification for the Trusted Platform Module (TPM), and the corresponding specification for the Trusted Computing Group Software Specification (TSS). The TPM is the key hardware component of a trusted computing platform and the TSS is the specification for an application program interface (API) that developers can use to create software that will interact with the TPM.

Windows Vista supports only version 1.2-compliant TPM devices natively, although third-party software, such as Wave’s Embassy Trust Suite, is available that you can use to support some functionality of version 1.1b TPM devices.Version 1.2 of the TPM specification from the TCG was published in October 2003, and has since been revised. In this chapter, we will cover only the native Windows Vista support for version 1.2 TPM devices. In 2006, PC OEMs started to make a big push to incorporate TPM version 1.2 devices into their products. Laptops seem to be on the leading edge of this new technological wave, with Dell, HP, and Lenovo cranking up production of laptops.

UNDERSTANDING THE TPM

The TPM is a microchip for motherboards that is designed to create, store, and protect cryptographic keys, and the fact that the TPM is integrated into motherboards allows it to be used as a tool for strong authentication of devices as well. The TCG intends for the TPM to be the foundation upon which secure computing platforms are built. Because the TPM is a dedicated piece of hardware that creates a master encryption key which can be used to encrypt other keys that are created by user mode applications, keys are separated from software vulnerabilities that would directly jeopardize the security of keys protected only by software. A key protected by software is susceptible to disclosure the moment a buffer overrun or some other flaw in the software code is discovered. Protecting encryption keys with a hardware device such as the TPM can be seen as a direct response to many of the most prevalent and serious security issues facing information security professionals today, including rising numbers of software vulnerabilities, theft of equipment containing sensitive data including personally identifiable information (PII), and identity theft.

NOTE: Personally identifiable information (PII) is any information that may be used to uniquely identify a person, such as a Social Security number (SSN), credit card numbers, a person’s health information (which the Health Insurance Portability and Accountability Act of 1996 [HIPAA] was enacted to protect), and the combination of a full name and address. It is critical to protect this information because it is useful to identity thieves.

However, cryptography is about more than just encrypting large amounts of data in order to keep it confidential. Cryptography is simply the process of taking a block of plain text and processing it to create cipher text. There are few limits as to what that plain text can be and what that cipher text can be used for. A lot of different applications for cryptography have been developed, including the following:

A cryptographic algorithm can be applied to a file (or set of files) in order to create a hash or message digest which serves as a fingerprint of the file(s). This function is widely used for gauging the integrity of data, and is critical to the field of forensics.
Digital signatures utilize public key cryptography and message digests in order to allow recipients to verify the integrity and authenticity of messages they receive.
Sensitive user data can be processed using cryptographic algorithms in order to protect the confidentiality of the data.

The TPM and Windows Vista TPM services use all of these functions to implement the functions they provide, and in doing so they also support users’ ability to securely utilize these cryptographic functions as well. Before getting into the technical details of how this works, we’ll look at what a trusted platform is, who developed such an idea, and where the TPM fits in.

Are You 0wned?

Has Anyone Seen My Laptop?

In 2006, we witnessed a parade of news stories in which employees lost laptops that contained PII or other sensitive data:

In April, Boeing announced that a laptop with PII of 3,600 of its employees had been stolen.
In May, a U.S. Department of Veterans Affairs employee’s laptop and external hard drive were stolen from his home. The laptop contained PII, including SSNs, on more than 26.5 million soldiers.
In June, Hotels.com announced that an auditor from Ernst & Young Global Ltd. had his laptop stolen, exposing the names, addresses, and credit card information of nearly one-quarter of a million Hotels.com customers to thieves.
In September, the U.S. Department of Commerce reported that 1,100 of its laptops were missing, and that 249 of the laptops contained PII.
In November, Kaiser Permanente notified 38,000 members that their personal health information had been compromised when an employee’s laptop was stolen out of his car.
In December, we heard from Boeing again. This time it announced that a laptop theft had compromised the personal information of 382,000 employees.

These are just a handful of the highest-profile data loss stories from 2006, and the list of headlines for 2007 should be long as well. Not only are companies and government agencies relying more than ever before on laptops to serve their workforce, but more smartphones and personal digital assistants (PDAs) are in use as well. Even the iPods those employees are listening to on their way to and from work can be used to transport files. The location of sensitive data has never been more fluid.

The return on investment for erecting firewalls, virtual private networks (VPNs), proxies, and other perimeter protection devices in order to secure the data that is inside our networks is diminishing. What we as security professionals need is a perimeter that is as mobile as our data. Encryption may be the only security perimeter that is actually capable of moving with that data, and provides a strong boundary between the data and the attacker. The TPM can help us build this new mobile perimeter by allowing us to use strong encryption while the cryptographic keys are protected in the TPM.

Trusted Platform Features

According to the TCG, a trusted platform must provide four features: protected capabilities, integrity monitoring, integrity storage, and integrity reporting. A trusted platform maintains certain storage locations, such as platform configuration registers (PCRs) and key storage slots in the TPM, where sensitive data is stored and processed. These locations may be accessed only by protected capabilities, which are the set of commands that are allowed to access and process the data.

The other three features of the trusted platform describe the system’s trustworthiness. For instance, we would like to know whether the system has been in a secure state, or whether it has allowed some subject to access objects in an unsupported manner. It is actually acceptable (although undesirable) for the system to enter an insecure state. However, it is unacceptable for the system to lie about the states it has been in. Integrity monitoring is the collection of data on the state of the system, and other metrics which define the trustworthiness of the system for us.

These metrics are used to make judgments concerning the system’s trustworthiness, so they must be adequately protected. The storage of integrity reporting measurements in protected locations is termed integrity storage. In addition to storing the actual data, integrity storage is used to store hashes of the integrity monitoring data. These hashes serve the same purpose as the hashes available with downloadable files and evidence collected for forensic analysis: They are used to ensure integrity of the data and they serve as proof that a third party has not tampered with the data. The metrics for integrity monitoring can be stored in a logfile, but the digests of the integrity monitoring data are stored in PCRs, which are volatile or nonvolatile data storage locations in the TPM itself. Integrity reporting is simply the process of vouching for the integrity of the data held in secure storage.

In the next section, you will see how the TCG trusted platform architecture supports and enables these features. It is important to understand how these features allow the trusted platform to start with a very small trust boundary that includes only a portion of the actual system. As the system loads, various pieces of code utilize these features to verify the integrity of other components in the system, and the trust boundary expands to include more and more portions of the system.

Trusted Platform Architecture

According to the TCG, the TPM is the base component of what it has labeled a trusted platform, which is a platform that provides users with a higher level of security than the traditional PC. When we discuss the TPM in this sense, we are discussing a somewhat abstract concept that is documented in specification materials developed by the TCG. However, the TPM is now also a part of real PCs.

Although the TCG is still in the process of developing the library of specifications which should be used together to form the trusted platform, we now have the real hardware for the TPM, Microsoft has implemented an operating system that provides a unified interface for the TPM in Windows Vista, applications within Windows Vista take advantage of the TPM, and we will soon see third-party applications that will run on the Windows Vista TSS and will take advantage of the TPM. Therefore, it is important to understand the TPM from two perspectives: We must look at it as a part of the architecture of the trusted platform as conceptualized by the TCG in its document, TCG Specification Architecture Overview: Specification Revision 1.2, found at www.trustedcomputinggroup.org/specs/IWG/TCG_1_0_Architecture_Overview.pdf; and we must understand how Microsoft has implemented these specifications by examining the TPM services architecture in Windows Vista.

First, we will look at the TCG trusted platform architecture. It is important to cover this architecture first in order to understand what a trusted platform is and how it works, and to see how the TPM fits into that. Also, Microsoft and computer manufacturers have not simply ripped the TPM from this trusted platform architecture and used it in isolation for some unintended purpose. They are taking the initial steps in trying to implement this evolving design for a secure PC. Once we understand the trusted platform from the perspective of the TCG, we will take a look at the blueprint for Windows Vista TPM services.

The TCG Trusted Platform
The trusted platform needs to have roots of trust, which are parts of the system that must be trusted and must enable, at a minimum, the ability to verify the trustworthiness of the rest of the system. Generally, three roots of trust are required: the root of trust for measurement (RTM); the root of trust for storage (RTS); and the root of trust for reporting (RTR). The RTM is actually the normal computing engine for the platform (generally the CPU in the case of a PC) while it is controlled by the core root of trust for measurement (CRTM), which is the set of instructions the computing engine executes in performing its trusted measurement duties. This set of instructions is supposed to be either a portion of the basic input/output system (BIOS) (the BIOS boot block) or the entire BIOS.

A key concept in discussing the trusted platform is the Trusted Building Block (TBB), which is nothing more than the CRTM and the TPM working together. These two components are physically present on the motherboard, and they must be immutable. Every time the system is reset or booted, the CRTM must have first control of the system. In other words, no code may be executed before the CRTM is executed. Following that, the CRTM may not hand off control to another component until it has measured that component to determine its trustworthiness.

NOTE: An object whose state cannot be modified after it is created is considered immutable.

This assumes that trusted mechanisms are being used to boot and run the platform. It is important to remember that the TCG has explicitly stated in its specifications that using the TPM is not mandatory. Users take advantage of the TPM and Windows Vista TPM services on an opt-in basis. This means if the user of the platform wants her system to load just like PCs have loaded in the past—where no trust assurance is provided—she can do that. She can leave the TPM disabled in the BIOS, and not take advantage of TPM functionality.

However, assuming she has enabled the TPM and wants to boot into an operating system on a more trustworthy platform, the boot process starts by loading the CRTM into the CPU and the CRTM begins executing. This must always be the first thing that occurs in a trusted platform following a system reset. All trust in the platform is derived from the TBB, so we have to be absolutely certain that every other piece of code the platform runs comes after the TBB. Otherwise, if a malicious piece of code is inserted into the chain of execution at the beginning, nothing else following it can be trusted.

The system reset loads the CRTM, and it begins executing. At this point, we have a trusted platform.We are at a base state. Only our TBB is functioning, and at this point it is actually the only part of the platform that we trust. All other code that is loaded and executed becomes trusted when the piece of code executing before it takes an integrity measurement of it. No piece of code is allowed to transfer control to another piece of code until it has determined that the code is trustworthy. Once the CRTM is running, we can see the rest of the boot process, as shown in Figure 4.1.

Here is an explanation of each step shown in Figure 4.1:

The CRTM takes integrity measurements of the remaining BIOS code. The measurements may be written to the Stored Measurement Log (SML) or recomputed whenever needed, and a digest of this measurement is created using the SHA-1 hashing algorithm. The SHA-1 digest is written to PCR[0].

If the CRTM determines that the measurement it has just taken is evidence of trustworthiness, it passes control of the platform to the remaining BIOS code.

The BIOS takes integrity measurements of the platform configuration settings, firmware code, and the code that loads the operating system (OS). The measurements may be written to the SML or recomputed whenever needed, and digests of these measurements are created using the SHA-1 hashing algorithm. The digests are written to the appropriate PCRs.

If the BIOS determines that the measurements it has just taken represent evidence of trustworthiness, it passes control of the platform to the remaining OS loader code.

Once the OS loader code executes, the next step is to pass control to the remainder of the OS. Before this can be done, the OS loader code must establish trust in the OS code. Trust measurements are taken against this code, and again, a digest is written to the appropriate PCR in the TPM.

If the OS loader trusts the remainder of the OS based, again, on trust measurements, it passes control to the remainder of the OS code.

Once the OS is loaded and running, it will control the TPM. However, at times, other applications will need to utilize the TPM. Before the OS can transfer control to an application, it must establish that the application code is trustworthy. It can do this just as it did previously: It takes integrity measurements on the application code and writes a digest to the TPM.

Once trust in the application has been established, the OS may transfer control over to it.

You can see by the preceding steps that all trust in the trusted computing platform is based upon the ability to trust the CRTM and TPM. All other trust in the system is derived or induced from this initial TBB. The trusted platform is indeed built upon this relationship between the CRTM and the TPM, so calling them the trusted building blocks is very appropriate. This fact also speaks to the importance of ensuring that the TPM and CRTM are immutable and physically secured to the platform. If we are to rely on the TBB to vouch for the platform’s trustworthiness, we must be sure that these two pieces are relatively impervious to modification. From this basis, the boundary of trust is extended to include more parts of the system. However, at any point during loading, if a piece of code does not pass muster during the integrity measurements, control is not transferred to that piece of code and the loading process stops.

Now that we understand how the trusted platform loads, we see the importance of the features of the trusted platform that we touched upon in the preceding section. Measurements are taken (integrity monitoring), they are stored in PCRs (integrity storage), the stored measurements must reliably be reported back to third parties that challenge the system’s trustworthiness (integrity reporting), and secure commands (protected capabilities) are used to carry out these operations.

The Physical TPM Interface
Now that we understand the importance of being able to rely upon the physical connection of the TPM to the motherboard as a key assumption for the TBB, it is worth noting the characteristics of that physical connection. The TPM should utilize a Low Pin Count (LPC) bus interface to the motherboard chipset, and a TPM-write cycle and TPM-read cycle should be provided to the TPM. Only the TPM can use these cycles, and the LPC bus must be protected from interference by other devices. Hardware manufacturers must implement these features. In addition, hardware manufacturers must implement secure firmware for the TPM, provide protection against dictionary attacks (often referred to as antihammering protections), and provide other countermeasures designed to combat hardware attacks.

Notes from the Underground...

As We Adapt, So Do the Attackers

As you read and learn about the powerful protection mechanisms that the TPM affords us, it is easy to be lulled into a false sense of security. Although the TPM allows us to avoid some vulnerabilities associated with software-only cryptographic solutions, this does not mean we are completely safe. It simply means that attackers will seek new avenues of attack. Many of these are more difficult and require more skill than what is currently required, though.

For a good briefing on penetration testing the TPM and Windows Vista TPM services, check out Doug MacIver’s presentation from Hack in the Box 2006, "Penetration Testing Windows Vista BitLocker Drive Encryption," available at http://packetstormsecurity.org/hitb06/DAY_2_-_Douglas_MacIver_-_Pentesting_BitLocker.pdf.

Binding, Sealing, and Attestation
So far, we have been able to gain an understanding of what a trusted platform is and how it loads.We understand the boot process, and the method by which successive parts of the platform are incorporated into the trust boundary. We can see that each piece of code that controls the platform must not relinquish control to another until it collects metrics on that code and brings it into the trust boundary. All of these are critical functions, yet at the same time many services are available to the user or user mode applications that rely on the TPM. These rely on the capability of the TPM to carry out binding, sealing, and attestation functions.

Binding is essentially the process of encrypting an encryption key. As an example, Microsoft’s BitLocker Drive Encryption must use a Volume Master Key (VMK), which encrypts the Full Volume Master Key (FVEK). The SRK, which is created when ownership of the TPM is taken and is stored in the TPM itself, is used to encrypt the VMK. This process is called binding or wrapping. Through binding or wrapping keys, users can be assured that the keys are secured even though they are not actually stored in the TPM, simply because the keys cannot be decrypted without a key that is stored in the TPM.

Sealing is the process of binding a key and tying it to certain platform characteristics. So, we know that binding is encrypting a key. Sealing goes one step further and associates the wrapped key to the state of the platform. For instance, it might check the software version, or it might check which versions of dynamic link libraries (DLLs) are loaded, and it will not unwrap the key it has sealed unless the platform has the same DLLs or software versions loaded.

Attestation is just a fancy name for the process of assuring that information is accurate. This is obviously a critical concept for the trusted platform, because as we have seen, all trust in the system is based on taking measurements and then checking those measurements. If the system cannot attest to the accuracy of that information, there can be no trust in the platform. An Attestation Identity Key (AIK) is a special 2,048-bit RSA key pair created and stored in the TPM that is used specifically for attestation. Numerous AIKs can be created after ownership of the TPM is taken, and they are used to digitally sign messages proving either the contents of the message or the authenticity of an entity (either a user or a platform). There are four types of attestation as far as the trusted platform is concerned:

Attestation by the TPM The TPM uses an AIK to digitally sign some data that is held within the TPM itself, proving that the TPM is active and can verify itself.
Attestation of the platform A set of PCRs are signed using an AIK so that the platform can report its integrity to a third party.
Attestation of the platform The platform proves it can be trusted to report its integrity measurements by providing the credentials that were used to create an AIK credential.
Authentication of the platform The platform uses a nonmigratable key, such as an AIK, to authenticate itself. This is strong device authentication.

Your Windows Vista PC
During the booting of a trusted computing platform based on Windows Vista, there is a point where the BIOS must transfer control to Windows Vista.We’ve covered the basics about what occurs before that transition and how the foundation of the trusted platform is established. We’re mainly concerned with what happens after that transition occurs.

Figure 4.2 shows the TBB and BIOS in relation to the Windows Vista architecture. The first thing worth noting is that the TSS sits atop the TPM driver and the TPM Base Services (TBS). The TPM driver is provided by the TPM manufacturer, the TBS is a component of Windows Vista, and the TSS is the implementation of the TCG specification of the TSS. So, the TCG has defined the specs for a component at the bottom of your trusted computing platform, the TPM, as well as a component toward the top, the TSS.

There are a few other important notes to consider with regard to the Windows Vista TPM architecture. It should not be surprising, but the TPM driver is required for the functioning of all other parts of the architecture above it. However, unlike most drivers, it is required before the OS loads because the OS loader needs to access the TPM if it is using a secure startup mechanism. Therefore, a TPM driver is also integrated into the BIOS code. Also, Microsoft has created the TBS in order to serve as a mediator between higher-level applications and the TPM driver, which is basically the TPM hardware itself, as far as these applications are concerned. Finally, for all non-Windows applications, the TSS provides a standard API for interacting with the TPM.

Currently, Windows Vista does not take integrity measurements of third-party applications, nor could it. Much like the BIOS, it is incumbent upon the third-party applications to provide measurements during a trusted state. If the applications could provide these metrics to Windows Vista, it can control whether those applications load depending on whether they have been corrupted, resulting in measurements that differ from the "trusted state" measurements. Any updates to these applications that would result in new integrity measurements need to be performed in a controlled manner, where this type of control of the application is shut off momentarily, the application code is updated, and then new measurements are provided. That being said, the 64-bit version of Windows Vista is providing this level of protection for some pieces of code which it can control. Given that this sort of integrity checking would break most 32-bit applications which were developed with no security mechanisms such as this in place, Code Integrity has been implemented in only the 64-bit version of Windows Vista to prevent breaking already existing 32-bit applications. Code Integrity utilizes the processes and architecture of the trusted platform we covered in the previous sections in order to enable the following features:

Verification of all drivers that are important to the boot process, including the Hardware Abstraction Layer (HAL) and the OS kernel, by the OS boot loader (which is now Winload)
Verification of the integrity of all code that executes in a protected process
Verification of the integrity of all kernel mode drivers
Verification of the integrity of all user mode binaries that employ cryptographic functions
Verification of the integrity of all user mode binaries that execute in a protected process used for high-definition media content
Verification of the integrity of the kernel code itself
Verification of the integrity of a specific set of user mode binaries

It is not too difficult to see how this Windows Vista architecture relates to the architecture we described when we talked about the more abstract features and functions of the TCG trusted platform. Let’s revisit the trusted platform loading process, but this time we’ll look specifically at our Windows Vista trusted platform (see Figure 4.3). Here is an explanation of each step shown in Figure 4.3:

The CRTM takes integrity measurements of the remaining BIOS code. The measurements may be written to the SML or recomputed whenever needed, and a digest of this measurement is created using the SHA-1 hashing algorithm. The SHA-1 digest is written to PCR[0].

If the CRTM determines that the measurement it has just taken is evidence of trustworthiness, it passes control of the platform to the remaining BIOS code.

The BIOS takes integrity measurements of the platform configuration settings, firmware code, and the MBR. The measurements may be written to the SML or recomputed whenever needed, and digests of these measurements are created using the SHA-1 hashing algorithm. The digests are written to the appropriate PCRs. See Table 4.1.

If the BIOS determines that the measurements it has just taken represent evidence of trustworthiness, it passes control of the platform to the Windows Vista boot manager, which performs its own integrity checks as part of the secure startup process.

Once BitLocker’s startup mechanism takes control, it takes integrity measurements of the New Technology File System (NTFS) boot sector and boot block, and it takes a measurement of the boot manager. These values are stored in PCRs 8 through 10, and PCR 11 is extended with a measurement after the VMK has been unsealed. BitLocker also looks back on the code that has already executed in a sense because the VMK it used for securing the drive has been sealed using PCRs 0, 2, and 4, in addition to 8 through 11.

So, once BitLocker’s secure startup process has established trust in the code that preceded it, as well as in the code to which it is about to pass control, it unseals the VMK and decrypts the drive before passing control to the NTOS kernel.

Once Windows Vista is loaded and running, it will be responsible for validating the integrity of code that is to run. It does this just as it did previously: It takes integrity measurements of the code, and if it finds an inconsistency when compared to previous measurements, it will not allow the code to load.

Once trust in the code is established,Windows Vista allows it to load.

The Role of the TBS
The TBS is designed to serve as the scheduler and the TPM resource controller in Windows Vista. The TPM has scarce resources, with only a handful of key slots and session slots in volatile storage, so it is necessary to virtualize these resources and to queue access to them. The TBS accepts commands from higher-level software, performs some validation checks, and then routes the commands down to the TPM through the TPM driver. The TBS may even need to mediate resource requests from multiple instances of the TSS. The process of calling down through the TBS for usage of TPM resources goes like this:

A function of the application that requires the TPM is called down through the TSS.

The TBS mediates the request and manages the TPM resource.

A trust measurement is made of the code that is requesting control.

If the measurement reflects a trustworthy piece of code, control is transferred to the application.

Once the request is processed, the result is returned to the application.

The TBS is then free to process the next job in the queue.

The TBS processes commands based on priority, not on a simple first in, first out stack. When a resource, such as key slots, for example, runs out, the TBS finds the least recently used key slot, saves the key, and then places the new request in the freed slot. If the application or service that had originally requested the slot was evicted, the TBS recognizes this and again makes a least recently used decision in order to free another slot.

One last point of note about TBS is that this component sits at the bottom of the user mode TPM architecture in Windows Vista. At the top of the kernel mode is the TPM driver. The connection between these two components is the conduit between user mode and kernel mode operation as far as TPM is concerned.

CONFIGURING AND MANAGING THE TPM ON A STAND-ALONE SYSTEM

Configuring the TPM consists of two basic tasks. First, you must i the TPM in the BIOS in order for Windows Vista to even recognize that the chip exists in your system. Second, you musti the TPM. During the initialization process, you set the TPM to on, which is the process by which Windows Vista starts the services provided by the TPM, and youi of the chip, which is the process of setting the TPM owner password. The Storage Root Key (SRK) is also created and stored in the TPM at this time. First, we will look at what relevant BIOS settings you need to be worried about, and then we’ll cover a few ways in which you can initialize the TPM within Windows.

Tools & Traps...

A TPM Term Quick Reference

As with any technical subject, it is impossible to communicate effectively and to understand the topic without first having a common language with which to communicate. The following is a quick reference of the terms commonly used in relation to TPM hardware and the TPM services within Windows Vista:

Enable This refers to the setting in the computer BIOS where you set the TPM chip to be made available to the operating system by the BIOS.
Disable This refers to the setting in the computer BIOS where you set the TPM chip to be made unavailable to the operating system by the BIOS.
Endorsement Key This is an encryption key that the manufacturer has embedded in the TPM chip. It is composed of a private and public key pair, with the private portion of the key never being exported outside of the TPM chip. This private key can be used to hash data in order to verify that the data can be trusted. The recipient of the data can use the public portion of the key to decrypt the data, and the recipient knows that only the TPM could have created the hash of the data. This plays an important part in the integrity monitoring, storage, and reporting functions we discussed earlier.
Storage Root Key The SRK is an encryption key that is created when you take ownership of the TPM, and it is stored in the TPM. When you clear the TPM this is erased, and when you take ownership of an already owned TPM it is replaced by a new SRK. The SRK is used as the master wrapping key. See the "Binding or Wrapping" entry, later in this list.
Take ownership Taking ownership of the TPM is simply the process of setting an owner password. Interestingly, access to the TPM is protected by only one-factor authentication. No username is required for authenticating to the TPM; only this ownership password. Effectively, anyone who knows the owner password is the TPM owner.
Initialize The TPM can be in four states: turned off and unowned; turned on and unowned; turned off and owned; or turned on and owned. When you first boot your Windows Vista system the TPM is turned off and unowned. Initializing the TPM is the process by which you turn on the TPM and take ownership of it.
Turn off Once the TPM is initialized, you may turn off the TPM without losing ownership information. Turning off the TPM simply allows you to stop using Windows Vista TPM services without losing ownership information.
Turn on If the TPM is currently in an off state you may turn the TPM on. Turning on the TPM provides access to Windows Vista TPM services. However, in order to use these services, you must have taken ownership of the TPM. If the TPM is already owned, turning it on allows the TPM services to function properly; if it is not already owned, you must take ownership of the TPM.
Clear When you clear the TPM you reset it back to its factorydefault state. It will be off and unowned. This function is available within Windows, and is sometimes also available in the computer BIOS.
Binding or wrapping Encryption keys that the user (or applications and services acting on behalf of the user) creates can be encrypted by the TPM and stored outside of the TPM. This process is called binding or wrapping the key. Any request for those keys must be made to the TPM, which can unbind/unwrap the key, but the private portion of the key is never exposed outside the TPM. The TPM uses the SRK to encrypt user keys.
Seal In addition to simply encrypting keys, the TPM can tie those keys to certain metrics concerning the state of the platform, such as what software is installed. The TPM can decrypt the key only if the state of the platform is the same. When a key is wrapped/bound in this way it is called sealing the key.
Attestation A trusted platform must be able to vouch for the accuracy and integrity of data. Attestation is the name for the process of vouching for data.

Configuring BIOS Settings

In order to use the TPM in Windows, as with most onboard hardware devices, you must enable it in the BIOS. We have been conducting tests on three different systems that contain a TPM chip, and some contain two BIOS settings that control the TPM. Your system should at least have a BIOS setting allowing you to enable or disable the TPM. This is a simple on or off function, like a light switch. If you leave this set to the Disable setting, the TPM chip is never made available to Windows. You will not see the chip in Device Manager. This setting must be set to Enable.

If you see a second setting concerning the TPM, it probably contains TPM options that can otherwise be controlled within Windows. One of the settings for this second TPM option usually allows you to clear the TPM, which erases all of the ownership information and cryptographic keys, including the SRK. It may also allow you to activate and deactivate the TPM. These settings are the equivalent of Turn TPM On and Turn TPM Off in the TPM Management Console. If this set of options is available to you, set the TPM to Activated here.

WARNING: When you are configuring the TPM in the BIOS, in tpm.msc, or through scripting, make sure you are careful. For instance, if you used Microsoft BitLocker Drive Encryption to protect a partition and you accidentally clear the TPM, you have just made it very difficult to get your data back. Even if you reinitialize the TPM using the same owner password, it will not contain the same SRK, and it is the SRK that encrypts the keys that were actually used to encrypt your data.

Using the TPM Microsoft Management Console

For anyone familiar with Microsoft Windows computers, the Microsoft Management Console (MMC) should be second nature. It should also be no surprise that Microsoft has built an MMC for configuring and managing the TPM. The consoles continue to be named with the .msc extension, thus invoking the TPM MMC is most handily done by opening the Run Dialog Box, typing tpm.msc, and then pressing Enter.

The TPM MMC has three panes. On the left are just two nodes: the TPM Management on Local Computer node and the Command Management node. When the TPM Management on Local Computer node is selected the center pane displays information specific to the TPM chip in the local computer, and the right pane displays the actions you can perform on the TPM chip, such as clearing the TPM, turning it on or off, and changing ownership of the TPM. Figure 4.4 shows this view of the TPM MMC.

The TPM Management on Local Computer node is very straightforward. You can perform five actions on the TPM from this node, and they are shown in the right pane. You can tell the state of the TPM by seeing which actions are grayed out and inaccessible. In Figure 4.4, it is apparent that the TPM is in a factory-default state because the only action available to us is Initialize TPM.

When the Command Management node is selected on the left, the full list of TPM commands is displayed in the center pane, and the command-related actions that may be performed are displayed in the right pane. Figure 4.5 shows this view of the TPM MMC.

Initializing the TPM
The first thing you need to do, before you can take advantage of any TPM-enabled applications, is to initialize the TPM. During the initialization process, you take ownership of the TPM. This means you create an owner password, and a hash of that password is stored in the TPM itself. This owner authorization hash value can also be stored in an XML file, and the credential is needed to perform many of the other TPM management functions, so you want to make sure that it is backed up somewhere. However, considering that this value is the key to getting into the TPM, it should be protected from disclosure. This means that you should not save it to a Universal Serial Bus (USB) device and then carry that USB device around in the same bag with your laptop.

In order to initialize the TPM, follow these steps:

Enter the BIOS and enable the TPM chip.

Click Start | All Programs | Accessories | Run.
Type tpm.msc and click OK.
Click Continue to allow the management console to open.
The TPM Management Console should open, displaying information about the installed TPM chip, as shown in Figure 4.4.
On the right side of the TPM Management Console, common TPM tasks will be listed, and because the TPM has not been initialized yet, all but the Initialize TPM task will be grayed out.
Click Initialize TPM . . . to start the Initialize the TPM Security Hardware Wizard. The first task is to create a TPM owner password. You will have the option of creating the password yourself, or having the password created automatically (the recommended option).
Create the TPM password

Automatically create the password (recommended)

Figure 4.6

Manually create the password option

Click Initialize.

After a moment, the wizard will finish and display a message notifying you that it has completed successfully, and that TPM-enabled applications may be used.

Whether you have Windows create the password for you or you create it yourself, you can always store the owner authorization value in a TPM file. Figure 4.7 shows a sample TPM file. Notice that the hash of the owner password is contained between the ownerAuth tags.

Turning the TPM On
You may turn on the TPM only if it is already in the off state, but you can complete the task regardless of whether you have the password. The following steps lead you through turning the TPM on when you have the password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Turn TPM On in the right pane.

When the first screen of the wizard is displayed, select I have a backup file with the TPM owner password if you have a TPM file with the password in it, or I want to type the TPM owner password if you want to type it in manually.

If you opted to type the password manually, the next screen of the wizard requires you to type in the password, and then you can click Turn TPM On. If you opted to load the password from a backup file, the next screen will allow you to type or browse to the location of the file, and then you can click Turn TPM On.

The wizard will turn off the TPM, and then close.

Use these steps in order to turn on the TPM if you have lost the password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Turn TPM On in the right pane.

The first screen of the wizard asks you to select whether you have the password in a TPM file, whether you will type it in manually, or whether you do not have the password at all. Select I do not have the TPM password.

The next screen of the wizard provides some basic instructions, as shown in Figure 4.8. You will need to click the Restart button in order to proceed.

When the machine restarts, right after the BIOS loads and before the Windows boot manager has control of the machine, you should see a message telling you that a request to change the TPM configuration has been received (see Figure 4.9). Select MODIFY and then press Enter to allow the machine to turn the TPM on, and the machine will finish booting.

NOTE: The message you see may be different from the one described in step 7 and shown in Figure 4.8. The BIOS produces this message for the specific platform upon receiving the input provided by the wizard we just ran from within Windows Vista. So, don’t expect your Lenovo ThinkPad to display exactly the same message, but it should provide basically the same information and options.

Turning the TPM Off
You may turn off the TPM only if it is already in the on state, but just like turning the TPM on, you can complete the task regardless of whether you have the password. The following steps lead you through turning the TPM off when you have the password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Turn TPM Off in the right pane.

When the first screen of the wizard is displayed, select I have a backup file with the TPM owner password if you have a TPM file with the password in it, or I want to type the TPM owner password if you want to type it in manually.

If you opted to type the password manually, the next screen of the wizard requires you to type in the password, and then you can click Turn TPM Off. If you opted to load the password from a backup file, the next screen will allow you to type or browse to the location of the file, and then you can click Turn TPM Off.

The wizard will turn off the TPM, and then close.

Follow these steps in order to turn off the TPM if you have lost the password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Turn TPM Off in the right pane.

The first screen of the wizard asks you to select whether you have the password in a TPM file, whether you will type it in manually, or whether you do not have the password at all. Select I do not have the TPM password.

The next screen of the wizard provides some basic instructions, as shown in Figure 4.10. You will need to click the Restart button in order to proceed.

When the machine restarts, right after the BIOS loads and before the Windows boot manager has control of the machine, you should see a message telling you that a request to change the TPM configuration has been received (see Figure 4.9 again, and read the note just below the graphic). Select MODIFY and then press Enter to allow the machine to turn the TPM on, and the machine will finish booting.

Clearing the TPM
You may clear the TPM only if it has already been initialized (enabled and an owner has been set), but as with the preceding two tasks, you can clear the TPM regardless of whether you have the password. The following steps lead you through clearing the TPM when you have the password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Clear TPM in the right pane.

When the first screen of the wizard is displayed, you will be presented with a justifiably menacing warning message, and options with regard to the TPM owner credentials (see Figure 4.11). Select I have a backup file with the TPM owner password if you have a TPM file with the password in it, or I want to type the TPM owner password if you want to type it in manually.

WARNING: Please take this warning seriously. If you do not have a backup of the keys created or protected by the TPM, any data encrypted with those keys is gone forever!
If you opted to type the password manually, the next screen of the wizard requires you to type in the password, and then you can click Clear TPM. If you opted to load the password from a backup file, the next screen will allow you to type or browse to the location of the file, and then you can click Clear TPM.

The wizard will clear the TPM, and then close.

Follow these steps in order to clear the TPM if you have lost the password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Clear TPM in the right pane.

The first screen of the wizard asks you to select whether you have the password in a TPM file, whether you will type it in manually, or whether you do not have the password at all. Select I do not have the TPM password.

The next screen of the wizard provides some basic instructions. You will need to click the Restart button in order to proceed.

When the machine restarts, right after the BIOS loads and before the Windows boot manager has control of the machine, you should see a message telling you that a request to change the TPM configuration has been received (see Figure 4.9). If you allow the machine to make the change, the TPM will be cleared and the machine will finish booting.

For each of the preceding tasks, you were allowed to perform the task without knowing the owner password. This may seem like a security flaw, but it is not. In order to perform these commands, the following must be true:

The machine booted successfully, meaning that initial integrity measurements were taken and found to be consistent.
If the machine uses any secure startup mechanism such as that which comes with BitLocker Drive Encryption, the system was able to verify the integrity of the boot volume, and the TPM successfully unsealed the key used to seal the volume.
The person logging on was required to present logon credentials to Windows Vista, and these credentials were valid.
The user that logged on had the appropriate permissions to run the TPM MMC.
The user was physically present at the system.

Based on these prerequisites,Windows Vista is trusting that it is safe to allow you to turn the TPM on or off or to clear it, even though you do not have the TPM owner credentials. In order for an attacker to use this to his advantage, he would have already had to steal your computer as well as your logon credentials. On top of that, if your computer was protected by a secure startup mechanism, he may have had to steal your PIN, USB storage device, or smart card as well. In addition, the attacker would be able to do nothing more than turn the TPM on, which would basically have no effect on you; turn it off, which would disable any TPM-dependent applications (you could remedy this easily by turning the TPM back on, and these applications would again function properly); or clear the TPM, resulting in a loss of the SRK which is required to access any data that was encrypted using the TPM.

Clearing the TPM has to be considered the worst-case scenario, given that it could lead to a loss of data. It does not provide the attacker with access to your data, though; he already has it by virtue of the fact that he is logged on to Windows. Furthermore, if you (or your organization, if we are discussing a scenario where this is part of an enterprise deployment) are using best practices procedures, you should have the BitLocker Drive Encryption keys backed up to a secure location stored away from the computer, and you can still perform emergency recovery procedures to get the data back.

Also, we should note here that in most cases, the system BIOS provides these functions. So, lacking the protections we mentioned in the five bullets shown earlier, an attacker can just access the BIOS and perform any of these functions much more easily than Windows is allowing him to. Even if you protect your BIOS with a password, this should be considered a much easier attack target than getting into Windows Vista and using the TPM MMC to perform these functions.

These three functions are executed using the SetPhysicalPresenceRequest method of the Win32_Tpm class, which is described in Table 4.3, later in this chapter. This means that the operation cannot be processed unless the user is present at the platform and authorizes the operation to complete. So, allowing you to turn the TPM on or off without the owner authorization value is not a security flaw. As we shall see in the next section, you are required to provide the owner authorization information in order to change the owner password. This function differs from the previous in that it:

Provides the attacker with full control of the TPM
Cannot be performed from outside the OS

Changing the Owner Password
Follow these steps to change the owner password:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the management console to open.

The TPM Management Console should open, displaying information about the installed TPM chip, as shown in Figure 4.12.

In the TPM Management Console, make sure you have the TPM Management on Local Computer node selected, and then click Change Owner Password in the right pane.

When the first screen of the wizard is displayed, select I have a backup file with the TPM owner password if you have a TPM file with the password in it, or I want to type the TPM owner password if you want to type it in manually.

If you opted to type the password manually, the next screen of the wizard requires you to type in the password, and then you can click Create New Password. If you opted to load the password from a backup file, the next screen will allow you to type or browse to the location of the file (see Figure 4.13), and then you can click Create New Password.

Create the TPM password.

If you select Automatically create the password (recommended), Windows will create a new, 40-character, all-numeric password. The password will be displayed as shown in Figure 4.2, and you will be required to save the SHA-1 hash of that password to a TPM file before the Change Owner Password Wizard can proceed. The Change Password button is grayed out until the file is saved.

If you choose the Manually create the password option, Windows will ask you to enter a password that is a minimum of eight characters. Using the manual password creation option, you are expected to remember the password, but you can save the authorization value (a hash of that password) to a TPM file if you wish.

Once the new owner authorization information has been saved, you can click the Change Password button to finish the process (see Figure 4.14).

Blocking and Allowing Commands
Blocking and allowing commands allows granular control over the secure operation of the TPM within your Windows Vista system. Currently, 125 commands are listed in the TPM MMC, and they are organized into 26 categories of functionality. Each is represented by an ordinal value, which is the value you will pass to the block and unblock functions.

There are three possible lists of blocked commands: the default list provided with Windows Vista; a list maintained on the local machine and managed by local administrators; and the list of commands controlled by Group Policy Objects (GPOs). If a TPM command exists in any of the lists, it will be blocked by the entity that controls command execution, the TBS. The TBS checks all three lists before passing the attempted command down to the TPM driver for processing. If the command exists in one of the lists, the TBS prevents the execution and returns an error to the service or application that sent the command.

The default list is evidenced by the fact that on a fresh Windows Vista install, some commands are already listed as blocked in the TPM MMC. In Figure 4.4, you can see that commands 152 (TPM_SaveState) and 153 (TPM_Startup) are blocked, but no administration of the command blocking list has occurred yet. Those are blocked by default.

There is more than meets the eye when it comes to the Command Management node in the TPM MMC. When you are managing the TPM on a system and you have these three lists to worry about, it can be difficult to figure out why a command is being blocked or allowed. Perhaps you’ve set the default block list to ignore (not recommended, by the way), but one command that you need to be able to use is still blocked. Instead of hunting down the lists in various places, you can use the TPM MMC to display which block list a command is on. To do that, follow these steps:

Click Start | All Programs | Accessories | Run.

Type tpm.msc and click OK.

Click Continue to allow the TPM MMC to open.

Select Command Management in the left pane.

Click View | Add/Remove Columns, as shown in Figure 4.15.

Use the Add/Remove Columns dialog box to add the On Default Block List, On Group Policy Block List, and On Local Block List columns, and remove any unwanted columns (here we have removed Category and Description), as shown in Figure 4.16.

Click OK and the Command Management node will appear as it does in Figure 4.17.

Now that we can actually see what commands are on which lists, let’s take a look at how you manage them. Commands that are on the default block list cannot be allowed through the TPM MMC unless you set the Local Computer Policy to ignore the default list. We would caution at this point that in a stand-alone system, the default block list should always be used. The commands are on the default list because they are either deprecated or can compromise privacy.

The Local Computer Policy contains four settings that are relevant to the TPM. You can find these settings in the Local Computer Policy\Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\ node, and the settings are described in Table 4.2. You can open the Local Computer Policy using the following steps:

Click Start | All Programs | Accessories | Run.

Type gpedit.msc and click OK.

Click Continue to allow the management console to open.

Because we are managing the TPM on a stand-alone system, we think the best practice for managing the TPM is to leave the default block list in place, and to use the local list to add other commands we may want to block. There is no reason to add another layer of confusion to the scenario by utilizing both the Group Policy list and the local list to set our own blocked commands. Also, because we are managing a stand-alone system, we do not have an Active Directory infrastructure to which we can back up the owner authorization credentials. So, basically the best method for managing the TPM is to leave all the Local Computer Policy settings in their default states, and to utilize only the TPM MMC to block and allow commands. Here is the easiest method for blocking/allowing commands within the MMC (these directions assume you already have the TPM MMC opened to the Command Management node):

Select the command you want to block/allow, as shown in Figure 4.18.

If the command is currently blocked and you want to allow it, click Allow Selected Command. If the command is currently allowed and you want to block it, click Block Selected Command.

If you blocked the command, the MMC will add the command to the local block list. If you allowed the command, the MMC will remove the command from the local block list. The new status will immediately be reflected in the MMC, as shown in Figure 4.19 (make note of the Status and On Local Block List columns for command 41).

NOTE: You’ll notice that in Figure 4.19, the command status displays as Blocked, but the icon shown is still the Allowed icon. If you click Refresh in the right pane, the icon is updated. Consider this a very minor bug in this prerelease of Windows Vista.

NOTE: If you enjoy doing things the hard way and need a way to really screw something up on your machine, you should know that the default block list, Group Policy block list, and local block list are stored in the Registry. You could avoid the ease of use the TPM MMC provides and edit the Registry, and risk deleting some critical Registry key in the process. You can find the default block list in HKEY_LOCAL_MACHINE\Software\Microsoft\Tpm\BlockedCommands\List. You can find the local block list at HKEY_LOCAL_MACHINE\Software\SYSTEM\ControlSet001\SharedAccess\Parameters\Tpm\ BlockedCommands\List. The Group Policy block list is stored in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Tpm\BlockedCommands\ List.

You have probably noticed that a Block New Command function is provided in the right pane as well. This does not provide the same functionality as the Block Selected Command function we just covered, and in fact, you cannot use it to block any of the commands listed in the TPM MMC at this point. All TPM commands agreed upon by the TCG at the time Vista is released are listed in the MMC, and you should block them as described earlier. However, hardware vendors may decide to implement commands that are not a part of the TPM specification, or the TCG may add new commands to the specification. Microsoft implemented the Block New Command function to provide coverage for both of these situations. In order to test the function, just pass it a number that does not correspond to a command that appears in the MMC, and the new command number will appear in the list. In Figure 4.20, you can see that we have blocked command 270.

Page: 1, 2

ADS BY GOOGLE