TCG EK Credential Profile
For TPM Family 2.0; Level 0
Specification Version 2.0
Revision 14
4 November 2014
Published
Contact:
admin@trustedcomputinggroup.org

TCG PUBLISHED
Copyright © TCG 2014

TCG

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

Copyright © 2014 Trusted Computing Group, Incorporated.

Disclaimers, Notices, and License Terms
THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDINGANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULARPURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATIONOR SAMPLE.
Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights,
relating to use of information in this specification and to the implementation of this specification, and TCG
disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, lossof 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.
This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, isgranted herein other than as follows: You may not copy or reproduce the document or distribute it toothers without written permission from TCG, except that you may freely do so for the purposes of (a)examining or implementing TCG specifications or (b) developing, testing, or promoting information
technology standards and best practices, so long as you distribute the document with these disclaimers,
notices, and license terms.
Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification
licensing through membership agreements.
Any marks and brands contained herein are the property of their respective owners.

Revision 14

Published

TCG PUBLISHED

Page ii of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

IWG Document Roadmap
IWG SKAE Extension

TNC -> new WG
IWG Reference Architecture
for Interoperability Part I

IWG Interoperability for
Backup and Migration
Services

TCG Credential Profiles for
TPM Family 1.2

TCG IWG: A CMC Profile for
AIK Certificate Enrollment

Credentials
IWG CMC Profile for
EK/Platform Certificate
Enrollment for TPM v1.2
TCG EK Credential Profile for
TPM Family 2.0

TCG Architecture Overview

IWG Platform Trust Services
Interface (IF-PTS)
Platform Trust Services
TCG Attestation PTS
Protocol: Binding to TNC IFM

IWG Simple Object Schema

IWG Core Integrity Schema
IWG Architecture Part II –Integrity Management

IWG Integrity Report
SchemaSchemasIWG Reference Manifest(RM) Schema

Credential Management

IWG Security Qualities
SchemaTrust Credentials

Executable Image Schema

IWG Verification Result
Schema

Revision 14

Published

TCG PUBLISHED

Page iii of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

Acknowledgement
The TCG wishes to thank those who contributed to this specification. This document builds on
considerable work done in the various working groups in the TCG.
Special thanks to the members of the IWG group and others contributing to this document:

Name
Bob BellMax Pritikin (Group Chair)
Tom Laffey
Scott Kelly
Ken Goldman
Ga-Wai Chin (Editor)
Georg Rankl
Stefan Kaeser
Eduardo Cabre
Rahul Verma
Ronald Aigner
Olivier Collart
Carolin Latze (Group Chair)
Gloria Serrao
Greg Kazmierczak

Revision 14

Published

Member Company
Cisco Systems
Cisco Systems
Hewlett-Packard
Hyperthought
IBM
Infineon
Infineon
InfineonIntel Corporation
Microsoft
Microsoft
STMicroelectronics
Swisscom
United States Government
Wave Systems

TCG PUBLISHED

Page iv of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

Table of Contents
1

Introduction ............................................................................................................ 7
1.1
1.2
1.3
1.4
1.5
1.6

2

Purpose ......................................................................................................................................... 7
Scope ............................................................................................................................................ 7
Relationship to Other TCG Specifications .................................................................................... 7
Keywords ....................................................................................................................................... 7
Abbreviations................................................................................................................................. 7
Definition of Terms ........................................................................................................................ 7

TPM 2.0 EK and EK Credential .............................................................................. 8
2.1
Endorsement Key .......................................................................................................................... 8
2.1.1 Object Handle............................................................................................................................ 8
2.1.2 Primary Key Generation ............................................................................................................ 8
2.1.3 EK Usage .................................................................................................................................. 9
2.1.4 EK Lifetime .............................................................................................................................. 10
2.1.5 Default EK Public Area Template............................................................................................ 10
2.2
Endorsement Key Credential ...................................................................................................... 14
2.2.1 NV Index Handles ................................................................................................................... 14
2.2.2 Assertions ................................................................................................................................ 15
2.2.3 EK Credential Lifetime ............................................................................................................ 15
2.3
Privacy Protection ....................................................................................................................... 173

X.509 ASN.1 Definitions ....................................................................................... 18
3.1
TCG Attributes............................................................................................................................. 18
3.1.1 TPM Security Assertions ......................................................................................................... 18
3.1.2 TPM Device Attributes ............................................................................................................ 21
3.1.3 TPM Specification Attributes ................................................................................................... 21
3.2
EK Certificate .............................................................................................................................. 22
3.2.1 Version .................................................................................................................................... 23
3.2.2 Serial Number ......................................................................................................................... 23
3.2.3 Signature Algorithm ................................................................................................................. 23
3.2.4 Issuer ....................................................................................................................................... 24
3.2.5 Validity ..................................................................................................................................... 24
3.2.6 Subject .................................................................................................................................... 24
3.2.7 Subject Public Key Info ........................................................................................................... 24
3.2.8 Certificate Policies ................................................................................................................... 25
3.2.9 Subject Alternative Name ........................................................................................................ 25
3.2.10
Basic Constraints ................................................................................................................ 26
3.2.11
Subject Directory Attributes ................................................................................................. 26
3.2.12
Authority Key Identifier ........................................................................................................ 26
3.2.13
Authority Information Access .............................................................................................. 26
3.2.14
CRL Distribution .................................................................................................................. 27
3.2.15
Key Usage ........................................................................................................................... 27
3.2.16
Extended Key Usage .......................................................................................................... 27
3.2.17
Subject Key Identifier .......................................................................................................... 27

4
5
6
A.

Changes from Previous Versions ....................................................................... 28
X.509 ASN.1 Structures and OIDs....................................................................... 29
References ............................................................................................................ 34
Certificate Examples ............................................................................................ 35

A.1
A.2

Example 1 (user device TPM, e.g. PC-Client) ............................................................................ 35
Example 2 (non-user device TPM, e.g. DevID) .......................................................................... 37

Revision 14

Published

TCG PUBLISHED

Page v of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

TablesTable 1: Default RSA EK Public Area Template (TPMT_PUBLIC)............................................................. 11
Table 2: Default ECC EK Public Area Template (TPMT_PUBLIC) ............................................................ 12
Table 3: EK Certificate Fields...................................................................................................................... 23

Revision 14

Published

TCG PUBLISHED

Page vi of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

1 Introduction
1.1 Purpose
The purpose of this document is to define the TPM 2.0 Endorsement Key (EK) Credential. This
specification describes the content of the credential and provides an X.509 instantiation of thecredential. A standardized and commonly used format should provide better interoperability
between credential providers and users.

1.2 ScopeThis document specifies the TPM 2.0 Endorsement Key Credential. It does not apply to TPM 1.2
credentials or credentials of other type.

1.3 Relationship to Other TCG Specifications
A TPM claiming adherence to this specification SHALL be compliant with the TPM 2.0 LibrarySpecification[1]; Family 2.0; Level 00; Revision 00.99 or later.

1.4 Keywords
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to beinterpreted as described in RFC 2119[16].

1.5 Abbreviations
CFB

Cipher Feedback mode

CSR

Certificate Signing Request

EK

Endorsement Key

EPS

Endorsement Primary Seed

IDevID Initial Device Identifier
KDF

Key Derivation Function

OEM

Original Equipment Manufacturer

RDN

Relative Distinguished Name

TPM2_ Prefix that indicates a TPM 2.0 command

1.6 Definition of Terms
The TCG Technical Committee Glossary contains a few definitions that are fundamental to thisdocument.
The following operational definitions, however, are specific to this specification.
Certificate – A certificate is an instantiation of a credential using the industry-standard certificate
structure from ISO/IEC/ITU-T X.509 version 3. Certificate generation consists of (a) assemblingvalues for the credential fields and (b) signing over the assembled fields.
Credential – A credential is an abstract proof that must be instantiated as a certificate before it canbe exchanged between entities.

Revision 14

Published

TCG PUBLISHED

Page 7 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

TPM 2.0 EK and EK Credential

2

2.1 Endorsement Key
The Endorsement Key (EK) is an asymmetric key pair consisting of a public and private key stored
in a Shielded Location on the TPM. The public part of the EK can be read from the TPM while theprivate part MUST never be exposed. The public key of the EK is included in the EK certificate.
In TPM 1.2, the Endorsement Key was defined as an RSA 2048 bit key. Different than in TPM 1.2,
TPM 2.0 can have more than one EK. The algorithm flexibility provided by the TPM 2.0 LibrarySpecification[1] allows the TPM to create EKs of any type of asymmetric algorithm implemented in
the TPM (see 2.1.2). The following provides a recommendation for the type of Endorsement Key forwhich an EK certificate is issued that is compliant to section 3.2 of this specification. In this case,
the TPM 2.0 EK SHOULD be an

RSA 2048 bit key or

ECC NISTP-256 bit key

NOTE The recommendation is provided to enhance interoperability. However, the EK is not limited
to this set of algorithms.
Any asymmetric algorithm supported in a platform-specific specification used to implement the TPM
MAY be used instead or in addition to the recommended key types.
The Endorsement Key pair MUST either be generated by the TPM using the command
TPM2_CreatePrimary or the TPM manufacturer MUST generate the EK in the manufacturing
environment and inject it into the TPM. The Endorsement Key is stored as an object in the TPM andis referenced by its object handle.

2.1.1 Object Handle
If the Endorsement Key pair is preinstalled as a persistent object when the TPM is shipped, thehandle value MUST be in the reserved handle range for Endorsement primary keys defined by the
TCG in Registry of Reserved TPM 2.0 Handles and Localities[2]. In any other case, the EK handle
value is assigned by the TPM and returned as a response parameter of the command
TPM2_CreatePrimary. The EK is assigned a transient object handle until it is made persistent withthe command TPM2_EvictControl. When made persistent, the EK is assigned a new object handle
whose value is specified by the caller in the persistentHandle command parameter.
It is not mandatory that an Endorsement Key injected by the TPM manufacturer is preinstalled as apersistent object. The key handle MAY be returned to the caller in TPM2_CreatePrimary when theinPublic command parameter matches the public area template of the EK. This is to allow the caller
to specify values for insensitive, outsideInfo and creationPCR (see TPM 2.0 Library Specification,
Part 3[1]) which are set as additional command parameters of TPM2_CreatePrimary and which canotherwise not be assigned.

