Skip to main content
main-content

Über dieses Buch

In this book the authors first describe the background of trusted platforms and trusted computing and speculate about the future. They then describe the technical features and architectures of trusted platforms from several different perspectives, finally explaining second-generation TPMs, including a technical description intended to supplement the Trusted Computing Group's TPM2 specifications. The intended audience is IT managers and engineers and graduate students in information security.

Inhaltsverzeichnis

Frontmatter

Chapter 1. Introduction

Abstract
This book is an introduction to Trusted Computing and next generation Trusted Platform Modules (TPM2.0). Concepts are repeated throughout this book, in an effort to make individual chapters more complete on their own, and enable readers with specific objectives to dip in and out of this book. This book starts by describing the background of Trusted Computing and trusted platforms, and speculating about the future of Trusted Computing and trusted platforms. It then describes the features and architecture of trusted platforms from several different perspectives. The second half of this book is devoted to a description of second generation Trusted Platform Modules, including a technical description that is intended to supplement the Trusted Computing Group’s TPM2.0 specifications “Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 00.96”. This book concludes with chapters written by experts in the TPM’s “Direct Anonymous Attestation” protocol and Trusted Virtualised Platforms.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 2. Futures for Trusted Computing

Abstract
Trusted virtualisation is anticipated to become the dominant form of Trusted Computing in PCs and servers because it enables isolation of applications, and simplifies determination of platforms’ trust and security properties. Trusted Computing can enable platforms to provide trusted services such as cryptographic erasure of data, negotiations for the supply of services, single-sign-on, and digital signatures. These provide greater confidence in the use of computer platforms. Nothing is free, however, and Trusted Computing is no exception: it requires a public key infrastructure and other infrastructure that is peculiar to Trusted Computing.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 3. Basics of Trusted Platforms

Abstract
Trusted Computing is constrained by legacy issues, customer expectations, legal matters, privacy, and disaster recovery. Many aspects of Trusted Computing come as no surprise to anyone versed in the art of information security: one must provide process isolation and can’t avoid certificates, authorisation or authentication; one must provide a good level of security, avoid global secrets, abide by the principle of separation of privilege, and deal with dictionary attacks. On the other hand, Trusted Computing is distinguished by concepts such as Roots of Trust, authenticated platform boot, platform attestation, and privacy-friendly platform identification and platform recognition. All types of trusted platform have a particular trusted platform lifecycle, from design to decommissioning.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 4. Trusted Platform Architecture

Abstract
All trusted platforms have some aspects in common. They require some form of excution isolation because that’s the only way to prevent a rogue application subverting another application. They need built-in trusted functions and credentials, because otherwise one can’t distinguish a rogue computing environment from a desired computing environment. All trusted platforms rely upon Roots of Trust that record platform integrity metrics in Platform Configuration Registers. This creates a chain of trust, which is a sophisticated form of auditing that allows verification that a platform’s state is the anticipated state. PCRs are built into Trusted Platform Modules, which are perhaps the most well-known component of Trusted Computing.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 5. TPM2 Requirements

Abstract
The design of TPM2.0 is dictated by a host of requirements and constraints. It is paramount that the use of Trusted Computing to protect a computer user’s data should continue to be controllable, and that Trusted Computing should continue to help protect privacy. At the same time, TPM2.0 must help protect platform services from attacks, be able to use a variety of cryptographic algorithms, and work when there is no local IT support desk. TPM2.0 must also be compatible with the plethora of types of modern computing platform, including virtualised platforms.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 6. TPM2 Operation

Abstract
Individual TPM2 commands are different to TPMv1.2 commands because they provide a choice of cryptographic algorithm, additional TPM authorisation methods, multiple Protected Storage hierarchies, TPM identities that are easier to use in PKIs, and more comprehensive attestation. Sets of TPM2 commands nevertheless provide the same overall functionality as sets of TPMv1.2 commands, and this chapter illustrates the command-set mapping from TPMv1.2 to TPM2. Perhaps the biggest differences from TPMv1.2 are that TPM2 is designed to be hosted by computer platforms that include at least one, preferably two, Trusted Computing Bases, and TPM2 includes functionality to help protect TCBs.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 7. Initialising TPM2

