Kenneth Goldman

Startup, Shutdown, and Provisioning

here is defined as software operations that occur each time a platform boots. The boot can be a cold boot, or it can be what in PC terms is called a resume from suspend or a boot from hibernate. The TPM holds several classes of volatile state, including PCR values, loaded sessions and keys, enables, authorization and policy values, hybrid NV indexes, and clock state. Based on the type of power cycle, this volatile state must either persist or be initialized. The TPM provides two commands that, in various combinations, permit external software to manage the power-cycle requirements.

Solving Bigger Problems with the TPM 2.0

Throughout this book, we have described examples of how you can use particular TPM commands in programs. This chapter looks at how some of those commands can be combined to create programs that use multiple features of the TPM. These ideas couldn’t be implemented easily with TPM 1.2, but TPM 2.0 has added features that make it easy to solve these problems.

TPM Software Stack

This book is primarily about TPM 2.0 devices. However, a TPM without software is like a car with a full tank of gas but no driver; it has great potential but isn’t going anywhere. This chapter, in preparation for the rest of the book, introduces you to the TPM’s “driver”, the TPM Software Stack (TSS). A good understanding of this topic will enable you to understand subsequent code examples in this book.

Extended Authorization (EA) Policies

TPM 2.0 has unified the way that all entities controlled by the TPM may be authorized. Earlier chapters have discussed authorization data used for passwords and HMAC authorization. This chapter goes into detail about one of the most useful new forms of authorization in the TPM, starting with a description of why this feature was added to the TPM and then describing in broad brushstrokes the multifaceted approach that was taken.

Platform Configuration Registers

Platform Configuration Registers (PCRs) are one of the essential features of a TPM. Their prime use case is to provide a method to cryptographically record (measure) software state: both the software running on a platform and configuration data used by that software. The PCR update calculation, called an , is a one-way hash so that measurements can’t be removed. These PCRs can then be read to report their state. They can also be signed to return a more secure report, called an (or quote). PCRs can also be used in an extended authorization policy to restrict the use of other objects.

Platform Security Technologies That Use TPM 2.0

Okay, we’ve written a whole book on TPMs, and you’ve apparently read the whole thing. Perhaps our attempts to keep the book interesting were successful…or you’re extraordinarily persistent…or maybe you just cheated and skipped to the conclusion.

Existing Applications That Use TPMs

Even though more than 1 billion TPMs are deployed in the market, and they exist on almost all commercial PCs and servers, very few people know about them. And many people who do know about TPMs are surprised to discover that many applications are written for them. There are also a large number of ways to easily write applications that take advantage of TPM 1.2 devices. Because TPM 2.0 devices are just beginning to appear on the market, it’s perhaps not surprising that not as many applications can use TPM 2.0 directly. The purpose of this book is to enable you to write programs that take advantage of all the features of TPM 2.0, both basic and advanced.

Authorizations and Sessions

Authorizations and sessions are among the most important concepts in TPM 2.0. Authorizations control access to entities in the TPM, providing many of the security guarantees of the TPM. Sessions are the vehicle for authorizations and maintain state between subsequent commands; additionally, sessions configure some per-command attributes such as encryption and decryption of command and response parameters and auditing. This chapter describes sessions as they relate to authorization of actions on entities. Chapters 16 and 17 describe details of the per-command session use modifiers.

Auditing TPM Commands

As used in the TPM, audit is the process of logging TPM command and response parameters that pass between the host and the TPM. The host is responsible for maintaining the log, which may be in host memory or on disk. An auditor can later use the TPM to attest to the log’s integrity (that it has not been altered) and authenticity (that it was logging TPM transactions).