2.1.2 Primary Key Generation
The Endorsement Key is a Primary Object controlled by the Endorsement Hierarchy. The
Endorsement Hierarchy has a Seed, the Endorsement Primary Seed (EPS) which is unique to each
TPM. The Primary Seed is a large random value; its size is required to be at least twice the security
strength of any algorithm implemented on the TPM. The EPS MUST be generated within the TPM
or MUST be generated and injected by the TPM manufacturer in the manufacturing environment.
The attribute TPMA_PERMANENT.tpmGeneratedEPS (see TPM 2.0 Library Specification, Part2[1]) MUST be set properly to indicates the source of the Seed. The attribute can be read with
TPM2_GetCapability. The Seed cannot be read from the TPM and MUST never be exposed.
The TPM 2.0 Library Specification[1] defines a process to create primary keys based on a Key
Derivation Function (KDF) and a Primary Seed. The KDF is a deterministic function that uses key
parameters to derive a reproducible key. These parameters determine the type of the key and are

Revision 14

Published

TCG PUBLISHED

Page 8 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

input to the command TPM2_CreatePrimary. When this command is called with the same
parameters, the same key is generated as long as the EPS does not change. The key can be madepersistent in TPM NV memory using the command TPM2_EvictControl or recreated when needed.
This way, any type of key (e.g. symmetric or asymmetric, signing or decryption key) can be createdby the TPM.

2.1.3 EK Usage
In TPM 1.2, the Endorsement Key was defined as a decryption key; it could not be used for signing
operations. Unlike TPM 1.2, TPM 2.0 provides more flexibility in defining an EK. The properties of
the Endorsement Key are determined by its public area template (TPMT_PUBLIC structure, see
TPM 2.0 Library Specification Part 2[1]). The TPMT_PUBLIC structure includes the base attributes
restricted, sign and decrypt that determine the cryptographic operation a key may perform on an
object. The TPM 2.0 Library Specification[1] does not impose any restrictions regarding theattributes of the Endorsement Key. As any other key the Endorsement Key can be a created as adecryption or signing key.
However, the EK and its credential may be considered privacy-sensitive if the private part of the EK
is used in a cryptographic protocol. In this case, the public EK or the EK certificate may represent a
privacy-sensitive cryptographic identifier for a particular platform. In privacy-sensitive environments,
the EK SHOULD NOT be used as a signing key and restricted to specific operations (this is
described in more detail in section 2.3 Privacy Protection).
On the other hand, there are environments where privacy is not an issue. This specification
distinguishes between user device TPMs and non-user device TPMs. Whether the EK MAY signdepends on the type of platform for which the TPM is built.
2.1.3.1 User Device TPM
User device TPMs are TPMs that are associated to a human user, typically PC Client or Mobile
platforms. If the EK is certified by a trusted entity, it SHOULD NOT be used for signing operations
due to privacy concerns. In this case, the EK SHOULD be defined as a restricted decryption key.
User device TPMs SHOULD follow the same privacy constraints as TPM 1.2. For a decryption key,
the key usage field in the EK Credential defined in section 3.2.15 MUST be set to keyEncipherment(for an RSA EK) or keyAgreement (for an ECC EK).
2.1.3.2 Non-User Device TPM
Non-user device TPMs on the other hand are TPMs that are associated to an enterprise, rather
than a specific user. This can be e.g.
Network Elements (e.g. routers, switches, wireless access points)Servers, Virtual Servers, Virtual Devices in a cloud infrastructureEmbedded Devices (e.g. printers)

For such platforms privacy is not a central concern and unique identification is of criticalimportance. These platforms MAY use a certified EK for signing operations. This is intended tofacilitate establishment of further TPM keys, like Device Identification keys, without the need for an
Attestation Key. This allows for simpler infrastructure implementations. In this case, no restrictions
other than defined in the TPM 2.0 Library Specification[1] apply to the settings of the baseattributes. The EK MAY be defined as a general-purpose key if both, signing and decryption should
be supported. The key usage field in the EK Credential defined in section 3.2.15 MUST be set
appropriately to indicate the usage of the EK. If decryption is supported, keyEncipherment (for an
RSA EK) or keyAgreement (for an ECC EK) MUST be set; if signing is supported, digitalSignature
MUST be set.
One use case for a signing EK is to sign the Certificate Signing Request (CSR) for an Initial Device
Identifier (IDevID) key. The IDevID key is a TPM-generated key that is used as an initial identity forsecure device authentication (see IEEE 802.1AR[9]). The CSR can be signed with the command
TPM2_Sign. The hash calculated over the certification request information is passed to the TPM in

Revision 14

Published

TCG PUBLISHED

Page 9 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

the digest command parameter; the inScheme command parameter specifies the signing scheme.
The issuer of the IDevID certificate could verify the CSR signature to ensure that the chip
requesting the IDevID certificate is privileged to receive it. Therefore the issuer could have a list of
EK certificates of all valid TPMs a product manufacturer has purchased. Alternatively, a CSR could
also be signed by an Attestation Key.

2.1.4 EK Lifetime
In TPM 2.0, the lifetime of an Endorsement Key is tied to the Endorsement Primary Seed (EPS). As
long as the EPS is not changed, EKs can be recreated with their public area templates. The
command TPM2_ChangeEPS replaces the Endorsement Primary Seed with a new random value
and makes it impossible to recreate any EKs derived from the previous Seed. This will invalidate allcertificates associated with the EKs.
Platform-specific specifications determine whether the command TPM2_ChangeEPS is required to
be implemented. Some platforms might want to change the EPS, e.g. during platform refurbishment
to erase existing EKs or after a field upgrade from a firmware that had a severe security flaw (inorder to revoke all EKs associated with the old firmware).
On the other hand, there are platforms that need a permanent EPS because invalidating theEndorsement Keys would disable the platform to prove that it is a genuine trusted platform. In nonuser device TPMs (see 2.1.3.2), for instance, the EPS is required to be permanent because the EK
represents the trust anchor for the device identity.
The TPM 2.0 Library Specification[1] provides a means to prevent the EKs from being replaced.
The command to change the EPS requires Platform Authorization, so the OEM can decide if the
EPS ever changes. The use of Platform Authorization can be disallowed by turning off the Platform
hierarchy (by setting the phEnable flag to CLEAR); this disables any functionality in the TPM thatwould require platformAuth or platformPolicy. Furthermore, TPM2_ChangeEPS can be added to
the list of commands that require assertion of Physical Presence. Alternatively, platforms could
prevent EKs from being erased by not exposing this functionality to the user.

2.1.5 Default EK Public Area Template
The following section defines the default values of an RSA and ECC EK public area template.
These default values are used to generate the RSA and ECC Endorsement Key corresponding to
the EK certificates installed by the TPM or Platform manufacturer. The hash calculated over the
public area template is one of the command parameters to the KDF that is used to create the EK.
The TPM or Platform manufacturer MAY create a proprietary EK public area template that isdifferent from the defaults below (this procedure is further described in section 2.2.1). The values
provided in the tables below would be typically used by PC Client platforms. Platform-specificworking groups MAY define a proprietary EK public area template if required. This might benecessary e.g. for Non-User Device TPMs that require an EK for signing purposes. However, theEK provided by the manufacturer MUST be defined as a non-duplicable key. This is ensured by
setting the following two attributes:


fixedTPM = 1



fixedParent = 1

When privacy is an issue, great care should be taken when selecting the attributes and theauthorization for the key (see section 2.3 privacy protection).

Revision 14

Published

TCG PUBLISHED

Page 10 of 37

TCG EK Credential Profile

2.1.5.1

TCG Copyright 2014

Specification Version 2.0

RSA Template

Parameter
type
nameAlg
objectAttributes

Type
TPMI_ALG_PUBLICTPMI_ALG_HASH
TPMA_OBJECT

authPolicy
size
bufferTPM2B_DIGESTUINT16
BYTE

parameterssymmetric->algorithm
symmetric->keyBits
symmetric->mode
symmetric->details
scheme->scheme
scheme->details
keyBits
exponent
uniquesize
buffer

TPMS_RSA_PARMS
TPMI_ALG_SYM_OBJECT
TPMI_AES_KEY_BITS
TPMI_SYM_MODE
TPMI_ALG_ASYM_SCHEME
TPMI_RSA_KEY_BITS
UINT32TPM2B_PUBLIC_KEY_RSAUINT16BYTE

Content
TPM_ALG_RSA
TPM_ALG_SHA256
fixedTPM = 1
stClear = 0
fixedParent = 1
sensitiveDataOrigin = 1
userWithAuth = 0
adminWithPolicy = 1
noDA = 0
encryptedDuplication = 0
restricted = 1
decrypt = 1
sign = 032
0x83, 0x71, 0x97, 0x67, 0x44, 0x84,
0xB3, 0xF8, 0x1A, 0x90, 0xCC, 0x8D,
0x46, 0xA5, 0xD7, 0x24, 0xFD, 0x52,
0xD7, 0x6E, 0x06, 0x52, 0x0B, 0x64,
0xF2, 0xA1, 0xDA, 0x1B, 0x33, 0x14,
0x69, 0xAA
TPM2_PolicySecret(TPM_RH_ENDORSEMENT), see 2.1.5.3
TPM_ALG_AES
128
TPM_ALG_CFB
NULL
TPM_ALG_NULL
NULL
2048
0
256
All 0

Table 1: Default RSA EK Public Area Template (TPMT_PUBLIC)

The default RSA EK public area template in Table 1 specifies an RSA 2048 bit key. Its
objectAttributes indicate that the Endorsement Key is a restricted non-duplicable decryption key
and its authorization is only allowed with authPolicy. The policy requires endorsementAuth toauthorize the EK. This policy is created with TPM2_PolicySecret where the authHandle parameterof the command, indicating the entity providing the authorization value, references theEndorsement hierarchy. The symmetric key is used to protect the child keys of the EK and isdefined as an AES 128 bit key using CFB mode. SHA256 is used to calculate the Name of the EK.
The buffer reserved for the public key of the EK is set to all zeros.

Revision 14

Published

TCG PUBLISHED

Page 11 of 37

TCG EK Credential Profile

2.1.5.2

TCG Copyright 2014

Specification Version 2.0

ECC Template

Parameter
type
nameAlg
objectAttributes

Type
TPMI_ALG_PUBLICTPMI_ALG_HASH
TPMA_OBJECT

authPolicy
size
bufferTPM2B_DIGESTUINT16
BYTE

parameterssymmetric->algorithm
symmetric->keyBits
symmetric->mode
symmetric->details
scheme->scheme
scheme->details
curveID
kdf->scheme
kdf->details
uniquex->sizex->buffery->sizey->buffer

TPMS_ECC_PARMS
TPMI_ALG_SYM_OBJECT
TPMI_AES_KEY_BITS
TPMI_SYM_MODE
TPMI_ALG_ECC_SCHEME
TPMI_ECC_CURVE
TPMI_ALG_KDF
TPMS_ECC_POINT
UINT16BYTE
UINT16BYTE

