ISO/IEC 11889-2:2009

Information technology - Trusted Platform Module - Part 2: Design principles

ISO/IEC 11889 defines the Trusted Platform Module (TPM), a device that enables trust in computing platforms in general. ISO/IEC 11889-2:2009 defines the principles of TPM operation. These include base operating modes, cryptographic algorithms and key sizes for the algorithms, basic interoperability requirements, basic protocols and the use of the protocols, and use of TPM resources.

Technologies de l'information — Module de plate-forme de confiance — Partie 2: Principes de conception

General Information

• Status: Published
• Publication Date: 17-May-2009
• Withdrawal Date: 17-May-2009
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9093 - International Standard confirmed
• Start Date: 14-Feb-2017
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 11889-2:2015 - Information technology - Trusted Platform Module Library - Part 2: Structures
• Effective Date: 10-May-2014

Overview

ISO/IEC 11889-2:2009 - "Information technology - Trusted Platform Module - Part 2: Design principles" defines the design principles and operational behavior for the Trusted Platform Module (TPM). Part 2 focuses on the TPM’s base operating modes, core cryptographic building blocks, interoperability requirements, authorization and transport protocols, and use of TPM resources (keys, PCRs, NV storage). The document is normative in large part and uses RFC‑2119 keywords (MUST/SHOULD/MAY) to state requirements. TPM implementers should also consult platform‑specific specifications for a complete build.

Key topics and technical requirements