Abstract
TPM2 must be initialised before it can perform useful work. A significant amount of initialisation must be done by the manufacturer to fix what the host platform can do and how it will do it. Manufacturer initialisation includes providing certificates for the TPM and platform, installing and initialising the Trusted Computing Bases for controlling TPM2, setting up TPM2’s PCRs to match the type of host platform, and deciding whether critical TPM2 commands require multi-factor authorisation. Some initialisation must be done every time that a platform boots. This boot-time initialisation includes ensuring that a TCB does in fact control TPM2, verifying that TPM2 is operating properly, and recording boot-time (static) integrity metrics. Some types of platform also require run-time TPM2 initialisation (initialisation without rebooting the platform), where the platform records metrics of isolated computing environments that were created by the platform’s chip set.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 8. Managing TPM2

Abstract
TPM2 must be managed before it can perform useful work. First of all, management software must learn a particular TPM2’s properties, such as the cryptographic algorithms that it supports, what TPM commands it supports, and what TPM resources are available. A TPM2’s Protected Storage hierarchies require the most management effort because TPMs typically can’t store many keys, data, and authorisation sessions at one time. Management software must keep swapping keys, data, and sessions in and out of the TPM. Short-term caches don’t require a caller to keep providing authorisation, but long-term caches do. Management software must also manage the TPM’s response to dictionary attacks, manage any TPM audit that is required, and align the TPM’s clock to UTC.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 9. Accessing Keys and Data in TPM2

Abstract
Accessing keys and data in TPM2 requires the use of “names” that uniquely identify a key or piece of data, to ensure that commands operate upon the desired key or data. A TPM2 is a security device, so access to a key or piece of data requires authorisation. TPM2 provides HMAC authorisation sessions (similar to those provided by TPMv1.2) but also provides simpler “password” authorisation (for use when the path to the TPM is trusted) and provides more complex “policy” authorisation sessions (for when multi-factor authorisation, such as use of PCRs, is required).
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 10. Customer Configuration of TPM2 and Its Host Platform

Abstract
Depending on the type of host platform, the customer might be able to configure aspects of TPM2’s behaviour, such as whether a secondary Trusted Computing Base can use the TPM. A customer might be able to customise a TCB to determine whether Trusted Computing is used to protect the customer’s data and/or the customer’s network infrastructure, and the degree of platform anonymity that is provided. In some platforms, customers will be able to store small pieces of data in the TPM’s non-volatile storage, and will be able to add personal TPM endorsements. Customers must always manage the password used to reset the TPM’s response to dictionary attacks, and must customise TPM2 if they change the host platform’s secondary Trusted Computing Base.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 11. Starting to Use TPM2

Abstract
After all TPM2 initialisation has been done, TPM2 management processes are in place, and authorisation sessions are up and running, one can start to use the TPM2. At its simplest, one can use the TPM just to obtain random (non-deterministic) numbers, or use the TPM as if it were just cryptographic software. If one wants to use the TPM to store keys and small pieces of data, one can create Protected Storage hierarchies and populate them. One can protect keys and data by sealing them to desired platform configurations, use encryption keys for encrypting data in the host platform, and use signing keys for signing data in the host platform. One can also use signing keys to certify that other keys and data exist, to certify that certain TPM commands have been used, or to certify the platform’s current state.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 12. Direct Anonymous Attestation (DAA) in More Depth

Abstract
Direct Anonymous Attestation is TPM2’s method of providing mathematically-proven anonymity or pseudonymity for signing keys in trusted platforms. The simple explanation of how DAA works is that it has a single verification (public) key but a plethora of signing (private) keys. One cannot tell which of many platforms created the signature. This chapter provides a more thorough explanation and enables one to understand (amongst other things) why one can’t tell whether two anonymous DAA signatures were created under the same private key, but can tell whether two pseudonymous DAA signatures were created under the same private key. This chapter is intended for readers with a background or interest in mathematics and/or cryptography.
Graeme Proudler, Liqun Chen, Chris Dalton

Chapter 13. Machine Virtualisation, Virtual Machines, and TPMs

Abstract
This chapter provides some background to the concept of trusted virtualisation because, while virtualisation is not essential when implementing a trusted platform, the authors anticipate that it will become the dominant implementation of Trusted Computing in PCs, if nothing else. The main benefit of virtualisation for Trusted Computing is that it can provide process isolation. This is critical for security because one must be able to prevent a rogue software process from interfering with another software process. Trusted virtualisation depends on a hypervisor running as the lowest layer (most privileged layer) of software. The hypervisor can both use the TPM to protect the hypervisor, and use the TPM to help protect the platform.
Graeme Proudler, Liqun Chen, Chris Dalton

Backmatter

Weitere Informationen

Premium Partner

    Bildnachweise