Content
TPM_ALG_ECC
TPM_ALG_SHA256
fixedTPM = 1
stClear = 0
fixedParent = 1
sensitiveDataOrigin = 1
userWithAuth = 0
adminWithPolicy = 1
noDA = 0
encryptedDuplication = 0
restricted = 1
decrypt = 1
sign = 032
0x83, 0x71, 0x97, 0x67, 0x44, 0x84,
0xB3, 0xF8, 0x1A, 0x90, 0xCC, 0x8D,
0x46, 0xA5, 0xD7, 0x24, 0xFD, 0x52,
0xD7, 0x6E, 0x06, 0x52, 0x0B, 0x64,
0xF2, 0xA1, 0xDA, 0x1B, 0x33, 0x14,
0x69, 0xAA
TPM2_PolicySecret(TPM_RH_ENDORSEMENT), see 2.1.5.3
TPM_ALG_AES
128
TPM_ALG_CFB
NULL
TPM_ALG_NULL
NULL
TPM_ECC_NIST_P256
TPM_ALG_NULL
NULL
32
All 0
32
All 0

Table 2: Default ECC EK Public Area Template (TPMT_PUBLIC)

The default ECC EK public area template in Table 2 specifies an ECC NISTP-256 bit key. Its
objectAttributes indicate that the Endorsement Key is a restricted non-duplicable decryption key
and its authorization is only allowed with authPolicy. The policy requires endorsementAuth toauthorize the EK. This policy is created with TPM2_PolicySecret where the authHandle parameterof the command, indicating the entity providing the authorization value, references theEndorsement hierarchy. The symmetric key is used to protect the child keys of the EK and isdefined as an AES 128 bit key using CFB mode. SHA256 is used to calculate the Name of the EK.
The buffer reserved for the public key of the EK is set to all zeros.

Revision 14

Published

TCG PUBLISHED

Page 12 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

2.1.5.3 authPolicy
The equations below are copied from the TPM 2.0 Library Specification Part 3[1] and indicate how
the authPolicy value, used in the default RSA and ECC EK public area templates (see Table 1 and2), is calculated using the TPM2_PolicySecret command. If there is an inconsistency between theequations below and the equations defined in the TPM 2.0 Library Specification, the definitions in
the Library Specification take precedence.
TPM2_PolicySecret uses the PolicyUpdate function:
PolicyUpdate(TPM_CC_PolicySecret, authObject→Name, policyRef)
This is equivalent to:policyDigestnew ≔ HpolicyAlg(policyDigestold || TPM_CC_PolicySecret || authObject→Name)
policyDigestnew+1 ≔ HpolicyAlg(policyDigestnew || policyRef.buffer)With:
policyAlg = SHA256
policyDigestold = 0x0...0 (32 bytes)
TPM_CC_PolicySecret = 0x00000151
authObject→Name is TPM_RH_ENDORSEMENT (=0x4000000B)
policyRef.buffer = not available
The authPolicy in the default EK public area template is calculated as follows:
policyDigestnew ≔ HSHA256(0x0...0 || 0x00000151 || 0x4000000B)
policyDigestnew+1 ≔ HSHA256(policyDigestnew)

Revision 14

Published

TCG PUBLISHED

Page 13 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

2.2 Endorsement Key Credential
The Endorsement Key Credential is an X.509 v3 certificate that contains the public EK, as well as
various assertions regarding the security qualities and provenance of the TPM. The definition of thecertificate fields are specified in section 3.2. The EK Credential is usually issued by a TPM or
Platform manufacturer during manufacturing process. An entity SHALL NOT create an EK
Credential for a TPM unless the entity is satisfied that the public key referenced in the EK
Credential was either:

returned in response to a TPM2_CreatePrimary command by an implementation ofProtected Capabilities and Shielded Locations that meets the TPM 2.0 Library Specification[1] orgenerated outside the TPM and inserted by a process defined in the Target of Evaluation(TOE) of the security target in use to evaluate the TPM.

There might be use cases where it is useful to issue an EK Credential after manufacturing (e.g. if
the EPS was changed or the TPM is shipped without EK). In this case, the entity issuing thecredential would create a new Endorsement Key with TPM2_CreatePrimary. This procedure would
require support for certificate enrollment. Support for an enrollment protocol is optional and MAY be
done using a proprietary method of the TPM or Platform manufacturer or a method standardized by
TCG. One example implementation (at time of writing, only available for TPM 1.2) is described in
the IWG document CMC Profile for EK/Platform Certificate Enrollment[6].
A primary use case of an EK Credential is to assist Attestation CAs to issue credentials for
restricted signing keys (Attestation Keys). The EK Credential can be used to provide evidence that
the Attestation Keys are resident on the same TPM.
In TPM 2.0, multiple EKs can be derived from a single Seed (as described in section 2.1.2.) As aresult, the TPM can have more than one EK Credential. However, the TPM might not beprovisioned with all the credentials because of NV space restrictions; the credentials could be
stored encrypted off the TPM. If an EK Credential is stored on the TPM, it is stored as an NV Index;
in this case, it is referenced by its NV Index handle (see 2.2.1). The authorization to modify oraccess (read, write, delete) the credential is determined by its attributes. The attributes of the Index
are defined by platform-specific workgroups, as well as the authorization for the index. Definitions
specific to PC Client can be found in PC Client Specific Platform TPM Profile for TPM 2.0[5],section Non-volatile Storage.

2.2.1 NV Index Handles
The NV Index handles related to the EK Credential have fixed values that are defined by the TCG
in the Registry of Reserved TPM 2.0 Handles and Localities[2]. The values are assigned byindividual workgroups and might therefore differ for different platforms. The TCG Registry defines
three types of handles which are described below. Each handle is associated with a separate NV
Index in the TPM.
EK Certificate
This is the NV Index handle of an RSA or ECC EK Credential. If an EK certificate ispresent, this MUST be used.



EK Nonce
This is the NV Index handle of a nonce value (encoded as a sized array) that is included in
the unique field of the TPMT_PUBLIC template. The nonce is used to provide additional
entropy in the key creation process of the EK. This is optional and only required if nondefault values are used. (The default values are defined in Table 1 and 2, section 2.1.5.)



EK Template
This is the NV Index handle of a TPMT_PUBLIC template. The EK Template allows thecredential provider to implement a proprietary template. This is optional and only required if

Revision 14

Published

TCG PUBLISHED

Page 14 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

non-default values are used. (The default values are defined in Table 1 and 2, section
2.1.5.)
The following steps describe the procedure to create the Endorsement Key corresponding to an EK
Credential:
1. Read the EK Nonce from the TPM NV memory, if present.
2. Read the EK Template from the TPM NV memory, if present.
3. If an EK Template was read from the TPM NV memory, use it as the public area template,otherwise use the default public area template defined in Table 1 and 2, section 2.1.5.
4. If the EK Nonce was read from the TPM NV memory, insert it into the unique field of the
public area template, ignoring the length field of the EK Nonce, and padding the rest of theunique field with zeros. Otherwise, leave the unique field from step 3 as it is.
5. Create the EK using the public area template so prepared in the command
TPM2_CreatePrimary.
NOTE A platform-specific working group is allowed to define a proprietary default EK public area
template that can be used instead of the templates defined in Table 1 and 2.

2.2.2 Assertions
In general, an EK Credential asserts that the holder of the private EK is a TPM conforming to TCG
specifications. Since the EK Credential is a public key credential, then by definition the signature of
the issuer binds the public key material and the subject of the credential, which is a particular TPM
device.
More specifically, an EK Credential asserts:


Mandatory TPM specification compliance: The TPM device correctly implements theProtected Capabilities and Shielded Locations according to a particular version of the TPM
specification set, especially the protection of the private Endorsement Key (EK). The TPM
specification is described by family, level, and revision. The TPM device MUST be fully
described by the following three data items: TPM manufacturer, TPM part number, andTPM firmware version. The values are manufacturer-specific.

Optional TPM security assertions: The EK Credential MAY include assertions that it meetsvarious evaluation conformance criteria or that it was manufactured or initialized undercertain specified conditions.

To meet the assertion requirements listed above, an EK Credential MUST contain the following
information fields:EK public key
TPM spec version
TPM manufacturer, TPM part number, and TPM firmware version

The assertions in the EK Credential provide information about the TPM which may be useful for an
Attestation CA. The Attestation CA can verify whether the TPM conforms to a required TPM
specification version and validate other properties of the TPM implementation. Based on thisinformation, the CA may evaluate whether or not the TPM should receive an Attestation Key
Credential. However, this specification does not provide any guidelines for Attestation CAs how toevaluate the content of an EK certificate.

2.2.3 EK Credential Lifetime
An EK Credential contains fields that express the validity period of the credential. The validity
period is at the discretion of the manufacturer. The credential is not expected to expire during thenormal life expectancy of the platform in which it resides. The lifetime can vary widely between
different types of platforms (e.g. while a typical validity period for a PC Client platform is 5-10 years,

Revision 14

Published

TCG PUBLISHED

Page 15 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

non-user device TPMs are expected to operate indefinitely into the future in which case the value
99991231235959Z should be used as expiration date). The credential lifetime can also depend on
the lifetime of the TPM device and the algorithm type of the Endorsement Key. The time frame
during which the security strength of the EK is acceptable SHOULD be taken into account by the
manufacturer when determining the credential lifetime (e.g. see SP800-57[10]).
However, an EK Credential can become useless before expiration of the validity period if theassociated EK is irrevocably erased from the TPM. This is the case if the EPS is replaced (see2.1.4 EK Lifetime).
In TPM 1.2, the EK Credential was defined as an NV index that had the D bit set (see [7]). Thisway, the credential could not be deleted after the TPM has been locked. TPM 2.0 provides
equivalent functionality to define a permanent NV Index. In TPM 2.0, the NV Index attributes
TPMA_NV_PLATFORMCREATE and TPMA_NV_POLICY_DELETE (see TPM 2.0 LibrarySpecification, Part 2[1]) determine the authorization required to delete an NV Index.
TPMA_NV_PLATFORMCREATE indicates whether the NV Index was defined by the platform. If
SET, the index may only be undefined with Platform Authorization and not with Owner
Authorization. TPMA_NV_PLATFORMCREATE SHOULD be SET for an EK Credential to preventthe credential from being deleted if the Owner is cleared. Platform-defined NV indices in addition
can SET TPMA_NV_POLICY_DELETE.
If TPMA_NV_POLICY_DELETE is SET, the Index may not be deleted unless the authPolicy of the
NV Index is satisfied using the command TPM2_NV_UndefineSpaceSpecial. A platform that
requires a permanent EK Credential would not create a policy that allows the EK Credential to be
removed. On the other hand, a platform that wants to clear the EK Credential, e.g. during platform
refurbishment, could create a policy that includes the command TPM2_PolicyCommandCode
where the command code is set to TPM_CC_NV_UndefineSpaceSpecial.
The settings of the NV Index attributes are determined by Platform-specific specifications.
Definitions specific to PC Client can be found in PC Client Specific Platform TPM Profile for TPM
2.0[5], section Non-volatile Storage.

