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
Current Stage
9093 - International Standard confirmed
Completion Date
14-Feb-2017
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 11889-2:2009 - Information technology -- Trusted Platform Module
English language
143 pages
sale 15% off
Preview
sale 15% off
Preview

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 11889-2:2009(E)
©
ISO/IEC 2009

---------------------- Page: 1 ----------------------
ISO/IEC 11889-2:2009(E)
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.


COPYRIGHT PROTECTED DOCUMENT


©  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 copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2009 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 3 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 4 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 5 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 6 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 7 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 8 ----------------------
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

---------------------- Page: 9 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 10 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 11 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 12 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 13 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 14 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 15 ----------------------
ISO/IEC 11889-2:2009(E)
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

---------------------- Page: 16 ----------------------
ISO/IEC 11889-2:2009(E)
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.