• TPM architecture and components: input/output, cryptographic co‑processor, key generation, HMAC, RNG, SHA‑1 engine, execution engine, NV memory, power detection and physical presence mechanisms.
• Cryptographic primitives and interoperability: references to SHA‑1, AES and RSA, and use of established schemes (OAEP, PKCS#1, HMAC) for encryption, signing and integrity. The part prescribes acceptable algorithms and key selection guidance for interoperability.
• Key lifecycle and identity: Endorsement Key (EK) creation and protection, Attestation Identity Keys (AIKs), Storage Root Key (SRK), and rules for key use and migration.
• Roots of trust: Root of Trust for Reporting (RTR) and Root of Trust for Storage (RTS), platform identity and privacy considerations, PCR (Platform Configuration Register) usage and measurement model.
• Authorization & transport: authorization protocols (OIAP, OSAP), transport sessions, ADIP/ADCP/AACP protocols, handling brute‑force/dictionary attack risks, and session management.
• Operational states & lifecycle: initialization, self‑test, startup, enabling/activating/ownership, clearing TPM, field upgrades and maintenance.
• Non‑volatile storage & counters: NV storage design principles, monotonic counters, audit/tracking and transport protection.
• Advanced functions: Direct Anonymous Attestation (DAA), certified migration, delegation model, time stamping and tick architecture.

Practical applications and who uses it

• TPM silicon vendors and firmware developers use this standard to design compliant TPM chips and internal services.
• Platform OEMs and BIOS/UEFI integrators implement TPM interfaces, PCR measurements and ownership workflows.
• Security architects and solution integrators leverage the standard to build trusted computing features: secure boot, measured launch, hardware-backed key storage, remote attestation and secure credential storage.
• Certification bodies and evaluators use the document alongside evaluation standards (e.g., ISO/IEC 19790) when assessing TPM security.

Related standards

• ISO/IEC 11889 (other parts: Part 1 Overview, Part 3 Structures, Part 4 Commands)
• Cryptographic and protocol references cited: ISO/IEC SHA and AES standards, PKCS#1, IEEE P1363, IETF RFC 2104/2119, and ISO/IEC 19790 (security evaluation).

Keywords: ISO/IEC 11889-2:2009, Trusted Platform Module, TPM design principles, TPM architecture, EK, AIK, PCR, RTR, RTS, TPM authorization protocols, TPM interoperability.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 11889-2
First edition
2009-05-15
Information technology — Trusted
Platform Module —
Part 2:
Design principles
Technologies de l'information — Module de plate-forme de confiance —
Partie 2: Principes de conception

Reference number
©
ISO/IEC 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved

Table of Contents
1. Scope 1
1.1 Key words 1
1.2 Statement Type 1
2. Normative references 2
3. Abbreviated Terms 3
4. Conformance 5
4.1 Introduction 5
4.2 Threat 6
4.3 Protection of functions 6
4.4 Protection of information 6
4.5 Side effects 7
4.6 Exceptions and clarifications 7
5. TPM Architecture 8
5.1 Interoperability 8
5.2 Components 8
5.2.1 Input and Output 9
5.2.2 Cryptographic Co-Processor 9
5.2.3 Key Generation 11
5.2.4 HMAC Engine 12
5.2.5 Random Number Generator 13
5.2.6 SHA-1 Engine 15
5.2.7 Power Detection 16
5.2.8 Opt-In 16
5.2.9 Execution Engine 17
5.2.10 Non-Volatile Memory 17
5.3 Data Integrity Register (DIR) 18
5.4 Platform Configuration Register (PCR) 18
6. Endorsement Key Creation 20
6.1 Controlling Access to PRIVEK 21
6.2 Controlling Access to PUBEK 21
7. Attestation Identity Keys 22
8. TPM Ownership 23
8.1 Platform Ownership and Root of Trust for Storage 23
9. Authentication and Authorization Data 24
9.1 Dictionary Attack Considerations 25
10. TPM Operation 26
10.1 TPM Initialization & Operation State Flow 27
10.1.1 Initialization 27
© ISO/IEC 2009 – All rights reserved iii

10.2 Self-Test Modes 28
10.2.1 Operational Self-Test 29
10.3 Startup 32
10.4 Operational Mode 33
10.4.1 Enabling a TPM 34
10.4.2 Activating a TPM 35
10.4.3 Taking TPM Ownership 36
10.4.4 Transitioning Between Operational States 38
10.5 Clearing the TPM 38
11. Physical Presence 40
12. Root of Trust for Reporting (RTR) 42
12.1 Platform Identity 42
12.2 RTR to Platform Binding 43
12.3 Platform Identity and Privacy Considerations 43
12.4 Attestation Identity Keys 43
12.4.1 AIK Creation 44
12.4.2 AIK Storage 45
13. Root of Trust for Storage (RTS) 46
13.1 Loading and Unloading Blobs 46
14. Transport Sessions and Authorization Protocols 47
14.1 Authorization Session Setup 48
14.2 Parameter Declarations for OIAP and OSAP Examples 50
14.2.1 Object-Independent Authorization Protocol (OIAP) 52
14.2.2 Object-Specific Authorization Protocol (OSAP) 56
14.3 Authorization Session Handles 59
14.4 Authorization-Data Insertion Protocol (ADIP) 60
14.5 AuthData Change Protocol (ADCP) 64
14.6 Asymmetric Authorization Change Protocol (AACP) 65
15. ISO/IEC 19790 Evaluations 66
15.1 TPM Profile for successful ISO/IEC 19790 evaluation 66
16. Maintenance 67
16.1 Field Upgrade 69
17. Proof of Locality 70
18. Monotonic Counter 71
19. Transport Protection 74
19.1 Transport encryption and authorization 75
19.1.1 MGF1 parameters 77
19.1.2 HMAC calculation 78
19.1.3 Transport log creation 78
19.1.4 Additional Encryption Mechanisms 78
iv © ISO/IEC 2009 – All rights reserved

19.2 Transport Error Handling 79
19.3 Exclusive Transport Sessions 79
19.4 Transport Audit Handling 80
19.4.1 Auditing of wrapped commands 80
20. Audit Commands 81
20.1 Audit Monotonic Counter 83
21. Design Section on Time Stamping 84
21.1 Tick Components 84
21.2 Basic Tick Stamp 85
21.3 Associating a TCV with UTC 85
21.4 Additional Comments and Questions 87
22. Context Management 89
23. Eviction 91
24. Session pool 92
25. Initialization Operations 93
26. HMAC digest rules 94
27. Generic authorization session termination rules 95
28. PCR Grand Unification Theory 96
28.1 Validate Key for use 98
29. Non Volatile Storage 100
29.1 NV storage design principles 101
29.1.1 NV Storage use models 101
29.2 Use of NV storage during manufacturing 103
30. Delegation Model 104
30.1 Table Requirements 104
30.2 How this works 105
30.3 Family Table 106
30.4 Delegate Table 107
30.5 Delegation Administration Control 108
30.5.1 Control in Phase 1 109
30.5.2 Control in Phase 2 110
30.5.3 Control in Phase 3 110
30.6 Family Verification 110
30.7 Use of commands for different states of TPM 112
30.8 Delegation Authorization Values 112
30.8.1 Using the authorization value 112
30.9 DSAP description 113
31. Physical Presence 116
31.1 Use of Physical Presence 116
32. TPM Internal Asymmetric Encryption 117
© ISO/IEC 2009 – All rights reserved v

32.1.1 TPM_ES_RSAESOAEP_SHA1_MGF1 117
32.1.2 TPM_ES_RSAESPKCSV15 118
32.1.3 TPM_ES_SYM_CTR 118
32.1.4 TPM_ES_SYM_OFB 118
32.2 TPM Internal Digital Signatures 118
32.2.1 TPM_SS_RSASSAPKCS1v15_SHA1 119
32.2.2 TPM_SS_RSASSAPKCS1v15_DER 119
32.2.3 TPM_SS_RSASSAPKCS1v15_INFO 120
32.2.4 Use of Signature Schemes 120
33. Key Usage Table 121
34. Direct Anonymous Attestation 123
34.1 TPM_DAA_JOIN 123
34.2 TPM_DAA_Sign 124
34.3 DAA Command summary 125
34.3.1 TPM setup 125
34.3.2 JOIN 126
34.3.3 SIGN 129
35. General Purpose IO 132
36. Redirection 133
37. Structure Versioning 134
38. Certified Migration Key Type 135
38.1 Certified Migration Requirements 135
38.2 Key Creation 136
38.3 Migrate CMK to a MA 136
38.4 Migrate CMK to a MSA 136
39. Revoke Trust 138
40. Mandatory and Optional Functional Blocks 139
41. 1.1a and 1.2 Differences 142
42. Bibliography 143
vi © ISO/IEC 2009 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 11889-2 was prepared by the Trusted Computing Group (TCG) and was adopted, under the PAS
procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval
by national bodies of ISO and IEC.
ISO/IEC 11889 consists of the following parts, under the general title Information technology — Trusted
Platform Module:
⎯ Part 1: Overview
⎯ Part 2: Design principles
⎯ Part 3: Structures
⎯ Part 4: Commands
© ISO/IEC 2009 – All rights reserved vii

Introduction
Figure 1. TPM Main Specification Roadmap
Start of informative comment
ISO/IEC 11889 is from the Trusted Computing Group (TCG) Trusted Platform Module (TPM)
specification 1.2 version 103. The part numbers for ISO/IEC 11889 and the TCG specification do
not match. The reason is the inclusion of the Overview document that is not a member of the TCG
part numbering. The mapping between the two is as follows:
ISO Reference  TCG Reference
Part 1 Overview  Not published
Part 2 Design Principles Part 1 Design Principles
Part 3 Structures  Part 2 Structures
Part 4 Commands  Part 3 Commands
End of informative comment
viii © ISO/IEC 2009 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 11889-2:2009(E)

Information technology — Trusted Platform Module —
Part 2:
Design principles
1. Scope
ISO/IEC 11889 defines the Trusted Platform Module (TPM), a device that enables trust in
computing platforms in general. ISO/IEC 11889 is broken into parts to make the role of each
document clear. Any version of the standard requires all parts to be a complete standard.
A TPM designer MUST be aware that for a complete definition of all requirements necessary to
build a TPM, the designer MUST use the appropriate platform specific specification to understand
all of the TPM requirements.
Part 2 defines the principles of TPM operation. The base operating modes, the algorithms and key
choices, along with basic interoperability requirements make up the majority of the normative
statements in part 2.
1.1 Key words
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,”
“SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document’s normative
statements are to be interpreted as described in RFC-2119, Key words for use in RFCs to Indicate
Requirement Levels.
1.2 Statement Type
Please note a very important distinction between different sections of text throughout this document.
You will encounter two distinctive kinds of text: informative comment and normative statements.
Because most of the text in this specification will be of the kind normative statements, the authors
have informally defined it as the default and, as such, have specifically called out text of the kind
informative comment They have done this by flagging the beginning and end of each informative
comment and highlighting its text in gray. This means that unless text is specifically marked as of
the kind informative comment, you can consider it of the kind normative statements.
For example:
Start of informative comment
This is the first paragraph of 1–n paragraphs containing text of the kind informative comment .
This is the second paragraph of text of the kind informative comment .
This is the nth paragraph of text of the kind informative comment .
To understand the standard the user must read the standard. (This use of MUST does not require
any action).
End of informative comment
This is the first paragraph of one or more paragraphs (and/or sections) containing the text of the
kind normative statements .
To understand the standard the user MUST read the standard. (This use of MUST indicates a
keyword usage and requires an action).
© ISO/IEC 2009 – All rights reserved 1

2. Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
ISO/IEC 8825-1⎪ITU-T X.690: Information technology – ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)
ISO/IEC 10118-3, Information technology — Security techniques — Hash-functions —
Part 3: Dedicated hash-functions, Clause 9, SHA-1
ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms —
Part 3, Block ciphers, Clause 5.1 AES
IEEE P1363, Institute of Electrical and Electronics Engineers: Standard Specifications For
Public-Key Cryptography
IETF RFC 2104, Internet Engineering Task Force Request for Comments 2104: HMAC:
Keyed-Hashing for Message Authentication
IETF RFC 2119, Internet Engineering Task Force Request for Comments 2119: Key words
for use in RFCs to Indicate Requirement Levels
PKCS #1 Version 2.1, RSA Cryptography Standard. This document is superseded by
P1363, except for section 7.2 that defines the V1.5 RSA signature scheme in use by the
TPM.
2 © ISO/IEC 2009 – All rights reserved