Revision 14

Published

TCG PUBLISHED

Page 16 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

2.3 Privacy Protection
In TPM 2.0, privacy-sensitive operations are controlled by the Privacy Administrator. The Privacy
Administrator controls the Endorsement hierarchy and sets the hierarchy authorization and policy(endorsementAuth and endorsementPolicy). The Privacy Administrator and the Owner are often thesame entity.
Because an Endorsement Key is unique to a TPM and usually has a long lifetime it could be used
to identify a user or a platform. Therefore, the EK and its certificate may be privacy-sensitive. The
following applies, if protection of privacy is important:The use of the EK SHOULD be limited, through policy, so that authorization from thePrivacy Administrator is always required. This can be enforced by using an authPolicy that
requires endorsementAuth or endorsementPolicy, authorization with authValue should bedisabled. This prevents the EK from being used without permission of the Privacy
Administrator.

The usage of the EK SHOULD be limited by its object attributes, so the EK can only beauthorized for specific commands. The EK SHOULD be defined as a non-duplicable
restricted decryption key. This prevents the EK from being used for signing operations.



The EK and EK certificate SHOULD NOT be considered public, and SHOULD be available
only to those entities which are trusted by the Privacy Administrator.

The availability of the EK can be controlled with the flag ehEnable. The purpose of the flag is toenable and disable the Endorsement hierarchy. When the Endorsement hierarchy is disabled(ehEnable CLEAR) objects defined under that hierarchy are inaccessible, endorsementAuth andendorsementPolicy cannot be used for authorization. It is not possible to use the EK in any
command or read the public EK with TPM2_ReadPublic. The ehEnable flag may be cleared withthe command TPM2_HierarchyControl using Endorsement Authorization or Platform Authorization.
Protection for the EK Credential can be provided by the flag phEnableNV if
TPMA_NV_PLATFORMCREATE is SET in the NV Index attributes of the EK Credential. This
attribute indicates whether the index was defined by the platform. When phEnableNV is CLEAR,
NV space defined by the platform firmware is not accessible, including the EK Credential. This flagcan only be cleared by Platform Authorization.

Revision 14

Published

TCG PUBLISHED

Page 17 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

3 X.509 ASN.1 Definitions
This section contains the format for the EK Credential instantiated as an X.509 certificate. All fields
are defined in ASN.1 and encoded using DER[18]. The appropriate OIDs are defined in section 5.
Version 3 of the X.509 certificate structure is used for compatibility with existing PKI tools andservices. TCG credential profiles do not utilize all aspects of X.509 defined fields and some fields
are overloaded with TCG specific interpretations. The following sections define TCG interpretations
for X.509 certificates.
TCG defines a number of new attribute value types to hold TCG-specific values. When present in a
public key certificate they are carried in the subject alternative name or subject directory attributes
extension.
This specification is a profile of RFC 5280[11] which is itself a profile of the ISO/IEC/ITU-T X.509
specifications for public key certificates. All syntax and semantics are inherited from thosespecifications unless explicitly documented otherwise below.

3.1 TCG Attributes
3.1.1 TPM Security Assertions
This attribute describes security-related assertions about the TPM.
Each attribute begins with a version number which identifies the version of the assertion syntax.
Future versions of this profile may add new assertions by appending new fields at the end of theASN.1 SEQUENCE and increasing the version number to identify which version of the assertion
syntax is encoded.
The fieldUpgradable BOOLEAN indicates whether the TPM is capable of having its firmware
upgraded after manufacturing.
The ekGenerationType indicates how the Endorsement Key in the TPM was created. It may beinternally generated within the TPM, generated externally and then inserted under a controlledenvironment during manufacturing. The revocable variants indicate whether the EK Credential canbe revoked or not.
In the CommonCriteriaMeasures, the profile and target for the evaluation can be described byeither an OID, a URI to a document describing the value, or both. If both are present, they must
represent consistent values. The URI values are included in an URIReference which describes
the URI to the document and a cryptographic hash value which identifies a specific version of the
document.
URIMAX is a constant used to provide an upper bound on the length of a URI included in thecertificate. This upper bound may be helpful to consumers of the extension and also helps limit theoverall size of the certificate. In order to provide a reasonable upper bound for ASN.1 parsers,
URIMAX SHOULD NOT exceed a value of 1024. This value was selected as it matches the length
limit for <A> anchors in HTML as specified by the SGML declaration (LITLEN) for HTML[17].
STRMAX is a constant defining the upper bound on the length of a string type. Like the URIMAX
this is to aid ASN.1 parsers and help limit the upper bound on the length of the certificate. Based on
the expected sizes of the strings in the ASN.1 in this document an upper bound of 256 wasselected. STRMAX SHOULD NOT exceed a value of 256.
Version ::= INTEGER { v1(0) }tPMSecurityAssertions ATTRIBUTE ::= {WITH SYNTAX TPMSecurityAssertions

Revision 14

Published

TCG PUBLISHED

Page 18 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

ID tcg—at-tpmSecurityAssertions }TPMSecurityAssertions ::= SEQUENCE {version Version DEFAULT v1,
fieldUpgradable BOOLEAN DEFAULT FALSE,
ekGenerationType [0] IMPLICIT EKGenerationType OPTIONAL,
ekGenerationLocation [1] IMPLICIT EKGenerationLocation OPTIONAL,
ekCertificateGenerationLocation [2] IMPLICIT
EKCertificateGenerationLocation OPTIONAL,
ccInfo [3] IMPLICIT CommonCriteriaMeasures OPTIONAL,
fipsLevel [4] IMPLICIT FIPSLevel OPTIONAL,
iso9000Certified [5] IMPLICIT BOOLEAN DEFAULT FALSE,
iso9000Uri IA5STRING (SIZE (1..URIMAX) OPTIONAL }EKGenerationType ::= ENUMERATED {internal (0),injected (1),internalRevocable(2),injectedRevocable(3) }EKGenerationLocation ::= ENUMERATED {tpmManufacturer (0),platformManufacturer (1),ekCertSigner (2) }EKCertificateGenerationLocation ::= ENUMERATED {tpmManufacturer (0),platformManufacturer (1),ekCertSigner (2) }-- common criteria evaluation

CommonCriteriaMeasures ::= SEQUENCE {version IA5STRING (SIZE (1..STRMAX)), -- “2.2” or “3.1”; future syntax definedby CC
assurancelevel EvaluationAssuranceLevel,
evaluationStatus EvalutionStatus,
plus BOOLEAN DEFAULT FALSE,
strengthOfFunction [0] IMPLICIT StrengthOfFunction OPTIONAL,
profileOid [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
profileUri [2] IMPLICIT URIReference
OPTIONAL,
targetOid [3] IMPLICIT OBJECT IDENTIFIER OPTIONAL,

Revision 14

Published

TCG PUBLISHED

Page 19 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

targetUri [4] IMPLICIT URIReference OPTIONAL }EvaluationAssuranceLevel ::= ENUMERATED {levell (1),level2 (2),level3 (3),level4 (4),level5 (5),level6 (6),level7 (7) }StrengthOfFunction ::= ENUMERATED {basic (0),medium (1),high (2) }-- Reference to external document containing information relevant to this subject.
-- The hashAlgorithm and hashValue MUST both exist in each reference if either-- appear at all.
URIReference ::= SEQUENCE {uniformResourceIdentifier IA5String (SIZE (1..URIMAX),
hashAlgorithm AlgorithmIdentifier OPTIONAL,
hashValue BIT STRING OPTIONAL }EvaluationStatus ::= ENUMERATED {designedToMeet (0),evaluationInProgress (1),evaluationCompleted (2) }-- fips evaluation

FIPSLevel ::= SEQUENCE {version IA5STRING (SIZE (1..STRMAX)), -- “140-1” or “140-2”
level SecurityLevel,plus BOOLEAN DEFAULT FALSE }SecurityLevel ::= ENUMERATED {level1 (1),level2 (2),level3 (3),level4 (4) }Revision 14

Published

TCG PUBLISHED

Page 20 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

3.1.2 TPM Device Attributes
The following definitions define the syntax of the relative distinguished names (RDNs) used in thesubject alternative name extension to identify the type of the TPM.
The value of the TPMManufacturer attribute MUST be the ASCII representation of thehexadecimal value of the 4 byte vendor identifier defined in the TCG Vendor ID Registry[3]. Eachbyte is represented individually as a two digit unsigned hexadecimal number using the characters
0-9 and A-F. The result is concatenated together to form an 8 character name which is appended
after the lower-case ASCII characters “id:”.
For example, the vendorId 0x12 0x34 0x56 0xEF would be encoded as “id:123456EF”.
Likewise, the value of the TPMVersion attribute MUST be the ASCII representation of thehexadecimal value of the 4 bytes derived from the major and minor firmware version of the TPM.
Each byte is represented individually as a two digit unsigned hexadecimal number using thecharacters 0-9 and A-F. The result is concatenated together to form a 8 character name which isappended after the lower-case ASCII characters “id:”.
For example, a revMajor of 0x0002 and revMinor of 0x0008 would be encoded as “id:00020008”.
The value of the TPMModel attribute is a UTF 8 string that represents the TPM part number. The
values are manufacturer-specific.
TPMManufacturer ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-tpmManufacturer }TPMModel ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-tpmModel }TPMVersion ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-tpmVersion }3.1.3 TPM Specification Attributes
The following definitions define the syntax of the TPM specification attributes.
The TPMSpecification attribute identifies the TPM family, level and revision of the TPM
specification with which a TPM implementation is compliant. The family value of “2.0” with level 0
and revision 99 identifies a TPM compliant with a public TPM 2.0 specification version 0.99
published by TCG. The family value is encoded in a UTF 8 string but the current defined standard
values fall within the ASCII character set.
tPMSpecification ATTRIBUTE ::= {WITH SYNTAX TPMSpecification
ID tcg-at-tpmSpecification }TPMSpecification ::= SEQUENCE {family UTF8String (SIZE (1..STRMAX)),level INTEGER,
revision INTEGER }Revision 14

Published

TCG PUBLISHED

Page 21 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

