|Author||David Challener and Will Arthur|
|File size||5.7 MB|
For your convenience Apress has placed some of the front
matter material after the index. Please use the Bookmarks
and Contents at a Glance links to access them.
Contents at a Glance
About the Authors��������������������������������������������������������������������������� xxi
About the Technical Reviewers���������������������������������������������������� xxiii
■■Chapter 1: History of the TPM�������������������������������������������������������� 1
■■Chapter 2: Basic Security Concepts����������������������������������������������� 7
■■Chapter 3: Quick Tutorial on TPM 2.0������������������������������������������� 23
■■Chapter 4: Existing Applications That Use TPMs�������������������������� 39
■■Chapter 5: Navigating the Specification��������������������������������������� 51
■■Chapter 6: Execution Environment����������������������������������������������� 71
■■Chapter 7: TPM Software Stack���������������������������������������������������� 77
■■Chapter 8: TPM Entities���������������������������������������������������������������� 97
■■Chapter 9: Hierarchies���������������������������������������������������������������� 105
■■Chapter 10: Keys������������������������������������������������������������������������ 119
■■Chapter 11: NV Indexes�������������������������������������������������������������� 137
■■Chapter 12: Platform Configuration Registers��������������������������� 151
■■Chapter 13: Authorizations and Sessions���������������������������������� 163
■■Chapter 14: Extended Authorization (EA) Policies���������������������� 217
■■Chapter 15: Key Management���������������������������������������������������� 249
■ Contents at a Glance
■■Chapter 16: Auditing TPM Commands���������������������������������������� 263
■■Chapter 17: Decrypt/Encrypt Sessions��������������������������������������� 271
■■Chapter 18: Context Management���������������������������������������������� 289
■■Chapter 19: Startup, Shutdown, and Provisioning��������������������� 301
■■Chapter 20: Debugging��������������������������������������������������������������� 311
■■Chapter 21: Solving Bigger Problems with the TPM 2.0������������ 323
■■Chapter 22: Platform Security Technologies
That Use TPM 2.0������������������������������������������������������������������������ 331
“Riveting! I couldn’t put it down until the last page.”
“I’m exhausted from reading this book! It kept me up three nights in a row. Where’s
my Ambien when I need it?”
“The suspense was killing me. I just had to read it straight through!”
Although these responses to our book would be gratifying, it’s doubtful that any book
on digital security will ever garner this type of reaction. Digital security is the computer
equivalent of disaster insurance. Few people care very much about it or give it much
thought, and everyone hates paying for it … until a catastrophe hits. Then we are either
really glad we had it or really sad that we didn’t have enough of it or didn’t have it at all.
We may sound like Chicken Little crying the “the sky is falling, the sky is falling,”
but mark our words: a digital security catastrophe is headed your way. We could quote
a plethora of statistics about the rising occurrence of digital security threats, but you’ve
probably heard them, and, quite frankly, you don’t care, or at least you don’t care enough.
It’s questionable whether any preaching on our part will make you care enough until
you’re personally impacted by such a calamity, but we’ll try anyway.
When your reputation is tarnished, your finances are impacted, your identity is
stolen, your physical well-being is threatened, your company’s reputation and finances
are harmed, and, quite possibly, your country is overthrown, then you’ll wake up to the
need for cyber security. But it might be too late then. Like people living in a flood zone,
the question isn’t whether the flood is coming, but rather when the disaster will hit and
whether you’ll be prepared for it. The time to buy digital-security flood insurance is now!
Don’t wait until the flood hits.
A Practical Guide to TPM 2.0 can be part of your digital-security insurance policy.
The TPM was designed as one of the core building blocks for digital security solutions. The
November 2013 “Report to the President: Immediate Opportunities for Strengthening the
Nation’s Cybersecurity” recommends “the universal adoption of the Trusted Platform
Module (TPM), an industry-standard microchip designed to provide basic securityrelated functions, primarily involving encryption keys, including for phones and tablets.”
Computers and devices that incorporate a TPM are able to create cryptographic keys and
encrypt them so they can be decrypted only by the TPM. A TPM provides this limited
but fundamental set of capabilities that higher layers of cybersecurity can then leverage.
Today, TPMs are present in many laptop and desktop personal computers. They’re used
by enterprises for tasks like secure disk encryption, but they have yet to be incorporated
to any significant extent in smartphones, game consoles, televisions, in-car computer
systems, and other computerized devices and industrial control systems. This needs to
happen for such devices to be trustworthy constituents of the increasingly interconnected
Our passion in writing this book is to empower and excite a rising generation of IT
managers, security architects, systems programmers, application developers, and average
users to use the TPM as the bedrock of increasingly sophisticated security solutions that
will stem the rising tide of threats that are being aimed at us, our employers, and our civil
institutions. Furthermore, the TPM is just plain cool. How many engineers, as children,
played with simple cryptography for fun? The ability to send an encrypted message to
a friend appeals to the secretive part of our human nature—the same part that enjoyed
playing spy games when we were young. And besides being fun, there’s something
inherently, morally right about protecting people’s assets from being stolen.
The TPM 2.0 technology can accomplish this. We believe in this technology and hope
to make believers of you, our readers, as well. Our hope is that you’ll get as excited about
this technology as we are and “go out and do wonderful things” with it, to paraphrase
Robert Noyce, one of Intel’s founders.
Why a Book?
Technical specifications are typically poor user manuals, and TPM 2.0 is no exception.
One reader of the specification claimed it was “security through incomprehensibility.”
Although the specification attempts to describe the functionality as clearly as possible,
its prime objective is to describe how a TPM should work, not how it should be used. It’s
written for implementers of TPMs, not for application writers using TPMs.
Also, for better or for worse, the detailed operations of the TPM commands are
specified in C source code. The structures are defined with various keywords and
decorations that permit the Word document to be parsed into a C header file. Microsoft
agreed with TCG that the source code in the specification would have an open source
license and could be used to implement a TPM. However, although C can describe
actions very precisely, even the best code isn’t as readable as text. One of the major
purposes of this book is to interpret the specification into language that is more
understandable to average software developers, especially those who need to understand
the low-level details of the specification.
Many readers don’t need to understand the detailed operation of the TPM and
just want to know how to use the various functions. These readers expect TSS (the TCG
software stack) middleware to handle the low-level details. They’re interested in how to
use the new TPM features to accomplish innovative security functions. Thus, this book is
just as concerned with describing how the TPM can be used as it is with explaining how
it works. Throughout the book, as features are described, use cases for those features are
interwoven. The use cases aren’t complete—they describe what the TPM 2.0 specification
writers were thinking about when those features were designed, but the specification is so
rich that it should be possible to implement many things beyond these use cases.
In writing this book, we’re trying to reach a broad audience of readers: low-level
embedded system developers, driver developers, application developers, security
architects, engineering managers, and even non-technical users of security applications.
We hope to encourage the broadest possible adoption and use of TPMs.
Non-technical readers will want to focus on the introductory material, including
the history of the TPM (Chapter 1), basic security concepts (Chapter 2), and existing
applications that use TPMs (Chapter 4). Visionaries who know what they want to
accomplish but aren’t themselves programmers will also benefit from reading these
chapters, because knowing the basic ways in which TPMs can be used may provide
inspiration for new use cases.
Engineering managers, depending on their needs and technical expertise, can go
as deep as they need to or want to. We hope that executives will read the book, see the
possibilities provided by TPMs, and subsequently fund TPM-related projects. When they
realize, for example, that it’s possible for an IT organization to cryptographically identify
all of its machines before allowing them onto a network, that true random number
generators are available to help seed OSs’ “get random number” functions, and that
weaker passwords can be made stronger using the anti-dictionary-attack protections
inherent in the TPM design, they may decide (and we hope they will) to make these
features easily available to everyday people.
Security architects definitely need to understand the functions provided by TPM 2.0
and, depending on the applications being developed, dive deep into how the TPM works
in order to understand the security guarantees provided. Linking disparate machines or
different functions to provide trusted software and networks should be possible using
TPM functionality as security architects get creative. Commercial availability of this
capability is long overdue.
Application developers, both architects and implementers, are a significant focus
of this book. These readers need to understand the TPM from a high-level viewpoint
and will be especially interested in the use cases. TPM 2.0 is feature rich, and the use
cases we describe will hopefully inspire creativity in developing and inventing security
applications. Developers have to know the basics of symmetric and asymmetric keys and
hashes in developing their applications—not the bit-by-bit computations, which are done
in the TPM or support software—but rather the types of guarantees that can be obtained
by using the TPM correctly.
We also want the book to be useful to embedded system developers, middle ware
developers, and programmers integrating TCG technology into operating systems and
boot code. The TPM now exposes more general-purpose cryptographic functions, which
are useful when a crypto library isn’t available due to either resource constraints or
licensing issues. We hope that low-level developers will find that this book goes as deep
as they need it to and that it serves as a critical tool in interpreting the specification.
Toward this end, diagrams and working code examples are used to help clarify many
concepts. We expect that embedded systems will increasingly use TPMs as the cost of
the technology is reduced (making cryptographic computations cheap to integrate into
embedded software) and as attacks on embedded software become more active.
If you’re new to security or need a refresher, Chapter 2 gives an overview of the security
concepts required to understand the book. This chapter provides high-level knowledge
of cryptography: we explain symmetric and asymmetric keys, secure hash algorithms,
and how a message authentication code (MAC) can be used as a symmetric key digital
signature. This chapter doesn’t delve into the underlying math used to implement
cryptographic algorithms; this isn’t intended as a general-purpose security or
cryptography textbook, because there is no need for most TPM 2.0 developers to possess
that depth of knowledge.
Chapter 3 presents a high-level tutorial on TPM 2.0 and the design rationale behind
it. It begins with applications and use cases enabled by TPM 1.2, all of which are also
available in TPM 2.0, and then continues by describing the new capabilities that are
available with the TPM 2.0 specification. This chapter should help you understand why
people are excited about the technology and want to use it in their applications and
Chapter 4 describes existing applications that use TPMs (currently, mostly 1.2). We
assume that many of these applications will be ported to TPM 2.0. Some are open source,
some are demonstration code written by academics to demonstrate what the TPM can
do, some are applications that have been around a long time and that can be linked to use
TPM features, and some are generally available applications written specifically to take
advantage of the TPM’s capabilities.
Chapter 5 provides a high-level orientation to the TPM 2.0 specification, offers
pointers to critical parts of the specification, and explores some best practices for using
Chapter 6 describes the setup and use of the execution environments available for
running TPM 2.0 code examples.
Chapter 7 discusses the trusted software stack (TSS). This is presented early in the
book because succeeding code examples use various layers of the TSS.
Chapter 8 begins the deep dive into TPM 2.0 functionality with a description of
TPM 2.0 entities: keys, data blobs, and NV indices.
Chapter 9 discusses hierarchies.
Chapter 10 covers keys.
Chapter 11 discusses NV indexes.
Chapter 12 explores PCRs and attestation.
Chapter 13 is one of the most in-depth chapters and is crucial if you’re developing
low-level code or architecting systems that make extensive use of sessions and
Chapter 14 discusses enhanced authorization.
Chapter 15 explains key management.
Chapter 16 describes the TPM’s auditing capabilities.
Chapter 17 examines decryption and encryption sessions and how to set them up.
Chapter 18 describes object, sequence, and session context management and the
basic functionality of a resource manager.
Chapter 19 discusses TPM startup, initialization, and provisioning. In typical usage,
these occur before keys and sessions are used, but knowledge of TPM entities and
sessions is a prerequisite to understanding TPM initialization and provisioning. This is
why we include this chapter after the previous three chapters.
Chapter 20 presents best practices for debugging TPM 2.0 applications.
Chapter 21 examines high-level applications that could use TPM 2.0 functionality.
Chapter 22 discusses platform-level security technologies that incorporate TPM 2.0
devices into their security solutions.
Although this is a technology book, we have tried to assume as little about our readers as
possible. Code examples use C, and a working knowledge of C is useful. However, most of
the concepts stand alone, and much of the book should be comprehensible to
non-programmers. Security concepts are explained at a high level, and every attempt is
made to make them understandable.
Some knowledge of the TPM 1.2 and 2.0 specifications is definitely beneficial but not
required. We encourage you to download the TPM 2.0 specifications from
www.trustedcomputinggroup.org so that you can refer to them as you read the book.
History of the TPM
A Trusted Platform Module, also known as a TPM, is a cryptographic coprocessor that
is present on most commercial PCs and servers. In terms of being present in computers,
TPMs are nearly ubiquitous, but until recently they’ve been mostly invisible to users due
to lack of compelling applications that use them. That situation is rapidly changing. With
the recent awarding of Federal Information Processing Standards (FIPS) certification to
various TPM designs, and recommendations from the President’s Council of Advisors
that the United States government begin using TPMs to defend the nation’s computers,
the TPM has become a strategic asset for computer owners to defend their cryptographic
assets. It is still true that very few people know enough about TPMs to use them in an
advantageous manner, a situation that motivated the writing of this book. This chapter
introduces you to TPMs, starting with TPM 1.1b, and describes the history of TPM 2.0’s
Why a TPM?
In the 1990s, it became increasingly obvious to people in the computer industry that
the Internet was going to change the way personal computers were connected, and
that commerce was going to move toward this environment. This immediately led to a
realization that there was a need for increased security in personal computers. When
PCs were first designed, little thought was given to their security, so the hardware did not
support it. Additionally, software was designed without any thought to security—ease of
use was the main driving force in software development.
The computer engineers who got together to develop the first TPMs—and who were
part of what came to be known as the Trusted Computing Group (TCG)—were trying to
reverse this trend and create a hardware anchor for PC system security on which secure
systems could be built. Cost pressures dictated that any such solution had to be very
cheap. The result was a hardware TPM chip intended to be physically attached to the
motherboard of a PC. The TPM command set was architected to provide all functions
necessary for its security use cases, detailed in Chapter 3; but anything not absolutely
necessary was moved off chip to software, to keep the cost down. As a result, the
specification was hard to read, because it wasn’t obvious how commands were to be used
when a lot of the logic was left to software. This started a trend in unreadability that has
continued through all the updates to the specification.
Chapter 1 ■ History of the TPM
Hardware security is not an easy topic to begin with, and it doesn’t help to have
a specification that is hard to understand. A good starting place to understand this
technology is the history of its development.
History of Development of the TPM Specification
from 1.1b to 1.2
The first widely deployed TPM was TPM 1.1b, which was released in 2003. Even at this
early date, the basic functions of a TPM were available. These included key generation
(limited to RSA keys), storage, secure authorization, and device-health attestation. Basic
functionality to help guarantee privacy was available through the use of anonymous
identity keys, based on certificates that could be provided with the TPM; owner
authorization was required to create those identity keys. A new network entity called a
privacy certificate authority (CA) was invented to provide a means to prove that a key
generated in the TPM came from a real TPM without identifying which TPM it came from.
Areas of dynamic memory inside the TPM, called Platform Configuration
Registers (PCRs), were reserved to maintain the integrity of a system’s boot-sequence
measurements. PCRs, together with identity keys, could be used to attest to the health of
the system’s boot sequence. This began the building of a secure architecture based on the
TPM anchor, one of the key aims of the TCG.
One specific non-goal of the TCG was making the TPM design immune to physical
attacks. Although such capabilities are possible, it was decided to leave physical
protections to the manufacturers as an area where they could differentiate. Any software
attacks are within scope for TPM-based security, however.
In a manner similar to smart-card chips attached to the motherboard, IBM PCs
were the first to use TPMs (similar security coprocessors had been used in mainframe
computers for decades). HP and Dell soon followed suit in their PCs, and by 2005 it was
difficult to find a commercial PC that did not have a TPM.
One drawback of TPM 1.1b was incompatibilities at the hardware level. TPM vendors
had slightly different interfaces, requiring different drivers, and package pinouts were not
standardized. TPM 1.2 was developed from 2005–2009 and went through several releases.
Its initial improvements over 1.1b included a standard software interface and a mostly
standard package pinout.
The TCG realized that although TPM 1.1b protected keys against attackers who did not
know a key’s authorization password, there was no protection against an attacker trying one
password after another in an attempt to guess a correct password. Attackers who do this usually
try passwords from a dictionary of common passwords; this is known as a dictionary attack.
The TPM 1.2 specification required that TPMs have protection against dictionary attacks.
Privacy groups complained about the lack of implementations of privacy CAs. This
led to the inclusion in TPM 1.2 of new commands for a second method of anonymizing
keys to help address this concerns—direct anonymous attestation (DAA)—and a method
of delegating key authorization and administrative (owner-authorized) functions.
Chapter 1 ■ History of the TPM
It turned out that shipping a machine with a certificate for its TPM’s endorsement
keys on the hard disk was in many case impractical, because IT organizations often
erased the hard disk when they received it and installed their own software load. When
they did so, the certificate was deleted. In order to provide a solution, a small amount of
nonvolatile RAM (usually about 2KB) was added in TPM 1.2; it had specialized access
controls along with a small number of monotonic counters.
The 1.1b specification had a means of copying migratable keys from one TPM to
another TPM in case a machine died or needed to be upgraded. This process required the
approval of the key owner and the TPM owner. It was designed with the assumption that
an IT administrator would be the TPM owner and the user would be the key owner. But in
1.2, the user needed to be able to use the TPM owner authorization to mitigate dictionary
attacks and create NVRAM, which made this design impractical. Therefore, in 1.2,
another technique was designed to let users create keys that could only be migrated by a
designated third party. Such keys could be certified to this effect and hence were called
Certified Migratable Keys (CMKs).
Signing keys are often used to sign contracts, and having a timestamp of when the
signing takes place is useful. The TCG considered putting a clock into the TPM, but the
problem was that the TPM loses power whenever the PC is turned off. Although putting
a battery in the TPM is possible, it is unlikely that the increased function would be worth
the higher cost. Therefore the TPM was given the ability to synchronize an internal
timer with an external clock and then to sign with the value of the internal timer. As an
example, this combination could be used to determine when a contract was signed. This
functionality also lets the TPM be used to distinguish how much time elapsed between
two signature operations performed by the TPM.
No changes were made to existing application programming interfaces in 1.2, which
preserved binary compatibility of software written to the 1.1b specification. A side effect
was that the TPM 1.2 specification became even more complex, because special cases
had to be used to maintain compatibility.
Before TPMs became ubiquitous, security coprocessors such as smart cards were
used by some applications to store keys to identify users and keys to encrypt data at rest.
TPMs are well equipped to take over this task. But they can do much more: because the
security coprocessor is integrated onto the system’s motherboard in the form of a TPM, it
has additional uses (such as device identification) that are detailed in Chapter 3.
TPM 1.2 was deployed on most x86-based client PCs from 2005 on, began to appear
on servers around 2008, and eventually appeared on most servers. Just having hardware
does nothing, however—software needs to use it. In order to make use of the TPM
hardware, Microsoft supplied a Windows driver, and IBM open sourced a Linux driver.
Software began to be deployed, as described in Chapter 4.
How TPM 2.0 Developed from TPM 1.2
In early 2000, when the TCG was faced with the choice of a hash algorithm, it had two
choices: MD5, which was most widely deployed; and SHA-1, which was stronger and was
deployed widely, although not as widely as MD5. SHA-1 was the strongest commercial
algorithm at the time and could feasibly be used in a small, cheap package. This was a
fortunate choice, because MD5 weaknesses became apparent shortly afterward.
Chapter 1 ■ History of the TPM
Around 2005, cryptographers published the first significant attack on the SHA-1
digest algorithm. The TPM 1.2 architecture relied heavily on the SHA-1 algorithm and
had hard-coded SHA-1 everywhere. Although an analysis of the attack showed that it did
not apply to the ways SHA-1 was used in the TPM, a common axiom in cryptography is
that cryptographic algorithms only become weaker over time, never stronger. The TCG
immediately began work on a TPM 2.0 specification that would be agile with respect
to digest algorithms. That is, the specification would not hard-code SHA-1 or any other
algorithm, but rather would incorporate an algorithm identifier that would permit design
of a TPM using any algorithm without changing the specification. With this change (and
other changes allowing all cryptographic algorithms to be agile), the TCG hoped the new
specification could be the last major TPM specification to be released.
The original mandate of the TPM 2.0 Work Group within the TCG was only that:
digest agility. However, even a cursory look at the TPM 2.0 specification shows that it’s far
more than TPM 1.2 plus an algorithm identifier. How did that happen?
TPM 1.1b had carefully crafted structures so that serialized versions (the structures
translated into byte streams) were compact enough to be encrypted with a 2,048-bit RSA
key in a single encryption. That meant there were only 2,048 bits (256 bytes) to work
with. No symmetric encryption algorithms were required in the design, which kept the
cost down and avoided problems when exporting designs that could do bulk symmetric
encryption. RSA was the only required asymmetric algorithm, and performance required
that structures be encrypted in one operation.
TPM 2.0 had to provide for digests that were larger than SHA-1’s 20 bytes, so it was
clear the existing structures were too large. An RSA key could not directly encrypt the
serialized structures in one operation. Using multiple operations to encrypt the structures
in blocks was impractical, because RSA operations are slow. Increasing the size of the
RSA key would mean using key sizes that were not widely used in the industry and would
also increase the cost, change the key structures, and slow the chip. Instead, the TPM
Work Group decided the specification had to use the common practice of encrypting a
symmetric key with the asymmetric key and the data with the symmetric key. Symmetric
key operations are well suited for encrypting large byte streams, because they are much
faster than asymmetric operations. Symmetric key encryption thus removed the barrier
on the size of structures. This freed the specification developers to use their creativity to
architect several functions that were distinct from TPM 1.2.
It is said that the best designs come about when the architects make a design and
then, having learned all the problems they will encounter, throw away the first design and
start over with a second. TPM 2.0 gave the architects the opportunity to do this. However,
they still had to make sure that the opportunities for software development that were
enabled by the TPM 1.2 design were not lost with the new architecture.
History of TPM 2.0 Specification Development
The specification made slow but steady progress for several years, with features being
debated, added, and deleted. David Grawrock of Intel was the chair of the specification
committee; under his leadership, the group selected the major features of the design and
settled on a basic feature set and high-order design. At this point, the committee decided
to change all the structures to allow for algorithm independence in the specification—
this is called algorithm agility. All the authentication techniques were unified with
Chapter 1 ■ History of the TPM
a technique originally called generalized authorization and now called enhanced
authorization (EA). This increased the flexibility of authorization while simultaneously
reducing the cost of the implementation and reducing the cognitive difficulty of
understanding the specification. All objects and entities use the same authentication
techniques. Many discussions took place regarding the problems created by having
algorithm flexibility while still allowing a user to determine precisely what algorithms
were used, both by a given key and also to protect the key, so the overall security of any
key held by the TPM could be determined.
When Grawrock left the chairmanship due to changing responsibilities at
Intel, Microsoft contributed a full-time editor, David Wooten, and HP took over the
chairmanship. It was decided at this point that the specification should be compilable,
which drove Wooten to create an emulator while writing the specification. A compilable
specification has the advantage of much-reduced ambiguity: if there is doubt about how
the specification is supposed to work, it can be compiled into an authoritative emulator.
Additionally, the generalized authentication structure was moved from Polish notation
(such as used in a TI calculator) to Reverse Polish notation (such as used in an HP
calculator), which made implementing the specification easier (but made understanding
the specification harder). The committee decided to add multiple key hierarchies to
accommodate different user roles.
Wooten worked tirelessly to develop an implementation of the specification and
provided strong leadership that drove the specification to its current feature set. When
HP’s Graeme Proudler stepped down from the chairmanship, David Challener of Johns
Hopkins Applied Physics Laboratory formed a joint chairmanship first with Julian
Hammersly of AMD, and later with Ari Singer of DMI. Kenneth Goldman (of IBM) took
over the editorship from David Wooten after the first release, reprising a role he held for
many years with the TPM 1.2 specification.
As new members joined the group over the years and began trying to understand the
specification, some of them, notably Will Arthur and Kenneth Goldman, dove deep into
the specification line by line. They submitted many bug and readability fixes to the TPM
Work Group, and most of those resulted in changes to the specification that enhanced its
consistency and readability. Even with these changes, it still is not easy reading, which led
to the original impetus for this book.
The TPM specification has been developed twice. The first time, it developed from 1.1b
to 1.2, evolving to incorporate capabilities as they came to be known to the specification
committee. This feature-creep form of evolution made the final specification very
complicated. In the second generation, TPM 2.0, after the cryptographic weaknesses
of SHA-1 caused the need for a change, the architecture was redesigned from scratch—
resulting in a much more integrated and unified design. The next chapter introduces the
cryptographic concepts that will be used throughout the rest of the book. A good high-level
understanding of these is imperative for you to understand TPM 2.0.
Basic Security Concepts
This chapter provides an overview of security concepts and their application to the TPM.
It is not important that you understand the underlying mathematics of those concepts,
so they will not be described. Instead, the chapter discusses the behavior of the various
cryptographic algorithms so you can understand how they are used in the TPM 2.0
Security experts can skip this chapter. If you have less or somewhat rusty knowledge,
you are advised to skim it to refresh your memory or learn how basic cryptographic concepts
are used in TPMs. If you have little or no TPM knowledge, this chapter is a must read.
All the cryptographic algorithms included in TPM 2.0 are based on public
standards that have been extensively reviewed. Creating custom algorithms that
are cryptographically strong has generally proven to be very difficult. Many years of
cryptanalysis must be performed before an algorithm is considered strong by the
community, and only algorithms that have met that criteria are approved for use in the
TPM by the Trusted Computing Group (TCG). This chapter describes three types of these
algorithms: hash algorithms used mostly for integrity, symmetric-encryption algorithms
used mostly for confidentiality, and asymmetric-encryption algorithms used mostly for
digital signatures and key management. Specifically, we explore secure hash algorithms
the Advanced Encryption Standard (AES); and two asymmetric standards,
RSA and elliptic curve cryptography (ECC). But before considering the actual algorithms,
you need to know what they are used to defend against.
The chapter begins with a description of the two attack classes: brute force and
cryptanalysis. It then defines some fundamental concepts: messages, secrecy, integrity,
authentication, and authorization, along with two higher-layer concepts, anti-replay and
nonrepudiation. It finishes with a listing of the cryptographic algorithm classes used in
For the most part, these are general security principles. They are used throughout
the TPM design, and a description of their specific application to TPM 2.0 will be given as
they are used throughout the book. In the few cases where the TPM uses cryptography in
a less common way, or where the specification introduces a new cryptographic term, we
explain it here. (The extend operation is an example of both cases: it’s a general security
concept that has been applied in a new way in TPMs.)
Everything done in a TPM is related in some way to mitigating cryptographic attacks.
Chapter 2 ■ Basic Security Concepts
Cryptography is all about preventing attackers from doing malicious things. Security
systems that use cryptography are designed to prevent bad people from having their
way with your data, impersonating you, or changing documents without being detected.
These attackers may attempt to compromise the security of a cryptographic design in
two basic ways: either by deeply understanding the mathematics of the algorithms and
protocols and using that knowledge to look for and exploit a flaw in the design, or by
using brute force.
If you use well-vetted algorithms and protocols, and use them the way they were
designed to be used, your design will probably be immune to the first type of attacks.
That is why you need to take care to use accepted algorithms and protocols in your design.
In a brute-force attack, the attacker tries every possible key, input, or password, trying to
guess the secrets used to protect the design.
Cryptographers don’t like to claim that anything is impossible. Rather, they say something
is “computationally infeasible,” meaning it would take an impractical amount of time to
attack the cryptography by trying every combination. For the Data Encryption Standard
(DES), 2^56 possible keys could be used. This number is large: 72,057,594,037,927,936.
Although breaking the DES algorithm might seem to be computationally infeasible, in
1998, a machine was developed that did exactly that.1
Passwords are also often attacked using brute force—first dictionary words are tried,
then combinations of words and numbers, and even special characters. Attackers may
even try Klingon words or words from the Harry Potter books or The Lord of the Rings!
RainbowCrack (www.project-rainbowcrack.com/) is a well-known program used to
crack even fairly long passwords using brute force.
A cryptographic algorithm is well designed if the strength of the algorithm is not
dependent on keeping the algorithm secret. The algorithm is infeasible to break if this is
true and if it is infeasible to guess the algorithm secret, commonly called a key. Defending
against brute force attacks is about picking key sizes so large that it is infeasible to try
them all, or reducing the number of attacks that can be performed in a period of time.
TCG assumes that all the algorithms it approves are well designed. This may
not be true. Because the specification is not wedded to a particular algorithm, if one is
found to be weak at some point in the future, then instead of the specification having to
be rewritten, just that algorithm can be removed from the list of approved algorithms.
The strength of an algorithm that is well designed is measured by its immunity to
mathematical attacks. The strength of an implementation depends on both the type
of algorithm and the size of the key used.
Chapter 2 ■ Basic Security Concepts
Calculating the Strength of Algorithms by Type
Symmetric algorithms are used for traditional encryption, where the same key is used for
encryption and decryption. For a well-designed symmetric algorithm, the strength of the
cryptographic algorithm should depend exponentially on the size of the key used. Thus if
a key is only 4 bits long, there are 24 or 16 possible keys. A brute-force attacker who tried
all 16 keys would break the encryption; but on average the attacker would have to try
only half of them, or 8 keys, before finding the correct key. Because the numbers get
large quickly via exponentiation, the strength of algorithms is generally quoted in bits.
A well-designed symmetric algorithm has a strength equal to the number of bits in its key.
In a TPM, the symmetric algorithms usually have key sizes of 128, 192, or 256 bits.
A secure hash algorithm is sort of like an algorithm that encrypts but cannot decrypt.
This may sound non-useful, but it has a number of very interesting uses. A secure hash
algorithm always produces the same size output, independent of the input. A wonderful
property of a secure hash algorithm is that given the input, you always get the same output;
but given just the output, you can’t calculate the input. The strength of such an algorithm
can be calculated two ways:
The number of tries that would have to be attempted to guarantee
finding an input that produces a given hash output. For a welldesigned hash algorithm, this is assumed to be the size of the
output in bits.
The number of tries that would have to be attempted to have a
50% chance of finding two inputs with exactly the same output.
For a well-designed hash algorithm, this is half the size of the
output in bits.2
Depending on how the secure hash is used, either can be correct; but because
cryptographers tend to be P3 people (Paid Professional Paranoids), the latter is generally
used for the strength of a well-designed secure hash algorithm.
Asymmetric algorithms are strange at first introduction: The encryption algorithm is
different from the decryption algorithm, and the two use different keys, which together
form a public and private key pair. There are two asymmetric algorithms you should
be concerned about and that are described later in this chapter: RSA (named after its
inventors, Rivest, Shamir, and Adleman) and Elliptic Curve Cryptography (ECC).
For asymmetric algorithms, it is difficult to calculate strength corresponding to
a particular key size. For RSA, there are tables you can consult. Those tables say that
2048 bits in an RSA asymmetric key corresponds to 112 bits in a symmetric key; 3,076
bits corresponds to 128 bits; and 15,360 bits corresponds to 256 bits of key strength. For
ECC, the strength is considered to be half the number of bits of its key’s size. Therefore, a
256-bit ECC key is the same strength as a 128-bit symmetric key, and a 384-bit ECC key
corresponds to a 192-bit symmetric key.
This kind of attack is generally called a birthday attack, because of an old party trick. If there are
23 (which is close to the square root of 365) people in a room, the chances of 2 of them having the
same birthday is 50%. If there are substantially more people in the room, the probability rises
accordingly. If there are 40 people, the probability is almost 90%.
Chapter 2 ■ Basic Security Concepts
If brute-force attacks are infeasible due to a large key size, the attacker may seek to
analyze the mathematics of the cryptographic algorithm or protocol with the hope of
finding a shortcut.
Attacks on the Algorithm Itself
Cryptographic algorithm design is a bit of an art. The mathematics are based on how hard
it is to solve a particular type of problem, and that difficulty in turn is based on current
knowledge. It’s very difficult to design an algorithm against which no attacks can ever
An attack on the SHA-1 hash algorithm3 was one of the motivations for moving
from TPM 1.2 to TPM 2.0. Under normal circumstances, a brute-force birthday attack on
SHA-1 would take about 280 calculations, with a cryptographic strength of 80. The attack,
which was based on a weakness in the underlying mathematics, successfully reduced the
number of calculations required for a successful attack to 263—a cryptographic strength
of 63. TPM 1.2 used SHA-1 throughout the design. With 56-bit DES encryption defeated
by brute-strength attacks in 1998, it was clear that 63 bits was not enough for the industry.
For that reason, TPM 2.0 removed this dependency on the SHA-1 algorithm. To defend
against such an attack ever happening again, the specification was made algorithm
agile—algorithms can be added to or subtracted from the specification without requiring
that the entire specification be rewritten.
To summarize, in order to be secure, cryptographic algorithms must not have the
Weaknesses in algorithms: You can avoid weak algorithms by
using well-vetted, internationally accepted, widely reviewed
Brute-force attacks: By choosing large key sizes and by allowing
the end user to pick the key size they wish to use, you can avoid
this vulnerability. Today 128 bits is generally considered a safe
value for symmetric algorithms, but some researchers and
security agencies insist on 192 bits.
Now that you’ve seen the attacks you’re defending against, we can discuss the basic
cryptography constructs used in the TPM specification. Let’s begin with some definitions.
Several concepts are important for understanding the TPM architecture and
cryptographic concepts. People often equate security solely with secrecy: the inability of
an attacker to decode a secret message. Although secrecy is certainly important, there
is much more to security. It’s easiest to understand these concepts by considering an
Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, “Finding Collisions in the Full SHA-1,”
Advances in Cryptology–CRYPTO 2005.
Chapter 2 ■ Basic Security Concepts
example. Because electronic business was a big motivator in the design of the TPM, the
following example comes from e-business.
An electronic order is transmitted from a buyer to a seller. The seller and buyer may
want to keep details (credit card numbers, for example) of the purchase secret. However,
they may also want to ensure that the order really came from the buyer, not an attacker;
that the order went only to the seller; that the order wasn’t altered in transit (for example,
by changing the amount charged); and that it was sent exactly once, not blocked or sent
multiple times. Finally, the seller may wish to verify that the buyer is permitted by their
company to buy the item and to spend the total amount of the purchase order. All these
aspects are the problems that cryptography and security protocols attempt to solve.
Based on this example, we can describe several commonly used security terms and
concepts, and then explain how they can be used to provide the various aspect of security.
Message: An array of bytes sent between two parties.
Secrecy: A means of preventing an unauthorized observer of a
message from determining its contents.
Shared secret: A value that is known to two parties. The secret can
be as simple as a password, or it can be an encryption key both
Integrity: An indication that a message has not been altered
during storage or transmission.
Authentication: A means of indicating that a message can be tied
to the creator, so the recipient can verify that only the creator
could have sent the message.
Authorization: Proof that the user is permitted to perform an
Anti-replay: A means of preventing an attacker from reusing a
Nonrepudiation: A means of preventing the sender of a message
from claiming that they did not send the message.
Let’s consider how each of these security concepts fits into the electronic purchase
order example. The message is the number of items ordered and any confidential
customer information, such as a credit card number. Integrity ensures that the order has
not been altered in transit—for instance, from 3 items to 300 items. Authentication proves
that the order came from the buyer. Authorization checks that the buyer is permitted
to purchase the items on behalf of their company. Anti-replay prevents the attacker
from sending the buyer’s message again to purchase three items multiple times. And
nonrepudiation means the buyer can’t claim they never ordered the items.
To provide these security guarantees, designers of a security system have a toolbox
of cryptographic functions that have been developed, analyzed, and standardized. Some
items are fundamental mathematical building blocks, such as the SHA-256 secure hash
algorithm or the RSA asymmetric-key encryption calculation. Other items, such as digital
signatures, build on these fundamentals by using the RSA algorithm. These cryptographic
functions are described next.
Chapter 2 ■ Basic Security Concepts
Trust us, there’s no math in this section. We won’t be describing prime number
algorithms and elliptic curves. But it’s important to understand some cryptographic
operations and how they relate to the basic security principles you’ve already seen.
A secure hash algorithm is used to provide integrity. It can be combined with a
shared-secret signing key in an HMAC algorithm to ensure authentication. HMAC is in
turn the basis for a cryptographic ticket and key-derivation functions. A shared secret
provides secrecy when used in symmetric-key encryption. A nonce provides anti-replay
protection. An asymmetric key used as a signing key offers nonrepudiation. The TPM also
uses an asymmetric key for secrecy in some protocols. All these concepts are described in
the following sections.
Secure Hash (or Digest)
Most computer science students are familiar with hashes; simple hashes are used to
speed searches. A more advanced form of a hash is a checksum that is used to detect
random errors in data. But cryptographers are concerned with malicious attackers trying
to break a system, so they need a secure cryptographic hash with very specific properties.
A cryptographic hash, like its much simpler cousins, takes a message of any length
and compresses it to a hash of fixed length. For example, a SHA-256 hash is 256 bits or
32 bytes. For security purposes, the important properties of a secure hash are as follows:
It’s infeasible, given a message, to construct another message with
the same hash.
It’s infeasible to construct two messages with the same hash.
It’s infeasible to derive the message given its hash.
As an example, you can observe that even a very small change in a message causes a
large change in the digest produced by the hash. For example, using SHA-1, the message
“Hello” hashes to:
The message “hello” with the first character changed to lowercase hashes to:
The TPM 2.0 specification allows for a number of different types of hash
algorithms—SHA-1, SHA-256, and SHA-384 are just some of them. Typically, TPMs
implement only a few of the allowed hashes. One problem that vexed the developers for
a long time was how to integrate multiple hash algorithms (which are used to maintain
integrity) if one of those hash algorithms was later broken. This is harder than it sounds,
because usually hash algorithms themselves are used to provide integrity to reports, and
if the hash algorithm can’t be trusted, how can you trust a report of which hash algorithm
is being used? The design that was chosen managed to avoid this problem: tags are used
throughout the design in data elements that identify the hash algorithms used.
Author David Challener and Will Arthur Isbn 9781430265832 File size 5.7 MB Year 2015 Pages 392 Language English File format PDF Category IT ebooks Book Description: FacebookTwitterGoogle+TumblrDiggMySpaceShare A Practical Guide to TPM 2.0: Using the Trusted Platform Module in the New Age of Security is a straight-forward primer for developers. It shows security and TPM concepts, demonstrating their use in real applications that the reader can try out. Simply put, this book is designed to empower and excite the programming community to go out and do cool things with the TPM. The approach is to ramp the reader up quickly and keep their interest.A Practical Guide to TPM 2.0: Using the Trusted Platform Module in the New Age of Security explains security concepts, describes the TPM 2.0 architecture, and provides code and pseudo-code examples in parallel, from very simple concepts and code to highly complex concepts and pseudo-code. The book includes instructions for the available execution environments and real code examples to get readers up and talking to the TPM quickly. The authors then help the users expand on that with pseudo-code descriptions of useful applications using the TPM. Download (5.7 MB) Application Security for the Android Platform CISSP Training Kit Accumulo 802.11ac: A Survival Guide Cyber Threat! Load more posts