3. Abbreviated Terms
Abbreviation Description
AACP Asymmetric Authorization Change Protocol
ADCP Authorization Data Change Protocol
ADIP Authorization Data Insertion Protocol
AIK Attestation Identity Key
AMC Audit Monotonic Counter
APIP Time-Phased Implementation Plan
AuthData Authentication Data or Authorization Data, depending on the context
BCD Binary Coded Decimal
BIOS Basic Input/Output System
CA Certification of Authority
CDI Controlled Data Item
CMK Cerifiable/Certified Migratable Keys
CRT Chinese Remainder Theorem
CRTM Core Root of Trust Measurement
CTR Counter-mode encryption
DAA Direct Autonomous Attestation
DIR Data Integrity Register
DOS Disk Operating System
DSA Digital Signature Algorithm
DSAP Delegate-Specific Authorization Protocol
ECB Electronic Codebook Mode
EK Endorsement Key
ET ExecuteTransport or Entity Type
FIPS Federal Information Processing Standard
GPIO General Purpose I/O
HMAC Hash Message Authentication Code
HW Hardware Interface
IB Internal Base
I/O Input/Output
IV Initialization Vector
KH Key Handle
LEAP Lightweight Extensible Authentication Protocol for wireless computer networks
LK Loaded Key
LOM Limited Operation Mode
LPC Low Pin Count
LSB Least Significant Byte
MA Migration Authority/Authorization
MIDL Microsoft Interface Definition Language
MSA Migration Selection Authority
MSB Most Significant Byte
NV Non-volatile
© ISO/IEC 2009 – All rights reserved 3