3.2 EK Certificate
This section contains the format for a TPM 2.0 EK Credential conforming to this specification. An
X.509 EK certificate is an instantiation of the TPM EK Credential defined in section 2.2.
The “Field Status” column in the table below specifies the presence of the certificate fields. The
value “Standard” means the field is an inherent component of the standard certificate syntax and is
not optional. The value “MUST”, “SHOULD” or “MAY” is used to indicate the presence of thecertificate extensions. The content is described in the “Value” column. Values marked with“(optional)” are added for completeness and are meant to be optional.
NOTE This specification does not preclude the use of other certificate extensions. However, any
extensions marked as critical will cause interoperability problems when existing clients do not know
how to parse the extension and reject it as specified in RFC 5280[11], section 4.2. (This has
historically been a challenge when introducing new critical extensions.)
Field Name

RFC 5280 Type

Value

Field Status

VersionINTEGERV3 (encoded as value 2)Standard

Serial Number

INTEGER

Positive integer

Standard

Signature Algorithm

AlgorithmIdentifier

sha256WithRSAEncryption
or ecdsa-with-SHA256

Standard

IssuerName

Name of issuing CA

Standard

Validity

notBefore
notAfter

Beginning and end ofvalidity period

Standard

Subject

Name

Unique name assigned by
the manufacturer
or empty

Standard

Subject Public Key
Info

SubjectPublicKeyInfo

RSA 2048 bit key
rsaEncryption
or ECC NISTP-256 bit key
id-ecPublicKeyStandard

Certificate Policies

CertificatePolicies

CertPolicyId
CPSuri (optional)
UserNotice (optional)

MUST
non-critical

Subject Alternative
Name

GeneralName
directoryName

TPM manufacturer
TPM part number
TPM firmware version
TPM serial nr (optional)

MUST
critical/ noncritical(dep. on subject)

Basic Constraints

BasicConstraints

CA=FALSE

MUST
critical

Extensions

Revision 14

Published

TCG PUBLISHED

Page 22 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

Field Name

RFC 5280 Type

Value

Field Status

Subject Directory
Attributes

SubjectDirectoryAttrib
utes

TPMSpecification
FamilyLevel
Revision
TPMSecurityAssertions(optional)

MUST
non-critical

Authority Key Id

AuthorityKeyIdentifier

Key identifier
Issuer name and serial
number (optional)

MUST
non-critical

Authority Info Access

AuthorityInfoAccessSy
ntax

id-ad-caIssuers
URI to issuing CA
id-ad-ocsp (optional)
URI to OCSP responder

SHOULD
non-critical

CRL Distribution

CRLDistributionPoints

URI to CRL

MAY
non-critical

Key Usage

KeyUsage

keyEncipherment
or keyAgreement
or digitalSignature

MUST
critical

Extended Key Usage

ExtKeyUsageSyntax

tcg-kp-EKCertificate

SHOULD
non-critical

Subject Key Id

SubjectKeyIdentifier

Key identifier

MAY

Table 3: EK Certificate Fields

3.2.1 Version
This field describes the version of the X.509 certificate. Since EK certificates contain mandatory
extensions the version number MUST be set to 3 (which is encoded as the value 2 in ASN.1).

3.2.2 Serial Number
The serial number MUST be a positive integer which is uniquely assigned to each EK certificate by
the issuer. The combination of an issuer’s DN and the serial number MUST uniquely describe asingle certificate.

3.2.3 Signature Algorithm
This field identifies the algorithm used by the EK certificate issuer to sign the certificate. The
certificate SHOULD be signed using an RSA 2048 bit key or ECC NISTP-256 bit key.
When using an RSA key the EK certificate SHOULD be signed using the algorithm
sha256WithRSAEncryption which has the OID value defined in RFC 5754[12] as shown below. The
AlgorithmIdentifier parameters field MUST be the ASN.1 type NULL.
sha256WithRSAEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 }When using an ECC key the EK certificate SHOULD be signed using the algorithm ecdsa-withSHA256 which has the OID value defined in RFC 5754[12] as shown below. The AlgorithmIdentifierparameters field MUST be the ASN.1 type NULL.

Revision 14

Published

TCG PUBLISHED

Page 23 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }If an ECC curve different than the recommended NISTP-256 is used as the signing key, thesecurity strength of the signing algorithm SHOULD be adapted to be equivalent to the security
strength of the signing key (e.g. ecdsa-with-SHA384 for NISTP-384 or ecdsa-with-SHA512 for
NISTP-521).
NOTE If a certificate issuer wishes to sign a certificate of one type with a key of another type (i.e.
sign an RSA certificate with ECDSA or an ECC certificate with RSA), they should take care ofexisting patents in order to avoid licensing issues.

3.2.4 Issuer
This field contains the distinguished name of the certificate issuer which is the entity that vouches
that the TPM is genuine and complies with the TPM 2.0 Library Specification[1].

3.2.5 Validity
The period when the certificate is valid is represented by two date values named notBefore andnotAfter. Issuers SHOULD assign notBefore to the current time when the EK certificate is issued
and notAfter to the last date that the certificate will be considered valid. Both notBefore and notAfter
MUST use the appropriate time format as indicated by RFC 5280[11]. (See also section 2.2.3 EK
Credential Lifetime)

3.2.6 Subject
The subject field MUST contain an X.500 distinguished name (DN) that uniquely identifies the TPM
or, if unique identification through the subject field is not required, MUST be empty.
If the subject name field is empty, the subject alternative name extension MUST be critical inaccordance with RFC 5280[11], otherwise it SHOULD be non-critical.

3.2.7 Subject Public Key Info
This describes the public Endorsement Key algorithm and key value. The public key SHOULD be
an RSA 2048 bit key or ECC NISTP-256 bit key.
For an RSA public key the algorithm rsaEncryption which has the OID value defined in RFC
3279[13] as shown below MUST be used. The AlgorithmIdentifier parameters field MUST be theASN.1 type NULL.
rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey as defined in RFC
3279[13].
RSAPublicKey ::= SEQUENCE {modulusINTEGER,publicExponent
INTEGER }

-- n
-- e

For an ECC public key the algorithm id-ecPublicKey which has the OID value defined in RFC
5480[14] as shown below MUST be used. The ECParameters field is required, the nameCurve field
SHOULD contain the OID secp256r1 (NISTP-256 curve).
id-ecPublicKey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }Revision 14

Published

TCG PUBLISHED

Page 24 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

ECParameters ::= CHOICE {namedCurveOBJECT IDENTIFIER-- implicitCurve
NULL-- specifiedCurve SpecifiedECDomain}
secp256r1 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }If an ECC curve different than the recommended NISTP-256 is used as the subject public key, theappropriate OID defined for that ECC curve MUST be used.
The ECC public key MUST be encoded as an ECC Point. The uncompressed Format SHOULD be
used.
ECPoint ::= OCTET STRING

3.2.8 Certificate Policies
This indicates the policy terms under which the certificate was issued. PolicyIdentifier MUST haveat least one object identifier. Policy qualifiers are optional. The cPSuri policy qualifier MAY containthe value of an HTTP URL at which a plain language version of the issuer's certificate policy may
be obtained. The userNotice policy qualifer MAY contain an explicitText. This extension SHOULD
be non-critical.

3.2.9 Subject Alternative Name
This contains the alternative name of the entity associated with this certificate. The issuer MUST
include TPM manufacturer, TPM part number and TPM firmware version, using the directoryNameform within the GeneralName structure. The ASN.1 encoding is specified in section 3.1.2 TPM
Device Attributes. In accordance with RFC 5280[11], this extension MUST be critical if subject isempty and SHOULD be non-critical if subject is non-empty.


The TPM manufacturer identifies the manufacturer of the TPM. This value MUST be thevendor ID defined in the TCG Vendor ID Registry[3] . It MUST match the value reported by
the command TPM2_GetCapability(property = TPM_PT_MANUFACTURER).

The TPM part number is encoded as a string and is manufacturer-specific. A manufacturer
MUST provide a way to the user to retrieve the part number physically or logically. This
information could be e.g. provided as part of the vendor string in the command
TPM2_GetCapability(property = TPM_PT_VENDOR_STRING_x; x=1…4).



The TPM firmware version is a manufacturer-specific implementation version of the TPM.
This value SHOULD match the version reported by the command TPM2_GetCapability(property = TPM_PT_FIRMWARE_VERSION_1).

NOTE This representation of subject alternative name is maintained to provide consistency with
TPM 1.2.
In addition, TPM 2.0 allows the inclusion of an optional attribute that contains the TPM serial
number. The issuer MAY include HardwareModuleName as defined in RFC 4108[15] using theotherName-form within the GeneralName structure. HardwareModuleName is intended to facilitate
establishment of Initial Device Identifier (IDevID) Credentials that are compliant to the IWG
document TPM Keys for Platform Identity[7] (at time of writing, only available for TPM 1.2) which
include the same HardwareModuleName attribute. This enables a platform manufacture to replicate
the certified TPM serial number from the EK Credential to the IDevID Credential. Alternatively, theunique serial number could also be stored in the subject field.


The TPM serial number is a manufacturer-specific unique chip identification number. If
present, the manufacturer SHOULD implement an NV index that allows the user to retrieve
the serial number from the TPM.

Revision 14

Published

TCG PUBLISHED

Page 25 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

NOTE The TPM serial number usually includes detailed production parameters. Since that might
be revealing information that the manufacturer doesn’t want to disclose the hash of the TPM serial
number could be used instead.
The HardwareModuleName attribute as defined in RFC 4108[15] is shown below. The hwType field
MUST contain the TCG registered OID (2.23.133.1.2) that represents the hwType for TPM 2.0. The
hwSerialNum field MUST contain the TPM serial number.
id-on-hardwareModuleName OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6) internet(1) security(5)mechanisms(5) pkix(7) on(8) 4 }HardwareModuleName ::= SEQUENCE {hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }3.2.10 Basic Constraints
This indicates whether the subject is a CA. “CA” MUST be set to FALSE. This extension MUST be
critical.

3.2.11 Subject Directory Attributes
The extension includes miscellaneous properties and security assertions about the entity. Thisextension MUST be non-critical.
The following attribute MUST be included in a subject directory attributes extension in the EK
certificate:The “TPM Specification” attribute which identifies the family, level and revision of the TCG
TPM specification to which the TPM was designed. The ASN.1 encoding is specified in
section 3.1.3 TPM Specification Attributes.

The following attribute MAY be included in a subject directory attributes extension in the EK
certificate:The “TPM Security Assertions” attribute which describes various assertions about the
security properties of the TPM and the conditions under which the Endorsement Key was
generated. The ASN.1 encoding is specified in section 3.1.1 TPM Security Assertions.

