Trusted Platform Module LibraryPart 1: Architecture
Family “2.0”Level 00 Revision 01.64
December 24, 2020
Committee Draft
Contact: admin@trustedcomputinggroup.org

Work in ProgressThis document is an intermediate draft for comment
only and is subject to change without notice. Readers
should not design products based on this document.

TCG

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Trusted Platform Module LibraryPart 1: Architecture

Licenses and Notices
Copyright Licenses:•

Trusted Computing Group (TCG) grants to the user of the source code in this specification (the“Source Code”) a worldwide, irrevocable, nonexclusive, royalty free, copyright license toreproduce, create derivative works, distribute, display and perform the Source Code andderivative works thereof, and to grant others the rights granted herein.

•

The TCG grants to the user of the other parts of the specification (other than the Source Code)the rights to reproduce, distribute, display, and perform the specification solely for the purpose ofdeveloping products based on such documents.

Source Code Distribution Conditions:•

Redistributions of Source Code must retain the above copyright licenses, this list of conditions
and the following disclaimers.

•

Redistributions in binary form must reproduce the above copyright licenses, this list of conditions
and the following disclaimers in the documentation and/or other materials provided with the
distribution.

Disclaimers:•

THE COPYRIGHT LICENSES SET FORTH ABOVE DO NOT REPRESENT ANY FORM OF
LICENSE OR WAIVER, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, WITHRESPECT TO PATENT RIGHTS HELD BY TCG MEMBERS (OR OTHER THIRD PARTIES)THAT MAY BE NECESSARY TO IMPLEMENT THIS SPECIFICATION OR OTHERWISE.
Contact TCG Administration (admin@trustedcomputinggroup.org) for information on specification
licensing rights available through TCG membership agreements.

•

THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTIESWHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE, ACCURACY, COMPLETENESS, OR NONINFRINGEMENT OFINTELLECTUAL PROPERTY RIGHTS, OR ANY WARRANTY OTHERWISE ARISING OUT OF
ANY PROPOSAL, SPECIFICATION OR SAMPLE.

•

Without limitation, TCG and its members and licensors disclaim all liability, including liability for
infringement of any proprietary rights, relating to use of information in this specification and to theimplementation of this specification, and TCG disclaims all liability for cost of procurement of
substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential,
direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in
any way out of use or reliance upon this specification or any information herein.

Any marks and brands contained herein are the property of their respective owners.

Page ii
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Change History
Revision 98
Added parameter to MemoryMove(), MemoryCopy(), and MemoryConcat() to make sure that the data
being moved will fix into the receiving buffer
Change the size of local 2B buffers so that they are sized to the sum of the sizes of the elements rather
than any other mathematical construct. This forces the size of the local buffer to track any changes to thesizes of the input components rather than have some assumed relationship.
Made multiple changes to code to eliminate “dead” code (code that could not be reached by any
perturbation of the inputs).
Removed the “+” from the handle parameter in TPM2_HMAC_Start().
Changed TPM_RC_BAD_TAG to 0x01e so that its value would match TPM_BADTAG from 1.2
Changed reference implementation so that it would only allow use of default exponent for creation of RSA
keys. It will allow other exponents for imported keys.
Changed _cpri__GenerateKeyRSA() in CpriRSA.c so that it no longer reads outside the bounds of anarray when getting a value to use for encrypting/decrypting with a key, generated from a seed.
Removed TPM_NV_INDEX entity name space.
Authorization check includes locality.
Revision 99
Added phEnableNV to make NV enable independent of the platform hierarchy enable.
Added TPM2_PolicyNvWritten to permit a policy based on whether or not NV has been written
Added TPM_PT_NV_BUFFER_MAX, the maximum data size in an NV write.
Added define for HCRTM PCR, platform specific
Return code when an NV hierarchy is disabled is TPM_RC_HANDLE.
TPM2_Shutdown state may be nullified on any subsequent command.
CTR mode increments the entire IV, not just 32 bits.
TPM2_PolicySecret cannot have a null authHandle.
Revision 101
Added Definitions for Endorsement Authorization, Owner Authorization, Platform Authorization.
An error may change TPM state under certain conditions.
A restricted signing key cannot have a scheme of TPM_ALG_NULL.
Added TPMS_EMPTY.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page iii
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM2_Sign: The signing scheme hash algorithm determines the size of the hash to be signed. However,this may be removed in a future revision.
TPM2_PCR_Allocate may return an error if the allocation fails.
Revision 103
Added ISO/IEC references and forward.
Handle errors always return TPM_RC_HANDLE, not TPM_RC_HIERARCHY.
TPM_PCR_Allocate does not change allocation for a bank not listed.
For a policy ticket, if expiration is non-negative, a NULL ticket is returned.
Revision 105
Added lockoutPolicy.
Added vendor-specific handles.
Added detection of a clock discontinuity to tickets.
Reworked TPM2_Import description.
Revision 107
Some reworking of H-CRTM, D-RTM.
Some clarification of policy expiration.
Changed references to ISO/IEC standards.
Change PPS, EPS Clear flush resident transient and persistent objects.
Revision 109
Any field upgrade preserves state, not just the standard commands.
Added TPM 2.0 Part 1 description of vendor-specific authorization values.
Refined description of PCR interaction with H-CRTM, TPM2_Startup, and locality. _TPM2_Hash_Start
indicates the start of an H-CRTM sequence, not DRTM.
A non-authorization session must have at least one of encrypt, decrypt, or audit set
A policy session timeout can only change to a shorter value.
Added defines for ECC curves and removed some redundant values in the Part B annex.
TPM2_Sign can use a symmetric key.
TPM2_NV_UndefineSpace fails if TPMA_NV_POLICY_DELETE is set.

Page iv
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Revision 111
TPM2_ContextSave encrypts just the TPM2B_CONTEXT_SENSITIVE structure.
TPM 2.0 Part 2 structures removed algorithms and added notation referring to algorithm registry.
HMAC commands cannot be used with a restricted key.
Revision 113
Clarified Auth Role for hierarchies and NV Index.
Added password check to authorization checks.
Indicated that handles returned by the TPM are TPM_HT_TRANSIENT (three places).
Revision 115
FIPS 186-4 note.
Return codes for tag requires vs. actual mismatch.
Revision 117
A trial session cannot use encrypt or decrypt
HMAC is optional when the HMAC key is the Empty Buffer. If present, it must be correct.
CFB uses sessionValue in the KDF, not sessionKey
FIPS-140 requires NV to be erased when an Index is deleted. NV data must be initialized on a first partial
write.
TPM2_Create for a keyed hash object must have TPM_ALG_NULL if sign and decrypt are both SET or
CLEAR.
For an unrestricted HMAC key, if both the key and parameter have a non-NULL scheme, they mustmatch.
Revision 119
Defined transient object and made the use of object and sequence object more consistent.
Refined the description of an exclusive audit session, the definition of auditReset, and its relationship tothe audit attribute.
Explained that the TPM clock must be accurate even if there is no reliable external clock.
Updated the informative algorithm ID table.
TPM2_HMAC and TPM2_HMAC_Start return code change.
All signing commands, including attestation commands, return TPM_RC_KEY for a non-signing key.
TPM2_SetCommandCodeAuditStatus is not audited when used to change the algorithm.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page v
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Trial policy sessions check authorizations.
DA protection does apply to TPM_RH_LOCKOUT.
Revision 121
continueAuthSession is ignored for a password session.
Reworked NV attributes to accommodate more NV types. Defined TPM_NT.
For a hybrid counter Index, the first write always writes through to NV memory.
Added ECC point padding description.
Unmarshaling routines return error code, not bool. Detailed CommandDispatcher parameters. Unmarshal
flag set means null is permitted.
The algorithm ID table in this specification is informative.
Context gap must be 2^^n-1.
Handle type 0x03 is for saved sessions, not active session.
Timeout is of length TPM2B_DIGEST, not UINT64.
nullProof can be used in a ticket.
TPM2_EncryptDecrypt uses an unrestricted key. The sign attribute is used as an encrypt attribute. A nonnull mode cannot be overridden.
A TPM2_PolicySecret being satisfied by a policy requires a password or auth value. The object must
permit password or HMAC authorization.
TPM2_PolicyNV is an immediate assertion.
Revision 122
NULL password can have continue set or clear.
Sign attribute becomes encrypt attribute for a symmetric cipher object.
Saved context metadata is normative. Encrypted data is vendor specific.
TPMU_SYM_MODE, TPMS_SCHEME_XOR selector permits NULL.
If the session requires a policy session, returns TPM_RC_AUTH_TYPE.
TPM2_NV_Certify returns TPM_RC_NV_UNINITIALIZED if unwritten even if size is zero.
Revision 123
Advised that callers should not use NV read public to calculate the Name.
Removed advice that FIPS may require an authValue size of half the hash algorithm digest size.

Page vi
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Clarified that nonceTPM is only used once in an HMAC calculation when the session is being used forboth encrypt and decrypt.
Clarified that authValue is an Empty Buffer if a session is not an authorization session.
Clarified that sessionValue for authorization sessions that are encrypt or decrypt sessions is sessionKey ||authValue regardless of binding.
Clarified that nameAlg is the authPolicy hash algorithm.
Structure definition lower limits apply to TPM inputs. Upper limits refer to inputs and outputs.
The year and day of year can indicate an errata date.
TPM_RC_NONCE is returned for a nonce value mismatch.
TPMS ALGORITHM_DETAIL_ECC kdf can be TPM_ALG_NULL.
TPMS_CONTEXT savedHandle indicates the context type.
If a handle in handle area references a session and the session is not present, returns
TPM_RC_REFERENCE_H0 + N.
Clarified that the size of an encrypted parameter can be zero.
TPM2_Startup can result in the PCR update counter non-zero because of PCR resets.
For RSA salt key, the size of an encrypted salt must be the same as the size of the public modulus.
TPM2_ECDH_KeyGen requires restricted CLEAR and decrypt SET.
TPM2_Commit does not require the sign attribute.
TPM_PolicyOR extends the digest into a Zero Digest PolicyDigest. It does not replace the digest.
TPM2_PolicyPCR with a trial policy may use the TPM PCR if the caller does provide PCR settings.
TPM2_PolicyNV, TPM2_PolicyCounterTimer, TPM2_NV_Certify, can return TPM_RC_VALUE if theoffset is greater than the data size.
Indicated that the reference implementation can do compare operations on a structure using a cast to abyte array, so unmarshaling code must initialize input buffers.
Revision 124
This revision begins to implement the NV PIN Index type. The information is incomplete and subject tochange. It is included as a work in progress rather than create two forks to the specification.
Clarified that TPM2B_DATA is the size of a TPMT_HA but is not required to contain an algorithm ID.
Clarified that time can be set to zero at _TPM_Init or TPM2_Startup.
TPM2_StartAuthSession rejects a symmetric salt key.
Revision 125
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page vii
December 24, 2020

Trusted Platform Module LibraryPart 1: ArchitectureContinued specifying NV PIN Index. The information is complete but not reviewed and still subject tosignificant changes.
Session-based encryption should support XOR, but a block cipher is platform specific.
Added TPM_PT_MODES for FIPS and other indications. Added TPMA_MODES.
Clarified the TPMA_STARTUP_CLEAR attribute (enable flags) settings on the various startup types.
_PRIVATE

structure - changed from TPMT_SENSITIVE to TPM2B_SENSITIVE.

Revision 126
Reworded the PIN Index and rewrap text.
Added restrictions on unique input for TPM2_Create and TPM2_CreatePrimary.Removed obsolete
TPM_CC_PP_FIRST and TPM_CC_PP_LAST.
Revision 127
Removed symmetric salt.
Revision 128
sensitiveDataOrigin is set for an asymmetric object.
Clarified that only the template unique field may be altered when an object is created.
A PIN index can be used in TPM2_PolicySecret if read or write locked.
ehProof is changed on TPM2_Clear.
TPM2_SetPrimaryPolicy requires a policy length consistent with the hash algorithm.
Revision 130
Augmented clause 27.1 “Object Creation / Introduction” by adding the table “Creation Commands” and a
description of that table.
Augmented clause 27.6.1 “Entropy Creation / Introduction” by adding the table “Deriving Cryptographic
Values” and a description of that table.
Added TPM2_PolicyTemplate(), TPM2_CreateLoaded(), TPMI_DH_PARENT.
Revision 131
Added TPM2_PolicyAuthorizeNV(), TPM2_EncryptDecrypt2().
Noted that TPM2_Create() may require transient resources.
TPM2_Clear() increments the pcrUpdateCounter, permitting a policy that can be invalidated on
TPM2_Clear().
TPM_PT_NV_BUFFER_MAX returns the maximum size for NV read and NV certify as well as NV write,

Page viii
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Noted that TPMA_NV_POLICY_DELETE with a policy that cannot be satisfied defines an Index that cannever be deleted.
TPM2_NV_Read ignores offset for bits and counter indexes.
Revision 132
Reworked Part 4 for refactored crypto code merge.
Added application note on audit alternative.
Added command code for PolicyAuthorizeNV and EncryptDecrypt2.
Added getcapability TPM_CAP_AUTH_POLICIESTPMS_TAGGED_POLICY.

for

hierarchy

policies,

and

new

structure

Offset is ignored when reading counter and bits NV indexes.
ReadClock can have audit session.
Revision 133
Added additional option to ticket expiration, and timeEpoch.
TPM2B_PRIVATE always has authorization value padded.
Clarified GPIO inputs and outputs.
EC Schnorr computation changes.
Salt always uses OAEP.
KDF must reject weak keys.
Revision 134
TPM2_Create for a fixedParent storage key only requires the symmetric algorithm of the parent and childto match.
Policy ticket creation also digests the timeEpoch.
Revision 135
Weak symmetric keys will not be generated and cannot be loaded.
OAEP uses the object's scheme. If the object's scheme is TPM_ALG_NULL, uses the objects Namealgorithm.
GPIO input and output settings are platform or vendor specific.
Added a TPM2_Create, etc. reference code error check if data objects have sensitiveDataOrigin SET.
The normative text was correct.
Revision 135 June 20
Modified the ECDAA signature calculation
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page ix
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Revision 136
Added PolicyAuthorize definition.
Noted that weak symmetric keys are not permitted.
OAEP uses the key's scheme unless it is NULL
Modifications to the ECDAA sign operation.
Parents use CFB mode, and cannot have a NULL symmetric algorithm
The salt key scheme must be NULL or OAEP.
Revision 137
Updated the interaction between nonceTPM and expiration.
data may be a non - Empty Buffer when a primary key is created.
TPM2_PolicySecret() referencing a PIN Pass Index returns a NULL ticket.
TPM2_SelfTest returns TPM_RC_FAILURE on failure.
phEnableNV is set on TPM Reset or TPM Restart
TPM2_Create and TPM2_CreatePrimary input is actually TPM2_PUBLIC even though the parametersays TPM2_TEMPLATE.
TPM2_PolicySecret for PIN and non-PIN Index clarifications.
TPM2_PolicyNV, TPM2_NV_Read, TPM2_NV_Certify may ignore offset parameter.
TPM2_NV_GlobalWriteLock, TPM2_NV_ReadLock may write NV.
Part 4 added SelfTest.h, Simulator_fp.h, removed CryptEccData.c,
Part 4 updated TPM2B structure sample.
Revision 138
Added back expiration comment that timeout cannot become smaller.
Explained the result of TPM_CAP_AUTH_POLICIES.
Removed obsolete CommandDispatcher.h and HandleProcess.h.
Revision 139
Revision 140
Added Attached Component (AC Send) description, structures, and functions.
TPM2_ECC_Parameters() may zero pad results.
TPM2_DictionaryAttackParameters does not reset failedTries.
Page x
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Revision 141
Clarified that the KDFa 0x00 byte is only explicitly added if Label is not present or if it is not NULLterminated.
Clarified that recoveryTIme may be tracked through a shutdown.
Added TDES annex explaining parity generation.
Revision 142
Code merge with 141.
Revision 143
Clarified HMAC key calculation for bound policy session with and without TPM2_PolicyAuthValue. Similar
clarification for encrypted policy session.
Added the TPM2_MAC commands
TPMI_ALG_MAC_SCHEME.

andmergedwith

TPM2_HMAC

commands.

Added

Changed TPM2B_TIMEOUT back to a UINT64.
TPM2_FlushContext for sessions ignores the upper byte of the handle.
Revision 144
Minor updates for TPM2_MAC.
Added TPMI_ALG_CIPHER_MODE, used for EncryptDecrypt.
Salt key must be a decrypt key.
seedValue is the size of the nameAlg digest.
Revision 145
More informative explanation. No normative changes.
Revision 146
Typos and fonts. No normative changes
Revision 147
Field upgrade should preserve the TPM vendor provisioned EKs.
Salt can only use asymmetric key encryption.
Alternative implementation of failedTries on non-orderly shutdown.
Added description of entropy usage for derived objects.
Alternate implementations for NV counter index initialization.
TPM_PT_NV_COUNTERS_MAX - zero value indicates no specified maximum.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xi
December 24, 2020

Trusted Platform Module Library
Added TPMI_DH_SAVED
TPM2_FlushContext.

forPart 1: Architecture
handlevalues

that

can

be

used

in

TPM2_ContextSaveor

TPMS_SCHEME_XOR cannot have a NULL hash algorithm
TPM2_PolicyTemplate() error codes if command is sent twice or if cpHash is already set.
CryptSym.h added to Part 4.
Revision 148
Reworked the attestation key certification to indicate that an encrypted challenge response is a more
likely use case than an encrypted certificate.
Field upgrade should not affect TPM2_CreatePrimary() outputs under certain conditions.
The reset of the TIme circuit is related to TPM power, not TPM_Init.
MAX_SYM_DATA 128 changed from shall to should.
sign and decrypt both CLEAR or SET and scheme not TPM_ALG_NULL returns TPM_RC_SCHEME.
TPM2_PCR_Allocate() takes effect at _TPM_Init(), not TPM2_Startup().
Clarified in the text (the code was correct) that TPM2_PolicyDuplicationSelect() Names do not include thesize.
The TPM may enter Failure mode if TPM2_Startup() is not TPM_SU_CLEAR after an algorithm setchange that affects PCR banks. It was previously not a may.
After a field upgrade, preserving seeds, etc. was changed from shall to should.
Revision 149
Part 1 added phEnableNV to STATE_CLEAR_DATA, clearCount increments on TPM Restart, not TPM
ResumeNoted that TPM2_EventSequenceComplete() always returns all hashes.
Noted that TPM2_PCR_Allocate() requirement for TPM_SU_CLEAR only applies until after the next
_TPM_Init.
Part 4: For code merge: Added KdfTestData.h. Deleted BnEccData.c. Changed CryptDataEcc.c to
CryptEccData.c
Revision 150
Added some notes about the interaction between audit and parameter encryption. Clarified that the audit
digest is a single hash of cpHash and rpHash.
The random commit value has to be at least equal to the security strength of the signing key. KDFa forthe commit calculation uses vendorAlg, not nameAlg.
+ decoration only applies to command parameters, not response parameters.
TPM2_Startup() does not clear the written bit for an orderly counter Index.
Page xii
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryRemoved CryptHashData.h.
Revision 151
TPM2_Hash() and TPM2_SequenceComplete() creates a ticket, with an Empty digest if in the NULL
hierarchy.
TPM2_VerifySignature() returns a ticket with an Empty digest if the key is in the NULL hierarchy.
Updated ECC key generation and point padding in the Part 1 annex.
The TPM_PT_PS_REVISION value is platform specific.
Moved implementation specific description of the Clock Safe flag to an example.
Clarified that the getcapability returning TPML_PCR_SELECTION must return a selection for allocatedbanks but can return additional selections.
Revision 152
Added a first draft of TPM2_CertifyX509().
Revision 153
C.5 ECC Key Generation changed d to c and G to Q.
TPM2B_PRIVATE_KEY_RSA is permitted to be larger for fixedTPM keys. the TPM2B_PRIVATE
structure in TPM2_Create() and TPM2_Load() may contain five CRT primes (instead of one).
Assign TPM_CC_CertifyX509 command code, x509Sign attribute, TPMA_X509_KEY_USAGE, Add
TPM2_CertifyX509 description, parameters, and actions.
Define NV digest attestation structure, TPMS_NV_DIGEST_CERTIFY_INFO, and added certifying an NV
digest to TPM2_NV_Certify.
Revision 154
Clarify that label in KDFa is an octet stream and the conditions for the KDFa zero byte.
Clarify the required size of an object sensitive area seedValue for TPM generated and imported objects.
Clarify that the L parameter in OAEP is a byte stream with the last byte zero, not a null terminated string.
Add an Annex with a Library Profile Guide.
Clarify that TPM_PT_NV_BUFFER_MAX applies to NV extend or NV certify.
The TPMA_X509_KEY_USAGE keyAgreeement and encipherOnly attributes require the decrypt
attribute.
Explain that most of TPM2_SetAlgorithmSet is vendor-dependent.
Explain that the initialization of the list of commands requiring physical presence is platform-specific.
Revision 155
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xiii
December 24, 2020

Trusted Platform Module LibraryPart 1: ArchitecturePart 2 removed , S AND <IO> from several table titles.
TPM_ECC_CURVE add + to TPM_ECC_NONEPart 4 added files for X.509 support: OIDS.h, MinMax.h, and AC support: AC_spt.c
Changed Implementation.h to TpmProfile.h and added a pointer in TpmBuildSwitches.h to preset thevalues.
Revision 156
Added the ACT feature.
Explained that the TPM2_CertifyX509 partialCertificate and addedToCertificate are a DER encoded
SEQUENCEs. Explained the encoding of the TPMA_OBJECT element. Noted that tbsDigest is returned
as a debugging aid. Changed qualifyingData to reserved and that it must be an Empty Buffer.
Added a requirement that, if a command resets PCR in multiple banks, the PCR Update Counter must be
incremented only once. If a command causes PCR in multiple banks to change, the PCR Update Countermust be incremented once for each bank.
Revision 157
Added the ACT code.
Revision 158
Minor updates to the ACT description.
Revision 159
Added several missing source code files to Part 4.
Reversed the TPMA_X509_KEY_USAGE bit map.
Revision 160
Add a note about a reference implementation not handling failedTries correctly in a non-orderly shutdown,
Add a note about a reference implementation handling the PIN Pass and PIN Fail pinCount incorrectly
when the index was authorized with a policy session.
ACT: preserveSignaled is a state reflecting signaled, not a TPM attribute. TPM2_Startup clears ACT
items. TPM2_ACT_SetTimeout clears preservedSignaled.
Revision 161
Based on a proposal from Greater China Regional Forum (GCRF) members, this revision adds SM2
encryption/decryption support. The suggestion to add this capability was received by TCG as acomment from the ISO/IEC JTC 1 Chinese National Body on the Final Draft International Standard ballot
for ISO/IEC 11889:2015.
Revision 162
Documented the policy session context values and which ones are shared. Observed that a policy
session cannot be used for session audit.
Page xiv
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Explained that TPM2_CrealeLoaded() can create child keys with the same key but different attributes.
Reworked the ACT preserveSignaled behavior on a power cycle.
Reworded the Part 2 TPMA_NV_AUTHWRITE and TPMA_NV_READ descriptions to match the otherattributes. The behavior does not change.
Revision 163
The RSASSA_PSS salt size is now the largest size permitted by FIPS 186-4. A note explains that older
TPMs may use a different maximum size.
Updated SMx specification numbers and titles
TPM_RC_AUTH_FAIL is returned when lockoutAuth is disabled.
TPM2_PolicySecret
returns
TPM_RC_AUTH_UNAVAILABLE
for
an
NV
TPMA_NV_AUTHREAD CLEAR. The command will increment an NV Index pinCount.

Index

with

TPM2_Startup with a TPM Reset changes nullProof and nullSeed.
Revision 164(This revision has many changes throughout to conform to ISO requirements for wording and formatting.
None affected the TPM operation.)
Observe that a saved sequence object does not have replay protection.
TPM2_Quote may return TPM_RC_SCHEME is signhandle is NULL.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xv
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Acknowledgements
The writing of a specification, particularly a security specification, takes many hours for both development
and review. This specification is no exception with roughly 100 individuals involved in the process. The
TCG would like to acknowledge the contribution of those individuals (listed below) and the companies
who allowed them to volunteer their time to the development of this specification.
The TCG would like to acknowledge the special contribution of David Wooten in the development of the
TPM 2.0 architecture and documentation of this specification. We also acknowledge the generosity ofMicrosoft in contributing the code in this specification, written by David Wooten, Jiajing Zhu, and PaulEngland.
Special thanks are due to David Challener, David Wooten, Julian Hammersley, Graeme Proudler, and Ari
Singer who served as Chair of the TPM Working Group at different times during the development of thisspecification.
The TCG would also like to give special thanks to David Grawrock, David Wooten, and Ken Goldman,
who were the editors of this specification.

Page xvi
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Contributors:
Loic Duflot; ANSSI
Frederic Guihery; AMOSSYS
Ralf Findeisen; AMD
Julian Hammersley; AMD
Dean Liberty; AMD
Ron Perez; AMD
Emily Ratliff; AMD
Gary Simpson; AMD
Gongyuan Zhuang; AMD
John Mersh; ARM Ltd.
Kerry Maletsky; Atmel
Randy Mummert; Atmel
Ronnie Thomas; Atmel
Douglas Allen; Broadcom
Chares Qi; Broadcom
Daniel Nowack; BSI
Florian Samson; BSI
Bill Lattin; Certicom
Matt Harvey; CESGPaul Waller; CESG
Bob Bell; Cisco
Bill Jacobs; Cisco
Rafael Montalvo; Cisco
Frank Mosberry; Dell
Amy Nelson; Dell
Ari Singer; DMI
Sigrid Gürgens; Fraunhofer SIT
Andreas Fuchs: Fraunhofer SIT
Carsten Rudolph; Fraunhofer SIT
Carline Covey; Freescale Semiconductor
Ira McDonald; High North
Vali Ali; Hewlett Packard
Liqun Chen; Hewlett Packard
Carey Huscroft; Hewlett Packard
Wael Ibrahim; Hewlett Packard
Graeme Proudler; Hewlett Packard

Ludovic Jacquin, Hewlett Packard Enterprise
Ken Goldman; IBM
Hans Brandl; Infineon
Hubert Braunwarth; Infineon
Ga-Wai Chin; Infineon
Roland Ebrecht; Infineon
Markus Gueller; Infineon
Ralph Hamm; Infineon
Georg Rankl; Infineon
Will Arthur; Intel
Ernie Brickell; Intel
Alex Eydelberg; IntelDavid Grawrock; Intel
Jiangtao Li; IntelDavid Riss; Intel
Ned Smith; Intel
Claire Vishik; Intel
Monty Wiseman; Intel
Igor Slutsker; Intel
Liran Perez; IntelZecharye Galitzky; Intel
Joshua Su; ITEDavid Challener; Johns Hopkins APL

Family “2.0”Level 00 Revision 01.64

Huang Qian; Lenovo
Ronald Aigner; Microsoft
Jing De Jong-Chen; Microsoft
Shon Eizenhoefer; Microsoft
Carl Ellison; Microsoft
Paul England; Microsoft
Leonard Janke; Microsoft
Richard Korry; Microsoft
Jork Loeser; Microsoft
Andrey Marochko; Microsoft
Jim Morgan; Microsoft
Dennis Mattoon; Microsoft
Himanshu Raj; Microsoft
David Robinson; Microsoft
Rob Spiger; Microsoft
Stefan Thom; Microsoft
Mark Williams; Microsoft
David Wooten; Microsoft
Jiajing Zhu; Microsoft
Luis Samenta; MIT
Ariel Segall; MITRE
Nataly Kremer; M-Systems Flash
Andrew Regenscheid; NIST
Qin Fan; Nationz
Jay Liang; Nationz
Xin Liu; Nationz
Jan-Erik Ekberg; Nokia
Michael Cox; NTRU
Nick Howgrave-Graham; NTRU
William Whyte; NTRU
Leooid Asriel; Nuvoton
Dan Morav; Nuvoton
Erez Naory; Nuvoton
Oren Tanami; Nuvoton
Dennis Huage; NVIDIA
Whllys Ingersoll; Oracle
Scott Rotondo; Oracle
Timothy Markey; Phoenix
Anders Rundgren; PrimeKey Solutions
Laszlo Elteto; Safenet
Michael Willet; Seagate
Olivier Collart; STMicroelectronics
Miroslav Dusek; STMicroelectronics
Jan Smrcek; STMicroelectronics
Mohamed Tabet; STMicroelectronics
Paul Sangster; Symantec
Jerome Quevremont; Thales
Mark Ryan; University of Birmingham
Mike Boyle; US Department of Defense
Stanley Potter; US Department of Defense
Sandi Roddy; US Department of Defense
Adrian Stanger; US Department of Defense
Kelvin Li; VIA
Nick Bone; Vodafone
Mihran Dars; Wave Systems
Thomas Hardjono; Wave Systems
Greg Kazmierczak; Wave Systems
Len Veil; Wave Systems

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xvii
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

CONTENTSCONTENTS .............................................................................................................................................. xviii
TABLES..................................................................................................................................................... xxix
FIGURES ................................................................................................................................................... xxx
Scope .................................................................................................................................................... 1
Specification Organization..................................................................................................................... 2
Normative references ............................................................................................................................ 3
Terms and definitions ............................................................................................................................ 5
Symbols and Abbreviated Terms ........................................................................................................ 15
5.1
5.2

Symbols ........................................................................................................................................ 15
Abbreviations ................................................................................................................................ 15

Compliance ......................................................................................................................................... 18
Conventions ........................................................................................................................................ 19
7.1
7.2
7.3

Bit and Octet Numbering and Order ............................................................................................. 19
Sized Buffer References ............................................................................................................... 19
Numbers ....................................................................................................................................... 19

Changes from Previous Versions ........................................................................................................ 21
Trusted Platforms ................................................................................................................................ 22
9.1
9.2

Trust .............................................................................................................................................. 22
Trust Concepts.............................................................................................................................. 22
Trusted Building Block.......................................................................................................... 22
Trusted Computing Base...................................................................................................... 22
Trust Boundaries .................................................................................................................. 22
Transitive Trust..................................................................................................................... 23
Trust Authority ...................................................................................................................... 23

9.3
9.4

Trusted Platform Module .............................................................................................................. 24
Roots of Trust ............................................................................................................................... 24
Introduction ........................................................................................................................... 24
Root of Trust for Measurement (RTM) ................................................................................. 25
Root of Trust for Storage (RTS) ........................................................................................... 25
Root of Trust for Reporting (RTR) ........................................................................................ 25

9.5

Basic Trusted Platform Features .................................................................................................. 26
Introduction ........................................................................................................................... 26
Certification .......................................................................................................................... 26
Attestation and Authentication ............................................................................................. 27
Protected Location ............................................................................................................... 30
Integrity Measurement and Reporting .................................................................................. 30

TPM Protections .................................................................................................................................. 32
10.1
10.2
10.3
10.4

Introduction ................................................................................................................................... 32
Protection of Protected Capabilities ............................................................................................. 32
Protection of Shielded Locations .................................................................................................. 32
Exceptions and Clarifications........................................................................................................ 32

TPM Architecture................................................................................................................................. 34
11.1

Introduction ................................................................................................................................... 34

Page xviii
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
11.2
11.3
11.4

Trusted Platform Module Library

TPM Command Processing Overview .......................................................................................... 34
I/O Buffer....................................................................................................................................... 38
Cryptography Subsystem ............................................................................................................. 38
Introduction ........................................................................................................................... 38
Symmetric Block Cipher MAC Algorithms ............................................................................ 38
Hash Functions .................................................................................................................... 38
HMAC Algorithm ................................................................................................................... 39
Asymmetric Operations ........................................................................................................ 39
Signature Operations ........................................................................................................... 40
Symmetric Encryption .......................................................................................................... 42
Extend .................................................................................................................................. 43
Key Generation .................................................................................................................... 44
Key Derivation Function ....................................................................................................... 44
Random Number Generator (RNG) Module ........................................................................ 48
Algorithms ............................................................................................................................ 50

11.5
11.6

Authorization Subsystem .............................................................................................................. 51
Random Access Memory.............................................................................................................. 51
Introduction ........................................................................................................................... 51
Platform Configuration Registers (PCR) .............................................................................. 51
Object Store ......................................................................................................................... 52
Session Store ....................................................................................................................... 53
Size Requirements ............................................................................................................... 53

11.7
11.8

Non-Volatile (NV) Memory ............................................................................................................ 53
Power Detection Module............................................................................................................... 54

TPM Operational States ...................................................................................................................... 55
12.1
12.2

Introduction ................................................................................................................................... 55
Basic TPM Operational States...................................................................................................... 55
Power-off State ..................................................................................................................... 55
Initialization State ................................................................................................................. 55
Startup State ........................................................................................................................ 56
Shutdown State .................................................................................................................... 58
Startup Alternatives .............................................................................................................. 59

12.3
12.4
12.5

Self-Test Modes ............................................................................................................................ 60
Failure Mode ................................................................................................................................. 61
Field Upgrade ............................................................................................................................... 62
Introduction ........................................................................................................................... 62
Field Upgrade Mode ............................................................................................................. 62
Preserved TPM State ........................................................................................................... 65
Field Upgrade Implementation Options................................................................................ 66

TPM Control Domains ......................................................................................................................... 67
13.1
13.2
13.3
13.4
13.5
13.6

Introduction ................................................................................................................................... 67
Controls......................................................................................................................................... 67
Platform Controls .......................................................................................................................... 68
Owner Controls ............................................................................................................................. 69
Privacy Administrator Controls ..................................................................................................... 69
Primary Seed Authorizations ........................................................................................................ 70

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xix
December 24, 2020

Trusted Platform Module Library
13.7
13.8

Part 1: Architecture

Lockout Control ............................................................................................................................. 70
TPM Ownership ............................................................................................................................ 71
Taking Ownership ................................................................................................................ 71
Releasing Ownership ........................................................................................................... 71

Primary Seeds ..................................................................................................................................... 73
14.1
14.2
14.3

Introduction ................................................................................................................................... 73
Rationale ....................................................................................................................................... 73
Primary Seed Properties............................................................................................................... 74
Introduction ........................................................................................................................... 74
Endorsement Primary Seed (EPS) ...................................................................................... 75
Platform Primary Seed (PPS) .............................................................................................. 75
Storage Primary Seed (SPS) ............................................................................................... 76
The Null Seed ....................................................................................................................... 76

14.4

Hierarchy Proofs ........................................................................................................................... 76

TPM Handles ....................................................................................................................................... 78
15.1
15.2
15.3
15.4
15.5
15.6
15.7

Introduction ................................................................................................................................... 78
PCR Handles (MSO=0016) ............................................................................................................ 78
NV Index Handles (MSO=0116) .................................................................................................... 78
Session Handles (MSO=0216 and 0316) ........................................................................................ 78
Permanent Resource Handles (MSO=4016) ................................................................................. 79
Transient Object Handles (MSO=8016) ......................................................................................... 79
Persistent Object Handles (MSO=8116) ........................................................................................ 80

Names ................................................................................................................................................. 81
PCR Operations .................................................................................................................................. 82
17.1
17.2
17.3
17.4
17.5
17.6

Initializing PCR.............................................................................................................................. 82
Extend of a PCR ........................................................................................................................... 82
Using Extend with PCR Banks ..................................................................................................... 82
Recording Events ......................................................................................................................... 83
Selecting Multiple PCR ................................................................................................................. 83
Reporting on PCR ......................................................................................................................... 84
Reading PCR ....................................................................................................................... 84
Attesting to PCR ................................................................................................................... 84

17.7

PCR Authorizations ...................................................................................................................... 85
PCR Not in a Set .................................................................................................................. 85
Authorization Set .................................................................................................................. 85
Policy Set ............................................................................................................................. 86
Order of Checking ................................................................................................................ 86

17.8 PCR Allocation .............................................................................................................................. 86
17.9 PCR Change Tracking .................................................................................................................. 87
17.10 Other Uses for PCR ...................................................................................................................... 87
TPM Command/Response Structure .................................................................................................. 88
18.1
18.2

Introduction ................................................................................................................................... 88
Command/Response Header Fields ............................................................................................ 89
tag......................................................................................................................................... 90

Page xx
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibrarycommandSize/responseSize ................................................................................................ 90
commandCode ..................................................................................................................... 90
responseCode ...................................................................................................................... 90
18.3
18.4
18.5
18.6

Handles ......................................................................................................................................... 90
Parameters ................................................................................................................................... 91
authorizationSize/parameterSize .................................................................................................. 91
Authorization Area ........................................................................................................................ 92
Introduction ........................................................................................................................... 92
Authorization Structure ......................................................................................................... 93
Session Handles .................................................................................................................. 94
Session Attributes (sessionAttributes) ................................................................................. 94

18.7 Command Parameter Hash (cpHash) .......................................................................................... 96
18.8 Response Parameter Hash (rpHash) ........................................................................................... 97
18.9 Command Example ...................................................................................................................... 97
18.10 Response Example ....................................................................................................................... 99
Authorizations and Acknowledgments .............................................................................................. 100
19.1
19.2
19.3
19.4
19.5
19.6

Introduction ................................................................................................................................. 100
Authorization Roles ..................................................................................................................... 100
Physical Presence Authorization ................................................................................................ 101
Password Authorizations ............................................................................................................ 102
Sessions ..................................................................................................................................... 103
Session-Based Authorizations .................................................................................................... 103
Introduction ......................................................................................................................... 103
Authorization Session Formats .......................................................................................... 104
Session Nonces ................................................................................................................. 104
Authorization Values .......................................................................................................... 106
HMAC Computation ........................................................................................................... 106
Note on Use of Nonces in HMAC Computations ............................................................... 108
Starting an Authorization Session ...................................................................................... 108
sessionKey Creation .......................................................................................................... 109
Unbound and Unsalted Session Key Generation .............................................................. 109
Bound Session Key Generation ......................................................................................... 110
Salted Session Key Generation ......................................................................................... 113
Salted and Bound Session Key Generation ....................................................................... 114
Encryption of salt ................................................................................................................ 115
Caution on use of Unsalted Authorization Sessions .......................................................... 115
No HMAC Authorization ..................................................................................................... 116
Authorization Selection Logic for Objects .......................................................................... 116
Authorization Session Termination .................................................................................... 117

19.7

Enhanced Authorization.............................................................................................................. 117
Introduction ......................................................................................................................... 117
Policy Assertion .................................................................................................................. 118
Policy AND ......................................................................................................................... 118
Policy OR ........................................................................................................................... 120
Order of Evaluation ............................................................................................................ 122
Policy Session Creation ..................................................................................................... 122
Policy Assertions (Policy Commands) ............................................................................... 123

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xxi
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Policy Session Context Values .......................................................................................... 126
Policy Example ................................................................................................................... 128
Trial Policy .......................................................................................................................... 128
Modification of Policies ....................................................................................................... 128
TPM2_PolicySigned(), TPM2_PolicySecret(), and TPM2_PolicyTicket() .......................... 130
Use of TPM for authPolicy Computation ............................................................................ 132
Trial Policy Session ............................................................................................................ 132
Use of TPM2_PolicySigned() and TPM2_PolicySecret() without nonceTPM .................... 133
19.8

Dictionary Attack Protection........................................................................................................ 133
Introduction ......................................................................................................................... 133
Lockout Mode Configuration Parameters........................................................................... 134
Lockout Mode ..................................................................................................................... 135
Recovering from Lockout Mode ......................................................................................... 135
Authorization Failures Involving lockoutAuth ..................................................................... 135
Non-orderly Shutdown........................................................................................................ 136
Justification for Lockout Due to Session Binding ............................................................... 136
Sample Configurations for Lockout Parameters ................................................................ 137

Audit Session .................................................................................................................................... 138
20.1
20.2
20.3
20.4
20.5
20.6

Introduction ................................................................................................................................. 138
Exclusive Audit Sessions ............................................................................................................ 139
Command Gating Based on Exclusivity ..................................................................................... 139
Audit Session Reporting ............................................................................................................. 139
Audit Establishment Failures ...................................................................................................... 140
Audit Alternative .......................................................................................................................... 140

Session-based encryption ................................................................................................................. 141
21.1
21.2
21.3

Introduction ................................................................................................................................. 141
XOR Parameter Obfuscation ...................................................................................................... 142
CFB Mode Parameter Encryption ............................................................................................... 142

Protected Storage ............................................................................................................................. 144
22.1
22.2
22.3
22.4
22.5

Introduction ................................................................................................................................. 144
Object Protections ...................................................................................................................... 144
Protection Values ........................................................................................................................ 144
Symmetric Encryption ................................................................................................................. 145
Integrity ....................................................................................................................................... 145

Protected Storage Hierarchy ............................................................................................................. 148
23.1
23.2
23.3

Introduction ................................................................................................................................. 148
Hierarchical Relationship between Objects ................................................................................ 148
Duplication .................................................................................................................................. 149
Definition ............................................................................................................................ 149
Protections ......................................................................................................................... 150
Rewrap ............................................................................................................................... 155

23.4
23.5
23.6
23.7

Duplication Group ....................................................................................................................... 158
Protection Group ......................................................................................................................... 159
Summary of Hierarchy Attributes ................................................................................................ 160
Primary Seed Hierarchies ........................................................................................................... 161

Page xxii
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Credential Protection ......................................................................................................................... 162
24.1
24.2
24.3
24.4
24.5
24.6

Introduction ................................................................................................................................. 162
Protocol ....................................................................................................................................... 162
Protection of Credential .............................................................................................................. 162
Symmetric Encrypt ...................................................................................................................... 163
HMAC ......................................................................................................................................... 163
Summary of Protection Process ................................................................................................. 164

Object Attributes ................................................................................................................................ 165
25.1

Base Attributes............................................................................................................................ 165
Introduction ......................................................................................................................... 165
Restricted Attribute ............................................................................................................. 165
Sign Attribute ...................................................................................................................... 165
Decrypt Attribute................................................................................................................. 165
Uses ................................................................................................................................... 167

25.2

Other Attributes ........................................................................................................................... 168
fixedTPM and fixedParent .................................................................................................. 168
stClear ................................................................................................................................ 168
sensitiveDataOrigin ............................................................................................................ 169
userWithAuth ...................................................................................................................... 169
adminWithPolicy ................................................................................................................. 169
noDA................................................................................................................................... 170
encryptedDuplication .......................................................................................................... 170

Object Structure Elements ................................................................................................................ 171
26.1
26.2
26.3
26.4
26.5
26.6
26.7

Introduction ................................................................................................................................. 171
Public Area.................................................................................................................................. 171
Sensitive Area ............................................................................................................................. 171
Private Area ................................................................................................................................ 172
Qualified Name ........................................................................................................................... 173
Sensitive Area Encryption........................................................................................................... 173
Sensitive Area Integrity ............................................................................................................... 173

Object Creation ................................................................................................................................. 175
27.1
27.2

Introduction ................................................................................................................................. 175
Public Area Template ................................................................................................................. 176
Introduction ......................................................................................................................... 176
type ..................................................................................................................................... 176
nameAlg ............................................................................................................................. 176
objectAttributes................................................................................................................... 176
authPolicy ........................................................................................................................... 177
parameters ......................................................................................................................... 177
unique ................................................................................................................................. 177

27.3

Sensitive Values ......................................................................................................................... 177
Overview ............................................................................................................................ 177
userAuth ............................................................................................................................. 177
data..................................................................................................................................... 177

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xxiii
December 24, 2020

Trusted Platform Module Library
27.4
27.5

Part 1: Architecture

Creation PCR .............................................................................................................................. 178
Public Area Creation ................................................................................................................... 178
Introduction ......................................................................................................................... 178
type, nameAlg, objectAttributes, authPolicy, and parameters ........................................... 178
unique ................................................................................................................................. 178

27.6

Creation Entropy ......................................................................................................................... 179
Introduction ......................................................................................................................... 179
Entropy for Ordinary Objects .............................................................................................. 180
Entropy for Primary Objects ............................................................................................... 180

27.7

Sensitive Area Creation .............................................................................................................. 180
Introduction ......................................................................................................................... 180
type ..................................................................................................................................... 181
authValue ........................................................................................................................... 181
seedValue .......................................................................................................................... 181
sensitive.............................................................................................................................. 182

27.8
27.9

Creation Data and Ticket ............................................................................................................ 183
Creation Resources .................................................................................................................... 183

Object Derivation ............................................................................................................................... 184
28.1
28.2
28.3
28.4

Introduction ................................................................................................................................. 184
Derivation Parameters ................................................................................................................ 184
Public Area Template ................................................................................................................. 184
Entropy for Derived Objects........................................................................................................ 185
Conceptual Description ...................................................................................................... 185
Implementation Alternatives ............................................................................................... 186

28.5

Derivation Process ...................................................................................................................... 186

Object Loading .................................................................................................................................. 187
29.1
29.2
29.3
29.4

Introduction ................................................................................................................................. 187
Load of an Ordinary Object......................................................................................................... 187
Public-only Load ......................................................................................................................... 187
External Object Load .................................................................................................................. 188

Context Management ........................................................................................................................ 189
30.1
30.2

Introduction ................................................................................................................................. 189
Context Data ............................................................................................................................... 190
Introduction ......................................................................................................................... 190
Sequence Number ............................................................................................................. 190
Handle ................................................................................................................................ 191
Hierarchy ............................................................................................................................ 192

30.3

Context Protections .................................................................................................................... 192
Context Confidentiality Protection ...................................................................................... 192
Context Integrity Protection ................................................................................................ 193

30.4
30.5
30.6

Object Context Management ...................................................................................................... 194
Session Context Management.................................................................................................... 194
Eviction ....................................................................................................................................... 195

Page xxiv
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
30.7
30.8

Trusted Platform Module Library

Incidental Use of Object Slots..................................................................................................... 196
Sequence Context Management ................................................................................................ 196

Attestation ......................................................................................................................................... 197
31.1
31.2
31.3
31.4
31.5
31.6

Introduction ................................................................................................................................. 197
Standard Attestation Structure.................................................................................................... 197
Privacy ........................................................................................................................................ 198
Qualifying Data ........................................................................................................................... 198
Anonymous Signing .................................................................................................................... 198
X.509 Certificate Signing ............................................................................................................ 198

Cryptographic Support Functions ...................................................................................................... 201
32.1
32.2
32.3
32.4

Introduction ................................................................................................................................. 201
Hash............................................................................................................................................ 201
HMAC ......................................................................................................................................... 201
Hash, MAC, and Event Sequences ............................................................................................ 201
Introduction ......................................................................................................................... 201
Hash Sequence .................................................................................................................. 202
Event Sequence ................................................................................................................. 202
HMAC Sequence................................................................................................................ 202
Sequence Contexts ............................................................................................................ 203

32.5
32.6

Symmetric Encryption ................................................................................................................. 203
Asymmetric Encryption and Signature Operations ..................................................................... 203

Locality .............................................................................................................................................. 204
Hardware Core Root of Trust Measurement (H-CRTM) Event Sequence........................................ 205
34.1
34.2
34.3

Introduction ................................................................................................................................. 205
Dynamic Root of Trust Measurement ......................................................................................... 205
H-CRTM before TPM2_Startup() and TPM2_Startup() without H-CRTM .................................. 206

Command Audit ................................................................................................................................. 207
Timing Components .......................................................................................................................... 209
36.1
36.2
36.3

Introduction ................................................................................................................................. 209
Time ............................................................................................................................................ 210
Clock ........................................................................................................................................... 210
Introduction ......................................................................................................................... 210
Clock Implementation ......................................................................................................... 211
Orderly Shutdown of Clock................................................................................................. 211
Clock Initialization at TPM2_Startup() ................................................................................ 212
Setting Clock ...................................................................................................................... 212
Clock Periodicity ................................................................................................................. 213

36.4
36.5
36.6
36.7

resetCount .................................................................................................................................. 213
restartCount ................................................................................................................................ 214
Note on the Accuracy and Reliability of Clock ............................................................................ 214
Privacy Aspects of Clock ............................................................................................................ 215

NV Memory ....................................................................................................................................... 217
37.1
37.2

Introduction ................................................................................................................................. 217
NV Indices................................................................................................................................... 217

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xxv
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Definition ............................................................................................................................ 217
NV Index Allocation ............................................................................................................ 218
NV Index Deletion .............................................................................................................. 219
High-Endurance (Hybrid) Indices ....................................................................................... 219
Reading an NV Index ......................................................................................................... 221
Updating an Index .............................................................................................................. 221
NV Index in a Policy ........................................................................................................... 225
PIN Index Considerations................................................................................................... 226
37.3
37.4

Owner and Platform Evict Objects .............................................................................................. 227
State Saved by TPM2_Shutdown() ............................................................................................ 228
Background ........................................................................................................................ 228
NV Orderly Data ................................................................................................................. 228
NV Clear Data .................................................................................................................... 229
NV Reset Data ................................................................................................................... 229

37.5
37.6
37.7

Persistent NV Data ..................................................................................................................... 230
NV Rate Limiting ......................................................................................................................... 232
NV Other Considerations ............................................................................................................ 233
Power Interruption .............................................................................................................. 233
External NV ........................................................................................................................ 233
PCR in NV .......................................................................................................................... 234

Multi-Tasking ..................................................................................................................................... 235
Errors and Response Codes ............................................................................................................. 236
39.1
39.2
39.3

Error Reporting ........................................................................................................................... 236
TPM State After an Error ............................................................................................................ 236
Resource Exhaustion Warnings ................................................................................................. 236
Introduction ......................................................................................................................... 236
Transient Resources .......................................................................................................... 236
Temporary Resources ........................................................................................................ 237

39.4

Response Code Details .............................................................................................................. 237

General Purpose I/O ......................................................................................................................... 239
Minimums .......................................................................................................................................... 240
41.1
41.2
41.3
41.4

Introduction ................................................................................................................................. 240
Authorization Sessions ............................................................................................................... 240
Transient Objects ........................................................................................................................ 240
NV Counters and Bit Fields ........................................................................................................ 240

Attached Components ....................................................................................................................... 241
42.1

Introduction ................................................................................................................................. 241
Purpose .............................................................................................................................. 241
Concept .............................................................................................................................. 241

42.2
42.3
42.4
42.5
42.6

TPM2_AC_Send() ...................................................................................................................... 241
Send Object Types ..................................................................................................................... 242
Send Object Attributes ................................................................................................................ 242
Attached Component Authorization ............................................................................................ 242
Attached Component Object Management ................................................................................ 243

Page xxvi
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Discovery ............................................................................................................................ 243
Setup .................................................................................................................................. 243
Sending .............................................................................................................................. 243
42.7
42.8

Power States............................................................................................................................... 244
Attached Component Format...................................................................................................... 244

Authenticated Countdown Timer (ACT) ............................................................................................ 245
43.1
43.2
43.3
43.4
43.5
43.6

Introduction ................................................................................................................................. 245
Description .................................................................................................................................. 245
Typical Use ................................................................................................................................. 245
Failure Mode ............................................................................................................................... 246
Field Upgrade ............................................................................................................................. 246
Typical ACT authPolicy............................................................................................................... 247

Annex A (informative) Policy Examples ................................................................................................... 248
A.1
A.2

Introduction ................................................................................................................................. 248
TPM 1.2 Compatible Authorization ............................................................................................. 248

Annex B (normative/informative) RSA ..................................................................................................... 250
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8

Introduction ................................................................................................................................. 250
RSAEP ........................................................................................................................................ 251
RSADP........................................................................................................................................ 251
RSAES_OAEP ............................................................................................................................ 251
RSAES_PKCSV1_5 ................................................................................................................... 251
RSASSA_PKCS1v1_5................................................................................................................ 251
RSASSA_PSS ............................................................................................................................ 252
RSA Key Generation .................................................................................................................. 253

B.8.1
B.8.2
B.8.3
B.9

Background ........................................................................................................................ 253
Large Prime Generation ..................................................................................................... 253
RSA Key Generation Algorithm .......................................................................................... 254

RSA Cryptographic Primitives .................................................................................................... 254

B.9.1
B.9.2
B.9.3

Introduction ......................................................................................................................... 254
TPM2_RSA_Encrypt() ........................................................................................................ 254
TPM2_RSA_Decrypt()........................................................................................................ 255

B.10 Secret Sharing ............................................................................................................................ 255
B.10.1
B.10.2
B.10.3
B.10.4

Overview ............................................................................................................................ 255
RSA Encryption of Salt ....................................................................................................... 255
RSA Secret Sharing for Duplication ................................................................................... 255
RSA Secret Sharing for Credentials................................................................................... 256

Annex C (normative/informative) ECC ..................................................................................................... 257
C.1
C.2

Introduction ................................................................................................................................. 257
Split Operations .......................................................................................................................... 257

C.2.1
C.2.2
C.2.3
C.2.4
C.2.5

Introduction ......................................................................................................................... 257
Commit Random Value ...................................................................................................... 257
TPM2_Commit() ................................................................................................................. 258
TPM2_EC_Ephemeral() ..................................................................................................... 259
Recovering the Private Ephemeral Key ............................................................................. 260

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xxvii
December 24, 2020

Trusted Platform Module Library
C.3
C.4

ECC-Based Secret Sharing ........................................................................................................ 260
EC Signing .................................................................................................................................. 260

C.4.1
C.4.2
C.4.3
C.5
C.6

ECDH ................................................................................................................................. 264
ECDH Encryption of Salt .................................................................................................... 265
ECC Secret Sharing for Duplication ................................................................................... 265
ECC Secret Sharing for Credentials .................................................................................. 265

ECC Primitive Operations ........................................................................................................... 265

C.7.1
C.7.2
C.7.3
C.7.4
C.8

ECDSA ............................................................................................................................... 260
ECDAA ............................................................................................................................... 260
EC Schnorr ......................................................................................................................... 262

ECC Key Generation .................................................................................................................. 264
Secret Sharing ............................................................................................................................ 264

C.6.1
C.6.2
C.6.3
C.6.4
C.7

Part 1: Architecture

Introduction ......................................................................................................................... 265
TPM2_ECDH_KeyGen() .................................................................................................... 265
TPM2_ECDH_ZGen() ........................................................................................................ 265
Two-phase Key Exchange ................................................................................................. 266

ECC Point Padding ..................................................................................................................... 267

Annex D (normative/informative) Support for SMx Family of Algorithms ................................................ 269
D.1
D.2

Introduction ................................................................................................................................. 269
SM2............................................................................................................................................. 269

D.2.1
D.2.2
D.2.3
D.2.4
D.3
D.4

Introduction ......................................................................................................................... 269
SM2 Digital Signature Algorithm ........................................................................................ 269
SM2 Key Exchange ............................................................................................................ 271
SM2 Encryption and Decryption ......................................................................................... 273

SM3............................................................................................................................................. 274
SM4............................................................................................................................................. 274

Annex E (normative/informative) TDES ................................................................................................... 275
E.1

TDES Key Parity Generation ...................................................................................................... 275

Annex F (informative) Library Profile Guide ............................................................................................. 276
F.1
F.2
F.3
F.4
F.5
F.6
F.7
F.8
F.9
F.10
F.11
F.12

Introduction ................................................................................................................................. 276
Platform Specific Constants........................................................................................................ 276
PCR ............................................................................................................................................ 276
Algorithms ................................................................................................................................... 276
Commands.................................................................................................................................. 276
Buffers......................................................................................................................................... 277
NV Storage ................................................................................................................................. 277
Sessions and Objects ................................................................................................................. 277
Physical Presence ...................................................................................................................... 277
Dictionary Attack Lockout ........................................................................................................... 277
Self Test ...................................................................................................................................... 277
ACT ............................................................................................................................................. 277

Page xxviii
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

TABLES
Table 1 — Block Cipher Parameters .......................................................................................................... 42
Table 2 — Hierarchy Control Setting Combinations ................................................................................... 68
Table 3 — Equations for Computing Entity Names .................................................................................... 81
Table 4 — Separators ................................................................................................................................. 89
Table 5 — Tag Values ................................................................................................................................ 90
Table 6 — Use of Authorization/Session Blocks ........................................................................................ 93
Table 7 — Description of sessionAttributes ................................................................................................ 94
Table 8 — Command Layout for Example Command ................................................................................ 98
Table 9 — Example Command Showing authorizationSize ....................................................................... 98
Table 10 — Response Layout for Example Command .............................................................................. 99
Table 11 — Example Response Showing parameterSize .......................................................................... 99
Table 12 — Password Authorization of Command ................................................................................... 102
Table 13 — Password Acknowledgment in Response ............................................................................. 102
Table 14 — Session-Based Authorization of Command .......................................................................... 104
Table 15 — Session-Based Acknowledgment in Response..................................................................... 104
Table 16 — Schematic of TPM2_StartAuthSession Command ............................................................... 108
Table 17 — Handle Parameters for TPM2_StartAuthSession.................................................................. 109
Table 18 — Format to Start Unbounded, Unsalted Session..................................................................... 110
Table 19 — Format to Start Bound Session ............................................................................................. 112
Table 20 — Format to Start Salted Session ............................................................................................. 113
Table 21 — Format to Start Salted and Bound Session ........................................................................... 114
Table 22 — Mapping of Hierarchy Attributes ............................................................................................ 160
Table 23 — Allowed Hierarchy Settings ................................................................................................... 161
Table 24 — Mapping of Functional Attributes ........................................................................................... 167
Table 25 — TPM 1.2 Correspondence ..................................................................................................... 168
Table 26 — Public Area Parameters ........................................................................................................ 171
Table 27 — Sensitive Area Parameters.................................................................................................... 172
Table 28 — Creation Commands ............................................................................................................. 175
Table 29 — Deriving Object Entropy ........................................................................................................ 180
Table 30 — Standard Attestation Structure .............................................................................................. 197
Table 31 — Contents of the ORDERLY_DATA Structure ........................................................................ 228
Table 32 — Contents of the STATE_CLEAR_DATA Structure ................................................................ 229
Table 33 — Contents of the STATE_RESET_DATA Structure ................................................................ 230
Table 34 — Contents of the PERSISTENT_DATA Structure ................................................................... 231

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page xxix
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

FIGURES
Figure 1 — Attestation Hierarchy ................................................................................................................ 28
Figure 2 — Architectural Overview ............................................................................................................. 34
Figure 3 — Command Execution Flow ....................................................................................................... 38
Figure 4 — Random Number Generation ................................................................................................... 49
Figure 5 — TPM Startup Sequences .......................................................................................................... 58
Figure 6 — On-Demand Self-Test .............................................................................................................. 60
Figure 7 — Failure Mode Behavior ............................................................................................................. 62
Figure 8 — Resuming Field Upgrade Mode after _TPM_Init...................................................................... 64
Figure 9 — Field Upgrade Mode ................................................................................................................. 65
Figure 10 — Command Structure ............................................................................................................... 89
Figure 11 — Response Structure ............................................................................................................... 89
Figure 12 — Command/Response Header Structure ................................................................................. 89
Figure 13 — Authorization Layout for Command ....................................................................................... 93
Figure 14 — Authorization Layout for Response ........................................................................................ 94
Figure 15 — A 12-input OR Policy ............................................................................................................ 122
Figure 16 — Use of TPM2_PolicyAuthorize() to Avoid PCR Brittleness .................................................. 129
Figure 17 — Creating a Private Structure ................................................................................................. 147
Figure 18 — Symmetric Protection of Hierarchy....................................................................................... 149
Figure 19 — Duplication Process with Inner and Outer Wrapper ............................................................. 153
Figure 20 — Duplication Process with Outer Wrapper and No Inner Wrapper ........................................ 154
Figure 21 — Duplication Process with Inner Wrapper and TPM_RH_NULL as NP ................................. 155
Figure 22 — Duplication Process with no Inner Wrapper and TPM_RH_NULL as NP ............................ 155
Figure 23 — Key Recovery Process ......................................................................................................... 156
Figure 24 — Duplication Groups ............................................................................................................... 159
Figure 25 — Protection Groups ................................................................................................................ 160
Figure 26 — Creating a Identity Structure ................................................................................................ 164
Figure 27 — Response Code Evaluation.................................................................................................. 238

Page xxx
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Trusted Platform Module LibraryPart 1: Architecture
Scope
This specification defines the Trusted Platform Module (TPM) a device that enables trust in computing
platforms in general. It is broken into parts to make the role of each part clear. All parts are required inorder to constitute a complete standard
For a complete definition of all requirements necessary to build a TPM, the designer will need to use theappropriate platform-specific specification to understand all of the requirements for a TPM in a specificapplication or make appropriate choices as an implementer.
Those wishing to create a TPM need to be aware that this specification does not provide a complete
picture of the options and commands necessary to implement a TPM. To implement a TPM the designer
needs to refer to the relevant platform-specific specification to understand the options and settingsrequired for a TPM in a specific type of platform or make appropriate choices as an implementer.
EXAMPLEThe number of platform configuration registers and their attributes are not defined in thisspecification. Those values would be specified by a platform specific specification or alternatively
determined by an implementer.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 1
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Specification Organization
This specification contains four parts, as follows. In normative clauses, text labeled NOTE or EXAMPLE
are informative, non-normative. Text in Part 2 table columns Description or Comments are informative,
non-normative.
TPM 2.0 Part 1: Architecture
TPM 2.0 Part 1 contains a narrative description of the properties, functions, and methods of a TPM.
Unless otherwise noted, this narrative description is informative. TPM 2.0 Part 1 contains descriptions ofsome of the data manipulation routines that are used by this specification. The normative behavior forthese routines is in C code in TPM 2.0 Part 3 and TPM 2.0 Part 4. Algorithms and processes described inthis TPM 2.0 Part 1 can be made normative by reference from TPM 2.0 Part 2, TPM 2.0 Part 3, or TPM
2.0 Part 4.
TPM 2.0 Part 2: Structures
TPM 2.0 Part 2 contains a normative description of the constants, data types, structures, and unions for
the TPM interface. Unless otherwise noted: (1) all tables and C code in TPM 2.0 Part 2 are normative,and (2) normative content in TPM 2.0 Part 2 takes precedence over any other part of this specification.
TPM 2.0 Part 3: Commands
TPM 2.0 Part 3 contains: (1) a normative description of commands, (2) tables describing the command
and response formats, and (3) C code that illustrates the actions performed by a TPM. Within TPM 2.0
Part 3, command and response tables have the highest precedence, followed by the C code, followed by
the narrative description of the command. TPM 2.0 Part 3 is subordinate to TPM 2.0 Part 2.
A TPM need not be implemented using the C code in TPM 2.0 Part 3. However, any implementation
should provide equivalent or, in most cases, identical results as observed at the TPM interface ordemonstrated through evaluation.
TPM 2.0 Part 4: Supporting Routines
TPM 2.0 Part 4 presents C code that describes the algorithms and methods used by the command code
in TPM 2.0 Part 3. The code in TPM 2.0 Part 4 augments Parts 2 and 3 to provide a complete descriptionof a TPM, including the supporting framework for the code that performs the command actions.
Any TPM 2.0 Part 4 code can be replaced by code that provides similar results when interfacing to theaction code in TPM 2.0 Part 3. The behavior of TPM 2.0 Part 4 code not included in an annex isnormative, as observed at the interfaces with TPM 2.0 Part 3 code. Code in an annex is provided forcompleteness, that is, to allow a full implementation of the specification.
NOTE

This specification does not provide code for lower -level cryptographic algorithms and use of external
libraries is required for a complete implementation.

Extensive modification of the code provided in TPM 2.0 Part 4 annexes is expected for any TPM
implementation. Modifications are required in order to interface the TPM code with actual TPM hardware
rather than the simulation framework provided. In addition, modifications of the code in TPM 2.0 Part 4annexes would be necessary in order to meet the needs of applicable evaluation regimes.

Page 2
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
IETF RFC 8017, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.2
NIST SP800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography (Revised)
NIST SP800-108, Recommendation for Key Derivation Using Pseudorandom Functions (revised)
FIPS PUB 186-3, Digital Signature Standard (DSS)
ISO/IEC 9797-2, Information technology -- Security techniques -- Message Authentication Codes (MACs)-- Part 2: Mechanisms using a dedicated hash-function
IEEE Std 1363TM-2000, Standard Specifications for Public Key Cryptography
IEEE Std 1363a™-2004 (Amendment to IEEE Std 1363™-2000), IEEE Standard Specifications for Public
Key Cryptography- Amendment 1: Additional Techniques
ISO/IEC 10116:2006, Information technology — Security techniques — Modes of operation for an n-bit
block cipher
GB/T 32918.1-2016: Information security technology - Public Key Cryptographic Algorithm SM2 Based on
Elliptic Curves Part 1: General
GB/T 32918.2-2016: Information security technology - Public Key Cryptographic Algorithm SM2 Based on
Elliptic Curves Part 2: Digital Signature Algorithm
GB/T 32918.3-2016: Information security technology - Public Key Cryptographic Algorithm SM2 Based on
Elliptic Curves Part 3: Key Exchange Protocol
GB/T 32918.4-2016: Information security technology - Public Key Cryptographic Algorithm SM2 Based on
Elliptic Curves Part 4: Public Key Encryption Algotithm
GB/T 32918.5-2017: Information security technology - Public Key Cryptographic Algorithm SM2 Based on
Elliptic Curves Part 5: Parameter definition
GB/T 32905-2016: Information security technology - SM3 Cryptographic Hash Algorithm
GB/T 32907-2016: Information security technology - SM4 Block Cipher Algorithm
ISO/IEC 10118-3:2018, Information technology — Security techniques — Hash-functions — Part 3:
Dedicated hash functions
ISO/IEC 14888-3:2018, Information technology -- Security techniques -- Digital signature with appendix -Part 3: Discrete logarithm based mechanisms
ISO/IEC 15946-1, Information technology — Security techniques — Cryptographic techniques based on
elliptic curves — Part 1: General

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 3
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
TCG Algorithm Registry

Page 4
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryTerms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
“ATH”
sequence of four octets of data containing 41 54 48 00 16 that is used as a label in a KDF
NOTE 1

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.2
“CFB”
sequence of four octets containing 43 46 42 00 16 that is used as a label in a KDF
NOTE 2

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.3
“DUPLICATE”
sequence of 10 octets containing 44 55 50 4C 49 43 41 54 45 00 16 that is used as a label in a
KDF
NOTE 3

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.4
“IDENTITY”
sequence of nine octets containing 49 44 45 4E 54 49 54 59 00 16 that is used as a label in a KDF
NOTE 4

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.5
“OBFUSCATE”
sequence of 10 octets containing 4F 42 46 55 53 43 41 54 45 00 16 that is used as a label in a
KDF
NOTE 5

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.6
“SECRET”
sequence of seven octets containing 53 45 43 52 45 54 00 16 that is used as a label in a KDF
NOTE 6

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.7
“STORAGE”
sequence of eight octets containing 53 54 4F 52 41 47 45 00 16 that is used as a label in a KDF
NOTE 7

See 11.4.10.2 for justification for the terminating octet of 00 16 .

4.8
“XOR”
sequence of four octets containing 58 4F 52 00 16 that is used as a label in a KDF
NOTE 8

See 11.4.10.2 for justification for the terminating octet of 00 16 .

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 5
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

4.9
ancestor<object loaded in a TPM> Storage Key that was needs to have been loaded prior to loading an
object4.10
authValue
octet string containing a value that is used for access authorization. The value is used as a
password or to derive a key for an HMAC calculation.
4.11
authPolicy
digest value produced by an execution of policy commands and used for access authorization
4.12
bound
authValue of the Object is not included in the HMAC authorization for the authorization session
4.13
canonical form
data structure in the format used for transport to and from the TPM (see clause 4.36)
4.14
CLEAR
bit with a value of zero (0), or the action of causing a bit to have a value of zero (0)4.15commanddiscrete TPM function that is exposed externally and recognizable by a TPM’s commandprocessor; as well as the values sent to the TPM to indicate the operation to be performed
4.16
commandCodenumeric identifier of the operation to be performed by a TPM
4.17
context
collection of data that provides qualifying information about a data object to differentiate it fromothers of the same type or to differentiate one version of a data object from another
4.18
cpHashhash of the command code, Object names, and parameters of a command
4.19
Derivation Parent
loadable key used to derive other keys; a TPM_ALG_KEYEDHASH Parent Key
4.20
descendant<Storage Key> Object whose loading is conditional on a specific Storage Key having beenpreviously loaded
Page 6
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

4.21
digestresult of a hash operation
4.22
duplicateallowing a Protected Object created by a TPM to be used on a different TPM
4.23
ECDH
Diffie-Hellman secure secret sharing process using elliptic curve operations
4.24
entitya hierarchy, PCR, object, or NV Index in a TPM shielded location
4.25
Ephemeral Key
key created as part of a protocol that is not used again after the protocol is complete
4.26
Empty Auth
Empty Buffer used as an authorization value
4.27
Empty Buffer
sized array with no data; indicated by a size field of zero followed by an array contai ning noelements
4.28
Empty Digest
Empty Buffer used as a digest
4.29
Empty Point
ECC point with Empty Buffers for both the x and y coordinates
4.30
Empty Policy
Empty Buffer used when a policy value is required;
NOTE 9as a policyValue, an Empty Buffer will satisfy no policy

NOTE 10

No policy can be satisfied by an Empty Policy because an Empty Policy has zero length but apolicyDigest is the size of a hash digest and a digest is never zero length.

4.31
Endorsement Authorization
authorization using either endorsementAuth or endorsementPolicy

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 7
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

4.32
ExtendExtended
operation that replaces the current value of a digest with the hash of a buffer constructed byconcatenating new data (normally a digest) to the current value of the digest (see 11.4.8)
4.33
External Object
Object that can be loaded into a TPM without being a member of a specific hierarchy
4.34
Failure mode
mode in which the TPM returns TPM_RC_FAILURE in response to all command s except
TPM2_GetTestResult() or TPM2_GetCapability()
4.35
importoperation that allows a Protected Object not created by a TPM to be incorporated into ahierarchy of the TPM
4.36
internal form
data structure using a layout that is specific to an implementation th at can or cannot be the sameas the canonical form
4.37
Lockout Authorization
Authorization using either lockoutAuth or lockoutPolicy
4.38
LSB0
little-endian
the least-significant octet of a datum is at byte offset 0
4.39
MSB0
big-endian
the most-significant octet of a datum is at byte offset 0
4.40
LSb0
the least-significant bit of a datum is assigned the bit number of 0
4.41
MSb0
the most-significant bit of a datum is assigned the bit number of 0
4.42
non-volatiledata that is retained even when power is removed

Page 8December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

4.43
NULL
context-sensitive value that, when applied to a pointer, is a system -defined value indicating thatthe pointer does not reference data; and, when applied to a structure identified by an algorithm
identifier, is the TPM_ALG_NULL value indicating that no additional data is present
4.44
NULL Password
NULL Authauthorization where the authorization value is the Empty Buffer, resulting in an authorization thatis a sequence of 9 octets containing either 40 00 00 09 00 00 00 00 00 16 or 40 00 00 09 00 00 01
00 00 16
4.45
NULL Signature
signature with the TPM_ALG_NULL signature scheme that contains no data
4.46
NULL-terminatedsequence of non-zero values followed by a value containing zero; most often a NULL -terminatedstring where the values are ASCII-encoded octets
4.47
NULL Ticket
ticket structure with tag set to a value that is correct for the context, hierarchy is TPM_RH_NULL,
and digest is an Empty Buffer
4.48
NV Index
Index
user defined non-volatile shielded location
4.49
Objectkey or data that has a public portion and, optionally, a sensitive portion; and which is a memberof a hierarchy
NOTE 11

An NV Index is not an object.

4.50
octet
eight bits of data
NOTE 12On most modern computers, this is the smallest addressable unit of data.

4.51
orderly shutdown
when the TPM has completed TPM2_Shutdown() before power to the TPM is removed or_TPM_Init is asserted
4.52
ordinary key
key produced with a seed taken from the TPM RNG
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 9December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

cf. Primary Key
4.53
Owner Authorization
authorization using either ownerAuth or ownerPolicy
4.54
Parent Key
any object with the decrypt and restricted attributes SET and the sign attribute CLEAR
NOTE 13

There are two types of parent keys: Storage Parent and Derivation Parent.

4.55
PCR
one or more platform configuration registers each containing a digest
4.56
PCR.alghash algorithm associated with a specific PCR
4.57
PCR bank
collection of PCR identified by a hash algorithm, with each PCR in the bank containing a digest
computed using the bank identifier's hash algorithm
4.58
PCR.digest
digest value associated with a specific PCR
4.59
Permanent Entity
TPM resource with an architecturally defined handle that does not change
NOTE 14The value of a Permanent Entity can change

4.60
Persistent Entity
TPM resource created by a Protected Capability that persists i n TPM memory across power
cycles and TPM resets
4.61
Platform Authorization
authorization using either platformAuth or platformPolicy
4.62
policyDigest
digest uniquely representing an ordered set of policy commands and operands; used todetermine if a policy authorizing an action has been satisfied

Page 10December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

4.63
policySession→cpHash
policy session context value that, if not the Empty Buffer, is the cpHash value that the authorizedcommand needs to have for the authorization to be valid
4.64
PolicyAuthorize Command
either TPM2_PolicyAuthorize() or TPM2_PolicyAuthorizeNV()
4.65
platform firmware
code added to the platform by its manufacturer that is needed for booting and proper platform
operation
NOTE 15

Commonly, but not exclusively, referred to as BIOS or UEFI or SMM code

4.66
Primary Key
key derived from a Primary Seed that is associated with the hierarchy of the Primary Seed
NOTE 16

See 4.52 ordinary key

4.67
Primary Object
Primary Key or a data blob with a sensitive area that is encrypted using a symmetric key derived
from the public area of the object and a Primary Seed
4.68
private area
encrypted and integrity protected blob that contains the sensitive area of an object
4.69
Primary Seedlarge random value contained within a TPM from which Primary Keys and Primary Objects arederived4.70
Protected Capability
operation performed by the TPM on data in a Shielded Location in response to a command sent
to the TPM
4.71
Protected Object
object with an encrypted sensitive portion, the sensitive portion of which the TPM will only
decrypt when it is in a Shielded Location
4.72
RAM
memory that can be accessed in any order and which has no endurance limitations

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 11
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

4.73
reset interval
period between two successive TPM Resets and the interval during which the resetCount is notchanged4.74
response
values returned by the TPM when it completes processing of a command
4.75
Resume PCR
platform configuration register with a value that is preserved o ver a TPM Resume sequence
4.76
Root of Trust
component that must always behave in the expected manner because its misbehavior cannot be
detected
NOTE 17

The complete set of Roots of Trust has at least the minimum set of functions to enable a descriptionof the platform characteristics that affect the trustworthiness of the platform.

4.77
rpHashhash of the response code and the parameters of a response
4.78
Sealed Data Object
encrypted, user-defined, data blob that is associated with a hierarchy and loaded using
TPM2_Load() or TPM2_CreatePrimary()
4.79
sensitive area
contain the confidential or secret parts of an object that needs to be encrypted and integrity
protected when not in a Shielded Location on a TPM
4.80
sequence object
transient data structure used to hold hash state that has a handle and can be context swapped
NOTE 18

See clause 30

4.81
sessiontransient TPM structure that maintains the state associated with a sequence of authorizations or
an audit digest
4.82
SET
bit with a value of one (1), or the action of causing a bit to have a value of one (1)Page 12
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

4.83
Shielded Location
location on a TPM that contains data that is shielded from access by any entity other than the
TPM and which can be operated on only by a Protected Capability
4.84
Shutdown(CLEAR)
abbreviated form of the command TPM2_Shutdown() with the startupType parameter set to
TPM_SU_CLEAR
4.85
Shutdown(STATE)
abbreviated form of the command TPM2_Shutdown() with the startupType parameter set to
TPM_SU_STATE
4.86
sizeof(x)operator that returns the number of octets in the operand 'x'
4.87
Startup(CLEAR)
abbreviated form of the command TPM2_Startup() with the startupType parameter set to
TPM_SU_CLEAR
4.88
Startup(STATE)
abbreviated form of the command TPM2_Startup with the startupType parameter set to
TPM_SU_STATE
4.89
Storage Key
key used to provide integrity and confidentiality protection for descendant keys that are stored offof the TPM
4.90
Storage Parent
Storage Key that is acting as a parent key
4.91
Temporary Object
Objects that become unusable after a TPM Reset and that cannot be converted into Persistent
Objects
4.92
temporary resource
data object created during the execution of a command that does not persist in TPM memory
after the command completes
4.93
TPM_GENERATED_VALUE
32-bit number (FF 54 43 47 16 ) that is used to tag structures that are generated by a TPM

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 13
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

4.94
TPM Reset
resetting of all TPM internal state to default values due to Startup(CLEAR)
4.95
TPM Resource Manager
TRM
software executing on a system with a TPM that ensures that the resources necessary to
execute TPM commands are present in the TPM
4.96
TPM Restart
Startup(CLEAR) that initializes all PCR but preserves most other TPM state from the previous
Shutdown(STATE)
4.97
TPM ResumeStartup(STATE) that initializes some PCR but preserves most TPM state from the previous
Shutdown(STATE)
4.98
transient object
object or sequence object that can be explicitly loaded and unloaded from TPM memory by the
TRM; cleared from TPM memory when the TPM is initialized (TPM2_Startup())
4.99
transient resource
object, sequence object, or session that can be explicitly loaded and unloaded from TPM
memory by the TRM; cleared from TPM memory when the TPM is initialized (TPM2_Startup())
4.100
Trusted Platform Module
TPM
implementation of this specification
4.101
user-installable software
any software that can be installed on a platform other than platform firmware
4.102
volatile data
data that is lost when power is removed
4.103
Zero Digest
non-zero-length digest with all octets set to zero

Page 14
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Symbols and Abbreviated Terms
5.1

Symbols

For the purposes of this document, the following symbol definitions apply unless the text is in the
Courier font.
A || B

concatenation of B to A

x

the smallest integer not less than x

x

the largest integer not greater than xA≔Bassignment of the results of the expression on the right (B) to the parameter on the left

A=B

equivalence (A is the same as B){A}

an optional element

A⊕B

bitwise exclusive OR of elements

A&B

logical AND of elements

A|B

the logical OR of elements{A | B}

selection of elements{A : B}an inclusive range of elements between A and B<A, B, … >an ordered list of elements (a tuple)

0…0

a context-sensitive number of octets of zeroF()denotes a function F

F(p == x)denotes a function or TPM command F with parameter p set to value x

length(x)denotes a function that returns the number of significant bits in an integer value xH()denotes the hash function[n]Pmultiplication of point P by the integer value nA•Bmultiplication of two integer values A and B

A→B

denotes a reference to element B within structure A

A mod BA modulus B

Text in the Courier font indicates code written according to the C language standard.
5.2

Abbreviations

For the purposes of this document, the following abbreviations apply.
Abbreviation

Description_TPM_

Prefix for an indication passed from the system interface of the
TPM to a Protected Capability defined in this specification

AK

Attestation Key

BIOS

Basic Input/Output System

CA

Certificate Authority

CFB

Cipher Feedback mode

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 15
December 24, 2020

Trusted Platform Module Library
Abbreviation

Part 1: Architecture

Description

CPU

Central Processing Unit

CRTM

Core Root of Trust for Measurement

CTR

Counter mode

D-RTM

dynamic RTM

DAdictionary attack

DoS

Denial of Service

DRBG

Deterministic Random Bit Generator

DSA

Digital Signature Algorithm

EA

Enhanced Authorization

EALEALevaluated assurance level

ECC

Elliptic Curve Cryptography

ECDAA

ECC-based Direct Anonymous Attestation

ECDH

Elliptic Curve Diffie-Hellman

EK

Endorsement Key

EPS

Endorsement Primary Seed

FIPS

Federal Information Processing Standard

FUM

Field Upgrade mode

GPIO

General Purpose I/O

HMAC

Hash Message Authentication Code

I/O

Input/Output

IV

Initialization Vector

KDF

key derivation function

KVT

known value test

LPC

Low Pin Count

LSb

Least Significant bit

LSO

Least Significant Octet

MSb

Most Significant bit

MSO

Most Significant Octet

NIST

National Institute of Standards and Technology

NP

new parentNV

non-volatile

NVRAM

Non-Volatile Random Access Memory

OAEP

Optimal Asymmetric Encryption PaddingOEM

Original Equipment Manufacturer

OIAP

Object-Independent Authorization Protocol

OID

Object Identifier in ASN.1 format

OSAP

Object-Specific Authorization Protocol

Page 16
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Abbreviation

Trusted Platform Module Library

Description

PCR

platform configuration register(s)POSTPower On Self-Test

PP

Physical Presence

PPS

Platform Primary Seed

PRF

Pseudo-Random Function

PRNG

Pseudo-Random Number Generator

PSS

Probabilistic Signature Scheme

QN

Qualified Name

RNG

Random Number Generator

RSA

Rivest, Shamir and Adleman

RTM

Root of Trust for Measurement

RTR

Root of Trust for Reporting

RTS

Root of Trust for Storage

S-RTM

Static RTM

SHA

Secure Hash Algorithm

SMAC

Symmetric block cipher Message Authentication Code

SMM

System Management Mode

SPS

Storage Primary Seed

SRK

Storage Root Key

TBB

Trusted Building Block

TCB

Trusted Computing Base

TCG

Trusted Computing Group

TPM

Trusted Platform Module

TPM2_

Prefix for a command defined in this specificationTSS

TCG Software Stack

UEFI

Unified Extensible Firmware Interface

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 17
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Compliance
Unless the TPM 2.0 Part 3 general description of a command indicates that the command is mandatory, acompliant TPM need not implement the command. However, if implemented, the command is required tohave the behavior defined in TPM 2.0 Part 3. A platform-specific specification will indicate the commands
from this specification that are required to be implemented in order to be compliant with that platformspecific specification.
The code in this specification is a reference implementation that describes required TPM behavior as
observed from the TPM interface. The C-code can be reorganized or rewritten in any desired
implementation language and remain compatible with this specification as long as the observablebehavior is equivalent.
Even though the code in the reference implementation has undergone extensive testing, it is likely thatsome errors exist and one or more of those errors could lead to a TPM failure or exploit. Regardless ofany other statement about normative behavior, one should not assume that a TPM exploit or failure is anintended behavior. It is not necessary to reproduce such a behavior in order to be compliant with thisspecification.
NOTE

Please report bugs in the reference code to the TCG (admin@trustedcomputinggroup.org) so thatthe reference code can be brought into compliance with the specification.

The response codes in the specification are normative. An implementation performing a check prescribedby this specification is required to return the indicated error if the check fails. The order in which checks
are performed is not normative. This means that a command with multiple errors could return different
response codes on different TPMs. However, the response code returned is required to be the normative
response code used to indicate the specific failure.
Capacities and algorithms of a TPM implementation can vary from the reference implementation; in thiscase, the same error would not occur in the same situation (such as, a TPM implementation with morememory can be able to satisfy a request where the reference implementation would have returned anerror). However, these differences should not cause a different response code to be returned when thenature of the error is the same as in the reference implementation.
TPM 2.0 Part 4 of the specification contains major subsystems that can change for each instance of a
TPM. For example, the NV subsystem of the reference implementation is not representative of the actual
implementation of most physical NV implementations but is a crude analog. When the subsystem isrewritten, an equivalent interface should be provided, and the errors returned are required to match thoseof the reference implementation.
NOTE

A constraint on the design of the TPM was the process of compliance -testing of different TPM
implementations. If a TPM implementation has modularity similar to the reference implementation,then TPM tests that assume a modular design will be able to produce reliable test results on each
TPM implementation.

The reference implementation uses static and stack-based allocation of resources and does not doallocations on a heap. However, a TPM implementation may use heap-based memory management inwhich case some error conditions and codes will differ. These differences are limited, and the allowed
response codes and error conditions are defined in 39.3.

Page 18
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Conventions
7.1

Bit and Octet Numbering and Order

An integer value is considered to be an array of one or more octets. The octet at offset zero within thearray is the most significant octet (MSO) of the integer. Bit number 0 of that integer is its least significant
bit and is the least significant bit in the last octet in the array.
EXAMPLEA 32-bit integer is an array of four octets; the MSO is at offset [0], and the most significant bit is bit
number 31. Bit zero of this 32-bit integer is the least significant bit in the octet at offset [3] in thearray.

NOTE 1Array indexing is zero-based.

NOTE 2This definition does not match the “network bit order” used in many IETF documents, such as RFC
4034. In those documents, the most significant bit of a datum has the lowest bit number. It isconventional practice to send that bit first when using a serial network protocol, and the bits arenumbered in the order in which they are sent. This specification numbers bits according to the powerof two to which they correspond within a datum. This numbering corresponds to the normal
convention for bit numbering in hardware registers that hold integer values rather than fixed -point
numbers.

NOTE 3

The TPM uses MSB0, LSb0 numbering.

The first listed member of a structure is at the lowest offset within the structure and the last listed member
is at the highest offset within the structure.
For a character string (letters delimited by “”), the first character of the string contains the MSO.
7.2

Sized Buffer References

The specification makes extensive use of a data structure called a sized buffer. A sized buffer has a size
field followed by an array of octets equal in number to the value in the size field.
The structure will have an identifying name. When the specification references the size field of thestructure, the structure name is followed by “.size” (a period followed by the word “size”). When thespecification references the octet array of the structure, the structure name is followed by “.buffer” (aperiod followed by the word “buffer”).
7.3

Numbers

Numbers are decimal unless a different radix is indicated.
Unless the number appears in a table intended to be machine readable, the radix is a subscript following
the digits of the number. Only radix values of 2 and 16 are used in this specification.
Radix 16 (hexadecimal) numbers have a space separator between groups of two hexadecimal digits.
EXAMPLE 1

40 FF 12 34 16

Radix 2 (binary) numbers use a space separator between groups of four binary digits.
EXAMPLE 20100 1110 0001 2

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 19
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The number of digits indicates the number of bits in the representation.
EXAMPLE 3

20 16 is a hexadecimal number that contains exactly 8 bits and has a decimal value of 32.

EXAMPLE 4

10 0000 2 is a binary number that contains exactly 6 bits and has a decimal value of 32.

EXAMPLE 5

0 20 16 is a hexadecimal number that contains exactly 12 bits and has a decimal value of 32.

A number in a machine-readable table can use the “0x” prefix to denote a base 16 number. In this format,
the number of digits is not always indicative of the number of bits in the representation.
EXAMPLE 6

0x20 is a hexadecimal number with a value of 32, and the number of bits is determined by thecontext.

Page 20
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Changes from Previous Versions
This version of the TPM specification introduces these additional features to the TPM family:•

Definition of an interface that allows variability of underlying cryptographic algorithms – TPM 1.2 isconstrained by its data structures to using RSA and SHA1. The TPM 2.0 structure and interface
defines support for a wide range of hash and asymmetric algorithms along with limited support foruse of various block, symmetric ciphers. Of particular note is the addition of support for the elliptic
curve (ECC) family of asymmetric algorithms.

•

Unification of authorization methods – TPM 1.2 has different schemes to authorize the use,delegated use, and migration of objects. This 2.0 specification provides a uniform framework forusing authorization capabilities, so they can be combined in unique ways to provide more
flexibility.

•

Expansion of authorization methods – TPM 2.0 allows authorization with clear-text passwords andHash Message Authentication Code (HMAC). It also allows construction of an arbitrarily complex
authorization policy for an object using multiple authorization qualifiers.

•

Dedicated BIOS support – TPM 2.0 adds a Storage hierarchy controlled by platform firmware,letting the OEM benefit from the cryptographic capabilities of the TPM regardless of the support
provided to the OS.

•

Simplified control model – TPM 2.0 needs no special provisioning process to be useful toapplications. Although objects on which the TPM operates can have limitations, all commands areavailable all the time. This lets application developers rely on TPM capabilities being available
whenever a TPM is present.

A TPM compatible with this specification need not be compatible with previous TPM specifications.
This specification defines the operations a TPM performs and the structures used for communication
between the TPM and the host system. It does not define an electrical interface to the TPM, nor does it
specify which subset of TPM 2.0 commands and resources are required for a specific platform. Pleaserefer to platform-specific TPM specifications for this information.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 21
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Trusted Platforms
9.1

Trust

In the context of Trusted Computing Group (TCG) specifications, “trust” is meant to convey an
expectation of behavior. However, predictable behavior does not necessarily constitute behavior that is
worthy of trust.
EXAMPLEWe expect that a bank will behave like a bank, and we expect that a thief will behave like a thief.

In order to determine the expected behavior of a platform, it is necessary to determine its identity as it
relates to the platform behavior. Physically different platforms may have identical behavior. If they are
constructed of components (hardware and software) that have identical behavior, then their trust
properties should be the same.
The TCG defines schemes for establishing trust in a platform that are based on identifying its hardware
and software components. The Trusted Platform Module (TPM) provides methods for collecting andreporting these identities. A TPM used in a computer system reports on the hardware and software in a
way that allows determination of expected behavior and, from that expectation, establishment of trust.
9.2

Trust Concepts
Trusted Building Block

A trusted building block (TBB) is a component or collection of components required to instantiate a Rootof Trust. Typically, platform-specific, a TBB is part of a Root of Trust that does not have Shielded
Locations.
EXAMPLEAn example of a TBB is the combination of the CRTM, the connection between CRTM storage and amotherboard, the path between CRTM storage and the CPU, the connection between the TPM and amotherboard, and the path between the CPU and the TPM. This combination comprises the Root ofTrust for Reporting (RTR).

A TBB is a component that is expected to behave in a way that does not compromise the goals of trusted
platforms.
Trusted Computing Base
A trusted computing base (TCB) is the collection of system resources (hardware and software) that is
responsible for maintaining the security policy of the system. An important attribute of a TCB is that it beable to prevent itself from being compromised by any hardware or software that is not part of the TCB.
The TPM is not the trusted computing base of a system. Rather, a TPM is a component that allows an
independent entity to determine if the TCB has been compromised. In some uses, the TPM can help
prevent the system from starting if the TCB cannot be properly instantiated.
Trust Boundaries
The combination of TBB and Roots of Trust form a trust boundary, within which measurement, storage,
and reporting can be accomplished for a minimal configuration. In systems that are more complex, it canbe necessary for the CRTM to establish trust in other code, by making measurements of that other codeand recording the measurement in a PCR. If the CRTM transfers control to that other code regardless ofthe measurement, then the trust boundary is expanded. If the CRTM will not run that code unless its
Page 22
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarymeasurement is the expected value, the trust boundary remains the same because the measured code isan expected extension of the CRTM.
Transitive Trust
Transitive trust is a process whereby the Roots of Trust establish the trustworthiness of an executablefunction, and trust in that function is then used to establish the trustworthiness of the next executablefunction.
Transitive trust can be accomplished either by: (1) knowing that a function enforces a trust policy before it
allows a subsequent function to take control of the TCB, or (2) using measurements of subsequentfunctions so that an independent evaluation can establish the trust. The TPM may support either of thesemethods.
Trust Authority
When the RTM begins to execute the CRTM, the entity that can vouch for the correctness of the TBB isthe entity that created the TBB. For typical systems, this is the platform manufacturer. In other words, themanufacturer is the authority on what constitutes a valid TBB, and its reputation is what allows someone
to trust a given TBB.
As the system transitions to code outside the CRTM, the transitive trust chain is maintained bymeasurement of that code. If execution of that code is conditional on its measurement, then the authority
for that code remains unchanged. That is, if the platform manufacturer’s CRTM does not run code outside
the CRTM unless that code has a specific measured value, then the platform manufacturer remains thetrust authority regardless of who provided that code.
In modern architectures, where firmware and software components come from many different suppliers, it
is often not feasible for platform manufacturers to know the signers of all code that runs on a platform.
Therefore, they may not remain the authority on platform state for very long. The measurements recordedin the RTS then determine the chain of authority for the current system state.
Two different methods allow evaluation of the trust authority for a platform.
1) Code is measured (hashed), and its value is recorded in the RTS. If the code is run regardless of its
measurement, then the authority for the trust is the digest of the code reported by the RTR. That is,
the measurements speak for themselves, and the verifier needs either to have knowledge of themeasurements that constitute trustworthy code or knowledge of the measurements that indicatesmalicious or vulnerable code.
2) Code is signed so that the identity of the authority for the code is known. If this identity is recorded in
the RTS, the evaluation can be changed. Instead of being based on knowing the digest of the code, it
can be based on identities of the signers of the code.
Because trusted sources of code can sometimes produce code with security vulnerabilities, support forrevocation is often required. To allow revocation of specific code modules, it is often necessary to use ahybrid solution where both authorities and details are recorded. This simplifies the process of determining
whether a module from a specific vendor has been revoked.
NOTE

If the code is measured (hashed) and not signed, it is harder to know if a specific measurement isvalid unless there is a centralized database of all known digests of revoked code. When the identityof the authority is known, one can contact the vendor to determine i f it has revoked code with agiven hash.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 23
December 24, 2020

Trusted Platform Module Library
9.3

Part 1: Architecture

Trusted Platform Module

A TPM is a system component that has state that is separate from the system on which it reports (thehost system). The only interaction between the TPM and the host system is through the interface definedin this specification.
TPMs are implemented on physical resources, either directly or indirectly. A TPM may be constructedusing physical resources that are permanently and exclusively dedicated to the TPM, and/or using
physical resources that are temporarily assigned to the TPM. All of a TPM’s physical resources may belocated within the same physical boundary, or different physical resources may be within different
physical boundaries.
Some TPMs are implemented as single-chip components that are attached to systems (typically, a PC)
using a low-performance interface. The TPM component has a processor, RAM, ROM, and Flashmemory. The only interaction with these TPMs is through the LPC bus. The host system cannot directly
change the values in TPM memory other than through the I/O buffer that is part of the interface.
EXAMPLEAn example of a low performance interface is the Low Pin Count, or LPC bus.

Another reasonable implementation of a TPM is to have the code run on the host processor while theprocessor is in a special execution mode. For these TPMs, parts of system memory are partitioned byhardware so that the memory used by the TPM is not accessible by the host processor unless it is in thisspecial mode. Further, when the host processor switches modes, it always begins execution at specificentry points. This version of a TPM would have many of the same attributes as the stand-alone
component in that the only way for the host to cause the TPM to modify its internal state is with welldefined interfaces. There are several different schemes for achieving this mode switching including
System Management Mode, Trust Zone™, and processor virtualization.
Definition of the interaction between the host and the TPM is the primary objective of this specification.
Prescribed commands instruct the TPM to perform prescribed actions on data held with the TPM. A
primary purpose of these commands is to allow determination of the trust state of a platform. The ability ofa TPM to accomplish its objective depends on the proper implementation of Roots of Trust.
9.4

Roots of Trust
Introduction

TCG-defined methods rely on Roots of Trust. These are system elements that must be trusted because
misbehavior is not detectable. The set of roots required by the TCG provides the minimum functionality
necessary to describe characteristics that affect a platform’s trustworthiness.
While it is not possible to determine if a Root of Trust is behaving properly, it is possible to know how
roots are implemented. Certificates provide assurances that the root has been implemented in a way that
renders it trustworthy.
EXAMPLEA certificate can identify the manufacturer and evaluated assurance level (EAL) of a TPM.

This certification provides confidence in the Roots of Trust implemented in the TPM. In addition, acertificate from a platform manufacturer can provide assurance that the TPM was properly installed on amachine that is compliant with TCG specifications so that the Root of Trust provided by the platform canbe trusted (see 9.5.2 for more information on certification).
The TCG requires three Roots of Trust in a trusted platform:•

Root of Trust for Measurement (RTM),

Page 24
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library•

Root of Trust for Storage (RTS), and•Root of Trust for Reporting (RTR).

Trust in the Roots of Trust can be achieved through a variety of means but is anticipated to include
technical evaluation by competent experts.
Root of Trust for Measurement (RTM)
The RTM sends integrity-relevant information (measurements) to the RTS. Typically, the RTM is the CPU
controlled by the Core Root of Trust for Measurement (CRTM). The CRTM is the first set of instructions
executed when a new chain of trust is established. When a system is reset, the CPU begins executing the
CRTM. The CRTM then sends values that indicate its identity to the RTS. This establishes the starting
point for a chain of trust (see 9.5.5 for a more detailed description of integrity measurement).
Root of Trust for Storage (RTS)
The TPM memory is shielded from access by any entity other than the TPM. Because the TPM can betrusted to prevent inappropriate access to its memory, the TPM can act as an RTS.
Some of the information in TPM memory locations is not sensitive and the TPM does not protect it fromdisclosure. An example of non-sensitive data is the current contents of a platform configuration register(PCR) containing a digest. Other information is sensitive and the TPM does not allow access to theinformation without proper authority. An example of sensitive data in a Shielded Location is the private
part of an asymmetric key.
Sometimes, the TPM uses the contents of one Shielded Location to gate access to another Shielded
Location. For example, access to (use of) a private key for signing can be conditioned on PCR having
specific values.
Root of Trust for Reporting (RTR)
9.4.4.1

Description

The RTR reports on the contents of the RTS. An RTR report is typically a digitally signed digest of thecontents of selected values within a TPM.
NOTE

Not all Shielded Locations are directly accessible. For example, the values of the private part ofkeys and authorizations are in Shielded Locations on which the TPM will not report.

The values on which the RTR reports typically are•evidence of a platform configuration in PCR (such as, TPM2_Quote()),•

audit logs (such as, TPM2_GetCommandAuditDIgest ()), and•key properties (such as, TPM2_Certify()).

The interaction between the RTR and RTS is critical. The design and implementation of this interaction
should mitigate tampering that would prevent accurate reporting by the RTR. An instantiation of the RTS
and RTR will•

be resistant to all forms of software attack and to the forms of physical attack implied by the
TPM’s Protection Profile, and•supply an accurate digest of all sequences of presented integrity metrics.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 25
December 24, 2020

Trusted Platform Module Library
9.4.4.2

Part 1: Architecture

Identity of the RTR

The TPM contains cryptographically verifiable identities for the RTR. The identity is in the form ofasymmetric aliases (Endorsement Keys or EKs) derived from a common seed. Each seed value and its
aliases should be statistically unique to a TPM. That is, the probability of two TPMs having the same EK
should be insignificant.
The seed can be used to generate multiple asymmetric keys, all of which would represent the same TPM
and RTR.
9.4.4.3

RTR Binding to a Platform

The TPM reports on the state of the platform by quoting the PCR values. For assurance that these PCRvalues accurately reflect that state, it is necessary to establish the binding between the RTR and theplatform. A Platform Certificate can provide proof of this binding. The Platform Certificate is assurance
from the certifying authority of the physical binding between the platform (the RTM) and the RTR.
9.4.4.4

Platform Identity and Privacy Considerations

The uniqueness of an EK and its cryptographic verifiability raises the issue of whether direct use of that
identity could result in aggregation of activity logs. Analysis of the aggregated activity could reveal
personal information that a user of a platform would not otherwise approve for distribution to theaggregators.
To counter undesired aggregation, TCG encourages the use of domain-specific signing keys andrestrictions on the use of an EK. The Privacy Administrator controls use of an EK, including the process ofbinding another key to the EK.
NOTEPrivacy Administrator's control of the EK differs from Owner control of the RTS providing separationof the security and identity uses of the TPM.

Unless the EK is certified by a trusted entity, its trust and privacy properties are no different from anyother asymmetric key that can be generated by pure software methods. Therefore, by itself, the public
portion of the EK is not privacy sensitive.
9.5

Basic Trusted Platform Features
Introduction

At a minimum, a trusted platform provides the three Roots of Trust described previously. All three roots
use certification and attestation to provide evidence of the accuracy of information. A trusted platform will
also offer Protected Locations (see 10.3) for the keys and data objects entrusted to it. Finally, a trusted
platform can provide integrity measurement to ensure the trustworthiness of a platform by logging
changes to platform state; this is done by recording logged entries in PCR for later validation as being
correct and unaltered. These basic TPM concepts are now described in detail.
Certification
The nominal method of establishing trust in a key is with a certificate indicating that the processes used
for creating and protecting the key meets necessary security criteria. A certificate can be provided byshipping the TPM with an embedded key (that is, an Endorsement Key) along with a Certificate ofAuthenticity for the EK. The EK and its certificate can be used to associate credentials (certificates) withother TPM keys; this process is described in clause 9.5.3.3. When a certified key has attributes that let it

Page 26
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarysign TPM-created data, it can attest to the TPM-resident record of platform characteristics that affect the
integrity (trustworthiness) of a platform.
NOTE

The EK does not have to be installed when the TPM is shipped. At the factory, an EK can begenerated from the Endorsement Seed and a Certificate of Authenticity created for that EK. The EK
does not have to be permanently installed in the TPM. When the TPM is in possession of acustomer, the customer can, at their discretion, have the TPM use the Endorsem ent Seed andrecreate the EK for which they have a Certificate of Authenticity.

Attestation and Authentication
9.5.3.1

Types of Attestation

Trusted platforms employ a hierarchy of attestations:
1) An external entity attests to a TPM in order to vouch that the TPM is genuine and complies with this
TPM specification. This attestation takes the form of an asymmetric key embedded in a genuine TPM,
plus a credential that vouches for the public key of that pair.
NOTE 1

A credential that is used to vouch for the embedded asy mmetric key is commonly called an"Endorsement Certificate."

2) An external entity attests to a platform in order to vouch that the platform contains a Root-of-Trust-forMeasurement, a genuine TPM, plus a trusted path between the RTM and the TPM. This attestation
takes the form of a credential that vouches for information including the public key of the asymmetrickey pair in the TPM.
NOTE 2A credential used to vouch for the platform is commonly called a "Platform Certificate."

3) An external entity called an “Attestation CA” attests to an asymmetric key pair in a TPM in order tovouch that a key is protected by an unidentified but genuine TPM and has particular properties. This
attestation takes the form of a credential that vouches for information including the public key of the
key pair. An Attestation CA typically relies upon attestations of type 1 and 2 in order to produce
attestation of type 3.
NOTE 3The credential created by the CA is commonly called an "Attestation Key Certificate."

4) A trusted platform attests to an asymmetric key pair in order to vouch that a key pair is protected by agenuine but unidentified TPM and has particular properties. This attestation takes the form of asignature signed by the platform’s TPM over information that describes the key pair, using anattestation-key protected by the TPM, plus attestation of type 3 that vouches for that attestation key.
NOTE 4This type of attestation is done using TPM2_Certify().

5) A trusted platform attests to a measurement in order to vouch that a particular software/firmware state
exists in a platform. This attestation takes the form of a signature over a software/firmware
measurement in a PCR using an attestation key protected by the TPM, plus attestation of type 3 or 4
for that attestation key.
NOTE 5This is type of attestation is commonly called a "quote" and is done with TPM2_Quote().

6) An external entity attests to a software/firmware measurement in order to vouch for particular
software/firmware. This attestation takes the form of a credential that vouches for information
including the value of a measurement and the state it represents.
NOTE 6This is commonly called "third-party certification."

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 27
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Attestation of types 3 and 4 entail the use of a key to sign the contents of Shielded Locations. An
Attestation Key (AK) is a particular type of signing key that has a restriction on its use, in order to prevent
forgery (the signing of external data that has the same format as genuine attestation data). The restrictionis that an AK can be used only to sign a digest that the TPM has created. If an AK is known to beprotected by a TPM (by virtue of attestation of type 3 or 4), it can be relied on to report accurately on
Shielded Location content, and not sign externally provided data that appears to be valid and TPMproduced but is not.

Platform Attestation

measurements

5

6

software4

Attestation Key(certified byAttestation CA)

platform

TPM

3

2

1

Figure 1 — Attestation Hierarchy
9.5.3.2

Attestation Keys

When the TPM creates a message to sign from internal TPM state (such as, in TPM2_Quote()), a special
value (TPM_GENERATED_VALUE) is used as the message header. A TPM-generated message always
begins with this value.
When the TPM digests an externally provided message, it checks the first few octets of the message toensure that they do not have the same value as TPM_GENERATED_VALUE. When the digest is
Page 28
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarycomplete, the TPM produces a ticket that indicates the message did not start with
TPM_GENERATED_VALUE. When an AK is used to sign the digest, the caller provides the ticket so that
the TPM can determine that the message used to create the digest was not a possible forgery of TPM
attestation data. The digest in the ticket must match the digest being presented to the AK for signing.
EXAMPLE

If an attacker produced a message block that was identical to a TPM -generated quote, that message
block would start with TPM_GENERATED_VALUE to indicate that it is a proper TPM quote. When
the TPM performs a digest of this block, it notes that the first octets are the same as
TPM_GENERATED_VALUE. It will not generate the ticket indic ating that the message is safe tosign, so an AK cannot be used to sign this digest. Similarly, an entity checking an attestation madeby an AK has to verify that the message signed begins with TPM_GENERATED_VALUE in order toverify the message is indeed a TPM-generated quote.

Values signed by an AK can be assured to reflect TPM state, but AKs can also be used for generalsigning purposes.
An AK does not have much value to a remote challenger if the AK cannot be associated with the platformthat it represents. This association is made using the identity certification process.
9.5.3.3

Attestation Key Identity Certification

Any TPM user that can create a key on a TPM can create a restricted-use signing key. The key creator
can then ask a third party, such as an attestation Certificate Authority (CA), to provide a certificate for it.
The attestation CA can request that the caller provide some evidence that the key being certified is a
TPM-resident key.
Evidence of TPM residency can be provided using a previously generated certificate for another key on
the same TPM. An EK or Platform Certificate can provide this evidence.
NOTE 1

There is no requirement that certificates come only from an attestation CA. The method describedabove is an example of a scheme that can be used when privacy is required.

If a certified key can sign, it can be used to certify that some other object is resident on the same TPM.
This allows the new AK to be linked to a certified key. A CA can use the certification from the TPM toproduce a traditional certificate for the new key.
If the certified key is a decryption key and cannot sign, then an alternative method is used to allow the
new key or data object to be reliably certified. For this alternative certification, the identity of the Object tobe certified and a certificate for the decryption key (such as, an EK) are provided to the CA. From thecertificate, the CA determines the public key for the decryption key. The CA then produces a challenge for
the Object to be certified and encrypts the challenge with the certified key. The encrypted challenge is
given to the TPM containing both the certified decryption key and the key to be certified.
The challenge is protected using methods that are dependent on the type of the certified decryption key.
The general method is described in clause 24. Additional methods appropriate to RSA keys are describedin B.10.4 and additional methods appropriate to ECC key are in C.6.4. The protection process produces
an encrypted blob, an HMAC over the blob, and a secret value that can only be recovered by the certified
decryption key.
TPM2_ActivateCredential() is used to access the challenge. The TPM recovers the secret value and uses
it to generate the keys necessary to decrypt and validate the HMAC and encrypted blob. If the challenge
is recovered successfully, and the key being certified by the credential is loaded on the TPM, then thechallenge is returned to the caller, and then provided to the CA. After the CA validates the challenge, it
can issue the certificate for the key

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 29
December 24, 2020

Trusted Platform Module Library
NOTE 3

Part 1: Architecture

The protection process used for the challenge is almost identical to the process used for key import.
In order to make sure that there is no misuse of the encrypted structures, an application -specificvalue is used in the key recovery process. In the case of a challenge, the label “IDENTITY” is usedin the KDF that generates the keys (symmetric and HMAC) from the seed value.

TPM2_ActivateCredential() can operate on any Object. The choice of attributes for an Object to becertified is at the discretion of the CA. Because a unique identifier for the Object is included in the integrity
hash, the TPM enforces the challenge's accessibility only if the Object matches the criteria set by the CA
as expressed in the object identifier.
Protected Location
When the sensitive portion of an object is not held in a Shielded Location on the TPM, it is encrypted.
When encrypted, but not on the TPM, it is not protected from deletion, but it is protected from disclosureof its sensitive portions. Wherever it is stored, it is in a Protected Location.
Objects in long-term protected storage need to be loaded into the TPM for use. The application thatcreated the objects manages their movement from long-term storage to the TPM.
Since a TPM has limited memory, it can be unable to hold all objects required by all applications
simultaneously. The TPM supports swapping of object contexts by a TPM Resource Manager (TRM) sothat the TPM can service these multiple applications. The object contexts are encrypted before being
returned to the TRM by the TPM. If the object is needed later, the TRM can reload the context into the
TPM providing a cache-like behavior.
Encryption of Protected Locations uses multiple seeds and keys that never leave the TPM. One of theseis the Context Key. It is a symmetric key used to encrypt data when it is temporarily swapped out of the
TPM so that a different working set of objects can be loaded. Other sensitive values that never leave the
TPM are the Primary Seeds. These seeds are the root of the storage hierarchies that protect objects thatare retained by applications. A Primary Seed is a random number used to generate protection keys forother objects; these objects may be Storage Keys that contain protection keys that are then used toprotect still more objects.
Primary Seeds can be changed, and when they are changed, the objects they protected will no longer be
usable. For example, the Storage Primary Seed (SPS) creates the Storage hierarchy for owner-relateddata, and that seed changes when the owner changes.
Integrity Measurement and Reporting
The Core Root of Trust for Measurement (CRTM) is the starting point of measurement. This process
makes the initial measurements of the platform that are Extended into PCR in the TPM. For
measurements to be meaningful, the executing code needs to control the environment in which it isrunning, so that the values recorded in the TPM are representative of the initial trust state of the platform.
A power-on reset creates an environment in which the platform is in a known initial state, with the main
CPU running code from some well-defined initial location. Since that code has exclusive control of theplatform at that time, it can make measurements of the platform from firmware. From these initial
measurements, a chain of trust can be established. Because this chain of trust is created once when theplatform is reset, no change of the initial trust state is possible, so it is called a static RTM (S-RTM).
An alternative method of initializing the platform is available on some processor architectures. It lets the
CPU act as the CRTM and apply protections to portions of memory it measures. This process lets a new
chain of trust start without rebooting the platform. Because the RTM can be re-established dynamically,
this method is called dynamic RTM (D-RTM). Both S-RTM and D-RTM can take a system in an unknown
state and return it to a known state. The D-RTM has the advantage of not requiring the system to berebooted.
Page 30
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

An integrity measurement is a value that represents a possible change in the trust state of the platform.
The measured object can be anything of meaning but is often•

a data value,•

the hash of code or data, or•an indication of the signer of some code or data.

The RTM (usually, code running on the CPU) makes these measurements and records them in RTS
using Extend. The Extend process (see 17.2) allows the TPM to accumulate an indefinite number ofmeasurements in a relatively small amount of memory.
The digest of an arbitrary set of integrity measurements is statistically unique, and an evaluator mightknow the values representing particular sequences of measurements. To handle cases where PCRvalues are not well known, the RTM keeps a log of individual measurements. The PCR values can beused to determine the accuracy of the log, and log entries can be evaluated individually to determine if
the change in system state indicated by the event is acceptable.
Implementers play a role in determining how event data is partitioned. TCG’s platform-specificspecifications provide additional insight into specifying platform configuration and representation as wellas anticipated consumers of measurement data.
Integrity reporting is the process of attesting to integrity measurements recorded in a PCR. The
philosophy behind integrity measurement, logging, and reporting is that a platform can enter any state
possible — including undesirable or insecure states — but is required to accurately report those states.
An independent process can evaluate the integrity states and determine an appropriate response.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 31
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM Protections
10.1

Introduction

This part of the specification describes the protections provided by the Trusted Platform Module. Thisclause describes the properties of selected capabilities and selected data locations for a TPM that has
been evaluated according to a Protection Profile and a TPM that has not been modified by physicalmeans.
TPM protections are based on the concepts of Protected Capabilities and Protected Objects. A Protected
Capability is an operation that must be performed correctly for a TPM to be trusted. A Protected Object isdata (including keys) that must be protected for a TPM operation to be trusted. Protected Objects in the
TPM reside in Shielded Locations; the TPM can manipulate the contents of Shielded Locations only byusing Protected Capabilities. Protected Objects outside Shielded Locations have their integrity andconfidentiality protected cryptographically.
Since a Protected Object can reside outside of Shielded Location protections, the definition of “access” toa Protected Object denotes disclosure of its contents, not modification. Such objects are not protectedagainst loss or tampering. However, before loading a Shielded Location with an outside object, the TPM
will use a secure hash function to validate that the object was properly protected and not altered. If theintegrity check fails, the TPM returns an error and does not load the object.
The only operations on Shielded Locations of a TPM are the Protected Capabilities defined in thisspecification and the vendor-specific operations that meet the requirements of 10.4.
10.2

Protection of Protected Capabilities

A Protected Capability can be modified only by other Protected Capabilities in the same TPM. Thus, theprocess of updating TPM firmware is required to be a Protected Capability.
10.3

Protection of Shielded Locations

As noted, access to any data on a TPM requires use of a Protected Capability. Therefore, all information
on a TPM is in a Shielded Location. The contents of a Shielded Location are not disclosed unless thedisclosure is intended by the definition of the Protected Capability. A TPM is not allowed to export datafrom a Shielded Location other than by using a Protected Capability.
Data in an I/O buffer that can be modified by the host is not “on” the TPM, even though the I/O
buffer can be shielded from access while the TPM is processing a command or generating a
response.

NOTE

10.4

Exceptions and Clarifications

Vendor-specific operations may access and modify Shielded Locations on a TPM under the following
circumstances.
•

A vendor-specific operation may use the standard TPM authorization mechanism.

•

A vendor-specific capability may read any TPM-resident structure that is not required to be in a
Shielded Location at all times if the usage of that structure is authorized per the structure’s
authorization mechanism.

EXAMPLEA vendor-specific command is permitted to use the public portion of a key. If the key is a user key,
no authorization would be required.

Page 32
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryAmong other things, the exception above enables access to a Shielded Location, so the structure’s
access authorization can be checked.

NOTE

•

Vendor-specific operations may use a sequence of Protected Capabilities.

•

Vendor-specific operations may use the standard TPM command interface or use a vendordefined interface.

These clarifications serve to approve specific legitimate interpretations of the requirements.
•

A vendor-specific operation that takes advantage of exceptions and clarifications to the“protection” requirements should be defined as part of the security target of the TPM. Such a
vendor-specific command or capability should be evaluated to determine whether it meets
Platform-specific TPM and System Security Targets.

•

If a TPM stores vendor-specific cipher-text that is protected against subversion to the same or
greater extent as internal TPM-resources stored outside the TPM with TCG-defined methods,
then that cipher-text does not require protection from physical attack. If the TPM stores only
vendor-specific cipher-text that does not require protection from physical attack, that location canbe excluded from analysis when determining whether the TPM complies with the “physicalprotection” requirements specified by TCG.

•

If a TPM uses external memory for non-volatile storage of TPM state (including seeds and proof
values), movement of the TPM state to and from the NV memory constitutes a vendor-defined
operation that is allowed by this specification. The protection profile of that TPM should include a
description of the protections of that data to ensure confidentiality and integrity of the data and to
mitigate against rollback attacks.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 33
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM Architecture
11.1

Introduction

This clause describes the overall operation of the TPM and the functional units required for its operation.
The major elements of the architecture are shown in Figure 2.

Figure 2 — Architectural Overview
11.2

TPM Command Processing Overview

Figure 3 is a high-level flow diagram for a TPM command. The figure shows only the normal flow for acommand that executes successfully. The tabs on a box indicate the name of the module performing theoperation. Additional details for each of the modules shown in Figure 3 are in this clause and in clauses
dedicated to those modules.
The partitioning of functions in Figure 3 is illustrative and not normative.

Page 34
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The flow assumes that the command has been placed in an input buffer that is accessible to the Execute
Command module (this name is used because of its similarity to the ExecCommand() function in thereference code that performs the functions illustrated here).
NOTE 1

The mechanism for getting the command into the TPM buffer and pr oviding the command-available
indication is specific to each physical interface and is defined in interface -specific documents.

The command structure includes a standard header (see 18) that Execute Command validates. It thendetermines if the command requires access to any Shielded Location that is identified by a handle. If so, itcalls the Handle module to verify that the handle references the right type of resource for the commandand that the resource is currently loaded on the TPM.
When control returns to Execute Command, it checks the tag parameter in the command header todetermine if authorization values are provided. If so, Authorizations is called to validate that each of theauthorizations is correct. The authorizations are associated with a handle value, so the authorization is
specific to a particular entity.
After validating the authorizations, Execute Command calls Command Dispatch to unmarshal theremaining command parameters and validate that the required parameters of the required type arepresent. All parameters are validated to meet the requirements of its data type as defined in TPM 2.0 Part
2 even if the parameter will subsequently be discarded because of optional behavior of a command.
After unmarshaling the parameters, Command Dispatch calls the command-specific library function to
execute the specific command. Additional parameter checking can be required in the command-specificactions.
The command processing is structured so that changes to the TPM state do not occur until the TPM canvalidate that the command parameters are correct and that the resources necessary to complete thecommand are available. Only then will it make irreversible changes to the TPM state. This structuring
ensures that when the TPM returns an error, the TPM will be in the same state as before command
actions modified the data in any Shielded Location.
NOTE 2Requiring that the TPM retain its state minimizes the interference between applications and helps
prevent system instability due to careless use of the TPM by applications.

There are several classes of operations that return an error but can change TPM state.
•

An authorization failure can update the dictionary attack mechanism.

•

The self test mechanism has state (for example, which algorithms have been tested) that is
considered to be different from the command execution state. Changes to this state can occur
regardless of the command return code. For example, an implicit self test invoked to test an
algorithm required by the command can mark the algorithm as tested.

•

If a self test fails, the TPM will go into Failure Mode.

When the command actions are complete, the Command Dispatch marshals response parameters into
the output buffer. If the command had authorizations, Acknowledge is called to construct acknowledge
session values for the response.
If the command encounters an error, the response packet will contain a code that is characteristic of theerror and, when possible, an indication of whether the error was associated with a handle, anauthorization session, or a command parameter. No additional qualifying data is present. In most cases,
the error code and parameter location value suffice to isolate the problem.
NOTE 3In the case of a self-test failure, the TPM response code is not sufficient to diagnose the problem.
Therefore, a reporting scheme is provided so that the failure cause can be read. However, error
report contents vary by vendor and are not standardized. There is thus no need to standardize self test response codes because no standard remediation is possible for most s elf-test failures.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 35
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

After constructing the response, including acknowledge sessions, the TPM indicates to the interface thatthe response is ready to be returned.
The TPM command/response structure is described in Clause 17.10 (see clause 19 for a description of
the methods for creating the values that authorize use of a TPM Shielded Location and clause 39 for
response code formatting information).
During the processing of these commands, the TPM uses other modules that the following parts of thisclause will describe.

Page 36
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Command Received

Execute Command

Validate Command Header• Correct type (tag)?
• Correct size (commandSize)?
• Command implemented(commandCode)?

Does command use
handles to reference
TPM objects?

Execute Command module does operations
that are common across commands but which
may have some variation by command

Yes
HandleFor each handle:• Is handle valid for the command?
• Is referenced object present in the TPM?

No

Are authorizations
required to use referenced
objects?

Yes
Authorization
For each authorization:• Is authorization the right type for command?
• Is authorization valid for object ?
Decrypt first parameter if it is encryptedNo

Command Dispatch
In command-specific manner:• Unmarshal (unpack) command parameters• Call function to perform command-specificactions• Marshal (pack) response parameters

Were authorizations
present in theCommand?

Yes
Acknowledge• If requested, encrypt first parameter• For each authorization in the command,
generate an acknowledgement• Update any audit values

No

Create Response Header

Response Out

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 37
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Figure 3 — Command Execution Flow
11.3

I/O Buffer

The I/O buffer is the communications area between a TPM and the host system. The system places
command data in the I/O buffer and retrieves response data from the buffer.
A description of the physical processes used to move I/O buffer data to/from the system is beyond thescope of this specification. Platform-specific working groups within the TCG produce the specifications forthe physical interfaces to the TPM on their platforms. Those specifications detail the interactions between
system software and the TPM I/O buffer.
There is no requirement that the I/O buffer be physically isolated from other parts of the system. It can bea shared memory. However, when processing of a command begins, the implementation must ensurethat the TPM is using the correct values. For example, if the TPM performs a hash of the command dataas part of the authorization processing, the TPM needs to protect the validated command data frommodification. That is, before the data is validated, it is required to be protected from modification. Before
the data is modified, it is required to be in a Shielded Location.
11.4

Cryptography Subsystem
Introduction

The Cryptography subsystem implements the TPM’s cryptographic functions. It can be called by theCommand Parsing module, the Authorization Subsystem, or the Command Execution module. The TPM
employs conventional cryptographic operations in conventional ways. These operations include•

hash functions,•asymmetric encryption and decryption,•

asymmetric signing and signature verification,•

symmetric encryption and decryption,•

symmetric signing (HMAC and SMAC) and signature verification, and•key generation.

The remainder of this clause describes some algorithms usually found in a TPM to show how they arehandled. These descriptions illustrate, but do not limit, the choice of available algorithms.
Symmetric Block Cipher MAC Algorithms
The TPM may implement Symmetric Block Cipher Message Authentication Code (SMAC).
An SMAC is a form of symmetric signature over some data using a symmetric block cipher algorithm. It
provides assurance that protected data was not modified and that it came from an entity with access to a
key value. To have usefulness in protecting data, the key value needs to be a secret or a shared secret.
Hash Functions
Hash functions can be used directly by external software or as the side effect of many TPM operations.
The TPM uses hashing to provide integrity checking and authentication as well as one-way functions, as
needed (such as, KDF).

Page 38
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

A TPM should implement an approved hash algorithm that has approximately the same security strength
as its strongest asymmetric algorithm.
EXAMPLEAn ECC with a 384-bit key has a security strength of 192 bits. SHA384, with 192 bits of security,
would meet the preceding requirement above.

NOTE

The TCG can create sets of algorithms that do not have the same security strength for the hash andasymmetric algorithms.

A hash function will be denoted by Halgorithm() with the algorithm subscript indicating the hash algorithm or
the parameter that contains the hash algorithm identifier. In some cases, the algorithm subscript ismissing, in which case the algorithm will be determined by context.
The Command Dispatch module will use the hash function when validating certain types ofauthorizations. Hash functions are also used in support of other operations in the TPM such as PCR
Extend.
HMAC Algorithm
The TPM implements the Hash Message Authentication Code (HMAC) algorithm specified in ISO/IEC
9797-2.
An HMAC is a form of symmetric signature over some data. It provides assurance that protected data was
not modified and that it came from an entity with access to a key value. To have usefulness in protecting
data, the key value needs to be a secret or a shared secret.
ISO/IEC 9797-2 defines the HMAC operation as:

HMAC(Κ, text) = H((Κ̅ ⊕ OPAD) || H((Κ̅ ⊕ IPAD) || text))(1)(See ISO/IEC 9797-2 for a description of parameters.)
Performing the HMAC computation requires selection of a hash algorithm. This specification modifies thenotation from ISO/IEC 9797-2 to be:

HMAChashAlg (K, text)(2)

If the algorithm subscript is not present, the hash algorithm is implied by the context.
The Command Dispatch module can use the HMAC function to validate an authorization. The HMAC
function can be used by the Command Execution module in support of its operations.
Asymmetric Operations
A TPM uses asymmetric algorithms for attestation, identification, and secret sharing. A TPM may support
any asymmetric algorithm to which the TCG has assigned an identifier. An asymmetric algorithm identifier
will indicate a family of algorithms and methods that are used with that algorithm.
The methods for using an asymmetric algorithm are found in algorithm-specific annexes to this TPM 2.0
Part 1. Currently, the only supported asymmetric algorithms are RSA (described in Annex B ) and ECC
using prime curves (described in Annex B ).
A TPM is required to implement at least one asymmetric algorithm.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 39
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Signature Operations
11.4.6.1

Signing

The TPM can sign using either an asymmetric or a symmetric algorithm. The method of signing depends
on the type of the key. For an asymmetric algorithm, the methods of signing are dependent on thealgorithm (RSA or ECC). For symmetric signatures, HMAC and SMAC signing schemes are defined. If a
key can be used for signing, then it will have the sign attribute.
NOTE 1The signing schemes for RSA are described in B.6 (RSASSA_PKCS1v1_5) and B.7 (RSASSA_PSS).
The signing schemes for ECC are described in C.4 (EC Signing).

A key with a sign attribute can also have a restriction on the contents of the message that can be signedwith the key. When a key has this restriction, the TPM will not use the key to sign message digests that
the TPM did not compute.
Any attestation message produced by a TPM will have a header (TPM_GENERATED_VALUE) to identify
the data as being produced within a TPM. If a restricted key is used to sign this data, then a relying party
can have assurance that the message data came from a TPM.
To allow a restricted key to sign an externally generated message, the TPM is used to produce themessage digest. When the TPM computes the digest, it will validate that the message does not begin with
TPM_GENERATED_VALUE. If it does, then the TPM will not produce the special certification (a ticket)
that indicates that the digest was produced by the TPM and is safe to sign with a restricted key.
A key designated as a signing key can be used in any command that uses a signing key. For somecommands, the signing scheme can be specified in the command. Not all schemes are valid for all keys,
and the TPM generates an error if the scheme is not allowed with the indicated key type.
EXAMPLE 1

The RSASSA-PKCS1-v1_5 signing scheme is not valid with an ECC key.

EXAMPLE 2

A key that has the "restricted" attribute can only be used with one signing scheme. If it is limited to
be used with RSASSA-PSS, it cannot be used with RSASSA-PKCS1-v1_5.

A restricted signing key is required to have a signing scheme specified in the key definition and that is the
only signing scheme that is allowed to be used with the key. For an unrestricted key, the key definition
may contain a signing scheme selection, or the signing scheme can be determined when the key is used.
To defer the signing scheme selection, the key would be created with TPM_ALG_NULL as the signingscheme selection.
11.4.6.2

Signature Verification

TPM2_VerifySignature() validates a signature over a digest. The command takes a handle of a public
key, a digest, and a block that contains the signature over the digest.
The TPM validates that the signature scheme is compatible with the selected key. In general, the TPM will
be able to validate any signature over a digest that it could have produced.
If the signature is valid, the TPM will produce a ticket.
11.4.6.3

Tickets

A ticket is an HMAC signature that uses a proof value as the HMAC key.
NOTE

Hierarchy proof values are described in detail in 14.4.

Page 40
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The TPM uses tickets for two purposes:•

re-signing data. After checking an asymmetric signature, the TPM re-signs the digest using a TPM
symmetric key. The TPM can later re-verify a signature without having to load the asymmetrickey; and•expanding state memory. When hashing an external message, the TPM has some state thatindicates the message did not start with TPM_GENERATED_VALUE. This state information
cannot be retained indefinitely in the TPM. A ticket allows this state to be stored off of the TPM in
a way that is easy for the TPM to validate. When a digest is later presented to the TPM to besigned, the ticket is provided allowing the TPM to validate that the digest to be signed is safe tosign.

The proof value used for a ticket will minimally have a number of bits equal to the size of the digest
produced by the hash algorithm.
EXAMPLEA proof value of 256 bits is required for a SHA256 ticket.

There are five different ticket types:
1) TPMT_TK_CREATION – this ticket type is produced when an object is created (TPM2_Create() or
TPM2_CreatePrimary()). The ticket is used in TPM2_CertifyCreation() so that the TPM can certifythat it created a specific object and the environmental parameters (PCR) that were extant when theobject was created. This avoids having the digest of the creation data be a permanent part of an
object’s data structure.
2) TPMT_TK_VERIFIED – this ticket type is produced by TPM2_VerifySignature() and used by
TPM2_PolicyAuthorize(). If a signature is signed by an asymmetric key, the signature verification
might be time consuming. If the same authorization is going to be used many times (such as an
authorization for TPM2_PolicyAuthorize()), there is a performance advantage to having theasymmetric authorization converted so that it uses symmetric cryptography which is usually faster.
This ticket is the symmetric equivalent authorization.
3) TPMT_TK_AUTH – this ticket is produced by TPM2_PolicySigned() or TPM2_PolicySecret() andused in TPM2_PolicyTicket(). A policy authorization can be tied to a specific policy session or allowed
to be used in any policy. When it can be used in any policy, it has a time at which it expires (which
can be some arbitrary time in the future). The long-lived authorization can be given in
TPM2_PolicySigned()/TPM2_PolicySecret() and a ticket is produced that is used to verify theauthorization parameters (what was authorized) and the time in the future when the authorization
expires. This ticket is then processed by TPM2_PolicyTicket() and, until the ticket expires, will havethe same effect on the policyDigest computation as the original authorization.
NOTE

If produced by TPM2_PolicySigned(), the ticket will use the TPM_ST_AUTH_SIGNED structure tag
and if produced by TPM2_PolicySecret(), the ticket will use the TPM_ST_AUTH_SECRET structuretag. TPM2_PolicyTicket() will use this tag to indicate which command code to use(TPM_CC_PolicySigned/TPM_CC_PolicySecret) when extending policyDigest.

4) TPMT_TK_HASHCHECK – This ticket is used to indicate that a digest of external data is safe to signusing a restricted signing key. A restricted signing key can only sign a digest that was produced by
the TPM. If the digest was produced from externally provided data, there needs to be an indicationthat the data did not start with the same first octets as are used for data that is generated within the
TPM. This prevents “forgeries” of attestation data. This ticket is used to provide the evidence that thedata used in the digest was checked by the TPM and is safe to sign. Assuming that the external datais "safe", this type of ticket is produced by TPM2_Hash() or TPM2_SequenceComplete() and used by
TPM2_Sign().

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 41
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture5) NULL Ticket – A NULL Ticket is produced when a response has a ticket, but no ticket is produced. An
example is TPM2_PolicySecret() with an expiration time of zero. It does not produce a ticket because,since the expiration time was zero, the authorization expires immediately. In this case, the TPM will
return a NULL Ticket. A NULL Ticket can also be used as an input parameter when the command
requires a ticket, but no ticket data is available.
Symmetric Encryption
The TPM uses symmetric encryption to encrypt some command parameters (typically, authentication
information) and to encrypt Protected Objects stored outside it. Cipher Feedback mode (CFB) is the only
block cipher mode required by this specification.
Any symmetric block cipher supported by a TPM can be used for parameter encryption. However weakkeys are not permitted to be used. Additionally, a TPM should support XOR obfuscation, which is a hashbased stream cipher. XOR obfuscation can be used only for confidential parameter passing.
NOTE

XOR allows an application to have confidential and integrity -protected interactions with only one
algorithm in common with the TPM (a hash).

When paired with an asymmetric key — as in an ECC decrypting key — a symmetric key is required tohave as many bits of security strength as the asymmetric key with which it is paired.
EXAMPLE 1

SP800-57 classifies 2048-bit RSA as providing 112 bits of security. AES with 128 - or 256-bit keys
provides adequate symmetric security for pairing with a 2048 -bit RSA key.

EXAMPLE 2

A prime-modulus ECC key has a security strength that is half the size of the prime mod ulus. AES
with 128- or 256-bit keys is suitable for pairing with a 256-bit ECC key, but AES with 128-bit keys is
not recommended for pairing with a 384-bit ECC key.

When a symmetric key is used for data encryption, the encrypted data has an HMAC. This HMAC ischecked before the data is decrypted. Verification that the decrypted data is properly associated with thesymmetric key is intended to make it more difficult to perform power analysis. To defeat the protections, itwould be necessary to defeat two different families of protection rather than one as would exist if theintegrity protection were applied to the clear text rather than the cipher text.
11.4.7.1

Block Cipher Modes

The block cipher modes referenced in this specification are defined in ISO/IEC 10116:2006. That
specification allows parameterization of most of the modes. In a TPM implementation, the parameters are
fixed, as defined in Table 1.
Table 1 — Block Cipher Parameters
Mode

Common Name

Parameter

Comments

CTR

Counterj=nsize of the plaintext variable

OFB

Output Feedback

j=nsize of the plaintext variable

CBC

Cipher-block Chaining

m=1

interleave factor

r=nsize of feedback buffer

k=nsize of feedback variable

j=nsize of plaintext variable

CFB

ECB
NOTE

Cipher-feedback

Electronic Code Booknone

n is the input block size of the cipher.

Page 42
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
11.4.7.2

Trusted Platform Module Library

Cipher Feedback (CFB) Mode

CFB is used when a symmetric block cipher is chosen as the encryption algorithm associated with asession. When used for parameter encryption, the key and Initialization Vector (IV) are derived from aper-session key so that reuse of the same key and IV is statistically unlikely.
NOTE

ISO/IEC 10116 use the term Start Variable instead of Initialization Vector (IV).

CFB is also used for symmetric encryption of the sensitive area of an object when the object is not stored
in a Shielded Location. When used in this way, the key and IV are derived from a secret. In some cases,
the IV is set to zero.
11.4.7.3

XOR Obfuscation

XOR obfuscation resembles Counter mode (CTR) block encryption, but it uses a KDF as the pseudorandom function instead of a symmetric block cipher.
XOR obfuscation reduces to one (a hash) the number of algorithms that a caller needs in common with
the TPM in order to use the TPM with some level of confidentiality and authentication.
This specification’s XOR scheme differs from that used in TPM 1.2: it uses a different formulation for input
into the hash function.
When this specification calls for use of XOR obfuscation, it uses a function reference. The function
prototype is:

XOR(data, hashAlg, key, contextU, contextV)

(3)

where

data

a variable-sized buffer containing the data to be obfuscatedhashAlg

the hash algorithm to be used in the KDF

key

a variable-sized value containing a secret key

contextU

a variable-sized value used to qualify one of the parties to the operation(often a nonce value)

contextV

a variable-sized value used to qualify one of the parties to the operation(often a nonce value)

The XOR() function uses the hash, key, contextU, and contextV parameters in a call to KDFa() toproduce a mask value:mask ≔ KDFa (hashAlg, key, “XOR”, contextU, contextV, data.size • 8)

(4)

The “XOR” value is defined in 4.8.

NOTE

The octets of mask are then XOR’d with the octets of data.buffer.
ExtendThe Extend operation is used to make incremental updates to a digest value. It is useful for
updating PCR, auditing, and constructing policy. Extend uses a hash function to combine newdata with an existing digest. Its notation is:
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 43
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

digestnew ≔ HhashAlg (digestold || datanew)

(5)

where

digestnew

the value of the digest (such as, a PCR) after the Extend operation

HhashAlg

the hash function using a context-specific algorithm (such as, the hashalgorithm associated with a specific bank of PCR)

digestold

the value of the digest before the Extend operation

datanew

a variable number of octets of data that are to be hashed with the initialvalue of digestold to produce Extend results

The Extend operation can also apply to an NV Index that has the TPMA_NV_EXTEND attribute.
Key Generation
Key generation produces two different types of keys. The first, an ordinary key, is produced using therandom number generator (RNG) to seed the computation. The result of the computation is a secret key
value kept in a Shielded Location.
The second type, a Primary Key, is derived from a seed value, not the RNG directly. The RNG usually
generates the seed that is persistently stored on the TPM. Generation of a Primary Key from a seed isbased on use of an approved key derivation function (KDF). The KDF from SP800-108 is widely used inthis specification.
This specification places no upper limit on the time allowed to generate a key. Platform-specificspecifications may limit the time for generating various key types.
Depending on the application, the TPM can generate a key by•using bits from the RNG, or•deriving the key from another secret value.

There are many ways to generate keys; these methods are described in detail in each clause wheregeneration of a key is required.
Key Derivation Function
11.4.10.1 Introduction
The TPM uses a hash-based function to generate keys for multiple purposes. This specification uses two
different schemes: one for ECDH and one for all other uses of a KDF.
The ECDH KDF is from SP800-56A. The Counter mode KDF, from SP800-108, uses HMAC as thepseudo-random function (PRF). It is referred to in the specification as KDFa().
11.4.10.2 KDFa()
With the exception of ECDH, KDFa() is used in all cases where a KDF is required. KDFa() uses Countermode from SP800-108, with HMAC as the PRF.
As defined in SP800-108, the inner loop for building the key stream is:Page 44
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library
K(i) ≔ HMAC (KI , [i]2 || Label || 0016 || Context || [L]2)

(6)

where

K(i)

the ith iteration of the KDF inner loop

HMAC()

the HMAC algorithm using an approved hash algorithmKI

the secret key material[i]2

a 32-bit counter that starts at 1 and increments on each iteration

Labela octet stream indicating the use of the key produced by this KDF

0016

Added only if Label is not present or if the last octet of Label is not zero.

Context

a binary string containing information relating to the derived keying
material[L]2

a 32-bit value indicating the number of bits to be returned from the KDF
Equation (6) is not KDFa (). KDFa () is the function call defined below.

NOTE 1As shown in equation (6), there is an octet of zero that separates Label from Context. In SP800-108,
Label is a sequence of octets that can or cannot have a final octet that is zero. If Label is not present, azero octet is added. If Label is present and the last octet is not zero, a zero octet is added.
After each iteration, the HMAC digest data is concatenated to the previously produced value until the sizeof the concatenated string is at least as large as the requested value. The string is then truncated to thedesired size (which causes the loss of some of the most recently added bits), and the value is returned.
When this specification calls for use of this KDF, it uses a function reference to KDFa(). The function
prototype is:

KDFa (hashAlg, key, label, contextU, contextV, bits)

(7)

where

hashAlga TPM_ALG_ID to be used in the HMAC in the KDF

key

a variable-sized value used as KIlabel

a variable-sized octet stream used as LabelcontextU

a variable-sized value concatenated with contextV to create the Context
parameter used in equation (6) above

contextV

a variable-sized value concatenated to contextU to create the Context
parameter used in equation (6) abovebits

a 32-bit value used as [L]2; and is the number of bits returned by thefunction

The values of contextU and contextV are passed as sized buffers and only the buffer data is used toconstruct the Context parameter used in equation (6) above. The size fields of contextU and contextV are
not included in the computation. That is:Context ≔ contextU.buffer || contextV.buffer

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021(8)

Page 45
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The 32-bit value of bits is in TPM canonical form, with the least significant bits of the value in the highest
numbered octet.
The implied return from this function is a sequence of octets with a length equal to (bits + 7) / 8. If bits is
not an even multiple of 8, then the returned value occupies the least significant bits of the returned octet
array, and the additional, high-order bits in the 0th octet are CLEAR. The unused bits of the mostsignificant octet (MSO) are masked off and not shifted.
EXAMPLE

If KDFa() were used to produce a 521-bit ECC private key, the returned value would occupy 66
octets, with the upper 7 bits of the octet at offset zero set to 0.

11.4.10.3 KDFe for ECDH
Producing a symmetric encryption key for an ECC-protected object uses “One-Pass Diffie-Hellman, C(1,1, ECC CDH)” from SP800-56A, 6.2.2.2. The KDF used is the “Concatenation Key Derivation Function(Approved Alternative 1)”. The inner loop of that KDF uses:

digesti ≔ H(counter || Z || OtherInfo)

(9)

where

digestithe digest generated on the ith iteration of the loop (i starts at 1)H()

an approved hash function

countera 32-bit counter that is initialized to 1 and incremented on each iterationZ

the X coordinate of the product of a public ECC key and a different
private ECC key

OtherInfoa collection of qualifying data for the KDF defined below

The 32-bit counter value is included in TPM canonical form, with the least-significant bit of the counter inthe highest numbered octet.
After each iteration, digesti is concatenated to the previously produced digests (MSO of digesti follows the
LSO of digesti-1). The number of iterations is determined by the number of bits to be produced and thesize of the digest produced by the hash function. In the returned octet string, the MSO of the returned
value is the MSO of digest1.
In SP800-56A, OtherInfo is specified as:

OtherInfo ≔ AlgorithmID || PartyUInfo || PartyVInfo {|| SuppPubInfo} {|| SuppPrivInfo}

(10)

where

AlgorithmID

a bit string that indicates how the derived keying material will be parsed
and for which algorithm(s)PartyUInfo

public information contributed by party U (the initiator)

PartyVInfo

public information contributed by party V (the responder)

SuppPubInfo

public information known to both U and V (optional)

SuppPrivInfo

private (secret) information known to both U and V (optional)

This specification requires that OtherInfo be constructed as:Page 46
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library
OtherInfo ≔ Use || PartyUInfo.buffer || PartyVInfo.buffer

(11)

where

Use

a null-terminated string indicating the use of the key (e.g., “DUPLICATE”,“IDENTITY”, “SECRET”, etc.) (see clause 4 for the definition of thesevalues). This field satisfies the requirements of SP800-56A since theparsing of keying material is determined by the use.

PartyUInfo.buffer

the x-coordinate of the public point of an ephemeral key

PartyVInfo.buffer

the x-coordinate of the public point of a static TPM key

The x-coordinates of the public points are sized buffers (that is, integers indicating the size in octets of thebuffer that follows). The buffer data is used in the KDF, but the size field is not.
When this specification calls for use of this KDF, it uses a function reference to KDFe(). The function
prototype is:

KDFe(hashAlg, Z, Use, PartyUInfo, PartyVInfo, bits)

(12)

where

hashAlg

the hash algorithm to be used as H() in equation (9) aboveZ

the product of a public point and a private x-coordinate

Use

a null-terminated string indicating the use of the key (e.g., “DUPLICATE”,“IDENTITY”, “SECRET”, etc.) (see clause 4 for the definition of thesevalues).

PartyUInfo

the x-coordinate of the public point of an ephemeral key

PartyVInfo

the x-coordinate of the public point of a static TPM key

bits

a 32-bit value indicating the number of bits to be returned

The implied return from this function is an octet string containing bits/8 octets. If bits is not an evenmultiple of 8, the return value is the least-significant bits of the return value, and the additional high-order
bits in the 0th octet are CLEAR. The unused bits of the MSO are masked off and not shifted.
NOTE

The function prototype in (12) is not a C-language prototype but, rather, a prototype to illustrate theparameters of the KDF for specific uses. The C -language prototype will include an extra parameterthat will be the buffer to receive the key material generated by the KDF.

11.4.10.4 Rejection of weak keys
Some algorithms have known weak keys. If such a key is generated, it must be discarded, and a new key
generated by starting over with another iteration of the KDF. In the case of DES, there are 64 known
weak or semi-weak keys. None of them are allowed. In the case of AES, at least one bit in the upper halfof the key must be set. Again, if this is not true, the key must be discarded, and a new key generated bystarting over with another iteration of the KDF.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 47
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Random Number Generator (RNG) Module
11.4.11.1 Source of Randomness
The RNG is the source of randomness in the TPM. The TPM uses random values for nonces, in key
generation, and for randomness in signatures.
The RNG is a Protected Capability with no access control. It nominally consists of•an entropy source and collector,•a state register, and•a mixing function (typically, an approved hash function).

The entropy collector collects entropy from entropy sources and removes bias. The collected entropy isthen used to update the state register providing input to the mixing function to produce the random
numbers.
The mixing function can be implemented with a pseudo-random number generator (a PRNG). A PRNG
can produce numbers that are apparently random from a non-random input (such as, a counter).
Combining an approved PRNG with an input that has considerably more entropy than a counter yields an
RNG with properties no worse than the underlying PRNG and possibly much better.
The RNG should meet the certification requirements of the intended market.
The TPM should provide sufficient randomness for each use by an internal function. When accessed by
an external call, it should be able to provide 32 octets of randomness. Larger requests can fail if
insufficient randomness is available.
Each RNG access produces a new value regardless of the data’s use. There is no distinction between
accesses for internal versus external purposes.
11.4.11.2 Entropy Source and Collector
A TPM should have at least one internal source of entropy, and possibly more. These sources could
include noise, clock variations, air movement, and other types of events.
As noted, the entropy collector is the process that collects the entropy from various sources and removes
bias.
EXAMPLE

If the entropy source has a bias of creating 60 percent 1s and only 40 percent 0s, then the collector
design corrects the bias before sending the information to the state register.

The entropy source and collector should provide entropy to the state register in a manner that is not
visible to an outside process or other TPM capability.
The entropy collector should regularly update the state register with additional, unbiased entropy.

Page 48
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Entropy
Sourceentropy
Entropy Protected Capability

randombits
randomnumbers

TPM2_StirRandom()
DRBG Protected Capability

RNG Protected Capability
Figure 4 — Random Number Generation
Any Protected Capability that requires an unpredictable number obtains it from a Random Number
Generator (RNG) Protected Capability in the same TPM. The RNG Protected Capability assembles
random bits from a Deterministic Random Bit Generator (DRBG) Protected Capability in the same TPM.
The DRBG Protected Capability obtains entropy from the entropy Protected Capability in the same TPM
and the TPM2_StirRandom() Protected Capability can be used to add additional information. The entropy
Protected Capability obtains entropy from an entropy source in the same TPM.
NOTE 1The "additional information" added by TPM2_StirRandom() could be entropy gathered from othersources but the TPM has no way of determining if the value has any entropy or not. As aconsequence, it is just deemed to be "additional information."

NOTE 2

It is recommended that the DRBG Protected Capability of a non-FIPS TPM consists of a DRBG
mechanism that complies with NIST Recommendation SP800-90 A, revised March 2012; except it
does not comply with its Clause 11.

NOTE 3

The DRBG Protected Capability of a FIPS TPM consists of a DRBG mechanism that complies with
NIST Recommendation SP800-90 A, revised March 2012.

The DRBG mechanism security should be at least as strong as the security strength of the strongest
cryptographic algorithm implemented in the TPM.
The DRBG Protected Capability should be reseeded using entropy from the entropy Protected Capability
when:•

a flag is SET indicating that reseeding is required;•

TPM2_StirRandom() is executed;•

after the TPM has failed a self-test; or•before the SPS is replaced.

It may be reseeded at other times, as well.
NOTE 4Each TPM can be seeded during TPM manufacture, via a manufacturer -specific method, using apersonalization string for the DRBG that is specific to the manufacturer and the type of TPM, plus amanufacturer-provided nonce that is specific to the individual TPM.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 49
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

11.4.11.3 Nonce Creation
The RNG module provides the bits used in any TPM-generated nonce.
Algorithms
11.4.12.1 Algorithm Identifiers
The structures and commands in this specification are constructed with minimal reliance on algorithm
defaults.
In most cases, an algorithm identifier identifies a family of algorithms followed by qualifiers. This differsfrom the TPM 1.2 version of the specification, which often included the key size in the algorithm identifier(TPM_ALG_AES128). This specification only uses the TPM 1.2 form of algorithm identifiers for hashalgorithms.
Since this specification depends on being able to discern the hash output size from the algorithm ID, its
hash algorithm identifiers imply a digest size.
EXAMPLE 1

Some of the hash
TPM_ALG_SM3_256.

algorithm

identifiersare

TPM_ALG_SHA 256,

TPM_ALG_SHA384,

and

Algorithm identifiers for symmetric and asymmetric encryption identify the family, such as RSA, ECC,
AES, etc. For these algorithms, supplementary information is required to define parameters.
EXAMPLE 2

Some family algorithm identifiers are TPM_ALG_ECC, TPM_ALG_RSA, TP M_ALG_SM4, and
TPM_ALG_AES.

11.4.12.2 Algorithm Support
This specification does not require implementation of any specific set of algorithms. When determining
algorithms or algorithm sets supported, implementers should carefully consider factors such as use
cases, strength of function, interoperability, backward compatibility, algorithm diversity, etc. TCG
recommends using TCG platform-specific specifications that reflect industry best practices.
NOTE 1

It is anticipated that support for TPM 1.2 compatibility will be retained unless support for the 1.2
algorithms (RSA 2048 and SHA1) would prevent that TPM from being sold.

TCG will specify sets of algorithms to be incorporated by various platform-specific specifications. Each set
includes a minimum of one hash algorithm, one symmetric encryption algorithm with approved
parameters, and one asymmetric encryption/signing algorithm with approved parameters. Without acomplete set of algorithms, the TPM would be unable to support all necessary functions.
A TPM may support algorithms in addition to the required sets. These do not need to be part of any set.
For example, the TPM may include an additional hash algorithm without including an additional
asymmetric or symmetric algorithm.
It is possible, and very likely given the multitude of algorithms supported by the TPM, that key-size
support will differ between TPM implementations. In addition, keys created by outside software cangreatly increase the number of key sizes that are possible to load.
A TPM will not create or load an object that uses an algorithm that is not supported by the TPM. Whencreating an object, the TPM checks the template for the object being created and when loading an object,
the TPM checks the public area of the object. In both cases, the TPM validates that it supports all of theindicated algorithms, parameters, and key sizes.

Page 50
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The strength of at least one algorithm set supported by a TPM should be at least 112 bits. Other
algorithms and algorithm sets can be supported in any combination.
A set’s strength is normally determined by the number of bits in a key of the symmetric algorithm. An
exception is Suite B, Top Secret, where the strength is considered to be 192 bits even though thesymmetric algorithm has 256-bit keys.

NOTE 2

If a TPM supports RSA, it should support a key size of 2048 bits or larger. Support for smaller key sizes isallowed but discouraged.
NOTE 3

Support for smaller keys is allowed so that legacy keys can continue to be supported. Use of keysizes less than 1024 bits is strongly discouraged.

A platform-specific specification may mandate support for algorithms or algorithm sets. It may select only
those algorithms for which the TCG has assigned algorithm identifiers.
A TPM can only implement algorithms that have a TCG-assigned algorithm ID.
11.5

Authorization Subsystem

The Authorization Subsystem is called by the Command Dispatch module at the beginning and end ofcommand execution. Before the command can be executed, the Authorization Subsystem checks thatproper authorization for use of each of the Shielded Locations has been provided.
Some commands access Shielded Locations that require no authorizations; access to some locations
may require a single-factor authorization; and access to other Shielded Locations may require use of an
authorization policy of arbitrary complexity.
The only cryptographic functions required by the Authorization Subsystem are hash and HMAC. An
asymmetric algorithm may be required if TPM2_PolicySigned() is implemented.
The details of the different methods of authorization are provided in Clause 19.
11.6

Random Access Memory
Introduction

Random access memory (RAM) holds TPM transient data. Data in TPM RAM is allowed, but not required,to be lost when TPM power is removed. Because the values in TPM RAM may be lost, in thisspecification they are referred to as being volatile, even if the data loss is implementation-dependent.
When the specification refers to a value that has both volatile and non-volatile copies, they may be kept ina single location as long as that location has the properties of allowing random access and having
unlimited endurance.
Not all values in TPM RAM are in Shielded Locations. A portion of TPM RAM contains the I/O buffer withproperties that are described in 11.3.
Platform Configuration Registers (PCR)
PCR are Shielded Locations used to validate the contents of a log of measurements. The nominal
behavior of a trusted platform is to maintain, in a log, a record of the events that affect the security stateof the platform, at least through the boot process while it is establishing the TCB. When additions are
made to the log, the TPM receives a copy of the log entry or the digest of data described by the log. The

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 51
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

data sent to the TPM is included in an accumulative hash in a PCR. The TPM can then provide anattestation of the value in the PCR, which, in turn, verifies the contents of the log.
It is possible for a single PCR to record all log entries. However, this would make it difficult to evaluate thedifferent stages of platform evolution as it boots into the operating system. Normally, multiple PCR areprovided in a TPM to allow simplification of the evaluation.
EXAMPLE 1

A TPM intended for a PC could have a PCR dedicated to recording measurements of the BIOS, a
PCR dedicated to the boot ROM on add-in cards, and a PCR dedicated to the OS loader. The
platform-specific specifications determine the number of PCR and their attributes in a TPM.

PCR can also be used to gate access to an object. If selected PCR do not have the required values, theTPM will not allow use of the object.
A TPM may maintain multiple banks of PCR. A PCR bank is a collection of PCR that are Extended withthe same hash algorithm. PCR banks are identified by the hash algorithm used to Extend the PCR in thatbank.
Multiple banks can handle situations where one hash algorithm is required for legacy or compatibility with
one set of applications, while a different hash algorithm is required to meet the security needs of anotherapplication. Within a bank, all PCR updates use the same hash algorithm. Not all banks need to have thesame number of PCR, but the attributes of all PCR with the same Index, other than hash algorithm, arethe same in all banks.
EXAMPLE 2

If PCR[0] has an attribute that allows it to be reset by TPM2_PCR_Rese t(), then that attributeapplies to PCR[0] in all banks.

NOTE 1Since banks may have different numbers of PCR, a PCR Index value may not be valid for all banks.
The allocation of PCR can also be changed by TPM2_PCR_Allocate() using Platform Authorization.
Changing the PCR allocation does not change the attributes of the PCR.

The contents of a PCR can be modified or reported. The two ways to modify a PCR are to reset it orExtend it. Reporting on a PCR can be accomplished through simple reading, inclusion in an attestation, or
inclusion in a policy.
Although listed in this clause, PCR need not be maintained in RAM. They may be kept in non-volatilememory. If kept in non-volatile memory, consideration must be made for the possible impact on TPM
performance during the critical boot phase, when many measurements are recorded.
A TPM is required to implement a PCR bank for each supported algorithm. However, a PCR bank may be
defined such that it contains no PCR.
NOTE 2

The requirement that a PCR bank be implemented for each hash algorithm allows the unmarshaling
to be based on the implemented algorithms rather than the implemented PCR.

The TPM may support Resume PCR that retain their state across a TPM Resume sequence but are set
to their default initial value on TPM Reset or TPM Restart.
Object StoreTPM RAM holds keys and data that are loaded into the TPM from external memory. In most cases, anobject cannot be used or modified unless it was first loaded into TPM RAM with one of the object loadcommands: (TPM2_Load(), TPM2_CreatePrimary(), TPM2_LoadExternal(), or TPM2_ContextLoad()).
NOTE

TPM2_Create() does not automatically load the object. After creation, t he object needs to be
explicitly loaded with TPM2_Load(), to load both the public and private portions, or with
TPM2_LoadExternal() to load just the public portion.

Page 52
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The structure used for keys can be generalized for use on data objects if the access properties used forkeys are suitable for access to these objects.
EXAMPLEA data blob can be defined so that access requires that some set of PCR has defined values, or an
authorization value is needed for access. Such a data blob, called a Sealed Data Object, ismanaged in the same way that a key is managed. That is, the Sealed Data Object has to be loaded
before being accessed, and the loaded blob can be context saved.

The TPM operates on other structures that are passed as parameters in specific commands. These
structures are transient and are not stored in the TPM as identifiable entities after the command hascompleted.
Items loaded in the TPM are given handles to let them be referenced in subsequent commands.
Session StoreThe TPM uses sessions to control a sequence of operations. A session can audit actions, provide
authorizations for actions, or encrypt parameters passed in commands.
A session can be created as needed using one of the session creation commands. The session is
assigned a handle at that time.
A TPM may be designed so that the RAM used for sessions is from a memory pool shared with the object
store. It may also be designed so that the session store and object store are separated and dedicated.
Size Requirements
Random access memory (RAM) should be large enough to handle the transient state, sessions, andobjects needed for completion of any implemented command. The minimums for the worst-casecommand in this specification are:•two loaded entities (two keys, a key and a Sealed Data Object, or a hash/HMAC sequence and a
key);

•

three authorization sessions;•an input buffer able to accommodate the largest command or an output buffer required for thelargest possible response;

NOTE

The largest command or response depends on the algorithms supported by the implementation.

•

any vendor-defined state required for operation; and•all defined PCR.

11.7

Non-Volatile (NV) Memory

The NV memory module stores persistent state associated with the TPM. Some NV memory is available
for allocation and use by the platform and entities authorized by the TPM Owner.
TPM NV memory contains Shielded Locations and Shielded Location can only be accessed withProtected Capabilities.
If the specification is not explicit about storage of a parameter, that parameter may be in either RAM or
NV, according to vendor preference.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 53
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

If the NV memory of the TPM is subject to wear, then the TPM should detect whether the data being
written to an NV memory location is the same as that currently stored and not perform the NV write if they
are the same.
The OS or the platform can define a special NV data structure (an NV Index) in order to store persistent
data values. NV memory can also be used persistently to store a loaded object. When a persistent object
is referenced in a TPM command, the TPM may move that object into an object slot so it can be accessedmore efficiently. The TRM needs to ensure that sufficient object memory RAM is available to allow thismovement.
NOTE

The movement occurs transparently.

A TPM capability indicates if the TPM is using Transient Object resources when a command references apersistent object. If so, the TRM needs to ensure that a Transient Object slot is available for eachpersistent object so referenced.
11.8

Power Detection ModuleThis module manages TPM power states in conjunction with platform power states.
All platform-specific TCG specifications that define the binding of the TPM to the platform should include
a requirement that the TPM be notified of all power state changes.
The TPM supports only the ON and OFF power states. Any system power transition requiring the RTM tobe reset also causes the TPM to be reset (_TPM_Init). Any system power transition that causes the TPM
to be reset will also cause the RTM to be reset.
NOTE

In most cases, the RTM will be a host CPU.

Page 54
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

TPM Operational States
12.1

Introduction

This clause describes TPM operational states and state transitions.
12.2

Basic TPM Operational States
Power-off StateA hardware TPM is in the Power-off state when reset is being asserted or when no power is applied to the
TPM. The TPM may internally generate reset by detecting low power or reset may be provided by an
external source.
It is possible to transition to the Power-off state from any other state because power can be lost at any
time.
NOTE

Uncontrolled transitions to this state are not shown in diagrams/descriptions because they would
add unnecessary clutter and provide no additional understanding.

Initialization StateThe TPM is placed in its initialization state when it receives the _TPM_Init indication. _TPM_Init isprovided in a platform-specific manner. For a hardware TPM, the _TPM_Init is normally signaled by thede-assertion of the TPM’s reset signal. It may also be signaled by an interface protocol or setting. For asoftware implementation, _TPM_Init may be a dedicated procedure call.
Regardless of how it is generated, _TPM_Init should coincide with a reset of the Roots of Trust for
Measurement for which the TPM is the Root of Trust for Reporting. For example, if the TPM is acomponent on the PC’s motherboard, _TPM_Init should coincide with a reset of the processor andchipset. After _TPM_Init is indicated, the RTM should begin executing the Core Root of Trust for
Measurement. It should not be possible to reset the TPM without resetting the RTM. It should not be
possible to reset the RTM without resetting the TPM.
While in the Initialization state, the TPM performs basic initialization functions in preparation for accepting
commands on the TPM interface. These functions are implementation dependent but, minimally, the TPM
should perform validation of the TPM firmware necessary to execute the expected command. If the TPM
is in Field Upgrade mode (FUM), the expected command is TPM2_FieldUpgradeData(). If the TPM is not
in FUM, the expected command is TPM2_Startup().
After completing the initializations, the TPM waits for the next command and, if the command is not the
expected first command, the TPM will return an error indicative of the mode. If the TPM returns an error, it
will continue to wait for the expected first command.
NOTE 1

If the TPM is not in FUM, it returns TPM_RC_INITIALIZE. If the TPM is in FUM, it returns
TPM_RC_UPGRADE.

NOTE 2

If TPM2_Startup()/TPM2_FieldUpgrateData() is not the first command to the TPM, i t indicates failureof the system to properly enter the CRTM, and the reliability of TPM measurements cannot be
assured. While it is possible to define a special failure mode that prohibits just PCR -related
operations, it is expected to be infrequent enoug h not to warrant such a mode and, as shown in
Figure 5, the TPM does not enter Failure Mode, if the first command is not TPM2_Startup().

When the TPM receives TPM2_Startup(), it becomes operational and is able to process other commands.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 55
December 24, 2020

Trusted Platform Module Library
NOTE 3

Part 1: Architecture

For compliance with other standards, such as FIPS 140, it is necessary for the TPM to validate thefirmware associated with a command’s execution before that command is ex ecuted. This includes
the code associated with TPM2_Startup() and TPM2_FieldUpgadeData(). A digital signature ormessage authentication code.

Occasionally, some TPM state could need to be retained over a power transition. This might occur if theplatform is entering the Suspend state, where the preponderance of system state is retained. To allow the
TPM to reflect this condition, system software can issue TPM2_Shutdown(TPM_SU_STATE) to the TPM.
TPM2_Shutdown() initiates an orderly shutdown of the TPM. The command’s startupType parameter
indicates the type of startup that is anticipated to follow and the type of data to be saved. For
TPM2_Shutdown(TPM_SU_CLEAR), the amount of data saved to NV memory is relatively small, withconsiderably more information retained when TPM_SU_STATE is indicated.
Startup State12.2.3.1

TPM2_Startup()

TPM2_Startup() transitions the TPM from the Initialization state to an Operational state. The commandincludes information from the platform to inform the TPM of the platform’s operating state.
TPM2_Startup() has two options: TPM_SU_CLEAR and TPM_SU_STATE. The operating state of a TPM
after TPM2_Startup() is dependent on how the TPM was shut down and the selected startup option.
12.2.3.2

Startup Types

The following terms are used to refer to the different startup and shutdown operations:•Startup(CLEAR) means TPM2_Startup(startupType == TPM_SU_CLEAR);•

Startup(STATE) means TPM2_Startup(startupType == TPM_SU_STATE);•

Shutdown(STATE) means TPM2_Shutdown(startupType == TPM_SU_STATE); and•Shutdown(CLEAR) means TPM2_Shutdown(startupType == TPM_SU_CLEAR).

The combinations of Shutdown() and Startup() provide three unique methods of preparing the TPM for
operation:1) TPM Reset is a Startup(CLEAR) that follows a Shutdown(CLEAR), or a Startup(CLEAR) for which
there was no preceding Shutdown() (that is, a disorderly shutdown). A TPM Reset is roughly
analogous to a reboot of a platform. As with a reboot, most values are placed in a default initial state,
but persistent values are retained. Any value that is not required by this specification to be kept in NV
memory is reinitialized. In some cases, this means that values are cleared, in others it means thatnew random values are selected.
2) TPM Restart is a Startup(CLEAR) that follows a Shutdown(STATE). This indicates a system that isrestoring the OS from non-volatile storage, sometimes called “hibernation”. For a TPM Restart, theTPM restores values saved by the preceding Shutdown(STATE) except that all the PCR are set totheir default initial state. This allows the TPM to record the boot sequence to ensure that the TCB isproperly instantiated while allowing continued function of the restored OS.
3) TPM Resume is a Startup(STATE) that follows a Shutdown(STATE). This indicates a system that isrestarting the OS from RAM memory, sometimes called “sleep.” For sleep, the expectation is that the
CRTM will perform the minimal actions required to make the system functional and then “return” tothe running OS rather than rebooting it. TPM Resume restores all of the state that was saved by
Shutdown(STATE), including those PCR that are designated as being preserved by Startup(STATE).
PCR not designated as being preserved, are reset to their default initial state.

Page 56
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
NOTE 1

Trusted Platform Module Library

The PCR are designated in a platform-specific specification.

If the TPM receives Startup(STATE) that was not preceded by Shutdown(STATE), then there is no state
to restore and the TPM will return TPM_RC_VALUE. The CRTM is expected to take corrective action toprevent malicious software from manipulating the PCR values such that they would misrepresent thestate of the platform. The CRTM would abort the Startup(State) and restart with Startup(CLEAR).
NOTE 2The startup behavior defined by this specification is different than TPM 1.2 with respect toStartup(STATE). A TPM 1.2 device will enter Failure Mode if no state is available when the TPM
receives Startup(STATE). This is not the case in this specification. It is up to the CRTM to takecorrective action if it the TPM returns TPM_RC_VALUE in response to Startup(STATE).

The TPM is required to validate the integrity of any NV values before those values are used before thatstate is used. This includes the state saved by TPM2_Shutdown(STATE)(see 12.2.4). When the TPM
determines that some NV value required for proper TPM operation is not valid, the TPM will enter Failure
Mode.
It is not specified when the validation of state specific to TPM Resume is to be checked. This gives
implementation options that may be specified by a platform-specific specification or determined by thevendor.
The startup sequences are illustrated in Figure 5.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 57
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Device Reset
DeviceReset

In FUMN_TPM_Init
Indication

Minimally includes self-test
for TPM2_FieldUpgradeData()

Y

Initialization for
Fieldupgrade

Minimally includes self-test
for TPM2_Startup()

Initialization forStartupN

Y

Wait For
Command

Was Previous
Shutdown(STATE)YIs Command
Startup(STATE)

Restore Saved State
Command
ReceivedN
Set Default StateIs Command
TPM2_Startup()

Is Command
Startup(CLEAR)

Y

Y
N

N
Set PCR to Default
Initialization StateTPM Reset

TPM Restart

Was Restore
SuccessfulY

TPM ResumeN

SET Initialized

ReturnTPM_RC_INITIALIZE

ReturnTPM_RC_VALUE

ReturnTPM_RC_SUCCESS

Operational

FailureMode

FUM
ResumeFigure 5 — TPM Startup Sequences
Shutdown State
TPM2_Shutdown() is used to prepare the TPM for loss of power. As with TPM2_Startup(),
TPM2_Shutdown() has two options: TPM_SU_CLEAR and TPM_SU_STATE.
Page 58
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

TPM2_Shutdown(TPM_SU_STATE) preserves the majority of the TPM operational state so that it can berestored on a subsequent TPM2_Startup(). TPM2_Shutdown(TPM_SU_CLEAR) preserves a minimal
amount of state, mostly to ensure continuity of the TPM timing functions.
NOTE

The timing functions are described in Clause 36.

The TPM preserves state data in NV memory. Data is copied from RAM into NV memory so that it is not
lost when power is removed from the TPM. The amount of data copied to NV memory is largely
implementation-dependent, but the specification indicates the state data that is required to be preserved.
This state data is recovered in a subsequent TPM2_Startup(). The type of startup determines what partsof the saved state data is restored and what is discarded.
A shutdown is “orderly” if the TPM receives TPM2_Shutdown() before power is lost and if the state is not
subsequently modified by a TPM command before the next _TPM_Init.
These commands will invalidate saved TPM state:
NOTE

This is not an inclusive list:•

TPM2_Clear(), TPM2_ChangeEPS(), TPM2_ChangePPS() – these commands invalidate saved
contexts in the hierarchy. TPM2_Clear() invalidates preserved contexts in both the storage andendorsement hierarchies.

•

TPM2_ContextSave() – context variables are modified by context save. Saving a session context
changes the session context ID and its tracking state (saved or in memory). Saving an object
context changes the object context ID.

•

TPM2_ContextLoad() for a session – the context ID and tracking state (in TPM or context saved)for each active session should be retained across a TPM Restart or TPM Resume sequence.
Saving or loading a session context changes the context ID or its tracking state. Saving or loading
an object context need not invalidate a preserved context.

•

Any command that modifies a PCR – regardless of the implementation, any change to a Resume
PCR will invalidate the saved state. If the TPM implements TPM2_PolicyPCR() and uses a PCR
generation counter, any PCR modification will change this counter value.

EXAMPLE•If a Shutdown(STATE) occurs but, prior to Startup(STATE), a TPM2_PCR_Event() is executed
selecting a Resume PCR, then the preserved state is no longer valid, and Startup(STATE) is not
valid until another Shutdown(STATE) occurs.

Any command that modifies Clock or returns the value of Clock.

A TPM implementation
TPM2_GetCapability().

may

invalidateapreserved

contextonanycommandexceptStartup Alternatives
The description of the startup process above was given in terms of a command interface. In somesystems, the TPM code is run in a special processor mode that provides the required isolation between
the TPM state and any other program state. For these implementations, TPM2_Startup() may not be acommand that is actually implemented. That is, the platform initialization can boot, validate the TPM code,and place the TPM in a state that is functionally equivalent to having run TPM2_Startup() on a discrete
TPM component.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 59
December 24, 2020

Trusted Platform Module Library
12.3

Part 1: Architecture

Self-Test Modes

If a command requires use of an untested algorithm or functional module, the TPM performs the test andthen completes the command actions. When performing a self-test on demand, the TPM should test only
those algorithms needed to complete the command (see Figure 6).
NOTE 1

It is preferable for the TPM to perform self-tests on untested algorithms and functional blocks as a
background task to increase the likelihood that algorithms are tested before they are needed.

Operational

Wait For
CommandCommand uses
untestedfunctions?

Test Required
FunctionsY

Test Successful?

Y

N

N

ReturnTPM_RC_FAILURE

Process
CommandReturn Result

FailureMode

Figure 6 — On-Demand Self-TestAftersending
TPM2_Startup(),thesystemmayuseeither
TPM2_SelfTest()
or
TPM2_IncrementalSelfTest() to cause the TPM to perform tests of untested algorithms. TPM2_SelfTest()
may optionally cause the TPM to perform a full self-test of all algorithms and functional blocks. Oncethese commands are issued, the TPM returns TPM_RC_TESTING for any command that requires use of
any testable function until all requested tests are completed.
FIPS 140-2 requires that all power-on self-tests be complete before the TPM returns any value that
depends on the results of a testable function. If compliance with FIPS 140-2 is required, any commandthat requires use of an untested function causes the TPM to operate as if TPM2_SelfTest(fullTest = NO)
was received. The TPM returns TPM_RC_TESTING and continues to return TPM_RC_TESTING until all
tests are complete. Alternatively, it may complete all tests and then complete the command. It may also
return TPM_RC_NEEDS_TEST.
Page 60
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
NOTE 3

Trusted Platform Module Library

Authenticated tests can be generated by attaching an audit session to TPM2_GetTestResult() andthen using TPM2_GetSessionAuditDigest() to obtain the signature.

If any self-tests fail, the TPM goes into Failure mode and does not allow execution of any Protected
Capabilities except TPM2_GetTestResult() and TPM2_GetCapability(). The TPM exits Failure mode
when it receives _TPM_Init.
12.4

Failure Mode

If the TPM fails an internal test, it enters Failure mode. While in Failure mode, the TPM returns
TPM_RC_FAILURE
in responseto anycommand except TPM2_GetTestResult() or
TPM2_GetCapability() (see Figure 7). While in Failure mode, the TPM is only required to provide a limited
number of property values. They are all in the set of TPM properties (TPM_CAP_TPM_PROPERTIES):•

TPM_PT_MANUFACTURER•

TPM_PT_VENDOR_STRING_1•

TPM_PT_VENDOR_STRING_2•

TPM_PT_VENDOR_STRING_3•

TPM_PT_VENDOR_STRING_4•

TPM_PT_VENDOR_TPM_TYPE•

TPM_PT_FIRMWARE_VERSION_1•

TPM_PT_FIRMWARE_VERSION_2

NOTE

An implementation is allowed to return other property values.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 61
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Failure
Mode

NOTE:

Only exit from Failure
Mode is _TPM_Init

Wait For
CommandY

TPM2_GetTestResult()

N
Return Test ResultsY

TPM2_GetCapability()

Return Capability

N

ReturnTPM_RC_FAILURE

Figure 7 — Failure Mode Behavior
12.5

Field Upgrade
Introduction

This specification describes optional Protected Capabilities for upgrading the TPM firmware. The methods
described in this specification would allow the upgrade process to be handled in a standard way on TPMs
from multiple vendors. The methods described here should not be viewed as limiting the vendor's options
for implementation of their own, vendor-specific methods for upgrading the TPM firmware. However, thefield upgrade methods chosen by the vendor should not be less robust than the methods described in thisspecification. In particular, the authorizations for the upgrade should be the same as the field upgradecommands in this specification.
Field Upgrade Mode
This specification describes two optional upgrade methods: full and incremental. These terms do not refer
to how much of the firmware in the TPM changes, but to how the upgrade is applied.
•

For a full upgrade, the TPM stores in Shielded Locations all blocks of the firmware update. It
makes no change to the executing firmware unless all the blocks are confirmed to be correct. The
upgrade process may be interrupted or abandoned without affecting TPM functionality.

Page 62
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture•

Trusted Platform Module Library

For an incremental upgrade, firmware updates may be applied as each block is received. The
TPM may not be fully functional if the upgrade process is abandoned.

The field upgrade process starts when the TPM receives a properly authorized
TPM2_FieldUpgradeStart() (see Figure 6). That command contains the digest of a first block of the
upgrade. If the next command is TPM2_FieldUpgradeData() and the digest of the data parameter(fuData) of the command matches the signed digest in TPM2_FieldUgradeStart(), the TPM accepts
fuData as containing the upgrade data.
The TPM may buffer firmware update blocks and not change the firmware until its buffer is full. When aconsequential change to the running firmware is made, the TPM enters Field Upgrade mode (FUM) anddoes not accept any command but TPM2_FieldUpgradeData() until the update is complete (see Figure7). Before the TPM enters FUM•

it may accept other commands, and•the update sequence may be abandoned by sending a zero-length upgrade data buffer. The TPM
acknowledges that it has abandoned the field upgrade by returning TPM_ALG_NULL for
nextDigest.

When the field upgrade process is complete, the TPM may either return to normal operation or enter amode that requires _TPM_Init before normal TPM operations resume. The TPM vendor should determine
if a reboot is required after the firmware update and cause the TPM to set the mode appropriately.
If the TPM is reset (_TPM_Init) while in FUM and the TPM is not able to revert to normal operation, threepossibilities exist for recovery. The choice is determined by the digest of the first upgrade block provided
to the TPM after _TPM_Init. The TPM may retain up to three digest values that it uses for comparison:
1) the digest of the first upgrade block of the current sequence to be used when the intent is to restart
the current upgrade sequence from the start (called Digest C in Figure 8);2) the digest of the first block of the firmware that was being replaced (called Digest P in Figure 8) to be
used when the intent is to abort the upgrade and restore the previous firmware; and3) the digest of the first upgrade block of the factory installed firmware (called Digest F in Figure 8) torestore the TPM to its factory state.
To enable option 2) above, the TPM may support TPM2_FirmwareRead() so that the software performing
the upgrade can save a copy of the current TPM firmware in case the upgrade fails.
TPM2_FirmwareRead() may not be supported on a TPM even if the TPM can perform a field upgrade.
If _TPM_Init is received while the TPM is in FUM, then TPM Reset is required after the field upgrade
completes, regardless of the nature of the firmware changes. This reset is required because the TPM
does not accept TPM2_Startup() while in FUM, and the TPM will not reflect the state of the platform.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 63
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Digest P (Previous) is thedigest of the first data blockin the firmware being
replaced.

FUM
ResumeH(fuData) ==Y

Digest P

N

Wait For
Command

Digest F (Factory) is the digest of
the first data block of the factory
installed TPM firmware.

H(fuData) ==Y

Digest F
TPM2_FieldUpgradeData()

Y

N

N
N
ReturnTPM_RC_UPGRADE
ReturnDigest C and Dnext

Digest C = Digest P

Digest C = Digest F

Dnext is the expected digestof the next data block in thecurrent sequence,

H(fuData) ==

Y

Dnext

Digest C (Current) is thedigest of the first block of thefirmware being installed.

FUM
Continue

Figure 8 — Resuming Field Upgrade Mode after _TPM_Init

Page 64
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryEnter FUM after TPM receives a valid
fuData block and the TPM makes afirmware change that does not allow
the TPM to continue normal
operations

FUM

Wait For
Command
NOTE: Dnext is the digest of thenext expected block of
the current firmware
update sequence

TPM2_FieldUpgradeData()

N

Y

Load fnData
Dnext := Next Block Digest

Dnext == emptyH(fnData) ==Dnext

ReturnTPM_RC_UPGRADE

FUM
Continue

Y

Y

N

N
Complete Upgrade
FUM := FALSE
ReturnDigest C and Dnext

N

Initialized ==TRUEY

TPM remains in thisloop until _TPM_Init
Y

Return TPM_RC_REBOOT

Restart RequiredN
ReturnnextDigest := TPM_ALG_NULL

Wait For
CommandOperational

Figure 9 — Field Upgrade Mode
Preserved TPM StateA field upgrade cannot cause exposure of any data that is specific to a TPM instance. This includes:
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 65
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture•Primary Seeds;•

Hierarchy authValue, authPolicy, and proof values;•

lockoutAuth and authorization failure count values;•

PCR authValue and authPolicy values;•

NV Index allocations and contents;•

Persistent object allocations and contents; and•Clock.

In particular, if the TPM supports TPM2_FirmwareRead(), the returned data is not allowed to contain any
data that is unique to the TPM instance.
A field upgrade should not cause the loss of any data that is specific to a TPM instance.
NOTE 1

A platform manufacturer may provide a means to change preserved data to accommodate a casewhere a field upgrade fixes a flaw that might have compromised TPM secrets.

Field Upgrade Implementation Options
The method described above for management of a TPM field upgrade is intended for use in a TPM that is
implemented as stand-alone component (that is, when the TPM is manufactured and sold as acomponent that is added to a platform). When the TPM is not a stand-alone component, other methods offield upgrade are possible and are not precluded by this specification.
If other methods are used, the security of that method is the responsibility of the platform manufacturer.

Page 66
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

TPM Control Domains
13.1

Introduction

Three entities control the TPM: the platform firmware, the platform Owner, and the Privacy Administrator.
The Owner and Privacy Administrator are often the same entity. This control does not give these entities
the ability to access user keys or data, but it does give them the ability to control selected TPM resources.
Each of the three entities has its own domain of control. Within that domain are TPM resources reservedto that entity. Each entity exercises its control over its domain by use of domain-specific authorization
values.
The NV space defined by the platform firmware has an additional control, phEnableNV. When SET, NV
space defined by the platform firmware is accessible. When CLEAR, it is inaccessible. This permits
independent control of the platform firmware hierarchy and its NV space. For example, the platform
hierarchy can be disabled while still permitting access to platform firmware NV space.
13.2

Controls

The platform firmware, platform Owner, and Privacy Administrator each have an authorization value andan authorization policy to control some portion of the TPM, including a specific Primary Seed (see clause14). The authorizations, policies, and Primary Seed for each domain are:•platformAuth/platformPolicy/PPS for platform firmware;•ownerAuth/ownerPolicy/SPS for the Owner; and•endorsementAuth/endorsementPolicy/EPS for the Privacy Administrator.

Associated with each hierarchy is a logical switch (that is, an “enable”) that determines whether thehierarchy is enabled. These enables are phEnable, shEnable, and ehEnable.
When the enable for a hierarchy is SET (1) and the specification indicates that an action can be
authorized with an authorization value, the corresponding policy is also allowed. For instance, when
phEnable is SET and platformAuth is allowed, platformPolicy can also be used.
When the enable for a hierarchy is CLEAR, neither the corresponding authValue nor authPolicy canauthorize operations.
The interaction of the two authorization types (value and policy) and the associated hierarchy enable areintended to provide a flexible set of controls. Table 2 shows the control combinations.
Table 2 shows the authValue as either being "Known" or "Unknown". These correspond to the enabled
and disabled states for an authValue. When the authValue is known, it can be used for authorization, but
it cannot be used when the authValue is unknown. Since a zero-length string (Empty Buffer) is a valid,knowable authValue; the way to make the authValue unknown, and disable its use, is to set it to a large
random number and then discard that number.
Table 2 shows the authPolicy as either being "Set" or "Empty". These also correspond to the enabled anddisabled states for an authPolicy. An authPolicy will have to match the value of a digest (policyDigest) inorder for it to be a valid authorization. Since no digest has a zero length, setting the authPolicy to an
Empty Buffer will disable use of the authPolicy. It is also possible to disable use of the authPolicy by
setting it to any value that does not represent a known policy but the conventional way to disable use of
authPolicy is to set it to an Empty Buffer (see 19.7 for the description of policyDigest generation and use).

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 67
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Table 2 — Hierarchy Control Setting Combinations
hierarchy
enableauthValue

authPolicy

Description

SET

Known

Set

The hierarchy is enabled, and objects in it can be loaded. Either
authValue or authPolicy can manage resources related to thehierarchy.

SET

UnknownSet

The authValue can be made unknown by setting it to a random value
and then discarding the value. This prevents the authValue from being
used. This combination is useful for keeping the hierarchy enabled but
using a policy-based delegation scheme for managing hierarchyrelated resources. An example is delegating control of creating
Primary Objects in a hierarchy to one entity while delegating control ofrelated NV resources to a different entity.

SET

Known

Empty

When the authPolicy is empty, it cannot match any policyDigest value
so the use of authPolicy is disabled. This combination is mostanalogous to the control scheme of TPM 1.2, where an authValue(ownerAuth) is used to manage the resources of the single hierarchy
supported by a 1.2 TPM.

CLEAR

N/A

N/A

When an enable is FALSE, the corresponding authValue andauthPolicy cannot be used to authorize any TPM action.

TPM2_HierarchyChangeAuth() can change the authValue associated with a hierarchy but only if thehierarchy is enabled. Either the authPolicy or the authValue of a hierarchy can be used to authorize achange to the authValue.
13.3

Platform Controls

The platform firmware has overall control of the TPM and the availability of the TPM to the platform
Owner or Privacy Administrator. The platform firmware is assumed to be provided by the platform
manufacturer and performs the management of the hardware in preparation for use by an operating
system (the operating system can be provided by a different vendor). In some systems, platform firmware
runs after the OS is loaded. Often this firmware is required to ensure the safety of the system.
EXAMPLE

Some systems have thermal properties that, if not managed properly, could lead to destruction of
the system, and could even lead to the system becoming a fire hazard.

If the firmware is crucial to the safety of the system, the platform manufacturer can design in a firmware
update process that ensures that only firmware approved by the manufacturer for a specific machine isallowed to be loaded on the system. This firmware can use cryptography to validate the firmware update
before it is loaded. The TPM has cryptographic functions that are similar or identical to the functions
needed by the platform firmware for its management of the system. Rather than replicate those
cryptographic capabilities, the platform firmware is given its own set of TPM resources for its use. Reuseof the TPM cryptographic capabilities by the platform is intended primarily as a cost savings.
The platform manufacturer decides if it is possible to disable use of the TPM by the platform. The methodfor disabling use of the TPM by the platform is platform-manufacturer specific.
The properties of the TPM required by the platform manufacturer need not match those of the Owner.
The platform manufacturer decides what cryptographic algorithms are required to safeguard the platform.
These algorithms can differ from the algorithms use by the Owner or the Privacy Administrator.
Platform controls allow the following operations not available to an ordinary TPM user:•

allocation of TPM NV memory;•

PCR configuration;

Page 68
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library•

control of the availability of any key hierarchies; and•change of the PPS, SPS, and EPS and reset of associated authorization values and policy.

NOTE 1This is not a comprehensive list. The uses of the platform controls are documented in TPM 2.0 Part
3. In that document, an authorization of a command that allows the use of the platform handle(TPM_RH_PLATFORM) indicates that the command accepts platformAuth or platformPolicy.

phEnable gates use of both platformAuth/platformPolicy and the PPS hierarchy, as described in theprevious clause. When phEnable is CLEAR, a _TPM_Init is required to SET it.
On any _TPM_Init, phEnable is SET to ensure that the platform can use the TPM during its initialization.
On TPM Reset or TPM Restart, platformAuth is set to an EmptyAuth, and platformPolicy is set to an
Empty Policy.
NOTE 2

Platform controls are reset on TPM Restart because the BIOS goes through a full initialization andhas no memory of any previous authorization values.

NOTE 3phEnable has to be SET before TPM2_Startup when accommodating the case of an interrupted field
upgrade that prevents startup from running. phEnable has to be SET to permit field upgrade
authorization.

A platformAuth/platformPolicy can be used in TPM2_HierarchyControl() to SET or CLEAR shEnable or
ehEnable.
13.4

Owner Controls

The TPM controls available to the Owner are a subset of those available to the platform. These include•

allocation of TPM NV memory, and•control of the availability of any storage hierarchies.

The shEnable gates use of both ownerAuth/ownerPolicy and the SPS hierarchy, as described in clause
13.2.
The shEnable is SET on each TPM Reset, TPM Restart, or when the SPS is changed (TPM2_Clear()).
The shEnable can be CLEAR (TPM2_HierarchyControl()) using either Lockout Authorization or Platform
Authorization. When shEnable is CLEAR, it can only be SET (TPM2_HierarchyControl()) if Platform
Authorization is provided.
The ownerAuth and ownerPolicy values are persistent. They are set to standard initialization values when
the SPS is changed (TPM2_Clear()): ownerAuth is set to an EmptyAuth, and ownerPolicy is set to an
Empty Policy. They can be explicitly changed by designated commands.
13.5

Privacy Administrator Controls

The Privacy administrator has control over the Endorsement Hierarchy and reporting of privacy-sensitive
data.
The Privacy Administrator uses endorsementAuth and endorsementPolicy to exercise its control. The
Privacy Administrator has a more limited domain of control than those of the platform firmware and the
Owner. The cases when endorsementAuth or endorsementPolicy are required are:•when creating Primary Objects in the Endorsement hierarchy, and•when controlling the availability of the Endorsement hierarchy.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 69
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Other actions that can be considered to be privacy-sensitive require use of objects in the Endorsement
hierarchy. For example, certification of a TPM object by the TPM produces a data structure that has datathat could allow cross-correlation of the objects. This data is obfuscated unless the certifying key is in theEndorsement hierarchy. The privacy administrator of the TPM is expected to manage the creation of
objects in the Endorsement hierarchy to ensure that the use of those objects is in accordance with theirprivacy policy.
The ehEnable gates use of endorsementAuth/endorsementPolicy and the EPS hierarchy, as described in
13.1. It also gates use of the vendor-specific handles TPM_RH_AUTH_00 to TPM_RH_AUTH_FF.
Additionally, when the SPS changes, the objects in the EPS hierarchy are flushed from the TPM, and new
EPS objects (that is, Primary Objects) must be created.
NOTE

Clearing the hierarchy is necessary to ensure that the new Owne r cannot abuse objects created by aprevious one and so that objects belonging to the previous Owner cannot compromise the new one.

The ehEnable is SET on each TPM2_Startup(TPM_SU_CLEAR) (that is, TPM Reset or TPM Restart) or
when the SPS is changed (TPM2_Clear()). The ehEnable can be CLEAR using either Endorsement
Authorization or Platform Authorization. When ehEnable is CLEAR, it can be SET using Platform
Authorization
NOTE

TPM2_HierarchyControl() will SET or CLEAR ehEnable if the proper authorization is provided.

The endorsementAuth and endorsementPolicy values are persistent. They are set to standard
initialization values when the SPS (TPM2_Clear()) or EPS (TPM2_ChangeEPS()) are changed:
endorsementAuth is set to an EmptyAuth, and endorsementPolicy is set to an Empty Policy. They can be
explicitly changed by designated commands.
13.6

Primary Seed Authorizations

Use of a Primary Seed to create a Primary Object requires use of the authorization associated with thatPrimary Seed: Platform Authorization for the PPS, Owner Authorization for the SPS, and Endorsement
Authorization for the EPS.
13.7

Lockout Control

A TPM is required to implement a lockout mechanism to protect against so-called “dictionary attacks,”
where an attacker tries numerous authorization values until one succeeds. Dictionary attack protection iscommon for security devices, such as smartcards, that use human input for authorization. A humansource of authorization likely has too little entropy to protect against an automated attack, so logic thatprevents high-speed guessing of the values is required.
When the dictionary attack lockout is engaged, preventing use of some resources, it is helpful to have asecret value that resets lockout. The TPM stores the secret value as lockoutAuth. Alternatively, a policy(lockoutPolicy) can be used to reset lockout.
NOTE 1The primary attack model for the dictionary attack begins when a system falls into the hands of athief. The thief tries to recover data on the system by guessing the password used to protect a disk’s
encryption keys. The dictionary attack logic defeats this attack by preventing the thief from making
many guesses before the TPM locks out further attempts. When/if the system is returned to its
rightful owner, that owner can enter the lockoutAuth value or satisfy lockoutPolicy, access the disk
encryption keys, and return to normal operation.

NOTE 2

Unfortunately, dictionary attack logic is not forgiving of poor typing or a short memory. If someone
types his or her password incorrectly due to clumsiness or poor memory, the dictionary attack logic
might not differentiate this from an attack, so it locks the TPM. Lockout Authorization allows
recovery from this situation.

Page 70
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The lockoutAuth value is reset to EmptyAuth and lockoutPolicy to the Empty Buffer when TPM2_Clear() is
executed.
NOTE 3

TPM2_Clear() changes the SPS rendering all previously -created user objects inaccessible. There
are, therefore, no keys for the dictionary attack logic to protect.

The lockoutAuth value can be changed (TPM2_HierarchyChangeAuth()) only when its current value isprovided. LockoutPolicy can be changed using TPM2_SetPrimaryPolicy().
Generally, dictionary attack protection is not applied to objects associated with the PPS or to NV Indexes
defined using Platform Authorization. The platform firmware is expected to select a high-entropy value
when setting the platformAuth after a TPM reset. Additionally, since Platform Authorization does notprovide access to user data protected by the TPM, disclosure of platformAuth does not expose user
secrets.
See 19.8 for full details on setting of parameters associated with dictionary attack logic and other aspectsof the dictionary attack protection.
13.8

TPM Ownership
Taking Ownership

Taking ownership of a TPM is the process of inserting authorization values for the ownerAuth,endorsementAuth, and lockoutAuth.
A TPM that has been cleared (TPM2_Clear()) has its ownerAuth, endorsementAuth, and lockoutAuth
values set to EmptyAuth and its ownerPolicy, endorsementPolicy, and lockoutPolicy values set to Empty
Buffers. The OS is expected to change these values and manage them on behalf of the platform Owner.
The platform can prevent access to the hierarchies associated with Owner Authorization andEndorsement Authorization and prevent use of the TPM’s persistent storage by the operating system anduser applications. TPM cryptographic capabilities would still be available, and these could be used as if
the TPM were a software cryptographic library.
Releasing Ownership
TPM2_Clear() clears the current Owner from the TPM. A persistent TPM control(TPMA_PERMANENT.disableClear) controls whether TPM2_Clear() is functional. If disableClear is
CLEAR, then TPM2_Clear() can be authorized using either Platform Authorization or Lockout
Authorization. If the control is SET, then TPM2_Clear() is not functional.
NOTE

TPMA_PERMANENT.disableClear can be SET or CLEAR using platformAuth/platformPolicy , giving
the platform the ability to enable execution of TPM2_Clear() when needed.

TPM2_Clear() instructs the TPM to:•flush any transient or persistent objects associated with the SPS or EPS hierarchies (PPS objects
are not affected);•release any NV Index locations that do not have their TPMA_NV_PLATFORMCREATE attribute
SET;•

set shEnable and ehEnable to TRUE;•

set ownerAuth, endorsementAuth, and lockoutAuth to an EmptyAuth;•set ownerPolicy, endorsementPolicy, and lockoutPolicy to an Empty Policy;

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 71
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture•

replace the existing SPS with a new value from the RNG; and•recompute shProof, and ehProof.

Page 72
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryPrimary Seeds
14.1

Introduction

A Primary Seed is a large, random value that is persistently stored in a TPM; it is never stored off the
TPM in any form. Primary Seeds are used in the generation of symmetric keys, asymmetric keys, otherseeds, and proof values.
A Primary Seed generates Primary Objects using the methods described in Clause 27.5. In brief, thecaller provides the parameters of an object to be created, and the TPM uses these parameters and thePrimary Seed in a key derivation function (KDF) to produce an object of the desired type. After the TPM
generates a Primary Object, it uses the parameters of that object and the Primary Seed to generate asymmetric key to encrypt the sensitive portion of the object (that is, the private data and authorizations). It
then returns the public portion and name of the object to the caller. The Primary Object can then becontext saved and loaded like any other object. It can be stored persistently in the TPM’s NV memory(TPM2_EvictControl()).
Primary Seeds generate only Primary Objects. All other objects use the random number generator of the
TPM as the source of entropy for generating secrets in the object.
14.2

Rationale

The algorithm flexibility provided by this specification makes it possible for the TPM to support manydifferent asymmetric key types. TPM 1.2 supported only the RSA algorithm with a limited number ofcommonly used parameters. The addition of ECC support significantly increases the number ofparameters because curve parameters can vary based on application.
While this flexibility is a major benefit of TPM 2.0, it creates new challenges for managing TPM
Endorsement Keys (EKs) and EK certificates. As mentioned in 9.4.4.2, an EK is an identity for the Root ofTrust for Reporting (RTR), and algorithm agility creates the possibility of having many identities for thesame RTR, with each identity based on a different set of cryptographic algorithms.
One possible approach for handling many EKs and their associated certificates would be for the TPM
manufacturer to have the TPM create EKs for many key parameters and store them on the TPM; in thisway, a key with the correct parameters would be available in most situations. The TPM vendor could thencreate one or more certificates for those keys. However, this approach would require a prohibitive amountof NV memory to store all the key pairs and associated parameters. The approach taken in thisspecification allows certification of a large number of EKs with different parameters without requiring thatany of them be stored in persistent TPM memory.
The mechanism of this specification uses a persistent, randomly generated seed value from which EKs
are derived. The derivation process lets the TPM generate a different EK for each set of key parameters.
As long as the seed value does not change, the same key parameters generate the same EKs.
The typical use of this EK generation approach is as follows: The TPM manufacturer or the platform
manufacturer has the TPM create a new Endorsement Primary Seed (EPS) and then generate key pairs
based on sets of input parameters and that EPS. The TPM retains the generated keys. Combinations of
key parameters should be chosen to ensure that likely TPM users would find a combination to suit theirneeds. The manufacturer then generates one or more certificates for the generated public keys and thenships the TPM/system with no EK pair stored on it. The system owner decides which key types areneeded, and the parameters for those types are entered into the TPM. If the parameters are the same as
those used by the manufacturer, the TPM generates the same key pair. The system owner then has an
EK with its certificate. Since an EK is not generally duplicable, the owner has a choice to make. They caneither re-create the EK whenever it is needed or tell the TPM to save the EK in persistent memory.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 73
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The seed key concept can be applied to two other TPM key hierarchies: one used by platform firmware,and one used for the owner’s Storage hierarchy. The Endorsement Keys (EK) are generated from theEndorsement Primary Seed (EPS), platform keys from the Platform Primary Seed (PPS), and Storage
Root Keys (SRK) from the Storage Primary Seed (SPS). Each seed value has a different life cycle, but
the way it seeds the associated hierarchies is approximately the same.
It is preferred that a TPM manufacturer generate a certificate for at least one EK before the device ships.
This certificate would be based on the EPS that is present in the TPM at that time. While it is possible forthe manufacturer to let the TPM populate the EPS and generate an RSA key pair, the unpredictability of
the generation time can make injecting an EPS a more attractive option. The time taken to inject an EPS
would be deterministic and one or more RSA key pairs could be generated for that EPS outside of the
TPM. This could save considerable time during manufacturing.
The external algorithm for generating a key pair from the EPS has to be the same as the algorithm usedby the TPM; otherwise, they will generate different keys. The generation times for the external and TPM
processes will be proportional so the manufacturer can use the time for external key generation time as
an indicator of the time that the TPM will take when the end user attempts to recreate the EK. If the
manufacturer does decide to inject an EPS and generate RSA keys outside of the TPM, there is an
opportunity to benefit the customer by discarding EPS values that result in long key pair generation times
for the certified values.
Another possible option is to inject the EPS and a precomputed pair of RSA primes that are compatible
with a specific template (compatible meaning that the primes are the right size and that the prime (p) and
p-1 are not evenly divisible by the public exponent). The TPM could access those primes when theassociated template is used for an EK. If this method is used, the TPM manufacturer has to make sure itis critical that the precomputed primes are only associated with a single template and that the primes are
erased from the TPM when the EPS is changed.
The primary seed approach allows multiple storage hierarchies with differing security properties, as
needed by various applications, without requiring that all of the SRKs occupy persistent TPM memory. An
SRK can be made persistent in TPM NV memory if required by the application.
This scheme is also used in support of the Platform hierarchy for implementation simplicity.
14.3

Primary Seed Properties
Introduction

A Primary Seed is required to have at least twice the number of bits as the security strength of any
symmetric or asymmetric algorithm implemented on the TPM.
EXAMPLE 1

RSA2048 is considered to have a security strength of 112 bits. If it were the strongest algorithm on
the TPM, then the required size of an associated Primary Seed would be at least 224 bits.

EXAMPLE 2

If AES256 were implemented, the Primary Seed would be 5 12 bits even if: (1) the desired security
strength is 196 bits, and (2) AES256 is used only for convenience, as is the case with Suite B.

A different authority controls each Primary Seed. In normal use, Primary Seeds are expected to havedifferent lifetimes.
After a field upgrade that changes the Primary Seed strength, or that changes the algorithm that uses thePrimary Seed, the TPM shall generate the original EKs corresponding to the EK certificates provisionedby the TPM manufacturer if the same template is provided to the TPM2_CreatePrimary() command until
such time as TPM2_ChangeEPS command changes the EPS.

Page 74
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

For a field upgrade that does not change the Primary Seed strength or the algorithm that uses thePrimary Seed and does not otherwise affect the security of Primary Objects based on the seeds,
TPM2_CreatePrimary() with the same inputs should produce the same Primary Object in the platform,
storage, and endorsement hierarchies after the field upgrade as it did before the field upgrade.
This requirement shall not be in effect for other keys derived from the EPS or for keys derived from the
SPS or PPS.
EXAMPLEA field upgrade can cause TPM2_CreatePrimary() to generate a different key for the same input
template. For example, revisions prior to revision 01.38 used KDFa, while revision 01.38 and after
use DRBG. In addition, the security strength requirement could cause a change in the seed length if
the field upgrade implements a stronger algorithm.

Endorsement Primary Seed (EPS)The EPS is used to generate EKs and is the basis of the RTR’s identity.
The TPM creates an EPS whenever it is powered on and no EPS is present. TPM2_ChangeEPS() canchange the EPS (replace it with a new EPS), but this requires authorization by Platform Authorization.
The TPM manufacturer may inject an EPS and, under controlled conditions, compute the asymmetric EKs
that the TPM would generate given specific input parameters. Only the TPM vendor can inject an EPS.
When an EPS is replaced, all objects in the Endorsement Hierarchy are invalidated, and certificatesassociated with the EKs generated from that EPS are no longer useful. This means that certificates for
new EPS-based EKs can be needed. The environment in which this process occurs may not provide
assurance that the EKs are generated from a genuine TPM. To support recertification in such anenvironment, the TPM allows cross certification of keys between the Platform hierarchy and theEndorsement hierarchy under control of the platform firmware. Cross certification allows a chain of trust to
be maintained as the seeds are changed.
When a platform enters the distribution channel, it is expected to have a certificate for at least one EK for
the TPM on that platform.
Either endorsementAuth or endorsementPolicy is required to use the EPS for creation of a Primary Object
in the Endorsement hierarchy.
Platform Primary Seed (PPS)The PPS is used to generate the hierarchy controlled by platform firmware. The hierarchies derived fromthis seed are for exclusive use by platform firmware and should not be made available to user-installable
software (such as, OS and applications).
NOTE 1The platform firmware can be changed because of actions by a person with possession of theplatform, but that is not included in the definition of user-installable software.

The TPM creates a PPS whenever it is powered on and no PPS is present. TPM2_ChangePPS() canchange the PPS (replace it with a new PPS), but this requires authorization by Platform Authorization.
A PPS may be injected but only by the TPM manufacturer.
Platform Authorization is required to use the PPS to create a Primary Object in the Platform hierarchy.
The authorization for use of objects in the PPS hierarchy should use a policy containing a reference toplatformAuth and not be based on a key-specific authorization value.
NOTE 2The TPM does not enforce this imperative.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 75
December 24, 2020

Trusted Platform Module Library
NOTE 3

Part 1: Architecture

A simple way to achieve this control is to create a policy that references platformAuth in a
TPM2_PolicySecret(). If the only component of the policy is TPM 2_PolicySecret() referencing
TPM_RH_PLATFORM, the policy can be the same for all objects in the Platform hierarchy and for all
platforms that implement the chosen policy hash.

Storage Primary Seed (SPS)The SPS is used to generate hierarchies controlled by the platform owner. This seed generates the keys
that serve as Storage Root Keys for normal OS and application use.
The TPM creates the SPS whenever it is powered on and no SPS is present. TPM2_Clear() can be used
to change the SPS if the TPM owner wants to ensure that no previously generated keys in the Storage
hierarchy can be used in the future.
Changing the SPS invalidates all objects in the Storage Hierarchy and they cannot be recreated.
Changing the SPS also invalidates all objects in the Endorsement Hierarchy and only the Primary Objects
in the Endorsement Hierarchy can be recreated.
The Null Seed
The Null Seed is set to a random value on every TPM Reset. The Null Seed can be used to generate
hierarchies (primary objects and children of primary keys) that are only usable until the next TPM reset.
Objects in the null-hierarchy cannot be made into persistent objects. However, in other respects objects inthis hierarchy behave like objects in the other hierarchy.
14.4

Hierarchy Proofs

The TPM uses a proof value to prove that it created or checked an externally provided value. A proof
value is associated with a hierarchy and is statistically unique. The proof values are used in tickets. The
tickets use the hierarchy-specific proof values. A ticket cannot be used when its associated hierarchy isdisabled.
EXAMPLE 1

The TPM can validate asymmetrically signed data. After doing so, it produces a ticket that is an
HMAC over the signed data, with the HMAC key being a proof value. This proves to the TPM th at it
has already checked the asymmetric signature, so it does not have to do so again. Subsequently,
when the TPM needs to check that the data was properly signed, it can use symmetric cryptography(a hash) rather than asymmetric cryptography to validate the signature.

EXAMPLE 2

When the TPM performs TPM2_ContextSave() on an object in the Storage hierarchy, it can include
the Storage hierarchy proof (shProof) in the object’s integrity value. When the SPS is changed,
shProof will change so that the saved contexts cannot be reloaded.

A Platform hierarchy proof (phProof), used for objects associated with the Platform hierarchy. phProofchanges when the PPS changes. An shProof, used for the Storage and Endorsement hierarchies,changes when the SPS changes.
NOTE

It is possible to create objects in the Endorsement Hierarchy that are not Primary Objects. Those
Ordinary Objects are considered to belong to a specific TPM Owner. A change of the SPS indicatesa change of Owner for the TPM. Inclusion of ehProof in the protection of Ordinary Objects in theEndorsement Hierarchy ensures that those Objects will be deleted when the Owner changes,
because ehProof also changes when the Owner changes.

A proof is a value that may be kept in permanent storage on the TPM or it may be regenerated from the
PPS or SPS on each boot or as needed. A proof value is never stored off the TPM in any form. Hierarchy
proof values are only used as an HMAC key if the result of the computation is stored off the TPM.
Examples are saved contexts and tickets. A hierarchy proof value may be used in other computations aslong as the result of the computation does not leave the TPM.
Page 76
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The TPM should produce proof values that are the larger of either•

the size of the largest digest produced by any hash algorithm implemented on the TPM, or•twice the size of the largest symmetric key supported by the TPM.

EXAMPLE 3

If the TPM implements SHA384 and AES256, the proof value will have a size of 512 bits.

NOTE

According to SP800-57, the security strength of SHA256 in an HMAC function equals 256 bits. Since
security strength is not improved when the key size is larger than the digest size, therecommendation for proof size provides the appropriate strength when the TPM is implementingbalanced algorithm sets. A TPM using SHA256, ECC256, and AES128 is balanced, and the proof
value is 256 bits.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 77
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM Handles
15.1

Introduction

TPM resources are referenced by handles that uniquely identify a resource that occupies TPM memory —either RAM or NV. A handle is a 32-bit value. Its most significant octet identifies the type of referenced
resource. At any given instant, its low-order 24 bits identify a unique resource of that type. The actual
resource identified by the low-order 24 bits may change with time.
A specific handle value can refer to only one TPM-resident resource at a time.
15.2

PCR Handles (MSO=00 16 )To reduce confusion, PCR are assigned handles that have the same values as in previous versions of thespecification. A PCR handle is an Index into an array of PCR. A PCR’s Index and handle value are the
same.
15.3

NV Index Handles (MSO=01 16 )An NV Index is associated with a persistent TPM resource created by TPM2_NV_DefineSpace().
15.4

Session Handles (MSO=02 16 and 03 16 )The TPM assigns session handles when an authorization session is started (TPM2_StartAuthSession()).
An HMAC session is assigned a handle with an MSO of 0216 and a policy session is assigned a handle
with an MSO of 0316. Each authorization session handle is associated with a unique context that can exist
in only one place at a time: either on the TPM in a Shielded Location, or in a saved context as a Protected
Object. The handle remains associated with the session as long as the session exists and does notchange when the session is context-saved and reloaded.
The low order 3 octets of each session handle are unique. They are assigned interchangeably to HMAC
or policy sessions but to only one at a time.
EXAMPLE 1

If a policy session has a value of 03 00 00 01 16 , then an HMAC session with a value of 02 00 00 01 16
will not be assigned at the same time.

NOTE 1The policy and session handles are assigned from a common pool of handle values.

When TPM2_GetCapability() is used to obtain a list of sessions that are currently loaded on the TPM, thecaller would use a handle with an MSO of 0216. While this would normally be an HMAC handle reference,
the TPM will respond with a list that includes both HMAC and policy sessions. The handles will be
returned in ascending order of the low-order three octets.
EXAMPLE 2

A list of loaded handles returned by the TPM in response to a TPM2_GetCapability( capability =TPM_CAP_HANDLES, property = 02 00 00 00 16 ), the TPM might return the list: 02 00 00 02 16 ,03 00 00 04 16 , and 02 00 00 05 16

When TPM2_GetCapability() is used to obtain a list of sessions that are active but not on the TPM, thecaller would use a handle with an MSO of 0316 which normally would reference a policy session. The
TPM will respond with a list of session handles that are in use, but not on the TPM. Since the TPM does
not keep a record of whether the saved session context was an HMAC or policy session, all of thehandles in the list will have an MSO of 0216.
The TPM is required to maintain a list of all, currently assigned session handles as well as the correct"version number" for any saved session contexts.
Page 78
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
NOTE 2Trusted Platform Module Librarythe "version number" is how the TPM prevents replay of an authorization.

When an authorization session is no longer needed, TPM2_FlushContext() can be used to delete allcontext associated with the session from TPM memory (see 30.6). The session handle for this command
can use an upper octet of either 0216 or 0316.
NOTE 3

Flushing a session context deletes any data in the TPM relating to the context and frees the handle
associated with that context and invalidates the version number of any saved context.

NOTE 4An alternative method of flushing a session context exists that is not available for other entities. On
the last use of the session, the caller can indicate (in one of the session attributes) that the session
is no longer needed. If the command completes successfully, the TPM will complete the responsecomputations for the session and delete the session context from TPM memory (see 18.6.4).

All session contexts in TPM memory are flushed on any TPM2_Startup(). The saved session contexts
remain valid until a TPM Reset.
15.5

Permanent Resource Handles (MSO=40 16 )Fixed resource handles refer to Shielded Locations that are always associated with the same handle.
These resources have handles with an MSO of 4016. Examples of these resources are Owner, Platform,and Endorsement hierarchy controls and the Lockout authorization value.
Another type of permanent resource handle is the vendor-specific authorization value. These optional
resources can be populated with authorization values that are known only by the TPM manufacturer orsome other privileged entity. The update of these authorization values is TPM-manufacturer-dependent.
If present, a vendor-specific authorization value can be used as a bind value within an authorization
session or to authorize a policy using the TPM2_PolicySecret command. In the former case, an entity thatknows the authorization value could create an auditable authorization session that only that entity could
execute. In the latter case, the entity could create and/or use TPM resources with an authorization policythat only that entity could execute.
Since vendor-specific authorization values might be usable by an entity who knows them to identify the
TPM, the use of these authorization values is under the control of the privacy administrator. Theseauthorization values are only usable when the Endorsement Hierarchy is enabled as described in clause
13.5.
NOTE

15.6

A use case for the vendor-specific authorization values is to recover in the field from a flaw in the
TPM firmware. For example, TPM vendors may provide a mechanism that updates one or more ofthese authorization values based on the measurement of the TPM firmware. This update mechanism
could be used to give the manufacturer confidence that a valid, uncompromised version of the TPM
firmware is running. In this scenario, if the manufactur er wished to provide a certificate for an
endorsement key generated in the field after a field upgrade to a trusted firmware version occurred,
the manufacturer could use an auditable authorization session using the vendor -specificauthorization value to verify the properties of the endorsement key and then create a certificate forthat new endorsement key.

Transient Object Handles (MSO=80 16 )The TPM assigns Object handles when an Object is loaded or when the Object’s persistence is changed(TPM2_EvictControl()). Transient Objects in TPM RAM have handles with an MSO of 8016; they may havea different value for the three LSOs each time the Object is used. This is because the Object’s context
may have been swapped out and the TPM assigned a new handle when the object was swapped back in.
The TRM ensures that the handle references the correct object.
All Transient Objects are flushed from TPM memory on any TPM2_Startup(). A loaded Transient Object
context can be flushed from TPM memory using TPM2_FlushContext() and indicating the handle of theloaded context to be flushed.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 79
December 24, 2020

Trusted Platform Module Library
15.7

Part 1: Architecture

Persistent Object Handles (MSO=81 16 )TPM2_EvictControl() can make a Transient Object into a Persistent Object. A Persistent Object, placed in
the TPM’s NV memory, is not cleared by a TPM2_Startup().
Making an Object persistent requires either Platform Authorization or Owner Authorization.
When the TPM changes a Transient Object to a Persistent Object, the caller indicates the handle to be
assigned to the Persistent Object. The MSO of the handle is required to be 8116. The next most significant
bit is required to be CLEAR if the authorization is provided using Owner Authorization and SET if theauthorization is provided using Platform Authorization. If the handle is not already in use, and space isavailable, a persistent copy of the Object is created and assigned the handle provided by the caller. This
handle always references the same Persistent Object as long as it remains persistent. The handle
assigned to a Persistent Object can be assigned to a new Persistent Object if the first Object is deleted
from persistent storage.

Page 80
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Names
The Name of an entity is its unique identifier. The handle associated with an object may change due tocontext management (TPM2_ContextSave() / TPM2_ContextLoad()), but the Name of an object remains
constant. The Name associated with an NV Index will change based on changes to the attributes of theIndex.
EXAMPLEWhen an NV Index is initially defined, it will have a Name for an Index with TPMA_NV_WRITTEN
CLEAR. After the Index is written, the Name will change to reflect that TPMA_NV_WRITTEN is SET
for the Index.

When an NV Index becomes locked (TPMA_NV_WRITELOCKED or TPMA_NV_READLOCKED is SET),
the Name of the NV Index changes. This has two implications:
The caller should use its copy of the NV public area and calculate the Name before using it in an HMAC
authorization calculation. Otherwise, an invalid authorization can trigger the dictionary attack protection
depending on TPMA_NV_NO_DA.
The TPM must check access control before checking authorization. For example, it should reject a read toa read locked NV Index before doing an authorization check that might trigger the dictionary attack
protection.
The method of computing the Name for an entity varies according to the entity type that is the MSO of thehandle. Table 3 shows the method and the handle’s MSO for different entity types.
When the computation of a Name uses a hash algorithm, the algorithm identifier is included in the Name
structure. If the Name is a handle, the Name is only the handle value.
Table 3 — Equations for Computing Entity Names
MSO ofHandleEntity Type

0016

PCR

0216

HMAC Session

0316

Policy Session

4016

Permanent Values

Equation for Computing the Name

Name ≔ handle
No hash is performed on the handle to produce the name and the name is only
the size of the handle.

Name ≔ nameAlg || HnameAlg (handle→nvPublicArea)
where
0116

NV Index

nameAlg
HnameAlg
nvPublicArea

8016

Transient Objects(1)handleName ≔ nameAlg || HnameAlg (handle→publicArea)
where

nameAlg
HnameAlg
8116

algorithm used to compute Namehash using the nameAlg parameter in the NV Index
location associated with handle
contents of the TPMS_NV_PUBLIC associated with

Persistent Objects

publicArea

algorithm used to compute Namehash using the nameAlg parameter in the object
associated with handle
contents of the TPMT_PUBLIC associated with handle

NOTE 1) The Name of a sequence object is an Empty Buffer (see 32.4.5).

When an object is created, a "template" for the public area is used to define the properties for the new
object. That template has the structure of an object's public area. The Name of a public area template iscomputed in the same way as the Name of a Transient Object.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 81
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

PCR Operations
17.1

Initializing PCR

All platform configuration registers (PCR) are reset to their default initial condition on TPM Reset and
TPM Restart. Some PCR may be designated as being preserved by TPM Resume. Those that arepreserved are restored to the state that they had at the last TPM2_Shutdown(STATE) operation. When
TPM2_Startup() completes successfully, PCR that are not designated as being preserved by TPM
Resume will be in their default initial condition.
If allowed by its attributes, a PCR can also be reset by TPM2_PCR_Reset() or by a Dynamic Root ofTrust (D-RTM) sequence (see 34.2). PCR attributes are defined in a platform-specific specification. They
determine the reset value of a PCR as well as the localities required to perform the reset.
The default initial condition for any PCR, other than PCR[0], is either all bits CLEAR or all bits SET. For
PCR[0], the default initial condition may all bits CLEAR, all bits SET, the locality at which TPM2_Startup()
was received, or an indicator that the first measurement came from an H-CRTM. Other platform types
may use other means of identifying the locality of the access.
A platform-specific specification can choose from the options list above.
EXAMPLE 1

A platform-specific specification can designate that the default initial condition for PCR[0 -16] is all
zeros, and for PCR[17-20], it is all ones.

EXAMPLE 2

A platform-specific specification can designate that the default initial condition for PCR[0] is the
locality indicator and that PCR[1-16] have an initial condition of all zeros.

NOTE

The locality indicator is an integer value between 0 and the maximum locality implemented on a
TPM. Currently, the maximum hardware locality is 4. In a TPMA_LOCALITY, a locality of four would
be represented by the octet 0001 0000 2 . When encoded for a PCR initial value, locality 4 would be
represented by the octet 0000 0100 2 .

EXAMPLE 3

A virtual TPM may use a unique identifier for each of the software entities that might access it. If
specific software is associated with a specific PCR, then the reset value of that PCR could be theunique identifier of the software that is allowed to change it.

TPM2_PCR_Reset() requires that the proper authorization be provided for the operation (see 17.7).
17.2

Extend of a PCR

Other than reset, described above, the only way to change a PCR value is to Extend it. The Extend
operation on a PCR is defined as

PCRnew ≔ Halg (PCRold || digest)(13)

After each Extend, the PCR value is unique for the specific order and combination of digest values thatwere Extended.
Except for D-RTM, authorization is required to extend a PCR (see 17.7).
17.3

Using Extend with PCR Banks

TPM2_PCR_Extend() has a handle to indicate the PCR to Extend and the data to be Extended. Extended
data is a structure that contains one or more digests along with the algorithm identifier for the digest(s).
Each digest is Extended to the PCR bank that has the same algorithm. If no digest data is provided forone of the PCR banks, no change is made to the PCR in that bank.
Page 82
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The TPM should perform the following operation for each algorithm in which pcrNum is defined:

PCR.digest[pcrNum][alg]new ≔ Halg (PCR.digest[pcrNum][alg]old || digest)

(14)

where

Halg

hash function using the algorithm associated with the PCR instance

PCR.digest

digest value in a PCR

pcrNumPCR numeric selectoralg

PCR algorithmic selector

digestdigest part of the list entry that has the same algorithm identifier as the
PCR bank

EXAMPLE

17.4

If a TPM supports three PCR banks (such as, SHA -1, SHA256, and SHA512), then an Extend to
PCR[2] with a SHA-1 digest and SHA256 digest would be Extended to PCR[2] in the SHA-1 bank,and the SHA256 digest would be Extended to PCR[2] in the SHA256 bank. There would be nochange to any PCR in the SHA512 bank.

Recording Events

An alternative way to record log entries is to input the full log entry to the TPM rather than performing thedigests outside the TPM. This performs a hash on the log entry for each of the hash algorithms supportedby the TPM. Events no larger than 1024 octets can use TPM2_PCR_Event(). Events exceeding 1024
octets can use the sequence commands: TPM2_HashSequenceStart(), TPM2_SequenceUpdate(), andTPM2_EventSequenceComplete()).
TPM2_PCR_Event() and TPM2_EventSequenceComplete() return a list of tagged digests. The digests
are the digests of the event data using each implemented hash algorithm.
EXAMPLEFor a TPM implementing two algorithms (such as, SHA256 and SM3), the event commands return alist of two tagged digests.

TPM2_EventSequenceComplete() requires that proper authorization be provided (see 17.7).
Recording
of
an
event
can
also
occur
as
the
resultofa_TPM_Hash_Start/_TPM_Hash_Data/_TPM_Hash_End sequence (an H-CRTM Event Sequence). The
indications for the H-CRTM sequence come from the TPM interface and not through the command buffer.
On receipt of _TPM_Hash_Start, the TPM will created an Event Sequence context. If no object context
space is available when the TPM receives _TPM_Hash_Start, the TPM will flush a context (vendor's
choice) in order to create the Event Sequence context. _TPM_Hash_Data is used to update the H-CRTM
Event Sequence context and _TPM_Hash_End completes the sequence. The digest or digests computed
during the H-CRTM Event Sequence will be extended into the PCR designated by the relevant platformspecific specification. A platform-specific specification may allow an H-CRTM Event Sequence before orafter TPM2_Startup(). An H-CRTM Event prior to TPM2_Startup() affects PCR[0]. After TPM2_Startup(),an H-CRTM Event affects PCR[17].
17.5

Selecting Multiple PCR

TPM2_PCR_Event() implicitly selects all PCR with the same Index. Some commands allow the selectionof multiple PCR in different banks. Examples are TPM2_PCR_Read(), TPM2_Quote(), andTPM2_PolicyPCR() that allow the caller to make arbitrary selections of PCR in multiple banks.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 83
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

When a command allows multiple PCR to be selected, a list of selectors is used. Each entry in the list
consists of an algorithm ID followed by a bit array. Each bit in the bit array corresponds to one PCR. If a
bit is SET, then the indicated PCR in the bank corresponding to the algorithm ID is selected.
The bit correspondence to PCR is that the bit corresponding to PCR[n] is the (n mod 8) bit in then/8 octet of the array.
EXAMPLEAn array to select PCR[0] and PCR[13] in a TPM with 16 PCR would be 01 20 16 . The bit for PCR[0]is the 0 mod 8 = 0 th bit in the 0/8 = 0 th octet (the octet with the 01 16 value) and the bit for PCR[13]is the 13 mod 8 = 5 th bit in the 13/8 = 1 st octet (the octet with the 20 16 value).

The list of selectors is processed in order. The selected PCR are concatenated, with the lowest numbered
PCR in the first selector being the first in the list and the highest numbered PCR in the last selector being
the last.
TPM2_PCR_Read() returns a list of PCR values that correspond to the PCR selected in the selector list.
TPM2_Quote() and TPM2_PolicyPCR() digest the concatenation of PCR.
It is not an error for the PCR selection to indicate a PCR that is not implemented in a bank. No value isincluded in the concatenation of PCR for an unimplemented PCR. It is an error if the algorithm ID selects
a hash algorithm that is not implemented.
17.6

Reporting on PCR
Reading PCR

TPM2_PCR_Read() reads the current values of a selection of PCR. For this command, the caller
indicates a list of PCR to be read using a PCR selection structure. This structure is an array of lists. Eacharray entry has a hash identifier and a bit field. The hash identifier indicates the bank of PCR, and the bit
field indicates the PCR being selected in the bank.
In the response, the TPM provides a PCR selection structure and a list of PCR values. The PCR selection
structure indicates the PCR that are present in the return structure. The size of the requested return data
structure may not fit in the available TPM output buffer. In that case, the list of PCR values is truncated,
and the response PCR selection structure indicates the PCR that were returned. If the returned structure
does not contain all of the PCR, the caller can modify the selection structure and make another readrequest to get additional PCR values.
Since the PCR can change between the calls to collect the full set of PCR of interest, the TPM returns acounter that increments on most invocations of TPM2_PCR_Extend(), TPM2_PCR_Event(),
TPM2_EventSequenceComplete(), or TPM2_PCR_Reset() (see 17.9 for exemptions). If this countervalue changes between calls, the sequence can be repeated until the desired PCR are all returned withno change to the counter value.
Attesting to PCR
In some cases, it is necessary for selected PCR to be in a specific state. When indicating that state, it is
not desirable to have to list the contents of each PCR. Instead, a digest of a concatenation of PCR (acomposite PCR digest) will indicate the current contents of all of the PCR of interest.
The PCR to be included in the composite digest are selected by the same type of structure used for
TPM2_PCR_Read(). The selection structure is first filtered so that unimplemented PCR are not in theselection structure. Then, a composite digest of all of the selected PCR is created. Finally, the filteredselection structure and the composite digest are hashed to create the final digest value. That digest canbe compared to a required digest (TPM2_PolicyPCR()) or returned in an attestation (TPM2_Quote()).
Page 84
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

To validate an attestation quote, a remote caller will typically use the PCR to recalculate the digest value.
The TPM 1.2 quote command returns the PCR values along with the digest. In TPM 2.0, because of hashagility, the PCR set could have exceeded the response buffer size. Therefore, TPM2_Quote() returns only
the digest, and the PCR values must be retrieved separately.
This can lead to a race condition. The PCR values can change between the time of the quote and thetime they are read. There are several solutions. The PCR can be read before and after the quote toensure that they did not change. Alternatively, the quote digest can be validated locally against the PCR
before returning results to a remote caller, and the quote can be rerun until the validation succeeds.
17.7

PCR Authorizations

TPM2_PCR_Reset(), TPM2_PCR_Extend(), TPM2_PCR_Event(), and TPM2_EventSequenceComplete()require authorization for the PCR being modified. The type of the authorization can differ based on the
PCR being modified. A PCR can be defined as having a fixed, EmptyAuth; a variable authValue; or avariable authPolicy.
The authorization (authValue or authPolicy) for a PCR may apply to a set of PCR. That is, several PCR
may be designated as using the same authorization value so that changing the authorization value(authValue or authPolicy) of any PCR in the set will change the value for all PCR in the set. A set of PCR
that are authorized by an authValue are in an authorization set. A set of PCR that are authorized by an
authPolicy are in a policy set.
The type of authorization associated with each PCR is fixed by a platform-specific specification. For eachset, the platform-specific specification defines the PCRs that are in the set. A PCR should not be in morethan one policy set or one authorization set.
A PCR may be in both a policy set and an authorization set. If it is in both, the only way to use theauthValue of the authorization set is with a policy that contains TPM2_PolicyAuthValue() or
TPM2_PolicyPassword().
An indication of the PCR in an authorization set can be read using TPM2_GetCapability(capability ==TPM_CAP_PCR_PROPERTIES, property == TPM_PT_PCR_AUTH) and the PCR in a policy set can beread using TPM2_GetCapability(capability == TPM_CAP_PCR_PROPERTIES, property ==TPM_PT_PCR_POLICY).
NOTE 1

The reference implementation only provides support for one set of each type. If additional sets areneeded, the property types for TPM_CAP_PCR_PROPERTIES can be extended.

NOTE 2

If a PCR is in multiple policy or authorization sets, the TPM will use the policy or authorization of thelowest numbered set. That is, the set with the lowest TPM_PT_PCR_POLICY or
TPM_PT_PCR_AUTH property.

To authorize a PCR, the correct authorization type is required, which will depend on the authorization setof a PCR. In all cases, The EmptyAuth value can be provided in either an HMAC session using a zerolength authValue in the HMAC calculation or as a zero length password.
PCR Not in a Set
If the PCR is in no set, then the authorization can only be with an EmptyAuth value.
Authorization Set
If the PCR is in an authorization set, then the authValue of the PCR is provided either with an HMAC
session or in a password. When a PCR has a fixed, EmptyAuth value, an authorization session is stillrequired.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 85
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

When a PCR has a variable authValue, that authValue is reset to an EmptyAuth on each
STARTUP(CLEAR). It is preserved across STARTUP(STATE). A variable authValue can be changed
using TPM2_PCR_SetAuthValue() by an entity with knowledge of the authValue.
Policy Set
An authPolicy for a policy set has both a hash algorithm and a digest value.
If the hash algorithm for the authPolicy is TPM_ALG_NULL, the policy has not been set. This uninitialized
policy set will use an EmptyAuth.
If the digest algorithm for the policy is not TPM_ALG_NULL, then the policy set is an initialized policy set.
If the PCR is in an initialized policy set, then the authorization can only be given with a policy session.
The hash algorithm for all policy sets is set to TPM_ALG_NULL by TPM2_ChangePPS(). The algorithm
and authPolicy associated with a PCR can only be changed using TPM2_SetAuthPolicy() by an entitywith knowledge of the Platform Authorization.
If an HMAC session or a password is used for a PCR in an initialized policy set, then the TPM will return
an error (TPM_RC_AUTH_TYPE). If a policy session is used for a PCR that is not in an initialized policy
set, then the TPM will return an error (TPM_RC_POLICY_FAIL). Neither of these two failures would
cause an update of the dictionary attack protection.
Order of Checking
When determining the correct type of authorization for a PCR, the TPM will use the authorization type. If
the authorization is a password or HMAC session, The TPM will check to see if the PCR is in an
authorization set.
17.8

PCR Allocation

A TPM may support reallocation of the PCR by the platform. To change the allocation of PCR, theplatform would use TPM2_PCR_Allocate(). The allocation structure has a PCR selection for each
implemented hash algorithm. To allocate a PCR in a bank, the corresponding bit would be SET in theselection for that bank.
The TPM2_PCR_Allocate() changes to PCR allocation take effect upon the next _TPM_Init and persist
until the next TPM2_PCR_Allocate().
NOTE 1

Because of RAM limitations, an implementation may not allow arbitrary allocation of PCR within abank. This does not create a deployment issue as the platform is expected to be able to manage the
TPMs that would be attached to that platform.

An allocation cannot be made for PCR if the attributes for the PCR are not defined by the platformspecific specification of that TPM.
NOTE 2

The attributes for a PCR include the Startup() initialization value, the locality for reset, and the
locality for extend.

There is a requirement that a bank exists for each hash algorithm but there is no requirement that thebank have any PCR (that is, all selection PCR selection bits for the bank can be CLEAR).
It is a valid implementation for the TPM to ship with a specific PCR allocation that is not changeable. If the
TPM does not allow the changing of the allocation, it would not implement TPM2_PCR_Allocate().

Page 86
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
17.9

Trusted Platform Module Library

PCR Change Tracking

To support the use of PCR in policy the TPM maintains a pcrUpdateCounter. In general, this counter isincremented each time a PCR is modified (either extended or reset). This counter is used when a policy
requires that PCR have a specific value (see 19.7.7.6).
A platform-specific specification may designate that updates of selected PCR will not cause a change to
pcrUpdateCounter.
A bitmap of the PCR that can be updated without changing pcrUpdateCounter can be read with
TPM2_GetCapability(capability == TMP_CAP_PCR_PROPERTY, property == TPM_PT_PCR_NO_INCREMENT).
17.10 Other Uses for PCR
The PCR-related commands defined in this library cover common use cases: for example, logging ofcomponents during boot or a runtime-switch in the TCB. Platform-specific specifications define PCR
attributes that control this behavior and describe how PCR should be used by external software.
However, PCR are designed for more generalized representation of platform state, and platform-specificspecifications may define additional PCR behaviors that capture this. Generally, a platform specification
may define a PCR to represent any value that is authoritatively known by the TPM or has been securely
communicated to the TPM. For instance, a TPM for a “trusted lock” might define a PCR that has value ofzero to indicate that a door is closed, and one to indicate that a door is open or a virtual-TPM specification
might define a PCR that has a value that represents some characteristic of the virtual machine that is
issuing the TPM command. This specification demands no particular behavior or value-semantics forsuch PCR.
NOTE

A PCR can "represent" a value either by having the PCR set to that value or by having the PCR
extended with the value. In the case of the "trusted lock," it is more likely that the PCR would
contain either a zero or one to represent the state of the lock than that each change to the lock be
extended to a PCR.

This does not mean that the platform-specific working groups are allowed to define new commands tooperate on PCR.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 87
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM Command/Response Structure
18.1

Introduction

A command is a TPM Protected Capability that indicates an operation to be performed by the TPM. It
contains from one to five components, in the following order:
1) a command header that indicates the overall size of the command, the command code, and a tag
indicating whether the Authorization Area is present;2) a command-dependent number (zero to three) of handles identifying the Shielded Locations with/on
which the command (Protected Capability) operates;
3) a 32-bit value indicating the size of the Authorization Area;
4) an Authorization Area containing one to three session structures; andNOTE

Components 3 and 4 always occur together. The authorization size parameter is not present if there
are no sessions in the Authorization Area.

5) a command-dependent parameter area containing qualifying information for the command.
A response contains
1) a response header that indicates the overall size of the response, the response code, and a tag
indicating whether the Authorization Area is present;2) a command-dependent number (zero or one) of handles identifying the Shielded Locations with/on
which the command (Protected Capability) operates;
3) a 32-bit value indicating the size of the parameter area;4) a command-dependent parameter area containing the values produced by the TPM; and5) an Authorization Area containing one to three session structures.
NOTE

Components 3 and 5 always occur together. That is, if the Authorization Area is empty, the 32 -bit
value for the parameter size will not be present.

As with the command, the formats for the remaining areas of the response are dependent on the value ofthe associated command code. The session and parameter area order are reversed in a response.
The ordering of authorization structures and command-dependent parameters is intended to minimize
TPM complexity. In a command, the authorization structures are first in order that the TPM can generate
its authorization digests from the command-dependent parameters as they arrive. In a response,
command-dependent parameters are first in order that the TPM can use the output buffer to assemble thecommand-dependent parameters prior to generating its authorization digests.
NOTE:

In traditional implementations, all of the octets of a command are available at the same time soskipping around in the data structure was not an issue. In some anticipated implementa tions, thiswill not be the case and the processing of a command or response will need to be more linear.

For tables in this specification, the separators indicating the demarcations between the header, handle, authorization,and parameter components are shown in Table 4.

Page 88
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library
Table 4 — Separators

Separator

Meaning
This type of separator is followed by one or more handles.
In a command, this type of separator is followed by a 32-bit
value indicating the number of octets in the Authorization Area.
In a response, it is followed by a 32-bit value indicating thenumber of parameter octets (present only if tag forcommand/response is TPM_ST_SESSIONS).
This type of separator is followed by one or more session
structures (present only if tag for command/response is
TPM_ST_SESSIONS).

This type of separator is followed by one or more parameters

Figure 10 and Figure 11 show the basic layout of a TPM command and response (see 18.9 for a detailed
example command and 18.10 for a detailed example response).
headerheader{ handles }Number of handles is command-dependentand can be zero{ handles }Number of handles is command-dependentand can be zero

{ authorizationSize }{ parameterSize }{ Authorization Area }One or more sessions{ parameters }Contents are commandCode-dependent{ parameters }Contents are commandCode-dependent{ Authorization Area}
One or more sessions

Figure 10 — Command Structure

Figure 11 — Response Structure

NOTE

18.2

Not all sessions in the Authorization Area are required to be used for authorization. Sessions canalso be used for audit or parameter encryption.

Command/Response Header Fields

A command or response header always contains three values, displayed in Figure 12.
tagcommandSize or responseSizecommandCode or responseCode

Figure 12 — Command/Response Header Structure

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 89
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecturetag
A tag is present in all commands sent to the TPM and in responses received from the TPM. The tag
indicates whether a command is formatted according to TPM 1.2 or this 2.0 specification. If the latter, thetag indicates if any session data is present.
Table 5 lists the tag values used for commands and response defined in this specification.
NOTE

The tags for commands defined in this specification indicate only whether the command uses one ormore sessions, and do not indicate the number of sessions present in the Authorization Area. Eachsession structure that uses a variable session handle follows the s ame format, which can be parsed
to find the start of the next session.

Table 5 — Tag Values
Value

Description

TPM_ST_NO_SESSIONSThis value indicates that the command or response is formatted according
to this specification and that the Authorization Area is empty. It is used in a
response if the command used this tag or if the command did not complete
successfully.

TPM_ST_SESSIONSThis value indicates that the command or response is formatted according
to this specification and that the Authorization Area contains one or moreauthorizations. It indicates that the authorizationSize value is present; in a
response, it indicates that the parameterSize value is present.

commandSize/responseSize
The commandSize/responseSize value indicates the total number of octets of this command/response,
starting with the first octet of tag.
commandCode
The commandCode appears only in the command to the TPM. It indicates the operation that the TPM
should perform and the formats of the handle and parameter areas for the command and response. The
commandCode parameter is included in the command parameter hash (cpHash) and the response
parameter hash (rpHash).
responseCode
The responseCode appears only in the response from the TPM. A responseCode of
TPM_RC_SUCCESS (zero) indicates that the TPM has successfully completed the command and,depending on the command format, that the handle, parameter, and authorization components arepresent.
A non-zero responseCode indicates an error or fault. In this case, tag will be TPM_ST_NO_SESSIONS,
and responseSize is 10, indicating that no octets follow the responseCode. No handle, parameter, or
session response components are present.
18.3

Handles

Handles are TPM-assigned values that let the caller indicate the TPM-resident structure that a commandis to manipulate. That is, the handle identifies the Shielded Location with/on which a Protected Capability
is to operate. Some TPM commands (such as, TPM2_Startup()) require no handles.

Page 90
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The number of handles in the command and in the response is implied by the commandCode. It also
indicates the command handles that have an associated authorization session. Handles that requireauthorization in an associated authorization session are listed ahead of handles that do not have anassociated authorization session.
EXAMPLE

TPM2_ObjectChangeAuth() has two handles, one (objectHandle) that uses an authorization session,and one (parentHandle) that does not. The standard command syntax requires that objectHandle
occur first.

A response can have handles only if the responseCode is TPM_RC_SUCCESS.
The architectural limit for the number of handles in the handle area is seven. This limit is determined by
the error-reporting scheme.
NOTE

18.4

No currently defined command uses more than three handles.

Parameters

The commandCode indicates the structure of the optional handle and parameter areas. The contents ofthese parameter areas differ for commands and responses. Some TPM commands (such as,
TPM2_Clear()) require no parameters.
All parameter values and the commandCode are included in the cpHash or rpHash. authorizationSize is
not included in the cpHash, and parameterSize is not included in the rpHash.
NOTE 1

If a parameter is encrypted, it is included in the cpHash/rpHash after encryption. Because audit alsouses cpHash and rpHash, audit of an encrypted session, although valid, is unlikely to be useful at
the application level.

A response can have parameters only if the responseCode is TPM_RC_SUCCESS.
The architectural limit for the number of parameters in the handle area is 15. This limit is determined by
the error-reporting scheme.
NOTE 2This is the limit of parameters in the parameter list, not the number of values that can be in theparameter area. If a command needs more than 15 para meters, a new structure can be defined that
encapsulates two or more of those parameters into a single structure, which can then be
unmarshaled as a unit. The only loss is that error reporting will not provide as much detail when acompound parameter has an error.

As described in clause 21, for a command or response parameter to be encrypted, it must be the firstparameter and it must be a TPM2B type.
NOTE 3In order to encrypt more than one parameter, they have to be encapsulated in a TPM2B, making
them a single parameter.

EXAMPLE

18.5

The TPM2B_SENSITIVE_CREATE is the first parameter to TPM2_CreatePrimary(). The data member,
TPMS_SENSITIVE_CREATE, has two members, a TPM2B_AUTH and a TPM2B_SENSITIVE_DATA.
The encapsulation of them in the TPM2B_SENSITIVE_CREATE permits both to be encrypted.

authorizationSize/parameterSize

These values are only present if the tag of the command/response is TPM_ST_SESSIONS.
In a command, the authorizationSize indicates the number of octets in all of the authorization structures in
the Authorization Area of the command. authorizationSize does not include the four octets of theauthorizationSize value. The minimum value for authorizationSize is 9.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 91
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

NOTE 1

The maximum value depends on the size of the largest digest produced by any hash implemented on
the TPM.

NOTE 2The driver and the TPM use the authorizationSize field to determine the number of authorizations .
After authorizationSize bytes have been processed, there are no more authorizations.

In a response, parameterSize indicates the number of octets in the parameter area of the response anddoes not include the four octets of the parameterSize value. parameterSize can have a value of zero.
authorizationSize is not included in cpHash, and parameterSize is not included in the rpHash.
18.6

Authorization Area
Introduction

The Authorization Area is present in a command only if tag for the command is TPM_ST_SESSIONS. If
present, the Authorization Area will contain:•

zero, one, or two authorizations (session or password);•

an optional session used for decrypting data sent to the TPM;•

an optional session used for encrypting data sent by the TPM; or•an optional session used for auditing.

If tag is TPM_ST_SESSIONS, then the Authorization Area will have at least one but no more than threeauthorization/session blocks. If tag is TPM_ST_NO_SESSIONS, then there is no Authorization Area.
The number of authorization sessions that a command will have is indicated in the command schematic in
TPM 2.0 Part 3. If a handle in the handle area has the "@" decoration, then an authorization session isrequired be present (an authorization session being either a password, a policy session, or an HMAC
session).
The authorization sessions occur in the order of the associated entity handles. That is, the first handle
with an "@" decoration will be associated with the first session in the Authorization Area.
Other sessions can be added to the Authorization Area. Those sessions can be designated as being forencryption, decryption, or audit; in any combination, in any order. However, in a single command, only
one session is allowed to have the encrypt attribute, one session is allowed to have the decrypt attribute,and one session is allowed to have the audit attribute.
A single session can be used for authorization, encryption, decryption, and audit at the same time. Thatis, if a session has one handle with the "@" decoration, the associated authorization session can have theencrypt, decrypt, and audit attributes all set. A password authorization cannot be used for anything but
authorization and the TPM will return an error (TPM_RC_ATTRIBUTES) if encrypt, decrypt, or audit is
SET in a password authorization.
NOTE 1

If an authorization session has encrypt, decrypt, and audit all SET, then the command can only haveone authorization session.

Page 92
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The combinations of attributes allowed for each session are summarized in Table 6.
Table 6 — Use of Authorization/Session Blocks
Position

password
authorization (1)(6)authorization
session (2)(6)encryption
session (3)decryption
session (4)audit
session (5)

1

✓

✓

✓

✓

✓

2

✓

✓

✓

✓

✓

✓

✓

✓

3
NOTES:
1)a password authorization cannot be used for encryption, decryption, or audit.

2)

an HMAC authorization session can also be used for encryption, decryption, and audit and a policy
authorization session can also be used for encryption and decryption

3)

only one session can be designated as being used for encryption

4)

only one session can be designated as being used for decryption

5)

password authorization sessions and policy sessions cannot be used for audit

6)

authorization sessions come before sessions used only for encryption, decryption, or audit

In TPM 2.0 Part 3, the schematic for each command will indicate if it has handles and if use of thosehandles requires authorizations. If there is an at symbol ("@") character in front of the handle name, thenuse of the TPM resource associated with the handle requires authorization and an authorization (session
or password) will be present. An authorization will be present for each TPM resource that requires
authorization (each handle with an "@"). An additional indication that a handle requires authorization isthat, in the "Description" column of the command schematic, each handle has an "Auth Index:" entry. If
that entry says "None", then no authorization is required. If that entry is followed by a number, then thenumber indicates the order of the associated authorization in the list of authorizations.
NOTE 2Currently, no command requires more than two authorizations.

If a command requires authorizations, then those authorizations will be first in the list of
authorizations/sessions. They can then be followed by other sessions used for encryption, decryption, or
audit.
If the responseCode is TPM_RC_SUCCESS, the response has the same number of sessions in thesame order as the request. Otherwise, no authorization or audit sessions are present.
Authorization Structure
18.6.2.1

Command

In a command, each authorization structure has the format shown in Figure 13.
session handle

A four-octet value indicating the session handle associated with thisdata block (will be TPM_RS_PW for a password authorization)

size field

A two-octet value indicating the number of octets in nonce

nonce

If present, an octet array that contains a number chosen by the caller

session attributes

A single octet with bit fields that indicate session usage

size field

A two-octet value indicating the number of octets in authorization

authorization

If present, an octet array that contains either an HMAC or a password,
depending on the session typeFigure 13 — Authorization Layout for Command
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 93
December 24, 2020

Trusted Platform Module Library
18.6.2.2

Part 1: Architecture

Response

In a response, each session structure has the format shown in Figure 14.
size field

A two-octet value indicating the number of octets in nonce (will be zerofor a password authorization)

nonce

If present, an octet array that contains a number chosen by the TPM

session attributes

A single octet with bit fields that indicate session usage

size field

A two-octet value indicating the number of octets in acknowledgment

acknowledgment

If present, an octet array that contains an HMAC

Figure 14 — Authorization Layout for Response

Clause 19.6.7 describes the methods for creating an authorization session.
Session Handles
Session handles are described in 15.4. They identify the session being referenced by a specific session
structure.
For a given command, the handle associated with a specific HMAC or policy session can occur only oncein the Authorization Area. The handle representing a password authorization (TPM_RS_PW) can occur
multiple times.
Session Attributes (sessionAttributes)
Each session has a sessionAttributes octet to indicate how the session is to be applied. Table 7 explains
the meaning of the fields in this octet.
If a session is not being used for authorization, at least one of decrypt, encrypt, or audit must be SET.
Table 7 — Description of sessionAttributes
Attribute

Meaning

continueSession

This attribute is used to indicate to the TPM if the session is to remain 'active' when the commandcompletes. If this attribute is CLEAR in the command and the command completes successfully(TPM_RC_SUCCESS), then the session will be flushed from TPM memory and the associatedsession handle will be available to be assigned to new sessions.
When the TPM responds, it will echo this attribute to indicate that the session remains open (seethe exception for password authorization below).
NOTE

In this context, "echo" means that the value of a session attribute will be the same in the
response as it was in the command.

The primary purpose of this attribute is to eliminate having to do explicit flushes(TPM2_FlushContext()) of a session when it is no longer used. Having this bit CLEAR on the lastuse of the session will end it and reclaim the TPM resources assigned to this session.
For a password authorization, this attribute has no effect, as there are no TPM resources
associated with a password authorization. This attribute will always be SET in a response
associated with a password authorization.
If the audit attribute is SET, then this attribute should also be SET since the audit data will be lost
if the session is flushed.

Page 94
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Attribute

Meaning

decrypt

This attribute is used to indicate to the TPM that the secrets associated with the session are to be
used to decrypt the first parameter of the command (the session-based encryption scheme isdefined in clause 21). The parameter will be decrypted after the HMAC computations are
successfully completed.
This attribute can only be SET in a command that has a sized buffer as its first parameter.
This attribute is required to be CLEAR in a password session. If SET in a password session, thenthe TPM will return an error because there is no session key for the decrypt operation
This attribute is echoed by the TPM in the corresponding session in the response
This attribute can only be SET in one session per command. A session with this attribute does notneed to be associated with an entity identified in the handle area. That is, the session can be
added just for using the session's secret for parameter decryption.
This attribute can be SET in combination with any other session attribute.

encrypt

This attribute is used to indicate to the TPM that the secrets associated with the session are to be
used to encrypt the first parameter of the response (the session-based encryption scheme isdefined in clause 21). The parameter will be encrypted before the TPM performs the HMAC
computations for any of the sessions.
This attribute may only be SET in a response that has a sized buffer as its first parameter.
This attribute is required to be CLEAR in a password session. If SET in a password session, thenthe TPM will return an error because there is no session key for the encrypt operation.
This attribute is echoed by the TPM in the corresponding session in the response.
This attribute can only be SET in one session per command. A session with this attribute does notneed to be associated with an entity identified in the handle area. That is, the session can be
added just for using the session's secret for parameter decryption.
This attribute can be SET in combination with any other session attribute.

auditThis attribute indicates that the session is being used for audit. A digest is maintained in thesession context and is updated each time the session is used with a command and audit is SET.
This attribute does not need to be SET in every use of the session but the TPM will only update
the audit data when the session is used with this attribute SET.
This attribute has no meaning for a password authorization and is required to be CLEAR.
This attribute is not allowed to be SET in a policy or trial policy session. This is because thecontext of the policy session would have to increase in order to hold the additional audit digest.
This is significant overhead and, rather than require the additional memory in policy sessions, useof audit is restricted to HMAC sessions.
After an HMAC session is started (TPM2_StartAuthSession(sessionType = TPM_SE_HMAC), this
attribute can be set in any subsequent use of the session. On the first use of the session with this
attribute set, the TPM will initialize the audit digest to 0…0 and then extend the concatenation of
cpHash for the command and rpHash for the response.
This attribute will be echoed by the TPM in the response.
This attribute can be used in combination with any other session attributes but only one session ineach command can have this attribute SET.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 95
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Attribute

Meaning

auditExclusive

This attribute is used to restrict use of an audit session. When this attribute is SET, the TPM willvalidate that the session has been used for all auditable commands since the audit sequence wasstarted.
NOTE

An audit sequence is started when the audit digest is reset to 0…0. The audit digest is set to
0…0 when the session is first used as an audit session and when the audit digest is reset (seethe description of the auditReset attribute below).

If the session was used for all auditable commands, then it is said to be "exclusive"(see 20.2 for
explanation of exclusive audit sessions).
If this attribute is SET and the session is exclusive, then the command will execute. Otherwise,
the TPM will fail this command to indicate to the caller that some TPM actions were not includedin the audit sequence.
Evaluation of the exclusive status is done at the start of the command. A session does not obtain
the exclusive status until the end of the command (this prevents a session from becoming
exclusive if the command fails). The implication of this processing is that, if this attribute is SET inthe command that starts the audit sequence, the command will fail because the session has not
yet become exclusive.
In a response, this attribute will be SET if the session has exclusive status. When a session is firstused as an audit session this attribute will be SET in the response as no command has executedwithout this session since the start of the sequence.
This attribute can only be SET when the audit attribute is SET which excludes this attribute frombeing SET on a password authorization or a policy session.
auditReset

18.7

This attribute allows the caller to restart an audit sequence with a session that has previously
been used for audit. If the associated command completes successfully, the TPM will initialize thesession audit hash with 0…0 before Extending the cpHash and the rpHash. The response will
have the exclusive attribute SET.
This attribute can only be SET if audit is SET.
The TPM will echo this attribute in the response.

Command Parameter Hash (cpHash)

The command parameter hash (cpHash) is used in the computation of a command authorization HMAC
and is included in the digests of session and command audits (depending on the policy, the cpHash canalso be used in the authorization). The cpHash is computed from the parameters of the command as
follows:

cpHash ≔ HsessionAlg (commandCode {|| Name1 {|| Name2 {|| Name3 }}} {|| parameters })

(15)

where

HsessionAlg

hash function using the algorithm selected for the session when it was
initializedcommandCodecommand code for the command

Name1

unique identity of the entity associated with the first handleName2unique identity of the entity associated with the second handle

Name3

unique identity of the entity associated with the third handle

Page 96
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
parameters
18.8

Trusted Platform Module Libraryremaining command parameters

Response Parameter Hash (rpHash)

The response parameter hash is used in the computation of a response acknowledgment HMAC and isincluded in the digest of session and command audits. The rpHash is computed from the parameters of
the response as follows:

rpHash ≔ HsessionAlg (responseCode || commandCode {|| parameters })

(16)

where

HsessionAlg

hash function using the algorithm selected for the session when it was
initialized

responseCodecommand result codecommandCodethe commandCode from the commandparameters

response parameters

The contents of the handles area of the response are not included in the rpHash.
NOTE

18.9

An rpHash needs to be computed only when the responseCode is TPM_SUCCESS, which meansthat it is redundant to include the response code. It is retaine d for legacy reasons.

Command Example

Table 8 shows an example of a command schematic used in this specification. The command has two

object handles (handleA and handleB). The "@" on the handleA name indicates that use of the entity
associated with the handle requires authorization. The command has at least one session to authorize
use of handleA. It will not have a session for use of handleB. The Authorization Area can have anadditional audit session and a session used only for parameter encryption. Since one session is required,
tag is TPM_ST_SESSIONS, and the authorizationSize field is present.
Although they are not shown in the command schematic, the authorizationSize value and the
Authorization Area would be present in the command buffer and be located between handleB anddataSize.
NOTE:

The Authorization Area is not shown with the command schematic because no single representationis possible.

The command and response tables have three columns.
1) Type – This column indicates the data type of the parameter passed to the TPM in a command or
received from the TPM in a response.
2) Name – This column indicates the name of the parameter. This name is referenced in the descriptionof the command that precedes the command table and in the detailed actions of the command that
follows the response table.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 97
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture3) Description – This column provides a limited description of the parameter and indicates the possible
options for the command.
EXAMPLE 1

Table 8 — Command Layout for Example Command
Type

Name

Description

TPMI_ST_COMMAND_TAG

tag

TPM_ST_SESSIONSUINT32

commandSize

TPM_CC

commandCode

TPM_CC_Example
handle to use for one object of thecommand

TPM_HANDLE@handleA

Auth Index: 1
Auth Role: USER
handle to use for the second object

TPM_HANDLE

handleBUINT32

dataSize

example data size

OCTET

data[dataSize]

example data

Auth Index: None

Table 9 illustrates all command octets for the command in Table 8. In this example, the nonce size is 20

octets and the authorization HMAC is computed using SHA256. The values in shaded cells are not shownin the TPM 2.0 Part 3 schematic of the command but are included in the command data sent to the TPM.
EXAMPLE 2

Table 9 — Example Command Showing authorizationSize
OffsetSizeParameter

Value

0

2

tag

TPM_ST_SESSIONS

2

4commandSize

209 < size in octets of the command >64commandCode

TPM_CC_Example

104handleA< a valid TPM resource handle>

14

4

handleB< a valid TPM resource handle>

18

4

authorizationSize

61 < size of the authorization session >22

4

authHandle< a valid TPMI_SH_AUTH_SESSION >26

2nonceCallerSize

20 < size of nonce >28

20

nonceCaller< a 20-octet random value>48

1

sessionAttributes(continueSession=1)

49

2

hmacSize

32 <size of HMAC>

51

32

HMAC

< a 32-octet HMAC value based on
SHA256>

83

2

dataSize

32 < size of the buffer >

85

124

data[dataSize]< 124 octet buffer >209

Page 98
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

18.10 Response Example
Table 10 shows an example schematic as it would appear in TPM 2.0 Part 3. The example is for a
response sent from the TPM after successful completion of the example command in Table 8. The
response has the same number of sessions in the same order as did the command.
EXAMPLE 1

Table 10 — Response Layout for Example Command
Type

Name

Description

TPM_STtag

TPM_ST_SESSIONSUINT32

responseSize

TPM_RC

responseCode

response code of the operation

TPM_HANDLE

handlenot included in the rpHashUINT32

dataSize

size in octets of the following data

OCTET

data[dataSize]a returned block of information

Table 11 illustrates the full response for the command in Table 8. As in the command, the nonce size is
20 octets and the acknowledgment HMAC is computed using SHA256. The values in shaded cells are notshown in the TPM 2.0 Part 3 schematic of the response but are present in the response data from the
TPM.
EXAMPLE 2

Table 11 — Example Response Showing parameterSize
OffsetSizeParameter

Value

0

2

tag

TPM_ST_SESSIONS

2

4

responseSize

203 < size in octets of the response >64responseCode0 < success >10

4handle< a valid TPM_HANDLE >144parameterSize

128

18

4

dataSize

124

22

124

data[dataSize]< 124 octet buffer >146

2nonceTpmSize

20

148

20

nonceTPM< a 20-octet random value >168

1sessionAttributes(continueSession=1)

169

2

hmacSize

32

171

32

HMAC

< a 32-octet HMAC value based on
SHA256 >203

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 99
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Authorizations and Acknowledgments
19.1

Introduction

Many commands to the TPM reference TPM-resident structures and use of these structures can requireauthorization. This authorization is provided in structured data that follows the command data. When an
authorization is provided to a TPM, the TPM will provide an acknowledgment.
To provide flexibility in how the authorizations are given to the TPM, this specification defines threeauthorization types:
1) password;
2) HMAC; and3) policy.
Depending on the command, zero, one, or two authorizations can be required. In a command, theauthorizations follow the handles, and in a response, the authorization replies follow the response
parameters. The command definition indicates how many authorizations are required.
19.2

Authorization Roles

For each object and NV Index, there is a set of operations that can be performed on or with that object or
NV Index. The operations are divided into groups, based on the impact of the operation on the object. To
perform an operation with or on an object in a group, the authorization specific to that group must be
provided. When performing an operation in one of the groups, the caller is acting in a specific role withrespect to that object.
The TPM supports three different authorization roles. The role and attributes determine whether apassword or HMAC can be used for authorization. A policy (if not the Empty Policy) can always be used.
1) USER – this authorization role is used for the normal uses of a key (e.g., signing with a signing key,or loading the child of a Storage Key). Methods are defined to allow USER role authorization to beprovided either with an authorization value (authValue) or a policy. If userWithAuth is SET, then
USER role authorization can be provided with a password authorization or an HMAC session. If
userWithAuth is CLEAR, then a password and HMAC authorizations cannot be used to provide
USER role authorizations. A policy session that satisfies the authPolicy of the entity can be usedregardless of the setting of userWithAuth.
NOTE 1For USER role, an authPolicy is satisfied when the policyDigest of a policy session matches thevalue of the authPolicy value of the object.

NOTE 2

If use of an object is to be gated based on PCR values, a policy session is required (see 19.7). If theintent is that different Users have access to the object but only if the PCR are correct, then it islikely that authorization with the authValue will be disabled; otherwise, the caller could circumvent
PCR protections simply by providing the authValue.

2) ADMIN – the object Administrator controls the certification of an object (TPM2_Certify() andTPM2_ActivateCredential()) and controls changing of the authValue of an object(TPM2_ObjectChangeAuth()). When an action requires ADMIN role authorization, that authorization
can be provided using the authValue of the object if the adminWithPolicy attribute of the object is
CLEAR. As with USER role authorization, ADMIN role can always be provided with a policy session
as long as the policy session satisfies the authPolicy of the object.

Page 100
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

NOTE 3

For ADMIN role, an authPolicy is satisfied when policySession→policyDigest matches the value ofthe authPolicy value of the object and policySession→commandCode matches commandCode forthe authorized command.

EXAMPLE

If the adminWithPolicy attribute of an object is SET, and if no branch i n the object's policy equation
contains TPM2_PolicyCommandCode(TPM_CC_Certify), then certification of that key cannot occur.

3) DUP – this authorization role is only used for TPM2_Duplicate(). If duplication is allowed,
authorization must always be provided by a policy session and the authPolicy equation of the object
must contain a command that sets the policy command code to TPM_CC_Duplicate.
19.3

Physical Presence Authorization

Authorization for some commands requires that it be provided with Platform Authorization. Authorization
for some other commands allows use of either Platform Authorization or Owner Authorization (Most ofthese commands cause persistent state change of the TPM). For these commands, it is possible torequire that authorization be augmented with an out-of-band method.
For commands that require Platform Authorization and commands that require a hierarchy authorization,
it is possible to require an out-of-band authorization. This can take any number of forms, such as a
dedicated pin in the TPM, a special signaling method through the TPM interface, or any desired
alternative. Whatever the form, the out-of-band authorization is referred to in this specification as PhysicalPresence (PP). This does not mean that the signaling requires a human to be physically present in orderfor the indication to be provided. The term is used in this specification because it was used in previous
TPM specifications to refer to a similar concept.
The TPM maintains a table of the commands that require that PP be asserted to authorize commandexecution. Only certain commands can be included in this table. If, in TPM 2.0 Part 3, the schematic for acommand has TPM_RH_PLATFORM in the "Description" column for one of the handles, then thatcommand can be added to the list of commands that require PP. Otherwise, it cannot.
NOTE 1In the "Description" column, TPM_RH_PLATFORM will be followed by +PP if assertion of PhysicalPresence is required or "+{PP}" to indicate that assertion of Physical Presence may be required if
indicated by the table.

NOTE 2A platform-specific specification may require that the table be initialized in a specific way. It could
even require that the table have certain commands defined to require PP confirmation even though a
PP interface is not provided on the TPM. This would serve to disable the use of that command by
the platform.

When the authorization handle is TPM_RH_PLATFORM, the TPM checks the table to see if thecommand requires confirmation with PP. If so, PP is checked before the TPM performs any otherauthorization checks.
TPM2_PP_Commands() is used to change the contents of the table of commands that requireconfirmation with PP authorization. Authorization of the command TPM2_PP_Commands() requires that
PP be asserted and TPM2_PP_Commands() cannot be removed from the list of commands that requirePP.
NOTE 3This constraint on TPM2_PP_Commands() prevents setting or modification of the table if no PP
interface exists on the TPM.

The contents of the table
TPM_CAP_PP_COMMANDS).

can

Family “2.0”

TCG PUBLIC REVIEW

Level 00 Revision 01.64

be

read

using

Copyright © TCG 2006-2021

TPM2_GetCapability(capability==

Page 101
December 24, 2020

Trusted Platform Module Library
19.4

Part 1: Architecture

Password Authorizations

A plaintext password value can be used to authorize an action when use of an authValue is allowed. A
plaintext password can be appropriate for cases in which the path between the caller and the TPM istrusted or when the authorization value is well known. For these instances, encryption of parameters or
the hiding of authorization values in an HMAC is not required.
NOTE 1

While it can seem relatively easy for a caller to perform an HMAC, ther e are situations where thecaller is resource-constrained and unable to do so. This is especially true when the calling software
does not support the hash algorithms implemented in the TPM. Additionally, authentication using acryptographic protocol makes it difficult to provide operating system abstractions.

A reserved authorization handle (TPM_RS_PW) indicates that the authorization is a password.
TPM_RS_PW is always available, and a separate action to create an authorization session is not
required. A password authorization does not use nonces. sessionAttributes→continueSession is ignored.
A password authorization lets the caller send more or fewer octets than are present in the object’s
authorization field. The TPM truncates any octets of zero on either of the two values before they arecompared.
If present, a password authorization is always associated with a command handle that requires
authorization as there is no session context associated with a password that would allow it to be used forencryption or command audit.
Unlike other handles for other session types, the TPM_RS_PW session handle can be used for morethan one authorization.
Password authorization data sent to the TPM has the format shown in Table 12.
Table 12 — Password Authorization of Command
Type

Name

Description

TPMI_SH_AUTH_SESSION

authHandle

required to be the reserved authorization session
handle TPM_RS_PW

TPM2B_NONCE

nonceCallerrequired to be an Empty Buffer

TPMA_SESSION

sessionAttributes

only continueSession can be SET

TPM2B_AUTH

password

authorization compared to the authValue of the TPM
entityTable 13 illustrates the format of a password authorization in a response. This structure is provided toensure a one-to-one correspondence between the sessions in the command and in the response.
Table 13 — Password Acknowledgment in Response
Type

Name

Description

TPM2B_NONCE

nonceTPM

zero-length for a password authorization

TPMA_SESSION

sessionAttributes

copy of the flags from the password authorization in thecommand, continueSession will be SET

TPM2B_AUTHhmac

zero-length buffer for a password authorization

NOTE 2This structure is used to provide symmetry between password and other response sessions.

Page 102
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
19.5

Trusted Platform Module Library

Sessions

A session is a collection of TPM state that changes after each use of that session. When an object
context is loaded into the TPM, multiple copies of the object context can exist both on the TPM and insaved contexts (see clause 30). When a session context is created, only one copy of that context canexist, either on the TPM or as a saved context. The context of a session changes on each use.
A session has a handle that is assigned by the TPM when the session is created. That handle will always
refer to the same session until the session is closed. If a handle is re-assigned to a subsequently createdsession, the session context data will contain a TPM-generated nonce that makes the new instance of thesession unique, even though the handle can have been used previously. This nonce will change eachtime the session is used so that previous instances of the same session can be distinguished from eachother (i.e., the nonce prevents reuse of stale session contexts).
There are three uses of a session:1) authorization – A session associated with a handle is used to authorize use of an object associatedwith a handle. If it is not a password authorization, it can also be used to provide keys for encryptionof command or response parameters. A policy session used to authorize cannot also be used as anaudit session. An HMAC session used to authorize can be used as an audit session.
2) audit – An audit session collects a digest of command/response parameters to provide proof that acertain sequence of events occurred. An audit session can also be used to provide secrets forencryption of command or response parameters and can be used for authorization of an HMAC
session.
3) encryption – A session that is not used for authorization or audit can be present for the purpose of
encrypting command or response parameters. If an encryption-only session exists, it will follow theauthorization sessions and can come before or after a session used only for audit.
A command can have as many as three authorization blocks. Password blocks can only be used forauthorization, so the maximum number of password blocks is equal to the number of authorizations
required by the command.
19.6

Session-Based Authorizations
Introduction

Session-based authorizations are used both for protocols that require confidentiality for the authorization
value and for audit sessions that require tracking of a sequence of commands sent to the TPM. An
authorization session also provides a means of linking the uses of the session.
There are two types of session-based authorization: HMAC and policy. Both types of session are initiatedusing TPM2_StartAuthSession(). That command establishes the parameters that will be used for theauthorizations. The sessionType parameter determines if the session will be an HMAC or policy session.
When the session is started, the hash algorithm and TPM nonce size used in the session are specified by
the caller. The command may include an initial caller nonce and a salt value to generate the session key.
The parameters of each session are independent from the parameters of any other session and arelimited only by the capabilities of the TPM. When TPM2_StartAuthSession() completes successfully, theTPM returns a handle for the session as well as the initial nonceTPM value.
Once an authorization session is established, it can be used to authorize actions in multiple commands.
The session is not ended until explicitly closed or flushed.
The secret values of a session are determined by the handles used when the session is started. The
command for starting a session allows selection of up to two object handles. One handle indicates a TPM
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 103
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

object that is used to encrypt a salt value that is sent when the session is started. A second handle
indicates an object containing a shared secret. The salt value and the shared secret are combined with anonce provided by the caller to create the session secrets.
NOTE

Using the endorsement key for which the certificate chain has been validated as the salt key canensure that the caller is connected to an authentic TPM.

Authorization Session Formats
For a session-based authorization session, the authorization structure for a command is as shown in
Table 14.
Table 14 — Session-Based Authorization of Command
Type

Name

Description

TPMI_SH_AUTH_SESSION

authHandle

the handle for the authorization session

TPM2B_NONCE

nonceCaller

the caller-provided session nonce; size may be
zero

TPMA_SESSION

sessionAttributes

the flags associated with the session

TPM2B_AUTHhmac

the session HMAC digest value

In a response, the format for the acknowledgement is as shown in Table 15.
Table 15 — Session-Based Acknowledgment in Response
Type

Name

Description

TPM2B_NONCE

nonceTPM

the TPM-provided session nonce. Size is as
specified when the session was started.

TPMA_SESSION

sessionAttributes

the flags associated with the session. This
attribute should be the same as the values in thecommand except continueSession may be
CLEAR.

TPM2B_AUTHhmac

the session HMAC digest value

Session Nonces
19.6.3.1

Overview

The primary use of a nonce in a session is to prevent an authorization from being reused. When thesession is started by TPM2_StartAuthSession(), the caller indicates, among other things, the size of thenonces to be used in the authorization HMAC and an initial nonce value (nonceCaller). After establishing
the session, the TPM returns a handle to identify the session and a TPM-generated random nonce(nonceTPM). The TPM stores this nonceTPM in the context of the session.
Each time the session is used for authorization, the caller performs an HMAC using, along with otherparameters, the last nonceTPM for the session and a new nonceCaller for the session. The TPM thenuses the received nonceCaller and the saved nonceTPM to validate the HMAC. For a response, the TPM
uses the last nonceCaller and a newly generated nonceTPM in the HMAC. The caller then uses thereceived nonceTPM and the saved nonceCaller to validate the HMAC in the response.
A nonce has a size field indicating the number of octets in the nonce followed by the nonce data. The
nonce size is not included in the HMAC computation.

Page 104
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
19.6.3.2

Trusted Platform Module Library

Session Nonce Size

When an authorization session is created, the caller provides an initial nonce (nonceCaller). The size fieldof nonceCaller is retained by the TPM and used to determine the size of all nonces generated by the TPM(nonceTPM) in the subsequent uses of the session. The minimum size for nonceCaller in
TPM2_StartAuthSession() is 16 octets.
After the initial session setup, the caller may use any size for a nonceCaller in each use of the session.
The nonceCaller size may vary from zero (0) up to the size of nonceTPM (the initial nonceCaller size).
NOTE

A TPM implementation may allow larger nonce sizes but the caller cannot expect a TPM to accept a
nonce size larger than the initial nonceCaller size.

The maximum size that may be requested for nonceTPM is the size of the digest produced by theauthorization session hash.
EXAMPLEFor SHA-1 the maximum size for nonceTPM is 20 octets and for SHA256 it is 32 octets.

When a session nonce is used in the authorization session HMAC, the size field of the nonce is notincluded in the authorization computation. If the nonce size field is zero (0), then the nonce does notaffect the authorization HMAC value.
19.6.3.3

Guidance on Nonce Size Selection

The size of the nonce should be chosen to provide a reasonable guarantee that a TPM-generated nonce
value will not be used twice with the same sessionKey. The choice of nonce size is not related to thenumber of uses of a specific authorization session but is related to the number of uses of the sessionKey.
An HMAC sessionKey is derived from the authValue kept in an object and that authValue can have a long
lifetime. To prevent replay attacks on a long-lived authValue, use of large nonces is recommended.
NOTE 1

The combined nonceCaller plus nonceTPM are what determine the anti-replay protection provided
by the nonces. Making the combined size larger than the block size of the session hash is notparticularly useful. If the caller does not have a good source of entropy for an RNG, then making thenonceTPM the size of the digest of the session hash is recommended, so that a nonceCaller size ofzero would be satisfactory.

NOTE 2

When using a session for encryption, if a parameter is encrypted in a response to on e command anda parameter is encrypted in the request of the next command, and they both use the same session
for encryption, then the caller has to provide a nonceCaller in order to prevent the use of the sameencryption key on the input and output. A nonce of length 1 with a value of zero would suffice.

19.6.3.4

Nonce Binding

A command can have sessions other than those required for authorization. One use of an extra session isto encrypt a command or response parameter. If an extra encrypting session were removed by anattacker, the TPM would not properly encrypt/decrypt the data and could, as a result, fail to encrypt a
response parameter. To prevent removal of extra encrypting sessions, the nonceTPM of each of thesesessions is included in the HMAC computation of the first authorization session of a command. If an extra
session is removed by an attacker, the first authorization will fail, and the command will not be executed.
To simplify the logic in the TPM, the nonceTPM of any session used for encryption of command or
response data is included in the HMAC computation for the first session even if the encrypt or decrypt
session is also an authorization session.
NOTE

If the first session is a password authorization, then the path to the TPM is trusted and there is noneed to guard against the extra session being removed, also there is probably no need forparameter encryption when a trusted path is present.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 105
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Authorization Values
19.6.4.1

Overview

An object can have a value used to authorize various actions on the object. An authorization session is
the mechanism through which a caller proves knowledge of the authorization value (authValue) needed toallow an action.
An authValue can be sent as a password that does not provide confidentiality (see 19.4), or in an HMACbased authorization session that can provide confidentiality of the authValue.
19.6.4.2

authValue Size

An authValue can be as small as zero octets but not larger than the digest size of the algorithm used tocompute the Name of the object.
EXAMPLE

If the Name algorithm for an object is SHA256, then the largest authValue for the object would be 32
octets.

19.6.4.3

Authorization Size Convention

When an authValue is based on a password or passphrase, then the authValue should be thepassword/phrase as long as the password/phrase is no larger than the digest produced by the nameAlgof the object.
If the passphrase is “This is a sample passphrase”, and nameAlg is TPM_ALG_SHA256, then theauthValue is 27 octets long containing the value “This is a sample passphrase”.

EXAMPLE

Trailing octets of zero are to be removed from any string before it is used as an authValue.
If the password/phrase, with trailing zeros removed, is longer than the digest produced by the nameAlg of
the object, then the password/phrase – with trailing octets of zero removed – is hashed using nameAlg
and the resulting hash given to the TPM as the authValue for the object.
HMAC Computation
The HMAC computation for all session types is the same. A sessionKey value is concatenated to an
authValue to create the key that is used in the computation of the HMAC in a command or response. If
sesssionkey and authvalue are both the Empty Buffer, see 19.6.15.

authHMAC ≔ HMACsessionAlg ((sessionKey || authValue),(pHash || nonceNewer || nonceOlder{ || nonceTPM decrypt } { || nonceTPM encrypt }|| sessionAttributes))

(17)

where

HMACsessionAlg

the HMAC function using the hash algorithm specified when the session
was started

sessionKey

a value that is computed in a protocol-dependent way, using KDFa().
When used in an HMAC or KDF, the size field for this value is notincluded.

authValue

a value that is found in the sensitive area of an entity. This value is an
EmptyAuth if the HMAC is being computed to authorize an action on the

Page 106
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Libraryobject to which the session is bound. The size field for this value is notincluded in any KDF or hash function.
NOTE 1

For policy sessions, the authValue is not included in the HMAC
calculation
unlessthepolicysessionincluded
TPM2_PolicyAuthValue() and it was not superseded by
TPM2_PolicyPassword().

NOTE 2

Trailing zeros are always removed from an authValue before it
is used in an authorization computation.

pHashdigest of the command (cpHash) or response parameters (rpHash) using
the session hash algorithm.

nonceNewera value that is generated by the entity using the session. A new nonce isgenerated on each use of the session. For a command, this will be
nonceCaller and for a response, nonceTPM. The nonce size field is notincluded in the HMAC.

nonceOldera value that was received the previous time the session was used. For acommand, this will be nonceTPM and for a response, nonceCaller. The
nonce size field is not included in the HMAC.

nonceTPMdecryptin the HMAC computation for the first authorization session of acommand, if a different session is being used for parameter decryption,then the nonceTPM for that session is included in the HMAC of the firstauthorization session; but only in the command (see 19.6.3.4). The
nonce size field is not included in the HMAC.

nonceTPMencrypt

sessionAttributes

NOTE 3The decrypt session is used by the TPM to decrypt a parameterin the command.

NOTE 4

The nonce of the decrypt session is included even if thatsession is also used for authorization.

in the HMAC computation for the first authorization session of acommand, if a different session is being used for parameter encryption,then the nonceTPM for that session is included in the HMAC of the firstauthorization session; but only in the command (see 19.6.3.4). The
nonce size field is not included in the HMAC.
NOTE 5The encrypt session is used by the TPM to encrypt a parameterin the response.

NOTE 6

The nonce of the encrypt session is included even if thatsession is also used for authorization.

NOTE 7

If the same session (not the first session) is used for decryptand encrypt, its nonceTPM is only used once. If different
sessions are used for decrypt and encrypt, both nonceTPMs areincluded.

an octet indicating the attributes associated with a particular use of thesessionWith the exception of sessionAttributes, all the values are large numbers, typically with sizes of 20 octets
or more.
In the HMAC computation equations shown below, the possibility that the HMAC computation can include
nonceTPMdecrypt or nonceTPMencrypt is indicated by “nonceOlder*" (asterisk added).

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 107
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Note on Use of Nonces in HMAC Computations
In equation (17), and the HMAC computation equations that follow, all of the nonce values are in
TPM2B_NONCE data structures. In the HMAC computations, the nonce entries should all be read as if
they had the .buffer suffix indicating that only the data portion of a nonce is ever used in an HMAC
computation.
Starting an Authorization Session
TPM2_StartAuthSession() is used to start an authorization session. The parameters of this command canbe chosen to produce sessions with different properties.
Table 16 — Schematic of TPM2_StartAuthSession Command
Type

Name

Description

TPM_STtag

UINT32

commandSize

TPM_CC

commandCode TPM_CC_StartAuthSession

TPMI_DH_OBJECT+

tpmKeyhandle of a loaded key used to encrypt salt
may be TPM_RH_NULL
Auth Index: None

TPMI_DH_ENTITY+

bind

entity providing the authValue
may be TPM_RH_NULL
Auth Index: None

TPM2B_NONCE

nonceCaller

initial nonceCaller, sets nonce size for thesession

TPM_SEsessionTypeindicates the type of session (HMAC orpolicy)TPM2B_ENCRYPTED_SECRET encryptedSalt

tpmKey algorithm-dependent secret
if tpmKey is TPM_RH_NULL, this shall be an
Empty Buffer

TPMT_SYM_DEF+

symmetric

the algorithm and key size for parameterencryption
may select TPM_ALG_NULL

TPMI_ALG_HASH

authHashhash algorithm to use for the session; andshall be a hash algorithm implemented on the
TPM and not TPM_ALG_NULL

The two values that determine the session protection values are tpmKey and bind. Both of these handles
can reference TPM_RH_NULL or a TPM entity. The tpmKey parameter references the key that is used toencrypt a salt value that is used in the computation of the sessionKey. The bind parameter references a
TPM entity that can provide an authValue to the computation for the sessionKey. The four variations for
tpmKey and bind give sessions with different properties.

Page 108
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library
Table 17 — Handle Parameters for TPM2_StartAuthSession

tpmKeybindsession properties

TPM_RH_NULL

TPM_RH_NULL

Unbound session

TPM_RH_NULL

TPM entity

Bound session

TPM key

TPM_RH_NULL

Salted session

TPM key

TPM entity

Salted and bound session

sessionKey Creation
A sessionKey value is used in the HMAC computation as shown in equation (17). If both tpmKey and bind
are TPM_RH_NULL, then sessionKey is set to an Empty Buffer. Otherwise, the sessionKey is created asfollows:

sessionKey ≔ KDFa(sessionAlg, (authValue || salt), “ATH”, nonceTPM, nonceCaller, bits)

(18)

where

sessionAlg

a TPM_ALG_ID for a hash that was chosen by the caller when thesession was started

authValue

if bind is not TPM_RH_NULL, a TPM2B_AUTH.buffer that is found in thesensitive area of a TPM entity; otherwise, an Empty Buffersalt

if tpmKey is not TPM_RH_NULL, then the salt value recovered fromencryptedSalt; otherwise, an Empty Buffer“ATH”

a four-octet label value (see 4.1)

nonceTPM

a TPM2B_NONCE that is generated by the TPM when the session wasstartednonceCallera TPM2B_NONCE that is provided by the caller when the session wasstarted.

bits

the number of bits returned is the size of the digest produced bysessionAlg

NOTE

When an authorization failure occurs, the TPM will check to see if the use of the object is exempt
from dictionary attack protection. If it is ex empt, the response code is changed from
TPM_RC_AUTH_FAIL to TPM_RC_BAD_AUTH and no increment of the failed authorization counteroccurs (see 19.8).

Unbound and Unsalted Session Key Generation
In this session key generation method used by TPM2_StartAuthSession(), tpmKey and bind are both
TPM_RH_NULL. This results in the session having no sessionKey (it is an Empty Buffer). The session is
not bound to any object.
NOTEThis session type is similar to the OIAP session of TPM 1.2.

A session started using this format can be used for parameter encryption while executing TPM
commands. However, during these commands, the key used to encrypt the parameter will only use theauthValue of the object being accessed by the commands in the key generation, so the strength of theencryption will be no better than the entropy in the authValue of the object.
When computing the HMAC, the authValue of the referenced entity is used:
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 109
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

authHMAC ≔ HMACsessionAlg (authValueentity.buffer,(pHash || nonceNewer.buffer || nonceOlder*.buffer || sessionAttributes))
If the size of authValue is zero, then the caller may omit the HMAC from the authorization (see No HMAC
Authorization19.6.15).
Table 18 — Format to Start Unbounded, Unsalted Session
Type

Name

Description

TPM_STtag

UINT32

commandSize

TPM_CC

commandCode

TPM_CC_StartAuthSession

TPMI_DH_OBJECT+

tpmKeyTPM_RH_NULL

TPMI_DH_ENTITY+bind

TPM_RH_NULL

TPM2B_NONCE

nonceCaller

initial nonceCaller, sets nonceTPM size forthe session

TPM2B_ENCRYPTED_SECRET encryptedSalt

00 0016

TPM_SEsessionTypeindicates the type of the session (HMAC,
policy, or trial)

TPMT_SYM_DEF+

symmetric

will normally be TPM_ALG_NULL for an
unbound and unsalted session

authHashhash algorithm to use for the session;required to be a hash algorithm
implemented on the TPM and not
TPM_ALG_NULL

TPMI_ALG_HASHNOTEWhen sessionType is TPM_SE_TRIAL, there is no benefit in using any other version of
TPM2_StartAuthSession() as a trial session is not allowed to be used for authorization. This meansthat the sessionKey of the session will never be used so there is no point in having the TPM
generate it.

Bound Session Key Generation
In this session key generation method used by TPM2_StartAuthSession(), tpmKey is TPM_RH_NULL
indicating that no salt value is present but bind references some TPM entity with an authValue.
NOTE 1This session type has properties that are similar to an OSAP session in TPM 1.2.

The sessionKey is computed using the authValue from bind and an Empty Buffer in place of the salt
value.

sessionKey ≔ KDFa (sessionAlg, authValuebind, “ATH”, nonceTPM, nonceCaller, bits)
NOTE 2(20)

If handle references a TPM resource that has an EmptyAuth, the sessionKey is still computed.

When performing an HMAC for authorization, the HMAC key is calculated as follows:
When the session is an HMAC session
If the authorization is not for the entity to which the session is bound, the HMAC key is theconcatenation of the entity's authValue to the session's sessionKey (created at
TPM2_StartAuthSession() (see equation (21).

Page 110
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64(19)

Part 1: Architecture

Trusted Platform Module Library

If the authorization is for the entity to which the session is bound, the HMAC key is the session's
sessionKey (created at TPM2_StartAuthSession() (see equation (22)).
When the session is a policy session
If the session has isAuthValueNeeded SET (by TPM_PolicyAuthValue()), the HMAC key is theconcatenation of the entity's authValue to the session's sessionKey (see equation (21)).
If the session has isAuthValueNeeded CLEAR, the HMAC key is the session's sessionKey(created at TPM2_StartAuthSession() (see equation (22)).

authHMAC ≔ HMACsessionAlg (sessionKey || authValueentity) ,(pHash || nonceNewer || nonceOlder* || sessionAttributes))(21)

authHMAC ≔ HMACsessionAlg (sessionKey,(pHash || nonceNewer || nonceOlder* || sessionAttributes))(22)

NOTE 3

Binding to an entity different from the one being authorized is a way of adding entropy to the session
key. It is useful in cases where the entity being authorized has a low entropy authorization value.

The TPM is required to keep track of the entity to which the session is bound. This is nominallyaccomplished when the session is started by recording, in the session context, the Name of the bindentity. For an NV Index or persistent handle, the TPM is required to also record the authorization value
associated with the entity.
NOTE 4In the Part 4 reference implementation, the authorization value is combined with the Nameand stored in the SESSION→boundEntity member.

NOTE 5

Recording of the NV Index authorization is required to prevent an attacker from "squatting" on an
Index. This would be accomplished by creating an NV Index that has properties that are identical toan NV Index that is expected to be created, but with an authorizatio n value known to the attacker.
The attacker would then start an authorization session bound to the NV Index and delete the NV
Index. When the NV Index to be attacked is created, the attacker would have an authorization
session bound to an Index with the same Name and could access to the NV Index even though theactual authorization value is unknown.

On a command, the TPM will check to see if the authorization is being used for the entity to which it wasbound. If so, then the authValue of the bound entity is not used in the HMAC computation. The TPM willrecord the fact that the authValue was not used in the HMAC computation of the authorization and notinclude it in the HMAC computation on the response.
NOTE 6This allows the session to remain bound to an NV Index for the duration of the first command thatwrites to the Index even though the Name of the Index changes during the command processing.
The session will not be bound to the Index when the command completes. The session can continue
to be used, but it, in effect, is no longer bound because there is no longer a TPM entity with thecorrect Name.

For a persistent object, the authorization value is included so that authorization can be revoked. If theadministrator for a persistent object changes the authorization, sessions bound to the old authorization
should no longer be valid.
NOTE 7To change the authorization of a persistent object, TPM2_ObjectChangeAuth() would be called. It
would return a new sensitive area. The current persistent object would be deleted(TPM2_EvictControl()) and the object with the new authorization loaded (TPM2_Load()). Finally, theloaded object would be made persistent (TPM2_EvictControl()). It is only required that the old object
be deleted if the new object is to have the same handle or if it is desired to revoke the old
authorization.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 111
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The noDA attribute of the bind object is recorded in the session context. For a description of the rationale,see clause 19.8.7.
Table 19 — Format to Start Bound Session
Type

Name

Description

TPM_STtag

UINT32

commandSize

TPM_CC

commandCode

TPM_CC_StartAuthSession

TPMI_DH_OBJECT+

tpmKeyTPM_RH_NULL

TPMI_DH_ENTITY

bind

entity providing the authValue to which thesession is bound and not TPM_RH_NULL

TPM2B_NONCE

nonceCaller

initial nonceCaller, sets nonceTPM size forthe session

TPM2B_ENCRYPTED_SECRET encryptedSalt

00 0016

TPM_SEsessionTypeindicates the type of the session (HMAC,
policy, or trial)

TPMT_SYM_DEF+

symmetric

if the session is to be used for parameterencryption, set this to an algorithm and key
size

authHashhash algorithm to use for the session;required to be a hash algorithm
implemented on the TPM and not
TPM_ALG_NULL

TPMI_ALG_HASHPage 112
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Salted Session Key Generation
In this session key generation method used by TPM2_StartAuthSession(), bind is TPM_RH_NULL,
indicating that no entity is referenced to provide an authValue, but tpmKey is present and indicates a key
used to encrypt the salt value. The sessionKey is computed with an Empty Buffer in place of theauthValue.

sessionKey ≔ KDFa (sessionAlg, salt, “ATH”, nonceTPM, nonceCaller, bits)(23)

Because bind is TPM_RH_NULL, the session is not bound to any entity. When the session is used toaccess any entity, the HMAC will use the sessionKey and the authValue of that entity.

authHMAC ≔ HMACsessionAlg ((sessionKey || authValueentity),(pHash || nonceNewer || nonceOlder*|| sessionAttributes))(24)

Table 20 — Format to Start Salted Session
Type

Name

Description

TPM_STtag

UINT32

commandSize

TPM_CC

commandCode

TPM_CC_StartAuthSession

TPMI_DH_OBJECT

tpmKeyhandle of a loaded key used to encrypt salt

TPMI_DH_ENTITY+bind

TPM_RH_NULL

TPM2B_NONCE

nonceCaller

initial nonceCaller, sets nonceTPM size forthe session

TPM2B_ENCRYPTED_SECRET encryptedSalt

conveys a secret value used to generate
the sessionKey – method of conveying thisvalue is dependent on the type of tpmKey

TPM_SEsessionTypeindicates the type of the session (HMAC,
policy, or trial)

TPMT_SYM_DEF+

symmetric

if the session is to be used for parameterencryption, set this to an algorithm and key
size

authHashhash algorithm to use for the session;required to be a hash algorithm
implemented on the TPM and not
TPM_ALG_NULL

TPMI_ALG_HASH

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 113
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Salted and Bound Session Key Generation
This version of TPM2_StartAuthSession() creates a session that has properties that are similar to the
OSAP session type of TPM 1.2 but also allows salting. For this version of the command, bind is used toprovide an authValue, tpmKey encrypts the salt value and the sessionKey is computed using both.

sessionKey ≔ KDFa (sessionAlg,(authValuebind || salt), “ ATH ”, nonceTPM, nonceCaller, bits)(25)

If the session is an HMAC session:•

Because bind is present, the session is bound to that entity. That is, when the session is used toauthorize use of the bound entity, the HMAC will use sessionKey but not the authValue.

authHMAC ≔ HMACsessionAlg (sessionKey,(pHash || nonceNewer || nonceOlder* || sessionAttributes))(26)

If the session is a policy session:•

The session is not bound to that entity. That is, when the session is used to authorize use of any
entity, the HMAC (if required) will use the sessionKey and the authValue.

authHMAC ≔ HMACsessionAlg ((sessionKey || authValueentity),(pHash || nonceNewer || nonceOlder* || sessionAttributes))•(27)

The noDA attribute of the bind object is recorded in the session context. For a description of therationale, see clause 19.8.7.
Table 21 — Format to Start Salted and Bound Session
Type

Name

Description

TPM_STtag

UINT32

commandSize

TPM_CC

commandCode

TPM_CC_StartAuthSession

TPMI_DH_OBJECT+

tpmKeyhandle of a loaded key used to encrypt salt

TPMI_DH_ENTITY

bind

entity providing the authValue and to which
the session is bound

TPM2B_NONCE

nonceCaller

initial nonceCaller, sets nonceTPM size forthe session

TPM2B_ENCRYPTED_SECRET encryptedSalt

contains a secret value used to generate thesessionKey – method of encrypting thisvalue is dependent on the type of tpmKey

TPM_SEsessionTypeindicates the type of the session (HMAC,
policy, or trial)

TPMT_SYM_DEF+

symmetric

if the session is to be used for parameterencryption, set this to an algorithm and key
size

TPMI_ALG_HASH

authHashhash algorithm to use for the session;required to be a hash algorithm implemented
on the TPM and not TPM_ALG_NULL

Page 114
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Encryption of salt
19.6.13.1 Overview
The salt parameter for TPM2_StartAuthSession() is asymmetrically encrypted using the methods
described in this clause.
The value produced by the secret exchange process using salt should be the size of the digest producedby the authHash of the session. For ECC, the size of the seed is limited because it is an ECC point; but
for RSA, XOR, and AES, the size of salt can vary.
When the value of salt is determined, it is used in the computation of sessionKey as shown in equation(18).
19.6.13.2 Asymmetric Encryption of Salt
The methods of encrypting the salt and producing the session secret differ for each asymmetric algorithm.
The methods are described in the algorithm-specific annexes to this specification.
Caution on use of Unsalted Authorization Sessions
If an authValue has low entropy, confidentiality of the value may not be preserved if the authValue is usedin an unsalted authorization session. For an unbound, unsalted session, the HMAC computation for the
response from the TPM is:

authHMAC ≔ HMACsessionAlg (authValue,(rpHash || nonceTPM || nonceCaller || sessionAttributes))(28)

If an attacker can read the response from the TPM, then the only values unknown to the attacker are
authValue and nonceCaller. An attacker may be able to determine nonceCaller by reading the commandas it is sent to the TPM. If the attacker has all the variables but authValue, they could perform an "off-line"
attack on the authValue using trial versions of authValue until one is found that produces a matchingauthHMAC.
NOTE 1In this context, an "off-line" attack means that the attacker can perform computations that do not
involve the TPM meaning that the protections that the TPM provides against authValue attacks has
no effect.

It is important to note that this vulnerability only occurs if an attacker has access to both the command
and response of a successful command using the authValue. If a user has a password protecting a key
and the system is lost or stolen, the key is protected because the attacker will not be able to observe thelegitimate owner of the key perform a successful operation with the key.
For a bound session without salt, the attack is a bit more complicated. The HMAC computation for the
response is:authHMAC ≔ HMACsessionAlg ((sessionKey || authValueentity),(pHash || nonceNewer || nonceOlder || sessionAttributes))(29)

If the attacker observes a TPM2_StartAuthSession() command and response and the authValue for thebind entity has low entropy, then they would have all of the components of sessionKey except for theauthValue of the bind entity. Then, by observing another successful transaction, an attacker could know
everything but the two authValues and they could again perform an offline attack.
NOTE 2

If the successful operation is on the bind entity, then only one authValue is unknown.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 115
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

As with the unbound and unsalted session, the vulnerability for a bound session only occurs if theattacker is able to observe successful command response sequences.
Salting provides a mechanism to allow use of low entropy authValues and still maintain confidentiality forthe authValue. It is also possible to use a high entropy authValue to protect the confidentiality of a lowentropy value. For instance, if the bind entity authValue has high-entropy, then there would be greater
computational complexity in guessing sessionKey || authValueentity. Depending on the authValue and salt
sizes, a bound session could have a sessionKey that is as difficult to guess as does a salted session.
No HMAC Authorization
For a session-based authorization, both HMAC and policy, an authHMAC value is computed as shown inequation (17) and that value is used as hmac in an authorization or acknowledgement as shown in Table
14 and Table 15 respectively. If an authorization session is started with bind and tpmKey both set to
TPM_RH_NULL, then sessionKey in equation (17) will be an Empty Buffer. If the authValue in equation(17) is also an Empty Buffer, then the HMAC key will be an Empty Buffer. When this situation exists, thecaller has the option of either providing the results of the authHMAC computation, or not.
If authHMAC is provided, it will be computed as shown in equation (17) with an Empty Buffer as the
HMAC key and the TPM will validate that the value in hmac matches the internally calculated value.
If authHMAC is not provided, the size of hmac (see Table 14) will be zero and the TPM will accept thisvalue of hmac as providing valid authorization for the object.
For an HMAC session, authValue in equation (17) will only be an Empty Buffer if the authValue of theauthorized object is an EmptyAuth, the session is a bind session and the authorization is for the entity towhich the session is bound, or if the session is not an authorization session.
For a policy session, two situations will result in authValue being an Empty Buffer:1) the authValue of the authorized object is an EmptyAuth, or2) the policy does not use the authValue of the object (that is, the evaluated policy does not contain
TPM2_PolicyAuthValue())(see 19.7.7.6).
For these two cases, if sessionKey is an Empty Buffer, hmac is allowed to be either a valid authHMAC oran Empty Buffer. For a bound or salted policy session, sessionKey is not an Empty Buffer, and hmac
must be valid.
NOTE

A policy session that does not use TPM2_PolicyAuthValue() would use a bound or salted session ifthat session is also used for encryption.

For a policy session that contains TPM2_PolicyPassword(), the password takes precedence and must bepresent in hmac.
The TPM will use the same formulation in the response as was in the command. This is, if hmac was nonzero in the command, the TPM will compute authHMAC as shown in equation (17) and use the result as
hmac. If hmac was an Empty Buffer in the command, it will be an Empty Buffer in the response.
Authorization Selection Logic for Objects
Each object has two attributes in its public structure to indicate how use of the object is authorized.

Page 116
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

1) userWithAuth – If this attribute is SET, then USER role authorization for an object can be provided
with an HMAC session or a password. If this attribute is CLEAR, then the authValue cannot be used
for USER role authorization, meaning that authorization cannot be done using an HMAC session or apassword. USER role authorizations with a policy are always allowed regardless of the setting of this
attribute.
2) adminWithPolicy – If this attribute is SET, then ADMIN role authorization for an object can only beprovided with a policy session. If this attribute is CLEAR, then authorization can be provided with apolicy session, with an HMAC session, or with a password.
When authorization is with a policy session and ADMIN role authorization is being provided, thecommand code value of the policy session must match the command code for the command being
authorized.
For TPM_RH_OWNER, TPM_RH_ENDORSEMENT, and TPM_RH_PLATFORM); userWithAuth andadminWithPolicy are always SET.
For an NV Index, NV Index attributes (TPMA_NV) determine authorization selection.
NOTE

For TPM_RH_OWNER, TPM_RH_ENDORSEMENT, and TPM_RH_PLATFORM); userWithAuth andadminWithPolicy do not have to be implemented as separate attributes. The code can simply
assume that the attributes are SET and act accordingly.

Authorization Session Termination
The TPM will terminate a session (authorization or audit) and clear all associated context under thefollowing circumstances:•when TPM2_FlushContext() selects the session;•

if sessionAttributes.continueSession is CLEAR in the command, the TPM will CLEAR thecontinueSession flag in the response and perform TPM2_FlushContext() actions;

NOTE

When sessionAttributes.continueSession is CLEAR in the command but the command does not
return success, then the session is not terminated.

•on TPM Reset, all authorization sessions are terminated; and•on TPM Resume or TPM Restart, authorization sessions in TPM memory will be terminated but
sessions context saved off the TPM will remain active.

19.7

Enhanced Authorization
Introduction

Enhanced authorization is a TPM capability that allows entity-creators or administrators to require specifictests or actions to be performed before an action can be completed. The specific policy is encapsulated ina value called an authPolicy that is associated with an entity
When an HMAC session is used for authorization, the authValue of the entity is used to determine if theauthorization is valid. When a policy session is used for authorization, the authPolicy of the entity is used.
Many TPM entities have or can have an associated authPolicy. A policy defines the conditions for use ofan entity. For example,

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 117
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture•a policy can limit the use of a key unless selected PCR have specific values;•a policy cannot allow use of a key after a specific time;•a policy can require that authorization to change an NV Index be provided by two different entities; or•a policy can limit a particular signing key to attest to PCR values but not to certify another TPM key.

A policy can be arbitrarily complex. However, the policy is expressed as one (statistically unique) digest
called the authPolicy.
The digest representing a particular policy can be included in an Object or NV Index when the Object or
NV Index is created (the digest representing a policy is created using the methods described insubsequent parts of this clause). In order to use the Object or Index, a policy session is created and thenthe TPM is given a sequence of policy commands that modify the digest in the policy session. After
executing all of the commands of the policy, the TPM will have computed a digest value that ischaracteristic of the policy. The policy session is then used as an authorization session. If the digest
accumulated in the policy session matches the policyDigest of the entity (and certain other optional
conditions are true) then the command is authorized.
After a policy session is used for authorization, policySession→nonceTPM is changed to a new, random
value; policySession→startTime is set to the current time; and the other values of the policy session
context are initialized to the state they had when the session was first created by
TPM2_StartAuthSession() (see19.7.8).
The mechanisms of policy creation and evaluation are explained in the remainder of this clause
Policy Assertion
An assertion is a statement that something is true. In an authorization policy, an assertion is a statementof something that must be true before the policy is satisfied. For example, an assertion can be that a setof PCR must have specific values to allow an object to be authorized for use in a specific command. The
list of all policy assertions defined by this specification is in 19.7.7.6.
A combination of one or more assertions is used to construct an authorization policy.
Policy AND
A policy can be expressed in an equation as a set of assertions that must all be satisfied before the policy
is valid. For example, a policy that requires that 4 assertions be true could be written as:
a&b&c&d
A possible implementation of the policy logic would be to have all the assertions evaluated at the sametime to determine if the policy is satisfied. This approach would require that the TPM resources scale with
the number of assertions that would need to be evaluated for the policy.
The alternative use in the TPM is to evaluate the expression one assertion at a time with each assertion
ANDed with the results of the previous evaluation.
(((1 & a) & b) & c) & d
The (1 & a) term means that assertion a is ANDed with an initial TRUE. This allows each assertion to bejust the AND of a new assertion with the results of the previous assertion evaluation. A pictorial
representation of the policy evaluation is:Page 118
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

b

a

d

c

1

Any number of assertions can be combined in this way using a fixed set of TPM resources.
The logic of a TPM policy cannot actually be expressed as a simple 1 or 0. For the policy to be valid, notonly does it need to evaluate to "TRUE", but it also has to be the correct policy. For example, these twopolicies can both evaluate to the same logic value (TRUE), but they do not represent the same policies.

b

a
1

y

x
1

So that it can differentiate (a & b) from (x & y), the TPM will update a running digest value for eachassertion that is added to the policy. The final digest value indicates the policy that was evaluated.
The running digest value is called the policyDigest. The policyDigest is initialized to a Zero Digest (0…0)
when the policy session is started (TPM2_StartAuthSession()). Then, as each policy assertion isevaluated, the policyDigest is updated.

policyDigestnew := H(policyDigestold || PolicyAssertion)
NOTE 1This is essentially an Extend operation.

The policyDigest will only be updated if a policy assertion is valid (TRUE) (see 19.7.10 for exception
relating to trial policies). This gives an alternative possibility for interpreting the output of one of the policy
AND gates. Instead of simply being a 1 (TRUE) or 0 (FALSE), the output of the gate is current value ofthe policyDigest. Using this perspective, the four-term policy becomes:

a

d

c

b

0...0
D1

Family “2.0”Level 00 Revision 01.64

D2

D3

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

D4Page 119
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

where
0…0

the initial value of the policy digest

D1

H(0…0 || a)

D2

H(D1 || b)

D3

H(D2 || c)

D4

H(D3 || d)

NOTE 2In these illustrations, the parameters for the Extend operations are simple parameters (" a", "b", etc.).
The actual parameters for the Extend are more complex but including the details in the illu strations
would add complexity without adding clarity.

Policy OR
If the only type of policy assertion was an AND, then the policies that could be evaluated by the TPM
would be of limited value. To make the policies more flexible, an OR policy assertion is defined. As with alogic OR gate, the OR policy assertion will be valid if any of the inputs is valid.
A simple policy using an OR might be written as:(a & b) | (x & y)or as:(((0…0) & a) & b) | (((0…0) & x) & y)
Evaluating the AND branches individually, the left side evaluates to:

Dleft ≔ H(H(0…0 || a) || b)and the right side to:Dright ≔ H(H(0…0 || x) || y)Then, the output from a 2-input policy OR operation will be defined to bepolicyDigestnew ≔ H(Dleft || Dright)
Notice that the OR operation replaces the policyDigest with a new value instead of Extending it as is donein an AND operation.
Pictorially, a policy with an OR is:

Page 120
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Dleft
b

a

DOR

0...0
y

x
0...0

DrightThe TPM processes the OR by comparing the current value of policyDigest with a list of digest values
provided by the caller. If policyDigest is on the list, then the TPM will digest the concatenation of all of thedigests in the list. For example, to perform the OR operation above, assume that the TPM has processed(a & b) producing Dleft. Then the TPM would be given a list of digests (Dleft, Dright). Because thepolicyDigest is on the list, the TPM computes DOR ≔ H(Dleft | Dright) and replaces policyDigest. Note that if
the TPM had processed (c & d) to compute Dright and was then given the same list of digests (Dleft, Dright),
the resulting policyDigest would be the same.
When processing a policy that has an OR, only one branch of the policy needs to be evaluated. For
example, if C and D assertions were valid, then only the right branch would need to be evaluated.

Dleft is not computedA

B(Dleft, Dright)

0...0

C
0...0

D
Dright

The list given to the TPM for a TPM2_PolicyOR() is limited to 8 digests. However, the effective size of thelist can be expanded indefinitely by using cascading OR. Figure 15 illustrates one of the many ways toconstruct a 12 input OR.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 121
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

DOR.A(DOR.A, DOR.B, DOR.C)

DOR.B

DOR.C

Figure 15 — A 12-input OR Policy
When the OR list can contain 8 digests, 64 different branches can be ORed in just two levels.
The result of an OR operation can be an input to an AND assertion allowing construction of arbitrarily
complex policies.
Order of Evaluation
Because the TPM uses digests, the order of evaluations is important. For policy evaluation, (A & B) is not
the same as (B & A). In addition, when performing an OR operation, the same list of digests (samenumber in the same order) must be given to the TPM each time. The list (Dleft, Dright) will not give the same
result as (Dright, Dleft) or (Dleft, Dright, Dother).
Policy Session Creation
TPM2_StartAuthSession(sessionType = TPM_SE_POLICY) is used to start an authorization session. The
authorization session can use any of the four options for tpmKey and bind.
NOTE 1

A policy session does not maintain a binding with a specific object. The bind paramete r is used only
for session key creation. This allows the context space of the session that is used for the binding
value to be dedicated to other policy parameters.

The most typical use of a policy session will be with tpmKey and bind both set to TPM_RH_NULL. When
this option is selected, an HMAC computation might not be performed when the policy session is used
and the session nonce and auth values can be Empty Buffers (see TPM 2.0 Part 3,
TPM2_PolicyAuthValue).
NOTE 2

When the session is created, nonceCaller still needs to be provided and its size is required to meetthe minimum requirements of the command.

When the authorization session is to be used to authorize a command that has an encrypted command or
response parameter, then either tpmKey or bind should be used in the TPM2_StartAuthSession() thatstarts the session so that a secure sessionKey is created.

Page 122
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Policy Assertions (Policy Commands)
19.7.7.1

Introduction

In TPM 2.0 Part 3 of the specification the set of policy assertions are the commands with names of theform TPM2_Policyxxx() where "xxx" is an indicator of the type of policy assertion. For example,
TPM2_PolicySigned() is a policy assertion that an authorization was signed by a specific entity; andTPM2_PolicyPCR() is an assertion that a selected set of PCR have a specific value.
Normally, each policy command will cause the policyDigest to be changed in a different way which is why
they are different commands. In some cases, the policy command will also cause other changes to thepolicy session context. For example, TPM2_PolicyLocality() modifies the policy state that indicates the
locality that is allowed when the policy session is used for authorization. TPM2_PolicyCommandCode()changes the policy state so that the policy can only be used to authorize a specific command.
The details of the policyDigest computation performed by each policy command are provided in the
General Description clause of each command found in TPM 2.0 Part 3. The description also indicates thepolicy state that is modified.
The assertions fall into three different groups: immediate, deferred, and combined.
19.7.7.2

Immediate Assertions

For an immediate assertion, the input values are validated and the TPM will return a failure and not
update the policyDigest if the assertion is not valid. An example of an immediate assertion is
TPM2_PolicyNV(). For this assertion, the TPM validates the logical or arithmetic relationship between an
input value and an NV Index. If the specified relationship is not valid, the TPM returns an error and thepolicyDigest is not modified. If the relationship is valid, then the policyDigest is updated with the Index
Name and the relationship that was validated.
19.7.7.3

Deferred Assertions

For a deferred assertion, the TPM will update the policyDigest based on the input values and record
some parameters in the policy session's context. These parameters are checked when the policy is used
for authorization. An example of a deferred assertion is TPM2_PolicyCommandCode(). For this assertion,
the input is a TPM command code. The policyDigest will be updated to record the fact that the
TPM2_PolicyCommandCode() was executed and the commandCode value that was specified. The TPM
also directly records the commandCode parameter in the policy session context. When the policy is used
for authorization, the TPM will verify that the command being authorized is the same as the command in
the policy and the authorization (and command) will fail if they are not the same.
19.7.7.4

Combined Assertions

For a combined assertion, the TPM will validate some condition of the input and record or modify someparameters in the policy session's context. An example of a combined assertion is TPM2_PolicySigned().
For this assertion type, the TPM validates that the parameters of the command have been signed by theindicated key. If so, it will update the policy session context based on the input parameters. One of thecontext values that can be updated is the cpHash of the session. If the cpHash of the authorizedcommand is not the same as the authorized cpHash then the command will not be authorized.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 123
December 24, 2020

Trusted Platform Module Library
19.7.7.5

Part 1: Architecture

Repetition of Assertions

In general, any policy assertion can occur multiple times within a policy as long as the assertion iscompatible with previous assertions. An example of an incompatible set of assertions is two occurrencesof TPM2_PolicyCommandCode() that indicate different command codes.
The TPM will return an error if an assertion is incompatible with a previous assertion. It is possible that thefailed assertion is incompatible with an assertion of a different type. For example, a
TPM2_PolicyCpHash() can be incompatible with a TPM2_PolicySigned(). If they indicate different valuesof policySession→cpHash, then the TPM will return an error.
NOTE

19.7.7.6

When referring to an element of the policy context, the notation policySession→element is used todenote a particular member of the policy context.

List of Assertions

The assertions listed in this clause will all update the policyDigest of the policy session being operated on
if the assertion condition is met. They can also cause a change to other policy session, context values(the list of policy session context values is in 19.7.8) as indicated in the brief description for eachassertion.

Page 124
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library•

TPM2_PolicyAuthorize() – valid if policySession→policyDigest has the value authorized by theselected key. This is an immediate assertion and is described in more detail in clause 19.7.11.

•

TPM2_PolicyAuthorizeNV() – valid if the specified NV Index contains a hash algorithm identifier anda digest value that match the hash algorithm and policySession→policyDigest. This immediate
assertion changes policySession->policyDigest and is described in more detail in clause 19.7.11.

•

TPM2_PolicyAuthValue() – valid if authValue of the authorized entity is provided when the policy
sessionisusedforauthorization.
This
deferred
assertionwill
SET
policySession→isAuthValueNeeded. When the policy is used for authorization, the TPM will checkpolicySession→isAuthValueNeeded. If it is SET, then the TPM performs an HMAC check on thesession as if it were an HMAC session. This HMAC validation will only succeed if the caller is able toprove knowledge of the entity's authValue by computing the correct HMAC.

•

TPM2_PolicyCommandCode() – valid when the authorized command has the specified commandcode. This deferred assertion sets policySession→commandCode.

•

TPM2_PolicyCounterTimer() – valid when a portion of the TPM’s TPMS_TIME_INFO structure has
the desired numerical relationship with another value. This is an immediate assertion. If the selected
subset of the TPM's TPMS_TIME_INFO structure does not have the specified relationship with the
input data, then the TPM will return an error and not change the policyDigest (see 36.1 for use
cases).

•

TPM2_PolicyCpHash() – valid if the cpHash of the authorized command has a specific value. Thisdeferred assertion modifies policySession→cpHash.

•

TPM2_PolicyDuplicationSelect() – valid if the handles of the authorized command reference
specific objects and the command code is TPM2_Duplicate(). This deferred assertion modifies
policySession→cpHash and policySession→commandCode.

•

TPM2_PolicyLocality() – valid if the command being authorized is being executed at one of theallowed localities. This is a deferred assertion that modifies policySession→locality. For localities 0-4,
the input locality parameter is a bit field that indicates the allowed localities. If an execution of thisassertion would result in no locality being allowed, then the TPM will return an error. For extended
localities, policySession→locality is set to the locality parameter of the command if thepolicySession→locality was not previously set. Otherwise, the locality parameter is required to be thesame as the current value of policySession→locality.

•

TPM2_PolicyNameHash() – valid if the handles of the authorized command reference specificobjects. This deferred assertion modifies policySession→cpHash.

•

TPM2_PolicyNV() – valid if the contents of NV have the desired relationship with another value. Thisis an immediate assertion. If the selected portion of the NV Index does not have the specified
relationship with the input data, then the TPM will return an error and not change the policyDigest.

•

TPM2_PolicyNvWritten() – valid when the TPMA_NV_WRITTEN attribute of the specified NV Index
has the desired value. This deferred assertion sets policySession→checkNvWritten and the state ofpolicySession→nvWrittenState.

•

TPM2_PolicyOR() – valid if policySession→policyDigest is on a list of digests. This is an immediate
assertion. If policySession→policyDigest is not on the list of digests, then TPM returns an error.
Otherwise, policySession→policyDigest is replaced with the digest of the list.

•

TPM2_PolicyPassword() – valid if the authValue of the authorized entity is provided when thesessionisusedforauthorization.
This
deferred
assertionwill
SET
policySession→isPasswordNeeded. When the policy is used for authorization, the TPM will checkpolicySession→isPasswordNeeded. If it is SET, then the TPM performs a password check on thesession as if it were a password session. . This password validation will only succeed if the caller isable to prove knowledge of the entity's authValue by providing the correct value as the password.
NOTE 1

A session can use TPM2_PolicyAuthValue() and TPM2_PolicyPassword() interchangeably. If
TPM2_PolicyAuthValue() and TPM2_Policy Password() are both us ed, then TPM will performthe check according to the last one used in the policy.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 125
December 24, 2020

Trusted Platform Module Library•Part 1: Architecture

TPM2_PolicyPCR() – valid if the selected PCR have the desired value. This assertion can be either acombined or a deferred assertion. If the caller provides a digest, the TPM validates that the current
values of the PCR match the input value and return an error (TPM_RC_VALUE) if not. If thiscommand completes successfully, the policyDigest will have been updated with the digest of theselected PCR. The TPM will also record that the PCR have been checked. If the PCR are changed
after they are checked but before the policy is used for authorization, then the policy will fail.
NOTE 2

The reference implementation provides this assurance by maintaining a PCR update counterthat increments each time the PCR are modified. The update counter is saved in the policy
session context. If the update counter does not change between the check of the PCR and theuse of the policy session for authorization, then the PCR are the same.

•

TPM2_PolicyPhysicalPresence() – valid if the physical presence is asserted when the authorizedcommand is executed. This deferred assertion sets policySession→isPPRequired.

•

TPM2_PolicySecret() – valid if the knowledge of a secret value is provided. This assertion is animmediate and possibly also a deferred assertion. Based on the input parameters, this command canmodify policySession→cpHash and policySession→timeout.
NOTE 3The secret value will be the authValue of some TPM entity.

•

TPM2_PolicySigned() – valid if the parameters are properly signed. This assertion is an immediate
and possibly also a deferred assertion. Based on the input parameters, this command can modify
policySession→cpHash and policySession→timeout.

•

TPM2_PolicyTemplate() – valid if the hash of the inPublic parameter of TPM2_Create(),
TPM2_CreatePrimary(), or TPM2_CreateLoaded() matches the templateHash in this command. Thisdeferred assertion sets policySession→cpHash.

•

TPM2_PolicyTicket() – valid if the ticket is valid. This assertion is an immediate and possibly also adeferred assertion. Based on the input parameters, this command can modify policySession→cpHashand policySession→timeout.
Policy Session Context Values

A policy session context contains the state and tracking information for evaluation of a policy. The context
values are set to their default values when the session is created and again each time the session is
successfully used to authorize a command.
The values can be changed by a policy assertion. The policy assertions are listed in 19.7.7.6 with anindication of the policy session context values that they modify. The policy session context values aredescribed further here.
•

policyDigest – digest that is updated by each assertion. The default value for policyDigest is a Zero
Digest (a buffer with a length equal to the digest size of the hash algorithm with all octets having avalue of zero).
•

nonceTPM – set from the RNG and is sized according to the size of nonceCaller in
TPM2_StartAuthSession(). This value does not change during the policy evaluation. However, it
does change when the policy session is used for authorization.

•

cpHash – set by an assertion that limits the authorization to a specific set of commandparameters. If an assertion would set policySession→cpHash and a previous assertion has set
policySession→cpHash to a different value, then the assertion will fail. The default forpolicySession→cpHash is an Empty Buffer.

•

nameHash – set by TPM2_PolicyNameHash() and indicates the combination of Name values for
a command. This context parameter occupies the same location as policySession→cpHash. If an
assertion would set policySession→nameHash and a previous assertion has set cpHash to adifferent value, then the assertion will fail. The default for policySession→nameHash is an Empty
Buffer.

Page 126
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library•

templateHash – set by TPM2_PolicyTemplate() and binds the policy to a specific creation
template. This context parameter occupies the same location as policySession→cpHash. If an
assertion would set policySession→templateHash and a previous assertion has set cpHash to adifferent value, then the assertion will fail. The default for policySession→templateHash is an
Empty Buffer.

•boundEntity – set by TPM2_StartAuthSession() to track the entity to which the session is bound.
This context parameter occupies the same location as policySession→cpHash. If an assertion
would set policySession→boundEntity and a previous assertion has set cpHash to a different
value, then the assertion will fail. The default for policySession→boundEntity is an Empty Buffer.

•

startTime – set to TPMS_TIME_INFO.clockInfo.clock when policySession→nonceTPM changes.
No assertion changes this value. It is updated to the current value of clock by
TPM2_StartAuthSession() and when the session is used for authorization.

•

timeout – the time when the policy session expires. Its default setting is an implementationspecific value corresponding to “never expires.” This value is updated if an assertion has a nonzero expiration time that is sooner than the current setting of policySession→timeOut. An
assertion can only decrease the value of policySession→timeout.

•commandCode – set by an assertion that limits the policy to a specific command but does not
limit the command parameters (TPM2_PolicyCpHash() limits the command and its parameters). If
an assertion sets policySession→commandCode and a previous assertion has set
policySession→commandCode to a different value, then the TPM will return an error. The default
for policySession→commandCode is an implementation-specific value that indicates that it has
not been set.

•

pcrUpdateCounter – set by TPM2_PolicyPCR(). The TPM maintains a pcrUpdateCounter that isincremented each time a PCR changes (with a few exceptions as described in clause 17.9).
When it executes TPM2_PolicyPCR(), the TPM will copy pcrUpdateCounter topolicySession→pcrUpdateCounter. When the policy session is used for authorization, the TPM
will verify that policySession→pcrUpdateCounter matches pcrUpdateCounter. A match provides
assurance that the PCR values still match the values evaluated by TPM2_PolicyPCR().

•

commandLocality – indicates the locality required for the command being authorized by thepolicy. The default for policySession→commandLocality is any locality. Each locality that is notenabled in TPM2_PolicyLocality(locality) is disabled in policySession→commandLocality. If theresult of this operation would result in there being no locality at which the policy would be valid,
the TPM will return an error and not change policySession→commandLocality. If
commandLocality is set to an extended locality (greater than 31), then the locality cannot bechange by subsequent TPM2_PolicyLocality().

•

isPPRequired – SET by TPM2_PolicyPhysicalPresence() to indicate that presence is required to
be asserted when authorized command is executed. The default value is CLEAR.

•

isAuthValueNeeded – SET by TPM2_PolicyAuthValue()to indicate that the authValue of theauthorized entity will need to be provided when the policy session is used for authorization. The
authValue is required to be included in an HMAC. The default value is CLEAR. It will also be
CLEAR by TPM2_PolicyPassword()•

isPasswordNeeded – SET by TPM2_PolicyPassword() to indicate that the authValue of theauthorized entity will need to be provided when the policy session is used for authorization. The
authValue is required to be provided as a password. The default value is CLEAR. It will also be
CLEAR by TPM2_PolicyAuthValue().

•

isTrialPolicy – SET to indicate that policySession→policyDigest is to be updated even if theassertion is not valid. The session cannot be used for authorization.

•

checkNvWritten – SET to indicate that the TPMA_NV_WRITTEN attribute of the authorized NV
Index must be compared with nvWrittenState.

•

nvWrittenState – SET when TPMA_NV_WRITTEN is required to be SET in the NV Index being
authorized. This attribute has no meaning when checkNvWritten is not SET.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 127
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Policy Example
In TPM 1.2, the basic policy for use of a key was limited to a combination of an authorization value and
PCR state. This policy was built in to each key. In TPM 2.0 there is no built-in policy. A TPM 2.0 policythat is the same as the TPM 1.2 policy is:
TPM2_PolicyPCR() & TPM2_PolicyAuthValue()
Note

This policy could also be written as
TPM2_PolicyAuthValue() & TPM2_PolicyPCR()
This policy would have a different policyDigest because the order of evaluation affects the digest.

To associate this policy with a key, evaluate the policy to determine the policyDigest that it would
generate. Then create the key with this digest as the authPolicy and CLEAR the userWithAuth attribute.
When userWithAuth is CLEAR, USER mode actions for the key will require use of the key's authPolicy.
Trial Policy
The policy evaluation to determine the value for the authPolicy can be done in software that does thesame policyDigest computation as the TPM. Alternatively, a trial policy session can be used. A trial policy
session is created and used in a sequence of policy commands just like a normal policy session. The
difference is, in a trial policy, a policy assertion is always assumed to be TRUE and the policyDigest
updated accordingly. The policyDigest value computed in the trial policy can be read from the TPM andused as an object's authPolicy. Since the assertions in the trial policy do not need to be valid, the trial
session cannot be used for authorization.
Modification of Policies
Some policies, such as those associated with the hierarchies, can be altered directly by changing the
authPolicy value. Policies associated with Objects and NV Indices cannot be directly altered. The reason
that these policies cannot be altered is that the policy can affect the trust that someone places in the useof that entity. For example, a key can only be trusted if it can only be used when the PCR have a specific
set of values. If the policy could be changed, then the PCR check could be removed, and the key would
no longer be trusted. There would be no way for the trusting entity to know if a version of the key exists
where the PCR are not checked.
Even though there is no way to directly change a policy, it can be indirectly changed. The command thatallows this is TPM2_PolicyAuthorize(). When this command is included in a policy, it allows a designatedentity (an "authority") to authorize a policyDigest to be included in the policy. This is best described withan example.
It is common to seal a data value to PCR values so that the data value can only be recovered if theplatform has booted in a known way. A problem with this is that if there is a BIOS update, the PCR willchange, and the sealed data value can no longer be retrieved, and some kind of recovery process isnecessary. The inability of a policy to accommodate changes to PCR values is called "brittleness". Thatterm suggests that the policy is easy to break (make unusable). This brittleness could be a problem with
TPM 2.0 if the policy was completely fixed.
Figure 16 illustrates the use of TPM2_PolicyAuthorize() to implement a flexible policy. This assertion
evaluation checks to see if the current policyDigest is authorized by a signing key – that is, did anauthorizing entity sign a digest indicating that a specific value of policyDigest represents a known set of
PCR values. If the policyDigest value was signed, then policyDigest is replaced by a digest of the Nameof the key that was used for authorization and policyRef (see 19.7.12).
Page 128
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

NOTE 1Other information is included with the Name of the key when the new policyDigest is computed inorder to indicate that the Name was included as the result of a TPM2_PolicyAuthorized() op eration.

NOTE 2This example purposefully avoids using terms that would indicate that the signing entity does
anything other than indicate that the PCR values are the expected values. In particular, the signing
entity does not have to certify that the PCR values are safe. The signing entity can provide otherassurances but, in the case of PCR, it is not necessary to warrant anything other than that the PCRvalues are expected.

An example of how of this assertion type can be used to avoid PCR brittleness is shown in Figure 16.
This shows the example policy in 19.7.9 but with the ability to satisfy the policy with different PCR values.
NOTE 3

The actual authPolicy in the authorized entity would contain (PolicyAuthorize & PolicyAuthValue).

As shown, a PolicyPCR assertion is followed by PolicyAuthorize(). If there is an authorization signed by
KEY for the current policyDIgest (in this case, DPCR.A), then the result of the PolicyAuthorize() will be DKEY.
This is the same output that would be produced if the input to the PolicyAuthorize() were DPCR.B and there
was an authorization sighed by KEY for DPCR.B. That is, in TPM2_PolicyAuthorize(), if the key authorized
the current policyDigest, policyDigest reset to a Zero Digest and then extended with the Name of the key.
The policyDigest value Dfinal no longer reflects the previous value (DPCR.A or DPCR.B).

PCR have value “A”

PolicyAuthorize(DPCR.A, KEY )PolicyAuthValue

PolicyPCR(A)0...0
DPCR.A

PCR have value “B”

DKEY

DfinalPolicyAuthorize(DPCR.B, KEY )PolicyAuthValue

PolicyPCR(B)

0...0
DPCR.B

DKEY

DfinalFigure 16 — Use of TPM2_PolicyAuthorize() to Avoid PCR BrittlenessIn the case of a BIOS update that changes PCR, the platform OEM could provide a signature for the PCRvalues created by the new BIOS. Now, if the policy of the sealed data includes a TPM2_PolicyAuthorize()from the OEM, then the BIOS can be updated, and no recovery process would be needed to deal with the
new PCR values. That is, with either authorized set of PCR, DKEY and Dfinal will be the same, even though
DPCR.A and DPCR.B are different.
An additional way to indirectly modify a policy uses TPM2_PolicyAuthorizeNV(). This command indicates
an NV Index location of a policy that will be effective for an entity, the effective policy being the policy
digest stored in the data at that NV index. When a policy is formed using TPM2_PolicyAuthorizeNV(), the
NV Index Name is specified. When the entity is to be authorized, the policy stored in the data of thenamed index is satisfied, and then TPM2_PolicyAuthorizeNV() is executed. If the policy stored in thatindex matches the policySession->policyDigest, then the policySession->policyDigest is replaced withresults of first setting the policySession->policyDigest to the Zero Digest, and then extending it with thecommand code concatenated with the name of the NV index, which will contain the modified policy. The
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 129
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

main difference between this command and TPM2_PolicyAuthorize() is that multiple policies can satisfy
TPM2_PolicyAuthorize(), as long as they are all signed with the appropriate key. Only the policy that iscurrently stored in the NV index can satisfy TPM2_PolicyAuthorizeNV().
TPM2_PolicySigned(), TPM2_PolicySecret(), and TPM2_PolicyTicket()
The set of assertions discussed in this clause have properties that enable a number of authorization
scenarios. Among these are:•the ability to grant an authorization that can persist for a specific amount of time (because in many
protocols, access to a resource (such as, a network) is granted for some time interval); and•the ability to associate an authorization with a policy of the authorizing entity (because in many
instances, the authorizing entity can use the same key or secret for different purposes).

TPM2_PolicySigned() and TPM2_PolicySecret() convey an authorization by signing a set of parametersthat indicate the nature of the authorization. With TPM2_PolicySigned() the signature is with a key value(symmetric or asymmetric) and with TPM2_PolicySecret() the signature is with an HMAC using an
authValue in the HMAC key.
The policy assertions of TPM2_PolicySigned() and TPM2_PolicySecret() can be time limited. When apolicy’s authorization is time limited, it expires (is no longer valid) when TPM Time is greater than theindicated value for the authorization. An expiration time can be expressed in two ways. A timeout is anabsolute value of Time. An expiration value is a relative value in seconds from the start Time of the policy
session to which the authorization applies.
Both TPM2_PolicySigned() and TPM2_PolicySecret() can produce tickets that enable authorizations to
be used and reused over a period of time and in different policy sessions. These tickets are used in
TPM2_PolicyTicket().
These three commands have several input parameters in common:•

nonceTPM – the value returned by TPM2_StartAuthSession() or when a session is used for an
authorization. It is used to limit the use of a policy assertion to a specific policy session. If a policy
command includes a nonceTPM, then the TPM will return an error if it does not matchpolicySession→nonceTPM.

•

cpHashA – if the caller chooses to limit the authorization to a specific command and commandparameters, they would include this value in the signed data structure. Use of this parameter allows
the caller to provide an authorization that is similar to the HMAC authorization. That type of
authorization is only valid for a specific command and set of command parameters. If this parameter
is not part of the signed authorization, then this parameter should be set to the Empty Buffer.

•

policyRef – in some circumstances, it is desirable to have an authorization convey some information
relating to the authorizing entity. For example, a fingerprint reader can have a signing key that it uses
to verify when it has recognized a fingerprint regardless of whose fingerprint it might be. This type of
authorization would be difficult to use if it were not possible to indicate whose fingerprint wasscanned. The policyRef parameter would allow the fingerprint reader to provide this indication. The
TPM includes this value in the policyDigest. In the example of the fingerprint reader, this would meanthat the policyDigest would only have the correct value if the fingerprint reader scanned a finger fromthe correct person. If this parameter is not part of the signed authorization, then this parameter should
be an Empty Buffer.
NOTE 1

Because TPM2_PolicySigned() does not include the cpHashA and policyRef size in the aHash
calculation, it is recommended that the size of policyRef not be the same size as that of the entity
Name algorithm.

Page 130
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library•

expiration this parameter is used to place a time limit on an authorization. It is either the number of
seconds from the last time that the nonceTPM of a policy session was changed, or the value of Timeafter which a policy assertion is no longer valid.

•timeout – this indicates the value of Time after which a policy assertion is no longer valid.

If a TPM2_PolicySigned() or TPM2_PolicySecret() has a non-zero expiration parameter:•

If nonceTPM is not included, expiration is a timeout.

•

If expiration is a negative number, a ticket will be produced

NOTE 2

For TPM2_PolicySecret(), if authHandle references a PIN Pass Index, then no ticket will be
produced even if expiration is negative. This prevents use of a ticket to bypass the limit count on an
PIN Pass Index.

When a policy session is started, a nonceTPM is generated and the current value of Time is copied topolicySession→startTime. When a policy assertion includes a non-zero expiration and a nonceTPM, thenpolicySession→startTime is added to the absolute value of expiration to determine the timeout for thepolicy assertion. If a policy assertion includes a non-zero value in its expiration parameter but nononceTPM, then the expiration parameter is used directly as a timeout
When an assertion produces a timeout, the timeout value is placed in policySession→timeout. If
policySession→timeout has previously been set, then it will be updated with the lesser of timeout andpolicySession→timeout.
When Time has a greater value than policySession→timeout, the policy session expires and cannot be
used for authorization. If the authorization used a timeout (no nonceTPM), then the authorization will also
expire on the next TPM Reset.
NOTE 3A policy assertion includes an expiration when the expiration parameter is non-zero. A policy
assertion includes a nonceTPM when its nonceTPM parameter is not the Empty Buffer.

NOTE 4

expiration can need to be converted to milliseconds before being added to policySession→startTime.

NOTE 5

When an expiration parameter is used directly as a timeout, expiration is the value of Time inseconds when the assertion expires. When an assertion contains a timeout parameter (only in
TPM2_PolicyTicket()), timeout is an implementation-dependent value.

A ticket contains a digest of the command parameters of the assertion along with a ticket timeout. As longas a ticket has not expired, its effect on a policySession→policyDigest and policySession→timeout will be
the same as the TPM2_PolicySigned() or TPM2_PolicySecret() command that generated the ticket. For
example, one can use a TPM2_PolicySigned() command with an expiration of -3600 (the negative of thenumber of seconds in an hour) to return a ticket. For the next hour, that ticket can be used with
TPM2_PolicyTicket() to grant whatever other permissions were approved by the TPM2_PolicySigned()command.
When the TPM is not able to report the passage of time (Time does not advance), accurate timing ofassertions is not possible. To prevent having a timed assertion persist past the intended timeout, a TPM
is required to invalidate any time based assertion that was created before a discontinuity in the TPM’s
measurement of time. Such a discontinuity can occur when Time does not advance or when Time isreset. This requirement is met by having a number (a counter or a nonce) that changes each time that
there is a time discontinuity (an epoch) and by including timeEpoch in the computation of time-based
assertions. This implies that each policy session will need to:

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 131
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture•record timeEpoch when the session is created (in policySession→timeEpoch);•validate that the timeEpoch associated with a time-limited assertion is the same aspolicySession→timeEpoch before the assertion is accepted; and•when a time-limited policy is used for authorization, verify that the current TPM timeEpoch matches
policySession→timeEpoch.

If a counter is used for timeEpoch, it needs to be saved in NV memory whenever it changes. If thenumber used for timeEpoch is a nonce, it can be kept in RAM and changed on each time discontinuity.
NOTE 6

A timeEpoch nonce needs to be large enough that a replay is infeasible. That is, a ticket issued witha given nonce will not be useable after a future power cycle because the nonce values happen to
match. In the context of a specific ticket, a nonce collision is not a “birthday problem” as the nonce
has to match exactly rather than being one of a group of values that are equivalent.

Use of TPM for authPolicy Computation
To use a policy for authorization for an object or NV Index, the creator of an object or NV Index isrequired to know, at the time of creation of the Object or NV Index, the digest of the policy. The
computation of this policy requires duplication of the steps that would be performed by the TPM when it
evaluates the policy and updates the accumulated policyDigest of the session.
This computation can be done by software but would require that the policy update process for eachcommand be replicated by software. As an alternative, the TPM can be used to perform the computation.
To use the TPM, a policy session is created, and various policy commands are sent to the TPM as if thepolicy were being evaluated in order to authorize an action. TPM2_PolicyGetDigest() can then be used toread the final policyDigest from the TPM. That policyDigest value can then be used as the authPolicy
parameter in a new Object/NV Index.
NOTE

There is no requirement that the authPolicy for each Object or NV Index be unique.

If the policy is complex and uses TPM2_PolicyOR(), it will be necessary to compute multiple policyDigest
values. The same policy session can be used for all of the computations by using TPM2_PolicyRestart()
after the policyDigest for a branch is computed. When the last branch is computed, it can be used in a
TPM2_PolicyOR that is constructed from the previously computed values.
TPM2_PolicyGetDigest() could also be used to help validate the software that is implementing the digest
computation. The value computed by the TPM can be compared to the value computed by the software
library to ensure that they are the same. If desired, TPM2_PolicyGetDigest() can be called after eachpolicy command.
Trial Policy Session
If a policy requires a signed (symmetric or asymmetric) authorization for an action, that authorization
cannot be available at the time that the Object/NV Index is created, and, in fact, the authorizing entity
might not be willing or able to provide the necessary authorization at the time of creation.
EXAMPLE 1

If the Object is to have a duplication authorization, the duplication authority cannot provide theauthorization for the duplication when the Object is created. If they did, then the migration policy
could be computed; the policyDigest of the session read and placed in a new Object, andimmediately used for duplication of the Object. The duplication authority cannot want to allow the
duplication at that time.

The TPM provides a special type of policy session to be used for the purpose of computing the policy
without enabling the use of the policy. When a session is created by TPM2_StartAuthSession(policyType

Page 132
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library= TPM_SE_TRIAL), a policy session is created that cannot be used for authorization. Since it cannot be
used for authorization, authorizations are not needed in the computation of the policy.
EXAMPLE 2

If TPM2_PolicySigned() is called to update the digest of a trial policy session, the signature is not
validated but the policyDigest is updated as if a correct signature was provided.

Use of TPM2_PolicySigned() and TPM2_PolicySecret() without nonceTPM
The primary purpose of including nonceTPM in TPM2_PolicySigned() and TPM2_PolicySecret()is to restrict the use of the policy assertion to a specific policy session so that the assertion can
only be used once.
nonceTPM serves a different purpose when the assertion is structured so that a ticket i s
produced. In that case, the intent is that the assertion can apply to more than one policy session,
so nonceTPM serves a different purpose – to associate the assertion with a specific TPM. Thatis, a non-zero expiration causes the TPM to produce a ticket. If the signer did not include
nonceTPM, its signature could be used with any session and therefore on any TPM. Including
nonceTPM binds the signature to a specific session, and thus a specific TPM. The signer forces
the ticket to be created on a specific TPM, which ties the ticket to a timer on that TPM.
Each nonceTPM is expected to be statistically unique and not appear on any other TPM (this isjust expected to be true and not required to be true). Therefore, when an assertion includes
nonceTPM, the assertion will only be usable on one policy session on a specific TPM.
NOTE

When a ticket is produced, that ticket is always restricted to use on a specific TPM because of theuse of TPM- and hierarchy-specific proof values in the ticket computation.

When the policy assertion does not include nonceTPM, then is it possible to use the assertion
with any policy session. For TPM2_PolicySecret() the assertion can still be associated with a
specific TPM if the authorization for the authObject uses an HMAC or policy session. This is becausethat authorization session will be TPM specific. For TPM2_PolicySigned(), when there is nononceTPM in the assertion, then the assertion can be used on any policy session on any TPM
where the public part of authObject can be loaded (that is, any TPM that is compatible with thisspecification). This can be suitable when an assertion is limited to performing specific actions(through cpHash) or specific policies (though policyRef), but this capability should be used withcaution.
19.8

Dictionary Attack Protection
Introduction

The TPM incorporates mechanisms that provide protection against guessing or exhaustive searches ofauthorization values stored within the TPM.
The dictionary attack (DA) protection logic is triggered when the rate of authorization failures is too high. If
this occurs, the TPM enters Lockout mode in which the TPM will return TPM_RC_LOCKOUT for an
operation that requires use of a DA protected authValue. Depending on the settings of the configurable
parameters described below, the TPM can “self-heal” after a specified amount of time or be
programmatically reset using proof of knowledge of an authorization value or satisfaction of a policy
The authValue for an object receives DA protection unless the object's noDA attribute is SET. The
authValue for an NV Index receives DA protection unless the TPMA_NV_NO_DA attribute of the Index is
SET. The authValue associated with a permanent entity, other than TPM_RH_LOCKOUT, does notreceiveDA
protection.
Sequence
objects
createdby
TPM2_HMAC_Start()
and
TPM2_HashSequenceStart() do not receive DA protection.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 133
December 24, 2020

Trusted Platform Module Library
NOTE 1

Part 1: Architecture

Authorization values associated with permanent entities, other than TPM_RH_LOCKOUT, areexpected to be high-entropy values that are managed by a computer or will be well -known values, Ineither case, they will not need DA protection. While it is safer when lockoutAuth is a high-entropy
value, it is possible that lockoutAuth will be a value chosen to be remembered by a human which will
likely have less entropy than other permanent entities. As a consequence, lockoutAuth is DA
protected even though it is a permanent entity.

The reason for being able to exclude entities from DA protection is that lockout of all TPM use could makethe system unstable. The OS can have uses for the TPM that should not be blocked due to authorization
problems with keys associated with user-mode applications. The OS is expected to use a well-known or
high-entropy authValue for any entities that it manages and an authValue of neither type needs DAprotection.
An authValue can be used for authorization in three ways:
1) a password;2) the authValue parameter in the HMAC computation of equation (17); or
3) the authValue parameter in the computation of sessionKey for a bound session as shown in equation(18).
All uses of a DA protected authValue receive DA protection.
NOTE 2

A TPM PIN Index provides a type of DA protection for an individual TPM entity. This is described inclause 37.2.8.

Lockout Mode Configuration Parameters
The TPM uses four, 32-bit, non-volatile state variables to control the initiation and recovery from the DAlockout mode.
NOTE

The "NV" notation indicates that these values are required to be held in persistent memory and be
updated in NV when they change

failedTries (NV) – This counter is incremented when the TPM returns TPM_RC_AUTH_FAIL.
TPM2_Clear() will reset this counter to zero. This counter is also set to zero on a successful
invocation of TPM2_DictionaryAttackLockReset(). This counter is decremented by one after
recoveryTime seconds if:
the TPM does not record an authorization failure of a DA-protected entity,
there is no power interruption, andfailedTries is not zero.
NOTE 1

If the TPM has a trusted source of time that runs when TPM power is lost, then failedTries may be
reduced when power is restored. The amount that failedTries is decremented would be dependent
on the duration of the power loss and the value of recoveryTime.

NOTE 2The TPM may keep track of the time elapsed toward recoveryTime at shutdown and use that against
the recoveryTIme upon power up.

maxTries (NV) – The TPM is in Lockout mode as long as failedTries equals this value. When a newowner is installed, maxTries is set to its default value as specified in the relevant platform-specificspecification.
recoveryTime (NV) – This value indicates, in seconds, the rate at which failedTries is decremented.
This can be set to a large value (232 - 1) which essentially inhibits automatic exit from Lockout mode.
When a new owner is installed, this value is set to its default value as specified in the relevant
platform-specific specification.

Page 134
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibrarylockoutRecovery (NV) – This value indicates the delay in seconds between attempts to use
lockoutAuth. The time delay only applies after an authorization failure using lockoutAuth. A value ofzero indicates that a system reboot (TPM2_Startup(TPM_SU_CLEAR)) is required between lockout
attempts.
The
parameters
maxTries,
recoveryTime,andlockoutRecovery
are
TPM2_DictionaryAttackParameters(). This command requires Lockout Authorization.

set

with

Lockout Mode
The TPM is in Lockout mode while failedTries is equal to maxTries. While in Lockout mode, any use of a
DA-protected authValue will return TPM_RC_LOCKOUT.
NOTE 1

An exception is that TPM2_DictionaryAttackLockReset() is allowed to execute even thoughlockoutAuth is DA protected.

NOTE 2

If there is an authorization failure that does not increment
TPM_RC_BAD_AUTH

failedTries, the TPM returns

An authorization failure can occur with a password or an HMAC. For a policy authorization, the policy isvalidated before the HMAC is computed. If the policy fails, the TPM returns TPM_RC_POLICY to indicatethat dictionary attack protection was not involved.
NOTE 3A policy authorization does not always have an associated HMAC.

Recovering from Lockout Mode
The TPM can recover from Lockout mode in three ways.
1) TPM2_DictionaryAttackLockReset() sets failedTries to zero. This command requires Lockout
Authorization. The TPM does not have to be in Lockout mode in order to use this command.
2) The TPM decrements failedTries by one if no TPM resets are recorded during recoveryTime.
NOTE 1

If the TPM is in Lockout mode, then the TPM will always leave Lockout mode when failedTriesdecrements because failedTries will no longer be equal to maxTries.

NOTE 2

The failure count is not decremented below zero.

3) failedTries is set to zero if the owner changes.
Configuration and programmatic recovery of the dictionary attack logic requires proof of knowledge of
Lockout Authorization. When the TPM owner is changed by changing the SPS, lockoutAuth is set to the
EmptyAuth and lockoutPolicy is set to the Empty Buffer
TPM2_DictionaryAttackLockReset() allows external software to reset the dictionary attack protection logic
by providing Lockout Authorization. This command can be used when the TPM is in Lockout mode.
Authorization Failures Involving lockoutAuth
When lockoutAuth is used in an authorization and that authorization fails, the TPM enters a lockout state
intended to provide special protection for the lockoutAuth value. An authorization failure associated withlockoutAuth causes the TPM to enter this special lockout state regardless of the setting of failedTries andmaxTries.
When in this special lockout state, the TPM will not allow use of lockoutAuth. The TPM will exit this state
when TPM2_DictionaryAttackLockReset() is used with a successful lockoutPolicy or after the TPM is
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 135
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

powered for a configurable time period (lockoutRecovery). If lockoutRecovery is set to zero, then the TPM
will not exit this state until the next TPM2_Startup() or until lockoutPolicy is used.
NOTE

The design depends upon the trusted computing base to filter commands to the TPM such as
TPM2_DictionaryAttackLockReset(). This prevents a rogue application from completing a denial ofservice attack on the TPM by intentionally sending the command with a bad lockoutAuth.

Non-orderly Shutdown
A TPM may be implemented such that the command execution unit does not always have access to NV
memory (see 37.7.2). For such an implementation, it may not be possible to increment the NV copy offailedTries when the authorization failure occurs. When the failure occurs, the TPM will return
TPM_RC_AUTH_FAIL and, until the NV version of failedTries is updated, the TPM will be in lockout.
It is possible that the TPM will be reset when a write to the NV version of failedTries is pending. If the
TPM did not handle this special case, then an attacker could try an authorization for a DA protected
object when NV writes are not possible. When the TPM restarted, the failed attempt would not berecorded, and the attacker could try again.
To prevent this type of attack, at TPM2_Startup(), the TPM checks if it is starting after an orderly
shutdown. If not, and failedTries is not already equal to maxTries, then the TPM will increment failedTriesby one.
NOTE 1This check and increment of failedTries may not be necessary if it is impractical for an attacker toprevent update of the NV version of failedTries.

An alternative implementation sets an NV flag indicating that access to a DA protected object occurred
during this boot cycle. After a non-orderly restart, if the flag is set, the TPM increments failedTries andclears the flag. If the flag is clear, there is no need to increment failedTries.
EXAMPLEThis handles the case where a platform repeatedly does a non -orderly shutdown, possibly due to a low
battery. Without the flag, failedTries would increment on each reboot and the TPM would go into
lockout.

NOTE 2

Some versions of the reference code did not correctly implement the behavior described above if a
DA protected object is accessed after a TPM2_Shutdown(). In this case, the NV flag (indicating thataccess to a DA protected object occurred during this boot cycle) is not set correctly. When a power
loss happens, failedTries is not incremented on the next TPM2_Startup().
The check and increment of failedTries on TPM2_Startup() prevents the case that a failed
authorization attempt is not recorded by the TPM (e.g. because NV memory is unavailable).

Justification for Lockout Due to Session Binding
When a bound session is created, the caller does not have to prove knowledge of the authValue of thebind object. The authValue is used in the creation of the sessionKey and if the caller does not know theauthValue, they will not be able to compute the correct sessionKey and use the authorization session.
A bound authorization session can be used to authorize actions on another object. If that object does nothave DA protection, then an attacker could use binding to circumvent DA protection on the bind object.
The attack is as follows:
An attacker creates an object (D) that has no DA protection and authValue known to the attacker.
An attacker guesses a possible authValue for a DA protected object (object A).
The attacker uses object A as the bind object in TPM2_StartAuthSession() to create a session (S).
The attacker uses session S to authorize an action on object D.
Page 136
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

If the authorization fails, the attacker goes to step b) and tries a new value.
By retaining the DA state of object A in the session state, the attack is prevented. When the session isused for authorization, the authorization failure counter (failedTries) is incremented if either the entity
being authorized is subject to DA protection or if the session is bound to an entity that has DA protection.
NOTE

If a session is bound to a permanent entity other than TPM_RH_LOCKOUT, then the session is notbound to an entity that has DA protection.

Sample Configurations for Lockout Parameters19.8.8.1

Introduction

Two common configurations are anticipated: one for enterprise-managed TPMs, and one for home users.
NOTE

19.8.8.2

It is anticipated that the operating system will layer additional anti -hammering protection atop thatprovided by the TPM so that it is unlikely that one OS user will be able to interfere with the actionsof another user or the trusted computing base (TCB).

Enterprise Use

In this use, it is expected that the TPM owner will set the lockoutAuth to a high-entropy value that is held
in a database and set the lockoutRecovery to a small, non-zero value, such as one. The enterprise will
use this value to recover the TPM when suitable non-automated validation procedures have been
performed.
The enterprise would likely set maxTries to a relatively low value (such as, 10).
For a server or data center, the recoveryTime would be set to a large value (such as, 232 -1) implying
manual recovery. For laptops, a setting of a few hours would provide adequate protection for PINs.
19.8.8.3

Home or Unmanaged Use

In this application, the lockoutAuth can be set to a random, high-entropy value that is then erased so that
programmatic lockout recovery is not possible. maxTries and recoveryTime can be set to balance security
and convenience.
NOTE

If this configuration is used, the only way to execute TPM2_Clear() to change the owner is to use
Platform Authorization.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 137
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Audit Session
20.1

Introduction

An audit session allows for the auditing of a selected sequence of commands so that evidence can beprovided that the commands were executed.
Any HMAC authorization session can be designated for auditing but only one session can be used foraudit in each command. A session is designated for auditing by setting the audit attribute in the session.
A policy session cannot be designated for auditing.
When a session is first used as an audit session, the TPM will initialize the audit hash for the audit
session. The initialization value is a Zero Digest with the number of octets determined by the hashalgorithm of the session.
If the session was bound when created (see 19.6.10 and 19.6.12), the bind value is lost and any further
use of the session for authorization will require that the authValue be used in the HMAC.
Since the first use of an audit session may cause the size of the session context to change, the command
may fail due to insufficient memory. TPM-management software can save other session contexts andretry the command.
NOTE 2The TPM is required to have sufficient memory to allow three sessions to be simultaneously loaded,
one of which can be an audit session.

For all commands using a session tagged as audit (including the initial use), if the command completes
successfully, the cpHash and the rpHash are Extended to the audit session digest. When a command
fails, the audit session digest is not changed and, as is normal in the case of a command failure, thesessions are not included in the response and session nonces are not updated.
The equation for updating the audit session digest is:

auditDigestnew ≔ HauditAlg (auditDigestold || cpHash || rpHash)(30)

The hash algorithm is the algorithm designated in TPM2_StartAuthSession().
NOTE 3

Audit within an encrypted session will record the enc rypted cpHash and/or rpHash, which is unlikely
to be useful at the application level.

Unless a command description indicates that no sessions are allowed, an audit session can be used withany command. A command can have only one audit session.
An audit session uses the same session format as other HMAC-based sessions. The method ofcomputing the HMAC differs in that, if the audit session is not associated with any object handle, no
authValue is available for use in the authorization HMAC. All HMAC computations for an audit session will
set authValue to an Empty Buffer.
NOTE 4

If the sessionKey is also an Empty Buffer, then no HMAC computation is performed and the hmac
parameter of the session structure will be an Empty Buffer.

For commands that do not require authorization, a bound or salted audit session causes an HMAC basedon a shared secret to be generated. This provides assurance that the command was executed on the
TPM. A bound session allows association with a known authValue in a TPM, which can provide
assurance that the commands being audited are actually associated with a specific TPM. However, if
others know the authValue, then the unsalted audit session can have the same association issue as the

Page 138
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Libraryunbound session. A salted session can be associated with a key that is known to be TPM-resident, so theaudit based on a salted session can be reliably associated with a specific TPM.
NOTE 5This assurance does not require a signed audit digest to be used.

EXAMPLE

TPM2_PCR_Read does not require authorization. A bound or salted audit session will cause an
HMAC to be used, and thus provide integrity for the command and response.

20.2

Exclusive Audit Sessions

An exclusive audit session permits the TPM to prove that a series of commands were executed with nointervening commands that were not audited by the exclusive audit session.
In a response, the auditExclusive attribute of an audit session will indicate if the TPM has executed any
commands that were not audited by the session. If there was another user of the TPM, the auditExclusive
attribute will be CLEAR. If not, the audit session is exclusive and the auditExclusive attribute will be SET.
The TPM keeps track of the current exclusive session. At most, one active session can have theauditExclusive status. A session becomes the current exclusive audit session when it is first used as anaudit session, regardless of the setting of auditReset. It can also become the current exclusive audit
session if the auditReset attribute of the session is SET in the command. In the response, theauditExclusive attribute of the session will be SET and the session is exclusive. The session is no longer
the current exclusive audit session if it is flushed (TPM2_FlushContext()) or if an auditable command is
executed that does not use the current exclusive audit session. auditReset can only be SET if audit isalso SET.
A command that is not allowed to have any sessions will not change the current exclusive audit session.
Those commands include the context management commands (TPM2_ContextSave(),
TPM2_ContextLoad(), and TPM2_Flush()), TPM2_Startup(), and TPM2_ReadClock().
NOTE 220.3

It is the responsibility of the TCG Software Stack (TSS) or other controlling software to preserve theintegrity of the exclusive audit session. As the purpose of the exclusive audit session is to show thatno other commands were executed during the session, the expectation is that the contro lling
software would limit access to the TPM to prevent any other uses of the TPM.

Command Gating Based on Exclusivity

If the auditExclusive attribute of an audit session is SET in the command, then the TPM will return
TPM_RC_EXCLUSIVE if the audit session is not the current exclusive audit session.
NOTE 1

As with other error returns, no change is made to the state of the session and it remains active.

NOTE 2

auditExclusive in a command only determines whether the command is executed. It does not affectthe exclusive status of the session.

NOTE 3auditExclusive SET requires audit to be SET.

20.4

Audit Session Reporting

The audit status of an audit session can be determined with TPM2_GetSessionAuditDigest(). This
command returns a data structure that includes the audit session digest. If the handle for the signing key
is not TPM_RH_NULL, the TPM returns a signature over the data structure.
In the atypical case where the TPM2_GetSessionAuditDigest() sessionHandle is the same as the handleof the audit session, because the audit digest is signed before the audit digest is updated, the cpHash
and rpHash for a TPM2_GetSessionAuditDigest() is not included in the audit digest of the signed data
structure. Possession of the audit digest is proof that the command executed. However, the cpHash andFamily “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 139
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

rpHash of TPM2_GetSessionAuditDigest() will be included in subsequent audits if the audit session
remains active.
TPM2_GetSessionAuditDigest() requires that the indicated session be an audit session and will return
TPM_RC_TYPE if it is not. The TPM does not change internal state unless the command actions
complete successfully. This means that a session cannot become an audit session unless the commandin which it is designated as an audit session completes successfully. From this we can conclude that asession cannot be designated as being an audit session in a TPM2_GetSessionAuditDigest() in which thesame session is the audited session.
20.5

Audit Establishment Failures

If a command is the first use of a session as an audit session, and the command fails, then the state of asession as an audit session will not change. This means that, if a session was not an audit session before
the command was executed, it will not be an audit session after the command fails. If a session was anaudit session before the command was executed, it will be an audit session after the command fails.
If a command fails, then the exclusive status of sessions does not change. A session that was exclusive
before the command failure is exclusive after the command failure.
20.6

Audit Alternative

Both TPM2_GetSessionAuditDigest() and TPM2_GetCommandAuditDigest() require Endorsement
Authorization. If an application does not have Endorsement Authorization, it can still obtain proof that acommand was run on a particular TPM. The application must have a fixedTPM asymmetric encryption
key that is trusted to be on the TPM. This key would have similar trust properties to the signing key thatwould be used with the TPM2_GetSessionAuditDigest() and TPM2_GetCommandAuditDigest()
commands. The application uses an audit session that is a salted session with the trusted key specified
as tpmKey. The salt forces an HMAC session. The HMAC verification is proof that the command was run
on that TPM.

Page 140
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Session-based encryption
21.1

Introduction

Several commands have parameters that could need to be encrypted going to or from the TPM. An
example is the authorization data that is passed to the TPM when an object is created or when theauthorization value is changed. Session-based encryption can be used to ensure confidentiality of theseparameters.
Not all commands support parameter encryption. If session-based encryption is allowed, only the firstparameter in the parameter area of a request or response can be encrypted. That parameter must havean explicit size field. Only the data portion of the parameter is encrypted. The TPM should support
session-based encryption using XOR obfuscation. Support for a block cipher using CFB mode is platform
specific. These two encryption methods (XOR and CFB) do not require that the data be padded forencryption, so the encrypted data size and the plain-text data size is the same.
If the symmetric algorithm is TPM_ALG_NULL and encryption or decryption is specified, the TPM returns
TPM_RC_SYMMETRIC.
Any first parameter can be encrypted as long as the parameter has a size field.
Session-based encryption uses the algorithm parameters established when the session is started andvalues that are derived from the session-specific sessionKey. The encryption values are created in a waythat is dependent on both the session type and the session encryption parameters.
If a session is also being used for authorization, sessionValue (see 21.2 and 21.3) is sessionKey ||authValue. The binding of the session is ignored. If the session is not being used for authorization,
sessionValue is sessionKey.
NOTE 1

A policy session that is used for parameter encryption uses authValue to calculate sessionValue
even if the policy does not include TPM2_PolicyAuthValue().

If sessionAttributes.decrypt is SET in a session in a command, and the first parameter of the command isa sized buffer, then that parameter is encrypted using the encryption parameters of the session. If
sessionAttributes.encrypt is SET in a session of a command, and the first parameter of the response is asized buffer, then the TPM will encrypt that parameter using the encryption parameters of the session.
The encrypt attribute can only be SET in one session that is used in a command and the decrypt attribute
can only be SET in one session per command. The attributes can be SET in different sessions or in thesame session.
Parameters in commands are encrypted before any cpHash is computed. Parameters in responses are
encrypted before any rpHash is computed.
The parameter data buffer is protected with either XOR obfuscation or CFB mode encryption. The size
field of the parameter is not protected.
When a command/response with an encrypted parameter is received, the cpHash/rpHash is computed as
required for the sessions before the parameter is decrypted.
NOTE 2The caller can obfuscate the true size of an authorization value by adding octets of zero to the end.
The extra octets of zero will have no impact on the authorization computations and are discarded by
the TPM.

The two methods of session-based encryption used in this specification are, by themselves, malleable.
That is, an attacker can make a controlled change (bit reversal) in the encrypted data that will result in an

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 141
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

identical change in the decrypted data. This kind of attack is mitigated by the HMAC authorization session
verification.
21.2

XOR Parameter Obfuscation

For session-based obfuscation using XOR(), the operation is:

XOR(parameter, hashAlg, sessionValue, nonceNewer, nonceOlder)

(31)

where

parametera variable sized buffer containing the parameter to be obfuscatedhashAlg

the hash algorithm associated with the session

sessionValuesee 21.1

nonceNewerfor commands, this will be nonceCaller and for responses it will be
nonceTPM

nonceOlderfor commands, this will be nonceTPM and for responses it will be
nonceCaller

NOTE 1The XOR () function is defined in 11.4.7.3.

NOTE 2The obfuscated size of parameter is the same as the size of the underlying parameter. That is, if a
TPM2B_CREATE is obfuscated, the size of the obfuscated data is the same as the size of the data.

21.3

CFB Mode Parameter Encryption

When session-based encryption uses a symmetric block cipher, an encryption key and IV will be
generated from:KDFa (hashAlg, sessionValue, “CFB”, nonceNewer, nonceOlder, bits)

(32)

where

hashAlg

the hash algorithm associated with the session

sessionValuesee 21.1“CFB”

label to differentiate use of KDFa() (see 4.2)

nonceNewer

nonceCaller for a command and nonceTPM for a response

nonceOldernonceTPM for a command and nonceCaller for a responsebits

the number of bits required for the symmetric key plus an IV

NOTE 1The IV size is equal to the block size of the cipher.

The most significant octets of the returned value are used as the encryption key and the remaining octets
are used as the IV. The number of octets used for the encryption key and for the IV is dependent on thealgorithm parameters of the session.
EXAMPLEFor AES, the block size is 16 octets regardless of the key size. If the key size were 256 bits (32octets), then, in the call to KDFa (), bits would be set to 48*8. The most significant 32 octets of the
returned value would be used as the key for the encryption and the next 16 octets would be used forthe IV.

Page 142
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
NOTE 2Trusted Platform Module Library

If the key size is not an even multiple of 8 bits, the first N octets of the returned value will containthe key and the remaining octets the IV. N is the smallest integer such that (N * 8) ≥ the key size.

The data portion of the parameter is then encrypted using the symmetric key and the symmetric blockcipher algorithm associated with the session.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 143
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Protected Storage
22.1

Introduction

When a Protected Object is in the TPM, it is in a Shielded Location because the only access to thecontext of the object is with a Protected Capability (a TPM command). The size of TPM memory may belimited and if the only storage for Protected Objects were the TPM Shielded Locations, the TPM’s
usefulness would be reduced. The effective memory of the TPM is expanded by using cryptographic
methods for Protected Objects when they are not in Shielded Locations.
22.2

Object Protections

The cryptographic protections for a Protected Object include encryption to prevent disclosure of theconfidential contents, and an integrity check to allow detection of modifications to the externally stored
Protected Object. The integrity check detects modifications to either the confidential or the nonconfidential portions of the Protected Object.
The integrity value is computed over the encrypted data. If the integrity check fails, then symmetric
decryption will not occur. Since the integrity value contains the digest of the associated public area (itsName), the confidential contents of the Protected Object will not be decrypted if they are not properly
paired with a public area.
22.3

Protection Values

The protection of a sensitive area uses two keys. These values are created from a secret value
associated with an object’s Storage Parent. One of the keys is used as an HMAC key and the second is asymmetric encryption key.
A seed value is used in the generation of the symmetric encryption key and the HMAC key. The source ofthe seed is dependent on the situation. If the protections are for an object in a hierarchy, the seed is theseedValue in the Storage Parent’s sensitive area. If the protections are for a duplication blob, the seed isderived from a shared secret that is protected using asymmetric methods of the new parent. The
algorithm-specific annexes contain the formulations for deriving the seed when asymmetric protections
are used.
To produce the symmetric key, the seed value and object Name are used in KDFa() as shown inequation (33). This method is used when a symmetric key is generated for the protection of sensitive
areas attached to a hierarchy or sensitive data in a duplication blob (see 23.3).
NOTE 1This method is also used to generate the symmetric key used for the protection of credential values(see 24.4).

To produce the HMAC key, the seed is used in KDFa() as shown in equation (35). This method is used
when an HMAC is used to protect the integrity of a sensitive area attached to a hierarchy or for sensitive
data in a duplication blob.
NOTE 2This method is also used to generate the HMAC key for credential values (see 24.4).

When performing symmetric encryption, an IV of zero is used unless the same symmetric key is used
multiple times. The same symmetric key is used each time that the sensitive area of a child changes due
to TPM2_ObjectChangeAuth(). For encryption of a child, a random IV is generated by the TPM each timeit performs the encryption.

Page 144
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
22.4

Trusted Platform Module Library

Symmetric Encryption

A symmetric key is used to encrypt the sensitive area of an object that was created by TPM2_Create() or
imported by TPM2_Import(). It is also used when re-encrypting a sensitive area when the authorization
value is changed (TPM2_ObjectChangeAuth()). The symmetric key is derived from a seed value
contained in the Storage Parent’s sensitive area and the Name of the protected object.
The block cipher used for encrypting the object's sensitive area is the symmetric cipher of the Storage
Parent.
The symmetric key for the encryption is computed by:symKey ≔ KDFa (pNameAlg, seedValue, “STORAGE”, name, NULL , bits)

(33)

where

pNameAlg

nameAlg of the object's Storage Parent

seedValue

symmetric seed value in the sensitive area of the object's Storage Parent(see 27.7.4)“STORAGE”

a value used to differentiate the uses of the KDF

name

Name of the object being encrypted / decrypted

bits

number of bits required for the symmetric key

When a symKey is being used to protect the sensitive area of a child object, the TPM will create a random
IV value (symIv) that is the size of an encryption block of the symmetric algorithm. This symIV is includedin the private area and in the HMAC computation of the sensitive area. A symIV of zero is used whenencrypting the sensitive area for duplication or a credential to be used in TPM2_ActivateCredential().
The symKey and symIv are used to encrypt the sensitive data.

encSensitive ≔ CFBpSymAlg (symKey, symIv, sensitive)

(34)

where

CFBpSymAlg

symmetric encryption in CFB mode using the symmetric algorithm of theStorage Parent

symKeysymmetric key from (33)

symIv

IV from RNG or 0

sensitive

a TPM2B_SENSITIVE containing the sensitive area structure being
protected

NOTE

The size and buffer fields of sensitive are encrypted.

After the data is encrypted, the TPM2B_IV containing the random symIv is placed in front of theencrypted data in preparation for the integrity computation. If the symIV was zero, then no value is added
to the encrypted data.
22.5

Integrity

The HMAC key (HMACkey) for the integrity is computed by:

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 145
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

HMACkey ≔ KDFa (pNameAlg, seedValue, “INTEGRITY”, NULL, NULL, bits)

(35)

where

pNameAlgthe nameAlg of the object's Storage Parent

seedValue

the symmetric seed value in the sensitive area of the object's Storage
Parent (see 27.7.4)“INTEGRITY”

a value used to differentiate the uses of the KDF

bits

the number of bits in the digest produced by pNameAlg

HMACkey is then used in the integrity computation.
An HMAC is performed over the symIV and the encSensitive produced in (34).
NOTE 1This is called an outerHMAC because it is the same HMAC process that is used when an object is
duplicated. The duplication can produce an inner and an outer HMAC.

outerHMAC ≔ HMACpNameAlg (HMACkey, symIv || encSensitive || name.buffer)

(36)

where

HMACpNameAlg

the HMAC function using nameAlg of the object's Storage Parent

HMACkeya value derived from the Storage Parent’s symmetric protection value(seedValue) according to equation (35)

symIv

a marshaled TPM2B_IV containing the symmetric IV value used in (34).
Both the size and buffer fields are included in the HMAC

encSensitive

encrypted TPM2B_SENSITIVE produced in (34); after encryption, thesize and buffer fields are not separable

name.buffer

the Name of the object being protected (does not include a size field)

The integrity value is placed before the symmetric IV.
NOTE 2

Placement of the integrity value at the beginning of the sensitive area in preparation simplifies theprocess of finding the integrity value when the protected data contains variable -sized elements.

NOTE 3

Inclusion of the Name ensures that the sensitive area is associated with the corre ct public area.

Marshal the sensitive area into a TPM2B_SENSITIVE

sensitiveArea

size
sensitiveType
authValue
seedValue[sensitiveType]sensitive

Create a symmetric key and IV for encryption:

symKey ≔ KDFa (pNameAlg, seed, “STORAGE”, name, NULL , bits)
symIV ≔ bits from the RNG

Page 146
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibrarysensitiveType
authValue
symValue[sensitiveType]sensitive

size

encSensitive ≔ CFBpSymAlg (symKey, symIv, sensitive)

sensitiveArea

size

Create encSensitive by encrypting the TPM2B_SENSITIVE

symmetric IV

Add the symmetric IV to (a TPM2B_IV) the encrypted blocksensitiveArea

size
sensitiveType
authValue
symValue[sensitiveType]sensitive

Compute the HMAC key

HMACkey ≔ KDFa (pNameAlg, seed, “INTEGRITY”, NULL, NULL, bits)

outerHMAC
size

Compute the HMAC over the symmetric IV (the full TPM2B_IV), theencSensitive from step 3, and the Name of the object being protected.

sensitiveArea

size

outerHMAC ≔ HMACpNameAlg (HMACkey, symIv || encSensitive || name.buffer)
An overall size field will be added to make the resulting
TPM2B_PRIVATE structure.

size size

NOTE

NOTE

An overall size field will be added to make the resulting
TPM2B_PRIVATE structure.

sensitiveType
authValue
symValue[sensitiveType]sensitiveouterHMAC
symmetric IV
size

sensitiveArea

Marshal the outerHMAC into a TPM2B_DIGEST and append thesymmetric IV and encrypted sensitive.

symmetric IV

sensitiveType
authValue
symValue[sensitiveType]sensitive

Figure 17 — Creating a Private Structure

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 147
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Protected Storage Hierarchy
23.1

Introduction

The TPM supports the creation of hierarchies of Protected Locations. A hierarchy is constructed with
Storage Keys as the connectors to which other types of objects (keys, data, and other connectors) can be
attached.
The hierarchical relationship of objects allows segregation of objects based on the system-operating
environment (established by PCR or authorizations) as well as simplifying the management of groups ofrelated objects.
23.2

Hierarchical Relationship between Objects

A hierarchy is rooted in a secret seed key, kept in the TPM. To create a hierarchy of keys, the seed key(Primary Seed) is used to generate a key that uses a specific set of algorithms. If this key is a restricteddecryption key, then it is a Parent Key. If it is not a Derivation Parent, then it is a Storage Parent underwhich other objects can be created or attached.
A Storage Parent provides protection for the sensitive area in another object (a child) when that object isstored outside of the TPM. Protection is provided by symmetric encryption and HMAC-based integrity
protection of the sensitive area. There are two different cases for sensitive area encryption: storage andduplication.
When an Ordinary Object is created (TPM2_Create() or TPM2_CreateLoaded()) the keys used forprotection of the Object’s sensitive area are derived from a seed value (seedValue) in the sensitive areaof the Storage Key. When an Object is prepared for duplication, its sensitive area is protected by arandom key and a form of Diffie-Hellman is used to convey the key to the duplication target.
The objects in a hierarchy have a parent-child relationship. A Storage Key that is protecting other objects
is a Storage Parent and the objects that it is protecting are its children. The ancestors of an object are theparent keys that connect the object to a TPM Primary Seed. Descendants of a key are all the objects thathave that Parent as an ancestor. Unless it is intended to be used as a parent, a child object can be of any
type.
A Derived Object is a child of its Derivation Parent. Both Primary Objects and Derived Objects are derived
from seed values. For a Primary Object, the seed value is a Primary Seed and for a Derivation Object theseed value is the secret seed value in the Derivation Parent.
The sensitive part of an object created from a seed is not stored off of the TPM except in a context blobs(see clause 30). This means that the seed used to create the Object is not also used to generate
protection keys for the Object. When an Object is duplicated, its sensitive area is protected by a random
key, so the creation seed is not put at risk by the duplication process (see 23.3).

Page 148
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Color indicates the seed
used to generate theprotections and the objects
protected by that seed

An ordinary object

A storage key
Seed from which HMAC and symmetricprotection keys are derived

LegendFigure 18 — Symmetric Protection of Hierarchy
There are two classes of Storage Keys: asymmetric and symmetric. All Storage Keys contain a symmetricprotection key. An asymmetric Storage Key has a public identity that can be used as the target of an
identity-based or secret-based duplication operation. An object that is a symmetric block cipher Object
can also be a Storage Key, but can only be the target of secret-based duplication
23.3

Duplication
Definition

Duplication is the process of allowing an object to be a child of additional Storage Parent keys. The newparent (NP) can be in a hierarchy of the same TPM or of a different TPM.
The creator of an object controls the duplication process by selecting the duplication policy for the object.
Authorization for duplication requires a policy session. The policy sequence is required to have acommand that causes the commandCode value of the policy context to be set to TPM_CC_Duplicate.
This enables the DUP role of the policy, which is a requirement for duplication.
Duplication occurs on a loaded object and produces a new, sensitive structure that is encrypted using themethods of the NP. This new sensitive structure cannot be used until TPM2_Import() has been executed
to convert the object from "external" to "internal" protections.
NOTE 1

External protections use both asymmetric and symmetric cryptography, whereas the internal
protections only use symmetric cryptography.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 149
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

When an Object is duplicated, its sensitive area can be protected with an outer wrapper, an inner
wrapper, or both. The outer wrapper uses Diffie-Hellman based on asymmetric keys and provides
identity-based duplication. The inner wrapper uses a symmetric key that is under control of the duplication
authority for the Object. Duplication using an inner wrapper is secret-based duplication.
NOTE 2The duplication authority is the entity that controls the conditions under which an Object can be
duplicated.

Protections
23.3.2.1

Introduction

In TPM2_Duplicate(), the caller can indicate that the object should be protected with an inner, symmetricencryption. That is, the sensitive area is symmetrically encrypted before it is asymmetrically encryptedusing the methods of the NP. If a symmetric inner wrapper is desired, the caller can provide a key or allow
the TPM to generate the key.
If the encryptedDuplication attribute is SET in the object being duplicated, then it is required that theobject have an inner wrapper and that the new parent not be TPM_RH_NULL. For such an object, theTPM will return an error (TPM_RC_SYMMETRIC) if the symmetricAlg parameter in TPM2_Duplicate() is
TPM_ALG_NULL and TPM_RC_HIERARCHY if the newParentHandle parameter is TPM_RH_NULL.
Creation of a duplicate object uses two encryption phases. The first is used to apply an inner wrapper andthe second is to encrypt using the algorithms of the NP.
The encryptedDuplication attribute of all objects in a duplication group are required to have the samesetting. When an object is created with the fixedParent attribute CLEAR, then the encryptedDuplication
attribute can be SET or CLEAR if the fixedTPM attribute is SET in the Storage Parent. If the fixedTPM
attribute of a Storage Parent is not SET, then the encryptedDuplication attribute is required to be thesame in all descendant objects of that Storage Parent.
23.3.2.2

Inner Duplication Wrapper

For the first phase, the TPM computes an integrity hash over the sensitive data. This hash includes theName of the public area associated with this object.

innerIntegrity ≔ HnameAlg (sensitive || name)

(37)

where

HnameAlghash function using the nameAlg of the object

sensitive

a TPM2B_SENSITIVE

name

the Name of the object being protected

A TPM2B_DIGEST containing the integrity digest value is prepended to the sensitive area and the buffer(integrity plus sensitive) is encrypted using CFB.

encSensitive ≔ CFBpSymAlg (symKey, 0, innerIntegrity || sensitive)

(38)

where

CFBsymAlg

Page 150
December 24, 2020

symmetric encryption in CFB mode using the algorithm specified in thecommand
TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

symKeyencryptionKeyIn parameter in TPM2_Duplicate() or a value from theRNG if no key is provided

innerIntegrity

value from (37)sensitive

the sensitive value used in (37)

If no inner wrapper is specified, no integrity value is computed, and no encryption occurs in this firstphase andencSensitive ≔ sensitive
23.3.2.3(39)

Outer Duplication Wrapper

In the second phase, the encSensitive produced by phase 1 is encrypted and integrity checked using
processes similar to those defined in clause 22. However, the seed from which the protection keys arederived is protected by the asymmetric algorithm of the NP. The method of generating seed is determinedby the asymmetric algorithm of the NP. The different methods are described in annexes to this TPM 2.0
Part 1, for example, clauses B.10.3 or C.6.3. The seed is selected prior to integrity generation for
encSensitive or encryption of encSensitive.
NOTE

For an RSA new parent, seed is not allowed to be larger than the size of the digest produced by the
nameAlg of the object. When the TPM creates seed, it will be exactly the size of the nameAlg of the
new parent.

Given a value for seed, a symmetric encryption key (symKey) is created by:symKey ≔ KDFa (npNameAlg, seed, “STORAGE”, Name, NULL , bits)

(40)

where

npNameAlg

the nameAlg of the new parent

seed

the symmetric seed value“STORAGE”

a value used to differentiate the uses of the KDF

Name

the Name of the object being encrypted or decryptedbits

the number of bits required for the symmetric key

The symKey is used to encrypt the encSensitive.

dupSensitive ≔ CFBnpSymAlg (symKey, 0, encSensitive)

(41)

where

CFBnpSymAlg

symmetric encryption in CFB mode using the algorithm of the new parent

symKeysymmetric key from (40)encSensitive

value from either (38) or (39)

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 151
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Next, an HMAC key is generated from seed:

HMACkey ≔ KDFa (npNameAlg, seed, “INTEGRITY”, NULL, NULL, bits)

(42)

where

npNameAlg

the nameAlg of the object's new parent

seed

the symmetric seed value used in (40)

“INTEGRITY”

a value used to differentiate the uses of the KDF.

bits

the number of bits in the digest produced by npNameAlg

An HMAC is then generated over the dupSensitive data. The Name of the associated public area isincluded in the HMAC computation to ensure that the sensitive area will only be decrypted when theproper public and private areas are used in TPM2_Import().

outerHMAC ≔ HMACnpNameAlg (HMACkey, dupSensitive || Name)

(43)

where

HMACnpNameAlg

the HMAC function using nameAlg of the new parent

HMACkeya value derived from the new parent symmetric protection value
according to equation (42)

dupSensitive

symmetrically encrypted sensitive area produced in (41)Name

the Name of the object being duplicatedTo complete the duplication process, the TPM2B_PUBLIC and TPM2B_ENCRYPTED_SECRET
produced by TPM2_Duplicate() are used in TPM2_Import() at the TPM containing the public and private
portions of the NP. If the private area is doubly encrypted, then the symmetric key used for the inner
wrapper is also given to the TPM.
TPM2_Import() will recover the symmetric key according to the algorithm of the NP. The
TPM2B_PRIVATE is decrypted. If an inner wrapper is present, the TPM2B_PRIVATE is decrypted using
the supplied symmetric key. After symmetric decryption, the integrity value is checked.

size

innerIntegrity ≔ HnameAlg (sensitive || name)

December 24, 2020[sensitiveType]sensitive

innerIntegrity digest

authValue
seedValuesize

Compute an innerIntegrity value

Page 152

sensitiveArea

If no inner or outer wrapper is applied to the object, this structure is returned as
the duplicate parameter in the response for TPM2_Duplicate().

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

sensitiveArea

NOTE

size

Marshal the sensitive area into a TPM2B_SENSITIVE

sensitiveTypesensitiveType
authValue
seedValue[sensitiveType]sensitive

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarysize

Set the encryption key (symKey) to encryptionKeyIn or a random value produced by the TPM.

encrypting

theinnerIntegrity value and theencSensitive ≔ CFBsymAlg (symKey, 0, innerIntegrity || sensitive)size
sensitiveTypesensitiveArea

by[sensitiveType]sensitive

size size

Create encSensitive
TPM2B_SENSITIVE

innerIntegrity digest

innerIntegrity digest

authValue
symValue

Using methods of the asymmetric new parent, create a seed value

Create a symmetric key (symKey):

symKey ≔ KDFa (npNameAlg, seed, “STORAGE”, Name, NULL, bits)

Create dupSensitive by encrypting encSensitive

dupSensitive ≔ CFBnpSymAlg (symKey, 0, encSensitive)

Compute the HMAC key from the seed created in step 5)

HMACkey ≔ KDFa (npNameAlg, seed, “INTEGRITY”, NULL, NULL, bits)

Compute the HMAC over dupSensitive and include the object NameouterHMAC

outerHMAC ≔ HMACnpNameAlg (HMACkey, dupSensitive || Name)
NOTE

An overall size field will be added to make the resulting TPM2B_PRIVATE
structure.

sensitiveArea

size
sensitiveType
authValue
symValue[sensitiveType]sensitive

Figure 19 — Duplication Process with Inner and Outer Wrapper

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 153
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Figure 20 illustrates the processing of a duplication blob when no inner wrapper is used in the sensitivearea.

Marshal the sensitive area into a TPM2B_SENSITIVE

sensitiveArea

size
sensitiveType
authValue
seedValue[sensitiveType]sensitive

Since there is no inner wrapper set encSensitive ≔ sensitive

Using methods of the asymmetric new parent, create a seed value

Create a symmetric key for encryption:

symKey ≔ KDFa (npNameAlg, seed, “STORAGE”, name, NULL , bits)

dupSensitive ≔ CFBnpSymAlg (symKey, 0, sensitive)

sensitiveArea

size

Create dupSensitive by encrypting encSensitive

sensitiveType
authValue
symValue[sensitiveType]sensitive

Compute the HMAC key from the seed created in step 3

outerHMAC
sensitiveTypesizeouterHMAC ≔ HMACnpNameAlg (HMACkey, dupSensitive || name)
NOTE

size

Compute the HMAC over the dupSensitive

sensitiveArea

HMACkey ≔ KDFa (npNameAlg, seed, “INTEGRITY”, NULL, NULL, bits)

An overall size field will be added to make the resulting TPM2B_PRIVATE
structure.

authValue
symValue[sensitiveType]sensitive

Figure 20 — Duplication Process with Outer Wrapper and No Inner Wrapper

Page 154
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarysize

sensitiveArea[sensitiveType]sensitive

size

Marshal the sensitive area into a TPM2B_SENSITIVE

sensitiveType

innerIntegrity digest

authValue
seedValuesize

sensitiveArea

Compute an innerIntegrity value

innerIntegrity ≔ HnameAlg (sensitive || Name)sensitiveType
authValue
seedValue[sensitiveType]sensitivebyencrypting

theinnerIntegrity value and theencSensitive ≔ CFBsymAlg (symKey, 0, innerIntegrity || sensitive)
NOTE

innerIntegrity digestsize

An overall size field will be added to make the resulting TPM2B_PRIVATE
structure.

sensitiveArea

Create encSensitive
TPM2B_SENSITIVE

size

Set the encryption key (symKey) to encryptionKeyIn or a random value produced by the TPM.

sensitiveType
authValue
symValue[sensitiveType]sensitive

Figure 21 — Duplication Process with Inner Wrapper and TPM_RH_NULL as NP

NOTE

An overall size field will be added to make the resulting TPM2B_PRIVATE
structure. This will result in a TPM2B_SENSITIVE being the only contents of
the TPM2B_PRIVATE buffer.

size

sensitiveArea

Marshal the sensitive area into a TPM2B_SENSITIVE

sensitiveType
authValue
seedValue[sensitiveType]sensitive

Figure 22 — Duplication Process with no Inner Wrapper and TPM_RH_NULL as NP
Rewrap23.3.3.1

Introduction

TPM2_Rewrap() is a primitive of an exemplar key recovery service that performs all its security-sensitive
processes on TPMs.
The effect of the recovery service is indistinguishable from duplication of a source key directly from asource platform to a destination platform.
The advantage of the recovery service is that

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 155
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture•

registration of a source key with the recovery service relies upon an operational source platform, but
not upon an operational destination platform, and•delivery of the source key by the recovery service relies upon an operational destination platform, but
not upon an operational source platform.

The recovery service keeps a source key from a source platform, irrespective of whether the destination
platform is known. The source key is protected from the recovery service by virtue of a backup password
that must be kept hidden from the recovery service but revealed to a destination platform. When thedestination platform is revealed to the recovery service, the recovery service facilitates the installation of
the source key in the destination platform.
While the source platform is operational, the source platform uses TPM2_Duplicate() to create adoubly wrapped duplication BLOB using a source key TpmPrivateKey, a backup password, and therecovery service’s public key. (Duplication BLOBs are described earlier in this subclause. Note thatthe “Outer Duplication Wrapper” subclause explains that the outer wrapping is symmetric encryptionthat depends on a seed generated from a public key.)
While the source platform is operational, the source platform sends the duplication BLOB (Source
BLOB in Figure 23) to the recovery service, which stores the BLOB.
When a destination platform is revealed to the recovery service, the recovery service uses
TPM2_Rewrap() to derive another doubly wrapped duplication BLOB using the original doubly
wrapped duplication BLOB, the recovery service’s key, and the destination platform’s public key.
When the destination platform is operational, the recovery service sends the derived duplication
BLOB (Recovery BLOB in Figure 23) to the destination platform.
While the destination platform is operational, the destination platform uses TPM2_Import() to create anormal key BLOB from the derived duplication BLOB, the destination platform’s key, and the backup
password.

Source BLOB
Recovery Service Key

SOURCE

Backup Password
TpmPrivateKey

RECOVERYSERVICE
Destination BLOB
Destination Key

DESTINATION

Backup Password
TpmPrivateKey

Figure 23 — Key Recovery Process
23.3.3.2

Creating a backed-up key

At the source platform, a key to be backed up, sourceKey = [sourcePubKey , sourceSensitiveKey],and the recovery service's public key recoveryServicePubKey are loaded in the source TPM.
Page 156
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

At the source TPM, TPM2_Duplicate() is used to create the doubly wrapped duplication BLOB, which
is sourceSensitiveKey, wrapped by encryptionKeyIn, wrapped by recoveryServicePubKey. The
parameters to TPM2_Duplicate() are:objectHandle - references the key sourceKey to be sent to the recovery service
newParentHandle - references the recovery service’s public key recoveryServicePubKey
encryptionKeyIn - is the backup password (this is an optional parameter and if the caller does notprovide a value, the TPM will generate one)symmetricAlg – the encryption algorithm for the inner wrapper
The TPM returns:
encryptionKeyOut – returned only if the TPM generated the key used for the inner wrapper
duplicate – the wrapped sensitive area of objectHandle; the Source BLOB.
outSymSeed - a protected version of the seed used to make the symmetric key used for outerwrapping encryption
The duplication BLOB duplicate is sent to the recovery service
23.3.3.3

Recovering a backed-up key

At the recovery service’s platform, the recovery service's key recoveryServiceKey=[recoveryServicePubKey , recoveryServiceSensitiveKey], and the destination platform’s public key
destinationPubKey are loaded into the recovery service’s TPM.
At the recovery service’s TPM, TPM2_Rewrap() is used to is used to replace the outer wrapper of the
Source BLOB with an outer wrapper tied to the Destination Key destinationPubKey. The parameters
for TPM2_Rewrap() are:oldParent - references the recovery service’s key recoveryServiceKey
newParent – references the destination platform’s public key destinationPubKey
induplicate – the Source BLOB
inSymSeed - this is outSymSeed from the source platform. It is needed to derive the symmetric
key used by the source platform for outer wrapping encryption
At the recovery service, the TPM will return
outDuplicate – the rewrapped Destination BLOB
outSymSeed - a protected version of the seed used to make the symmetric key used by therecovery service for outer wrapping encryption
At the destination platform, the destination platform’s key destinationKey =[destinationPubKey ,destinationSensitiveKey] is loaded into the TPM.
At the destination platform, TPM2_Import() is used to create outPrivate , which is a normal key BLOB
that can be loaded into the TPM on the platform. The parameters to TPM2_Import() are:parentHandle – a reference to the destination platform’s key (this will become the Storage Parent
for the imported object)encryptionKey – the backup password (encryptionKeyIn or encryptionKeyOut)
objectPublic – the public area of the key being imported
duplicate – the Destination BLOB outDuplicate from the recovery service
inSymSeed is outSymSeed from the recovery service. It is needed to derive the symmetric key
used by the recovery service for outer wrapping encryption
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 157
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

At the destination platform, the TPM returns
outPrivate – the sensitive area of the imported object
23.4

Duplication GroupThe duplication process allows an object or segment of a hierarchy to be duplicated for use in anotherhierarchy. This ability facilitates key distribution and backup. A duplication group is a group of objects in ahierarchy under a duplication root. The entire duplication group can be moved to another hierarchy by
duplicating the duplication root.
When an object is created, its duplication attribute (fixedParent) is selected. If fixedParent is CLEAR, thenthe object can be operated on by TPM2_Duplicate(). This command allows the sensitive area of an object
to be encrypted under a new parent so that it can be used in a different TPM hierarchy. The act of
duplicating a Storage Key has the side effect of duplicating all of its descendants regardless of the settingof their fixedParent attribute. That is, if a Storage Parent is usable in a different hierarchy, then all thedescendants of the Storage Parent are also usable in the different hierarchy as well.
NOTE 1

No modification of the encryption of a child object is req uired to make it usable on another hierarchy.
This is because the Storage Key that is duplicated contains the information used to protect its
children. Duplication of the protection information has the effect of duplicating the objects protectedby that information.

NOTE 2

If a particular Storage Parent is usable in multiple hierarchies, then descendants of that Storage
Parent are usable in the same hierarchies regardless of when they are created. That is, if they are
created after the duplication of the Storage Parent, they are still usable in multiple hierarchies.

If an object has fixedParent CLEAR, it is the root of a duplication group. If the object is not a Storage Key,
then the group will have a single member. For a Storage Key, the duplication group consists of all objects
that are duplicated as a direct consequence of duplicating the group root.
Objects that have fixedParent SET cannot be directly duplicated (that is, they cannot be the referenced
objectHandle in TPM2_Duplicate()). However, they can be implicitly duplicated if an ancestor has
fixedParent CLEAR and that ancestor is duplicated.
Objects that have fixedParent SET and have no ancestors with fixedParent CLEAR are the only objects
that are not part of a duplication group. These objects are identified by having their fixedTPM attribute
SET. All objects that are in a duplication group have their fixedTPM attribute CLEAR.
An object can be a member of more than one duplication group. This would occur if more than one of its
ancestor Storage Keys has fixedParent CLEAR or if an object and one of its ancestors has fixedParent
CLEAR.

Page 158
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Members of the
duplication group of
duplication root DR1

DR1

DR2

Members of the
duplication group of
duplication root DR2

An object with fixedParent = SET

An object with fixedParent = CLEAR

LegendFigure 24 — Duplication Groups
23.5

Protection GroupThe algorithms (asymmetric, symmetric, and hash) and key sizes used to protect child keys are
consistent within a protection group. The protection group is all of the descendants of a duplication root
not including other duplication roots or their descendants.
By requiring all of the non-duplicable Storage Keys to use the same algorithm, it is easier to determine
the security properties of a hierarchy. If an object’s fixedTPM attribute is SET, then all of the ancestor
keys of that object use the same set of algorithms. If an object’s fixedTPM is not SET, then theprotections are determined by the duplication authority for each of the duplication roots in the object’s
hierarchy.
The reason that the protections are determined by the duplication authority and not by the algorithms of
the key is that a duplication authority can attach a duplication root to a software-generated new parent.
Inspecting the hierarchy in which an object exists does not guarantee the protections of the object unlessthe object’s fixedTPM is SET.
Change of the algorithm set at a duplication root is illustrated in Figure 25.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 159
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The crosshatch in an object
indicates the algorithms
used to protect the object.

The algorithm set
may change at a
duplication root.

Figure 25 — Protection Groups
23.6

Summary of Hierarchy Attributes

The hierarchy attributes of an object indicate how the object is connected to the hierarchy. They indicate if
the object could be extant in other hierarchies and if the object can be duplicated directly by
TPM2_Duplicate().
Table 22 lists the possible combinations of an object’s hierarchy attributes and the interpretation of eachcombination.

fixedTPM

fixedParent

Table 22 — Mapping of Hierarchy Attributes

Description00This combination represents a duplication root.

01This combination is not allowed.

10This combination indicates an object that is permanently in the protection group of its Storage Parent. It
cannot be the objectHandle reference in TPM2_Duplicate().

11This combination indicates an object that was created on a specific TPM and no duplicate of the object ispossible.

Page 160
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
23.7

Trusted Platform Module LibraryPrimary Seed Hierarchies

A Primary Object is an object that is derived from a Primary Seed value. The sensitive area of a Primary
Object is not returned in the TPM2_CreatePrimary() or TPM2_CreateLoaded() response. The Primary
Object will need to be regenerated each time it is needed, or it can be made persistent in NV memory on
the TPM (TPM2_EvictControl()).
NOTE 1A Primary Object can be duplicated in which case its sensitive area will be stored off of the TPM.

NOTE 2

The reason for not allowing a Primary Object to be returned is to prevent certain types of power
analysis attacks on the primary seed values.

Once created, a Primary Object can be context-saved/restored.
A Primary Object can have fixedParent SET or CLEAR. If a Primary Object has fixedParent SET, thenfixedTPM is required to be SET.
Hierarchy Attributes Settings Matrix
Table 23 shows the combinations of hierarchy settings allowed for an object. In the table, the checkmarks ("✓") indicate that the combination is allowed.
Table 23 — Allowed Hierarchy Settings
fixedTPM setting in

Object's fixedParent

parentobject

CLEAR

SET

CLEAR

CLEAR

✓

✓

CLEAR

SET

SET

SET

SET

CLEAR

✓
✓

Comments
if the parent's fixedTPM attribute is CLEAR, the child's
fixedTPM is required to be CLEAR
if the parent of an object has fixedTPM SET, then fixedParent
and fixedTPM must have the same setting in the child(1)(2)

NOTE
1)

For purposes of this table, the parent of a Primary Object is considered to have a fixedTPM attribute that is always SET.

2)

If the parent has fixedTPM SET, then a child can be duplicable (fixedParent == CLEAR) or not (fixedParent == SET). If thechild is not duplicable, then it is required to have the same setting of fixedTPM as its parent.

The consistency of the hierarchy settings is checked in object templates (TPM2_Create() andTPM2_CreatePrimary()) and in public areas for loaded objects (TPM2_Load()) or duplicated objects(TPM2_Import()).

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 161
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Credential Protection
24.1

Introduction

The TPM supports a privacy preserving protocol for distributing credentials for keys on a TPM. The
process allows a credential provider to assign a credential to a TPM object, such that the credential
provider cannot prove that the object is resident on a particular TPM, but the credential is not available
unless the object is resident on a device that the credential provider believes is an authentic TPM.
24.2

ProtocolThe initiator of the credential process will provide, to a credential provider, the public area of a TPM object
for which a credential is desired along with the credentials for a TPM key (usually an EK). The credential
provider will inspect the credentials of the “EK” and the properties indicated in the public area todetermine if the object should receive a credential. If so, the credential provider will issue a credential forthe public area.
The credential provider can require that the credential only be useable if the public area is a valid object
on the same TPM as the “EK.” To ensure this, the credential provider encrypts a challenge and then"wraps" the challenge encryption key with the public key of the “EK.”“EK” is used to indicate that an EK is typically used for this process but any storage key can beused. It is up to the credential provider to decide what is acceptable for an “EK.”NOTEThe encrypted challenge and the wrapped encryption key are then delivered to the initiator. The initiator
can decrypt the challenge by loading the “EK” and the object onto the TPM and asking the TPM to returnthe challenge. The TPM will decrypt the challenge using the private “EK” and validate that thecredentialed object (public and private) is loaded on the TPM. If so, the TPM has validated that theproperties of the object match the properties required by the credential provider and the TPM will returnthe challenge.
This process preserves privacy by allowing TPM objects to have credentials from the credential provider
that are not tied to a specific TPM. If the object is a signing key, that key can be used to sign attestations,and the credential can assert that the signing key is on a valid TPM without disclosing the exact TPM.
A second property of this protocol is that it prevents the credential provider from proving anything about
the object for which it provided the credential. The credential provider could have produced the credential
with no information from the TPM as the TPM did not need to provide a proof-of-possession of any private
key in order for the credential provider to create the credential. The credential provider can know that thecredential for the object could not be in use unless the object was on the same TPM as the “EK”, but thecredential provider cannot prove it.
24.3

Protection of Credential

The credential blob (which typically contains the information used to decrypt the challenge) from thecredential provider contains a value that is returned by the TPM if the TPM2_ActivateCredential() issuccessful. The value can be anything that the credential provider wants to place in the credential blobbut is expected to be simply a large random number.
The credential provider protects the credential value (CV) with an integrity HMAC and encryption in muchthe same way as a credential blob. The difference is, when seed is generated, the label is “IDENTITY”
instead of “DUPLICATE”.

Page 162
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
24.4

Trusted Platform Module Library

Symmetric Encrypt

A seed is derived from values that are protected by the asymmetric algorithm of the “EK”. The methods ofgenerating the seed are determined by the asymmetric algorithm of the “EK” and are described in anannex to this TPM 2.0 Part 1. In the process of creating seed, the label is required to be “INTEGRITY.”NOTE

If a duplication blob is given to the TPM, its HMAC key will be wrong and the HMAC check will fail.

Given a value for seed, a key is created by:symKey ≔ KDFa (ekNameAlg, seed, “STORAGE”, name, NULL , bits)

(44)

where

ekNameAlg

the nameAlg of the key serving as the “EK”

seed

the symmetric seed value produced using methods specific to the type ofasymmetric algorithms of the “EK”

“STORAGE”

a value used to differentiate the uses of the KDF

namethe Name of the object associated with the credential

bits

the number of bits required for the symmetric key

The symKey is used to encrypt the CV. The IV is set to 0.

encIdentity ≔ CFBekSymAlg (symKey, 0, CV)

(45)

where

24.5

CFBekSymAlg

symmetric encryption in CFB mode using the symmetric algorithm of the
key serving as “EK”

symKeysymmetric key from (44)CVthe credential value (a TPM2B_DIGEST)HMAC

A final HMAC operation is applied to the encIdentity value. This is to ensure that the TPM can properly
associate the credential with a loaded object and to prevent misuse of or tampering with the CV.
The HMAC key (HMACkey) for the integrity is computed by:

HMACkey ≔ KDFa (ekNameAlg, seed, “INTEGRITY”, NULL, NULL, bits)

(46)

where

ekNameAlg

the nameAlg of the target “EK”

seed

the symmetric seed value used in (44); produced using methods specificto the type of asymmetric algorithms of the “EK”

“INTEGRITY”

a value used to differentiate the uses of the KDF

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 163
December 24, 2020

Trusted Platform Module Library
bitsPart 1: Architecture

the number of bits in the digest produced by ekNameAlg
Even though the same value for label is used for each integrity HMAC, seed is created in a mannerthat is unique to the application. Since seed is unique to the application, the HMAC is unique to theapplication.

NOTE

HMACkey is then used in the integrity computation.
identityHMAC ≔ HMACekNameAlg (HMACkey, encIdentity || Name)

(47)

where

HMACekNameAlg

the HMAC function using nameAlg of the “EK”

HMACkeya value derived from the “EK” symmetric protection value according toequation (46).

encIdentity

symmetrically encrypted sensitive area produced in (45)Name

the Name of the object being protected

The integrity structure is constructed by placing the identityHMAC (size and hash) in the buffer ahead ofthe encIdentity.

size

Marshal the CV into a TPM2B_DIGEST

Credential Value

size

Summary of Protection Process

Credential Valuesize size

24.6

Credential Value

Using methods of the asymmetric “EK”, create a seed value

Create a symmetric key for encryption:

symKey ≔ KDFa (ekNameAlg, seed, “STORAGE”, Name, NULL , bits)
Create encIdentity by encrypting the CV

encIdentity ≔ CFBekSymAlg (symKey, 0, CV)

Compute the HMAC key

HMACkey ≔ KDFa (ekNameAlg, seed, “INTEGRITY”, NULL, NULL, bits)
Compute the HMAC over the encIdentity from step 4

outerHMAC ≔ HMACekNameAlg (HMACkey, encIdentity || Name)outerHMAC

Figure 26 — Creating a Identity Structure

Page 164
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Object Attributes
25.1

Base Attributes
Introduction

Three attributes are used to determine how the TPM can use an object. These attributes are designatedas restricted, sign, and decrypt. The Boolean combinations of these attributes are used to express the fullrange of behaviors for objects.
Restricted Attribute
When the restricted attribute of a key is SET, the key can only operate on other objects that follow strict,but simple, format rules. A restricted key is not usable in all commands that use a key of that type. The
restrictions on each type of key are explained in the clauses describing the sign and decrypt attributes.
The restricted attribute has no meaning when applied to an object that has both sign and decrypt CLEAR
and restricted is required to be CLEAR for those objects.
Sign Attribute
This attribute can apply either to symmetric or asymmetric keys. A signing key uses its sensitive area key
to sign data. The signature is returned by the TPM.
An asymmetric signing key can perform signing according to the key family (such as, RSA or ECC) andthe signing method selected. An external entity can use the public portion of an asymmetric key tovalidate that the information was signed by someone with knowledge of the private portion of the key.
For a symmetric cipher object, this attribute and the object’s mode determines whether the key can
encrypt or sign (SMAC).
A symmetric key that can sign is used for performing an HMAC or an SMAC computation. This signature
can be checked by another entity that knows the HMAC or SMAC secret key in order to validate thesource of the information.
A restricted signing key can only sign a digest that has been produced by the TPM. The digest can beover externally supplied data or an internally generated structure. An internally generated structure that is
to be signed will have the characteristic TPM_GENERATED_VALUE as the first octets in the structure to
be hashed and signed. When the TPM generates a digest over externally provided data, the TPM
validates that the first octets of the data are not equal to the TPM_GENERATED_VALUE. When a digest
is signed by a restricted signing key, there is no ambiguity about whether or not the signed data was
generated by the TPM.
A restricted signing key is occasionally referred to in this specification as an Attesting or Attestation Key.
Decrypt AttributeAn asymmetric decryption key uses the private asymmetric key in its sensitive area to decrypt data blobs
that have been encrypted using the public portion of the key. A symmetric decryption key uses the key inits sensitive area to decrypt data that has been encrypted by that key.
A key that has both decrypt and restricted attributes SET only accepts data that has a specific structure.
The encrypted data block must have as its first element an integrity value for the remainder of the
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 165
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

structure. This integrity value is an HMAC of the encrypted data. This format allows the TPM to prevent
misuse of the restricted decryption keys that are the basis of the protected storage hierarchy.
If the sensitive data is part of a child object, the symmetric and HMAC keys are derived from thesymmetric seed value (seedValue) in the sensitive area of the Storage Parent. If the sensitive data is a
duplication or certification blob, the symmetric and HMAC keys are derived from a single use seed. That
seed is then protected using the asymmetric public key of the intended recipient of the protected blob.
When loading a protected blob, the TPM validates the integrity value before decrypting the data. The only
way that the integrity value can be correct is if it were created by some entity with access to theunencrypted sensitive data.
NOTE

The specific threat scenario that is addressed by this scheme is that an attacker will use a protectedblob in a command that is not appropriate for that blob. For example, an attacker can load thesensitive portion of an asymmetric key and attempt to access the sensitive area using
TPM2_Unseal(). The TPM will unseal data, but not a key. The attacker can attempt to modify the
public area of the key in order to trick the TPM into thinking that the protected blob contains asealed data rather than a private key. The integrity value prevents these deceptions.

A restricted decryption key is often referred to in this specification as a Storage Key.

Page 166
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Uses
Table 24 shows the combinations of an object’s functional attributes and describes the resulting
properties.

sign

decrypt

restricted

Table 24 — Mapping of Functional Attributes

Description

0

0

0

A data blob. Can be accessed using TPM2_Unseal().
NOTE: This attribute set can only be used for a keyedHash object.

0

0

1

Not allowed. The TPM will not load or create an object with this setting.

0

1

0

A key that can be used in any operation that requires a decryption key, except that the key cannot
be a storage key.

0

1

1

Indicates that only the default schemes and modes of the key can be used
In this specification, key with these properties is referred to as a Parent Key. Asymmetric keys andsymmetric keys with these attributes are Storage Parents, and keyedHash objects with these
attributes are Derivation Parents. The TPM only allows keys with these attributes to be used on
objects that have a specific structure. For Storage Parents, use includes create, load, and activate
credential.

1

0

0

Indicates a key that can be used with any signing operation including quote, certify, and sign. The
recipient of signatures generated by this key should be aware that quotes and certifications can beforged so the trust would not be in the key but in the entity that knows the key authorization value.
If use with object type TPM_ALG_KEYEDHASH, then the key can be used for HMAC operations.

1

0

1

This combination indicates a key that can sign any digest that the TPM has created. The TPM only
signs a digest over externally provided data that did not have as its first octets
TPM_GENERATED_VALUE. This key can be used reliably for quoting, certifying, and signing. No
signing command is prohibited for this type of key.
Only the default schemes and modes of the object can be used.

1

1

0

A general-purpose key that can be used with any command that requires a key as long as thecommand is compatible with the key algorithm. However, this key cannot be a Storage Key (theparent of other keys).

1

1

1

This type of key is currently not supported because use of a signing key as a storage node could
prevent an application from being able to use the TPM in a way that is compliant with FIPS.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 167
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Table 25 shows the correspondence between the TPM 1.2 method of identifying key properties and themethod in this specification.

TPM 1.2 Namesigndecrypt

restricted

Table 25 — TPM 1.2 Correspondence

TPM_KEY_SIGNING

1

0

0

In TPM 1.2, keys had restricted schemes. In this specification, thescheme is defined in the command.

TPM_KEY_STORAGE

0

1

1

The functional properties are nearly the same as TPM 1.2. This key
could only be used to protect and unprotect items in a Protection
hierarchy.

Comments

TPM_KEY_IDENTITY

1

0

1

In TPM 1.2, an Identity key was highly constrained and could not, forexample, sign a structure that was not produced by the TPM. In thisspecification, the restricted signing key can sign (within the limits
defined in clause 25.1.3) a digest produced by the TPM. This allows,for example, an Attestation Key to sign a PKCS#10 certificate
request.

TPM_KEY_AUTHCHANGE

-

-

-

This is not used in this specification and its use was deprecated in
TPM 1.2. The functionality is provided by session encryption.

TPM_KEY_BIND

0

1

0

Functionality is roughly equivalent between the TPM 1.2 type and theunrestricted decryption key. The specification would use
TPM2_RSA_Decrypt() in place of the TPM 1.2 TPM_Unbind().

TPM_KEY_LEGACY

1

1

0

Use of these keys is only constrained by the key family properties.
For example, an ECC key will not perform TPM2_RSA_Decrypt().

TPM_KEY_MIGRATE

0

1

1

A Storage Key can be the object of a re-wrap if the new parent isallowed within the policy for the object. The policy for duplication of
the object is always visible in the public area.

0

0

Sealed Data

25.2

0

A blob containing user defined data

Other Attributes
fixedTPM and fixedParent

These attributes are described in detail in clause 23.
stClearThis attribute indicates an object that will need to be reloaded after any Startup(CLEAR). Objects can beloaded into the TPM and their context saved by the TPM resource manager. Normally, these saved
contexts can be reloaded at any time before the next TPM Reset. However, if this attribute is SET, thenthe saved context associated with the object will be invalidated on each TPM Restart as well as on TPM
Reset.
An object that has this attribute SET cannot be made persistent.

Page 168
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibrarysensitiveDataOrigin
The meaning and allowed settings for this attribute are different for Created and Derived Objects. For a
Derived Object, this attribute is required always to be CLEAR. For a Created Object, this attribute is SET
if the sensitive data of the object is to be generated by the TPM.
NOTE 1

The reason that sensitiveDataOrigin is to be CLEAR for a derived object is that it is impractical touse it to indicate anything about the provenance of the seed value used in deriving an object. The
only case in which the sensitiveDataOrigin of the Derivation Parent might reasonably be ref lected in
the derived key is when sensitiveDataOrigin and fixedTPM are both SET in the parent. For all othercases, there is no way for the TPM to provide any assurance about the setting ofsensitiveDataOrigin. However, for a derived key with fixedTPM SET, it is a relatively simple matterto check the setting of this attribute in the Derivation Parent. Rather than add to the TPM thecomplexity of validating that a Derivation Parent has the correct combination of attributes to allow
this attribute to be SET, it was decided to require that this attribute be CLEAR rather than ignored.
This is because this attribute does not change the way that Object derivation takes place as it doeswith Object creation.

When a symmetric object (TPM_ALG_KEYEDHASH or TPM_ALG_SYMCIPHER) is created, the caller
can provide the secret data or have the TPM generate it. If the TPM is to be the source of the data, thenthe caller will SET this attribute. Otherwise, this attribute will be CLEAR, and the caller-provided data will
be used.
When an asymmetric object is created, this attribute must be SET. The public part of an asymmetricobject is determined by its private key. If the caller has control over both the public and sensitive areas,then the TPM cannot ensure that the key is statistically unique. This is not an issue unless the object also
has fixedTPM SET. One of the assumptions of a fixedTPM object is that it is statistically unique. This
would not be the case for an asymmetric key if the caller provided the data. To avoid the possibility ofcreating a fixedTPM object on multiple TPMs, an asymmetric key is required to have its private key
generated by the TPM or the object can be imported. If it is imported, fixedTPM will not be SET.
“NOTE 2

The requirement that sensitiveDataOrigin be SET for asymmetric objects is enforced indirectly.
When an asymmetric key is created, the caller is not allowed to provide the sensitive data of thekey. Because the caller does not provide the sensitive data, sensitiveDataOrigin is required to be
SET. Since this relationship is only checked when the object is created, sensitiveDataOrigin isallowed to have any setting when an object is loaded or imported.

userWithAuth
This attribute indicates that the object's authValue can be used to provide the USER role authorizations
for the object. If this attribute is CLEAR, then USER role authorizations can only be provided by satisfying
the object's authPolicy in a policy session. A policy session can be used for USER mode authorizations
when this attribute is SET or CLEAR.
adminWithPolicy
This attribute indicates that authorization for an action requiring the ADMIN role requires that the
authPolicy of the object be satisfied. If this attribute is CLEAR, then the authValue can be used in an
HMAC session to perform operations that require ADMIN role.
As with USER role authorizations, any ADMIN role action can be authorized with a policy session thatsatisfies the authPolicy.
The primary reason for having a set of operations that require ADMIN role is to allow each of the actions
to be individually controlled. When a policy is used for an ADMIN role action, the policy must contain acommand that sets the commandCode for the policy to the specific command. This allows each ADMIN
role action to be individually enabled and controlled without having to group them.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 169
December 24, 2020

Trusted Platform Module LibraryPart 1: ArchitecturenoDA
If this attribute is SET in an object, then authorization failures of the object will not invoke dictionary attack
protections. In addition, actions on an object with this attribute SET are not subject to lockout. This
attribute is used to ensure that access to objects used by the OS is not blocked due to actions by users.
An OS would be expected either to use objects with well-known values or to use high-entropy
authorization values. In neither case is dictionary attack protection required.
encryptedDuplication
If this attribute is CLEAR, then an object can be duplicated with newParentHandle set to TPM_RH_NULL,
which means that there is no outer wrapper for the object. If the caller does not specify an inner wrapper,
then the object can be exported with this sensitive area in the clear.
While the entity that controls duplication is expected to be trusted to maintain the confidentiality of thesensitive area of a key during duplication, conformance to some standards requires that the sensitive
area be encrypted when it leaves the TPM and reliance on the caller is not adequate for those standards.
This attribute provides a method of producing objects that conform to those standards.
NOTE

It is understood that the duplication authority can still arrange to have access to the sensitive area of
the key by creating a software key and having the TPM duplicate to that key.

Page 170
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Object Structure Elements
26.1

Introduction

The TPM is intended to provide a means of creating a Storage hierarchy to protect data and keys (keysgenerated by the TPM or some other entity). Each of these objects (keys and data) has two components.
The first is a public area that contains the attributes of the object and a public identity. The second is thesensitive area that contains the elements of the object that require TPM protections. These elements
include an authorization value, one or more secret key values, and, in some cases, sealed data values.
The structure definitions for both the public and sensitive areas of an object define how the information is
to be arranged when it crosses the TPM interface. The organization of these structures as they exist
within the TPM is at the discretion of the TPM vendor. However, the actions of commands in thisspecification are defined in terms of these presumptive structures and any implementation will need to
produce equivalent results.
26.2

Public Area

The public area contains the information for identification of an object and its properties. The fields of the
public are listed and described in Table 26.
Table 26 — Public Area Parameters
Parameter

Description

typeThis identifies the type of the object. An algorithm ID is used as the type identifierbecause the structures contain parameters that are specific to the types of operations
that can be performed on or with the object. For example, an RSA type would contain an
RSA key pair that could be used for operations defined for RSA. An AES type would be
used for symmetric encryption or decryption.

nameAlg

This is a second algorithm ID that identifies the hash algorithm used for computing theName of the object.

objectAttributes

This contains the set of attributes of the object. These attributes are in five classes:
1) usage (sign, encrypt, restricted);2) authorization (userWithAuth, adminWithPolicy, noDA);3) duplication (fixedParent, fixedTPM, encryptedDuplication);
4) creation (sensitiveDataOrigin); and5) persistence (stClear).

authPolicy

This will contain the authorization policy for the object if one is defined. nameAlg is usedas the authPolicy hash algorithm,
NOTE

An object that is intended to be duplicated must have an authPolicy enabling the
duplication.

[type]parameters

The parameters of an object are dependent on the object type. For symmetric key object,
the parameters would indicate the size of the key and the default encryption mode. For
an asymmetric object (RSA or ECC), the parameters would indicate the key size, signingscheme, and symmetric encryption methods associated with the key.

[type]unique

The unique value of an object is also dependent on the object type. For an asymmetricobject, this will be the public key. For a symmetric object, this will be a value computedby hashing values in the sensitive area.

26.3

Sensitive Area

The sensitive area is related to the public area and contains the data that are required to be encrypted
when not in a Shielded Location on the TPM. It contains the authorization value and the item-specific
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 171
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

information such as the private or secret portion of a key. If an object is a Storage Key, it contains thesymmetric key that is used to encrypt its child object.
The structure of the sensitive area is shown in Table 27.
Table 27 — Sensitive Area Parameters
Parameter

Description

sensitiveTypeThis identifies the type of the object for this sensitive area. This value and the typeparameter of the public area are the same.

authValue

This is the authorization value for the object. It is an octet array of zero or more
octets. The authorization value for an object cannot have more octets than thedigest produced by the object’s nameAlg.

seedValue

This value is required for Storage Keys and is the seed used to generate theprotection values for the child objects of the Key.
This is optional for asymmetric keys that are not Storage Keys and is not used if
present.
For all other object types, this is an obfuscation value. It is hashed with thesensitive field to produce the unique value in the public area. Including this value inthe computation obfuscates unique so that the sensitive value cannot be
determined from the unique field.

[sensitiveType]sensitive

The contents of this parameter are dependent on sensitiveType.
For an asymmetric key, this will contain the private key.
For a symmetric key, this will be the key.
For an HMAC key this is the HMAC key value.
For a data object, this will be the sensitive data.

Each sensitive area created by the TPM contains some TPM-created data that makes each sensitive
area statistically unique. This will be either an asymmetric key or a large random number. The uniquevalues in the sensitive area are cryptographically linked to values in the public area in a way that makes
each public area statistically unique. The fact that a sensitive area is statistically unique andcryptographically linked to a public area ensures that a TPM can detect any attempt to substitute thesensitive area associated with a public area.
NOTE

26.4

Such a substitution would allow subversion of secrets -based policy authorization. If an attacker
could use an arbitrary sensitive area with a public area with a known Name, the attacker could
perform TPM2_PolicySecret() and cause the policyDigest to be updated with the chosen Name eventhough the attacker does not know the authorization value of the correct sensitive area.
Cryptographic linking of the sensitive area to the public area ensures that this type of attack is notpractical.

Private Area

When a sensitive area is not in a Shielded Location on a TPM, it is integrity-protected and symmetricallyencrypted. There is more than one format for a protected sensitive area but the loadable (TPM2_Load())
form of the protected sensitive area is called a “private” area.
NOTE 1Another format is a saved context.

The process of converting a sensitive area to a private area requires that the sensitive area be marshaledto its canonical form. This marshaled structure is then encrypted using a key derived from the Storage
Parent's symmetric seed (seedValue). An HMAC is performed over the data with the Name of theassociated sensitive area include in the HMAC. The combination of the HMAC and the encrypted
sensitive area is a key’s private area.
NOTE 2

Similar protections are used when an object is context saved or duplicated.

Page 172
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
26.5

Trusted Platform Module Library

Qualified Name

The Qualified Name (QN) of an object is the digest of all of the Names of all of the ancestor keys back to
the handle of the Primary Seed at the root of the hierarchy. The QN of an object includes the Name of theobject. The QN uses the Name hash of the current object to compute the QN for the object.
EXAMPLE 1

Assuming that key A is the Storage Parent of object B , then the Qualified Name of B (QN B ) is:

QN B ≔ H B (QN A || NAME B )The QN is not a digest of all of the entities loaded into the TPM. It is a digest of all of the entities in achain.
EXAMPLE 2

Assume two entities with public areas of A and B and different Name hash algorithms ( H A and H B ).
Also assume that they share the same parent P with a QN of QN P . The QN for A is QN A ≔ H A (QN P ||H A (A)) and the QN for B is QN B ≔ H B (QN P || H B (B)).

The primary purpose of the Qualified Name is to supplement the environmental information relating to
object creation and object use. The environment of an object includes its hierarchy. The hierarchy starts
at a Primary Seed and includes all ancestor keys for the object. The Qualified Name of an object isincluded in its creation data. The Qualified Name permits validation that a list of ancestor Names iscorrect. It is then possible to determine if, for example, all ancestor keys use sufficient cryptographic
strength. The Qualified Name of an object is included in its certification to indicate that the key is being
used in a different environment (ancestry) than the one in which it was created.
Both the Name and Qualified Name for a Primary Seed are the handle of the Primary Seed. If the parent
handle is TPM_RH_NULL, Name and QN are also TPM_RH_NULL. This makes the QN of a Primary
Object or Temporary Object equal to:

QN ≔ HnameAlg (A hierarchy handle || Primary Object Name)
NOTE

26.6

(48)

The creation data for an object includes both the Name and QN of the Storage Parent of that object.

Sensitive Area Encryption

When a sensitive area is in a loadable format (a private area), the symmetric encryption key is derived
from the secret seed (seedValue) of the parent.
When a sensitive area has been encrypted for duplication, the sensitive area is symmetrically encryptedwith a key that is protected using asymmetric methods associated with the new parent. Before aduplicated object can be loaded, it must be “imported” (TPM2_Import()) and encrypted using thesymmetric key derived from the secret seed of the new parent.
NOTE

Clause 30.3 describes the protections that are applied to a sensitive area when it is part of a saved
context.

All symmetric encryption of the sensitive area uses Cipher Feedback (CFB) mode.
The method of generating the encryption key and IV for the encryption is described in clause 22.
26.7

Sensitive Area Integrity

When an object is not in a Shielded Location, it is susceptible to modification through means other than
through a Protected Capability. An HMAC-based integrity scheme allows these modifications to be
detected. The integrity HMAC includes the sensitive data and some representation of the public area.
Inclusion of the public area preserves the binding between the two elements of the object.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 173
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The HMAC key is generated from the same seed that is used for generating the symmetric encryption key
and IV. The HMAC of the protected structure is required to be checked before the sensitive area isdecrypted.

Page 174
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Object Creation
27.1

Introduction

TPM2_Create(), TPM2_CreatePrimary() and TPM2_CreateLoaded() are used to create the objects (keysand data) that are part of a TPM’s Storage hierarchy. TPM2_CreatePrimary() is used to create Primary
Objects that are derived from a Primary Seed. TPM2_Create() is used to create Ordinary Objects that are
generated with values from the TPM RNG. TPM2_CreateLoaded() can be used to create a Primary or
Ordinary Object.
NOTE 1

TPM2_CreateLoaded() can also be used for Derived Objects. This is covered in more detail inclause 28.

Table 28 — Creation Commands
Creation command

TPM2_CreatePrimary()

TPM2_Create()

TPM2_CreateLoaded()Parent Handle TypePrimary Seed

Storage Parent

Primary
Seed

Storage
ParentDerivation
ParentCreated Object TypePrimary

Ordinary

Primary

Ordinary

DerivedPublic Area Returned

yes

yes

yes

yes

yes

Sensitive Area Returned

no

yes

no

yes

no

creationData Returned

yes

yes

no

no

no

Table 28 compares and contrasts the creation of objects by TPM2_CreatePrimary(), TPM2_Create(), andTPM2_CreateLoaded(). In particular, when creating keys:•

TPM2_CreatePrimary() – creates and loads Primary Objects for immediate use and provides
creationData.

•

TPM2_Create() – creates Ordinary Objects for later use (via TPM2_Load()). TPM2_Create() returns a
BLOB containing the sensitive area of an Ordinary Object and provides creationData.

•

TPM2_CreateLoaded() – depending on the type of the parent, generates and loads a Primary Object,
an Ordinary Object; or Derived Object.

Authorization to use the Parent is required in order to generate a child. Authorization to use a Primary
Seed is required in order to create a Primary Object.
All of the objects created by these commands are similar in most respects. For TPM2_Create() andTPM2_CreatePrimary(), the parameters required to create an object are the same for both commands.
They are:•a public area template,•the sensitive values,•

optional user-provided identification data, and•the optional creation PCR selection.

For TPM2_CreateLoaded(), the only parameters are the public area template and the sensitive values.
NOTE 2The user-data and PCR parameters are not used for TPM2_CreateLoaded() as it does not return thecreationData used for creation certification. For objects where the creation certification is necessary,
the TPM2_Create() or TPM2_CreatePrimary() functions are available.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 175
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Any type of object that can be created with TPM2_Create() can be created with TPM2_CreatePrimary() or
TPM2_CreateLoaded().
NOTE 3

TPM2_CreateLoaded() can be used for creation of asymmetric keys but it cannot be used forderivation of certain types of asymmetric keys. This limitation is because of the variability inalgorithms for some asymmetric key types (such as RSA).

The sensitive area of an Object created from a seed does not leave the TPM except in a saved context orby duplication. If a Primary Object is not context saved (and not persistent), it will need to be recreatedafter the next TPM2_Startup(). Even if context saved, if a Primary Object is not made persistent in the
TPM (TPM2_EvictControl()), it will need to be recreated after each TPM Reset.
27.2

Public Area Template
Introduction

A public area template describes the desired attributes of the object to be created. The TPM uses thistemplate to guide the creation of the new object.
The format of the template has to match the desired format of the object to be created, in all details. The
item-specific information (the unique field) will be replaced by the TPM in the creation process, but allother fields in the created object will be identical to those in the template.
In general, the fields in the public area are checked as if the object were being loaded under the Storage
Parent indicated in the creation command.
type
This parameter indicates the basic type of the object and determines the format of the parameters andunique fields. The type can indicate a symmetric key, an asymmetric key, or a data value.
The allowed values for type are: TPM_ALG_SYMCIPHER, TPM_ALG_KEYEDHASH, TPM_ALG_RSA,
or TPM_ALG_ECC.
NOTE

The list of types can change. If an algorithm ID is allowed for use as a public area type, it is denotedby an "O" in the "Type" column of the TPM_ALG_ID constants table published by the TCG.

nameAlg
The nameAlg parameter in the template is set according to the object type. If the object is a restricteddecryption key, then the object is required to have the same nameAlg as the Storage Parent. For all othercases, the nameAlg can be any supported hash algorithm.
In the case of TPM2_LoadExternal(), nameAlg is allowed to be TPM_ALG_NULL. When this value isselected, the TPM does not validate the cryptographic linkage between the public and sensitive portionsof the object. Since the nameAlg is TPM_ALG_NULL, the object has no Name.
NOTE

Certification of the key with no Name has no meaning as the certification will have no Name for thecertified object.

objectAttributes
These flags must be set according to the rules appropriate for loading the object. The required settings
are found in TPM 2.0 Part 2, in the definition of TPMA_OBJECT.

Page 176
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

authPolicy
If use of an object is to be gated by a policy (including PCR), the template will contain the policy hash.
Otherwise, this entry will be set to the Empty Policy.
parameters
This field contains parameters that describe the details of the object indicated in type.
For a Storage Key that has fixedParent SET in its objectAttributes, these parameters will be identical tothe parameters of the Storage Parent. For other objects, these parameters can vary according to the typeand application.
unique
The unique field of the template is the only field in the public area that is replaced by the TPM during theobject creation process. The caller can place any value in this field as long as the structure of the value isconsistent with the type field. That is, this field should be structured in the same way as the data that will
be placed in this field by the TPM. The caller can also set the size of this field to zero and the TPM will
replace it with a correctly sized structure.
27.3

Sensitive Values
Overview

The sensitive values that are provided when the object is created allow initial setting of the authValue forthe object and can provide some other object-sensitive value. The sensitive value can be an encryption
key or sealed data.
The sensitive values provided to the TPM in TPM2_Create() and TPM2_CreatePrimary() (the inSensitive
parameter) can optionally be encrypted using standard session-based encryption techniques. Since
session-based encryption allows use of a different session for authorization and encryption, the session
used for encrypting the authorization and other sensitive data does not have to be the same as theauthorization session for the Storage Parent of the newly created object. This ensures that the entity that
controls the Storage Parent does not automatically gain access to the secret values of a child.
userAuth
The userAuth value is the initial authValue for the created object. This value can be no larger than thedigest produced by the nameAlg of the object.
NOTEThis limitation ensures that any valid authValue will be usable on any TPM that can load the key. If
this limitation were not imposed, then some TPM might not be able to load a duplicated object
because the authValue was too large for the implementation.

data
This contains information that the caller wants to be incorporated in the sensitive part of the createdobject. This can be either a symmetric key or user data. If data is an Empty Buffer, then thesensitiveDataOrigin attribute of the template is required to be SET. If data is not empty, thensensitiveDataOrigin is required to be CLEAR.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 177
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

If the object type is TPM_ALG_KEYEDHASH and both sign and encrypt are CLEAR, then the createdobject is a Sealed Data Object and the TPM will return an error (TPM_RC_SIZE) if data is an Empty
Buffer.
If the created object is an asymmetric key and not a primary key, then data is required to be an Empty
Buffer and sensitiveDataOrigin in the template is required to be SET. For a primary key, data permits
personalization of the key with private data, data that can be provided as an encrypted parameter.
NOTE

27.4

If the caller were allowed to specify the private key, then for some types of asymmetric algorithms(such as, ECC) the actions of the TPM would not determine the Name of the object. Since the TPM
has no effect on the creation of such an object, the preferred means of having such a key become
part of a hierarchy is to import it with TPM2_Import().

Creation PCR

The PCR selection that is present in TPM2_Create() or TPM2_CreatePrimary() parameters is used to
select the PCR values that will best represent the environment in which the object was created. The
selection and the PCR are hashed according to the creation data algorithm and included in the creation
data (a TPM2B_CREATION_DATA) that is returned in the command response.
NOTE

27.5

When an Object is created, the TPM produces a ticket that it (the TPM) can use to verify that it
created the Object. This allows the TPM to certify that it created the Object(TPM2_CertifyCreation()).

Public Area Creation
Introduction

This clause describes how the TPM uses the parameters of TPM2_Create() and TPM2_CreatePrimary()
to set the values in the public area of the created object.
This clause does not describe the error conditions if the parameters are bad. That information is provided
in the description of TPM2_Create() and TPM2_CreatePrimary() in TPM 2.0 Part 3.
type, nameAlg, objectAttributes, authPolicy, and parameters
The TPM will validate that these parameters are consistent in the template and then copy them from
template into the created structure without modification.
unique27.5.3.1

Introduction

This parameter will contain a type-specific structure. It is used to ensure that each object has astatistically unique identity. The methods used to create unique ensure that it is cryptographically boundto the contents of the sensitive area. Creation of unique from the sensitive data uses non-invertible
processes (such as, a hash) so that the unique value does not compromise the confidentiality of thesensitive area.
The computation of unique uses one or more values in the sensitive area of the object. At least one of thesensitive area values will be provided by the TPM to ensure that unique is, in fact, unique. For
asymmetric keys, uniqueness is provided by the public key and the public key is mathematically linked tothe private key in the sensitive area.

Page 178
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

For symmetric objects (symmetric keys, HMAC keys, and data blobs), the key (or data) is hashed with a
TPM-generated obfuscation value and the resulting digest is used as the unique value.
There are two reasons for generating the unique parameter for symmetric objects in this way. The first isthat it protects the contents of the user-provided data. If the secret data has low entropy, then making theunique parameter a simple digest of that data would allow an offline attack to determine what the secretdata might be. The large, random, obfuscation value generated by the TPM is not known to an attacker,
which mitigates this threat.
The second reason for this method is that it prevents an attacker from stealing an object’s identity. If theidentity were not based on the contents of the sensitive area, then an attacker could create a sensitive
structure and associate it with the public area of any symmetric object. Having the sensitive area contain
information that can cryptographically link the sensitive area to the public area prevents this kind of
substitution.
The methods for producing unique for each of the object types are described in the remainder of clause
27.5.3.
27.5.3.2

TPM_ALG_KEYEDHASH

This type is used for an HMAC key or data block. The computation for unique for a KeyedHash object is:unique ≔ HnameAlg (obfuscate || key)

(49)

where

HnameAlghash using nameAlg from the object templateobfuscate

the contents of seedValue.buffer in the object's sensitive areakey

the contents of sensitive.bits.buffer in the object's sensitive area; this will
be either an HMAC key, a data blob, or a symmetric key.

27.5.3.3

TPM_ALG_SYMCIPHERThis type is used for a symmetric block cipher key. The unique value is computed as shown in (49).
27.5.3.4

TPM_ALG_RSA

For an RSA key, unique is the public modulus of the key. It is computed as described in clause B.8.
27.5.3.5

TPM_ALG_ECC

For an ECC key, unique is the public point computed as described in clause C.5.
27.6

Creation Entropy
Introduction

The reference code uses common algorithms for generating keys of a specific type. That is, there is one
algorithm for generating RSA keys, one for ECC keys, one for HMAC keys and one for symmetric keys.
NOTE

RSA and ECC are “if implemented.”

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 179
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

When calling these functions, the caller is allowed to indicate where the function should get entropy foruse in the algorithm. This allows these functions to be used for Primary, Derived, and Ordinary Objects
simply by changing the source of “entropy.”
Table 29 — Deriving Object Entropy
Object Type

Source of Object Entropy

Described in
ClausePrimary

DRBG initialized using a hierarchy seed and the hash of the input template27.6.3

Ordinary

TPM’s default DRBG

27.6.2Derived

KDF

28.4

Table 29 compares and contrasts the methods used to create the cryptographic values of primary,ordinary and derived keys.
•

A Primary Object is intended to be created multiple times, in the absence of any other key, with theminimum amount of persistent storage. As a result, the cryptographic values of primary keys are
created by instantiating a DRBG.

•

An Ordinary Object is intended to be created exactly once and persistently stored. As a result, thecryptographic values of ordinary objects are created by the DRBG that is used by default when a
TPM requires random data. This DRBG is seeded with entropy when the TPM was created andtopped-up with additional entropy added at intervals.

•

A derived key is intended to be derived multiple times from a parent key, and not persistently stored.
As a result, the cryptographic values of derived keys are created by applying a KDF and hashalgorithm specified in the Derivation Parent to the Derivation Parent’s symmetric key, using label andcontext values provided by the caller.
Entropy for Ordinary Objects

For an Ordinary Object, the caller would pass a NULL pointer. When the key generation function needs arandom number, it would pass that NULL pointer to the random number generator. Because the pointer is
NULL, the random number generator will use the default random number generator of the TPM which
produces numbers that are as random as the TPM is able to produce.
Entropy for Primary Objects
For a Primary Object, the caller would instantiate a deterministic random number generator (DRBG) andseed the DRBG with a primary seed, a template hash, and a use string. The key generation function
would pass this pointer to the random number generator which would use this state instead of the TPM’s
default state. This produces a sequence of bits that have as much entropy as the primary seed and whichhave a property that is required for generating a Primary Object – the DRBG state can be reinstantiatedeach time the same Primary Object is created.
Choice of the entropy generation for Primary Objects is a vendor option.
NOTE

27.7

The reference implementation uses a DRBG based on SP800 -90A in order to minimize complianceissues.

Sensitive Area Creation
Introduction

This clause indicates how the TPM creates the sensitive portion of an object (a TPMT_SENSITIVE).
Page 180
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The process for computing the contents of a sensitive area is determined by the type of the object,indicated in the type field of template.
Some of the sensitive area fields can contain data that is provided by the caller. Some of the fields arealways provided by the TPM. When a TPM-provided field is in a Primary Object, the TPM-provided data isalways derived, in some way, from the associated Primary Seed such that the same Primary Object canbe reproduced as long as the associated Primary Seed remains unchanged. For Ordinary Objects, animplementation can either get the TPM-provided data from the RNG or compute the fields of the object as
if it were a Primary Object, but with a random number used in place of a Primary Seed.
The performance difference between the two methods of producing asymmetric objects is negligible as
the majority of the work is in validating the choices rather than in generating them. For symmetric objects,
the difference might be worth having different methods for Primary and Ordinary Objects but there is anadded cost in development and testing that could offset the benefit of any slight performance advantage.
For Ordinary Objects, the method used for generating sensitive should be used for generating seedValue.
That is, if sensitive is generated by taking values from the RNG, then seedValue should be generated bytaking values from the RNG. If sensitive is generated by creating a random seed and using the methods
used for Primary Keys, then that same seed should be used for generating seedValue.
type
The type parameter of the object's sensitive area is a copy of the type parameter from the object's publicarea template.
authValue
The authValue of the object is copied from the userAuth field of the inSensitive parameter of commands
such as TPM2_Create(), TPM2_CreateLoaded,or TPM2_CreatePrimary(), or from newAuth incommands such as TPM2_ObjectChangeAuth.
When the TPM returns a TPM2B_PRIVATE structure, the TPM pads the TPM2B_AUTH to its maximum
size.
NOTE

This prevents the TPM from leaking the size of the authorization value in cases where trailing zeros
are stripped.

seedValue
For a symmetric object, seedValue field is used as an obfuscation value. It is also used to hold thesymmetric seed value for Storage Keys.
For an asymmetric key that is not a Storage Key, seedValue is not needed and the TPM will ignore thevalue if it is present.
For a Storage Key, seedValue is used as a seed for generating the integrity and confidentiality values forprotecting child objects of the key.
For all object types, when the TPM generates seedValue, it is the size of the digest produced by the
nameAlg of the object.
NOTE 1Presuming that the protection algorithms of a Storage Key are reasonably balanced (a requirement),
then this size of seed will provide adequate entropy required for prote ction of the child Object.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 181
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

For an imported symmetric object, seedvalue is required to be the size of the digest produced by the
nameAlg of the object.
For an imported Storage Key, seedvalue is required to be at least to be at least half the size of the digest
produced by the nameAlg.
NOTE 2This requirement is for backward compatibility .

For Imported asymmetric non-Storage Keys, seedValue is not required.
NOTE 3

The rationale for these requirements derive from the use of seedValue. When seedValue is used in ahash, it is the full size. When used in an HMAC, it can be half the size.

seedValue is generated using the “entropy” source used for the object type (see 27.6).
When creating a Primary Object in the Endorsement Hierarchy, it is required that the entropy source be
updated to reflect the current SPS. This allows the sensitiveValue to remain the same after a change of
the SPS but prevents any previously-generated Child Objects in the Endorsement Hierarchy from being
loaded after the SPS changes.
NOTE 3In the reference implementation, this is accomplished by reseeding the DRBG state with the proof
value of the storage hierarchy.

sensitive
27.7.5.1

Symmetric Objects

Symmetric objects have a type of TPM_ALG_SYMCIPHER or TPM_ALG_KEYEDHASH. For a symmetricobject, the sensitive object data can be provided by the caller or generated by the TPM.
If sensitiveDataOrigin attribute in the object template is CLEAR, then the sensitive data is provided by thecaller. If provided by the caller, the sensitive data will be in the data field of the inSensitive parameter of
TPM2_Create() or TPM2_CreatePrimary(). For TPM2_CreateLoaded(), if the Parent is a Derivation
Parent, then sensitiveDataOrigin is required to be CLEAR in the template.
If sensitiveDataOrigin is SET, it indicates that the TPM is the source of the sensitive data and the data
field of the inSensitive parameter is required to be an Empty Buffer.
A user provided symmetric key is required to be the size indicated by parameters.symDetail.keyBits.sym
in the template. It is the number of octets required to hold the number of bits indicated.
NOTE 1

If the key has fewer significant digits than necessary, pad octets of zero are required. The padoctets are added to the high-order end of the key.

A user provided HMAC key is not allowed to be larger than the smaller of the block size of the hashalgorithm or 128 octets. Limiting the size to 128 octets is for compatibility of structures between TPM.
NOTE 2

The HMAC algorithm requires that keys larger than the hash block size be hashed before use. This
may result in fewer bits of entropy in the HMAC key than expected by the caller. The TPM will notallow the caller to specify an overly large value for the HMAC key. If the caller desires to use alarger value, they have to perform the digest externally and pass the resulting digest to the TPM for
use as the HMAC key.

If not provided by the caller, sensitive is generated by the TPM. For a TPM_ALG_KEYEDHASH object,
the size is the digest size of the nameAlg of the object. For a TPM_ALG_SYMCIPHER object, the size isequal to (parameters.symDetail.keyBits.sym + 7) / 8.

Page 182
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
27.7.5.2

Trusted Platform Module Library

Asymmetric Objects

The sensitive field in an asymmetric key object is the private key. The key is generated in a way that is
specific to the algorithm and is described in an algorithm-specific annex of this TPM 2.0 Part 1.
EXAMPLE

27.8

RSA key generation is described in clause B.8 and ECC key generation is described in clause C.5.

Creation Data and Ticket

When it creates an object, the TPM also creates a data structure that describes the environment in which
the object was created. This data includes:•a digest of selected PCR at the time of object creation and a bit-map indicating the PCR that were
included in the list. The PCR selection is those PCR indicated in the call to TPM2_Create() andTPM2_CreatePrimary().

•

the locality at which the object was created•the nameAlg of the Storage Parent. If the parent is a Primary Seed, then the algorithm will be
TPM _ALG_NULL.

•

the Name of the Storage Parent. If the parent is a Primary Seed, then the Name will be the handleof the seed.

•

the Qualified Name of the Storage Parent. If the parent is a Primary Seed, then the Qualified
Name will be the handle of the seed.

•some additional data provided by the caller that is to be associated with the new object

In addition to these values, the TPM will create a ticket that will allow the TPM to validate that the creation
data was generated by the TPM.
The creation data will act as a form of certification of the object that is most useful when fixedTPM is
CLEAR in the created object. Without this information, it would not be possible to determine how theobject came to be in the hierarchy where it is found. When the object is moved, it would be up to the
duplication authority to provide some certification of the duplication process. If there is no creation data
indicating that the object was created in the place where it was found, and there is no certificate from the
duplication authority for the object, then it can be difficult to establish the trustworthiness of the object.
NOTE

27.9

In this case, the trustworthiness of the object refers to determ ining that the sensitive area of theobject has only ever been accessible by trusted entities such as other TPMs.

Creation Resources

When a Primary Object is created, it is also loaded in a TPM object slot and the handle is returned. If nofree object slot is available, the TPM will return TPM_RC_OBJECT_MEMORY.
When creating an ordinary object, the TPM may use an object slot as scratch memory in which it builds
the object. If the implementation does use this scheme and no object slot is available, then the TPM will
return TPM_RC_OBJECT_MEMORY.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 183
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Object Derivation
28.1

Introduction

This clause describes the differences between Object creation and Object derivation. If no difference isstated, then there is none.
The TPM2_CreateLoaded() command is used for derivation. This command can be used to create orderive any type of object with the type of Object determined by the type of the entity referenced by theparentHandle parameter. If parentHandle references a Primary Seed, then a Primary Object is created; ifparentHandle references a Storage Parent, then an Ordinary Object is created; and if parentHandle
references a Derivation Parent, then a Derived Object is generated.
NOTE

28.2

For a given template (inPublic), the same Primary Object is created by both TPM2_CreatePrimary()
and TPM2_CreateLoaded().

Derivation Parameters

For object derivation the TPM uses the sensitive value in a Derivation Parent as a key in a key derivation
function (KDF). The KDF that is to be used in Object derivation is a property of the Derivation Parent andcan include the hash algorithm to use in the derivation process.
KDFa (TPM_ALG_KDF1_SP800_108) is the only KDF that is currently supported b y the reference
code,

NOTE

Most KDFs require additional parameters in order to have different types of keys derived for different
applications. The TPM allows two additional parameters (label and context) to be provided in
TPM2_CreateLoaded(). These additional parameters can be provided in two ways: in the unique field of
the inPublic value, or in the data field of the inSensitive parameter. If provided in the unique field, thecorresponding value in the inSensitive.data field is ignored.
Since TPM2_CrealeLoaded() does not use the public attributes in the KDF, it can create child keys withthe same private key but different attributes.
NOTE

TPM2_PolicyTemplate() on the parent can be used to restrict the child attributes.

EXAMPLE

28.3

Once the parent is duplicated, one TPM can derive a key that can only be used for encryption and adifferent TPM can derive the same key that is restricted to be used for decryption. Or an HMAC key canbe restricted to signing on one TPM and verification on another.

Public Area Template

For TPM2_CreateLoaded(), a TPM2B_TEMPLATE is used for the inPublic parameter instead of a
TPM2B_PUBLIC. The difference in parameters is to allow overloading of the unique field in the inPublicparameter. For a TPM2B_PUBLIC, the unique field is unmarshaled based on the type of inPublic. For a
TPM2B_TEMPLATE, the inPublic is unmarshaled as a byte array and passed to the
TPM2_CreateLoaded() action code where it is unmarshaled based on the type of parent and type ofinPublic.
When using TPM2_CreateLoaded() to create a Primary or Ordinary Object, the caller should use thesame format for the unique field that would be used when creating the Object with TPM2_CreatePrimary()or TPM2_Create(). The derivation-specific format is required when parentHandle references a Derivation
Parent.
For object creation, sensitiveDataOrigin indicates to the TPM whether the caller is providing the sensitive
data or if the TPM is to generate it. For Object Derivation, the caller provides values that influence thePage 184
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Libraryderivation process, but the caller does not explicitly set the sensitive value. For this reason,
sensitiveDataOrigin is required to be CLEAR in the template for a Derived Object.
28.4

Entropy for Derived Objects
Conceptual Description

The ‘entropy’ for a Derived Object is provided by a protected value in the sensitive area of the derivation
parent (the sensitive value). That entropy, along with caller-provided values, is used in a KDF to spreadthe entropy across values in the derived object. Those derived values are the sensitive and seedValues.
The remainder of the Derived Object is provided by the template or computed from the two derived
values.
KDFa is used for the derivation. The parameters for the derivation are:KDFa (hashAlg, sensitive, [label,] [context,] 0, 8192)(1)

where:
hashAlg

the nameAlg of the derivation parent

sensitive

the sensitive value in the sensitive area of the derivation parentlabel

an optional string provided by the caller

context

an optional string provided by the caller

KDFa has a counter and a bits parameter that are set, as shown above, to 0 and 8192 respectively.
NOTE

In order to be compliant with SP800-108, the KDFa function will increment counter to 1 before using
it in the generation of the first HMAC block.

This call will cause the KDF to generate 1024 bytes of data, with the results of the first digest being themost significant bytes.
During the derivation process, the data is removed from the 1024-byte buffer as needed for each use.
The data is used from most significant byte to least significant byte with no bytes skipped. For most key
generations, a deterministic number of bytes will be removed for each of the derived fields (sensitive andseedValue).
Example 1

For a 128-bit AES key in a SYMCIPHER object having SHA -256 as its nameAlg, the most significant
16 bytes of the KDF data are used for the AES key and the next -most-significant 32 bytes are used
for the seedValue.

Example 2

For ECC, the TPM uses the method of FIPS 186-4 B.4.1 Key Pair Generation Using Extra Random
Bits. For a 256-bit ECC key, the most-significant 40 bytes are used to generate the private key and,if the nameAlg of the derived object is SHA-256, the next-most-significant 32 bytes will be used forthe seedValue.

In some cases, the number of bytes used for the sensitive value is indeterminate. This is because someof the generated values are unsuitable for the application and could need to be discarded. In such cases,
bytes are taken from the 1024-byte buffer until suitable values for sensitive have been found and the next
most significant bytes are used for seedValue.
Example 3

Not all 64-bit values are suitable for use as DES keys. When the derivation process produces on e ofthese values, the key will be discarded, and the next most significant bytes are taken from the 1024byte KDF buffer.

When suitable values for both sensitive and seedValue have been extracted from the 1024-byte KDF
buffer, the remaining bytes are discarded.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 185
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Implementation Alternatives
There are various ways to produce an implementation that is compatible with the conceptual description
above without actually having to generate 1024 bytes of data. Some examples are given here:•

An implementation may compute the number of bytes that will be needed to produce the sensitiveand seedValue and the KDF would only need to generate that number of bytes. The bits
parameter in the call to generate the data would still need to be 8192. In order to facilitate thistype of implementation, the CryptKDFa() function in the reference code has a blocks parameterthat limits the number of returned blocks, regardless of the size of the sizeInBits parameter.

•

An implementation may generate blocks on a demand basis. This is fairly complex but allows thederivation process to be used as if it were any other RNG. To implement this process, the callingparameters of the KDF are saved in a structure so that they are available for multiple calls. This
structure is passed to the functions that use a random number generator. When random bits areneeded, the generator checks the type of the random number generator context and, if it contains
KDF parameters, they are used in a call to the KDF. After each call, the counter value isincremented so that the net effect of generating one block at a time is the same as generating allof them at the same time. The additional complexity of this implementation is that it is requiredthat all of the bytes from the KDF be used in order, with none skipped. In order to deal with a callthat does not use a full block, a buffer is added to the KDF structure in which residual bytes are
saved. When a call is made to fetch bytes from the KDF, the residual buffer is checked first andany bytes in that buffer are returned before the KDF is called to produce additional bytes. If the
KDF produces a block and not all bytes are returned, the residual bytes are placed in the buffer.
This provides continuity of bytes as required by 28.4.1.

28.5

Derivation Process

The derivation process is required to be the same for all TPMs. That is, with the same inputs, all TPMs
will generate the same Derived Objects.
When generating a Derived Object, the TPM will create the entropy structure for a KDF and pass apointer to the structure to the function that creates Objects. The algorithm for generating an Object is as
described in clause 27.7.
NOTE

The method of generating RSA keys is highly variable and is normally chosen according to theconstraints of the application. In some cases , compliance is the overriding factor and in others,
performance can be the determining factor. Since no single algorithm seems to be optimum for all
the constraints and it would not be acceptable to require that TPMs implement one RSA key
generation for compliance and one for interoperability, the TCG has chosen not to support derivation
for RSA keys.

Page 186
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Object Loading
29.1

Introduction

An object is either a key or data that can be loaded into the TPM for use. An object must be loaded before
the TPM can use or modify the object. Loading can require that the USER role authorization for the
Storage Parent be provided
29.2

Load of an Ordinary Object

It is possible to load just the public portion of an object into the TPM (TPM2_LoadExternal()) or to load
both the public and private portions (TPM2_Load()). If the sensitive area is to be manipulated or used,then both portions are required to be loaded.
When loading an object, multiple consistency checks are performed. Among these checks:
Is the HMAC of the encrypted private area correct – this ensures that the sensitive area was not
modified, that the sensitive area and the provided public area are matched, and that the object is a
descendant of the Storage Parent.
Is the unique parameter of the public area cryptographically bound to the sensitive data – this isrequired to prevent improper association of a public area with a sensitive area. If this check were notdone, an attacker could use a public area that had a Name that is the same as a different object andassociate a different sensitive area with the public area. If the object were used in
TPM2_PolicySecret(), the attacker could get the TPM to create a policyDigest with any desired hashvalue.
EXAMPLEA legitimate policy uses signature validation of a key with Name1. An attacker could create an
object with Name1 (copy the data from the legitimate key) and then create a sensitive area that
had an authValue known to the attacker, instead of using TPM2_PolicySigned() to create thepolicy.

Are the attributes consistent – these values need to be checked even if the integrity check indicatesthat the values were not modified. This is because the object could have been created by software
using inconsistent values. The integrity could be good, but the values could be wrong.
If fixedTPM is SET, fixedTPM must also be SET in the Storage Parent.
NOTE

If fixedTPM is properly SET, then the other checks need not be made because the object isverified to have been created on the TPM that loaded the object, so the other attributes are
known to be correct.

If fixedParent is CLEAR, then fixedTPM must also be CLEAR.
If restricted is SET, only one of sign or decrypt can be SET.
29.3

Public-only Load

There are several cases, such as duplication or signature verification, when only the public portion of anasymmetric key can be loaded. The public-only load of an object requires that the caller associate theobject with one of the hierarchies. This association is needed when the key is used for signature
verification so that the TPM can determine which proof value to use in the ticket.
A public-only load occurs when the inPrivate parameter to TPM2_LoadExternal() has a size of zero.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 187
December 24, 2020

Trusted Platform Module Library
29.4

Part 1: Architecture

External Object Load

External Objects allow the cryptographic processes of the TPM to be used on keys that are not part of a
TPM hierarchy. The public portion of an asymmetric key can be loaded so that the TPM can be used tovalidate a signature. A symmetric key can be loaded so that the symmetric engines of the TPM can beused to encrypt or decrypt data.
TPM2_LoadExternal() is used to load an External Object. When only the public portion is loaded, theattributes of the object are arbitrary, but the structures are required to be consistent with the type. That is,
if an RSA signing key is loaded, the signing scheme must be a valid scheme for an RSA key.
When the sensitive portion of the object is loaded (such as, a symmetric key), the sensitive area is notencrypted by a Storage Parent but can be encrypted using parameter encryption. The fixedParent andfixedTPM attributes are required to be CLEAR when both parts are loaded. This check allows the object
to be used in any command that is valid for the type including certification.
NOTE

If an entity has access to both the public and sensitive portions of a key, then the entity could import
the key and then certify it.

An external object can be associated with a hierarchy when it is loaded. This allows creation of tickets
that are specific to a hierarchy in commands such as TPM2_VerifySignature().
If the hierarchy with which an External object is associated is disabled, the object will be flushed. If theassociated hierarchy is disabled when TPM2_LoadExternal() is called, the object will not load.

Page 188
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryContext Management
30.1

Introduction

To allow the TPM to be shared among many applications, the TPM supports context management. The
objects, sequence objects, and sessions used by an application may be loaded into the TPM whenneeded and saved when a different application is using the TPM. The TPM Resource Manager (TRM) is
responsible for swapping the contexts so that the necessary resources are present in the TPM whenneeded.
There are two types of contexts: those associated with Transient Objects, and those associated withauthorization sessions.
The four commands used to manage the contexts are1) TPM2_ContextSave() – the TPM integrity protects, encrypts, and returns the context associated witha handle,2) TPM2_ContextLoad() – allows a previously saved context to be loaded to TPM RAM and have ahandle assigned,3) TPM2_FlushContext() – the context information associated with the specified handle is erased from
TPM RAM, and
4) TPM2_EvictControl() – allows the owner or the platform firmware to designate objects that are toremain TPM-resident over TPM2_Startup() events. This command will return a new handle.
A saved context is cryptographically bound to a specific TPM so that it may not be loaded on a different
TPM. This binding is provided by using a statistically unique proof value in the generation of theprotection values for a context (see 30.3 and 30.3.2). When the proof value of a hierarchy changes,
saved object contexts belonging to that context can no longer be loaded into the TPM. The proof value fora context will change when its Primary Seed changes. Additionally, ehProof will change when either the
SPS or EPS changes.
NOTE 1In the reference implementation, ehProof is a non-volatile value from the RNG. It is allowed that theehProof be generated by a KDF using both the EPS and SPS as inputs. If generated with a KDF, theehProof can be generated on an as-needed basis or made a non-volatile value.

Saved contexts for all objects and sessions are invalidated on a TPM Reset. In the reference
implementation, the encryption keys for contexts are changed by TPM Reset so previously saved
contexts may no longer be loaded. Saved session contexts remain valid until the session is closed, or
TPM Reset. If the stClear attribute of an object is SET, then saved contexts for the object are invalidatedon either TPM Reset or TPM Restart (that is, any time the TPM does a Startup(CLEAR). If the stClear
attribute of an object is CLEAR, then the saved contexts for that object are valid and may be loaded into
the TPM until the next TPM Reset.
NOTE 2In the reference design, when an object context is saved, the current value of clearCount is placedin the context. When the context is loaded, if the object is a stClear object, the value in the object iscompared to the current value of clearCount. If they are not the same, then the context load fails.

Objects and sessions are not retained in TPM memory after a TPM2_Startup() and it is necessary for the
TRM to save the contexts for any session or object that is to be useable after TPM Restart or TPM
Resume.
NOTE 3

The TPM might lose power between a TPM2_Shutdown(TPM_SU_STATE) and the subsequent
TPM2_Startup(). With respect to context preservation, the TPM behavior is defined to be the same
whether the TPM loses power or not.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 189
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The structure of a saved context TPM2B_CONTEXT_DATA may be defined by the vendor, but a saved
context is required to have its integrity and confidentiality protected by cryptographic means. Parts 3 and
4 of this specification implement the normative requirements for providing confidentiality and integrity
protection for saved contexts. These protections are described in more detail in subsequent parts of thisclause 30.
NOTE 430.2

The algorithms chosen for integrity and confidentiality protection of a saved context are vendor
specific. However, the cryptographic strengths of the algorithms used are required to be the highestof any algorithm of the same type implemented on the TPM.

Context Data
Introduction

The data structure TPMS_CONTEXT returned by TPM2_ContextSave contains context metadata as wellas the actual context TPM2B_CONTEXT_DATA. The context metadata contains:•a sequence number,•a handle, savedHandle, and

NOTE

•

For Transient Objects, this savedHandle in a saved context data structure is not the same as thehandle used by the TPM to reference loaded objects and b y TPM commands to describe the object
being operated on.

a hierarchy selector.

The actual context contains:•

an integrity HMAC, and•an encrypted data blob.

The structure of the metadata is normative. The internal structure TPMS_CONTEXT_DATA of the actual
context is vendor specific. The encrypted data blob contains the data necessary to reconstruct the fullobject or session context in the TPM. The other fields are defined in the remainder of this clause 30.2.
The structure of the context contains both confidential and non-confidential data. This specification
requires encryption of the confidential data. The TPMS_CONTEXT structure is normative. The structureof the enclosed TPMS_CONTEXT_DATA is vendor-specific, and its confidential data must be encrypted.
Sequence Number
New protection values are generated each time a context is saved. The protection values are an HMAC
key, a symmetric key, and an initial value. The values are made unique by including a counter value inthe generation process (see 30.3 and 30.3.2). The counter value used for the context is stored in thesequence number field of the context structure. Two counters are used for generating the sequencenumbers. One counter is used for transient and sequence object contexts. A second counter is used forsession contexts.
There are two counters used to provide sequence numbers. The counter (objectContextID) provides
sequence numbers for Transient Objects. This counter is incremented each time an object context is
saved. The counter (contextCounter) is used to provide sequence numbers for sessions and increments
when a session context is created or loaded (its behavior is described in more detail in clause 30.5).
When creating the context structure, the TPM sets the sequence parameter to the value of the counterused in the generation of the protection values for the context.

Page 190
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

When a context is loaded, (TPM2_ContextLoad()), the TPM checks that the sequence parameter is in a
viable range before starting the operation. For an object, the viable range is any number that is less thanthe current value of the object sequence counter. For a session, the sequence number must also be lessthan the session sequence number, but it must also be greater that the sequence number minus theallowable range for session sequence number.
In the reference implementation, objectContextID is a 64-bit counter that is initialized to zero at startup
and is expected to never overflow. The size is platform-specific.
EXAMPLEFor purposes of this example, assume that the sequence counter value is only 16 bits and that thesession counter indicates the last assigned session context had a value of 10 10 16 . It would then be
an error if the sequence parameter in a loaded session context is greater than 10 10 16 . Assume
further that the TPM only allows a range of 256 between session values (explanation in 30.5). Thenit would be an error if the sequence parameter of the session in TPM2_ContextLoad() is less than
10 10 16 – 01 00 16 = 0F 10 16 ; and the TPM will not load the context.

HandleThe savedHandle number for a context indicates the type of the context (object or authorization session).
The type of the context is used to determine how to reconstruct the protection values for validation of thecontext. If the savedHandle value in the context is changed by software, the context will not load.
For a session, the same handle is assigned to the context whether the context is loaded in the TPM or ina saved context. That is, savedHandle is the same as the handle the TPM uses to refer to the session. A
session handle will have an MSO of TPM_HT_HMAC_SESSION (0216) or TPM_HT_POLICY_SESSION(0316). The range of values in the handle index (the low-order three octets of the handle) is TPM
dependent. In the reference implementation, the low order bits of the session context handles fall within arange from 0 to MAX_ACTIVE_SESSIONS – 1 and the TPM will generate an error and do no further
processing of the context if the handle is outside of this range.
A savedHandle MSO of TPM_HT_TRANSIENT (8016), indicates that the context is an Object or sequenceobject. For an object, the savedHandle parameter of the context structure does not indicate the handle
value used by the TPM to reference the object (when a Transient Object context is not on the TPM, theTPM retains no information about that context). Therefore, the savedHandle value is not used forTransient Object contexts in the same way that it is used for session contexts. Instead, the savedHandle
is used to indicate the type of the Transient Object context.
Three savedHandle values are defined for Transient Object contexts:
1) 00 00 0016 – indicates a Transient Object that does not have the stateClear property;
NOTE

An Object has the stateClear property when stClear is SET in the Object or in any of its ancestor
keys.

2) 00 00 0116 – indicates a sequence Object (see 32.4.5); and3) 00 00 0216 – indicates a Transient Object that has the stateClear property.
EXAMPLEA sequence Object will have a 32-bit handle value of 80 00 00 01 16 .

If the savedHandle type is TPM_HT_TRANSIENT, the TPM will not generate or load a context with anyother value besides the three values described above for the handle’s index.
Objects that have the stateClear property are invalidated by Startup(CLEAR). To enforce this, the TPM
will include clearCount in the integrity value of the Object.
TPM processing of contexts with savedHandle values of 80 00 00 0016 or 80 00 00 0116 is the same. The
reason for differentiating sequence Objects is to identify the context for the convenience of the TPM
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 191
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

resource manager (TRM). The TRM needs to manage sequence objects differently from other Transient
Objects. Because the context of a sequence object changes each time the sequence is updated, thecontext needs to be saved each time the context is used. The context of a Transient Object does notchange on use. Therefore, the TRM can optimize by saving the Transient Object context only once.
Hierarchy
The hierarchy parameter of the context indicates which of the hierarchy proof values are used in thecreation of the protection values for the context. For objects, this value is determined by the hierarchy ofthe object and may be TPM_RH_NULL for a Temporary Object. Sequence objects and sessions are in
the Null hierarchy.
30.3

Context Protections
Context Confidentiality Protection

A symmetric block cipher is used to protect the confidentiality of a saved context. The algorithm isselected by the TPM vendor but is required to have the highest security strength of any symmetric blockcipher implemented on the TPM.
When the context is created by TPM2_ContextSave(), the value of sequence is stored in the
TPM2B_CONTEXT_SENSITIVE context before it is encrypted. When the context is loaded, the value ofsequence is compared to the value in the loaded TPM2B_CONTEXT_SENSITIVE context after it isdecrypted. If the values are not the same, then the TPM will enter failure mode as this is symptomatic of a
specific type of power analysis attack.
The symmetric key and IV are regenerated when a context is loaded. It is required that the symmetric key
and IV not be generated until the context integrity has been validated.
NOTE 1This restriction prevents simultaneous power-analysis attacks on the integrity and encryption valuesof a context. Since the integrity is checked first, no attempt is made to create the symmetric key if
the integrity check fails.

KDFa() is used to generate the symmetric encryption key and IV for context encryption. The parametersof the call are:(symKey, symIv) ≔ KDFa (hashAlg, hProof, vendorString, sequence, handle, bits)

(50)

where

hashAlga hash algorithm chosen by the vendor

hProofthe proof value associated with the hierarchy associated with the context

vendorStringa value used to differentiate the uses of the KDF

sequence

the sequence parameter of the TPMS_CONTEXT

handlethe handle parameter of the TPMS_CONTEXT

bits

the number of bits needed for a symmetric key and IV for the context
encryption

NOTE 2The value of vendorString is required to be different from any other label string used in a KDFa ()call. The reference implementation uses “CONTEXT_ENC RYPT”

NOTE 3The nullProof is used as the hProof value for a context in the Null hierarchy so that the encryption
keys do not repeat and so that they change on each TPM Reset.

Page 192
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The key and IV produced in (50) are used to encrypt the object or session context

encContext ≔ CFBsymAlg (symKey, symIv, context)

(51)

where

CFBsymAlg

symmetric encryption in CFB mode using a symmetric algorithm chosen
by the TPM vendor

symKeysymmetric key from (50)symIv

IV from (50)context

the context being protected (a TPM2B_CONTEXT_DATA)NOTE 4The size field and the buffer field of context are encrypted.

Context Integrity Protection
The integrity of a saved context is protected by an HMAC using a hash algorithm selected by the TPM
vendor. The hash algorithm chosen is required to have the highest security strength of any hashalgorithm implemented on the TPM (see the description of TPM_PT_CONTEXT_HASH in TPM 2.0 Part
2).
The HMAC is constructed using the proof value associated with the hierarchy to which the object belongs.
Since the proof value changes when the associated Primary Seed changes, HMAC validation for apreviously saved context will fail when the associated Primary Seed changes; and that context may nolonger be loaded. Other values in the HMAC computation serve to invalidate other context subsets
without necessarily invalidating them all.
EXAMPLEThe clearCount value is included in the HMAC of a context for an object with the stClear attribute sothat the context will be invalidated on each TPM Restart as well as each TPM Reset.

The only TPM state change that invalidates all saved contexts is TPM Reset.
Sessions, Sequences, and Temporary Objects are in the “null” hierarchy.
The HMAC integrity computation for a saved context is:contextHMAC ≔ HMACvendorAlg (hProof, resetValue { || clearCount}|| sequence || handle || encContext)

(52)

where
HMACvendorAlg

HMAC using a vendor-defined hash algorithm

hProofthe hierarchy proof as selected by the hierarchy parameter of the
TPMS_CONTEXT

resetValueeither a counter value that increments on each TPM Reset and is notreset over the lifetime of the TPM; or a random value that changes oneach TPM Reset and has the size of the digest produced by vendorAlg

clearCounta counter value that is incremented on each TPM Resume and may be
incremented or set to zero on TPM Reset. This value is only included if
the handle value is 80 00 00 0216.

NOTE

the handle value is 80 00 00 02 16 when the stClear attribute of the object is SET or when the stClear
attribute is set in one of the object's ancestor keys.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 193
December 24, 2020

Trusted Platform Module Library

30.4

Part 1: Architecture

sequence

the sequence parameter of the TPMS_CONTEXT

handlethe handle parameter of the TPMS_CONTEXT

encContext

the encrypted context blob

Object Context Management

When an object’s context is saved, a copy of the object context is integrity protected, encrypted, andreturned to the caller. The original context remains in the TPM and the TPM retains its handle. A saved
object context may be reloaded into the TPM with TPM2_ContextLoad(). If the TPM has sufficient
memory available, it will load the object and assign a handle. If other copies of the same object are in
TPM memory, they are unaffected. An object context is only removed from TPM memory with
TPM2_FlushContext(), deletion of the associated hierarchy seed, or TPM2_Startup().
The handle assigned to an object when it is loaded may not be assigned to any other TPM resource,
object, or session. When the object is flushed from TPM memory, its handle may be assigned to another
TPM resource when it is loaded or created.
Software may create as many copies of an object context as desired. When an object is not in TPM
memory, it has no associated handle. If an object context is saved and subsequently reloaded, it is likelythat a different handle will be assigned to the object.
When the Primary Seed is changed for the hierarchy associated with an object, all objects associatedwith that hierarchy are flushed from TPM memory. The TPM will no longer load saved contexts
associated with the previous Primary Seed.
When an attempt is made to load an object or an object context (TPM2_Load(), TPM2_CreatePrimary(),
TPM2_LoadExternal() or TPM2_ContextLoad()) and the TPM does not have sufficient RAM to hold theobject, the TPM will return TPM _RC_OBJECT_MEMORY or TPM _RC_MEMORY. This warning code isnormally handled by the TRM. It indicates that an object or a session needs to be unloaded from TPM
memory before the command can complete. If the TPM returns TPM_RC_OBJECT_MEMORY, it
indicates that an object must be flushed from TPM memory. If the TPM returns TPM_RC_MEMORY, thenit is possible that removal from TPM RAM of either an object or a session would allow the command tocomplete.
When a command references a persistent object, the TPM may move the object from NV into an object
slot. If no slot is available, the TPM will return TPM_RC_OBJECT_MEMORY.
An implementation is allowed to use an object slot for temporary memory in execution of TPM2_Import()
and return TPM_RC_OBJECT_MEMORY if a slot is not available.
If the TPM uses an object slot for temporary memory, the slot will be freed at the end of the command inwhich the slot was allocated.
If a TPM receives Shutdown(STATE) before the _TPM_Init, then the saved object contexts will continue
to be usable after a TPM Restart or TPM Resume. An exception is that an object may be created with thestClear attribute. If this attribute is SET in an object or an ancestor of an object, then the saved context
will be invalidated on TPM Restart. All saved object contexts are invalidated by TPM Reset.
30.5

Session Context Management

A session context is created by TPM2_StartAuthSession(). The context associated with a session is
unique. That is, the data describing the session’s state may be either on the TPM or saved off the TPM,
but not both. Further, a saved session context may only be loaded once. These limitations on the session
context are intended to prevent possible attacks based on replay of authorizations.
Page 194
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The handle associated with a session does not change as long as the session is active. The session is
active until closed by the continueSession flag being FALSE or until the session context is flushed fromthe TPM by TPM2_FlushContext().
The nominal implementation uses a volatile counter (contextCounter) that increments each time a session
is created or context loaded. This count value is assigned to the created or loaded session context andserves as a version number for the session context. If the session context is saved and reloaded, it isassigned a new version number. contextCounter is saved by Shutdown(STATE) and reset on TPM Reset.
The TPM maintains a database of concurrent sessions so that it can validate that a reloaded session
context is the most recent version. It is required that the TPM be able to ensure that the restored context
is the correct context regardless of the number of contexts created.
The size of contextCounter affects the size of the memory required for tracking each of the contexts. It istherefore desirable that the counter only be large enough for the majority of applications, meaning that it
will not be large enough for all applications. In those applications, a method is required to handle counterrollover.
One scheme for handling rollover is to maintain an even/odd interval. If, for example, a nonce were being
used for each interval, then the TPM could maintain two nonces, one to be used when the MSb of thevolatile counter is 0 and the other when the MSb is 1. When the counts of all the sessions have the sameMSb, then a new nonce can be created for use when the MSb changes. This scheme works unless asession has a long lifetime. That is, if the session is created when the MSb is 0, and the session is still
active when the counter reaches its maximum value with all bits equal 1, then the context with an MSb of
0 will need to be discarded.
Rather than have the old session be automatically flushed, the TPM provides an indication that it isreaching its limit and that one or more saved session contexts need to have their sequence number
updated to the current interval in preparation for the context counter rollover.
The indication that the context counter is approaching its limit is provided when an authorization session
is created or loaded. If the creation or loading of a session would make it impossible for the TPM to bringall contexts into the current interval, then it would return an error (TPM_RC_CONTEXT_GAP) and not
create or load the new session. On receiving this error, the management software either would explicitly
flush old session contexts or would load the old session contexts to update their associated countervalues.
When the TPM returns TPM_RC_CONTEXT_GAP, it will not allow an authorization session to be created
and it will only allow the oldest authorization session to be loaded. When the oldest session is loaded, itssequence number is updated. It may be used or saved with its new sequence number.
NOTE

The TPM has to provide the indication of the session-tracking limit being reached before themaximum count is reached. If there are three sessions in the ‘odd’ interval and the end of the ‘even’interval is being reached, then the TPM has to indicate the limit while there are still three available
session sequence numbers in the ‘even’ interval. This allows the sessions in the ‘odd’ interval to beloaded and saved with an ‘even’ interval session sequence number and wi th no session in the ‘odd’
interval so that a new ‘odd’ interval identifier can be created.

Session contexts in TPM RAM are flushed on any TPM2_Startup(). Saved session contexts are notinvalidated and may be reloaded after a TPM Restart or TPM Resume. Saved session contexts areinvalidated on a TPM Reset.
30.6

Eviction

Eviction is the process of removing the context associated with an object or session from TPM RAM toallow for other sessions or objects to be loaded or created. Saving a session context removes the
majority of the session context from TPM RAM. Saving an object context does not remove it from TPM
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 195
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

memory. When applied to an object, TPM2_FlushContext() will remove it from the TPM RAM but notinvalidate the saved contexts of that object. When applied to a session, TPM2_FlushContext() willinvalidate the session whether its context is in TPM RAM or saved.
An object may be copied to persistent TPM NV memory with TPM2_EvictControl(). When madepersistent, TPM2_FlushContext() and TPM2_Startup(TPM_SU_CLEAR) have no effect on the persistent
copy of the object.
A session may not be made persistent.
Use of TPM2_EvictControl() requires either Owner Authorization or Platform Authorization. An object
made persistent using ownerAuth may be evicted from persistent memory using either Owner
Authorization or Platform Authorization. An object made persistent using Platform Authorization may only
be evicted from persistent memory using Platform Authorization.
30.7

Incidental Use of Object Slots

In most cases, the TRM will explicitly load and unload (flush) objects from the TPM’s object memory. In
three cases, the TPM will make use of object slots as a side effect and the TRM needs to deal withpotential resource issues that may arise. The three cases are: TPM2_Import(), use of persistent objects,
and _TPM_Hash_Start.
TPM2_Import() allows an implementation to use an object slot for its “scratch” memory while operating on
the import blob. When the command completes the slot will be available. An implementation that uses thisoption may return TPM_RC_OBJECT_MEMORY if a needed slot is not available. This return code is in
the group of response codes that are expected to be handled by the resource manager.
When a handle references a persistent object, a TPM implementation is allowed to return
TPM_RC_OBJECT_MEMORY if an object slot is not available. This allows the TPM to keep the
persistent image of the object in a compressed form and decompress it into an object slot for efficient
processing. The version of the persistent object held in an object slot will be removed when the commandcompletes.
When the TPM receives _TPM_Hash_Start, it will unconditionally create an Event Sequence context. If
an object slot is available, the TPM will use the available slot. If an object slot is not available, the TPM
will flush an arbitrary object context and use that slot. At the end of the event sequence(_TPM_Hash_End), the slot used for the Event Sequence will be vacant. The TRM should be aware that
the _TPM_Hash_Start sequence may cause loss of a loaded object.
30.8

Sequence Context Management

Unlike a session context (see clause 30.5), a saved sequence object does not include replay protection.
Thus, an attacker could undo a TPM2_SequenceUpdate() by context saving the sequence object context
before the update and context loading the stale context after the update. The application can mitigate this
attack by adding a length to the update packet. The verifier can check the length and detect a missing
update.
EXAMPLE:NOTE:

Commands such as TPM2_HMAC_Start(), TPM2_MAC_Start(), or TPM2_HashSequenceStart() create asequence object.
Using an HMAC session during TPM2_SequenceUpdate() can prevent an alteration of the update
packet (by a man in the middle).

Page 196
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Attestation
31.1

Introduction

Attestation is the action of having the TPM sign some internal TPM data. Confidence in the attestation isrelated to the confidence in the key that is used to sign. The highest confidence is provided by afixedTPM, restricted signing key that is created on a TPM with a certificate from the TPM manufacturer.
The TPM may be used to attest to several different types of data:•

PCR data – TPM2_Quote()•

Clock and Time data – TPM2_GetTime()•

Audit digests – TPM2_GetCommmandAuditDigest() and TPM2_GetSessionAuditDigest()•

Other TPM Objects – TPM2_Certify()

For all of these commands, the TPM produces a standard attestation structure and appends thecommand-specific data. The resulting data block is then hashed and signed by the selected signing key.
The selected key may be any key that has the sign attribute SET. If the signing key is unrestricted, thenthe caller may indicate the signing scheme to be used. If the signing key is restricted, the TPM will return
an error (TPM_RC_SCHEME) unless the scheme selector in the attestation command is
TPM_ALG_NULL.
31.2

Standard Attestation Structure

The contents of the standard attestation structure are described in Table 30.
Table 30 — Standard Attestation Structure
Parameter

Type

Description

magic

TPM_GENERATEDThis unique value (TPM_GENERATED_VALUE) occurs as the firstoctets in any TPM-generated attestation structure. This field is used toprevent use of a restricted signing key to sign a forgery of an attestation.
A TPM will not allow a restricted signing key to sign any external data ifthat data starts with this unique value. The way that the TPM enforces
this restriction is that a TPM will not use a restricted key to sign a digest
that the TPM did not produce. Since the TPM produced the digest, it canensure that any external data did not start with this value.

type

TPMI_ST_ATTEST

This identifies the type of the attestation structure and indicates thecontents of the attested parameter.

qualifiedSigner

TPM2B_NAME

This is the Qualified Name of the key used to sign the attestation data. A
key that can be duplicated may be signing in different locations and thisQualified Name allows the Verifier to determine the environment in which
the signature was produced.

extraData

TPM2B_DATA

external info supplied by caller (often in qualifyingData parameter)
NOTE

A TPM2B_DATA structure provides room for a digest and a method
indicator to indicate the components of the digest. The definition ofthis method indicator is outside the scope of this specification.

clockInfoTPMS_CLOCK_INFO The values of Clock, resetCount, restartCount, and Safe

firmwareVersion

UINT64This TPM-vendor-defined value changes when the firmware on the TPM
changes, if that change is meaningful to the security of the TPM.

[type]attested

TPMU_ATTEST

the type-specific attestation information

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 197
December 24, 2020

Trusted Platform Module Library
31.3

Part 1: Architecture

Privacy

The attestation block contains information that could allow cross correlation of attestation values. The
combination of a firmwareVersion and clockInfo could be used to identify that two attestations weresigned by keys on the same TPM. This correlation is possible because the combination of resetCount,restartCount, and firmwareVersion could be unique. Even if the combination is not unique for all TPM, animperfect correlation may be adequate for certain types of activity tracking.
The TPM prevents such tracking by adding obfuscation values to the reported values of resetCount,restartCount, and firmwareVersion. This obfuscation value is different for each key and TPM (see 36.7).
Although the values are obfuscated, they do not lose any of their usefulness for indicating changes to thevalues. While the absolute values are not visible in the attestation, it is still possible to look at attestations
signed by the same key and determine how many times the TPM was reset or restarted between theattestations and to see the delta in the firmware version number (if any).
It is sometimes necessary to have the non-obfuscated values of the clockInfo and firmwareVersion
included in an attestation. Support for this is provided by allowing signing keys in the Endorsement
hierarchy. When a key in the Endorsement hierarchy signs an attestation, no obfuscation is applied. The
underlying presumption is that the TPM’s Privacy Administrator controls the Endorsement hierarchy and it
is possible, through policy, to limit the use of keys in that hierarchy so that authorization from the Privacy
Administrator is always required.
31.4

Qualifying Data

Each of the attestation commands has a parameter called qualifyingData. This parameter is notinterpreted by the TPM and may contain any data chosen by the caller. The most common use of thisparameter is expected to be as a nonce to ensure "freshness" of an attestation.
31.5

Anonymous Signing

If an anonymous scheme (TPM_ALG_ECDAA) is used for signing in any attestation command, thequalifiedSigner parameter will be an Empty Buffer.
NOTE 1

If the qualifiedSigner field was properly populated (not the Empty Buffer), then the unique identity ofthe signing key would be disclosed.

For TPM2_Certify() using an anonymous signing scheme, both the qualifiedSigner and qualifiedName of
the certified key are set to an Empty Buffer.
NOTE 2

31.6

If the qualifiedName field was not cleared, then it would be possible to establish a hierarchicalrelationship between to certified objects. This is not desirable for an anonymous scheme.

X.509 Certificate Signing

TPM2_CertifyX509() signs an X.509-formatted certificate. Prior to constructing and signing an X.509
certificate, TPM2_CertifyX509() verifies that the key-to-be-certified is loaded in the TPM, and that some ofthe permissions in the key’s proposed X.509 certificate are compatible with the key-to-be-certified.
A typical use of TPM2_CertifyX509() is the enrollment of any TPM key into an X.509 Public Key
Infrastructure. TPM2_CertifyX509() signs an X.509 formatted certificate describing the TPM key, rather
than enabling the TPM key to self-certify by creating an X.509 formatted Certificate Signing Request(CSR). This is because a CSR doesn’t provide a way for a TPM to communicate to a Certification
Authority that the TPM key is protected by a TPM, or the restraints on the TPM key that are enforced by
the TPM. The X.509 formatted certificate signed by the TPM is inspected by a Certification Authority prior
to the CA signing its own certificate describing the operations on the key that are approved by the CA. A
simpler CA will use conventional X.509 methods to just verify the TPM’s certificate and verify the X.509
Page 198
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarycertificate of the key that signed the TPM’s certificate. A more sophisticated CA that understands TPMs
will also interpret the TPM certificate’s Extensions element, which describes the certified key’s detailed
TPMA_OBJECT attributes and indicates precisely what operations a TPM can and cannot perform on thecertified key.
In a typical usage of TPM2_CertifyX509():•First, the CA (or its proxy) loads a certifying signing key in the TPM. The certifying signing key istypically a key with the x509Sign attribute SET.
•
Next, the CA uses the certifying key with TPM2_CertifyX509() to certify a TPM key . The DERencoded partialCertificate parameter for TPM2_CertifyX509() describes the validity time for the certificate
as well as the X.509 Name for the certifying and certified keys. Additionally, partialCertificate is required
to contain a KeyUsage in the Extension field and may contain a TPMA_OBJECT Extension.
TPM2_CertifyX509() verifies that the key is compatible with approved operations, constructs a complete
X.509 RFC 5280-defined certificate, and signs that complete certificate.
•
TPM2_CertifyX509() returns the part of the complete X.509 certificate that was constructed by the
TPM, plus the TPM’s signature over the complete certificate. This data and partialCertificate areassembled outside the TPM into a complete X.509 RFC 5280-defined signed certificate for inspection by
the Certification Authority using conventional X.509 tools.
•
Finally, the Certification Authority recertifies the TPM key using the CA’s normal certifying key, forconsumption by entities that trust the CA.
Certification Authorities should be wary of certificates signed by TPM2_CertifyX509() with keys that do nothave the x509sign attribute SET, because an X.509 certificate can be signed using TPM2_Sign(). In thatcase, the TPM will not have verified that the certified key is loaded in the TPM and will not have verified
that the certified key is compatible with the X.509 certificate. Nevertheless, an X.509 certificate signed by
TPM2_CertifyX509() with an ordinary signing key or a restricted signing key may be acceptable when the
CA trusts the entity controlling usage of that signing key: the CA itself may have exclusive control over thesigning key, for example.
An x509sign key is even more restricted than a restricted key: a restricted key won’t use TPM2_Sign() tosign any data that starts with the “magic” parameter, and an x509sign key won’t use TPM2_Sign() to sign
any data at all. Hence the command TPM2_CertifyX509() is the only way that an x509sign key can signan X.509 certificate. An x509sign key will also sign any of the non-X.509 certification commands (e.g.,
TPM2_Certify, TPM2_CertifyCreation, TPM2_NV_Certify), which sign data that start with the TCG“magic” value. This enables an x509sign key to be an Attestation Key with a certificate proving that thex509sign key is bound to a single TPM and is safe because none of the certification commands sign datathat could masquerade as a fraudulent certificate.
TPM2_CertifyX509() verifies that a key-to-be-certified is compatible with permissions granted by theX.509 certificate. Broadly speaking, the TPM verifies that the private key can decrypt if the certificate says
the key is approved for decryption and verifies that the private key can sign if the certificate says the key
is approved for signing. The TPM verifies that a key has its fixedTPM attribute SET if the certificate
approves the key for nonrepudiation/contentCommitment operations, because only the TPM that has aparticular fixedTPM key can use that particular key.
TPM2_CertifyX509() cannot guarantee that a key will perform only the operations approved by an X.509
certificate. A TPM cannot control operations on the public part of a key and doesn’t usually know why is
key is being used, whereas a certificate can approve operations on the public part of a key and canapprove the objective of operations on a key. Relying parties are cautioned that not all of the information
in a certificate signed using TPM2_CertifyX509() is validated by the TPM. The TPM validates the public
key of the target, the KeyUsage, and the TPMA_OBJECT extended attributes.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 199
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Some partialCertificate inputs to TPM2_CertifyX509 cannot be verified by the TPM but must be present
because they are necessary to create a signature over an X.509 certificate. One such input is thecertifying signing scheme OIDs that are necessary to create the signature. The caller does not need tosupply OIDs if the TPM is able to generate the OIDs for the certifying signing scheme. However, there areso many OIDs that the TPM is unable to generate all possible OIDs, and some OIDs have not yet been
assigned. Thus, the caller must supply the OIDs for the certifying signing scheme if the TPM is unable togenerate them. Should the caller supply OIDs, they take precedence over any OIDs that the TPM would
have assigned.

Page 200
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Cryptographic Support Functions
32.1

Introduction

In TPM 1.2, the cryptographic primitives were not exposed for general purpose use. For example, the
RSA engine could not be used for exponentiation. This specification provides commands that allow
access to the primitive cryptographic processes of the TPM.
One assumption in TPM 1.2 was that the host processor usually had much greater performance than theprocessor used for the TPM so there was no point in having the TPM do something that the host could domuch faster. In addition, TPM 1.2 was a passive device with limited bandwidth. While it is true that thehost processor will usually have more capability than the TPM, this will not be true in all cases. In fact, onsome systems, the main processor will be able to switch execution environments and perform the TPM
operations. In others, the TPM may be built around a cryptographic coprocessor that has significantly
greater processing capability for cryptographic operations than the host. These higher performance
implementations will not be performance-limited by being attached to the system with a low-bandwidthinterface. These performance differences mean that exposure of the cryptographic primitives of TPM 2.0
makes more sense that it did in TPM 1.2.
Another reason to make the cryptographic primitives available is that not all software will implement all thealgorithms that may be in the TPM. For example, a BIOS may not implement the RSA algorithm but would
want to check the RSA signature of some code.
This clause describes the commands and methods that may be provided by a TPM compliant to thisspecification.
32.2

Hash

TPM2_Hash() will create a digest of a block of data using the indicated hash algorithm. If the amount ofdata to be hashed exceeds that input buffer size of the TPM, then a hash sequence is used (see 32.4).
If the data used to create the digest does not have TPM_GENERATED_VALUE as its first octets, thenthe response to TPM2_Hash() or TPM2_SequenceComplete() will contain a ticket indicating that thedigest may be signed with a restricted signing key.
NOTE

32.3

The creation of the ticket may be suppressed by using TPM_RH_N ULL as the hierarchy parameter in
TPM2_Hash() or TPM2_SequenceComplete().

HMAC

TPM2_HMAC() will compute an HMAC over a block of data using a TPM-resident value for the HMAC
key. In this command, the handle parameter is required to reference an object with a type of
TPM_ALG_KEYEDHASH with the sign attribute SET.
32.4

Hash, MAC, and Event Sequences
Introduction

When the amount of data to be included in a digest cannot or will not be sent to the TPM in one of theatomic hash/HMAC commands (TPM2_Hash(), or TPM2_HMAC()) then a sequence of commands may
be used to provide incremental updates to the digest.
A sequence is started with either TPM2_HashSequenceStart() or TPM2_HMAC_Start(); increments of
data
are
added
to
the
sequence
digest(s)using
TPM2_SequenceUpdate();andFamily “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 201
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM2_SequenceComplete() or TPM2_EventSequenceComplete() is used to complete a sequence.
TPM2_SequenceComplete() and TPM2_EventSequenceComplete() may also provide the last data to be
included in the sequence digest(s).
Three types of sequences are defined:
1) hash2) Event
3) HMACHash Sequence
In a hash sequence, the TPM will perform a hash over all the data in the sequence using the selected
algorithm.
TPM2_SequenceComplete() completes the hash sequence and returns a digest of the data. Additionally,
if the data used to create the digest did not start with TPM_GENERATED_VALUE, then a ticket is
produced indicating that the digest may be signed with a restricted key.
A hash sequence is:
TPM2_HashSequenceStart() (hashAlg is a supported hash algorithm), followed by
TPM2_SequenceUpdate() (zero or more), followed by
TPM2_SequenceComplete()
Event Sequence
For an Event Sequence, the TPM will potentially create multiple digests over the data (a digest for each
PCR bank). TPM2_EventSequenceComplete() is used to complete the sequence and return a list ofdigests; and, If a PCR handle is provided, each digest is extended into the corresponding PCR bank.
EXAMPLEIf a TPM implements both a SHA1 and a SHA256 bank, then the list will contain two digests.

An Event Sequence is:
TPM2_HashSequenceStart() (hashAlg is TPM_ALG_NULL), followed by
TPM2_SequenceUpdate() (zero or more) followed by
TPM2_EventSequenceComplete() (will do an Extend if pcrHandle is a PCR and not TPM_RH_NULL)HMAC Sequence
For an HMAC sequence, the TPM will use the indicated key as the HMAC key and perform an HMAC
computation over the data of the sequence using the specified hash algorithm.
TPM2_SequenceComplete() completes the HMAC sequence and returns the HMAC value.
NOTE

The response for TPM2_SequenceComplete() also has a validation parameter. This parameter isused for a hash sequence to indicate if the digest is safe to sign with a restricted key. Thisparameter is not used for an HMAC sequence so the TPM will set the validation parameter to a NUL
TicketAn HMAC sequence is:Page 202
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

TPM2_HMAC_Start() (hashAlg is a supported hash algorithm), followed by
TPM2_SequenceUpdate() (zero or more) followed by
TPM2_SequenceComplete()
Sequence Contexts
Sequences involve hashing of data and the intermediate hash state must be retained by the TPM in a
protected location. This intermediate state is kept in a vendor-specific structure that may occupy an object
slot on the TPM.
A sequence context is assigned a handle so that it may be saved and restored like any Transient Object.
Its properties are not identical to other Objects because the sequence context is updated on each use. In
addition, unlike other Objects, the public portion of a sequence is not readable with TPM2_ReadPublic().
A sequence context can be replayed if one has the authorization for the sequence.
If an authorization or audit for a sequence object requires computation of a cpHash and an rpHash, theName associated with sequenceHandle will be the Empty Buffer.
When TPM2_EventSequenceComplete() or TPM2_SequenceComplete() completes successfully, thesequence context is flushed from the TPM.
A sequence is exempt from dictionary attack protection and authorization failures will not cause the TPM
to enter lockout.
32.5

Symmetric Encryption

TPM2_EncryptDecrypt() is defined for symmetric encryption and decryption of blocks of data. Support forthis command in a TPM may cause the TPM to be subject to different jurisdictions' legal import/export
controls than would apply to a TPM without these commands.
The command supports chaining of encryption so that the encryption/decryption may be done
incrementally as the data arrives or to handle the cases where the block of data is larger than will fit into asingle TPM buffer.
32.6

Asymmetric Encryption and Signature Operations

The annexes to this TPM 2.0 Part 1 contain descriptions of the cryptographic encryption/decryption andsignature primitives that are defined for each of the asymmetric algorithms supported by the specification.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 203
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Locality
In some systems, accesses to the TPM are segregated by privilege level. The interface to the TPM may
be able to discriminate the different privilege levels and provide an indication to the TPM when the accessis at a privilege level other than the default level.
The indication of privilege level can be used in access control policy to ensure that the operation on an
object is occurring at the right level. The privilege level of a command is called its Locality.
The method by which the TPM interface determines the Locality of an access is system-dependent. The
TPM interface provides a Locality indication to the TPM each time the TPM is accessed. The contents ofthe command or response buffer are not changed by the Locality indication.
The definition of the modifier is platform-specific. Depending on the platform, the modifier could be a
special bus cycle or additional input pins on the TPM. One example would be special cycles on the Low
Pin Count (LPC) bus that inform the TPM it is under the control of a process on the PC platform. The
assumption is that spoofing the modifier to the TPM requires more than just a simple hardware attack andwould require expertise and possibly special hardware.
The locality value is represented as a byte and locality values have two separate representations.
Localities 0 through 4 are represented as bits in the byte with 0000 00012 representing locality 0 and
0001 00002 representing locality 4. This representation allows multiple localities to be represented in asingle byte as long as the localities are in the range of 0-4. This representation of locality is compatible
with previous versions of this specification.
A second representation is for localities above 4. These are called extended localities. For extended
localities, the locality byte is an integer value representing the locality. Because of the format for localities
0-4, the first extended locality is 32. The range of extended localities is 32-255. The locality value may
indicate only one extended locality at a time.
NOTE

Locality 5 through 31 cannot be selected.

Page 204
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Hardware Core Root of Trust Measurement (H-CRTM) Event Sequence
34.1

Introduction

A process that puts the system in a known state running known code creates the starting point for a chainof trust. A computer system reset puts the processor and chipset into a known state, and the processor(the root of trust for measurement) begins executing code provided by the platform manufacturer. Thisinitial code is the core root of trust for measurement (CRTM). It is code that must be trusted as there is no
way to tell what that code is other than to rely on the manufacturer. Usually, one of the actions of the
CRTM is to extend a PCR with a value that represents the identity of the CRTM. This boot process starts
the chain of trust with two different roots that are usually from different sources: the RTM from a CPU
vendor and a CRTM from a platform manufacture.
Some system implementations support an alternative method of starting a chain of trust that makes the
CPU the CRTM. For this method, the CPU is placed in a known state and measures the code that it willrun. Before being measured, this code is protected so that it cannot be tampered with and there isassurance that the code that is measured is the code that is executed. Since the CPU is both executing
the measured code and measuring it, it is both the RTM and the CRTM. This is called a hardware-based
core root of trust for measurement or H-CRTM.
The TPM supports an H-CRTM by providing special interface indications that allow the TPM to determine
when it is receiving data from the RTM acting as CRTM. These indications are:•

_TPM_Hash_Start – sent by the RTM to indicate the start of a H-CRTM Event Sequence. The TPM
will initialize an H-CRTM Event Sequence context. The H-CRTM Event Sequence context contains
hash state for each bank of PCR. This indication is only allowed from the RTM when it has been put
into a known "good" state as defined by the RTM manufacturer. There is only one _TPM_Hash_Start
per H-CRTM Event Sequence.

•_TPM_Hash_Data – sent by the RTM to update the digests in the H-CRTM Event Sequence contexts
with H-CRTM data. An H-CRTM Event Sequence may have zero or more _TPM_Hash_Data
indications.

•_TPM_Hash_End – sent by the RTM to indicate the end of the H-CRTM Event Sequence. On receiptof this indication, the TPM will take actions that are dependent on whether the H-CRTM occurred
before or after TPM2_Startup(). The actions taken as the result of this indication will always include
initialization of at least one PCR followed by a PCR being extended with the H-CRTM data.

During an H-CRTM sequence, if any indication other the _TPM_Hash_Data occurs between the_TPM_Hash_Start and _TPM_Hash_End indications (including receipt of a command), then the H-CRTM
Event Sequence is abandoned, the H-CRTM Event Sequence context is flushed, and no change to any
PCR occurs.
NOTE

34.2

The interface is permitted to be designed such that it is not possible to interrupt this sequence.

Dynamic Root of Trust Measurement

When an H-CRTM occurs after TPM2_Startup() it is called the dynamic root of trust for measurement (DRTM).
NOTE 1

There is no special designation for when the H -CRTM occurs before TPM2_Startup()

NOTE 2

The D-RTM sequence may be repeated one or more times after TPM2_Startup. On each invocationof the D-RTM sequence, the RTM has to be in the same known state.

For D-RTM, the TPM will initialize one or more PCR to zero and then extend PCR[17] in each bank with
the H-CRTM data accumulated in the H-CRTM Event Sequence.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 205
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

PCR[17][hashAlg] ≔ HhashAlg (0…0 || HhashAlg (hash_data))

(53)

Where

hash_data

all the octets of data received in _TPM_Hash_Data indications

The PCR that are initialized and extended as a result of a D-RTM event are specified in a platformspecific TPM specification.
34.3

H-CRTM before TPM2_Startup() and TPM2_Startup() without H-CRTM

If the H-CRTM sequence occurs before TPM2_Startup(), then only PCR[0] will be affected. When
_TPM_Hash_End is received, the TPM will complete the Event Sequence digests. It will then initialize
PCR[0] to 4 and Extend the H-CRTM Event Sequence data. The value 0…4 represents evidence that theinitial measurement was from an H-CRTM.
PCR[0][hashAlg] ≔ HhashAlg (0…04 || HhashAlg (hash_data))

(54)

where
0…04

denotes a numeric value of 4 with high-order bits of 0 to make the value
the size of a digest computed with hashAlg

hash_data

all the octets of data received in _TPM_Hash_Data indications

If PCR[0] is initialized by an H-CRTM event before TPM2_Startup(), then TPM2_Startup(CLEAR) will notchange the value of PCR[0]. Otherwise, TPM2_Startup(CLEAR) will set PCR[0] to the locality of the
TPM2_Startup() command.
If there is an H-CRTM event before a TPM2_Startup(CLEAR), there must be an H-CRTM event before asubsequent TPM2_Startup(STATE). The locality of the TPM2_Startup(STATE) is not checked against the
locality of the previous TPM2_Startup(CLEAR)
If there is no H-CRTM event before TPM2_Startup(CLEAR), there must be no H-CRTM event before asubsequent TPM2_Startup(STATE) and the TPM2_Startup(STATE) must have the same locality as theprevious TPM2_Startup(CLEAR).

Page 206
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Command Audit
The command audit mechanism allows the TPM owner to create a verifiable log of each execution of
selected commands.
TPM2_SetCommandCodeAuditStatus() is used either to change the list of commands being audited or tochange the audit hash algorithm (it cannot change both in the same command). This command requires
either Platform Authorization or Owner Authorization. The selection may change at any time.
NOTE 1

It is anticipated that a small number of commands will be selected for audit, most likely thosecommands that provide identities and control of the TPM. However, there are few restrictions on
which commands may be audited.

The audit log, the list of executed TPM commands and responses, is maintained outside the TPM by an
untrusted party. Enabling the audit function of a TPM does not guarantee that the log will be properly
maintained. The TPM audit function simply provides a means to determine if the log was properly
maintained.
It is not necessary to continuously maintain the audit log in order to use the audit capability. When an
audit log is started, the current contents of the audit digest register can be read to establish the starting
value for the log. At the end of the audit interval, the audit digest register can be read again and thecontents of the audit log over the audit interval can be verified.
An audit can be used to track use of keys and, therefore, is potentially privacy sensitive. For this reason,
the privacy administrator of the TPM must authorize access to the audit digest register. Authorization fromthe privacy administrator is expressed using Endorsement Authorization.
The update of the audit digest register occurs when the command completes successfully and the
response has been created. The command audit update is:

auditnew ≔ HauditAlg (auditold || cpHash || rpHash)

(55)

where

HauditAlg

hash function using the currently selected audit hash algorithm

auditoldthe previously computed audit digest

cpHashthe command parameter hash using the audit hashrpHashthe response parameter hash using the audit hash

NOTE 2Clause 18.7 describes the process for computing cpHash and clause 18.8 describes the process forcomputing the rpHash.

The audit mechanism uses two components: an audit digest register and an audit counter. The audit
counter is a non-volatile register that counts the number of audit logs that are created. If the audit digest
register contains all octets of zero when an audit event is recorded, then a new audit log is being created
and the audit counter is incremented.
An audit log ends and the audit digest is cleared when the command TPM2_GetCommandAuditDigest()
returns a signature.
NOTE 3

The audit counter is incremented when the new log starts so that a missing log cannot be dismissed
as being irrelevant. Because a new audit log is started only when an auditable event occurs, any
missing log is suspect.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 207
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The audit counter is non-volatile and is reset to zero by TPM2_Clear(). The audit digest register is reset
when an unanticipated power event occurs (that is, loss of TPM power without an orderly shutdown). The
audit digest is preserved over any orderly shutdown.
The audit digest register is reset by a TPM2_SetCommandCodeAuditStatus() that changes the audit
digest algorithm auditAlg.
An audit report structure contains the current value of the audit digest register and the value of the audit
counter.
NOTE 4The signed audit structure is a TPM2B_ATTEST structure that contains other qualifying information
about the signing environment.

Because the audit mechanism utilizes NV memory, endurance may be a factor. The endurance
requirements of the audit mechanism are platform-specific.
NOTE 5The command audit session counter is incremented on the first auditable command in a session.
This is typically infrequent, so the endurance of the counter is not likely to be a major issue.

When the TPM is in Failure mode, command audit is not functional and command audit of
TPM2_GetTestResult() and TPM2_GetCapability() will not occur.
TPM2_SetCommandAuditStatus() is audited when it changes the list of audited commands. It is notpossible to disable audit of this command. If TPM2_SetCommandAuditStatus() is used to change theaudit hash algorithm, then the command is not audited and evidence of this operation is provided by thechange in the hash algorithm reported when the command audit value is read.

Page 208
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Timing Components
36.1

Introduction

The TPM has timing components for use in time-stamping of attestations and for gating policy
Time is a free-running hardware value that is not under software control. Time advances when the Timecircuit is powered and is reset to zero when power to the Time hardware is lost.
NOTE 1

Typically, the Time hardware will be powered down when the rest of the TPM is powered down.

Clock is a value that is derived from Time and advances as Time advances. Clock may be advanced inorder to bring it into alignment with real time. However, Clock may not be set back except by installing a
new owner.
The resetCount and restartCount values allow detection of power loss that could cause discontinuities inthe time recorded by Clock. The Safe flag indicates whether Clock might have been wound backwards, inwhich case the current Clock value would be unsafe. The timing components are exposed throughcommands that:•

read the value of Clock, Time, resetCount, and restartCount (TPM2_GetTime());•

time-stamp externally provided data using a signature key and Clock, resetCount, andrestartCount (TPM2_GetTime(), TPM2_Quote(), TPM2_Certify(), and other restricted signing
operations);

NOTE 2

TPM2_ReadClock() returns uncertified (not signed) values. TPM2_GetTime() returns a structure andan optional signature over the data. TPM2_ReadClock() is used by the OS to manage the timing
resources of the TPM and TPM2_GetTime() is for attestation of time and is under control of theprivacy administrator.

•

allow Clock to be adjusted forward (TPM2_SetClock());•

allow the rate of advance of Clock to be adjusted (TPM2_ClockRateAdjust()); and•allow objects to be lifetime-limited using authorization policy expressions that reference Safe,
Clock, Time, resetCount, and restartCount (TPM2_PolicyCounterTimer()).

Potential use cases for the TPM timing components include:•

lifetime limits for keys when certificate revocation is impossible or undesirable;•

time-limited delegation of rights (such as, the right to use or duplicate a key for 1 hour);•time-stamping of security event logs to ensure that events cannot be forged in the past;•boot-counter stamping of event logs to ensure that a log associated with a particular reboot
cannot be deleted without leaving a trace;•boot-counter/PCR-counter stamping of keys to indicate they were created during OS installation;•

time-stamping of attestation values as an alternative to the use of a nonce in online protocols; and•indication of whether a TPM/platform has rebooted since last checked.

Clock is not designed to be a replacement for other online or local time sources and is not appropriate forall uses. Later clauses describe the behavior of timing resources and their specific security properties.
Implementers and relying parties should understand the limitations before using these features.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 209
December 24, 2020

Trusted Platform Module Library
36.2

Part 1: Architecture

TimeTime is a 64-bit value that contains the time in milliseconds that the circuit providing Time has been
powered.
NOTE

Depending on the frequency of the TPM oscillator and the setting of the frequency divisor(TPM2_ClockRateAdjust()), the rate at which Time advances can be in error by as much as 32.5%.

Time is unaffected by TPM2_ClockSet().
The circuit providing Time may be powered independently from the rest of the TPM. However, Time must
be powered whenever the TPM is powered. The Time hardware needs to provide a reliable indication thatit has lost power or has been reset. Time should not be reset unless the TPM requires a _TPM_Init
indication before resuming operation.
Time need not advance continuously when powered. The Time hardware is required to provide a reliableindication if Time has stopped advancing.
36.3

Clock
Introduction

Clock is a time value that can be advanced but never rolled back. It may increment in volatile memory. If
so, it is periodically written to NV memory.
A non-orderly shutdown may cause a write to NV memory to be missed. Other values that are written to
NV on an orderly shutdown will be advanced to a known safe value on the next startup. However, Clockis not advanced because power outages would cause the clock to be advanced to a time in the future andit could not be adjusted back to an accurate value. To indicate that a value reported in Clock may be arepeat of a previously reported value, a flag (safe) is CLEAR after a non-orderly shutdown. After the next
NV update of Clock, safe is SET to indicate that Clock is not a repeat.
Clock is a volatile value that advances at the rate that Time advances. A non-volatile value (NV Clock) is
updated periodically from Clock. NV Clock will always move forward as Clock advances. However,
because of unexpected power loss, it is possible that the same value of Clock will be reported more thanonce. The mitigations for this are described in subsequent parts of this clause (36.3).
The accuracy of Clock is approximate. The causes of inaccuracy are•

the TPM’s time reference may not be accurate, and•the TPM must rely on external software to provide initial or periodic adjustments to Clock settings.

The interpretation of the time-origin (t=0) is out of the scope of this specification, although Coordinated
Universal Time (UTC) is expected to be a common convention.
The value of Clock may be set forward by external software (TPM2_ClockSet()) to compensate for powerinterruptions or clock slew, but, except for changes in ownership (TPM2_Clear()), the TPM will not allow
external software to set Clock backward.
The value of Clock may be advanced by TPM2_ClockSet() using either platform or owner authorization.
NOTE

The value of Clock cannot be advanced beyond FF FF 00 00 00 00 00 00 16 . This restriction prevents
any possibility of Clock rolling over during its lifetime and simplifies use of Clock in policies.

Page 210
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

The TPM may be driven by an imprecise internal or external frequency source. To compensate, the TPM
allows external software with a more reliable time source to make limited (+/-15%) adjustments to the rateof advancement of Clock.
Clock Implementation
The technology used for non-volatile storage may make the update rate for NV Clock an endurance
issue. To mitigate this, the interval between updates of NV Clock from Clock are allowed to be as long as
once per 222 milliseconds.
NOTE

If NV Clock is implemented in a technology that allows millisecond updates and has no endurance
issues, then Clock and NV Clock can be the same.

Since NV Clock may be updated at a low rate, a power event may cause the value in Clock to appear togo backward. For example, assume that the update interval for NV Clock is the maximum allowed value(222 milliseconds or approximately 70 minutes). Power may be removed from the TPM and Time justbefore an update of NV Clock. Then, when power is restored, Clock will be restored from NV Clock andClock may have a value that is more than an hour older than the last reported value of Clock. Thisillustrates that the values of Clock reported by the TPM for the first hour of operation may have a lower
value than values returned before the power outage.
The Safe flag in the TPMS_TIME_INFO structure is used to indicate if the reported value of Clock isguaranteed not to be a repeat of a previously reported value. The Safe flag is described in more detail in
the following clause.
Orderly Shutdown of Clock
In order to reduce the amount of time that must pass before Safe is SET, the TPM supports an orderly
shutdown. TPM2_Shutdown() is used to indicate to the TPM that software anticipates the loss of TPM
power and that the appropriate state should be preserved. When the TPM receives TPM2_Shutdown(), it
will copy all of the bits of Clock to NV Clock. After an orderly shutdown, the TPM will SET a non-volatile
flag to indicate that an orderly shutdown has occurred.
NOTE 1To allow the NV Clock to only have to record the upper bits of Clock, an alternate implementation isto keep Clock in memory that has a copy saved on an orderly shutdown and to restore Clock fromthat memory on the next power up.

After an orderly shutdown, Clock continues to count and NV Clock will be updated at the normal rate.
Any time a command is executed that uses the value of Clock, the flag indicating orderly shutdown will be
CLEAR even if this command occurs subsequent to TPM2_Shutdown(). This flag may be SET when NV
Clock is updated from Clock.
NOTE 2

It is possible for the TPM to perform multiple shut downs before TPM power is actually lost.

If Safe is not SET when TPM2_Shutdown() is received, then NV Clock must not be set from Clock and
Safe must not be SET on the subsequent startup.
It is permitted for the low-order 10 bits of Clock to come from Time and for NV Clock not to implement
those bits. That is, NV Clock does not maintain resolution to better than 210 milliseconds. If an
implementation uses this option, then Safe will be CLEAR at least for the first 210 milliseconds of TPM
operation.
Clock remains safe as long as Time is powered. That is, if there is a non-Orderly shutdown and the TPM
is powered down but Time is powered, then Clock will be updated the next time the TPM starts. Sincetime is not lost, Clock will not appear to go backwards and Safe can be SET. During the time that the
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 211
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM is powered down it is not necessary for Time to advance, it simply needs not to be set to a lower
time value.
Clock Initialization at TPM2_Startup()
On any TPM2_Startup() or _TPM_Init (vendor's choice), Clock is loaded from NV Clock and Clock begins
incrementing at a one millisecond rate. NV Clock is then updated, no less frequently than the update
interval. It is anticipated that the first update of NV Clock will occur when some number of low-order bits ofthe volatile Clock become zero, indicating the passage of the update interval. For example, assuming that
the NV Clock update interval is 212 (approximately every 4 seconds), the TPM may perform an update of
NV Clock whenever the low-order 12 bits of volatile Clock are zero.
NOTE 1

If the TPM had an orderly shutdown, the low-order bits of the NV Clock will likely not be zero, so thefirst update of NV Clock after the _TPM_Init will occur in less than the normal update int erval.

NOTE 2

If the TPM received TPM2_Shutdown() and a subsequent command that used Clock, then the NV
value of Clock will likely be non-zero, but Safe will be CLEAR.

Setting Clock
The value in the volatile Clock may be set forward using TPM2_ClockSet(). The newTime parameter of
TPM2_ClockSet() is required to have a greater value than the volatile Clock. So that policies that rely on
Clock do not have to contend with the possibility of the value of Clock wrapping, newTime may not begreater than FF FF 00 00 00 00 00 0016.
If TPM2_ClockSet() causes the volatile and non-volatile versions of Clock to differ by more than theimplementation-dependent update interval, then NV Clock will be updated before TPM2_ClockSet()
returns.
NOTE 1

It is not necessary that all the bits of NV Clock be updated. Only the bits of NV Clock that are
updated in the normal update process need to be changed.

EXAMPLE

Assume the update of NV Clock occurs every 2 12 milliseconds (00 00 10 00 16) , that the low-order 32
bits of NV Clock are 00 00 00 00 16 and Clock are 00 00 0F 00 16 , and that a newTime advances Clockto 00 00 11 00 16 . Since this makes the difference between Clock and NV Clock more than the update
interval (2 12 ), NV Clock is updated to 00 00 11 00 16 .

The expected management for Clock is for a coarse (large) update to be made after TPM2_Startup() inorder to recover the time lost when the TPM was not powered. After that single large change, Clock is
expected to be updated with relatively small values to keep it synchronized with real time. If software
manages Clock in this manner, TPM2_ClockSet() will not have to be throttled in order to avoid NV wearout.
NOTE 2

System software may purposely cause the rate of Clock advance to be slower than real time and justmake minor adjustments when an attestation of some sort is required. If managed in this way,
TPM2_ClockSet() may be executed many times between update interv als. Because update of the NV
portion of Clock is not allowed unless the difference between the two versions is at least as large as
the update interval, TPM2_ClockSet() will not need throttling to avoid wear -out.

NOTE 3The specification could have been written so that TPM2_ClockSet() would never invoke NV
throttling. That is, the value for newTime could have been set such that the rate of NV Clock update
would be at an acceptable rate or TPM2_ClockSet() would fail. This logic is complex, and undernormal circumstances, redundant. As a consequence, the specification does not place restrictions
on the values of newTime other than those listed above. The fact that TPM2_ClockSet() requires
Owner Authorization or Platform Authorization will provide some level of protection against an
attacker using TPM2_ClockSet() for a wear-out attack on the TPM. TPMs can implement wearprotection if extraordinary rates of update are observed.

Page 212
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Clock Periodicity
The TPM clock may be driven by an internal or external frequency source or be derived from a timesource supplied by its operating environment. TPM profiles shall specify the time source to be used andthe required accuracy.
External software may make limited adjustments to the rate of advance of Clock to provide a better
approximation to real time.
This specification requires that the nominal rate of advance of Clock when powered is within 15% of therate of UTC. If the external clock is not reliable, the TPM must provide its own clock with the necessary
accuracy. External software may indicate that Clock is not advancing at the rate of UTC and that the rateneeds to be increased or decreased. The command to adjust the clock rate is TPM2_ClockRateAdjust().
The newRate parameter of this command allows fine or coarse upward or downward adjustments to thecurrent counting rate. This specification does not define coarse or fine adjustment percentages, andsoftware that manages the TPM must infer this from observed behavior.
The range of adjustment of the rate is dependent on the design of the TPM. It is required that thevariation in the rate be large enough that it will allow software to adjust the rate of Clock advance to be
the same as UTC. The TPM should not allow rate adjustments that are larger than the design tolerance of
the TPM.
EXAMPLE 1

A TPM is designed to have a nominal internal oscillator frequency of 10 MHz with a tolerance of +/ 15% and a presettable counter that is used to count the oscillator clocks and generate an output
every second that is used to advance Clock. To cover the tolerance of the oscillator, the preset forthe counter would have to be between 8,500,000 and 11,500,000.

EXAMPLE 2

A TPM is designed as above but with the additional ability to accept an outside frequency reference
as long as that reference is at least +/-15%. If the external source is more accurate than +/ -15%,
then the TPM may still allow an adjustment over the 8,500,000 to 11,500,000 range.

NOTE 1In the worst case, an attacker who knows either the Platform Authori zation or Owner Authorization
value may be able to make the TPM run 32.5% (1.15 2 ) fast or slow. However, an attacker who knows
the Platform Authorization or Owner Authorization could also set Clock arbitrarily far into the future.

An error is returned if external software tries to adjust the clock rate outside specified bounds.
The TPM may store adjustments to the nominal clock rate in volatile memory. If it does, then adjustment
should only be stored on an orderly shutdown and not during the actions of TPM2_ClockRateAdjust().
That is, the adjustment value should be in volatile memory and only saved to nonvolatile memory on anorderly shutdown.
NOTE 2

36.4

This constraint on TPM2_ClockRateAdjust() is so that software may make changes to the rate atarbitrarily high rates without causing an NV event that might require throttling.

resetCountThe resetCount is a non-volatile, 32-bit counter that is incremented on a successful TPM Reset. It may beread using TPM2_ReadClock() and be used in an authorization policy (TPM2_PolicyCounterTimer()).
Additionally, the contents of the resetCount are included in the attestation data for any of the attestationcommands.
NOTE 1

Depending on the hierarchy of the signing key, the value of resetCount can be obfuscated so that averifier can tell that the counter has changed but cannot know the absolute value of the counter.

The purposes of resetCount are to indicate when the static trust state of the platform may have changed
and to indicate a possible discontinuity in Clock.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 213
December 24, 2020

Trusted Platform Module Library
EXAMPLENOTE 2

Part 1: Architecture

Without the resetCount, the sequence - (1) attest to trusted values (2) transition to an untrusted state(3) perform a transaction (4) TPM Reset (5) attest to trusted value - would hide the fact that thetransaction may have occurred during an untrusted state.
Since the volatile Clock is reloaded from the NV Clock on each _TPM_Init, the volatile Clock willlose some time in nearly all circumstances.

resetCount is incremented whenever the TPM starts up and all previous state is lost (i.e., on a TPM
Reset). resetCount is set to zero in TPM2_Clear().
36.5

restartCountIn addition to TPM Reset, other events may cause a discontinuity in TPM-recorded time or in the Root ofTrust for Reporting (RTR). A suspend-resume cycle will cause a time discontinuity. _TPM_Hash_Start
can cause an RTR discontinuity in the dynamic Root of Trust for Measurement (D-RTM) PCR. The
restartCount is used to provide an indication of these discontinuities.
The restartCount is a non-volatile, 32-bit counter that increments when the TPM executes TPM Resume,
TPM Restart, or _TPM_Hash_Start. Since resetCount increments on each TPM Reset, the combination ofresetCount and restartCount accounts for the cases when a discontinuity may occur, allowing TPM Time
to fall behind real time.
NOTE

When software sets Clock forward, that is a positive time discontinuity under control of software.
The negative discontinuities of Clock are due to hardware actions that may be outside of the controlof software.

The combination of resetCount and restartCount also accounts for the discontinuities of the RTR. A
change in resetCount indicates a discontinuity in the static RTR, and a change in restartCount indicates achange in the dynamic RTR.
restartCount is reset to 0 on TPM Reset – when resetCount is incremented. This does not cause a loss of
information about the dynamic RTR because a change to resetCount also implies a change to the
dynamic RTR.
36.6

Note on the Accuracy and Reliability of Clock

Clock is designed to allow a managed environment, such as enterprise, to maintain a small deviation
between Clock and real time. If the platform is not managed, if the platform falls into the hands of an
adversary, or if the platform is controlled by malware, then accuracy of Clock is diminished. This note
addresses considerations that influence the applicability of Clock for time-stamping and for time-limited
objects.
This analysis assumes that the TPM is not physically attacked, but that adversaries may manipulate
external software and local clocks like the CMOS clock on PC platforms.
It is assumed that, under normal operation, external software adjusts Clock at platform startup andsubsequently makes occasional additional rate and forwarding adjustments to ensure that Clock remains
within acceptable tolerances. Enterprise management servers or web services may occasionally request
time-stamped nonces to check that Clock meets network policy.
If Clock is used to time-stamp event log entries, then server software should ensure that Clock is accurate(as described above), and client software may occasionally record TPM Time values counter-signed byexternal authoritative time-stamping services to provide fiduciary time markers. These services may
include the Clock and Time values as well as the initialization counters (resetCount and restartCount).
The minimal security guarantees provided by the TPM in this case are

Page 214
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library•

proper ordering of events logged at times greater than 1 millisecond apart (apart from whenassociated with discontinuities in the resetCount and restartCount), and•that time stamps can never be forged to indicate a time in the past. If the value of Clock could be“stale,” Safe will indicate as much. If Clock has occasionally been reported to other authorities or
has been counter-signed, then the accuracy of the other time stamps can be interpolated moreaccurately.

If Clock is used to lifetime-limit objects, then when the platform is properly managed, objects will become
inaccessible with temporal accuracy related to the precision of clock management and the update intervalof NV Clock. If the lifetime has the granularity of NV Clock update, then once it becomes inaccessible, itcannot be recovered because, at that granularity, Clock will not move backward. If the granularity of the
lifetime needs to be shorter than the update interval of Clock, then the Safe flag can be checked to see if
the value of Clock may be “stale” or not.
If the platform falls into adversarial hands, the attacker will never be able to recover already revoked
objects. However, for objects with lifetimes in the future, an adversary may effectively stop the passage oftime so that objects never expire.
EXAMPLETo make TPM Time “stop,” the platform is recommended to only be turned on briefly to access thetime-limited object and then turned off in a way that prevents an orderly shutdown of the TPM. If the
TPM is left on for less than the update interval and the platfor m does not have an orderly shutdown,
Clock will continue to repeat values within the range of an update interval. In a managed
environment, a platform with a Clock that has a value that is substantially different from real time will
likely be denied further network services. For a system in an unmanaged environment, a more
complex policy using resetCount and Time may be used to limit access to objects even if time does
not advance (for example, the policy may allow access for 20 minutes or 2 reboots).

When the owner of the platform changes (new SPS generated) Clock is reset to zero. Using Clock to dotime stamping with a non-duplicable key does not constitute a vulnerability because the signing key also
becomes inaccessible when the owner changes, so no new events can be created. If the time-stamping
key is duplicable, then a more detailed security analysis is needed — for instance, examination of the
Qualified Name in the signing structure.
If Clock is used in other policy settings, similar considerations apply. If an object is destroyed when theowner is changed, then Clock reset is benign. However, if an object survives an owner change (such as,
an NV Index created by the platform), then use of Clock in its access policy may not be appropriate.
36.7

Privacy Aspects of Clock

The attestation structures return several values that, when taken together, may be sufficiently unique toidentity a specific platform. For example, the difference between Clock and Time is, during the interval ofa boot, likely to be somewhat unique for a platform. When combined with resetCount and restartCount,the values can become very indicative of a specific platform. If these values allow signatures from two
keys to be correlated, then those keys remain correlated as long as they are in use. The TPM uses
authorizations and obfuscation values to prevent this type of unwanted correlation.
All attestations contain a TPMS_CLOCK_INFO structure. That structure contains Clock, resetCount,restartCount, and Safe. The attestation structure also contains a 64-bit value that is indicative of thefirmware version number. When these values are going to be signed by a key that is not in the Platform orEndorsement hierarchy, resetCount, restartCount, and firmware version number have a key-specific value
added to them before they are put into the attestation structure. The addition allows the determination ofchange in values but prevents disclosure of the exact value.
Each Attestation Key has a different 128-bit obfuscation value that is constant for the lifetime of the key. It
is computed by:

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 215
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

obfuscation ≔ KDFa (signHandle→nameAlg, shProof, “OBFUSCATE”,
signHandle→QN, 0, 128 )Page 216
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021(56)

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

NV Memory
37.1

Introduction

Each TPM is required to have some non-volatile memory. This memory is used to retain values acrosspower events. The NV memory is used to hold:•

NV Index values,•

objects made persistent by TPM2_EvictControl,•state saved by TPM2_Shutdown(), and•Persistent NV data.

37.2

NV IndicesDefinition

An NV Index is space that is defined by a user of the TPM. The Index is identified by a unique handle
value. An NV Index handle has an MSO of TPM_HT_NV_INDEX.
The NV Index structure has:•

An identifying handle – this handle is assigned by the caller when the Index is defined and is used
to reference the Index. The handle associated with an Index has an MSO of
TPM_HT_NV_INDEX.

•

A nameAlg – this parameter indicates the hash algorithm used in the computation of the Name of
the Index (see clause 16).

•

An authorization policy – this parameter is optional and is the digest of the policy for the NV Index.
For the policy to apply to an operation, the corresponding TPMA_NV_POLICY_READ,
TPMA_NV_POLICY_WRITE, or TPMA_NV_POLICY_DELETE attribute needs to be SET.
Different policies for read, write, and delete can be achieved using policy OR terms and
TPM2_PolicyCommandCode().

•A set of NV Index attributes – this parameter determines the nature of the Index and who may
manipulate or read the Index.

•

An authorization value that is no larger than the size of the digest produced by the nameAlg of
the NV Index.

•

A value indicating the size of the Index data – this parameter indicates the number of octets thatare required to hold the NV data. For some Index types, the size is fixed.

•

The NV Index data that may be modified according to the type of the NV Index.

All the parts of the NV Index structure, except for the authValue and Index data, constitute the public
portion of the Index. They are hashed using the nameAlg to produce the Name of the Index.
The public area of the Index may be read using TPM2_NV_ReadPublic().
NOTE

TPM2_NV_ReadPublic() also returns the Name of the NV Index.

An NV Index can be designated as a hybrid Index. A hybrid Index is intended for applications where
frequent updates are expected. High frequency updates are generally not compatible with the technology
currently used for nonvolatile storage on a TPM. A hybrid Index maintains a volatile (RAM) and a nonvolatile copy of its Index data. A write to an ordinary Index is immediately written to NV memory but a
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 217
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

write to a hybrid Index may only update the copy of the Index data in RAM. The non-volatile copy of a
hybrid NV Index is updated on TPM2_Shutdown().
If an NV Index has TPMA_NV_ORDERY SET, then it is a hybrid Index.
NOTE 1The user of a hybrid NV Index will understand that data may be lost if the TPM does not shut downin an orderly fashion so that the volatile data can be written to NV memory.

Whether or not NV Index is a hybrid, when an NV Index is defined (TPM2_NV_DefineSpace()), thepersistent values of the NV Index are written to NV if the command completes successfully.
Any NV Index type can be defined as a hybrid. The conditions under which the write to NV memory occur
vary and are described below.
NOTE 2

An implementation is not required to support an arbitrary number of hybrid indices and is not
required to support any ordinary hybrid Index with a size of more than eight octets.

NV Index Allocation
An NV Index is allocated with TPM2_NV_DefineSpace(). Either Platform Authorization or Owner
Authorization is required in order to allocate an Index. The caller indicates the NV Index to assign to the
NV location, the access controls for the Index, and the type and or size of the data buffer that should bereserved for writing. While the allocation process does write the meta-data for the Index to NV, it does notwrite to the data area of the Index data and a read of the NV location before it is written will return anerror (TPM_RC_NV_UNINITIALIZED).
When an NV Index is defined (TPM2_NV_DefineSpace), its TPMA_NV_WRITTEN attribute will be
CLEAR. Until the Index is written by a party that can satisfy the write policy, the Index is defined but has
no data, and TPM2_PolicyNV() and TPM2_NV_Read() will fail.
TPMA_NV_WRITTEN is SET when an authorized party first writes the Index. This permits a relying party
to know that the value in the Index was written by an authorized party. It is not simply a default value thatwas present when the Index was defined (or deleted and redefined to attempt a roll back.)
A replying party can read the Index attributes and policy, which are public, to determine the authorized
party.
NOTE

The meta-data of an NV Index is the data relating to the NV Index description (Index number, policy,
attributes, data size, and authValue) along with any additional information that the TPM needs tomanage the NV Index memory.

Different types of NV Index may be supported.
•

Ordinary – an Index with an NV Index type of TPM_NT_ORDINARY contains data that is opaque tothe TPM that is modified using TPM2_NV_Write().

•Counter – an Index with an NV Index type of TPM_NT_COUNTER contains a 64-bit counter that is
modified using TPM2_NV_Increment().

•

Bit field – an Index with an NV Index type of TPM_NT_BITS contains 64 bits that are initialized to 0
and are modified using TPM2_NV_SetBits().

•

Extend – an Index with an NV Index type of TPM_NT_EXTEND contains a value that has behavior
similar to a PCR and is modified using TPM2_NV_Extend().

•

PIN Fail - an Index with an NV Index type of TPM_NT_PIN_FAIL that contains a
TPMS_NV_PIN_COUNTER_PARAMETERS structure that is modified using TPM2_NV_Write() or byusing the authValue of the Index. pinCount is reset when an authorization attempt using authValue
succeeds. pinCount is incremented after an authorization attempt using authValue fails. pinCount

Page 218
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Librarycannot increment beyond pinLimit because authValue authorization is locked out if pinCount >=pinLimit. A Pin Fail Index can be modified with TPM2_NV_Write.
•

PIN Pass - an Index with an NV Index type of TPM_NT_PIN_PASS that contains a
TPMS_NV_PIN_COUNTER_PARAMETERS structure that is modified using TPM2_NV_Write() or byusing the authValue of the Index. pinCount is incremented after an authorization attempt using
authValue succeeds. pinCount cannot increment beyond pinLimit because authValue authorization islocked out if pinCount >= pinLimit. A Pin Pass Index can be modified with TPM2_NV_Write.

TPM2_NV_DefineSpace() can fail if an Index with the requested handle already exists or if there isinsufficient NV memory for the allocation. Creation of a hybrid Index will fail if there is insufficient RAM
available for the allocation. The command will fail if an Index type is not supported.
EXAMPLE

If the TPM does not implement TPM2_NV_Extend(), then the TPM will not allow creation of an NV
Index that has the TPMA_NV_EXTEND attribute.

If the Index to be created has its TPMA_NV_POLICY_DELETE attribute SET, then platform authorizationisrequiredforallocation.
This
attributeisonlyallowedtobeselectedif
TPM2_NV_UndefineSpaceSpecial() is implemented on the TPM.
NOTEThis attribute indicates that a policy is required to delete the Index. It permits creation of an Index
that can never be deleted. One example is an Empty Policy, which can never be satisfied. Anotherexampleisapolicy
that
does
not
includeTPM2_PolicyCommandCodewith
TPM_CC_NV_UndefineSpaceSpecial. Requiring platform authorization protects against the current
TPM owner creating such an Index.

NV Index Deletion
An
NV
Index
can
be
removed
TPM2_NV_UndefineSpaceSpecial().

using

either

TPM2_NV_UndefineSpace()or

If the TPMA_NV_POLICY_DELETE attribute is SET, then the Index can only be deleted if ADMIN roleauthorization is provided. ADMIN role authorization is provided by a policy session with thecommandCode of the policy set to TPM2_NV_UndefineSpaceSpecial().
TPM2_NV_UndefineSpace is used to delete other Indices from the NV. The authorization given fordeleting the Index is required to be the same as the authorization given to allocate the Index.
TPM2_Clear() will remove any NV Index that used Owner Authorization to define the Index.
TPM2_Clear() uses either TPM_RH_LOCKOUT or TPM_RH_PLATFORM.
TPM2_ChangePPS() does not cause any NV Index to be removed.
To comply with FIPS-140, the data contents and authorization value must be zeroized when the NV Index
is deleted.
High-Endurance (Hybrid) Indices37.2.4.1

Description

Some applications need the ability to make frequent updates to non-volatile values such as monotonic
counters. A high update rate is generally not compatible with the technology currently used for nonvolatile storage on a TPM. To allow the TPM to support high-update rates while protecting the enduranceof the NV memory, a hybrid Index type is defined.
When an NV Index is defined with the TPMA_NV_ORDERLY attribute SET, the TPM will allocate therequired NV memory as well as space in TPM RAM for the data value. During normal operation, updates
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 219
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

to the Index will modify the RAM copy of the Index data with updates to the NV on Shutdown() or
whenever the RAM copy of a counter is divisible by a set modulus. In some cases, the data write may
never occur.
NOTE

The value of the modulus is implementation specific and can be accessed using
TPM2_GetCapability(capability==
TPM_CAP_TPM_PROPERTY,
property==
TPM_PT_ORDERLY_COUNT). The returned value is the modulus – 1. This value is referred to as
MAX_ORDERLY_COUNT.

If the TPMA_NV_ORDERLY attribute of an Index is SET, the TPM will perform special processing on the
Index at TPM2_Startup(). The processing is dependent on the type of the Index.
37.2.4.2

Hybrid Indices Other than Counter Indices

For hybrid Indices that are not Counters, the NV Index data in volatile memory is copied to non-volatilememory on a Shutdown(STATE), Thedata need not be copied to non-volatile memory on
Shutdown(CLEAR).
On TPM Resume, the non-volatile copy of the Index data is copied into the volatile version of the NV
Index data.
On TPM Reset, the TPMA_NV_WRITTEN attribute will be initialized to CLEAR. On a subsequent
update of the Index, it will be initialized before it is updated.
On TPM Restart, if TPMA_NV_CLEAR_STCLEAR is SET, the NV Index is initialized as in b) above. If
TPMA_NV_CLEAR_STCLEAR is CLEAR, then the NV Index is initialized as in a) above.
NOTE

37.2.4.3

TPMA_NV_CLEAR_STCLEAR cannot be SET if the NV Index type is TPMA_NV_COUNTER.
Counters are either restored (on an orderly startup) or set to a higher value (on a non -orderly
startup).

Counter Hybrid Indices

The hybrid counter Index is designed so that it will be monotonically increasing and not miss an increment
command regardless of the type of shutdown or startup.
For a Counter NV Index with the TPMA_NV_ORDERLY attribute, Index data in non-volatile memory is
written to NV on any Shutdown().
NOTE 1

For a Counter (or any other Index) that has TPM A_NV_ORDERLY CLEAR, non-volatile memory is
written on any update of the NV Index.

On any orderly startup of the TPM (TPM2_Startup() following an orderly shutdown), the NV value of a
hybrid counter Index will be copied to the RAM version. The count will be able to continue without any
discontinuity.
On a non-orderly startup, the value of the counter in NV is adjusted before it is copied to RAM. A counter
is adjusted by logical OR of the value of MAX_ORDERLY_COUNT to the NV value. This sets the RAM
version of the counter to the maximum value it could have had before being updated due to the modulus
test. This ensures that the RAM counter value is no less than any previously used counter value.
EXAMPLE

Assume that MAX_ORDERLY_COUNT contains 0F FF 16 and that the TPM lost power without anorderly shutdown. On a startup, if an orderly counter is found to have a value of
00 00 00 00 00 01 73 A1 16 , then the RAM version is updated to 00 00 00 00 00 01 7F FF 16 .

NOTE 2

When the RAM version of the counter is set this way, it is not necessary to immediately update thecounter to NV. If the counter is incremented, then it will be automatically saved to NV when the low
bits become zero.

Page 220
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
NOTE 3

Trusted Platform Module Library

If the RAM counter were initialized so that the low bits we re zero and a subsequent un-orderly
shutdown occurred, the counter would have to be advanced again, whether it had been incremented
or not. By setting the counter to the maximum value before NV update, there is no need to advancethe count on a subsequent unorderly shutdown unless the counter was used.

Reading an NV Index
Read access to an NV Index is provided with TPM2_NV_Read(), TPM2_NV_Certify(), andTPM2_PolicyNV(). For all of these commands, read authorization is required. The attributes of the Index
determine what authorizations are allowed. TPMA_NV_PPREAD allows the Index to be read using
Platform Authorization; TPMA_NV_OWNERREAD allows the Index to be read using Owner Authorization;
TPMA_NV_AUTHREAD allows the Index to be read using the authValue of the Index; andTPMA_NV_POLICYREAD allows the Index to be read if the authPolicy of the Index is satisfied.
At least one of TPMA_NV_PPREAD, TPMA_NV_OWNERREAD, TPMA_NV_AUTHREAD
TPMA_NV_POLICYREAD needs to be SET or the TPM will not allocate the Index.

orAn access control (TPMA_NV_READ_STCLEAR) allows reading of the Index to be temporarily blocked.
When this attribute is SET, TPM2_NV_ReadLock() may be used to temporarily disable read access to theIndex. When the Index has been locked for read, the TPMA_NV_READLOCKED attribute of the Index will
be SET. TPMA_NV_READLOCKED will be CLEAR on the next TPM Reset or TPM Restart. If the
TPMA_NV_READLOCKED attribute is SET when the Index is read, the TPM returns
TPM_RC_NV_LOCKED.
The authPolicy of the NV Index may be constructed such that it only applies for reading or for writing. It
may be constructed to allow general reading and limited writing or general writing and limited reading. If
reading or writing of the Index is to be restricted based on PCR values, then read authorization needs touse authPolicy.
Updating an Index
37.2.6.1

Introduction

The command used to update an Index is determined by the NV Index type. TPM2_NV_Write() is used tomodify an Ordinary Index or a PIN Index, TPM2_NV_Increment() is used to modify a Counter Index,
TPM2_NV_SetBits() is used to modify a Bit Field Index, and TPM2_NV_Extend() is used to modify an
Extend Index. For all of these commands, write authorization is required.
The attributes of the Index determine what authorizations are allowed. TPMA_NV_PPWRITE allows theIndex to be modified using Platform Authorization; TPMA_NV_OWNERWRITE allows the Index to bemodified using Owner Authorization; TPMA_NV_AUTHWRITE allows the Index to be modified using theauthValue of the Index; and TPMA_NV_POLICYWRITE allows the Index to be modified if the authPolicyof the Index is satisfied.
At least one of TPMA_NV_PPWRITE, TPMA_NV_OWNERWRITE, TPMA_NV_AUTHWRITE or
TPMA_NV_POLICYWRITE needs to be SET or the TPM will not allocate the Index. For a PIN Index,
TPMA_NV_AUTHWRITE may not be SET and at least one of the other three write methods is required to
be selected.
NOTE 1

A method other than TPMA_NV_AUTHWRITE is required for a PIN Index because the authValue ofa PIN Index is not accessible until the Index is writ ten.

If the access control attribute TPMA_NV_WRITEDEFINE is SET, TPM2_NV_WriteLock() or
TPM2_NV_GlobalWriteLock() may be used to permanently disable modify access to the Index. When the
Index has been locked for modify, the TPMA_NV_WRITELOCKED attribute of the Index will be SET. This
attribute will remain SET until the Index is deleted (TPM2_NV_UndefineSpace()).
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 221
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

If TPMA_NV_WRITEDEFINE is CLEAR, the TPMA_NV_WRITELOCKED attribute can be SET using
TPM2_NV_WriteLock() if TPMA_NV_WRITE_STCLEAR is SET or TPM2_NV_GlobalWriteLock() if
TPMA_NV_GLOBALLOCK is SET. In this case, TPMA_NV_WRITELOCKED will be CLEAR on the next
TPM Reset or TPM Restart.
NOTE

If
TPMA_NV_WRITELOCKED
is
SET,
but
TPMA_NV_WRITTENis
CLEAR,
then
TPMA_NV_WRITELOCKED is CLEAR by TPM Reset or TPM Restart. This is true even if the
TPMA_NV_WRITEDEFINE attribute is set. It prevents an NV Index from being defined that cannever be written and permits a use case where an Index is defined, but the user wants to proh ibit
writes until after a reboot.

If the TPMA_NV_WRITELOCKED attribute is SET when an attempt is made to modify the Index, the TPM
returns TPM_RC_NV_LOCKED.
For a PIN Fail Index, the TPM will return TPM_RC_NC_ATTRIBUTES if TPMA_NV_NO_DA is CLEAR.
37.2.6.2

NV Ordinary Index Update

TPM2_NV_Write() is used to modify the contents of an ordinary Index. The modification may be to theentire Index or, if the Index attributes allow (TPMA_NV_WRITE_ALL CLEAR), the size of the data to write
can be as small as zero octets.
When a partial write is allowed, the offset parameter of TPM2_NV_Write() may be non-zero or the size ofthe data parameter may be less than the size of the Index. The TPM checks the TPMA_NV_WRITTEN
attribute. If it is CLEAR, then the TPM will initialize the remainder of the Index to either all zero or all one.
Alternatively, the TPM can initialize the entire Index at the time the Index is defined.
If the sum of the size of the data parameter and the offset parameter in TPM2_NV_Write() is greater than
the size of the Index, then the TPM will not perform the write and will return an error.
On any TPM2_NV_Write() (including a size of zero), if the modification is successful, then the
TPMA_NV_WRITTEN attribute of the Index will be SET. Any octets not initialized by the first write will
have a value of all zero or all one.
EXAMPLE

If the Index is defined to contain 2 octets, and the first write of the Index is a single octet of 55 16 , tooffset 0, then the next read of the full Index will return 55 00 16 .

If the Ordinary Index has the TPMA_NV_ORDERLY attribute, then only the RAM version of the Index iswritten. The data is preserved on a Shutdown(STATE).
37.2.6.3

NV Counter Index

When an Index has the TPMA_NV_COUNTER attribute, it behaves as a monotonic counter and may only
be modified using TPM2_NV_Increment().
When an NV counter is created, it has no value and the TPMA_NV_WRITTEN attribute will be CLEAR.
On each TPM2_NV_Increment() the TPM checks the TPMA_NV_WRITTEN attribute of the Index. If it is
CLEAR, then the TPM will initialize the 8-octet counter value such that the first increment will set a valuethat is greater than any value that a counter Index with the same Name has had over the lifetime of the
TPM. The TPMA_NV_WRITTEN attribute will be SET.
NOTE 1This check ensures that an Index cannot be deleted and another Index with the same Name definedwith a lower value.

NOTE 2

The reference implementation implements this by tracking and using the largest count of any deleted
NV Counter. An alternative implementation could track the largest count of any NV Counter, deleted
or currently defined.

Page 222
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

After checking TPMA_NV_WRITTEN and performing any required initialization operations, the TPM will
increment the Counter.
NOTE 3

The TPM will need to maintain a largest-count value. It is not necessary to update this value except
when a NV Index is deleted. If the NV Index being deleted has the largest value held by an NV
Index, then this value would be copied to the largest -count value. The value of an NV Counter Index
after the first increment is larger than the largest-count value.

NOTE 4Since no counter can ever repeat a previous value ever contained in any NV Counter Index, acounter with a particular Name cannot be rolled back by deleting it and redefining it.

If the TPMA_NV_ORDERLY attribute is CLEAR, the increment will occur on the NV version of the counter(no RAM version exists). If the TPMA_NV_ORDERLY attribute is SET, the increment will occur on the
RAM version of the counter, and if this causes a rollover, the NV version of the counter is updated.
However, if TPMA_NV_WRITTEN is CLEAR, the NV version of the counter is also written. Once SET,
TPMA_NV_WRITTEN of a counter is never CLEAR.
An Index may be defined with the TPMA_NV_ORDERLY attribute to indicate that the Index is expected tobe modified at a high frequency and that the data is only required to persist when the TPM goes throughan orderly shutdown process. For a counter, it also means that it will be written to NV when the counterhas reached some threshold value. The threshold value for counters (MAX_ORDERLY_COUNT) is
implementation dependent and can be read using TPM2_GetCapability(capability = TPM_CAP_PT,
property = TPM_PT_ORDERLY_COUNT). This property has one of 32 values that can be expressed as(2N-1) where N is between 1 and 32.
EXAMPLE

If MAX_ORDERLY_COUNT is 00 00 0F FF 16 , then whenever the RAM version of a counter isincrementing, causing the low-order 12 bits to be zero, the NV version of the counter is updated.

The meaning of this threshold value is that when the counter is incremented such that the counter value
ANDed with MAX_ORDERLY_COUNT is zero, then the NV version of the counter will be updated.
NOTE 5Another way to express this is to simply say that the NV version of the counter will b e updated when
the low order bits of the counter “roll-over”.

The TPM is required to ensure that, when an NV Counter is read, its value is not less than a previously
reported value of the counter. That is, it may not go backward. If the shutdown was orderly, then,regardless of the type of the NV Counter, the NV value of a counter will not be less than the last reported
value. If the shutdown was not orderly and the NV Counter has the TPMA_NV_ORDERLY attribute, thena value of the Counter may have been read from the RAM version of the counter but the NV version may
not have been updated. To handle this case, if the TPMA_NV_ORDERLY attribute of an NV Counter is
SET, and the TPM shutdown was not orderly, then, at TPM2_Startup() the TPM will OR the value of
MAX_ORDERLY_COUNT to the contents of the non-volatile counter and set that as the current count in
the RAM version of the counter.
NOTE 6

The TPM has to prevent a rollback attack caused by a counter being deleted and then being
recreated with a lower value. To do this, the TPM may keep track of the value of the highest count ofa deleted counter using a phantom counter. When a counter is deleted, the current value of thecounter is compared to the current phantom counter and other counters. If the value is lar ger thanthe phantom counter and other counters, the phantom counter is updated. When a new NV counteris created, it starts with the highest value of all the counters, including the phantom counter.

For a Counter with the TPMA_NV_ORDERLY attribute SET, the NV copy of the data will be updated
whenever a specified number of low order bits of the RAM copy become all zeros. That number of loworder bits is TPM implementation-dependent. The setting for a TPM may be found using
TPM2_GetCapability(TPM_CAP_TPM_PROPERTIES, TPM_PT_ORDERLY_COUNT). That capability is
MAX_ORDERLY_COUNT.
The TPMA_NV_CLEAR_STCLEAR attribute has no effect on an NV Counter Index and it may be SET or
CLEAR in the template.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 223
December 24, 2020

Trusted Platform Module Library
37.2.6.4

Part 1: Architecture

NV Bit Field Index

When an Index has the TPMA_NV_BITS attribute it may only be modified by TPM2_NV_SetBits().
When an NV Bit Field Index is created, it has no value and the TPMA_NV_WRITTEN attribute will be
CLEAR.
On each TPM2_NV_SetBits(), the TPM will check the TPMA_NV_WRITTEN attribute of the Index. If it is
CLEAR, the TPM will set the 64 bits of the Index to zero. The TPM will then SET the
TPMA_NV_WRITTEN attribute for the Index.
After checking TPMA_NV_WRITTEN and doing any necessary initialization, the TPM will OR the bits
parameter to the Index.
If the TPMA_NV_ORDERLY attribute is not SET, the NV value of the Index is written with the modified
value. If no bits were SET in the bits, the NV Index data will only be updated if TPMA_NV_WRITTEN was
CLEAR when the command execution was started.
If TPMA_NV_ORDERLY is SET, the RAM version of the Bit Field data is updated but it is not written to
NV. The data is only preserved to NV on a Shutdown(STATE), and on TPM Reset, the
TPMA_NV_WRITTEN attribute of the Index will be CLEAR.
37.2.6.5

NV Extend Index

When an Index has the TPMA_NV_EXTEND attribute, it may only be modified by TPM2_NV_Extend().
When an NV Extend Index is created, it has no value and the TPMA_NV_WRITTEN attribute will be
CLEAR.
On each TPM2_NV_Extend(), the TPM will check the TPMA_NV_WRITTEN attribute of the Index. If it is
CLEAR, the TPM will initialize the Index to a Zero Digest that is the size of the digest produced by the
nameAlg of the Index. The TPM will then SET the TPMA_NV_WRITTEN attribute for the Index.
After checking TPMA_NV_WRITTEN and doing any necessary initialization, the TPM will extend theIndex using:nvIndex→datanew ≔ HnameAlg (nvIndex→dataold || data.buffer)

(57)

where

HnameAlg

the hash algorithm indicated in nvIndex→nameAlg

nvIndex→data

the value of the data field in the Index

data.buffer

the data buffer of the command parameter

If the TPMA_NV_ORDERLY attribute is not SET, the NV value of the Index is written with the modified
value.
If TPMA_NV_ORDERLY is SET, the RAM version of the Index is updated but it is not written to NV. The
data is only preserved on a Shutdown(STATE), and on TPM Reset, the TPMA_NV_WRITTEN attribute of
the Index will be CLEAR..

Page 224
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
37.2.6.6

Trusted Platform Module Library

NV PIN Index

TPM2_NV_Write() is used to modify the contents of a PIN Index. The modification may be to the entire
Index or, if the Index attributes allow (TPMA_NV_WRITE_ALL CLEAR), the size of the data to write canbe as small as zero octets.
When a partial write is allowed, the offset parameter of TPM2_NV_Write() may be non-zero or the size ofthe data parameter may be less than the size of the Index. The TPM checks the TPMA_NV_WRITTEN
attribute. If it is CLEAR, then the TPM will initialize the remainder of the Index to either all zero or all one.
Alternatively, the TPM can initialize the entire Index at the time the Index is defined.
If the sum of the size of the data parameter and the offset parameter in TPM2_NV_Write() is greater than
the size of the Index, then the TPM will not perform the write and will return an error.
On any TPM2_NV_Write() (including a size of zero), if the modification is successful, then the
TPMA_NV_WRITTEN attribute of the Index will be SET. Any octets not initialized by the first write will
have a value of zero.
EXAMPLE

If the Index is defined to contain 2 octets, and the first write of the Index is a single octet of 55 16 , tooffset 0, then the next read of the full Index will return 55 00 16 .

If the Index has the TPMA_NV_ORDERLY attribute SET, then only the RAM version of the Index iswritten. The data is only preserved to NV on a Shutdown(STATE), and on TPM Reset, the
TPMA_NV_WRITTEN attribute of the Index will be CLEAR.
If the authValue of an PIN Index is used for authorization, then the authorization will fail if the pinCount
field of the Index is not less than the pinLimit field or if the TPMA_NV_WRITTEN attribute of the Index is
CLEAR.
When the authValue of a PIN Index is used for authorization and the authorization succeeds, thepinCount field is set to zero if the Index is PIN Fail and incremented if the Index is PIN Pass. If theauthorization fails, pinCount is incremented for a PIN Fail Index and left unchanged for a PIN Pass Index.
NV Index in a Policy
TPM2_PolicyNV() may be used to include the contents of an NV Index in a policy command.
TPM2_PolicyNV() allows various comparisons of the value of the NV data with a reference value.
TPM2_PolicyNV() is an immediate assertion (see 19.7.7.2). If the comparison succeeds, the TPM will
update the policyDigest with the comparison values and the access controls on the referenced Index,
including the authPolicy. Inclusion of the update policy of the Index provides a means of identifying the
update properties of the Index. To make effective use of this command, writing of the Index should be
dependent on authPolicy. If the policy must be met in order to write the Index, then it is possible to ensurethat only the correct entity may recreate the Index. If other write authorizations are allowed, then it is notpossible to know if the Index was written by a known entity.
If an NV Index is used in TPM2_PolicyNV() after it is defined but before it is first written, then the TPM will
return an error.
The nominal use of a PIN Index is to reference the Index in an entity’s policy in TPM2_PolicySecret(). The
TPM2_PolicySecret() will succeed if pinCount is less than pinLimit and the caller is able to provide theauthValue of the Index in the authorization. If the rest of the policy is satisfied, access to the PINprotected entity will be allowed.
NOTE 1A PIN Fail Index provides a form of individual Dictionary Attack defense that is not affected by the
TPM's global Dictionary Attack mechanism. In particular, it can be used to allow the TPM to emulate
the behavior of a smart card.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 225
December 24, 2020

Trusted Platform Module Library
NOTE 2

Part 1: Architecture

A PIN Pass Index allows count-limited use of a TPM object. An example use would be to only allow
access to a decryption key for protected content.

PIN Index Considerations
37.2.8.1

Restricting the number of uses of an object with PIN Pass

It is possible to limit the number of authValue (PIN) authorizations of a particular key or entity.
A key or object has a limited number of authorizations when its policy has a TPM2_PolicySecret assertion
pointing to a PIN Pass NV Index.
A PIN Pass's pinLimit is the number of correct authorization attempts that are permitted before
authorization via authValue is locked out. If pinCount is less than its pinLimit, pinCount is incremented
immediately by the TPM after authValue authorization succeeds. There is no automatic reset or
decrement method for pinCount. Once pinCount equals pinLimit, an administrator must reduce pinCount
and/or increase pinLimit using TPM2_NV_Write or delete the Index.
37.2.8.2

Localized Dictionary Attack protection with PIN FailIt is possible to authorize a particular key or object via an authValue (PIN) that has its own individual
Dictionary Attack defense and does not use (and is not affected by) the TPM's global Dictionary Attack
defense mechanism. This may be useful when a TPM is used to emulate a smartcard, for example.
A key or object has localized Dictionary Attack protection if its policy has a TPM2_PolicySecret assertion
pointing to an PIN Fail NV Index.
A PIN Fail's pinLimit is the number of incorrect authorization attempts that are permitted before
authorization via authValue is locked out. If pinCount is less than its pinLimit, pinCount is incremented
immediately by the TPM after authValue authorization fails. pinCount is reset to zero by the TPM
whenever authValue authorization succeeds.
NOTE

In the reference code prior to revision 1.56, a successful authorization with the PIN Index authPolicy
has the same effect on pinCount as a successful authorization with the PIN Index authValue. Thatmeans, for a PIN Pass NV Index, pinCount is incremented after authPolicy authorization succeeds,
and for a PIN Fail NV Index, pinCount is reset to zero after authPolicy authorization succeeds. Thisbehavior of the reference code was incorrect. Authorization with ownerAuth/ownerPolicy,
platformAuth/platformPolicy is not affected by this issue, and will not increment or reset pinCount.
To avoid this issue on some older implementations, it is recommended that Owner or Platform
authorization be used to read the PIN Index. It is recommended that the PIN Index authPolicy not be
used to read the PIN Index unless authValue is part of the policy for reading the Index. The following
setting is recommended for a PIN Pass or PIN Fail NV Index when the Index is defined:•

If the Owner authorized the creation of the index, TPMA_NV_ OWNERREAD is SET and
TPMA_NV_OWNERWRITE is CLEAR•

If the Platform authorized the creation of the index, TPMA_NV_PPREAD is SET and
TPMA_NV_PPWRITE is CLEAR•

TPMA_NV_POLICYREAD is CLEAR (unless authValue is part of the policy for reading theindex)•

TPMA_NV_POLICYWRITE is SET•

TPMA_NV_WRITEALL is SET

Page 226
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
37.2.8.3

Trusted Platform Module Library

PIN Index Attributes

A PIN Index may be read or write locked. If read or write locked, the Index may still be referenced by
TPM2_PolicySecret(). An Index disabled using phEnableNV (if platform created) or shEnable (if ownercreated) cannot be used in a policy. If a policy points to an unwritten PIN Pass or PIN Fail Index, theIndex’s authorization check must fail because pinLimit is not written.
NOTE 1

Allowing a PIN Index to be used when write locked allows it to be used as a PIN but prevents writingof the pinLimit.

TPMA_NV_ORDERLY may be SET or CLEAR, however, if SET the Index will revert to unwritten on TPM
Reset and possibly on TPM Restart (depending on TPMA_NV_CLEAR_STCLEAR). This will cause theIndex to not be usable for PIN authorization until it is reinitialized.
TPM2_PolicyAuthValue() and TPM2_PolicyPassword() cannot be used in the policy that does the initialwrite to a PIN Index. This is because these policy commands require that the authValue of the PIN Index
to be used and the authValue of a PIN Index cannot be used until it is first written. Therefore, it may bedesirable that TPMA_NV_POLICYWRITE is SET so that the PIN Index value may be initialized.
If TPMA_NV_POLICYREAD, TPMA_NV_PPREAD, or TPMA_NV_OWNERREAD is SET then the Index
may read using TPM2_NV_Read (with those authorizations) without affecting the contents of the Index. If
TPMA_NV_AUTHREAD is the only method of reading the Index, then the act of reading the Index couldchange its pinCount.
NOTE 2Using the NV Index authorization value for the read would consume a PIN Pass Index authorization
or reset the PIN Fail pinCount. In addition, authValue can't be used for authorization once pinCount>= pinLimit.

NOTE 3

In a PIN Fail Index, it may be desirable that TPMA_NV_AUTHREAD is SET, so pinCount can bereset by reading the NV Index with valid authValue authorization.

TPMA_NV_AUTHREAD is SET, so pinCount can be reset by reading the NV Index with valid authValue authorization.

It is recommended that the Index have a policy that includes a PolicySigned assertion, to unambiguously
identify the Index and the entity authorized to initialize the Index.
NOTE 4This prevents covert attacks where an Index is secretly deleted and replaced.

If the authObject parameter of TPM2_PolicySecret() references a PIN Pass Index, then the command
may succeed, but a NULL ticket will be returned. The reason is that the ticket could allow more accesses
to a count limited object than allowed by the PIN Pass Index.
NOTE 5

Without this restriction, a caller could get a ticket for a count limited object and use the ticket insteadof using the PIN Pass Index. This could, potentially, allow unlimited access to a PIN Pass entity.

If a PIN Pass or PIN Fail Index is referenced as a bind object, the TPM must return TPM_RC_HANDLE.
Otherwise, the sequence in which the TPM processes authorizations would enable a hammering attackon the Index.
Restrictions on PIN Pass and PIN Fail Indexes are specified in Part 3 TPM2_NV_DefineSpace.
37.3

Owner and Platform Evict Objects

In some applications, it is desirable for an object to be made persistent in the TPM so that it is always
available. An example of when this would be useful is for a Primary Key. Having the Primary Key bealways available avoids the time penalty of re-computing the Primary Key after each TPM Reset.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 227
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

TPM2_EvictControl() is used to make a loaded object persistent by saving it to the TPM’s NV memory.
This command is also used to remove a persistent object.
To be made persistent, an object needs to have both public and private portions loaded; the object cannot
be in the NULL hierarchy, the object cannot have the stClear attribute SET, and the object cannot be adescendant of a key with the stClear attribute SET.
The type of the objectHandle parameter of TPM2_EvictControl() determines if the Object is to be madepersistent or to be removed from persistent memory. If objectHandle is a Transient Object, it is madepersistent and, if objectHandle is a persistent object, it is deleted. The Transient Object is not affected.
When making a Transient Object persistent, the persistentHandle parameter of TPM2_EvictControl()indicates which handle is to be assigned to the persistent version of the object. The TPM will not allow
assignment of a persistent handle if that handle is already assigned to a persistent object.
If objectHandle is a Transient Object in the Platform Hierarchy, Platform Authorization must be provided.
If objectHandle is in the Endorsement or Storage Hierarchy, Owner Authorization is required.
The persistent handle space is divided evenly between the Platform and the Owner. The persistenthandles that may be assigned when Owner Authorization is provided are in the range 81 00 00 0016 to81 7F FF FF16. Handles in the range 81 80 00 0016 to 81 FF FF FF16 may be assigned when Platform
Authorization is provided. When removing a persistent object, the authorization used to persist the object
is required to remove it.
37.4

State Saved by TPM2_Shutdown()
Background

TPM2_Shutdown() is used for an orderly shutdown of the TPM. When doing an orderly shutdown, theTPM will save some state to NV memory. In the reference implantation, the state saved is separated into
three groups:
1) NV Orderly Data – data that is saved on any Shutdown and is not reset,
2) NV Clear Data – data that is saved on Shutdown(STATE) and is reset on TPM Restart or TPM Reset(such as, PCR), and
3) NV Reset Data – data that is saved on Shutdown(STATE) and is reset on TPM Reset (such as
session context tracking information).
NV Orderly Data
The data in this structure is saved to NV on any Shutdown type and restored on any Startup. It may havespecial initialization performed if the Startup is not orderly. In the reference implementation, this data iscollected into a special data structure (ORDERLY_DATA) the contents of which are illustrated in Table
31.
Table 31 — Contents of the ORDERLY_DATA Structure
Parameter

Description

Changed By:

clock

This is the version of Clock that is updated on any
Shutdown and on any rollover of the RAM version of
Clock.

TPM2_Clear(),
TPM2_Startup(),passage of time

Page 228
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryParameter

Description

Changed By:

clockSafe

used to determine the Safe value reported in the
TPMS_CLOCK_INFO structure. This value is CLEAR
when a Startup is not orderly and once CLEAR, is not
SET until the RAM value of Clock rolls over.

TPM2_Clear(),
TPM2_Startup(),passage of time

NV Clear Data
Data in this structure is saved to NV on any Shutdown(STATE) but is set to its default initialization value if
the subsequent Startup is either TPM Reset or TPM Restart. In the reference implementation, data of thistype is collected into a single data structure (STATE_CLEAR_DATA) as illustrated in Table 32.
NOTE

The default reset value is applied on either TPM Reset or TPM Restart. These change conditions are
not listed in the “Changed By” column.

Table 32 — Contents of the STATE_CLEAR_DATA Structure
Parameter

Description

Changed By

shEnablethe enable for the storage hierarchy. The default
initialization value is SET.

TPM2_HierarchyControl()ehEnablethe enable for the endorsement hierarchy. The default
initialization value is SET.

TPM2_HierarchyControl()phEnableNV

the enable for the platform hierarchy NV indices. The
default initialization value is SET.

TPM2_HierarchyControl()platformAlg

the hash algorithm used for platformPolicy. The default
initialization value is TPM_ALG_NULL

TPM2_SetPrimaryPolicy()

platformPolicy

the policy used if the authorization session is a policy
TPM2_SetPrimaryPolicy()
session and the authorized handle is
TPM_RH_PLATFORM. The default initialization value isan Empty Buffer.

platformAuth

the authorization value used if the authorization handle
is TPM_RH_PLATFORM and the authorization isprovided by password or an HMAC session. . The
default initialization value is an Empty Buffer.

pcrSavea data structure that holds the PCR that are preserved TPM2_PCR_Extend(),across Startup(STATE). The PCR in this structure are
TPM2_PCR_Event()
determined by a platform-specific TPM specification. .
The default initialization value for each PCR isdetermined by the relevant platform-specificspecification but is normally a Zero Digest for each PCR
in the structure.

TPM2_HierarchyChangeAuth()

NV Reset Data
Data in this structure is saved to NV on any Shutdown(STATE) and restored by a subsequent Startup of
any type. In the case of a TPM Reset, the values are set to their specified initialization value. In thereference implementation, data of this type is collected into a single data structure(STATE_RESET_DATA) as illustrated in Table 33.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 229
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Table 33 — Contents of the STATE_RESET_DATA Structure
Changed By (1)Parameter

Description

nullProof

proof value used with entities associated with the
TPM_RH_NULL hierarchy (including all session
contexts, sequences, and Temporary Objects);
initialization value is from the RNG

nullSeed

seed value used for creating Temporary Objects with
TPM_RH_NULL as a parent; initialization value isfrom the RNG

clearCounta value that is incremented each time the TPM
performs a TPM Restart; used to tag contexts for
stClear objects so that they may not be reloaded after
a TPM Restart; initialization value is zero

objectContextID

counter that is incremented each time an object is
TPM2_ContextSave()context saved; used to ensure that the encryption key
and IV for each saved object is unique; initialization
value is zerocontextArrayan array for keeping the version numbers of theassociated saved session contexts; used to prevent
replay of authorization sessions; each element isinitialized to zero indicating that it is not assigned

TPM2_ContextLoad(),
TPM2_ContextSave(),
TPM2_StartAuthSession()contextCountthe value used to set the version number for eachsaved context; initialization value is 0.

TPM2_ContextSave(),
TPM2_StartAuthSession()commandAuditDigest

the current command code audit digest; initialization
value is an Empty Digest.

Any audited command,
TPM2_GetCommandAuditDigest()

restartCountcounts the number of TPM Resume, TPM Restart, or
D-RTM events. Initialization value is zero.

TPM2_Startup(),_TPM_Hash_End

pcrUpdateCountercounts the number of changes to PCR; because this TPM2_PCR_Extend(),value is used in policy sessions, it is not reset until
TPM2_PCR_Event(),
the context protections for saved session contexts are
TPM2_PCR_Reset()changed. Initialization value is zerocommitCounterthe number of times TPM2_Commit() is executed;
initialization value is zero.

commitNonce

value used to create the pseudo-random values usedin two-phase signing operations; initialization value isfrom the random number generator.

commitArray

bit vector used to indicate that only one first phase ofa two phase signing operation has occurred;initialization value is all bits CLEAR.

NOTE (1)37.5

TPM2_Startup(CLEAR)

TPM2_Commit()

sign-phase of two-phase sign,
TPM2_Commit()

The default reset value is applied on each TPM Reset. This change condition is not listed in the “Changed By”
column.

Persistent NV Data

The data in this category is data that is always present in the TPM. This does not mean that the datacannot be changed, but that there is always a value associated with the location. The data can bechanged by a Protected Capability.
In the reference implementation, the persistent NV data is in the PERSISTENT_DATA structure. It
contents are listed in Table 34. While this table shows the context of the structure in the reference
implementation, it is only illustrative. An implementation may change the contents in order to satisfy therequirements of the implementation.
Page 230
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library
Table 34 — Contents of the PERSISTENT_DATA Structure

Parameter

Description

Changed By

disableClear

This value is CLEAR if TPM_RH_OWNER isallowed for authorization of TPM2_Clear().

TPM2_ClearControl(), TPM2_Clear()ownerAlg

the hash algorithm used for the ownerPolicy

TPM2_SetPrimaryPolicy(),
TPM2_Clear()ownerPolicy

the policy used if the authorization session is apolicy session and the authorized handle is
TPM_RH_OWNER

TPM2_SetPrimaryPolicy(),
TPM2_Clear()endorsementAlg

the hash algorithm used for the endorsementPolicy TPM2_SetPrimaryPolicy(),
TPM2_Clear()endorsementPolicy

the policy used if the authorization session is apolicy session and the authorized handle is
TPM_RH_ENDORSEMENT

TPM2_SetPrimaryPolicy(),
TPM2_Clear()ownerAuththe authorization value used if the authorization
handle is TPM_RH_OWNER and the authorization
is provided by password or an HMAC session

TPM2_HierarchyChangeAuth(),
TPM2_Clear()endorsementAuth

the authorization value used if the authorization
TPM2_HierarchyChangeAuth(),handle is TPM_RH_ENDORSEMENT and the
TPM2_Clear()authorization is provided by password or an HMAC
sessionlockoutAuth

the authorization value used if the authorization
TPM2_HierarchyChangeAuth(),handle is TPM_RH_LOCKOUT and the
TPM2_Clear()authorization is provided by password or an HMAC
sessionlockoutAlg

the hash algorithm used for the lockoutPolicy

TPM2_SetPrimaryPolicy(),
TPM2_Clear()lockoutPolicy

the policy used if the authorization session is apolicy session and the authorized handle is
TPM_RH_LOCKOUT

TPM2_SetPrimaryPolicy(),
TPM2_Clear()

epSeedthe seed value for the Endorsement Hierarchy

TPM2_ChangeEPS()

ehProofthe proof value for the Endorsement Hierarchy. It is TPM2_ChangeEPS()
used to tag tickets and saved object contexts for
TPM2_Clear()objects in the Endorsement Hierarchy.

spSeedthe seed value for the Storage Hierarchy

shProofthe proof value for the Storage Hierarchy. It is used TPM2_Clear()to tag tickets and saved object contexts for objects
in the Storage Hierarchy.

ppSeedthe seed value for the Platform Hierarchy

phProofthe proof value for the Platform Hierarchy. It is used TPM2_ChangePPS()
to tag tickets and saved object contexts for objects
in the Platform Hierarchy.

resetCounta counter that increments on each TPM Reset

TPM Reset,
TPM2_Clear()totalResetCounta value that increments on each TPM Reset. Thisvalue is used as resetValue in equation (52) to tag
saved contexts.

TPM Reset

pcrPolicies

This structure is used when a platform-specificspecification requires that update of certain PCR
requires policy authorization.

TPM2_PCR_SetAuthPolicy()

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

TPM2_Clear()

TPM2_ChangePPS()

Page 231
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Parameter

Description

Changed By

pcrAuthValues

This structure is used when a platform-specificspecification requires that update of certain PCR
requires HMAC or password authorization

TPM2_PCR_SetAuthValue()pcrAllocatedThis structure is used when a platform-specificspecification requires support for
TPM2_PCR_Allocate() to change the algorithms
used for PCR and the population of the PCR ineach bank.

TPM2_PCR_Allocate()

ppListIn the reference implementation, this is an array ofbits that is used to indicate the commands that
require assertion of Physical Presence when
TPM_RH_PLATFORM is used for authorization.

TPM2_PP_Commands()

failedTries

count of the number of authorization failures forobjects that are subject to Dictionary Attack
protection. This value can count down if noauthorization failures occur for lockoutRecovery
time.

TPM2_DictionaryAttackLockReset(),authorization failures,passage of time (recoveryTime)

maxTries

the maximum value for failedTries before the TPM
enters lockout

TPM2_DictionaryAttackParameters()

recoveryTime

the time that must pass before failedTries isdecremented

TPM2_DictionaryAttackParameters()

lockoutRecovery

the time that must pass after an authorization
failure using TPM_RH_LOCKOUT

TPM2_DictionaryAttackParameters()

lockoutAuthEnabled

when CLEAR, TPM_RH_LOCKOUT may not be
used for authorization

TPM_RH_LOCKOUT auth failure,
passage of time (lockoutRecovery)orderlyStatebetween a TPM2_Shutdown() and _TPM_Init, no
TPM command caused a change to the TPM’s
state to make the state in NV inconsistent with thestate in TPM RAM

many

auditCommandsin the reference implementation, a bit arrayindicating which commands are audited

TPM2_SetCommandCodeAuditStatus()

auditHashAlg

the hash algorithm used for the command audit

TPM2_SetCommandCodeAuditStatus()

auditCountera counter that increments on the first auditedcommand following a reset of the command audit
digest. The count is only incremented if thecommand completes with TPM_RC_SUCCESS.

audited commandalgorithmSet

this is a vendor-specific value that indicates thealgorithm set that is in use on the TPM. This value
may be used selectively to disable algorithms
implemented in the TPM.

TPM2_SetAlgorithmSet()

firmwareV1

the more significant 32-bits of the vendor-assigned, TPM2_FieldUpgradeStart(),firmware revision
TPM2_FieldUpdradeData()

firmwareV2

the less significant 32-bits of the vendor-assigned,
firmware revision

37.6

TPM2_FieldUpgradeStart(),
TPM2_FieldUpdradeData()

NV Rate Limiting

The TPM is allowed to limit the rate at which updates are made to NV memory. An update occurs whenan NV Index is defined or undefined, when an NV Index is modified, and when the persistence of anPage 232
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Libraryobject is changed with TPM2_EvictControl(). An NV modification is allowed for other commands in an
implementation dependent way. The rate for limiting the updates is TPM dependent.
When the TPM will prevent execution of a command because it is rate-limiting NV updates, the TPM will
return TPM_RC_NV_RATE. This code is in the group of warning return codes meaning that the command
might succeed if retried later.
NOTE 1

Checking to see if the NV is being rate limited is allowed to occur at any part of the commandexecution. This means that the TPM is permitted to return TPM_RC_NV_RATE before it has
validated all of the parameters of the command. As a consequence, when the command is retried
when the TPM is not rate limiting, it can fail due to incorrect parameters.

TPM2_GetCapability()withcapability=
TPM_CAP_PROPERTIES
andproperty=
TPM_PT_NV_WRITE_RECOVERY will provide an estimate of the number of milliseconds before the
TPM will be able to accept a command that will modify the TPM NV.
After TPM2_Shutdown(), any command is allowed to cause a change of th e TPM’s orderly shutdown
state and the TPM is permitted to return TPM_RC_NV_RATE in response to commands that are notnormally allowed to make modifications to the TPM NV state.

NOTE 237.7

NV Other Considerations
Power Interruption

A TPM is not required to maintain the integrity of the data in an NV Index if a power loss interrupts thewrite. After the interruption, the TPM should indicate that the Index no longer exists. The interruption of awrite to one Index is not allowed to affect the integrity of other Indices.
External NV
37.7.2.1

Introduction

An implementation is allowed to use an external device for storing non-volatile TPM data. This may
include all application defined NV (NV Indices and persistent objects) as well as all TPM state data. When
stored in an external device, the data is required to be encrypted, integrity checked, and rollback
protected using algorithms that have the highest security strength of any algorithm implemented on the
TPM.
The encryption keys used to encrypt the data in the NV shall be protected in a manner which is definedby the TPM profile which is being implemented. The level and manner of protection for these keys shallalso be specified and shall be at least as strong as the keys themselves. For a chip-based
implementation, the encryption keys used to encrypt the data stored in NV are not allowed to be exposed
outside of the TPM, even if encrypted.
The protection keys used to protect external NV data will be contained in or derived from a persistentvalue that does not leave the physical TPM. That persistent value must not be a global secret.
NOTE

37.7.2.2

In many implementations, it is expected that the persistent values will be stored in fuses.

Access Interruptions

When an external device is used for non-volatile storage, that device may not always be accessible to the
TPM command execution engine. When the memory is not accessible, operations that require update of
NV will return TPM_RC_NV_UNAVAILABLE.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 233
December 24, 2020

Trusted Platform Module Library
NOTEPart 1: Architecture

When updates to NV are being rate limited (but the NV is accessible), the TPM wil l return
TPM_RC_NV_RATE.

During the time when NV is not available for update, Clock should not advance and Safe should be NO
when accessed.
When NV is not available, the implementation may or may not advance Clock. If Clock is not being
advanced, the TPM will return TPM_RC_NV_UNAVAILABLE for commands that do comparisons to Clockor adjustments of Clock. These commands are:•

TPM2_PolicySigned() or TPM2_PolicySecret() with a non-zero expiration;•

TPM2_PolicyTicket(); and•TPM2_PolicyCounterTimer() if any part of TPMS_TIME_INFO.clockInfo.clock is used in theoperation.

When NV is not available, the implementation may or may not advance Time. If Time is not being
advanced, then TPM2_PolicyCounterTimer() will return TPM_RC_NV_UNAVAILABLE if any part of
TPMS_TIME_INFO.time is used in the operation.
PCR in NV
If a TPM implementation places PCR in NV space, it should also use a caching scheme to prevent NV
wearout.

Page 234
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryMulti-Tasking
An implementation of the TPM may use cycles of a host processor for execution. The operating systemon the host processor may not be able to operate properly if the TPM uses large blocks of time tocomplete execution of a command. In such systems, the TPM may be designed to yield after completionof a portion of the command so that the command may be resumed later.
When the TPM yields before completion of a command, it may return TPM_RC_YIELDED. This code
indicates that the exact command that the TPM was executing may be resubmitted later. If the next
command to the TPM is not the yielded command, the TPM may lose any state associated with thecommand that yielded so that when the yielded command is restarted, it may restart from the beginning.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 235
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Errors and Response Codes
39.1

Error Reporting

When a command fails, the TPM will return a 10-octet response that indicates the response code. No
auxiliary information is provided by an error other than what may be inferred from the context of the error.
39.2

TPM State After an Error

When the TPM returns an error that is related to command execution, the TPM is required to preserve the
TPM state. Except for the possible effect on the dictionary attack logic, it should be as though thecommand had not been received.
In some cases, an otherwise asynchronous operation may cause the TPM to create an error. For
example, if the TPM is doing self-test of functions on an as-needed basis, the TPM may return an error
due to failure of the self-test. The TPM should preserve the fact that it has failed the self-test but it should
not preserve any command-specific results.
When a command modifies NV RAM, the action of writing the NV may fail and it may not be recoverable.
If the TPM cannot recover from the NV write failure, then it should disable the NV so that the affected NV
locations cannot be accessed.
39.3

Resource Exhaustion Warnings
Introduction

The executable specification has been optimized for comprehension and correctness. In particular, thereference implementation has been designed to minimize the locations in the code where resource
exhaustion can occur, so that recovery from these situations is simplified. This is known not to achieve an
efficient use of limited RAM resources, and other implementations may choose methods that are moreaggressive in their use of memory. These implementations will invariably have error conditions that are
not covered in the normative clauses of the reference implementation. This clause describes the methods
that are recommended for reporting of these errors.
Allocated resources are classified by their persistence relative to a command’s execution. A transient
resource is one that can be moved to or from TPM memory using a context management command(TPM2_ContextLoad(), TPM2_ContextSave()). These resources may continue to occupy TPM memory
after completion of a command. A temporary resource is used in the processing of a command but isdisposed of before the command completes. The following two clauses describe the expected behavior of
the TPM when it is unable to create either of these resource types.
Transient Resources
The TPM reference implementation allocates space for a configuration-defined number of transient
resources of the maximum size supported by the configuration parameters. This allocation occurs during
the compilation process of the reference implementation. The maximum size of the objects is determinedby the structure definitions in TPM 2.0 Part 2. The reference implementation presumes that, if a resource
slot is available, then any object that might be stored in that slot will fit.
A practical consequence of this approach is that the only resource allocation failure for a transient
resource occurs when all the dedicated slots of the appropriate type (object, sequence object, or session)
are full. For objects, the number of available slots determines when the resources are all used. For
sessions, there are two slot resources: handles and session contexts.
Page 236
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

When the TPM is out of object slots, it returns TPM_RC_OBJECT_MEMORY. When out of session
context slots, it returns TPM_RC_SESSION_MEMORY. When the TPM is out of handle slots forsessions, the response code is TPM_RC_SESSION_HANDLES.
For a system using dynamic allocation of memory for transient resources, the TPM should return an error
response code that indicates the type of resource that needs to be removed from the TPM for thecommand to complete. If removal of either an object or a session from TPM memory would free memory
for the command, then the TPM may return TPM_RC_MEMORY. If removal of a specific resource isrequired,theTPMshouldreturnacodethat
indicatesthespecific
resource(TPM_RC_OBJECT_MEMORY or TPM_RC_SESSION_MEMORY).
Temporary Resources
The TPM reference implementation is designed so that temporary resources are allocated on theexecution stack. Static analysis of the code allows the maximum size of the stack to be determined sothat resource exhaustion for a temporary resource cannot occur.
This construction vastly simplifies the control flow of the normative command actions, since no additional
memory management code is required. However, other memory management schemes for temporary
resources are allowed. Error handling for these implementations is complex and beyond the scope of thisspecification. However, the TPM is required to follow the standard error reporting rules.
•

If the TPM returns an error, the state of the TPM is required to be restored to the state that existed
before the command execution began.

NOTE 1•One exception is state that would change even if a command were not executed, such as Clock,Time, dictionary attack lockout recovery, and related state. Another exception is state deliberatelychanged as a result of the error, such as the count of authorization failures and NV PIN Fail index
values.

The TPM will return TPM_RC_MEMORY if removal of one or more transient resources will allow
the command to complete.

NOTE 2•

If the TPM requires the removal of a specific type of resource, then it needs to return the specificresponse code (TPM_RC_SESSION_MEMORY or TPM_RC_OBJECT_MEMORY) rather than the
non-specific TPM_RC_MEMORY response.

If a session must be flushed before a new session can be created, the TPM will return
TPM_RC_SESSION_HANDLES.

The consequence of these requirements is that the TPM is required to be able to return the memory
allocation to the same state that existed before the command execution began. It is also required that nochange to NV memory be made before all temporary resources required for completion of the command
have been allocated.
39.4

Response Code Details

The response code from the TPM is a 32-bit value but the TPM only uses the low-order 12 bits tocommunicate its warnings or errors, leaving the remaining 20 bits for use by software.
The response codes are encoded so that certain errors can be associated with the component in which
the error occurred, and the specific element of the component. In cases where the error cannot be
associated with a specific parameter of the command, the response code will be sufficiently differentiatedto allow determination of the cause of the error.
EXAMPLE 1

If the second handle in the handle area was the wrong type for the command, the TPM would return
TPM_RC_VALUE + TPM_RC_H + TPM_RC_2.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 237
December 24, 2020

Trusted Platform Module Library
EXAMPLE 2

Part 1: Architecture

If the TPM can determine that the error was in the handle area but not the handle in error, the TPM
would return TPM_RC_VALUE + TPM_RC_H.

The design of the response codes was constrained so that the response codes returned for commands
defined in this specification would be different from the response codes defined by the previous version of
the specification, TPM 1.2. This constraint leads to a layout that satisfies the requirements but is not
intuitive.
An algorithm for evaluating the response code to determine the nature of the error and the command
handle, session, or parameter value in error is shown in the Figure 27 flow chart.

Bit

Bit

1
1

1
0

0
9

0
8

0
7

0
6

0
5

0
4

0
3

0
2

0
1

0
0

S

R

R

0

0

C

C

C

C

C

C

C

Bits 8:7 == 00b

1
1

1
0

0
9

0
8

0
7

0
6

0
5

0
4

0
3

0
2

0
1

0
0

N

S

V

R

1

0

C

C

C

C

C

C

C

Bit 7 ?

Y

TPM 1.2 Response
Code0

Bit 10 ?

1

Note:

Bit 11 ?

0

Bit

1
0

0
9

0
8

0
7

0
6

0
5

0
4

0
3

0
2

0
1

0
0

P

P

P

P

1

1 C

C

C

C

C

C

1
1

1
0

0
9

0
8

0
7

0
6

0
5

0
4

0
3

0
2

0
1

0
0

0 H H H 1

0

C

C

C

C

C

C

1
1

1
0

0
9

0
8

0
7

0
6

0
5

0
4

0
3

0
2

0
1

0
0

1

S

S

S

1

0

C

C

C

C

C

C

Bit 6 ?

Vendor DefinedCode1

Warning Code inBits[06:00]

0

Values in Bits[06:00] above have different
meanings from the values in Bits[05:00] below
even if the numeric values are the same.

1
1

1

Error Code inBits[06:00]

1

Error Code in Bits[05:00]
Parameter Number in Bits[11:08]

0

Error Code in Bits[05:00]
Handle Number in Bits[10:08]

0Bit

Bit 11 ?

1

Bit

Error Code in Bits[05:00]
Session Number in Bits[10:08]

Figure 27 — Response Code Evaluation

Page 238
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

General Purpose I/O
A TPM may have one or more I/O pins that inputs or outputs a logic state. TPM2_NV_Read and
TPM2_NV_Write may be used to access the value of GPIO using normal access controls.
A platform-specific specification defines the mapping of NV Indices to individual General Purpose I/O(GPIO). Whether the TPM reserves any NV storage for the indicated GPIO is platform specific.
This specification does not require the NV Indices associated with GPIO pins to be pre-allocated. Whenone of the Indices reserved for GPIO pins is defined, it is automatically associated with the corresponding
GPIO pin.
NOTE 1The owner and platform space are segregated and it is expected that the GPIO pins will be assigned
to Index values in the Index space reserved for the platform.

NOTE 2The TCG maintains a registry of reserved NV Index values.

The controls that let the GPIO pin be used either as an input or an output are vendor or platform specific.
For outputs, if the Index has the TPMA_NV_ORDERLY attribute SET, the output state is volatile, andbecomes non-volatile on an orderly shutdown. If the TPMA_NV_ORDERLY attribute is CLEAR, theoutput state is non-volatile.
For inputs, a read of the Index returns TPMI_YES_NO, where YES indicates a logic 1 and NO indicates alogic 0 on the input pin.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 239
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Minimums
41.1

Introduction

This clause lists the minimums for specific functional blocks where a minimum is needed to ensure proper
TPM operation.
Platform-specific TPM specifications may impose other minimums but those minimums are not allowed tobe less than the minimums in this specification.
41.2

Authorization Sessions

An active authorization session is a session that is currently loaded into TPM memory and can beaddressed with a session handle in a command. A concurrent session is an authorization session thateither is loaded on the TPM or has its context saved.
A command may require no more than three sessions divided according to the needs of the command.
The TPM is required to be able to support execution of a command with three authorization sessions.
The management of sessions is different from the management of objects. Management software cankeep the contexts for an indefinite number of objects and load them as required. The number ofconcurrent sessions, however, is limited by the resources that the TPM can devote to tracking thosesessions.
The TPM should support a minimum of 64 concurrent sessions. Fewer sessions would impair the ability of
the TPM to conduct concurrent operations with multiple users.
41.3

Transient Objects

In order to be able to execute all commands, the TPM needs to have two active, loaded objects of any
type. A Transient Object is an object that occupies TPM memory and may be referenced by handle. The
number of Transient Objects that the TPM supports does not include those objects that have been placedin persistent TPM memory.
NOTE

41.4

A TPM implementation is permitted to copy an object from persistent storage into a Transient Object
slot in order to speed up access to the object data.

NV Counters and Bit Fields

All TPM implementations should allow at least one NV Index to be allocated for use as a monotonic
counter (TPMA_NV_COUNTER) or bit field (TPMA_NV_BITS). The number of these Index types
determines how many different policies may include revocation as part of their logic. When the number ofthese Index types is too small, the software complexity of handling revocation becomes too complex tomanage.
NOTE 1This minimum (1) may be adequate for a TPM in a simple embedded system but is too low for a TP M
in a complex system such as a PC. It is recommended that platform-specific specifications for more
complex systems mandate support for at least sixteen (16) counter or bit field Indices.

NOTE 2

The requirement that a TPM support the TPMA_NV_COUNTER or TP MA_NV_BITS attribute implies
that the TPM is required to implement either TPM2_NV_Increment() or TPM2_NV_SetBits().

Page 240
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Attached Components
42.1 Introduction
PurposeThe TPM has an extensive set of commands that allow implementation of flexible access control for
objects contained in the Shielded Locations of the TPM. The pair of commands TPM2_AC_Send() andTPM2_Policy_AC_SendSelect() enable the access control mechanisms of a TPM to be used to manage
sensitive data (such as keys) for other components (called the Attached Components) that are attachedto the TPM.
Examples of Attached Components are encrypting disk controllers, crypto accelerators, and network
adapters with crypto capabilities.
Concept
An Attached Component (AC) is physically connected to a TPM through a data channel other than the
TPM’s command and response buffer (the details of the TPM-to-AC data channel are beyond the scopeof this document). A properly authorized TPM2_AC_Send() will cause the TPM to copy the selected TPM
Object to a selected AC over the provided data channel. This avoids having to “bounce” the Object via an
out of band transfer from the TPM through memory then to the component. Object data is, therefore,
duplicated outside the TPM’s “Shielded Location”. The platform manufacturer provisions the connection
between the TPM and the Attached Component, and hence determines the protection of an object intransit from the TPM to the Attached Component.
TPM2_AC_Send() uses the DUP auth role that requires authorization with a policy with
policySesssion→commandCode set to TPM_CC_AC_Send.
NOTE

TPM2_AC_Send() will
TPM2_AC_Send().

only

send

objects

thatareconstructed

with

a

policythat

allows42.2 TPM2_AC_Send()
TPM2_AC_Send() instructs the TPM to copy portions (possibly all) of the Object referenced by
sendObject to the Attached Component referenced by ac. The methods used to send the Object and theproperties of the Attached Component are outside the scope of this specification. The command does notcause the referenced object to be flushed.
The applications using this TPM and the creators of the TPM’s objects are expected to understand theproperties of the Attached Component and the connection between the TPM and the Attached
Component.
The use of Enhanced Authorization allows the object creator to restrict sending the object using any
combination of Policies. For example, the policy may only allow an Object to be sent when PCR and
Locality have specific values. TPM2_AC_Send() requires DUP role authorization for the sendObject. Thismeans that sendObject authorization requires a policy session that has policySession→commandCodeset to TPM_CC_AC_Send. This requirement ensures that TPM2_AC_Send() is only used on Objects thatare intended to be sent to an Attached Component.
The acDataIn parameter allows TPM2_AC_Send() to send qualifying data to an Attached Component
along with the Object. For example, acDataIn may be used to identify a key slot in the AC into which the
Object is to be loaded.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 241
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

An Attached Component optionally returns acDataOut information to the caller. A possible use of
acDataOut would be for the AC to indicate the key slot into which it has placed the Object.
After TPM2_AC_Send() completes, the Object in the TPM may be flushed without effecting the values in
the AC. Similarly, the AC may modify (or delete) the Object data from its memory without affecting any
Object in TPM Shielded Locations.
42.3 Send Object Types
The TPM does not restrict the type of Object that may be sent to an AC. However, an AC may not be able
to process all types of TPM Objects. The AC may be designed to reject unknown Object types or it may
be the responsibility of system software to ensure that only the proper Object types be sent to an AC.
42.4 Send Object Attributes
The sendObject shall have fixedTPM, fixedParent and encryptedDuplication CLEAR.
42.5 Attached Component Authorization
TPM2_AC_Send() requires authorization for the Object to be sent and for the AC that is the target of thesend operation.
EXAMPLE

If an Attached Component is an encrypting disk controller, unauthorized software, such as
ransomware, cannot set the encryption key without getting access to the proper authorization. Useof the PCR as part of the policy for the object can ensure that the disk encryption key can only be
set early in the boot phase.

Proper authorization to send to an AC is determined by the presence of an aliased NV Index. The rangeof AC handles is AC_FIRST to AC_LAST. The range for aliased AC Indexes is NV_AC_FIRST to
NV_AC_LAST. If the Owner or Platform creates an NV Index in the range AC Indexes and acorresponding AC exists in the AC handle range, then the write authorization settings of the AC Index(TPMA_NV_PPWRITE,
TPMA_NV_OWNERWRITE,
TPMA_NV_AUTHWRITE,
and
TPMA_NV_POLICYWRITE) determine how the send may be authorized. If no aliased AC Index exists,then either Owner Authorization or Platform Authorization may be used to allow the send to the AC.
The Platform and Owner may use TPM2_NV_DefineSpace() to delegate the rights to access a specificAC
The Platform or Owner may change the access rights to the AC by calling
TPM2_NV_UndefineSpace() and then TPM2_NV_DefineSpace() with new parameters.
TPM2_NV_ChangeAuth() allows the current key and object manager to change the authValue by using
the current AC authorization policy.
The following is a summary of states and allowed actions:
Attached Component has no aliased NV Index defined
Can use TPM2_AC_Send() to send objects to the Attached Component with ownerAuth orplatformAuth
Can use TPM2_AC_GetCapability() to get optional information about the AC
Attached Component has an aliased NV Index
Can use TPM2_AC_Send() to send objects to the Attached Component with the write
authorization types allowed by the aliased Index.
Can change authorization using ADMIN role (TPM2_NV_ChangeAuth()).

Page 242
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

TPM2_Clear will delete any AC Index alias defined by the Owner but not by the Platform.
42.6 Attached Component Object Management
Discovery
Applications may use information from the platform manufacturer (for example, a platform certificate) to
determine whether a platform has an Attached Component. Software may also discover the number ofattached components by calling TPM2_GetCapability(TPM_CAP_HANDLES) with a TPM_HT_AC
Property Type to find available AC handles.
Specific information about each Attached Component may be provided by calling the
TPM2_AC_GetCapability() command. In response to this command, the TPM returns vendor-specificinformation about a specific Attached Component. For example, capabilitiesData may be used to return apairing value that can be also obtained from the AC itself by an AC-specific API (see Part 2, Attached
Component Structures).
The association between ACs and AC handle is vendor specific, but the association is required to beconstant during the platform’s lifetime. If an AC is replaced, the new AC should have the same AC handle
as the AC that was replaced.
After reboot or other TPM power state changes, TPM2_GetCapability() should be used to obtain the list of
the available ACs.
NOTE 1

It is suggested that no handle be associated with a defective AC. However, it is also all owed that adefective AC be reported using TPM2_AC_GetCapability().

TPM2_GetCapability() can be used at any time to determine the current AC configuration.
NOTE 2

There is no mechanism for the TPM to proactively signal the change in state of an AC. However , aplatform can have a method for the AC to signal software and for that indication to trigger anenumeration process.

Setup
The AC’s configuration should be performed by the AC’s Manufacturer. AC configuration is out of scopeof the TCG.
Sending
If the desired Object is not already loaded, the application (such as a key manager) may load it using an
existing TPM2 command such as TPM2_Load(). This removes the wrapping of the object and returns an
object handle. However, if an object is evicted and then re-loaded, there is no assurance the TPM willassign the object the same object handle. For this reason, applications should not associate the TPM’s
assigned object handle with the object when sent to the Attached Component, or when the object is within
the Attached Component’s domain. Key and object managers using the TPM2_AC_Send() command
may assign, if necessary, a handle for the transferred object within the Attached Component domainusing the acDataIn parameter. Therefore, in common usages there is no association between the TPM
generated object handle assigned to the object and any handle for that object within the Attached
Component’s domain. Any association between the TPM’s object and the Attached Component’s object isdone by the application or the application’s resource and object manager external to the TPM.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 243
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

42.7 Power States
The AC authorization values and policies that are setup by TPM2_NV_DefineSpace() are persistentacross all TPM power state changes, like the authorization values and policies of other NV Indexes.
TPM power state changes have no effect on the Attached Component’s copy of objects, because thatcopy of the object is no longer in the TPM’s “Shielded Location”.
42.8 Attached Component Format
The format and security properties of the connection between the TPM and the Attached Component areoutside the scope of the TPM Library Specification. A vendor may provide a proprietary connection
between the TPM and an Attached Component where the format and the security properties are definedby that vendor. A TCG platform-specific Working Group may define a data format that may include a key
exchange method so that independently manufactured Attached Components can interoperate withdifferent TPMs.

Page 244
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Authenticated Countdown Timer (ACT)43.1 Introduction
The functionality and commands described in this clause enable the TPM to manage multiple
authenticated countdown timers (ACT).
43.2 Description
An ACT is a 32-bit counter that, when not already zero, will decrement by one each second that the TPM
is powered.
The countdown timers are used to trigger events on a platform when they count down to zero, at which
point they are said to timeout or expire. TPM2_ACT_SetTimeout() is used to set an ACT to a non-zerovalue and begin the timeout. On TPM Reset or TPM Restart, all ACT timeouts are set to zero with no side
effects (no event triggered). ACT timeouts are preserved across TPM Resume.
The ACT timeouts are saved by TPM2_Shutdown(STATE). On TPM2_Startup(STATE), if the TPM
shutdown was orderly, the saved ACT values are restored and the ACT resumes counting. If an ACT
startTimeout has been written (TPM2_ACT_SetTimeout()) since the last TPM2_Startup(), then the current
timeout of the ACT is saved by TPM2_Shutdown(STATE); otherwise, the saved value is one half of thecurrent ACT timeout. If a TPM2_ACT_SetTimeout() occurs after the TPM2_Shutdown(), then the TPM
state is no longer orderly, and a subsequent TPM2_Startup(STATE) will fail.
An ACT has an authValue and an authPolicy. The authValue is the same as the current platformAuth andcan only be used if phEnable is SET. The authPolicy is ACT-specific and is neither enabled nor disabledby phEnable. Each ACT has its own authPolicy.
NOTE 1A system could continue to operate after a TPM2_Shutdown(STATE). Therefore, saving half thetimeout
prevents
anattackerfromcontinuallyextendingthetimeoutby
doing
TPM2_Shutdown(STATE) immediately after TPM2_Startup(STATE), and then restarting the system(TPM Resume) just before the timer expires.

TPM2_ACT_SetTimeout() must be properly authorized. Authorization may be provided either by
platformAuth or by an ACT-specific authPolicy. The startTimeout parameter in TPM2_ACT_SetTimeout()
is an integer number of seconds.
The authPolicy for an ACT can be changed by TPM2_SetPrimaryPolicy() using either platformAuth or the
ACT-specific authPolicy.
The authPolicy of an ACT is initialized to an Empty Policy by TPM Reset or TPM Restart but is preserved
during TPM Resume.
NOTE 2After TPM Reset or TPM Restart, phEnable is SET, allowing the platform to initialize any ACT
authPolicy.

43.3 Typical Use
A typical example for the use of an ACT is as a watchdog timer that will cause a platform reset when thetimer reaches zero (expires). In a system using an ACT, a periodic platform action outside the TPM
indicates that the timeout should be set anew using TPM2_ACT_SetTimeout(). The most common reason
why timeout is not set anew is that the local system is not behaving properly because of some type of
corruption (either inadvertent or malicious). The intent of the timer is that, in the absence of a properly
authorized timeout extension, the platform would be reset, putting it back into a known state with the

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 245
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

expectation that the corruption can be removed. The reason for having an authenticated timeout is toallow an external entity to make a decision about the health of the system.
The example above is not the only one supported by an ACT. In fact, this specification does not mandatethat any specific platform behavior occur as a result of a timer expiring. The action on timer expiration
may be chosen by a platform-specific specification or be vendor specific.
Because platformAuth may be used to change the authPolicy or set a startTimeout for any ACT, theplatform firmware has ultimate control of the ACT. On each TPM Reset or TPM Restart, the platform
firmware is expected to set the authPolicy for all ACT using platformAuth. This specification mandates no
specific policy for any ACT, but it is expected that, in most cases, the platform firmware will either:
Initialize an ACT authPolicy with a policy that can only be satisfied by an entity trusted by the platform
manufacturer; orInitialize the ACT authPolicy so that the authPolicy can be changed using ownerAuth.
In case a), the platform firmware may set an initial timeout to ensure that some corrective action will occur
if malware prevents the trusted entity from setting the ACT.
NOTE 1This is how the platform would typically initialize a watchdog timer

In case b), the system software is expected to take control of the ACT. The platform would not set an
initial timeout as it is possible that the ACT will not be used by the system software.
NOTE 2

If the platform firmware does not initialize the ACT authPolicy before phEnable CLEAR, then the
ACT cannot be used.

43.4 Failure Mode
If the TPM enters failure mode, the ACT should continue to count down and trigger the specified event
should it expire.
NOTE 1

If the failure mode was caused by a timer failure or affects functionality that is required for theplatform-specific event, the ACT might not trigger reliably.

TPM2_ACT_SetTimeout() shall not be usable while a TPM is in Failure Mode. This means that the
timeout cannot be extended and that timed events will occur if the TPM is not powered down or Resetbefore the ACT expires. A platform-specific specification may specify that an event will have no effect if
the TPM is in Failure Mode.
A TPM may allow reading of the remaining ACT time (TPM2_GetCapability(capability = TPM_CAP_ACT)
when the TPM is in Failure Mode.
43.5 Field Upgrade
The behaviour of a TPM during Field Upgrade is undefined. However, it is preferred that ACT continue tooperate normally during Field Upgrade except that the ACT may not be changed by
TPM2_ACT_SetTimeout().
NOTE

Since platformAuth is required to start a Field Upgrade, platformAuth can be used to set thestartTimeout for any active ACT to a value that is sufficient to allow a Field Upgrade to complete.

Page 246
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

43.6 Typical ACT authPolicy
This clause describes a typical ACT authorization policy that authorizes setting of startTimeout with anauthentication credential (key). The signature created by the authentication key is used as a
cryptographically protected deferral ticket for the ACT.
The ACT authPolicy is constructed using TPM2_PolicySigned() and may include other policy
components. Authorization by multiple entities can be achieved by combining multiple
TPM2_PolicySigned() commands using AND or OR terms.
The deferral ticket is provided to the TPM in TPM2_PolicySigned() as the auth parameter (the signed
authorization). The signature verification key, the authObject in TPM2_PolicySigned(), may be asymmetric or asymmetric key.
NOTE

The advantage of an asymmetric signing key is that only the public key needs to be provisioned into
the TPM. In the case of a symmetric HMAC key, it is recommended that the HMAC key’s authPolicy
restrict the key to be used only for TPM2_PolicySigned() and not for other commands like
TPM2_HMAC(), so that the TPM cannot to issue its own deferral tickets).

For the nonceTPM and expiration parameters of TPM2_PolicySigned(), the following is recommended:
nonceTPM present and not an Empty Buffer
expiration > 0
Both settings ensure that a deferral ticket is single-use. The presence of nonceTPM in
TPM2_PolicySigned() prevents the same signature being used multiple times within a policy session todefer the ACT indefinitely.
NOTE

The nonceTPM for the policy session changes at the end of TPM2_ACT_SetTimeout(). This
invalidates the previous signature and prevents replay of TPM2_ACT_SetTimeout() without getting a
new signature from the authorized entity.

The non-negative expiration prevents TPM2_PolicySigned() creating a policy ticket which may be reusedwith TPM2_PolicyTicket() over a period of time to defer the ACT.
The ability to change startTimeout of TPM2_ACT_SetTimeout() should be limited by including cpHash in
the ACT authPolicy. This can be achieved in two ways:
1) The ACT authorization policy includes TPM2_PolicyCpHash(). In this case, the entity setting the policy
determines the startTimeout value.
2) The ACT authorization policy includes TPM2_PolicySigned() with cpHashA set. In this case, the signer(of the deferral tickets) determines the startTimeout value.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 247
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Annex A
(informative)
Policy Examples
A.1

Introduction

This clause compares authorization between TPM 1.2 and this specification.
A.2

TPM 1.2 Compatible Authorization

A TPM 1.2 key may have its use gated by PCR and authValue. To select this authorization, the key would
be created with a pcrSelection with at least one bit SET and the digestAtRelease set to indicate the digestof the selected PCR. Additionally, the key’s TPM_AUTH_DATA_USAGE would be set to
TPM_AUTH_ALWAYS. To perform the authorization, an authorization session is created and used toprove knowledge of the authValue in the authorization HMAC. If the HMAC check is successful and thedigest of the selected PCR matches the digestAtRelease, the action is approved.
For a TPM compatible with this specification, use of PCR for access control requires a policy. The policy
should be created at the time of object creation so that the policy requires selected PCR to have a
specific value. This is similar to determining the digestAtRelease in TPM 1.2. The policy will use two
factors: PCR and an authValue. The first policy command will be TPM2_PolicyPCR() and it will modify thepolicyDigest by:policyDigest1 ≔ HcontextAlg (policyDigest0 || TPM_CC_Policy_PCR || PCR Selection || PCR digest) (58)
where

H contextAlg

hash function using the context hash algorithm

policyDigest0

an array of octets of zero equal in length to the size of the policy digest

TPM_CC_Policy_PCR a constant indicating the command modifying the policyDigest

PCR Selectiona TPML_PCR_SELECTION that indicates the PCR that will be includedin the PCR digest

PCR digest

the expected digest of the PCR selected by the PCR Selection; the PCR
are hashed using the hash algorithm of the policy session

To cause the TPM to compute an HMAC using the authValue of the object, a TPM2_PolicyAuthValue()
would be included in the policy. It would modify the policyDigest as:policyDigest2 ≔ HcontextAlg (policyDigest1 || TPM_CC_PolicyAuthValue)

(59)

where

H contextAlg

hash function using the context hash algorithm

policyDigest1

the result of performing the operation in equation (58) above

TPM_CC_PolicyAuthValuethe command code for TPM2_PolicyAuthValue()

The value of policyDigest2 would be included in the template of the object in the authPolicy parameter.
To use the object, a policy authorization session would be started using TPM2_StartAuthSession(). Thena TPM2_PolicyPCR() and TPM2_PolicyAuthSession() would be executed using the handle of theauthorization session. If the PCR were the same as those used when performing the operation ofPage 248
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Libraryequation (58), then the policyDigest of the policy session will match the authPolicy of the object. Because
the policy sequence contained TPM2_PolicyAuthValue(), the TPM will check that the HMAC in theauthorization indicates that the caller knows the authValue of the object (same computation as performedon an HMAC session). If both checks succeed, the object is properly authorized.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 249
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Annex B
(normative/informative)
RSA
B.1

Introduction

The RSA asymmetric algorithm is used for digital signatures, secret sharing, and encryption.
A TPM that supports RSA should support a public modulus size of at least 2,048 bits. Support for otherkey sizes is permitted.
NOTE 1

The reference implementation supports key sizes of 1024, 2048, and 3072.

When the size (k) of the public modulus (n) of an RSA key is given, then log2n = (k – 1). Additionally, fora two-prime system, the primes (p and q) satisfy log2(p2) = (k – 1) and log2(q2) = (k – 1).
The RSA algorithm requires the methods of encryption and signing defined in IETF RFC 8017. This
includes support for RSAES-OAEP, RSAES-PKCS1-v1.5, RSASSA-PKCS1-v1.5, and RSASSA-PSS.
The RSA structures in this specification support only public keys that are the product of two primes.
Support for other numbers of primes is allowed, but it is performed in a vendor-specific manner and thus
beyond the scope of this specification.
A TPM is required only to support a public exponent (e) of 216+1. Support for other exponents is allowed
but discouraged.
NOTE 2

The reference implementation does not support an exponent size smaller than 7 nor does it allow
keys to be created on the TPM with a public exponent less than 2 16 + 1.

When loading an RSA key, the TPM validates that its public and private portions are properly paired by
dividing the public modulus by the single private prime and requiring that the remainder be zero. The TPM
does not validate whether input values are primes.
NOTE 3

Validating the pairing of the public and private key portions need not be performed when the key is
being loaded. However, this check is performed before the authorization value of the key or theprivate portion of the asymmetric key may be used.

The TPM will also validate that the provided and computed prime factors are in an acceptable range. To
be acceptable, the square of the prime is required to have the same number of significant bits as the
public modulus.

Page 250
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
B.2

Trusted Platform Module Library

RSAEP

This is the RSA public key primitive defined in IETF RFC 8017, clause 5.1.1. It is a modular
exponentiation of a message (m) with the public exponent (e), modulo the public modulus (n) to produce
the cipher text (c). This is expressed as:c ≔ me (mod n)

(60)

where

B.3

c

the encrypted message

ma value 0 < m < n to be encryptedethe public exponent (default is 216 + 1)n

the public modulus

RSADP

This is the RSA private key primitive defined in PSCS#1v2.1, clause 5.1.2. This clause describes theprivate key in two forms: as a pair and as a quintuple. The reference implementation uses the pair form
with a private exponent (d). Using this form, the RSADP operation recovers a message from a cipher textby:m ≔ cd (mod n)
NOTE

B.4

(61)

The reference implementation also supports use of the CRT form of the private exponent.

RSAES_OAEPThis encryption scheme is defined in IETF RFC 8017. It is the only scheme used with an RSA-restricteddecryption key. The algorithm identifier for this scheme is TPM_ALG_OAEP.
For RSA keys protecting a secret value (such as, an encryption key or a session secret), the L parameteris a byte stream, the last byte of which must be zero, indicating the intended use of the encrypted value.
A command that accepts or creates an RSA-encrypted secret indicates the value of the string to use for
L. The RSA key's scheme hash algorithm (or, if it is TPM_ALG_NULL, the RSA key’s Name algorithm) isused to compute lhash := H(L), and the null termination octet is included in the digest.
MGF1 (as defined in IEEE Std 1363TM-2000) computes dbMask and seedMask. The mask-generation
function uses the Name algorithm of the RSA key as the hash algorithm.
B.5

RSAES_PKCSV1_5

This encryption scheme is defined in IETF RFC 8017. It has no parameters. The algorithm identifier forthis scheme is TPM_ALG_RSAES.
B.6

RSASSA_PKCS1v1_5

This signing scheme is defined in IETF RFC 8017. The algorithm identifier for this scheme is
TPM_ALG_RSASSA.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 251
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

An RSA-restricted signing key may use either this algorithm or RSASSA_PSS, but not both. An
unrestricted signing key may select as its default either this algorithm or RSASSA_PSS. If
TPM_ALG_NULL is selected, the caller will indicate the scheme in the signing command.
This signature scheme prepends an OID to a digest before signing with the private key. It may be used inany command that allows an asymmetric signing operation.
For signing commands that use restricted signing keys, the TPM provides the OID that corresponds to thedigest algorithm, and the OID provided by the caller is discarded.
For commands that use unrestricted signing keys, the TPM uses the caller-provided OID.
NOTE 1

If the command does not provide a parameter for the OID, then the TPM provides the OID even if
the key is not restricted.

For hash algorithms where the TCG defines a TPM_ALG_ID, the TCG provides the OID to use withrestricted signing keys. Currently, the defined values are:•

SHA1
30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 1416•

SHA25630 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 2016•

SHA38430 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00 04 3016•

SHA51230 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 4016

NOTE 2

These values are from IETF RFC 8017.

NOTE 3The listing above is not normative. TCG maintains the normative list.

B.7

RSASSA_PSS

This signing scheme is defined in IETF RFC 8017. The algorithm identifier for this scheme is
TPM_ALG_RSAPSS.
A restricted signing key may use either this algorithm or RSASSA_PKCS1v15, but not both. An
unrestricted signing key may use either this algorithm, RSASSA_PKCS1v15, or TPM_ALG_NULL. If
TPM_ALG_NULL is selected, the caller can indicate the signing scheme in the signing command.
When used with a restricted signing key, the hash algorithms for messages (M) and M’ are the same.
When used with an unrestricted signing key, the hash algorithm for M and M’ can differ.
For both restricted and unrestricted signing keys, the random salt length is the largest size allowed by
FIPS 186-4.
NOTE

Older TPMs may use the largest size allowed by the key size and message digest size.

Page 252
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

B.8

RSA Key Generation

B.8.1

Background

The implementation of the RSA key-generation function should meet the requirements of the intended
market. The methods in FIPS 186-3 are recommended.
In the reference implementation, the primes used for the key are generated using the methods of FIPS
186-3, B.3.3 "Generation of Random Primes that are Probably Prime."
NOTE

B.8.2

FIPS 186-3 only allows this method to be used for primes of 1024 bits or larger. For smaller primes,
the methods described in clause B.3.5 "Generation of Probable Primes with Conditions Based on
Auxiliary Provable Primes" or clause B.3.6 "Generation of Probable Primes with Conditions Basedon Auxiliary Probable Primes" can be used if FIPS compliance is required.

Large Prime Generation

For generating a prime the reference implementation has two different implementations: one using testingof candidates and the other using a number sieve. The process for testing of candidates is described inclause B.8.2.
The inputs are:•primeSize – this is the number of bits in the prime to be generated. It should be half the number ofbits in the public modulus to be generated•e – the public exponent
NOTE 1•In the reference implementation, the exponent is required to be a prime number > 2 16

a random number generation function according to the type of key being generated (see 27.6.2 and27.6.3)
NOTE 2Derivation of RSA keys is not supported.

The prime generation process is:set prime candidate p to the next primeSize number of bits from the provided random number
generation function
adjust p so that the high-order two bits and the low order bit are one
NOTE 3In the reference implementation, when a prime is generated, the upper two octets for prime
candidates are verified to be B5 05 16 or greater. This forces the prime to be greater than
0.7071075439453125 * 2 (n/2) where n is the number of bits in the public modulus. This isslightly larger than the required value of √2/2 * 2 (n/2) . This value ensures that the MSb of the
product of these to prime will be SET. Setting of the two most significant bits would also ensurethat the magnitude of the product is large enough but re duced the range of allowed primes bysmall factor (about 4.3%).

test p to determine if it is probably prime
Using a greatest common divisor (GCD()) function, see if p shares any common factors with acomposite number that is the product of the first 1024 primes and if so, go to a).
do N rounds of Miller-Rabin where N is determined by the size of the prime and if the test fails on
any round, go to a)
NOTE 4The value for N are found in FIPS 186-3, Table C.2.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 253
December 24, 2020

Trusted Platform Module Library
NOTE 5

Part 1: Architecture

The witness values used by Miller-Rabin are from the same random number function used
to generate the prime candidate.

return p
B.8.3

RSA Key Generation Algorithm

The key generation process is:
initialize the values of the algorithm
Set securityStrength according to the size of the public modulus of the key to be generated as
specified in SP800-57 part 1.

primeSize ≔ 1/2 the size of the RSA modulus (inPublic.parameters.keyBits of the template)find a first prime (p) using the method in B.8.2
find a second prime (q) using the method in B.8.2:
If |p – q| < 2100, go to b)
compute the public modulus n ≔ p • q
NOTE 1

Depending on the starting values, the algorithm could take many iterations to find two suitableprimes.

compute the private exponent d ≔ e-1 (mod (p – 1)(q – 1))
NOTE 2

The reference implementation also provides an option to use the CRT form of the private exponentd.

if d < 2nLen/2 where nLen is the number of bits in the public modulus (n), then go to step b)
NOTE 3

If required, a random value is encrypted with the public exponent and decrypted with the private
exponent to validate that the key can be used for signing and signature verification.

return n, p and d
B.9

RSA Cryptographic Primitives

B.9.1

Introduction

When RSA is implemented on a TPM, it may provide these additional commands to support cryptographic
operations. The command description in TPM 2.0 Part 3 indicates the restrictions on the types of keys
that may be used with each of the commands.
B.9.2

TPM2_RSA_Encrypt()

TPM2_RSA_Encrypt() may be used to perform encryption according to the methods described in IETF
RFC 8017. If the scheme of the key is TPM_ALG_NULL, then the encryption scheme may be specified in
the command. Otherwise, the scheme specified in the key will be used. The scheme options are:•

TPM_ALG_NULL – selects RSAEP as described in clause B.2•

TPM_ALG_OAEP – selects RSAES_OAEP as described in clause B.4•

TPM_ALG_RSAES – selects RSAES_PKCSV1_5 as described in clause B.5

Page 254
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
B.9.3

Trusted Platform Module Library

TPM2_RSA_Decrypt()

TPM2_RSA_Decrypt() performs the decryption operations defined in IETF RFC 8017, clause 7.1.2. The
handle used in this command is required to have the decrypt attribute SET. If the scheme of the key is
TPM_ALG_NULL, then the encryption scheme may be specified in the command. Otherwise, the scheme
specified in the key will be used. The scheme options are:•

TPM_ALG_NULL – selects RSADP as described in clause B.3•

TPM_ALG_OAEP – selects RSAES_OAEP as described in clause B.4•

TPM_ALG_RSAES – selects RSAES_PKCSV1_5 as described in clause B.5

B.10 Secret Sharing
B.10.1

Overview

When data is to be delivered securely to the TPM a secret sharing mechanism is required. There arethree cases when RSA is used for secret sharing:1) injecting a salt value for an authorization session,2) exchanging protection values for object duplication, and3) exchanging protection values for identity credentials.
For each of these uses, a secret value is OAEP encrypted as described in clause B.4.
The size of the secret value is limited to the size of the digest produced by the scheme hash algorithm (ornameAlg if the scheme hash algorithm is TPM_ALG_NULL) of the object that is associated with the public
key used for OAEP encryption.
B.10.2RSA Encryption of Salt

In TPM2_StartAuthSession(), when tpmKey is an RSA key, the secret value (salt) is encrypted using
OAEP as described in clause B.4. The string “SECRET” (see clause 4.5) is used as the L. The data value
in OAEP-encrypted blob (salt) is used to compute sessionKey.
B.10.3

RSA Secret Sharing for Duplication

When the new parent for a duplicated object is an RSA key, a random seed value is created and used in
the KDF operations to generate a symmetric encryption key and IV according to equation (33) and an
HMAC key according to equation (35). The seed value will be OAEP encrypted to the public key of the
new parent as described in clause B.4 using “DUPLICATE” as the L parameter. The seed size will be thesize of a digest produced by the OAEP hash algorithm of the new parent.
On TPM2_Import() the private key of the new parent is used to decrypt the key protector containing theseed value. If the label value in the OAEP encrypted blob is not “DUPLICATE”, then the decryption
routine should generate an error. The error should cause the seed value to be set to an invalid value sothat the error will not be reported until the integrity HMAC is validated.
NOTE

This is to ensure consistency in behavior with ECC and to minimize the information available to an
attacker.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 255
December 24, 2020

Trusted Platform Module Library
B.10.4

Part 1: Architecture

RSA Secret Sharing for Credentials

When a credential is protected (such as TPM2_MakeCredential() and TPM2_ActivateCredential()), a
random seed value is created and used as described in clause B.10.3. The only difference is that thelabel value used for the KDF will be “IDENTITY” instead of “DUPLICATE”

Page 256
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Annex C
(normative/informative)
ECC
C.1

Introduction

The ECC algorithm is used for digital signatures and for secret sharing.
NOTE 1

As implemented in a TPM, ECC is not used directly for encryption of data. Rather, ECDH secretsharing is used to establish a symmetric key, and then a symmetric algorithm is used for the actual
data encryption.

A TPM should support prime modulus ECC.
If the ECC algorithm is supported, the TPM is required to support ECDSA and ECDH (SP800-56A,
Clause 6.2.2.2 “One-Pass Diffie-Hellman, C(1, 1, ECC CDH)”).
The TPM should support ECC key sizes of at least 256 bits. Support for other key sizes is allowed.
NOTE 2

It is anticipated that the recommended ECC key size will increase over time in revisions to thisspecification.

The TPM does not check the security of ECC curve parameters. It does check that the public and private
keys are properly paired.
Validating the pairing of the key’s public and private portions need not be performed when the key is
being loaded. However, this check is required to be performed before the authorization value of the
key or the private portion of the asymmetric key may be used.

NOTE 3

C.2

Split Operations

C.2.1

Introduction

Several of the EC schemes us two-phase protocols in which the TPM generates an ephemeral key pair in
the first phase and uses that ephemeral key in the second phase. These protocols require that theephemeral key only be used once. Ordinary TPM keys have context that may be saved and restored by
TPM context management. This clause describes the methods used to implement the required single use
ephemeral keys.
C.2.2

Commit Random Value

A split operation requires two TPM commands the first of which is TPM2_Commit(). It uses a TPMgenerated, random value in the commit computation. A second command (such as, any of the signingcommands) completes the split signing operation and uses the same commit value. The random commit
value is required to:•have at least the number of bits equal to the security strength of the signing key;•

not be known outside of the TPM; and•only be used once.

Because the random value is not allowed to be known outside of the TPM, the TPM is required to store
the random value between the two commands in split sequence. To allow more than one split sequence
to be in process at a time, the TPM may have an array of values and return a count value as one of the

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 257
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

response parameters of the TPM2_Commit() indicating the array entry being used for the sequence. Thiscount value is an input to the TPM in the command that completes the split sequence.
NOTE

The number of split sequences supported by the TPM may be found using
TPM2_GetCapability(capability = TPM_CAP_TPM_PROPERTIES, property = TPM_PT_SPLIT_MAX).

To minimize the size of the array used for storing these values, a TPM may generate pseudo-random
values instead.
If using pseudo-random values, the TPM creates the value using KDFa(), a counter (commitCount), anda random value (commitRandom). On each TPM Reset, the TPM will select a new random value forcommitRandom and reset commitCount to zero. On TPM2_Commit(), the TPM would use the current
value of the commitCounter to generate the pseudo-random value (r) byr ≔ KDFa (vendorAlg, commitRandom, “ECDAA Commit”, name, commitCount, bits)

(62)

where

nameAlg

the nameAlg of the signing key (signHandle)

commitRandom

the current value of commitRandom“ECDAA Commit”

value used to differentiate uses of KDFa()

name

the Name of signHandle

commitCountthe current value of commitCountbits

the number of bits in the order of the curve of the signing key(signHandle)
NOTE:
When the number of bits is not a multiple of 8, it is rounded up to be amultiple of 8.

To track the usage of the commitCount, the TPM maintains a bit array (A[]) that has a power of 2 numberof bits (N) (that is, the bits indexes of A[] are from 0 to 2N-1). After computing the value of r, the low-order
N bits of commitCount are used to index A[] and the corresponding bit is SET. The low-order 16 bits ofcommitCount are returned as the counter parameter.
C.2.3

TPM2_Commit()

TPM2_Commit() performs the first part of a split operation. The TPM will perform the point multiplications
on the provided points and return intermediate signing values. Alternatively, the TPM will simply return apublic ephemeral key based on a commit private value. The signHandle parameter refers to an ECC key.
TPM2_Commit() has the following parameters, all of which are optional.

P1

point on the curve used by signHandle (a TPM2B_ECC_POINT)s2

octet array used to derive
TPM2B_ECC_PARAMETER)y2y-coordinate
of
the
point
TPM2B_ECC_PARAMETER)NOTE 1x-coordinateof

associated

a

base

point

(a

with

s2

(a

P1 is a TPM2B_ECC_POINT, a sized buffer containing a TPMS_ECC_POINT. It is not a sized buffer
containing an array of bytes. A size of zero for the TPM2B_ECC_POINT will create an unmarshaling
error because the minimum size for P1 is 4 (two ECC parameters, both of which are Empty Buffers).
If P1 is an Empty Buffer, the TPM returns TPM_RC_INSUFFICIENT regardless of s2 and y2. If P1 isan Empty Point and s2 and y2 are Empty Buffers, then the TPM will set E := [r]G where r is thecommit random value and G is the generator point for the curve.

Page 258
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

In the algorithm below, the following additional values are used in addition to the command parameters:

HnameAlghash function using the nameAlg of the key associated with signHandlepfield modulus of the curve associated with signHandlenorder of the curve associated with signHandleds

private key associated with signHandle

G

generator of the curve associated with signHandleccounter that increments each time TPM2_Commit() is executed

A[i]array of bits used to indicate when a value of c has been used in asigning operation; the values of i are 0 to 2N-1.

N

log2 of the number of values in Aknonce that is set to a random value each on each TPM Reset; the nonce
size is twice the security strength of any ECDAA key supported by the
TPM

The commit algorithm is:
Validate that s2 and y2 are either both Empty Buffers or both not Empty Buffers (TPM_RC_SIZE)
If s2 is an Empty Buffer, skip to step e)compute x2 ≔ HnameAlg (s2) mod p
if (x2, y2) is not a point on the curve of signHandle, return TPM_RC_ECC_POINT
if p1 is not an Empty Point and p1 is not a point on the curve of signHandle, return
TPM_RC_ECC_POINT
set K, L, and E to be Empty Buffers
generate or derive r (see C.2.2)
set r ≔ r mod n
if s2 is not an Empty Buffer, set K ≔ [ds] (x2, y2) and L ≔ [r] (x2, y2)
if p1 is not an Empty Point, set E ≔ [r] (p1 )if p1 is an Empty Point and s2 is an Empty Buffer, set E ≔ [r] G
if K, L, or E is the point at infinity, return TPM_RC_NO_RESULT
set counter ≔ commitCountset commitCount ≔ commitCount + 1
NOTE 2

Depending on the method of generating r, it can be necessary to update the tracking array here.

output K, L, E and counter
NOTE 3

C.2.4

Depending on the input parameters, K and L or E can be Empty Points

TPM2_EC_Ephemeral()

TPM2_EC_Ephemeral() is similar to TPM2_Commit() in that it uses the commit random value to generate
an ephemeral key for use in a two-phase operation. However, TPM2_EC_Ephemeral() only used theFamily “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 259
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

random value r to generate a corresponding public key Q ≔ [r]G where G is the generator point for a
specified curve.
As with TPM2_Commit(), a counter value is returned. This value needs to be used in a subsequentcommand in order to complete the two-phase operation.
C.2.5

Recovering the Private Ephemeral Key

To complete a split or two-phase operation, the TPM uses the same random or pseudo-random value
generated in TPM2_Commit(). The random or pseudo-random value is determined by the counter fieldprovided as an input parameter for the command that is the second phase of the split operation.
If the values are stored in an array, counter is used to index the array and, after the value is used in thesigning operation, the value is erased. If using the pseudo-random method, the following algorithm isused to reconstruct the random value.
set t ≔ low-order 16 bits of commitCount
verify that t – 2N < counter < t; else return TPM_RC_RANGE
set i ≔ low-order N bits of counter
if A[i] is CLEAR, return TPM_RC_VALUE
set c ≔ commitCount - t
if counter ≥ t; c ≔ c – 216c ≔ c + countercompute r as in equation (62) using c in place of commitCountif the command completes successfully set A[i] ≔ 0
C.3

ECC-Based Secret Sharing

An ECC key protects a secret in two cases: object duplication and seeding of a session. In both cases,
the method for generating the required key uses KDFe(), as described in clause 11.4.10.3.
C.4

EC Signing

C.4.1

ECDSA

For a TPM compliant with this specification, the default ECC signing scheme (DSA) is as defined ISO/IEC
14888-3.
C.4.2

ECDAA
Introduction

If a TPM supports ECC, it is recommended that it also support the ECDAA scheme described in thisclause C.4.2.
Direct Anonymous Attestation based on ECC (ECDAA) is a TPM signature scheme that provides
anonymous signatures (meaning that different signatures from the same signer cannot be correlated), or
pseudonymous signatures (meaning that different signatures from the same signer can be correlated but
Page 260
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

the identity of the signer is still unknown). Multiple ECDAA schemes are supported in this TPM
implementation.
The TPM signs data with an ECDAA key in an unconventional way. A Verifier verifies signature values
using data equivalent to a public key, and verifies the public key using data equivalent to a certificate(which is also called a credential) supplied by an Issuer. However, the public key and the credential are
randomized by the TPM and the TPM’s Host platform before they are sent to the Verifier. This prevents
both the Verifier and the Issuer from identifying the TPM that created the signature value.
It is anticipated that the most common use of ECDAA will be to certify (TPM2_Certify()) a TPM object(usually a key). A credential issuer will provide a certificate for an ECDAA key. This certificate will validatethat the ECDAA key belongs to a valid TPM without disclosing the ECDAA key. That ECDAA key may
then be used to certify other TPM objects. These certificates prove that the certified object belongs to avalid TPM without disclosing the identity of that TPM. If the certified key is a signing key, it may then be
used to attest to various TPM states, without disclosing the identity of the TPM to which it belongs.
This scheme is substantially different from the AIK scheme in 1.2 in that the ECDAA key may be used toprovide the anonymity for keys rather than having to send each new attestation key to a privacy certificate
authority (PCA) in order to have an anonymizing certificate produced. After a certificate has beenobtained for an ECDAA key, it may be used to produce anonymized certificates for many TPM keys
without requiring additional interaction with a privacy CA.
An ECDAA key may be used in any command that produces a signature. The TPM may not be used toverify an ECDAA signature.
ECDAA Key Generation on the TPM
While any signing key may be an ECDAA key, it is most useful as a Primary Key in the Endorsement
hierarchy. This ensures that a TPM will normally produce the same ECDAA keys and receive the same
credentials from a given Issuer, no matter how many times the credentialing process is performed, and nomatter how many owners the TPM has had. This property is desirable because an Issuer should only givecredentials to a platform after verifying that the platform has the architecture of a trusted platform. The
Issuer would give replacement (different) credentials only when it is necessary to retire the oldcredentials. Replacement credentials erase the previous DAA history of the platform, at least as far as thecredentials from that issuer are concerned. Replacement might be desirable, as when a platform changes
hands, for example, in order to eliminate any association via DAA between the seller and the buyer. On
the other hand, replacement might be undesirable, since it enables a rogue to rejoin a community fromwhich it has been barred. Replacement is done by submitting a different TPMT_PUBLIC.unique fieldvalue to the TPM when the key is created (TPM2_Create() or TPM2_CreatePrimary()). Software may use
any value of TPMT_PUBLIC.unique field at any time, in any order, but the Issuer can detect when arequest uses a different value from the previous request and could reject the request.
The cryptographic parameters of the curve are indicated by the template in the command(TPM2_Create() or TPM2_CreatePrimary()) that creates the curve. The curve ID depends on the Issuer
who is expected to provide a credential for the DAA key (different Issuers may require different curves).
The TPM generates a private key (ds) and a public key (Qs). The non-cryptographic parameters in thetemplate (that is, object attributes and signing scheme) are chosen by the entity that calls the commandto create the DAA key. Inappropriate choice of the non-cryptographic parameters will cause the Issuer toreject an application for a DAA credential.
The security strength of an ECDAA key is the same as an ECC key of the same size. The key size isdetermined by the order of the curve (n) and the cofactor (h).
If the Endorsement Primary Seed is used as the DAA seed, then, like other EK, an ECDAA key willchange whenever the EPS is changed.
Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 261
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

The process for generating an ECDAA key is identical to the process used for any ECC key.
For the TCG defined ECDAA protocol, the curve described by p, n, and b is a Barreto-Naehrig (BN)elliptic curve. BN curves are of the form y2=x3+b as defined in [ISO/IEC 15946-5 : 2008 Clause 7.3 “BNcurve”], which is equivalent to [IEEE P1363.3 (Draft 2) Clause A.11.5 BN Curves].
The linear term ( a ) of generic ECC curves (curves with the form y 2 =x 3 +ax+b ) is zero in BN curves.
All BN curves are suitable but some are less efficient than others. The BN curves recommended inthis version of DAA were chosen by the DAA designers.

NOTE

The cryptographic value of the public key in the resultant TPM key structure is Qs, which is used by theIssuer when computing the membership credential on the DAA private key ds. Qs is not used to verify the
DAA signatures produced by the TPM and corresponding host platform.
ECDAA Sign Operation
The ECDAA scheme may be used in any command that uses a signing key. These are, the attestationgroup and TPM2_Sign().
For an attestation command using the ECDAA scheme, both the qualifiedSigner and extraData fields inthe attestation block (a TPMS_ATTEST) are set to be the Empty Buffer before the data is hashed. The
attestation data is then marshaled and hashed. The resulting hash data is then concatenated to the firsthash to produce the value to sign (P).

P ≔ HschemeHash(qualifyingData || HschemeHash(TPMS_ATTEST))(63)

For TPM2_Sign(), the value to sign is the input digest andP ≔ digest(64)

To complete the ECDAA sign operation, the TPM uses the same random or pseudo-random value (r)used in TPM2_Commit(). The value is determined by the counter field in the scheme parameter of thesigning command. This parameter is used in the process defined inC.2.5.
The signature is created using a modified Schnorr signature using the P and r values described above:
set k to a random value such that 0 < k < ncompute T ≔ H(k || P)(mod n)compute integer s ≔ (r + Tds)(mod n)
if s = 0, output failure (negligible probability)
The signature is the tuple (k , s).
The k value is returned in the R parameter of the TPMT_SIGNATURE structure.

NOTE

C.4.3

EC Schnorr
Introduction

If a TPM supports ECC, it should support the TPM_ALG_ECSCHNORR scheme.
The scheme description uses the following values:
Page 262
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryG

generator point for the curve of the signing key

dS

private value of the signing key

QS

public point of the signing key (QS ≔ [dS]G)norder of G

HschemeHash

hash algorithm specified in the signing scheme

EC Schnorr Sign
An EC Schnorr signature is generated when the signing scheme for a key is TPM_ALG_ECSCHNORR.
The scheme many be used in any signing operation
To sign a digest P
set k to a random value such that 0 < k < ncompute E ≔ (xE, yE) ≔ [k]Gif E is the point at infinity, go to a)compute r ≔ TRUNC(HschemeHash(FE2BS(xE) || P ) ,n)
NOTE 1x E is a field element with the same number of bits as the curve order n

NOTE 2TRUNC() is a function that reduces the number of octets in the first argument until it has no more
octets than the second argument. Truncation occurs from the less significant end of the number. If
the digest produced by H schemeHash has the same number of octets as the curve order n , then notruncation occurs.

NOTE 3

FE2BS() is a function that converts the number x E (a field element) into a canonical value (octet orbyte string) with the same number of octets as the field order n . This can result in a value withleading octets of zero. As x E is computed (mod p ) the value may be greater than ncompute integer s ≔ (k + rdS) (mod n)
NOTE 4This is the same computation as step c) in C.4.2.3.

if s = 0 or s = k go to a)
NOTE 5The s = k check is to eliminate the possibility that 0 = r (mod n ). Optionally, an implementation
could check after d) that 0 ≠ r (mod n ).

The signature is the tuple (r, s).
EC Schnorr Signature Validate
To validate a Schnorr signature (r, s) over digest P
verify that 0 < s < ncompute (xE, yE) ≔ [s]G + [-r]QS
compute r' ≔ TRUNC(HschemeHash(FE2BS(xE) || P ) ,n)
the signature is valid if r' = r

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 263
December 24, 2020

Trusted Platform Module Library

The comparison of r’ and r is done assuming that both values are numeric and not octet strings.
This reduces the chance of interoperability problems due to padding performed on r .

NOTE

C.5

Part 1: Architecture

ECC Key Generation

For an ECC key, the method of FIPS 186-4, Annex B.4.1 Key Pair Generation Using Extra Random isused. The caller provides a random number generation function according to the type of key being
generated (see 27.6.2, 27.6.3, and 28.4) and that function is called when random bits are required by thegeneration process. The key generation process is:
obtain a random value c of length(n) + 64 bits where n is the order of the curve
set d ≔ (c mod(n-1)) + 1
compute Q ≔ (xQ, yQ) ≔ [d]G
return d and Q
C.6

Secret Sharing

C.6.1

ECDH

For secret sharing with an ECC key, the One-Pass Diffie-Hellman, C(1, 1, ECC CDH) method from
SP800-56A is used.
Using the notation of SP800-56A, the initiator generates an ephemeral key pair (de,U, Qe,U) from the curveparameters. The public point of the ephemeral key(Qe,U) is used by the recipient to recover the sharedsecret.
The initiator uses the private portion of the ephemeral key (de,U) and the public portion (Qs,V) of an ECC
key of the recipient and computes the point P ≔ h [de,U ]Qs,V. Then it will set Z ≔ xP where xP is the xcoordinate of P.
The recipient may compute P ≔ h [ds,V ]Qe,U and Z ≔ xP.
The Z value is used in KDFe to generate a value for seed that is appropriate for the use of the seed. The
seed will be the size of the digest produced by the hashAlg used in the KDF. Seed is computed by:seed ≔ KDFe(hashAlg, Z, label, PartyUInfo, PartyVInfo, bits)

(65)

where

hashAlg

the nameAlg of the recipient key

Z

the x coordinate (xP) of the product (P) of a public point and a private key(P ≔ h [d] Q)label

an application-dependent value

PartyUInfo

the x-coordinate of the secret exchange value (Qe,U)

PartyVInfo

the x-coordinate of a public key (Qs,V)

bits

the number of bits in the digest of hashAlg

Page 264
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
C.6.2

Trusted Platform Module Library

ECDH Encryption of Salt

In TPM2_StartAuthSession(), when tpmKey is an ECC key, a seed value is produced as described inclause C.6.1 with the label parameter set to “SECRET”. This seed value is then used as the session
secret.
C.6.3

ECC Secret Sharing for Duplication

When the new parent for a duplicated object is an ECC key, an ephemeral key is created and used togenerate a seed value as described in clause C.6.1. When creating the seed, the label parameter is set to“DUPLICATE”. The seed value is then used to generate the encryption and integrity values for the
duplication blob as described in clause clause 22.
C.6.4

ECC Secret Sharing for Credentials

When the decryption key for an identity blob is an ECC key, an ephemeral key is created and used togenerate a seed value as described in clause C.6.1. When creating the seed, the label parameter is set to“IDENTITY”. The seed value is then used to generate the encryption and integrity values for the identity
blob as described in clause 22.
C.7
C.7.1

ECC Primitive Operations
Introduction

When ECC is implemented on a TPM, it may provide these additional commands to support
cryptographic operations with unrestricted ECC keys.
C.7.2

TPM2_ECDH_KeyGen()

TPM2_ECDH_KeyGen produces an ephemeral key pair. It multiplies the private ephemeral key with the
public point of a loaded TPM key to produce the Diffie-Hellman shared secret.
This function can be performed by software as the public key and parameters are known. The function
would be provided by the TPM as a service.
Since the operation can be performed by software, no authorization is required to use the public portion of
the key and the key attributes are not checked.
C.7.3

TPM2_ECDH_ZGen()

TPM2_ECDH_ZGen performs the ECDH primitive function with one static and one ephemeral key as
defined in SP800-56A, clause 6.2.2. The input point (Qe) is multiplied by the private coordinate (ds) to
produce the point Z = (xZ, yZ) ≔ hdsQe.
Since this operation used the private portion of an ECC key, authorization is required. To prevent
inadvertent compromise of a signing key, sign and restricted are required to be CLEAR in the referenced
key.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 265
December 24, 2020

Trusted Platform Module Library
C.7.4

Part 1: Architecture

Two-phase Key Exchange
Introduction

Various key exchange protocols use an ephemeral key from each party. For these protocols, each party
generates an ephemeral key and that key is sent to the other party along with other information. The
other party then uses the key material from the other party along with its own ephemeral key to generate
the key-exchange values.
These protocols require two phases. In the first phase, the TPM generates an ephemeral key to be sent
to the other party. In the second phase, the TPM combines data from the other party with the ephemeral
key generated in the first phase. The protocols require that the ephemeral key generated by the TPM only
be used once and be discarded after the key exchange is complete. This property of this key is the sameas required for ECDAA.
TPM2_EC_Ephemeral() uses the commit mechanism to generate a random value (r) and a public key P≔ [r]G. The value of P is returned to the caller along with the counter value associated with r.
TPM2_ZGen_2Phase() is used to complete the second phase of the key exchange. The counter value
returned by TPM2_EC_Ephemeral() is provided from which the TPM recreates r and regenerates theassociated public key. When TPM2_ZGen_2Phase() completes successfully, the TPM will "retire" the rvalue so that it may not be used again.
One of the parameters of TPM2_ZGen_2Phase() is a scheme selector (inScheme). This indicates to the
TPM which of the supported schemes is to be used. This annex describes two of the allowed schemes.
They are the two EC schemes from SP800-56A that require two ephemeral and two static keys. The
schemes are specified in SP800-56A in 6.1.1.2 Full Unified Model, C(2, 2, ECC CDH) and 6.1.1.4 Full
MQV, C(2, 2, ECC MQV). These schemes use the following terms:

ds,A

the private part of a TPM-resident ECC key referenced by the keyAparameterQs,Athe public point of the key referenced by keyA equal to [ds,A]G withcoordinates (xs,A, ys,A)de,Aa private ephemeral key generated by the TPM (the value of r
associated with counter parameter)Qe,Athe public ephemeral key associated with counter equal to [de,A]G or [r]Gwith coordinates (xe,A, ye,A)

Qs,B

the inQsB parameter – a point on the curve of keyA assumed to be astatic public key associated with the other party in the key exchange withcoordinates (xs,B, ys,B)

Qe,B

the inQeB parameter – a point on the curve of keyA assumed to be an
ephemeral public key associated with the other party in the key
exchange with coordinates (xe,B, ye,B)
Full Unified Model

When this scheme is selected for TPM2_ZGen_2Phase(), the TPM will:
set outZ1 ≔ [ds,A]Qs,B
set outZ2 ≔ [de,A]Qe,B

Page 266
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
NOTE

Trusted Platform Module Library

If outZ1 or outZ2 is the point at infinity, then both coordinate values of the point will be Empty
Buffers.

Full MQVThis scheme uses an associated value function (avf()) that is defines as:
Inputs:Q = (x, y)a public keynthe modulus of the curve containing Q

Process:

Process:
Set f ≔ ( log2(n)/ 2)
Set x' = 2f + (x mod 2f )return x'
The MQV computation is:validate that Qs,B and Qe,B are on the curve associated with ds,Ausing counter, recover de,A = r as described in clause C.2.5
set Qe,A ≔ [de,A]G where G is the generator point for the curve of ds,A
set tA ≔ (de,A + ds,A · avf(Qe,A)) (mod n)
set outZ1 ≔ [h · tA] (Qe,B + [avf(Qe,B)](Qs,B))
NOTE 1

if outZ1 is the point at infinity both the coordinate values of outZ1 will be Empty Buffers

NOTE 2This protocol may be susceptible to unknown key -share (UKS) attacks.

C.8

ECC Point Padding

To provide consistent behavior across all TPM implementations this clause describes the padding
requirements for ECC parameters. An ECC point returned by the TPM is composed of x and y ECC
parameters, both of which are required to be the size of their associated curve (e.g., 32 bytes for NIST P256). If necessary, leading bytes of zero will be added to these point values. When the ECC parameters
are returned by the command TPM2_ECC_Parameters(), the numeric values will be as specified in the
TCG Algorithm registry. However, the size of values, other than the x and y of the generator point, may
not be the same as the registry because values may or may not be zero padded.
To ensure interoperability, an ECC point that is part of a TPM2B_PUBLIC should be padded with zeros tobe the size of the order of the curve that defines the key.
When an ECC point is input to the TPM, the padding is required as described above for TPM output of an
ECC point.
NOTE:

The reason for requiring padding on the input of an ECC point is that an ECC point makes up theunique field of an ECC key. The Name of the key is computed by hashing the key’s public area as
input to the TPM. If the ECC point in the unique field is not properly padded, the Name would not be
consistent.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 267
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

An intermediate ECC point, such as the result of an ECC point multiplication or the public key of anephemeral ECC key, is required to be padded if used as input to the KDFe() function.
NOTE

This ensures that the secret derived from KDFe(), which is used e.g. as salt in
TPM2_StartAuthSession(), or as protection seed of the outer wrapper in TPM2_Duplicate(), is thesame on different implementations.

Revision 1.16 of this specification also required the ECC private key in duplicate of TPM2_Import() to bepadded.

Page 268
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Annex D(normative/informative)
Support for SMx Family of Algorithms
D.1

Introduction

This clause provides additional information for implementation of the SM2, SM3, and SM4 algorithms
published by the Standardization Administration of the P.R.C.
D.2

SM2

D.2.1

Introduction

SM2 contains information relating to ECC cryptography and is in five parts.
•

GB/T 32918.1-2016: General – "provides necessary basics of mathematics and related cryptographic
techniques used in public key cryptographic algorithm SM2 based on elliptic curves." The methods ofthis part are compatible with the EC methods in other standards and no special considerations arenecessary to accommodate this standard.

•

GB/T 32918.2-2016: Digital Signature Algorithm – defines the process for generation and verificationof a digital signature using the methods described in Part 1. The signing method in this part of thestandard requires addition of a new signing scheme and methods. These are described in this annex.

•

GB/T 32918.3-2016: Key Exchange Protocol – defines a two phase key exchange protocol using themethods of Part 1. The method in this part of the SM2 standard is supported by addition of a key
exchange command (TPM2_ZGen_2Phase()). The algorithm is fully described in TPM 2.0 Part 3 ofthis TPM specification.

•

GB/T 32918.4-2016: Public Key Encryption Algorithm – defines an encryption method using single
pass EC Diffie-Hellman to exchange a key that is then used to generate a stream cipher.

•

GB/T 32918.5-2017: Parameter definition – defines the parameters for a 256-bit ECC curve.

D.2.2

SM2 Digital Signature Algorithm
SM2 Sign

The SM2 signing scheme has an algorithm ID of TPM_ALG_SM2. If the TPM implements this algorithm,
then any structure that allows an ECC-based signing scheme may use this algorithm ID.
The TPM only implements a portion of the full SM2 signing scheme. That portion is the part that uses theprivate key to sign a digest.
The inputs to the algorithm are:ea digest to signds

a private ECC keynthe modulus of the curve for ds

The computation implemented in the TPM is:
set k to a random value such that 1 ≤ k ≤ n-1
compute P1 ≔ (x1, y1) ≔ [k]GFamily “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 269
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

compute r ≔ e + x1 (mod n)
if r equals 0 or (r + k) equals n, go to a)compute s ≔ ((1 + ds)-1 · (k – r · ds)) (mod n)
if s equals 0, go to a)the signature is the tuple (r, s)
SM2 Signature Verification
For verification (TPM2_VerifySignature() and TPM2_PolicySigned()), the inputs are:ethe digest that was signed(r, s)

the signature tupleP

a public ECC key

G

the generator point for the curve of Pnthe modulus of the curve for ds

The verification computation performed by the TPM is:verify that r and s are in the inclusive interval 1 to (n – 1)
compute t ≔ (r + s) (mod n)
verify that 0 < tcompute (x, y) ≔ [s]G + [t]Pcompute r' ≔ (e + x) (mod n)
verify that r' = r
If any of the verification steps fails, then the signature is not valid.
Implementation Issues
In the SM2 standard, the message to sign is combined with key-specific data to produce an e value that issigned using the algorithm shown above. The computation for e uses a value ZA that, according to theSM2 standard, is computed by:

ZA ≔ H( ENTLA || IDA || a || b || xG || yG || xA || yA )

(66)

where

ENTLA

two octets containing the length of IDA in octets

IDA

octet string containing information that can identify an entity’s identity
unambiguously (see ISO/IEC 15946-3 3.9)acoefficient for the linear term of the equation for the curve of the signingkeybcoefficient for the constant term of the equation for the curve of thesigning key

xG

the x coordinate of the generator point for the curve of the signing key

Page 270
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module LibraryyG

the x coordinate of the generator point for the curve of the signing key

xA

the x coordinate of the public key of the signing key

yA

the y coordinate of the public key of the signing key

Using ZA and a message (M) the digest to sign (e) is computed by:e ≔ H(ZA || M)(67)

Since the TPM does not do the operation in equation (67), the caller may need to modify the input
message before using the TPM to sign the digest. If the application requires it, the caller would need to do
the computation of e before giving the value to the TPM to sign.
One consequence of this is that attestation operations will not create a signature that is in all details,
compliant with SM2 Part 2. Instead, the attestation signatures will be TPM specific. The reason that
attestations do not sign using the full scheme are:•

There is no infrastructure for the distribution of IDA values•

Requiring the use of an IDA value in a signature could allow correlation of a user and void the privacy
assurances of the attestation•

Ensuring that an external digest does not match a valid attestation becomes intractable.

The reason that the attestation problem becomes intractable is that, using ZA with an attestation meansthat the first bytes that were used to form the digest of the signed value (e) would vary with each key used
to sign. An attacker could perform a hash using the key specific values followed by message data thathas all the characteristics of an attestation. The TPM will not be able to discern the transition from ZA data
to the false attestation data.
To prevent this kind of attack without adding excessive complexity to the TPM, the attestation is done
without including ZA. Since the use of ZA does not improve the security of the SM2 signature, leaving it out
does not compromise the value of the SM2 signing process for attestations. Also, since an attestation
only has meaning in the context of a TPM, having TPM-specific verification of a signature over an
attestation block should not create an issue.
TPM2_Sign() may be used with the TPM_ALG_SM2 scheme identifier to create a full SM2-compatible
signature. To do an SM2 signature, the application would compute ZA, and then use the resulting digest
as the first data in one of the TPM hash commands (which could be a TPM2_HashSequenceStart()); with
the ZA value followed by the message data (M). The digest of H(ZA || M) would then be used as the digest
parameter for TPM2_Sign().
Since Z A is a constant value for a key, an application might choose to keep Z A as part of the metadata for the key so that it would not need to be recomputed each time the key is used for an SM2
signature.

NOTE

D.2.3

SM2 Key Exchange
Introduction

The key exchange algorithm GB/T 32918.3-2016 is a two-phase algorithm. It is similar to the scheme
described in clause C.7.4.3.
NOTE

This protocol may be susceptible to unknown key-share (UKS) attacks.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 271
December 24, 2020

Trusted Platform Module LibraryPart 1: ArchitectureThis SM2 key exchange computations use an associated value function (avfSM2()) that is similar to thefunction defined in SP800-56A with the only differencing being that the result is one bit less than the value
defined in SP800-56A. The avfSM2() function is:
Inputs:Q = (x, y)a public keynthe modulus of the curve containing Q

Process:
set f ≔ ( log2(n)/ 2) − 1
set x' ≔ 2f + (x (mod 2f))
return x'
NOTEThis function is similar to the function in SP800 -56A except that, in the formulation in GB/T 32918.32016 as shown in a) above, the value of f is one less than the equivalent in SP800-56A.

SM2 Key Exchange Protocol
The key exchange protocol is between two entities, A and B. The TPM performs computations as party A.
Since the protocol is symmetric, both party A and party B may be TPMs and they will both perform thesame operations, using the values from the other TPM as party B values.
The caller must use TPM2_EC_Ephemeral() to have the TPM generate a single-use ephemeral key. The
ephemeral public key is sent to the other party as Qe,B.
The inputs to the key exchange computation are:counterthe counter parameter from TPM2_Commit()Qs,Ba public EC key from party B; usually, the public part of a static key

Qe,Ba public EC key; usually, the public part of an ephemeral key

ds,Aa private EC key (an unrestricted decryption key)

The protocol:
validate that Qs,B and Qe,B are on the curve associated with ds,Ausing counter, recover r as described in clause C.2.5
set Qe,A ≔ [r]G where G is the generator point for the curve of ds,A
set tA ≔ (ds,A + de,A · avfSM2(Qe,A)) (mod n)
set Z ≔ [h · tA] (Qs,B + [avfSM2(Qe,B)](Qe,B))
if Z is the point at infinity, return failure

Page 272
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
D.2.4

Trusted Platform Module Library

SM2 Encryption and Decryption
Introduction

These clauses describe the encryption and decryption process of GB/T 32918.4-2016 as implemented in
the TPM.
NOTE

The results of the encryption contains an encoded ECC point. This specification only supports theuncompressed version of a point.

These algorithms may be use with any ECC key with a restricted attribute that is CLEAR.
Encryption
The encryption process is based on ECDH using the exchanged secret key as a generator for a bit
stream. That bit stream is XOR with the clear text M to produce the ciphter text C. The inputs to theencryption process are:PB

a public EC key for the entity receiving the encrypted dataGthe generator point for the curve of PBnthe modulus of the curve of PB

Mthe bit string to be encrypted

KDF

a KDF algorithm such as KDF1 or KDF2

Hash

the hash algrotihm used in the KDF

The process:set k to a random value such that 1 ≤ k ≤ n-1
compute P1 ≔ (x1, y1) ≔ [k]Gcompute P2 ≔ (x2, y2) ≔ [k]PB
if P1 or P2 is the point at infinity, go to a)
set C1 ≔ x1 || y1
NOTE 1C 1 is the uncompressed form of an ECC point.

create a bit string t of length len(M) using the selected KDF and hash algorithm with x2,|| y2 as the key
value
NOTE 2Currently, only KDF2 (TPM_ALG_KDF2) is supported.

set C2 ≔ M ⊕ t
set C3 ≔ H(x2 || M || y2)
return C1, C2, and C3
Decryption
The inputs to the decryption are:Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 273
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

C1

an ephemeral key

C2

a block encrypted according to cribed in clause D.2.4.2

C

an encrypted block as described in clause D.2.4.2

dB

a private static key

KDF

a KDF algorithm such as KDF1

Hash

the hash algrotihm used in the KDF

The process:extract P1 = x1, y1 from C1.
compute P2 ≔ (x2, y2) ≔ [dB]P1
create a bit string t of length len(M) using the selected KDF and hash algorithm with x2,|| y2 as the key
value
set M ≔ C2 ⊕ t
set V ≔ H(x2 || M || y2)
if V is not equal to C3, return error
return M
D.3

SM3

SM3 (defined in GB/T 32905-2016) is a hash algorithm that uses a 512-bit block and produces a digest of
256 bits.
If the TPM implements this algorithm, then the algorithm ID for SM3 (TPM_ALG_SM3_256) may be usedin any structure that allows a hash algorithm.
D.4

SM4

SM4 (defined in GB/T 32907-2016) is a symmetric block cipher with a key and block size of 128 bits.
If the TPM implements this algorithm, then the algorithm ID for SM4 (TPM_ALG_SM4) may be used inany structure that allows a symmetric block cipher.

Page 274
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture

Trusted Platform Module Library

Annex E
(normative/informative)
TDES
E.1

TDES Key Parity Generation

A TDES key is generated by getting 24 bytes from the random number generator appropriate for the typeof key generation (such as a KDF for a derived key). The 24 bytes are treated as 3, 64-bit values incanonical TPM form (big-endian bytes). The odd parity is then generated for each byte with the parity
replacing the least significant bit in each byte to create 3 DES keys. The resulting three DES keys arethen validated to make sure that none of them is on the list of prohibited DES key values. If any of thegenerated key values is prohibited, then the TPM will repeat the key generating process by generating 24
new bytes.

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 275
December 24, 2020

Trusted Platform Module LibraryPart 1: Architecture

Annex F(informative)
Library Profile Guide
F.1

Introduction

This annex provides guidance to TPM platform specific work groups when developing platform specific
TPM specifications. The platform specific specification must specify these items. It aggregates platform
specific information from other parts of this specification.
F.2

Platform Specific Constants•

Constants returned by TPM2_GetCapability with the capability prefix TPM_PT_PS. See Part 2.

•

The manufacturer, vendor strings, and firmware version.

F.3

PCR
•

Number of PCR.

•

The minimum size of a selection structure.

•

Number of banks.

•

Supported hash algorithms.

•

PCR authorization, authorization groups, and locality.

•

Which can be reset, under what conditions, and what the reset value is.

•

Whether the PCR is preserved on resume.

•

Which PCR increment the PCR update counter.

•

DRTM and H-CRTM behavior, and PCR values at _TPM2_Init().

F.4

Algorithms

Define algorithms. See the TCG algorithm registry.
•

Hash, asymmetric, and symmetric algorithms.

•

For elliptic curve, the curves.

•

Key sizes.

•

Padding modes.

•

Endorsement key certificate provisioning, and the NV attributes for the certificates.

•

Algorithms and modes for parameter encryption.

F.5

Commands

See Part 2 and note that some commands have prerequisites or are implemented as a set.
•

Mandatory, optional, and forbidden commands.

•

Whether firmware upgrade is required, and whether the library specification or a vendor specificmethod is permitted.

Page 276
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64

Part 1: Architecture
F.6

Trusted Platform Module Library

Buffers•

The minimum for the maximum size of an NV Index.

•

The minimum size for the input and output buffers.

F.7

NV Storage•

Specify as much as possible the NV storage capacity. Since NV Indexes has varying meta-datarequirements, the value may not be exact.

•

The types of NV Indexes supported. This is linked to the supported TPM2_NV commands.

•

Whether NV Indexes and persistent keys may or may not come from the same NV memory pool.

•A minimum number of total Indexes, and minimums for certain Index types, such as counters.

•

Whether both orderly and non-orderly indexes are supported.

•

The minimum number of persistent key slots.

F.8

Sessions and Objects•

The minimum number of loaded and active sessions.

•

The minimum number of loaded objects.

F.9

Physical Presence•

If physical presence is implemented, specify the table of commands that require physicalpresence.

F.10 Dictionary Attack Lockout•

The default value for maxTries and recoveryTime.

F.11 Self Test•

Whether TPM2_SelfTest() can be blocking or non-blocking.

F.12 ACT•The number of supported ACT instances (usually 0 or 1).

•

Trigger event when the ACT times out.

•

Whether TPM2_ClockRateAdjust() may affect the ACT rate, and maximum adjustment.

•

The ACT behavior if TPM is in a low power state (sleep mode) (typically, ACT must advance).

•

Whether the ACT state must be preserved over a power cycle (setting of the preserveSignaled
attribute).

•

Whether clearing or setting the signaled attribute must also clear or set the associated trigger
event (e.g. when ACT signaling is turned off, or ACT signaling is preserved across TPM
Resume).

Family “2.0”Level 00 Revision 01.64

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Page 277
December 24, 2020

Trusted Platform Module Library•Part 1: Architecture

Whether the remaining ACT timeout must be retrievable in TPM Failure Mode.

Page 278
December 24, 2020

TCG PUBLIC REVIEW
Copyright © TCG 2006-2021

Family “2.0”Level 00 Revision 01.64