Abbreviation Description
NVRAM Non-Volatile Random Access Memory
OAEP Optimal Asymmetric Encryption Padding
OEM Original Equipment Manufacturer
OIAP Object-Independent Authorization Protocol
OID Object Identifier
OSAP Object-Specific Authorization Protocol
PCR Platform Configuration Register
PI Personal Information
PII Personally Identifiable Information
POST Power On Self Test
PRIVEK Private Endorsement Key
PRNG Pseudo Random Number Generator
PSS Probabilistic Signature Scheme
PUBEK Public Endorsement Key
RNG Random Number Generator
RSA Algorithm for public-key cryptography. The letters R, S, and A represent the initials of the first public describers of the algorithm.
RTM Release to Manufacturing/Ready to Market
RTR Root of Trust for Reporting
RTS Root of Trust for Storage
SHA Secure Hash Algorithm
SRK Storage Root Key
STF Self Test Failed
TA Time Authority
TBB Threading Building Blocks
TCG Trusted Computing Group
TCV Tick Count Value
TIR Tick Increment Rate
TIS TPM Interface Specification
TNC Trusted Network Connect
TOE Target of Evaluation
TOS Trusted Operating System
TPCA Trusted Platform Computing Alliance
TPM Trusted Platform Module
TPME Trusted Platform Module Entity
TSC Tick Stamp Counter
TSC_ TPM Software Connection, when used as a command prefix
TSN Tick Session Name
TSR Tick Stamp Reset
TSRB TickStampReset for blob
TSS TCG Software Stack
TTP Trusted Third Party/Time-Triggered Protocol
TS Tick Stamp
UTC Universal Time Clock
VPN Virtual Private Network
4 © ISO/IEC 2009 – All rights reserved

4. Conformance
4.1 Introduction
Start of informative comment
The Protection Profile in the Conformance part of the specification defines the threats that are
resisted by a platform. This section, “Protection,” describes the properties of selected capabilities
and selected data locations within a TPM that has a Protection Profile and has not been modified by
physical means.
This section introduces the concept of protected capabilities and the concept of shielded locations
for data. The ordinal set defined in part II and III is the set of protected capabilities. The data
structures in part II define the shielded locations.
• A protected capability is one whose correct operation is necessary in order for the operation of
the TPM Subsystem to be trusted.
• A shielded location is an area where data is protected against interference and prying,
independent of its form.
ISO/IEC 11889 uses the concept of protected capabilities so as to distinguish platform capabilities
that must be trustworthy. Trust in the TPM depends critically on the protected capabilities. Platform
capabilities that are not protected capabilities must (of course) work properly if the TPM Subsystem
is to function properly.
ISO/IEC 11889 uses the concept of shielded locations, rather than the concept of “shielded data.”
While the concept of shielded data is intuitive, it is extraordinarily difficult to define because of the
imprecise meaning of the word “data.” For example, consider data that is produced in a safe
location and then moved into ordinary storage. It is the same data in both locations, but in one it is
shielded data and in the other it is not. Also, data may not always exist in the same form. For
example, it may exist as vulnerable plaintext, but also may sometimes be transformed into a
logically protected form. This data continues to exist, but doesn't always need to be shielded data -
the vulnerable form needs to be shielded data, but the logically protected form does not. If a specific
form of data requires protection against interference or prying, it is therefore necessary to say “if the
data-D exists, it must exist only in a shielded location.” A more concise expression is “the data-D
must be extant only in a shielded location.”
Hence, if trust in the TPM Subsystem depends critically on access to certain data, that data should
be extant only in a shielded location and accessible only to protected capabilities. When not in use,
such data could be erased after conversion (using a protected capability) into another data
structure. Unless the other data structure was defined as one that must be held in a shielded
location, it need not be held in a shielded location.
End of informative comment
1. The data structures described in ISO/IEC 11889-3 MUST NOT be instantiated in a TPM, except
as data in TPM_Shielded-Locations.
2. The ordinal set defined in ISO/IEC 11889-3 and ISO/IEC 11889-4 MUST NOT be instantiated in
a TPM, except as TPM_Protected-Capabilities.
3. Functions MUST NOT be instantiated in a TPM as TPM_Protected-Capabilities if they do not
appear in the ordinal set defined in ISO/IEC 11889-3 or ISO/IEC 11889-4
© ISO/IEC 2009 – All rights reserved 5