3.2.12 Authority Key IdentifierThis identifies the subject public key of the certificate issuer and hence facilitates the validation of
the certificate path. The certificate MUST contain an authority key identifier that matches the
subject key identifier of the CA certificate. The issuer name and the serial number are optional. Thisextension MUST be non-critical.

3.2.13 Authority Information AccessThis provides additional information about the issuer. Authority Information Access SHOULD
contain the accessMethod OID id-ad-caIssuers and MAY additionally contain the OID id-ad-ocsp.
This extension MUST be non-critical.
If id-ad-caIssuers appears as accessMethod, then the accessLocation value SHOULD point to the
URL where the certificate of the issuing CA can be retrieved.
If id-ac-ocsp appears as accessMethod, then the accessLocation value SHOULD point to theaccess value of the OCSP responder (HTTP URI). The relying party can access the certificate
status for this certificate by sending a properly formatted OCSPRequest to the URI. If both a CDP
and OCSP AIA extension are present in the certificate, then the relying parties SHOULD use OCSP
as the primary validation mechanism.

Revision 14

Published

TCG PUBLISHED

Page 26 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

3.2.14 CRL Distribution
This extension is optional and provides the location of the subject’s revocation information. The
relying party can access the CRL for this certificate from this URI. If both a CDP and OCSP AIA
extension are present in the certificate, then relying parties SHOULD use OCSP as the primaryvalidation mechanism. This extension MUST be non-critical.

3.2.15 Key Usage
This extension indicates the intended purpose of the subject public key. This extension MUST be
critical.
If the EK has the decrypt attribute set, the keyEncipherment bit MUST be set for an RSA EK
certificate; the keyAgreement bit MUST be set for an ECC EK certificate.
If the EK has the sign attribute set, the digitalSignature bit MUST be set.

3.2.16 Extended Key Usage
This extension indicates the intended purpose of the subject public key. Extended key usage
SHOULD contain the OID tcg-kp-EKCertificate defined in section 5 of this document as shown
below. The OID is used to unambiguously identify the certificate as an EK certificate. This extension
MUST be non-critical.
tcg-kp-EKCertificate OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) international-organizations(23) tcg(133) kp(8) 1}

NOTE If the issuing CA is used exclusively to issue EK certificates, it is recommended to equally
include the OID tcg-kp-EKCertificate in the issuing CA certificate. This ensures that the use of the
CA is limited to that particular purpose. If the issuing CA issues certificates for multiple known
purposes, then the set of relevant EKU OIDs could be included in the issuing CA certificate.

3.2.17 Subject Key IdentifierThis identifies the public key of the certificate. This extension MAY be included in EK certificates.

Revision 14

Published

TCG PUBLISHED

Page 27 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

4 Changes from Previous Versions
This chapter provides a summary of significant changes from the TCG Credential Profile
specification V1.2[4].
Former versions of the Credential Profile specification defined three different credential
types. The Endorsement Key (EK) Credential, the Attestation Identity Key (AIK) Credential,
and the Platform Endorsement (Platform) Credential. This document specifies only theEndorsement Key Credential for TPM 2.0.
In TPM 1.2, the Endorsement Key was defined as a single, RSA 2048 bit key. Further, it
was required to be a decryption key. TPM 2.0 can have more than one EK, and supports
different asymmetric key types. An EK can be created as a decryption or signing key.
Due to the increased number of possible EKs, TPM 2.0 allows EK Credentials to be stored
in an external device. In addition to the handle for the EK certificate, there might beauxiliary handles for a nonce and a public area template (that indicate how the key
associated to the certificate is generated).

Changes related to certificate fields:
 Signature algorithm: TPM 1.2 used sha-1WithRSAEncrytion. This is changed tosha256WithRSAEncryption for TPM 2.0 since the use of SHA-1 for the generation of digital
signatures is considered as too weak (see [10]).
 Subject: In TPM 1.2, subject was required to be empty. In TPM 2.0, it can either contain adistinguished name or be empty. This change accommodates the request for a field that
could contain a unique identifier.
 Subject public key info: TPM 1.2 used OID id-RSAES-OAEP where the octect string for the“pSourceFunc” parameter was “TCPA”. This is changed to OID rsaEncryption for TPM 2.0
since the uncommon OID used in TPM 1.2 could not be processed by most of the standard
libraries.
 Certificate policies: In TPM 1.2, the CPS qualifier (URL point at plain text version of thecertificate policy) and the UserNotice qualifier (text with “TCPA Trusted Platform Module
Endorsement”) were mandatory. In TPM 2.0, both policy qualifiers are changed to be
optional because the RFC 5280[11] recommends that the extension consist of only an OID
to promote interoperability. The extension is changed to be non-critical for TPM 2.0.
 Subject alternative name: This extension was required to be critical in TPM 1.2. In TPM 2.0,
it is either critical or non-critical dependent on the presence of the subject field which is inaccordance to RFC 5280[11].
 Subject alternative name – TPM firmware version: The attribute is increased to contain four
bytes to match the version number implemented in TPM 2.0.
 Subject alternative name – TPM serial number: TPM 2.0 allows the inclusion of the
HardwareModuleName attribute which includes the TPM serial number.
 Subject directory attributes – supported algorithms: The attribute is removed for TPM 2.0.
While TPM 1.2 was constrained to RSA and SHA-1, TPM 2.0 is able support many different
algorithms. That would result in a too complex list and is therefore dropped.
 Authority information access: In TPM 1.2, accessMethod was only allowed to be id-adocsp. This is changed to allow either id-ad-ocsp or id-ad-caIssuers for TPM 2.0. The URL
provided with id-ad-caIssuers is useful to retrieve the issuing CA certificate.
 Key usage: Empty in TPM 1.2. Since in TPM 2.0 the subject public key info is changed tocontain the generic OID rsaEncryption, the key usage extension is used to indicate thepurpose of the key.
 Extended key usage: Empty in TPM 1.2. TPM 2.0 recommends using tcg-kp-EKCertificate.
This OID unambiguously identifies the certificate as an EK certificate.
 The certificate field definitions were expanded to cover ECC.

Revision 14

Published

TCG PUBLISHED

Page 28 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

5 X.509 ASN.1 Structures and OIDs
TCG has registered an object identifier (OID) namespace as an “international body” in the ISO
registration hierarchy. This leads to shorter OIDs and gives TCG the ability to manage its own
namespace. The OID namespace is inherited from TCPA. These definitions are intended to be
used within the context of an X.509 v3 certificate specifically leveraging the profile described in
RFC 5280[11].
-- TCG specific OIDs
tcg OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) international-organizations(23) tcg(133) }tcg-tcpaSpecVersion OBJECT IDENTIFIER ::= {tcg 1}
tcg-attribute OBJECT IDENTIFIER ::= {tcg 2}
tcg-protocol OBJECT IDENTIFIER ::= {tcg 3}
tcg-algorithm OBJECT IDENTIFIER ::= {tcg 4}
tcg-ce OBJECT IDENTIFIER ::= {tcg 6}
tcg-kp OBJECT IDENTIFIER ::= {tcg 8}-- TCG Spec Version OIDs
tcg-sv-tpm12 OBJECT IDENTIFIER ::= { tcg-tcpaSpecVersion 1}
tcg-sv-tpm20 OBJECT IDENTIFIER ::= { tcg-tcpaSpecVersion 2}-- TCG Attribute OIDs
tcg-at-tpmManufacturer OBJECT IDENTIFIER ::= {tcg-attribute 1}
tcg-at-tpmModel OBJECT IDENTIFIER ::= {tcg-attribute 2}
tcg-at-tpmVersion OBJECT IDENTIFIER ::= {tcg-attribute 3}
tcg-at-platformManufacturer OBJECT IDENTIFIER ::= {tcg-attribute 4}
tcg-at-platformModel OBJECT IDENTIFIER ::= {tcg-attribute 5}
tcg-at-platformVersion OBJECT IDENTIFIER ::= {tcg-attribute 6}
tcg-at-securityQualities OBJECT IDENTIFIER ::= {tcg-attribute 10}
tcg-at-tpmProtectionProfile OBJECT IDENTIFIER ::= {tcg-attribute 11}
tcg-at-tpmSecurityTarget OBJECT IDENTIFIER ::= {tcg-attribute 12}
tcg-at-tbbProtectionProfile OBJECT IDENTIFIER ::= {tcg-attribute 13}
tcg-at-tbbSecurityTarget OBJECT IDENTIFIER ::= {tcg-attribute 14}
tcg-at-tpmIdLabel OBJECT IDENTIFIER ::= {tcg-attribute 15}
tcg-at-tpmSpecification OBJECT IDENTIFIER ::= {tcg-attribute 16}
tcg-at-tcgPlatformSpecification OBJECT IDENTIFIER ::= {tcg-attribute 17}
tcg-at-tpmSecurityAssertions OBJECT IDENTIFIER ::= {tcg-attribute 18}
tcg-at-tbbSecurityAssertions OBJECT IDENTIFIER ::= {tcg-attribute 19}-- TCG Algorithm OIDs
tcg-algorithm-null OBJECT IDENTIFIER ::= {tcg-algorithm 1}-- TCG Key Purposes OIDs
tcg-kp-EKCertificate OBJECT IDENTIFIER ::= {tcg-kp 1}
tcg-kp-PlatformCertificate OBJECT IDENTIFIER ::= {tcg-kp 2}
tcg-kp-AIKCertificate OBJECT IDENTIFIER ::= {tcg-kp 3}-- TCG Certificate Extensions
tcg-ce-relevantCredentials OBJECT IDENTIFIER ::= {tcg-ce 2}
tcg-ce-relevantManifests OBJECT IDENTIFIER ::= {tcg-ce 3}
tcg-ce-virtualPlatformAttestationService OBJECT IDENTIFIER ::= {tcg-ce 4}
tcg-ce-migrationControllerAttestationService OBJECT IDENTIFIER ::= (tcg-ce 5}
tcg-ce-migrationControllerRegistrationService OBJECT IDENTIFIER ::= (tcg-ce 6}
tcg-ce-virtualPlatformBackupService OBJECT IDENTIFIER ::= (tcg-ce 7}-- TCG Protocol OIDs
tcg-prt-tpmIdProtocol OBJECT IDENTIFIER ::= {tcg-protocol 1}-- tcg specification attributes for tpm and platform

Revision 14

Published

TCG PUBLISHED

Page 29 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

tPMSpecification ATTRIBUTE ::= {WITH SYNTAX TPMSpecification
ID tcg-at-tpmSpecification }TPMSpecification ::= SEQUENCE {family UTF8String (SIZE (1..STRMAX)),level INTEGER,
revision INTEGER }tCGPlatformSpecification ATTRIBUTE ::= {WITH SYNTAX TCGPlatformSpecification
ID tcg-at-tcgPlatformSpecification }TCGSpecificationVersion ::= SEQUENCE {majorVersion INTEGER,
minorVersion INTEGER,
revision INTEGER }TCGPlatformSpecification ::= SEQUENCE {Version TCGSpecificationVersion,
platformClass OCTET STRING SIZE(4) }-- tcpa tpm specification attribute (deprecated)tCPASpecVersion ATTRIBUTE ::= {WITH SYNTAX TCPASpecVersion
ID tcg-tcpaSpecVersion }TCPASpecVersion ::= SEQUENCE {major INTEGER,
minor INTEGER }-- manufacturer implementation model and version attributes
TPMManufacturer ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-tpmManufacturer }TPMModel ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-tpmModel }TPMVersion ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-tpmVersion }PlatformManufacturer ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-platformManufacturer }PlatformModel ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-platformModel }PlatformVersion ATTRIBUTE ::= {WITH SYNTAX UTF8String (SIZE (1..STRMAX))
ID tcg-at-platformVersion }-- tpm and platform tbb security assertions
Version ::= INTEGER { v1(0) }Revision 14

Published

TCG PUBLISHED

Page 30 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

tPMSecurityAssertions ATTRIBUTE ::= {WITH SYNTAX TPMSecurityAssertions
ID tcg—at-tpmSecurityAssertions}
TPMSecurityAssertions ::= SEQUENCE {version Version DEFAULT v1,
fieldUpgradable BOOLEAN DEFAULT FALSE,
ekGenerationType [0] IMPLICIT EKGenerationType OPTIONAL,
ekGenerationLocation [1] IMPLICIT EKGenerationLocation OPTIONAL,
ekCertificateGenerationLocation [2] IMPLICIT
EKCertificateGenerationLocation OPTIONAL,
ccInfo [3] IMPLICIT CommonCriteriaMeasures OPTIONAL,
fipsLevel [4] IMPLICIT FIPSLevel OPTIONAL,
iso9000Certified [5] IMPLICIT BOOLEAN DEFAULT FALSE,
iso9000Uri IA5STRING (SIZE (1..URIMAX)) OPTIONAL }tBBSecurityAssertions ATTRIBUTE ::= {WITH SYNTAX TBBSecurityAssertions
ID tcg—at-tbbSecurityAssertions }TBBSecurityAssertions ::= SEQUENCE {version Version DEFAULT v1,
ccInfo [0] IMPLICIT CommonCriteriaMeasures OPTIONAL,
fipsLevel [1] IMPLICIT FIPSLevel OPTIONAL,
rtmType [2] IMPLICIT MeasurementRootType OPTIONAL,
iso9000Certified BOOLEAN DEFAULT FALSE,
iso9000Uri IA5STRING (SIZE (1..URIMAX)) OPTIONAL }EKGenerationType ::= ENUMERATED {internal (0),injected (1),internalRevocable(2),injectedRevocable(3) }EKGenerationLocation ::= ENUMERATED {tpmManufacturer (0),platformManufacturer (1),ekCertSigner (2) }EKCertificateGenerationLocation ::= ENUMERATED {tpmManufacturer (0),platformManufacturer (1),ekCertSigner (2) }-- V1.1 of this specification adds hybrid and physical.
-- Hybrid means the measurement root is capable of static AND dynamic-- Physical means that the root is anchored by a physical TPM-- Virtual means the TPM is virtualized (possibly running in a VMM)-- TPMs or RTMs might leverage other lower layer RTMs to virtualize the-- the capabilities of the platform.
MeasurementRootType ::= ENUMERATED {static (0),dynamic (1),nonHost (2),hybrid (3),physical (4),virtual (5) }Revision 14

Published

TCG PUBLISHED