4.2 Threat
Start of informative comment
This section, “Threat,” defines the scope of the threats that must be considered when considering
whether a platform facilitates subversion of capabilities and data in a platform.
The design and implementation of a platform determines the extent to which the platform facilitates
subversion of capabilities and data within that platform. It is necessary to define the attacks that
must be resisted by TPM_Shielded-Locations and TPM_Protected-Capabilities in that platform.
The ISO/IEC 11889 standard defines the attacks that are resisted by the TPM. These attacks must
be considered when determining whether the integrity of TPM_Protected-Capabilities and data in
TPM_Shielded-Locations can be damaged. These attacks must be considered when determining
whether there is a backdoor method of obtaining access to TPM_Protected-Capabilities and data in
TPM_Shielded-Locations. These attacks must be considered when determining whether
TPM_Protected-Capabilities have undesirable side effects.
End of informative comment
1. For the purposes of the “Protection” section of the standard, the threats that MUST be
considered when determining whether the TPM facilitates subversion of TPM_Protected-
Capabilities or data in TPM_Shielded-Locations SHALL include
a. The methods inherent in physical attacks that fail if the TPM complies with the “physical
protection” requirements specified by ISO/IEC 11889
b. All methods that require execution of instructions in a computing engine in the platform
4.3 Protection of functions
Start of informative comment
A TPM_Protected-Capability must be used to modify TPM_Protected-Capabilities. Other methods
must not be allowed to modify TPM_Protected-Capabilities. Otherwise, the integrity of
TPM_Protected-Capabilities is unknown.
End of informative comment
1. A TPM SHALL NOT facilitate the alteration of TPM_Protected-Capabilities, except by
TPM_Protected-Capabilities.
4.4 Protection of information
Start of informative comment
TPM_Protected-Capabilities must provide the only means from outside the TPM to access
information represented by data in TPM_Shielded-Locations. Otherwise, a rogue can reveal data in
TPM_Shielded-Locations, or create a derivative of data from TPM_Shielded-Locations (in a way
that maintains some or all of the information content of the data) and reveal the derivative.
End of informative comment
1. A TPM SHALL NOT export data that is dependent upon data structures described in part 3 of
ISO/IEC 11889, other than via a TPM_Protected-Capability.
6 © ISO/IEC 2009 – All rights reserved

4.5 Side effects
Start of informative comment
An implementation of a TPM_Protected-Capability must not disclose the contents of TPM_Shielded-
Locations. The only exceptions are when such disclosure is inherent in the definition of the
capability or in the methods used by the capability. For example, a capability might be designed
specifically to reveal hidden data or might use cryptography and hence always be vulnerable to
cryptanalysis. In such cases, some disclosure or risk of disclosure is inherent and cannot be
avoided. Other forms of disclosure (by side effects, for example) must always be avoided.
End of informative comment
1. The implementation of a TPM_Protected-Capability in a TPM SHALL NOT facilitate the
disclosure or the exposure of information represented by data in TPM-shielded–locations,
except by means unavoidably inherent in the TPM definition.
4.6 Exceptions and clarifications
Start of informative comment
These exceptions to the blanket statements in the generic “protection” requirements (above) are
fully compatible with the intended effect of those statements. These exceptions affect ISO/IEC
11889-data that is available as plain-text outside the TPM and ISO/IEC 11889-data that can be
used without violating security or privacy. These exceptions are valuable because they approve use
of TPM resources by vendor-specific commands in particular circumstances.
These clarifications to the blanket statements of the generic “protection” requirements (above) do
not materially change the effect of those statements, but serve to approve specific legitimate
interpretations of the requirements.
End of informative comment
1. A Shielded Location is a place (memory, register, etc.) where data is protected against
interference and exposure, independent of its form
2. A TPM_Protected-Capability is an operation defined in and restricted to those identified in part 3
and 4 of ISO/IEC 11889
3. A vendor specific command or capability MAY use the standard ISO/IEC 11889 owner/operator
authorization mechanism
4. A vendor specific command or capability MAY utilize a TPM_PUBKEY structure stored on the
TPM so long as the usage of that TPM_PUBKEY structure is authorized using the standard
ISO/IEC 11889 authorization mechanism.
5. A vendor specific command or capability MAY use a sequence of standard ISO/IEC 11889
commands. The command MUST propagate the locality used for the call to the used ISO/IEC
11889 commands or capabilities, or set locality to 0.
6. A vendor specific command or capability that takes advantage of exceptions and clarifications to
the “protection” requirements MUST be defined as part of the security target of the TPM. Such a
vendor specific command or capability MUST be evaluated to meet the Platform Specific TPM
and System Security Targets.
7. If a TPM employs vendor-specific cipher-text that is protected against subversion to the same or
greater extent as internal TPM-resources stored outside the TPM with ISO/IEC 11889-defined
methods, that vendor-specific cipher-text does not necessarily require protection from physical
attack. If a TPM location stores only vendor-specific cipher-text that does not require protection
from physical attack, that location can be ignored when determining whether the TPM complies
with the "physical protection" requirements specified by ISO/IEC 11889.
© ISO/IEC 2009 – All rights reserved 7