Page 31 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0-- common criteria evaluation
CommonCriteriaMeasures ::= SEQUENCE {version IA5STRING (SIZE (1..STRMAX)), -- “2.2” or “3.1”; future syntax definedby CC
assurancelevel EvaluationAssuranceLevel,
evaluationStatus EvalutionStatus,
plus BOOLEAN DEFAULT FALSE,
strengthOfFunction [0] IMPLICIT StrengthOfFunction OPTIONAL,
profileOid [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
profileUri [2] IMPLICIT URIReference OPTIONAL,
targetOid [3] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
targetUri [4] IMPLICIT URIReference OPTIONAL }EvaluationAssuranceLevel ::= ENUMERATED {levell (1),level2 (2),level3 (3),level4 (4),level5 (5),level6 (6),level7 (7) }StrengthOfFunction ::= ENUMERATED {basic (0),medium (1),high (2) }URIReference ::= SEQUENCE {uniformResourceIdentifier IA5String (SIZE (1..URIMAX)),
hashAlgorithm AlgorithmIdentifier OPTIONAL,
hashValue BIT STRING OPTIONAL }EvaluationStatus ::= ENUMERATED {designedToMeet (0),evaluationInProgress (1),evaluationCompleted (2) }-- fips evaluation
FIPSLevel ::= SEQUENCE {version IA5STRING (SIZE (1..STRMAX)), -- “140-1” or “140-2”
level SecurityLevel,plus BOOLEAN DEFAULT FALSE }SecurityLevel ::= ENUMERATED {level1 (1),level2 (2),level3 (3),level4 (4) }-- aik certificate label from tpm owner

TPMIdLabel OTHER-NAME ::= {UTF8String IDENTIFIED BY {tcg-at-tpmIdLabel} }-- the following are deprecated but may be present for compatibility with TCPA
TPMProtectionProfile ATTRIBUTE ::= {WITH SYNTAX ProtectionProfile
ID tcg-at-tpmProtectionProfile }TPMSecurityTarget ATTRIBUTE ::= {WITH SYNTAX SecurityTarget
ID tcg-at-tpmSecurityTarget }Revision 14

Published

TCG PUBLISHED

Page 32 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

TBBProtectionProfile ATTRIBUTE ::= {WITH SYNTAX ProtectionProfile
ID tcg-at-tbbProtectionProfile }TBBSecurityTarget ATTRIBUTE ::= {WITH SYNTAX SecurityTarget
ID tcg-at-tbbSecurityTarget }ProtectionProfile ::= OBJECT IDENTIFIER
SecurityTarget ::= OBJECT IDENTIFIER-- V1.1 addition for enabling references to other credentials or-- XML-based Reference Manifests. These data objects are included-- in X.509 extensions using the new tcg-ce-[relevantCredentials,-- relevantManifests] OIDs.
HashAlgAndValue ::= SEQUENCE {hashAlg
AlgorithmIdentifier,hashValue
OCTET STRING }HashedSubjectInfoURI ::= SEQUENCE {documentURI IA5String (SIZE (1..URIMAX)),documentAccessInfo OBJECT IDENTIFIER OPTIONAL,
documentHashInfo HashAlgAndValue OPTIONAL }SubjectInfoURIList ::=SEQUENCE SIZE (1..REFMAX) OF HashedSubjectInfoURI
TCGRelevantCredentials::=
SEQUENCE SIZE (1..REFMAX) OF HashedSubjectInfoURI
TCGRelevantManifests::=
SEQUENCE SIZE (1..REFMAX) OF HashedSubjectInfoURI-- V1.2 addition of virtualization oriented credential extensions. This extension
indicates how a remote challenger can contact the (deep) attestation service below
the current credential holder in order to attest the layer below. Using this modelallows the credential of each virtualization layer to reference the attestation
service for the layer below it.
A remote challenger could traverse the layer
hierarchy using this extension until reaching the physical trusted platform rooted
attestation.
The following URI is optionally included in a certificate for a
virtualmachineassociatedwiththetcg-ce-virtualPlatformAttestationService
extension
OID.
These
URI
are
associatedwiththetcg-ce[virtualPlatformAttestationService,
migrationControllerAttestationService,
migrationControllerRegistrationService,virtualPlatformBackupService]
OIDs
respectively:
VirtualPlatformAttestationServiceURI ::= IA5String (SIZE (1..URIMAX)
MigrationControllerAttestationServiceURI ::= IA5String (SIZE (1..URIMAX)
MigrationControllerRegistrationServiceURI ::= IA5String (SIZE (1..URIMAX)
VirtualPlatformBackupServiceURI ::= SEQUENCE {restoreAllowed BOOLEAN DEFAULT FALSE,
backupServiceURI
IA5String }Revision 14

Published

TCG PUBLISHED

Page 33 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

6 References
For dated references, only the edition cited applies. For undated references, the latest edition of thereferenced document (including any amendments) applies.
[1]

TPM 2.0 Library Specification:
http://www.trustedcomputinggroup.org/resources/tpm_library_specification[2]

Registry of Reserved TPM 2.0 Handles and Localities:
http://www.trustedcomputinggroup.org/resources/registry[3]

Vendor ID Registry:
http://www.trustedcomputinggroup.org/resources/vendor_id_registry[4]

TCG Credential Profile Version 1.0, Version 1.1 and Version 1.2:
http://www.trustedcomputinggroup.org/resources/infrastructure_work_group_tcg_credential_profiles_specification[5]

PC Client Specific Platform TPM Profile for TPM 2.0:
http://www.trustedcomputinggroup.org/developers/pc_client[6]

CMC Profile for EK/Platform Certificate Enrollment for TPM 1.2:
http://www.trustedcomputinggroup.org/developers/infrastructure[7]

TPM Keys for Platform Identity for TPM 1.2:
http://www.trustedcomputinggroup.org/developers/infrastructure[8]

TPM 1.2 Main Specification:
http://www.trustedcomputinggroup.org/resources/tpm_main_specification[9]

IEEE Standard for Local and metropolitan area networks, Secure Device Identity, 2009[10]

NIST Special Publication 800-57, Recommendation for Key Management – Part 1: General[11]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile, RFC 5280, http://www.ietf.org/rfc/rfc5280.txt[12]

Using SHA2 Algorithms with Cryptographic Message Syntax, RFC 5754,
http://www.ietf.org/rfc/rfc5754.txt[13]

Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile, RFC 3279, http://www.ietf.org/rfc/rfc3279.txt[14]

Elliptic Curve Cryptography Subject Public Key Information, RFC 5480,
http://www.ietf.org/rfc/rfc5480.txt[15]

Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages, RFC 4108,
http://www.ietf.org/rfc/rfc4108.txt[16]

Key words for use in RFCs to Indicate Requirement Levels, RFC 2119,
http://www.ietf.org/rfc/rfc2119.txt[17]

Hypertext Markup Language – 2.0, RFC 1866, http://www.ietf.org/rfc/rfc1866.txt[18]

ITU-T X.690: Information technology – ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
Rules (DER)

Revision 14

Published

TCG PUBLISHED

Page 34 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

A. Certificate Examples
A.1 Example 1 (user device TPM, e.g. PC-Client)
The following section provides an example for a standard, user device TPM (e.g. PC-Client)Endorsement Key certificate. The ASN.1 encoding for the subject alternative name and subject
directory attributes extension is provided below. The values used in this example are for illustrative
purpose and must be replaced with manufacturer-specific data.
Subject alternative name:
TPMManufacturer = id:54534700 (TCG)
TPMModel = ABCDEF123456 (part number)
TPMVersion = id:00010023 (firmware version)// SEQUENCE
30 49// SET
31 16// SEQUENCE
30 14// OBJECT IDENTIFER tcg-at-tpmManufacturer (2.23.133.2.1)
06 05 67 81 05 02 01// UTF8 STRING id:54434700 (TCG)
0C 0B 69 64 3A 35 34 34 33 34 37 30 30// SET
31 17// SEQUENCE
30 15// OBJECT IDENTIFER tcg-at-tpmModel (2.23.133.2.2)
06 05 67 81 05 02 02// UTF8 STRING ABCDEF123456
0C 0C 41 42 43 44 45 46 31 32 33 34 35 36// SET
31 16// SEQUENCE
30 14// OBJECT IDENTIFER tcg-at-tpmVersion (2.23.133.2.3)
06 05 67 81 05 02 03// UTF8 STRING id:00010023
0C 0B 69 64 3A 30 30 30 31 30 30 32 33

Subject directory attributes:
TPMSpecification
Family = id:322E3000 (2.0)
Level = 0
Revision = 99
TPMSecurityAssertions (not included here since optional)// SEQUENCE
30 1E// OBJECT IDENTIFIER tcg-at-tpmSpecification (2.23.133.2.16)
06 05 67 81 05 02 10// SET
31 15// SEQUENCE
30 13// UTF8 STRING (2.0)
0C 03 32 2E 30// INTEGER (0)02 01 00// INTEGER (99)02 01 63

Revision 14

Published

TCG PUBLISHED

Page 35 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

The encoding of the extensions above is extracted from the following example certificate. The
example certificate provided below is for illustrative propose only, all example values must be
replaced with manufacturer-specific data. For simplicity some optional configurations (e.g. optional
data within an extension) are omitted. The manufacturer’s certificate is not required to look exactly
the same as the example certificate. For better testing the certificate is provided in PEM format.
When read from the TPM the certificate is encoded in DER[18].
-----BEGIN CERTIFICATE----MIID7zCCAtegAwIBAgIBATANBgkqhkiG9w0BAQsFADAUMRIwEAYDVQQDDAlFeGFt
cGxlQ0EwHhcNMTQwMTE1MTU0MDUwWhcNMTUwMTE1MTU0MDUwWjAAMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAncvm0aOBK05rdNInYXzJGV5SFteVUFpt
XFxg4evROvlulB3BzUmFGQYFDcItVnJX2fAvf0UJLtLBVBQggb5ylL6bRpj72cS3
oyNbs0CGmix9Z1QDjkZZFvIsD1GcKO0tvsCvsEItH8Cm0fq8WcGFijWLdRD5eulP
55pq1bAHAvIo4+VLMJVBG71xrKGZeHPjKoq6seYjh7AGy+hk2vmFzpZ8Ghdgqv+K
02IZ7FEdzuylHW8U3qsxBHysMut4inj6AiVf467OOs5meHiifIK9MGkovMrfY9iX
uUVUs/KXpE1sgeoX9BLvx1BPcODosr5K+z5i71OtIXy4CXrPvcGzRwIDAQABo4IB
XjCCAVowQAYIKwYBBQUHAQEENDAyMDAGCCsGAQUFBzAChiRodHRwOi8vd3d3LmV4
YW1wbGUuY29tL0V4YW1wbGVDQS5jcnQwDgYDVR0PAQH/BAQDAgAgMFkGA1UdEQEB/wRPME2kSzBJMRYwFAYFZ4EFAgEMC2lkOjU0NDM0NzAwMRcwFQYFZ4EFAgIMDEFC
Q0RFRjEyMzQ1NjEWMBQGBWeBBQIDDAtpZDowMDAxMDAyMzAMBgNVHRMBAf8EAjAAMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly93d3cuZXhhbXBsZS5jb20vRXhhbXBs
ZUNBLmNybDAQBgNVHSAECTAHMAUGAyoDBDAfBgNVHSMEGDAWgBQ0d2ckTESv554q
4LJMaVeVJLM92jAQBgNVHSUECTAHBgVngQUIATAhBgNVHQkEGjAYMBYGBWeBBQIQ
MQ0wCwwDMi4wAgEAAgFjMA0GCSqGSIb3DQEBCwUAA4IBAQAba2btJ/+4z02MWpNp
99AFGpEu3yIaJqI6NeHvC6fxxe/9lWlHKISR+CnpAh03/MKT8TP2/cUSi0jjkQNh
MtueUNofE79fYXtHXHU7wzzUFWNwCmhTuHDYl3jmD0fJ9yA2CuUHT6q3UV+PwXN+
EHE1hQwC8QtNC/5A7wY1e5dBLdgwSSIgTc4lSsbNcZ9d+m7mWEWpumSYU0czTDEN
Hmdu/VJuDN/RCOAyBb+hc19LAucGmnFYOhxWHfd9zbXZA1ldFUxrpPuVfKx+Eo8f
rMsB2oZKMwSYUAWotqolhLe2wdBMRjdmVz44kIhuFB7y4BpQjlB1+xAzX9Hb31CG
eoS2-----END CERTIFICATE-----

Revision 14

Published

TCG PUBLISHED

Page 36 of 37

TCG EK Credential Profile

TCG Copyright 2014

Specification Version 2.0

A.2 Example 2 (non-user device TPM, e.g. DevID)
This second example certificate additionally includes the optional HardwareModuleName attributein the subject alternative name extension which includes the TPM serial number. The particular use
case for such an EK certificate is for non-user devices (e.g. switches, routers, and wireless accesspoints) that require an Device Identifier (DevID) Credential conforming to the IWG TPM Keys for
Platform Identity[7] specification. The values used in this example are for illustrative purpose andmust be replaced with manufacturer-specific data.
Subject alternative name:
HW type = TPM 2.0
TPM serial number = the string “tpmserialnumber”// OBJECT IDENTIFIER id-on-hardwareModuleName (1.3.6.1.5.5.7.8.4)
06 08 2B 06 01 05 05 07 08 04// CONTEXT SPECIFIC (0)A0 1A// SEQUENCE
30 18// OBJECT IDENTIFIER TPM2.0 (2.23.133.1.2)
06 05 67 81 05 01 00// OCTECT STRING tpmserialnumber
04 0F 74 70 6D 73 65 72 69 61 6C 6E 75 6D 62 65 72

The encoding of the extension above is extracted from the following example certificate. Same as
for the example certificate provided in A.1, it is provided for illustrative propose only, all example
values must be replaced with manufacturer-specific data. For simplicity some optional
configurations (e.g. optional data within an extension) are omitted. The manufacturer’s certificate is
not required to look exactly the same as the example certificate. For better testing the certificate isprovided in PEM format. When read from the TPM the certificate is encoded in DER[18].
-----BEGIN CERTIFICATE----MIIEGDCCAwCgAwIBAgIBATANBgkqhkiG9w0BAQsFADAUMRIwEAYDVQQDDAlFeGFt
cGxlQ0EwHhcNMTQwMTE1MTU0MDUwWhcNMTUwMTE1MTU0MDUwWjAAMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAncvm0aOBK05rdNInYXzJGV5SFteVUFpt
XFxg4evROvlulB3BzUmFGQYFDcItVnJX2fAvf0UJLtLBVBQggb5ylL6bRpj72cS3
oyNbs0CGmix9Z1QDjkZZFvIsD1GcKO0tvsCvsEItH8Cm0fq8WcGFijWLdRD5eulP
55pq1bAHAvIo4+VLMJVBG71xrKGZeHPjKoq6seYjh7AGy+hk2vmFzpZ8Ghdgqv+K
02IZ7FEdzuylHW8U3qsxBHysMut4inj6AiVf467OOs5meHiifIK9MGkovMrfY9iX
uUVUs/KXpE1sgeoX9BLvx1BPcODosr5K+z5i71OtIXy4CXrPvcGzRwIDAQABo4IB
hzCCAYMwQAYIKwYBBQUHAQEENDAyMDAGCCsGAQUFBzAChiRodHRwOi8vd3d3LmV4
YW1wbGUuY29tL0V4YW1wbGVDQS5jcnQwDgYDVR0PAQH/BAQDAgAgMIGBBgNVHREB
Af8EdzB1pEswSTEWMBQGBWeBBQIBDAtpZDo1NDQzNDcwMDEXMBUGBWeBBQICDAxB
QkNERUYxMjM0NTYxFjAUBgVngQUCAwwLaWQ6MDAwMTAwMjOgJgYIKwYBBQUHCASg
GjAYBgVngQUBAgQPdHBtc2VyaWFsbnVtYmVyMAwGA1UdEwEB/wQCMAAwNQYDVR0f
BC4wLDAqoCigJoYkaHR0cDovL3d3dy5leGFtcGxlLmNvbS9FeGFtcGxlQ0EuY3Js
MBAGA1UdIAQJMAcwBQYDKgMEMB8GA1UdIwQYMBaAFDR3ZyRMRK/nnirgskxpV5Uk
sz3aMBAGA1UdJQQJMAcGBWeBBQgBMCEGA1UdCQQaMBgwFgYFZ4EFAhAxDTALDAMy
LjACAQACAWMwDQYJKoZIhvcNAQELBQADggEBABtrZu0n/7jPTYxak2n30AUakS7f
Ihomojo14e8Lp/HF7/2VaUcohJH4KekCHTf8wpPxM/b9xRKLSOORA2Ey255Q2h8T
v19he0dcdTvDPNQVY3AKaFO4cNiXeOYPR8n3IDYK5QdPqrdRX4/Bc34QcTWFDALx
C00L/kDvBjV7l0Et2DBJIiBNziVKxs1xn136buZYRam6ZJhTRzNMMQ0eZ279Um4M
39EI4DIFv6FzX0sC5waacVg6HFYd933NtdkDWV0VTGuk+5V8rH4Sjx+sywHahkoz
BJhQBai2qiWEt7bB0ExGN2ZXPjiQiG4UHvLgGlCOUHX7EDNf0dvfUIZ6hLY=-----END CERTIFICATE-----

Revision 14

Published

TCG PUBLISHED

Page 37 of 37