5. TPM Architecture
5.1 Interoperability
Start of informative comment
The TPM supports a minimum set of algorithms and operations to meet ISO/IEC 11889 standard.
Algorithms
RSA, normative statements in section 5.2.2.1
SHA-1, normative statements in section 5.2.6
HMAC, normative statements in section 5.2.4
The algorithms and protocols are the minimum that the TPM supports. Additional algorithms and
protocols may be available to the TPM. All algorithms and protocols available in the TPM would be
included in the TPM and platform credential.
The reason to specify these algorithms is two fold. The first is to know and understand the security
properties of selected algorithms; identify appropriate key sizes and ensure appropriate use in
protocols. The second reason is to define a base level of algorithms for interoperability.
End of informative comment
5.2 Components
Start of informative comment
The following is a block diagram Figure 5:a shows the major components of a TPM.

Figure 5:a - TPM Component Architecture
End of informative comment
8 © ISO/IEC 2009 – All rights reserved

5.2.1 Input and Output
Start of informative comment
The I/O component, Figure 5:a C0, manages information flow over the communications bus. It
performs protocol encoding/decoding suitable for communication over external and internal buses. It
routes messages to appropriate components. The I/O component enforces access policies
associated with the Opt-In component as well as other TPM functions requiring access control.
ISO/IEC 11889 does not require a specific I/O bus. Issues around a particular I/O bus are the
purview of a platform specific specification.
End of informative comment
1. The number of incoming operand parameter bytes must exactly match the requirements of the
command ordinal. If the command contains more or fewer bytes than required, the TPM MUST
return TPM_BAD_PARAMETER.
5.2.2 Cryptographic Co-Processor
Start of informative comment
The cryptographic co-processor, Figure 5:a C1, implements cryptographic operations within the
TPM. The TPM employs conventional cryptographic operations in conventional ways. Those
operations include the following:
Asymmetric key generation (RSA)
Asymmetric encryption/decryption (RSA)
Hashing (SHA-1)
Random number generation (RNG)
The TPM uses these capabilities to perform generation of random data, generation of asymmetric
keys, signing and confidentiality of stored data.
The TPM may symmetric encryption for internal TPM use but does not expose any symmetric
algorithm functions to general users of the TPM.
The TPM may implement additional asymmetric algorithms. TPM devices that implement different
algorithms may have different algorithms perform the signing and wrapping.
If the TPM uses RSA with the required key length (2048 bits for storage keys), the output of all
commands for key or data blob generation (e.g., TPM_CreateWrapKey, TPM_Seal, TPM_Sealx,
TPM_MakeIdentity) consists of only one block. However, if the TPM uses other asymmetric
algorithms that result in more than one output block for these commands, the integrity of the blobs
must be protected by the TPM (by means of appropriate chaining mechanisms).
End of informative comment
1. The TPM MAY implement other asymmetric algorithms such as DSA or elliptic curve.
a. These algorithms may be in use for wrapping, signatures and other operations. There is no
guarantee that these keys can migrate to other TPM devices or that other TPM devices will
accept signatures from these additional algorithms.
b. If the output key or data blob generated with a storage key consists of more than one block,
the TPM MUST protect the integrity of the blob by means of appropriate chaining
mechanisms.
2. All storage keys MUST be of strength equivalent to a 2048 bits RSA key or greater. The TPM
SHALL NOT load a storage key whose strength less than that of a 2048 bits RSA key.
3. All AIK MUST be of strength equivalent to a 2048 bits RSA key, or greater.
© ISO/IEC 2009 – All rights reserved 9

5.2.2.1 RSA Engine
Start of informative comment
The RSA asymmetric algorithm is used for digital signatures and for encryption.
For RSA keys the P1363 standard provides the implementation details for digital signature,
encryption and data formats.
There is no requirement concerning how the RSA algorithm is to be implemented. TPM
manufacturers may use Chinese Remainder Theorem (CRT) implementations or any other method.
Designers should review P1363 for guidance on RSA implementations.
ISO/IEC 11889 retains support for 512-bit keys only for the purposes of backwards compatibility
with legacy applications.
End of informative comment
1. The TPM MUST support RSA.
2. The TPM MUST use the RSA algorithm for encryption and digital signatures.
3. The TPM MUST support key sizes of 512, 1024, and 2048 bits. The TPM MAY support other
key sizes.
a. The minimum RECOMMENDED key size is 2048 bits.
4. The RSA public exponent MUST be e, where e = 2 +1.
5. TPM devices that use CRT as the RSA implementation MUST provide protection and detection
of failures during the CRT process to avoid attacks on the private key.
5.2.2.2 Signature Operations
Start of informative comment
The TPM performs signatures on both internal items and on requested external blobs. The rules for
signatures apply to both operations.
End of informative comment
1. The TPM MUST use the RSA algorithm for signature operations where signed data is verified by
entities other than the TPM that performed the sign operation.
2. The TPM MAY use other asymmetric algorithms for signatures; however, there is no
requirement that other TPM devices either accept or verify those signatures.
3. The TPM MUST use P1363 for the format and design of the signature output.
5.2.2.3 Symmetric Encryption Engine
Start of informative comment
The TPM uses symmetric encryption to encrypt authentication information, provide confidentiality in
transport sessions and provide internal encryption of blobs stored off the TPM.
For authentication and transport sessions, the mandatory mechanism is a pseudo one-time-pad with
XOR. The mechanism to generate the one-time-pad is MGF1 and the nonces from the session
protocol. When encrypting authorization data, the authorization data and the nonces are the same
size, 20 bytes, so a direct XOR is possible.
For transport sessions the size of data is larger than the nonces so there needs to be a mechanism
to expand the entropy to the size of the data. The mechanism to expand the entropy is the MGF1
function from P1363. This function provides a known mechanism that does not lower the entropy of
the nonces.
10 © ISO/IEC 2009 – All rights reserved

AES may be supported as an alternate symmetric key encryption algorithm. The mode of use for
AES in the TPM is counter mode and the actions for an operation define what the starting counter
value is.
Internal protection of information can use any symmetric algorithm that the TPM designer feels
provides the proper level of protection.
The TPM does not expose any of the symmetric operations for general message encryption.
End of informative comment
5.2.2.4 Using Keys
Start of Informative comments:
Keys can be symmetric or asymmetric.
As the TPM does not have an exposed symmetric algorithm, the TPM is only a generator, storage
device and protector of symmetric keys. Generation of the symmetric key would use the TPM RNG.
Storage and protection of the symmetric key would be provided by the BIND and SEAL capabilities
of the TPM. If the caller wants to ensure that the release of a symmetric key is not exposed after
UNBIND/UNSEAL on delivery to the caller, the caller should use a transport session with
confidentiality set.
For asymmetric algorithms, the TPM generates and operates on RSA keys. The keys can be held
only by the TPM or in conjunction with the caller of the TPM. If the private portion of a key is in use
outside of the TPM it is the responsibility of the caller and user of that key to ensure the protections
of the key.
The TPM has provisions to indicate if a key is held exclusively for the TPM or can be shared with
entities off of the TPM.
End of informative comments.
1. A secret key is a key that is a private asymmetric key or a symmetric key.
2. Data SHOULD NOT be used as a secret key by a TPM_Protected-Capability unless that data
has been extant only in a shielded location.
3. A key generated by a TPM_Protected-Capability SHALL NOT be used as a secret key unless
that key has been extant only in a shielded location.
4. A secret key obtained by a TPM_Protected-Capability from a Protected Storage blob SHALL be
extant only in a shielded location.
5.2.3 Key Generation
Start of informative comment
The Key Generation component, Figure 5:a C2, creates RSA key pairs and symmetric keys.
ISO/IEC 11889 places no minimum requirements on key generation times for asymmetric or
symmetric keys.
End of informative comment
© ISO/IEC 2009 – All rights reserved 11

5.2.3.1 Asymmetric – RSA
The TPM MUST generate asymmetric key pairs. The generate function is a protected capability and
the private key is held in a shielded location. The implementation of the generate function MUST be
in accordance with P1363.
The prime-number testing for the RSA algorithm MUST use the definitions of P1363. If additional
asymmetric algorithms are available, they MUST use the definitions from P1363 for the underlying
basis of the asymmetric key (for example, elliptic curve fitting).
5.2.3.2 Nonce Creation
The creation of all nonce values MUST use the next n bits from the TPM RNG.
5.2.4 HMAC Engine
Start of informative comment
The HMAC engine, Figure 5:a C3, provides two pieces of information to the TPM: proof of
knowledge of the AuthData and proof that the request arriving is authorized and has no
modifications made to the command in transit.
The HMAC definition is for the HMAC calculation only. It does not specify the order or mechanism
that transports the data from caller to actual TPM.
The creation of the HMAC is order dependent. Each command has specific items that are portions
of the HMAC calculation. The actual calculation starts with the definition from RFC 2104.
RFC 2104 requires the selection of two parameters to properly define the HMAC in use. These
values are the key length and the block size. ISO/IEC 11889 will use a key length of 20 bytes and a
block size of 64 bytes. These values are known in the RFC as K for the key length and B as the
block size.
The basic construct is
H(K XOR opad, H(K XOR ipad, text))
where
H = the SHA1 hash operation
K = the key or the AuthData
XOR = the xor operation
opad = the byte 0x5C repeated B times
B = the block length
ipad = the byte 0x36 repeated B times
text = the message information and any parameters from the command
End of informative comment
The TPM MUST support the calculation of an HMAC according to RFC 2104.
The size of the key (K in RFC 2104) MUST be 20 bytes. The block size (B in RFC 2104) MUST be
64 bytes.
The order of the parameters is critical to the TPM’s ability to recreate the HMAC. Not all of the fields
are sent on the wire for each command for instance only one of the nonce values travels on the
wire. Each command interface definition indicates what parameters are involved in the HMAC
calculation.
12 © ISO/IEC 2009 – All rights reserved

5.2.5 Random Number Generator
Start of informative comment
The Random Number Generator (RNG) component, Figure 6:a C4 is the source of randomness in
the TPM. The TPM uses these random values for nonces, key generation, and randomness in
signatures.
The RNG consists of a state-machine that accepts and mixes unpredictable data and a post-
processor that has a one-way function (e.g. SHA-1). The idea behind the design is that a TPM can
be good source of randomness without having to require a genuine source of hardware entropy.
The state-machine can have a non-volatile state initialized with unpredictable random data during
TPM manufacturing before delivery of the TPM to the customers. The state-machine can accept, at
any time, further (unpredictable) data, or entropy, to salt the random number. Such data comes from
hardware or software sources – for example; from thermal noise, or by monitoring random keyboard
strokes or mouse movements. The RNG requires a reseeding after each reset of the TPM. A true
hardware source of entropy is likely to supply entropy at a higher baud rate than a software source.
When adding entropy to the state-machine, the process must ensure that after the addition, no
outside source can gain any visibility into the new state of the state-machine. Neither the Owner of
the TPM nor the manufacturer of the TPM can deduce the state of the state-machine after shipment
of the TPM. The RNG post-processor condenses the output of the state-machine into data that has
sufficient and uniform entropy. The one-way function should use more bits of input data than it
produces as output.
Our definition of the RNG allows implementation of a Pseudo Random Number Generator (PRNG)
algorithm. However, on devices where a hardware source of entropy is available, a PRNG need not
be implemented. ISO/IEC 11889 refers to both RNG and PRNG implementations as the RNG
mechanism. From a user standpoint, the difference between a RNG and a PRNG is nonexistent.
However, from a designer standpoint the difference between an RNG and PRNG will dictate various
implementation choices. The ISO/IEC 11889 specification does not distinguish between the two
types as the specification does not deal with implementation issues.
The TPM should be able to provide 32 bytes of randomness on each call. Larger requests may fail
with not enough randomness being available.
End of informative comment
1. The RNG for the TPM will consist of the following components:
a. Entropy source and collector
b. State register
c. Mixing function
2. The RNG capability is a TPM_Protected-Capability with no access control.
3. The RNG output may or may not be shielded data. When the data is for internal use by the TPM
(e.g., generation of tpmProof or an asymmetric key), the data MUST be held in a shielded
location. The RNG output for internal use MUST not be known outside the TPM. In particular, it
MUST not be known by the TPM manufacturer. When the data is for use by the TSS or another
external caller, the data is not shielded.
© ISO/IEC 2009 – All rights reserved 13

5.2.5.1 Entropy Source and Collector
Start of informative comment
The entropy source is the process or processes that provide entropy. These types of sources could
include noise, clock variations, air movement, and other types of events.
The entropy collector is the process that collects the entropy, removes bias, and smoothes the
output. The collector differs from the mixing function in that the collector may have special code to
handle any bias or skewing of the raw entropy data. For instance, if the entropy source has a bias of
creating 60 percent 1s and only 40 percent 0s, then the collector design takes that bias into account
before sending the information to the state register.
End of informative comment
1. The entropy source MUST provide entropy to the state register in a manner that provides
entropy that is not visible to an outside process.
a. For compliance purposes, the entropy source MAY be outside of the TPM; however,
attention MUST be paid to the reporting mechanism.
2. The entropy source MUST provide the information only to the state register.
a. The entropy source may provide information that has a bias, so the entropy collector must
remove the bias before updating the state register. The bias removal could use the mixing
function or a function specifically designed to handle the bias of the entropy source.
b. The entropy source can be a single device (such as hardware noise) or a combination of
events (such as disk timings). It is the responsibility of the entropy collector to update the
state register whenever the collector has additional entropy.
5.2.5.2 State Register
Start of informative comment
The state register implementation may use two registers: a non-volatile register rngState and a
volatile register. The TPM loads the volatile register from the non-volatile register on startup. Each
subsequent change to the state register from either the entropy source or the mixing function affects
the volatile state register. The TPM saves the current value of the volatile state register to the non-
volatile register on TPM power-down. The TPM may update the non-volatile register at any other
time. The reasons for using two registers are:
To handle an implementation in which the non-volatile register is in a flash device;
To avoid overuse of the flash, as the number of writes to a flash device are limited.
End of informative comment
1. The state register is in a TPM shielded-location.
a. The state register MUST be non-volatile.
b. The update function to the state register is a TPM protected-capability.
c. The primary input to the update function SHOULD be the entropy collector.
2. If the current value of the state register is unknown, calls made to the update function with
known data MUST NOT result in the state register ending up in a state that an attacker could
know.
a. This requirement implies that the addition of known data MUST NOT result in a decrease in
the entropy of the state register.
3. The TPM MUST NOT export the state regi
...