Protection Profile PC Client Specific TPM...Add leakage protection to O.Tamper_Resistance Add...

TCG

Protection Profile PC Client Specific TPM TPM Library specification Family “2.0” Level 0 Revision 1.38 12 September, 2017 Version 1.1 revision 0.12 Contact: [email protected]

Work in Progress: This 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 PUBLIC REVIEW Copyright © TCG 2017

mailto:[email protected]

Level 0 Revision 1.38 ii 12 September, 2017

TCG PUBLIC REVIEW

Disclaimers, Notices, and License Terms

THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR 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, 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.

This document is copyrighted by Trusted Computing Group (TCG), and no license, express

or implied, is granted herein other than as follows: You may not copy or reproduce the document or distribute it to others 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.

http://www.trustedcomputinggroup.org/

Level 0 Revision 1.38 iii 12 September, 2017

TCG PUBLIC REVIEW

Table of Contents

1. Scope ................................................................................................................................................................ 4

1.1 Key words .............................................................................................................................................. 4

1.2 Statement Type ..................................................................................................................................... 4

2. PP Introduction ................................................................................................................................................. 5

2.1 PP Reference ........................................................................................................................................ 5

2.2 TOE Overview ....................................................................................................................................... 5

2.2.1 TOE Definition ................................................................................................................................ 5

2.2.2 TOE Usage and Security Features ................................................................................................ 5

2.2.3 Non-TOE Hardware, Firmware and Software ................................................................................ 7

2.2.4 TPM Life Cycle ............................................................................................................................... 7

3. Conformance Claims ...................................................................................................................................... 12

3.1 CC Conformance Claim ...................................................................................................................... 12

3.2 Conformance with Packages .............................................................................................................. 12

3.3 Conformance with other Protection Profiles ........................................................................................ 12

3.4 Conformance Statement ..................................................................................................................... 12

4. Security Problem Definition ............................................................................................................................ 13

4.1 Assets .................................................................................................................................................. 13

4.2 Threats ................................................................................................................................................ 13

4.3 Organisational Security Policies ............................................................ Error! Bookmark not defined.

4.4 Assumptions ........................................................................................................................................ 16

5. Security Objectives ......................................................................................................................................... 17

5.1 Security Objectives for the TOE .......................................................................................................... 17

5.2 Security Objectives for the Operational Environment ......................................................................... 19

5.3 Security Objective Rationale ............................................................................................................... 19

6. Extended Components Definition ................................................................................................................... 29

6.1 Family Random Number Generation .................................................................................................. 29

7. Security Requirements ................................................................................................................................... 30

7.1 Security Functional Requirements ...................................................................................................... 30

7.1.1 Definitions of Subjects, Objects and TSF data ............................................................................ 30

7.1.2 Presentation of operations on SFR components ......................................................................... 37

7.1.3 SFRs for the General Behavior of the TOE ................................................................................. 38

7.1.3.1 Management ............................................................................................................................... 38

7.1.3.2 Data Protection and Privacy ....................................................................................................... 39

7.1.3.3 Cryptographic SFR ..................................................................................................................... 40

7.1.3.4 Identification and Authentication SFR ......................................................................................... 48

Level 0 Revision 1.38 iv 12 September, 2017

TCG PUBLIC REVIEW

7.1.3.5 TSF Protection ............................................................................................................................ 54

7.1.4 SFRs Concerning the Object Hierarchy of the TOE .................................................................... 57

7.1.4.1 TPM Operational States .............................................................................................................. 57

7.1.4.2 Creation and Modification of the TPM Hierarchy ........................................................................ 63

7.1.4.3 Data Import and Export ............................................................................................................... 68

7.1.4.4 Measurement and Reporting ...................................................................................................... 74

7.1.5 SFRs for the TOE Operation ........................................................................................................ 78

7.1.5.1 Access SFR ................................................................................................................................ 78

7.1.5.2 Non-Volatile Storage ................................................................................................................... 84

7.1.5.3 Credentials .................................................................................................................................. 90

7.2 Security assurance requirements ........................................................................................................ 92

7.3 Security Requirements rationale ......................................................................................................... 94

7.3.1 Sufficiency of SFR........................................................................................................................ 94

7.3.2 Dependency Rationale ............................................................................................................... 112

7.3.3 Assurance Rationale .................................................................................................................. 133

8. Appendix ....................................................................................................................................................... 135

8.1 Random Number Generator (informative) ........................................................................................ 135

8.2 Acronyms .......................................................................................................................................... 135

8.3 Normative references ........................................................................................................................ 137

Tables

Table 1: Threats .................................................................................................................................................... 13 Table 2: Organisational Security Policies ................................................................ Error! Bookmark not defined. Table 3: Assumptions to the IT Environment ........................................................................................................ 16 Table 4: Security Objectives for the TOE .............................................................................................................. 17 Table 5: Security Objectives for the Operational Environment ............................................................................. 19 Table 6: Security Objective Rationale ................................................................................................................... 20 Table 7: Subjects ................................................................................................................................................... 30 Table 8: Protected Objects, operations, security attributes and authorisation data.............................................. 31 Table 9: objects, operations and security attributes for the TPM state control SFP ............................................. 59 Table 10: Security assurance requirements for the TOE ...................................................................................... 92 Table 11: Security requirements rationale ............................................................................................................ 94 Table 12: SFR Dependency rationale ................................................................................................................. 112

Level 0 Revision 1.38 v 12 September, 2017

TCG PUBLIC REVIEW

Level 0 Revision 1.38 1 12 September, 2017

TCG PUBLIC REVIEW

Revision History 1

Revision Date Description

0.01 13.12.2012 Initial version in the TCG document style

0.02 15.01.2013 Authorisation, TPM State Control SFP, Access Control SFP added

0.03 30.01.2013 NV Memory, Data Import and Export added

0.04 12.02.2013 Adjustments for FUM state handling, update of security objective rationale regarding firmware upgrade

0.05 20.02.2013 Update due to discussion in the SEWG and internal review

0.06

0.07 2.4.2013 Updating cryptographic SFR and FIA_AFL.

0.08 23.04.2013 Life cycle case 2, phase 3 allows the platform vendor to use Field upgrade or other means to install new TPM firmware, all references to Field Upgrade commands removed and Figure 1 updated; updates of SFR FCS_CKM.1/PK, FCS_CKM.1/OK, and some FCS_COP.1; O.ECDAA, OE.ECDAA and FCS_COP.1/Commit included because TPM2_Commit() is mandatory; FPT_STM.1 refined and application note adapted, FDP_ACF.1/State is corrected in respect to FUM (assignments added, physical presence removed)

0.09 24.4.2013 Move management functions from FDP_ACF.1/AC to FMT_MSA.1/AC and FMT_MOF.1/AC, shift access control for NVM from FDP_ACF.1/AC to FDP_ACF.1/NVM, FCS_COP.1/AES requires CFB and allows for other modes, reference to standards added. Update of FIA_AFL and introduction to field upgrade.

0.10 5.6.2013 Move management functions from FDP_ACF.1/AC to FMT_MSA.1/AC and FMT_MOF.1/AC, shift access control for NVM from FDP_ACF.1/AC to FDP_ACF.1/NVM, FCS_COP.1/AES requires CFB and allows for other modes, reference to standards added. Update of FIA_AFL and introduction to field upgrade.

FDP_ACC.1/Ac and FDP_ACF.1/Ac checked

0.11 10.7.2013 Chapter about audit is removed, chapter about key hierarchy updated (should be checked again), key generation SFR are updated, TPM2_ChangePPs and TPM2_ChangeEPS removed.

0.12 15.7.2013 Update of mapping tables and rationale in section 7.3, Table 8: inserted new row for object “Clock”, new rules for access control and management of security attributes for Clock (FDP_ACF.1/AC, FMT_MSA.1/AC), update of rationale in section 7.3, some minor changes according to review comments in the meetings

0.13 22.7.2013 FDP_RIP.1: list of more detailed objects instead of “all objects”; inserted the object “null seed” into table 8; inserted operations and security attributes for “user key” into table 8; appendix 8.1 is now ready for review; removed remaining references to optional commands according to the latest draft of PC client spec. from the SFRs, these are: TPM2 _EncryptDecrypt, TPM2_HMAC, TPM2_GetTime, TPM2_PolicyTicket, TPM2_SetAlgorithmSet, TPM2_NV_GlobalWriteLock, TPM2_NV_Certify; added references to the following mandatory commands in the SFRs: TPM2_LoadExternal, TPM2_ReadPublic, TPM2_ActivateCredential, TPM2_MakeCredential, TPM2_Unseal, TPM2_ObjectChangeAuth, TPM2_HMAC_Start, TPM2_EventSequenceComplete, TPM2_DictionaryAttackParameters; new SFRs for credential handling: FDP_ACC.1/Cre, FDP_ACF.1/Cre, FDP_MSA.3/Cre, FDP_MSA.1/Cre


TCG PUBLIC REVIEW

0.14 24.7.2013 Additional application note (7) addressing the injection of an EPK by the manufacturer, FMT_MSA.4/AC moved to sec. 7.1.3.4 and renamed to FMT_MSA.4/AUTH. FMT_MSA.4/Hier is introduced for management of security attributes for enabling/disabling hierarchies. FMT_MSA.4/NVM Hier is introduced for management of security attributes for reading NVM.

0.15 23.10.2013 Changes from Telco 25 th of Sept.

DAA changed to ECDAA.

TPMA_NV_GLOBALLOCK is introduced and assecc control rule defined in FDP_ACF.1.2/NVM (15).

Physical presence is addressed as optional authentication feature of PCCS TPM but removed from SPD and objectives: A.Physical_Presence, OE. Physical_Presence, FMT_MSA.1/PP , FIA_UAU.5.2 (3) , are removed and links to them, removed in O.Limit_Actions_Authdecribed as optional in table 7.

Note TPM2_PolicyPhysicalPresence is marked as mandatory in PCCS ordinary table.

FPT_TST.1.2, FPT_TST.1.3, FDP_ACF.1.2/States (5), GPIO and MMIO (cf. Juergens comments) need to be agreed.

0,16, 0.17 Internal working draft

0.18 Draft, comments solved, language corrected

0.19 12.03.2014 Comments OCO18 and OCO32 corrected.

0.20 31.03.2014 All changes from 0.19 accepted. Comments closed removed.

0.21 08.04.2014 All changes from TCG_PP_PC_client_specific_TPM_SecV2_v020_OCO_JH.doc accepted. Agreed correction for FCS_RNG.1. Closed comments OCOx and JHx removed. Still fomat issues with OSP.RT_Measurement (field needs update to keep hyperlinks in document)

0.23 11.06.2014 All changes reported from Infineon (mail from 14. and 28.5.) and accepted from SEWG. Changes at FCS_RNG.1.1, FCS_COP.1/ECDSA, FCS_COP.1.1/ECDAA, FDP_ACC.1.1/ExIm, FDP_ACF.1.2/ExIm, FMT_MSA.4.1/AUTH

0.25 13.08.2014 Changes belonging to evaluator report: Section 4.1 Assets added (15); O.Crypto_Key_Man definition changed (17); A.Configuration definition changed (13); Table 11 O.ECDAA updated (25)

0.26 26.08.2014 Additional changes resulting fro evaluator report:

Update to section 4.1 Assets (15); T.Bypass Objectives changed (21); T.Compromise Objectives changed (22);

.27 27.08.2014 Changed ECC-based Direction Anonymous Attestation Protocol to ECDAA signing operation in 4 locations.

0.28 17.09.2014 Add a new threat T.Leak linked to O.Tamper_Resistance and SFR FPT_PHP Rephrase OSP.RT_Reporting and OSP.RT_Storage. Change ATE_DPT.2 to ATE_DPT.1 to comply with CC3.1 R4 Editorial change to bold “Moderate” in 7.3.3

Add cross in rationale between T.Intercept and O.Import & O.Export since encryption depends on object attributes.

0.29 17.09.2014 Editorial change in T.Leak add “but not limited to”

0.30 8.10.2014 Correction typo T.Leak Add ISO references and remove IEEE 1363 and 1364 references Include ISO references in SFR Update reference to library specs revision 1.15 and PTP revision 0.43


TCG PUBLIC REVIEW

0.31 15.10.2014 Remove “Registration” and “Date” from $2 .1 (Date on top page) Remove “other means” to update firmware by Platform integrator. Add a note that FU is either compliant to Library spec or not but must comply with SFRs Add leakage protection to O.Tamper_Resistance Add justification between T.Intercept and O.Export/O.Import Add justification between O.FieldUpgradeControl and FIA_UAU.5

.32 5.11.2014 Modified Application note 14 for clarity and to include reference to BN_P256 curve.

Removed Operation 1 from FDP_ACC.1/Cre Subset access control

Removed Application note 43

.33 12.11.2014 Modified FCS_COP.1.1/AES changed “,” to “or”

Changed TPM Spec reference to 1.16 (only even versions are published)

Fixed Figure captions and updated figure cross references

1.1 r12 Addressed editorial changes in Sections 1-3 and Section 8

2


TCG PUBLIC REVIEW

1. Scope 3

This protection profile describes the security requirements for the Trusted Computing 4 Group (TCG) PC Client Specific Trusted Platform Module (TPM) Family 2.0; Level 0 5 conforming to the Common Criteria version 3.1 revision 4. 6

A TPM designer MUST be aware that for a complete definition of all requirements necessary 7 to build a TPM, the designer MUST use the Trusted Computing Group TPM Library 8 specification and the PC client specific specification for all TPM requirements. Security 9 targets for Common Criteria evaluation of PC Client Specific Trusted Platform Module MUST 10 be strictly conformant to this protection profile. 11

1.1 Key words 12

The key words “MUST,” “must”, “MUST NOT,” “must not”, “REQUIRED,” “required”, 13

“SHALL,” “shall”, “SHALL NOT,” “shall not”, “RECOMMENDED,” “recommended”, “MAY,” 14 “may”, “OPTIONAL”, and “optional” in this document normative statements are used as 15 described in RFC-2119. “SHOULD”, “should”, “SHOULD NOT”, and “should not” have an 16 additional meaning and are to be interpreted as described in Common Criteria Part 1, p. 11. 17

1.2 Statement Type 18

Please note a very important distinction between different sections of text throughout this 19 document. There are two distinctive kinds of text: application notes as informative comment 20 and normative statements. Because most of the text in this protection profile will are 21 normative statements, the authors have informally defined it as the default and, as such, 22 have specifically called out text which is informative comment. This means that unless text 23 is specifically marked as informative comment, it is considered to be normative statements. 24


TCG PUBLIC REVIEW

2. PP Introduction 25

2.1 PP Reference 26

Title: Protection Profile PC Client Specific Trusted Platform Module Specification 27 Version 2.0 Family 2.0; Level 0; Revision 1.16 (PP PCCS TPM V2 F2.0 L0) 28

Sponsor: Trusted Computing Group 29

CC Version: 3.1 (Release 4) 30

Assurance level: EAL augmented with ALC_FLR.1 and AVA_VAN.4 31

Document version: 0.32 32

Keywords: trusted computing group, trusted platform module, PC client specific TPM 33

2.2 TOE Overview 34

2.2.1 TOE Definition 35

The TOE is the TCG PC Client Specific Trusted Platform Module (PCCS TPM). This TPM is a 36 device that implements the functions defined in the TCG Trusted Platform Module Library 37 Specification, version 2.0, [7], [8], [9], [10] and the PC client specific interface specification 38 [11]. The TCG Trusted Platform Module Library specification describes the design 39 principles, the TPM structures, the TPM commands and supporting routines for the 40 commands. The TPM PC client specific interface specification describes the additional 41 features that must be implemented by a TPM for a PC Client platform. 42

The TOE consists of 43

(1) TPM hardware, 44

(2) TPM firmware, 45

(3) TPM guidance documentation. 46

The TPM hardware is typically implemented as a single-chip component that is attached to 47 the PC platform using a low-performance interface. It has processor, RAM, ROM and Flash 48 memory and may have special components to support random number generation and 49 cryptographic operations. The TPM firmware is running on the TPM platform. The TPM 50 guidance documentation provides the necessary information for secure usage of the TOE by 51 customers and users. 52

2.2.2 TOE Usage and Security Features 53

The TPM library specification describes the TPM protections in terms of Protected 54 Capabilities and Protected Objects (cf. [7], chapter 10 for details). A Protected Capability is 55 an operation that must be correctly performed for a TPM to be trusted and therefore is in 56 the scope of the CC evaluation as part of the TOE security functionality (TSF). A Protected 57 Object is data that must be protected for a TPM operation to be trusted. The TSF performs 58 all operations with Protected Objects inside the TPM. The TSF protects the confidentiality of 59 Protected Objects when exported from the TPM and checks the integrity of Protected objects 60 when imported into the TPM. The TOE provides physical protection for Protected Objects 61 residing in the TPM. 62


TCG PUBLIC REVIEW

The TPM provides methods for collecting and reporting identities of hardware and software 63 components of a computer system platform. The computer system report is generated by a 64 Trusted Computing Base (TCB) that includes the TPM and allows determination of expected 65 behavior. From the report provided by the TCB, there is trust in the computer system 66 platform. 67

There are commonly three Roots of Trust in a trusted platform; a root of trust for 68 measurement (RTM), root of trust for reporting (RTR) and root of trust for storage (RTS). In 69 TCG systems roots of trust are components that must be trusted because misbehavior 70 cannot be detected. The RTM is a computing engine capable of making inherently reliable 71 integrity measurements and maintaining an accurate summary of values of integrity digests 72 and the sequence of digests. The RTR is a computing engine capable of reliably reporting 73 information held by the RTM. The RTS provides secure storage for a practically unlimited 74 number of private keys or other data by means of exporting and importing encrypted data. 75

Support for the Root of Trust for Measurement 76

The TPM supports the integrity measurement of the trusted platform by calculation and 77 reporting of measurement digests of measured values. Typically the RTM is controlled by 78 the Core Root of Trust for Measurement (CRTM) as the starting point of the measurement. 79 The measurement values are representations of embedded data or program code scanned 80 and provided to the TPM by the measurement agent. The TPM supports cryptographic 81 hashing of measured values and calculates the measurement digest by extending the value 82 of a PCR with a calculated or provided hash value. The PCRs are shielded locations of the 83 TPM which can be reset by TPM reset or a trusted process, and written only through 84 measurement digest extensions, and read. 85

Root of Trust for Reporting 86

The TPM holds the Endorsement Primary Seed (EPS) and generates Endorsement Keys (EK) 87 from the EPS. The EK and the corresponding Endorsement Certificates define the trusted 88 platform identities for the RTR. The TPM may be shipped with an EK and a Certificate of the 89 Authenticity of this EK. The EK is bound to the Platform via a Platform Certificate, providing 90 assurance from the certification body of the physical binding and connection through a 91 trusted path between the platform (the RTM) and the genuine TPM (the RTR). The 92 attestation of the EK and the Platform Certificates build the base for attestation of other 93 keys and measurements (cf. [7] chapter 9.5 for details). 94

Root of Trust for Storage 95

The TPM holds the Storage Primary Seed (SPS) and generates Storage Root Keys (SRK) from 96 SPS. The SRK are roots of Protected Storage Hierarchies associated with a TPM. One use of 97 the storage keys in these hierarchies are used for symmetric encryption and signing of other 98 keys and data together with their security attributes. The resulting encrypted file, which 99 contains header information in addition to the data or the key, is called a BLOB (Binary 100 Large Object) and is output by the TPM and can be loaded in the TPM when needed. The 101 private keys generated on the TPM can be stored outside the TPM (encrypted) in a way that 102 allows the TPM to use them later without ever exposing such keys in the clear outside the 103 TPM. The TPM uses symmetric cryptographic algorithms to encrypt data and keys and may 104 implement asymmetric cryptographic algorithms of equivalent strength. 105


TCG PUBLIC REVIEW

Platform Key Hierarchy 106

The TPM may hold an additional Platform Primary Seed (PPS) and generate Platform Keys 107 from PPS. The platform key hierarchy is controlled by the Platform firmware. The PPS may 108 be generated by the TOE or be injected by the TPM manufacturer. 109

Other Security Services and Features 110

The TOE provides cryptographic services for hashing, asymmetric encryption and 111 decryption, asymmetric signing and signature verification, symmetric encryption and 112 decryption, symmetric signing and signature verification and key generation. The Hash 113 function SHA-1 and SHA-256 are provided as a cryptographic service to external entities for 114 measurements and used internally for user authentication, signing and key derivation. A 115 TOE is required to implement asymmetric algorithms: where the current specification 116 supports RSA with 2048 bits for digital signature, secret sharing and encryption and ECC 117 algorithms with P-256 and BN-256 curves for digital signatures and secret sharing. The 118 TOE provides symmetric encryption and decryption of AES-128 in CFB mode and perhaps 119 additional algorithms in CBC, CTR, ECB (not recommended) and OFB modes of operation. 120 The TOE implements symmetric signing and signature verification by means of HMAC 121 described in [16]. The TOE generates three types of keys: Ordinary keys are generated using 122 the random number generator to seed the key computation. Primary Keys are derived from 123 a Primary Seed and key parameters by means of a key derivation function. Derived Keys are 124 derived from the sensitive value of the parent and key parameters by means of a key 125 derivation function. 126

The TPM stores persistent state associated with the TPM in NV memory and provides NV 127 memory as a shielded location for data of external entities. The platform and entities 128 authorised by the TPM owner control allocation and use of the provided NV memory. The 129 access control may include the need for authentication of the user, delegations, PCR values 130 and other controls. 131

The TSF also includes random number generation, self-test and physical protection. 132

2.2.3 Non-TOE Hardware, Firmware and Software 133

The TPM is a hardware component of a computer system. The Platform firmware and the 134 operating system of this computer system interact with the TPM by sending commands to 135 the TPM and receiving responses of the TPM through the interface described in [7] and [0]. 136 Further, the TPM is able to obtain the indications _TPM_Init, locality and an optional 137 feature physical presence via its I/O interface, and adjust its internal state accordingly. 138 Therefore the TOE is a passive device controlled by the software running on the computer 139 system. 140

2.2.4 TPM Life Cycle 141

The TPM life cycle may be described in four phases: Development, Manufacturing, Platform 142 Integration and Operational usage. Because the PC client specific TPM supports Field 143 Upgrade the TPM life cycle distinguishes two cases. 144

Case 1: The TPM hardware and firmware are manufactured and delivered together. 145


TCG PUBLIC REVIEW

Case 2: The TOE firmware component is installed (as a replacement or an 146 augmentation of the previously loaded TPM firmware) after delivery of the TOE 147 hardware component to the platform vendor or the end user. 148

The full Field Upgrade (cf. [7], chapter 12.5.2) does change the TOE and the incremental 149 Field Upgrade may change the TOE. The TPM life cycle is also linked to the life cycles of the 150 EPS, PPS and SPS and their corresponding key hierarchies. 151

Case 1 of the TPM life cycle can be summarised as follows. 152

Development of the TPM (Phase 1) 153

The Development of the TPM (Phase 1) comprises the development of the TPM 154 hardware and the TPM firmware. 155

Manufacturing and Delivery of the TPM (Phase 2) 156

The Manufacturing Phase comprises the production of the integrated circuit 157 implementing complete or parts of TPM firmware, the loading of TPM firmware parts 158 stored in EEPROM or Flash memory, testing and delivery to the platform vendor. 159

In this phase the TPM manufacturer may inject EPS and PPS but whenever the TPM 160 is powered on and no EPS, PPS or SPS is present the missing primary seeds will be 161 generated automatically and may be changed afterwards. The TPM manufacturer 162 may generate an EK and the corresponding Endorsement Certificate as evidence for 163 its genuine TPM. 164

This phase ends with TPM delivery to the customer. 165

Platform Integration (Phase 3) 166

The TPM is installed in the platform, equipped with TPM and platform specific keys 167 and certificates, and delivered to the customer of the platform. 168

In this phase the platform vendor may equip the TPM with the PPS, Platform Primary 169 Key, Platform Keys and corresponding Platform Certificates. The Platform hierarchy 170 and the Endorsement hierarchy (based on the EPS created by the TPM manufacturer 171 or the Platform manufacturer) may be bound by cross certification. 172

Operational usage (Phase 4) 173

In the Operational Phase the TPM is prepared for operational usage and used in the 174 environment of the end user. The preparative procedures for operational usage 175 include secure acceptance of the delivered TOE, taking and releasing ownership and 176 establishing the Storage key hierarchy for protection of owner-related and other User 177 data and TSF data of the TPM outside the TPM. 178

179


TCG PUBLIC REVIEW

Co

mm

on

Cri

teri

a S

cop

e O

f Ev

alu

atio

n

180

181

Figure 1: TPM Life Cycle case 1 182

183

In case 2 of the TPM life cycle the TPM hardware and parts of the TPM firmware of a 184 previously certified TPM are used for access, integrity and authenticity control of the 185 installation of the new firmware running on the same hardware and building a new TPM. 186 The parts of the previously certified TPM may be run through the life cycle as in case 1 or in 187 case 2. 188

The following steps describe the life cycle case 2 for the upgraded firmware parts only. The 189 TOE hardware is as already delivered to the platform vendor or the end user. 190

Development of the TPM (Phase 1) 191

The Development of the TPM (Phase 1) comprises the development and testing of the 192 TPM firmware upgrades to be installed on hardware of a previous TPM. 193

Manufacturing of the TPM (Phase 2) 194

Phase 1: TOE Development

•TPM hardware Development

•TPM firmware Development

Phase 2: TOE Manufacturing

and Delivery

•TPM IC manufacturing

•TPM firmware loading

•TPM conformance testing

•EPS and PPS loading (Optional)

•EK and the corresponding Endorsement Certificate generation (optional)

Phase 3: Platform

Integration

•TPM is installed on the platform

•Platform specific keys and certificates are set

Phase 4: Operational

usage

•TPM is prepared for operational usage

•Used in the end user environment

•Secure acceptance of the delivered TOE

•Taking and releasing ownership

•Establishing the Storage key hierarchy


TCG PUBLIC REVIEW

The TPM manufacturer delivers the firmware upgrade for Field Upgrade to the 195 platform vendor as their customer.1 196

Platform Integration (Phase 3) 197

The platform vendor uses the Field Upgrade functionality2 to install the new TPM 198 firmware on hardware of a previous TPM before delivery of the platform to the end 199 user. 200

Note the platform vendor may use different ways for delivery of the firmware upgrade 201 to the end user, e.g. using update mechanisms of operating systems running on the 202 platform. 203

Operational usage (Phase 4) 204

The platform vendor or the end user may use the Field Upgrade functionality to 205 install the new TPM firmware on hardware of a previous TPM after delivery of the 206

platform to the end user. The preparative procedures for operational usage of the 207 new certified TPM include secure acceptance procedures for use by the end user. 208

The Field Upgrade preserves User data (NV index allocations and contents, persistent 209 object allocations and contents) and TSF data (EPS, PPS and SPS, hierarchy 210 authentication reference data authValue, authPolicy and proof, lockoutAuth, 211 lockoutPolicy, lockout parameters, the PCR authValue and authPolicy values, clock). 212 Thus the Field Upgrade does not change the Storage key hierarchy for protection of 213 owner-related and other User data and TSF data. After Field Upgrade the new TPM 214 will be ready for operational use in the environment of the end user. 215

The installation of the new firmware may be performed in Phase 3 or Phase 4. The previous 216 TOE requires authorisation for firmware upgrade and verifies the integrity and authenticity 217 of TPM firmware upgrade data as provided by the TPM firmware manufacturer. But the new 218 TPM may or may not be a certified TPM depending on the TPM vendor or platform vendor 219 certification policy. Thus the user of the TPM shall be made aware of these changes, 220 whether the installed firmware is certified, and which version of a certified TPM is installed. 221

1 The TPM manufacturer may use the field upgrade process as well but this is not expected as the

TPM vendor may use manufacturing utilities. 2 The field upgrade implementation may be proprietary or compliant to the library specifications but

must fulfill the SFRs defined in this protection profile.


TCG PUBLIC REVIEW

Co

mm

on

Cri

teri

a S

cop

e O

f Ev

alu

atio

n

222

Figure 2 TPM Life Cycle case 2 223

224

The Common Criteria evaluation covers the Development of the TOE (Phase 1), the 225 Manufacturing of the TPM (phase 2) up to the delivery to the platform vendor under the 226 development environment (cf. CC part 1 [1], paragraph 157) in the evaluator activity of class 227 ALC: Life-cycle support. The concrete state of the TPM when delivered to the platform 228 vendor as customer of the TPM vendor depends on the vendor configuration options. A TPM 229 can be delivered with no key, or with an Endorsement Key, or with an Endorsement Key 230 and Endorsement Certificate, or with a Platform Key and Platform Certificate. The security 231 target shall describe all configurations of the TOE as delivered to the platform vendor. 232 Details on these configurations will be provided for evaluator activities of families ALC_CMS 233 and ALC_DEL. The user guidance provide by the TPM vendor shall describe the requirement 234 and general procedures and the supplier of the certified TOE shall obey these procedures 235 enabling the end users’ acceptance of the certified version and configuration of the delivered 236 TOE. (cf. element AGD_PRE.1.1C for details). 237

Phase 1: TOE Development

•TPM firmware upgrade package development

Phase 2: TOE Manufacturing

and Delivery

•TPM firmware upgrade package manufacturing

•TPM firmware upgrade package delivery to the customer for Field Upgrade

Phase 3: Platform

Integration

•TPM firmware upgrade package installation

Phase 4: Operational

usage

•Secure acceptance procedures for the end user


TCG PUBLIC REVIEW

3. Conformance Claims 238

The following sections describe the conformance claims of the Protection Profile PC Client 239 Specific Trusted Platform Module. 240

3.1 CC Conformance Claim 241

This Protection Profile claims to be conformant with the Common Criteria version 3.1 242 Release 4 as follows 243

- Part 2 extended, 244

- Part 3 conformant. 245

3.2 Conformance with Packages 246

This PP is conformant to assurance package EAL4 augmented with ALC_FLR.1 and 247 AVA_VAN.4 defined in CC part 3. 248

3.3 Conformance with other Protection Profiles 249

This PP does not claim conformance to any other PP. 250

3.4 Conformance Statement 251

This PP requires strict conformance of any ST or PP, that claims conformance to this PP. 252


TCG PUBLIC REVIEW

4. Security Problem Definition 253

The following sections describe the security problem definition of the Protection Profile PC 254 Client Specific Trusted Platform Module. 255

4.1 Assets 256

This section of the security problem definition shows the assets of the TOE to be protected 257 and the threats that are considered. 258

The assets are: 259

- Protected Objects, operations, security attributes and authorisation data as 260 defined in Table 8. 261

- Objects, operations and security attributes for the TPM state control SFP as 262 defined in Table 9. 263

264

4.2 Threats 265

This section of the security problem definition shows the threats that are to be countered 266 by the TOE, its development environment, its operational environment, or a combination of 267 these three. A threat consists of a threat agent, an asset (either in the operational or in the 268 development environment) and an adverse action of that threat agent on that asset. 269

Table 1: Threats 270

# Threat Description

1 T.Compromise An undetected compromise of the data in shielded locations may occur as a result of an attacker (whether an insider or outsider) attempting to perform actions that the individual or capability is not authorised to perform.

2 T.Bypass An unauthorised individual or user may tamper with TSF, security attributes or other data in order to bypass TOE security functions and gain unauthorised access to TOE assets.

3 T.Export A user or an attacker may export data from shielded locations without security attributes or with insecure security attributes, causing the data exported to be erroneous and unusable, to allow erroneous data to be added or substituted for the original data, and/or to reveal

secrets.

4 T.Hack_Crypto Cryptographic key generation or operation may be incorrectly implemented, allowing an unauthorised individual or user to compromise keys generated within the TPM or encrypted data or to modify data undetected.

5 T.Hack_Physical An unauthorised individual or user of the TOE may cause unauthorised disclosure or modification of TOE assets by physically interacting with the TOE. The attacker may be a


TCG PUBLIC REVIEW

# Threat Description

hostile user of the TOE.

6 T.Imperson An unauthorised individual may impersonate an authorised user of the TOE (e.g. by dictionary attacks to guess the authorisation data) and thereby gain access to TOE data in shielded locations and protected capabilities.

7 T.Import A user or attacker may import data without security attributes or with erroneous security attributes, causing key ownership and authorisation to be uncertain or erroneous and the system to malfunction or operate in an insecure manner.

8 T.Insecure_State The TOE may start-up in an insecure state or enter an

insecure state, allowing an attacker to obtain sensitive data or compromise the system.

9 T.Intercept An attacker may intercept the communication between a user and the TPM subjects to gain knowledge of the commands and data sent to the subject or manipulate the communication.

10 T.Malfunction TOE assets may be modified or disclosed to an unauthorised individual or user of the TOE, through malfunction of the TOE.

11 T.Modify An attacker may modify data in shielded locations or their security attributes in order to gain access to the TOE and its assets.

12 T.Object_Attr_Change A user or attacker may create an object with no security attributes or make unauthorised changes to security attribute values for an object to enable attacks.

13 T.Replay An unauthorised individual may gain access to the system and sensitive data through a “replay” or “man-in-the-middle” attack that allows the individual to capture identification and authentication data.

14 T.Repudiate_Transact An originator of data may deny originating the data to avoid accountability.

15 T.Residual_Info A user may obtain information that the user is not authorised to have when the data in shielded locations is no

longer actively managed by the TOE (“data scavenging”).

16 T.Leak An attacker may exploit information which is leaked from the TOE during usage of the TSF in order to disclose confidential assets.

271


TCG PUBLIC REVIEW

4.3 Organisational Security Policies 272

This section of the security problem definition shows the Organisational Security Policies 273 (OSPs) that are to be enforced by the TOE, its development environment, its operational 274 environment, or a combination of these three. OSPs are rules, practices, or guidelines. 275 These may be laid down by the organisation controlling the operational environment of the 276 TOE, or they may stem from legislative or regulatory bodies. OSPs can apply to the TOE, 277 the operational environment of the TOE, and/or the development environment of the TOE. 278

Table 2: Organisational Security Policies 279

# OSP Description

1 OSP.Context_Mana-gement

A resource manager shall be able to secure caching of resources without knowledge or assistance from the application that loaded the resource.

2 OSP.Policy_Authorisation

The TPM supports multiple trusted processes obeying the principle of least privilege by means of role based administration and separation of duty by configuring policy authorisation to allow individual entities (trusted processes, specific privileges, operations).

3 OSP.Locality The TCG platform supports multiple transitive trust chains by means of a mechanism known as locality. The Host Platform's trusted processes assert their locality to the TPM. The TPM guards access to resources, PCRs and NV Storage Space, to keys and data to be imported, and to defined commands depending on the execution environment’s privilege level.

4 OSP.RT_Measurement The root of trust for measurement calculates and stores the measurement digests as hash values of a representation of embedded data or program code (measured values) for reporting.

5 OSP.RT_Reporting The root of trust for reporting reports on the contents of the RTS. A RTR report is typically a digitally signed digest of the contents of selected values within a TPM (measurement, key properties or audit digest). The authenticity of the assets reported is based on the verification of the signature and the certificate of the signing key.

6 OSP.RT_Storage The root of trust for storage protects the assets (listed in Table 8 and Table 9) entrusted to the TPM in confidentiality and integrity.

7 OSP.FieldUpgrade The Platform software is allowed to perform Field Upgrade within the certified TPM or installing a new certified TPM before and after delivery to the end user. The end user shall be aware of the certification and the version of the TPM.

8 OSP.ECDAA The ECDAA issuer and the TPM owner establish a procedure for attestation without revealing the attestation information


TCG PUBLIC REVIEW

# OSP Description

(i.e. the identity of the TPM).

280

281

4.4 Assumptions 282

This section of the security problem definition shows the assumptions that the TOE makes 283 on its operational environment in order to be able to provide security functionality. If the 284 TOE is placed in an operational environment that does not meet these assumptions, the 285 TOE may not be able to provide all of its security functionality anymore. 286

Table 3: Assumptions to the IT Environment 287

# Assumption Description

1 A.Configuration The TOE will be properly installed and configured based on AGD instructions.

288


TCG PUBLIC REVIEW

5. Security Objectives 289

5.1 Security Objectives for the TOE 290

The security objectives are a concise and abstract statement of the intended solution to the 291 problem defined by the security problem definition. The TOE provides security functionality 292 to solve a certain part of the problem defined by the security problem definition. This part 293 wise solution is called the security objectives for the TOE and consists of a set of 294 statements describing the security goals that the TOE should achieve in order to solve its 295 part of the problem. 296

Table 4: Security Objectives for the TOE 297

# Objective Description

1 O.Context_Management The TOE must ensure a secure wrapping of a resource (except seeds) in a manner that securely protects the confidentiality and the integrity of the data of this resource and allows the restoring of the resource on the same TPM and during the same operational cycle only - TPM operational cycle is a Startup Clear to a Shutdown Clear and contexts cannot be reloaded across a different Startup Clear to Shutdown Clear cycle from the one in which they are created.

2 O.Crypto_Key_Man The TOE must manage cryptographic keys, including generation of cryptographic keys using the TOE random number generator as source of randomness, in a manner to protect their confidentiality and integrity.

3 O.DAC The TOE must control and restrict user access to the TOE protected capabilities and shielded locations in accordance with a specified access control policy where the object owner manages the access rights for their data objects using the principle of least privilege.

4 O.Export When data are exported outside the TPM, the TOE must securely protect the confidentiality and the integrity of the data as defined for the protected capability. The TOE shall ensure that the data security attributes being exported are unambiguously associated with the data.

5 O.Fail_Secure The TOE must enter a secure failure mode in the event of a failure.

6 O.General_Integ_Checks The TOE must provide checks on system integrity and user data integrity.

7 O.I&A The TOE must identify all users, and shall authenticate the claimed identity except of the role “World” before granting a user access to the TOE facilities.


TCG PUBLIC REVIEW


8 O.Import When data are being imported into the TOE, the TOE must ensure that the data security attributes are being imported with the data and the data is from an authorised source. In addition, the TOE shall verify those security attributes according to the TSF access control rules. TOE supports the protection of confidentiality and the verification of the integrity of imported data.

9 O.Limit_Actions_Auth The TOE must restrict the actions a user may perform before the TOE verifies the identity of the user.

10 O.Locality The TOE must control access to objects based on the locality of the process communicating with the TPM.

11 O.Record_Measurement The TOE must support calculating hash values and recording the result of a measurement.

12 O.MessageNR The TOE must provide user data integrity, source authentication, and the basis for source non-repudiation when exchanging data with a remote system.

13 O.No_Residual_Info The TOE must ensure there is no “object reuse”, i.e. there is no residual information in information containers or system resources upon their reallocation to different users.

14 O.Reporting The TOE must report measurement digests and attest to the authenticity of measurement digests.

15 O.Security_Attr_Mgt The TOE must allow only authorised users to initialise and to change security attributes of objects and subjects. The management of security attributes shall support the principle of least privilege by means of role based administration and separation of duty.

16 O.Security_Roles The TOE must maintain security-relevant roles and association of users with those roles.

17 O.Self_Test The TOE must provide the ability to test itself, verify the integrity of the shielded data objects and the protected capabilities operate as designed and enter a secure state in case of detected errors.

18 O.Single_Auth The TOE must provide a single user authentication mechanism and require re-authentication to prevent

“replay” and “man-in-the-middle” attacks.

19 O.Sessions The TOE must provide the confidentiality of the parameters of the commands within an authorised session and the integrity of the audit log of the commands.

20 O.Tamper_Resistance The TOE must resist physical tampering of the TSF by hostile users. The TOE must protect assets against leakage.

21 O.FieldUpgradeControl The TOE restricts the Field Upgrade to authorised role and accepts only authentic update data provided by the TOE


TCG PUBLIC REVIEW


vendor.

22 O.ECDAA The TPM must support the TPM owner for attestation to the authenticity of measurement digests without revealing the attestation information by implementation of the TPM part of the ECDAA.

298

5.2 Security Objectives for the Operational Environment 299

The following table defines the security objectives for the operational environment of the 300 TOE. 301

Table 5: Security Objectives for the Operational Environment 302

# Objective Name Objective Description

1 OE.Configuration The TOE must be installed and configured properly for starting up the TOE in a secure state. The security attributes of subjects and objects shall be managed securely by the authorised user.

2 OE.Locality The developer of the host platform must ensure that trusted processes indicate their correct locality to the TPM and untrusted processes are only able to assert the locality 0 to the TPM.

3 OE.Credential The IT environment must create EK and AK credentials by trustworthy procedures for the root of trust for reporting.

4 OE.Measurement The platform part of the root of trust for measurement provides a representation of embedded data or program code (measured values) to the TPM for measurement.

5 OE.FieldUpgradeInfo The developer via AGD documentation will instruct the admin how to do the upgrade and that the admin should inform the end user regarding the Field Upgrade process, its result, whether the installed firmware is certified or not, and the version of the certified TPM.

6 OE.ECDAA The ECDAA issuer must support a procedure for attestation without revealing the attestation information based on the ECDAA signing operation.

303

5.3 Security Objective Rationale 304

The following table provides an overview of the mapping between the security objective for 305 the TOE and the functional security requirements. The table shows and the rationale 306 demonstrates that each security objective for the TOE is traced back to threats countered 307 by that security objective and OSPs enforced by that security objective; each security 308 objective for the operational environment is traced back to threats countered by that 309


TCG PUBLIC REVIEW

security objective, to OSPs enforced by that security objective, and to assumptions upheld 310 by that security objective. All security objectives counter all threats, enforce all 311 organisational security policies and uphold all assumptions. 312

Table 6: Security Objective Rationale 313

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

OE

.Con

figu

rati

on

OE

.EC

DA

A

OE

.Locality

OE

.Cre

den

tial

OE

.Measu

rem

en

t

OE

.Fie

ldU

pgra

deIn

fo

T.Compromise X X X X

T.Bypass X X

T.Export X X X

T.Hack_Crypto X

T.Hack_Physical X X

T.Imperson X X X X X X

T.Import X

T.Insecure_State X X X X

T.Intercept X X X

T.Malfunction X X

T.Modify X X X X

T.Object_Attr_Change X

T.Replay X

T.Repudiate_Transact X

T.Residual_Info X

T.Leak X

Error! Reference source not found.

X


X X


X X


X X

OSP.RT_Measurement X X


X X


X X X X X


X X

A.Configuration X


TCG PUBLIC REVIEW

314 T.Compromise: An undetected compromise of the data in shielded locations may occur as 315 a result of an attacker (whether an insider or outsider) attempting to perform actions that 316 the individual or capability is not authorised to perform. 317

T.Compromise is countered by O.I&A, O.DAC, O.No_Residual_Info and O.Security_Roles. 318 These objectives limit the ability of a user to the performance of only those actions that the 319 user is authorised to perform: 320

O.I&A: The TOE must identify all users, and shall authenticate the claimed identity 321 except of the role “World” before granting a user access to the TOE facilities. This 322 objective provides the prerequisite for the application of the access control roles for 323 the subjects by uniquely identifying users and requiring authentication of the user 324 bound to a subject. 325

O.DAC: The TOE must control and restrict user access to the TOE protected 326 capabilities and shielded locations in accordance with a specified access control 327 policy where the object owner manages the access rights for their data objects using 328 the principle of least privilege. This objective limits an attacker from performing 329 unauthorised actions through a defined access control policy. 330

O.No_Residual_Info: The TOE must ensure there is no “object reuse”, i.e. there is no 331 residual information in information containers or system resources upon their 332 reallocation to different users. 333

O.Security_Roles: The TOE must maintain security-relevant roles and association of 334 users with those roles. This objective further supports the access control policy by 335 associating each user with a role, which then can be assigned a specific access 336 control policy. 337

T.Bypass: An unauthorised individual or user may tamper with TSF, security attributes or 338 other data in order to bypass TOE security functions and gain unauthorised access to TOE 339 assets. 340

T.Bypass is countered by O.Security_Attr_Mgt and O.Security_Roles. These objectives allow 341 the TOE to invoke the TSF in all actions and to counter the ability of unauthorised users to 342 tamper with TSF, security attributes or other data: 343

O.Security_Attr_Mgt: The TOE must allow only authorised users to initialise and to 344 change security attributes of objects and subjects. The management of security 345 attributes shall support the principle of least privilege by means of role based 346 administration and separation of duty. This objective requires that only authorised 347 users be allowed to initialise and change security attributes, which counters the 348

threat of an unauthorised user making such changes. 349

O.Security_Roles: The TOE must maintain security-relevant roles and association of 350 users with those roles. 351

T.Export: A user or an attacker may export data from shielded locations without security 352 attributes or with insecure security attributes, causing the exported data to be erroneous 353 and unusable, to allow erroneous data to be added or substituted for the original data, 354 and/or to reveal secrets. 355


TCG PUBLIC REVIEW

T.Export is countered by O.Export, O.Security_Attr_Mgt and OE.Configuration. These 356 objectives ensure the protection of confidentiality and integrity of exported data with secure 357 security attributes bound to these data. 358

O.Export: When data are exported outside the TPM, the TOE shall securely protect 359 the confidentiality and the integrity of the data as defined by the protected capability. 360 The TOE shall ensure that the data security attributes being exported are 361 unambiguously associated with the data. 362

The objective O.Security_Attr_Mgt limits initialisation and management of security 363 attributes of objects and subjects to authorised users only. The objective 364 OE.Configuration requires the authorised user to manage these security attributes 365 securely. Thus the object cannot be exported with insecure security attributes. 366

T.Hack_Crypto: Cryptographic key generation or operation may be incorrectly 367

implemented, allowing an unauthorised individual or user to compromise keys generated 368 within the TPM or encrypted data or undetected modification of data. 369

T.Hack_Crypto is countered by O.Crypto_Key_Man. The security objective ensures secure 370 key management and cryptographic operation. 371

O.Crypto_Key_Man: The TOE must manage cryptographic keys, including generation 372 of cryptographic keys using the TOE random number generator as source of 373 randomness, in a manner to protect their confidentiality and integrity. 374

T.Hack_Physical: An unauthorised individual or user of the TOE may cause unauthorised 375 disclosure or modification of TOE assets by physically interacting with the TOE. The 376 attacker may be a hostile user of the TOE. 377

T.Hack_Physical is countered by O.Tamper_Resistance and O.DAC: O.Tamper_Resistance 378 requires the TOE to resist physical tampering of the TSF which control and restrict user 379 access to the TOE protected capabilities and shielded locations according to O.DAC. 380

T.Imperson: An unauthorised individual may impersonate an authorised user of the TOE 381 and thereby gain access to TOE data in shielded locations and protected capabilities. 382

T.Imperson is countered by O.I&A, O.Security_Roles, O.Import, O.Locality, OE.Locality, 383 O.Limit_Actions_Auth These objectives prevent impersonation by authentication based on 384 managed roles with their security attributes and access control considering security 385 attributes of the users securely provided by the TOE environment: 386

O.I&A: The TOE must identify all users, and shall authenticate the claimed identity 387 except of the role “World” before granting a user access to the TOE facilities. This 388 objective provides the prerequisite for the application of the access control roles for 389 the subjects by uniquely identifying users and requiring authentication of the user 390

bound to a subject. 391

O.Security_Roles: The TOE must maintain security-relevant roles and association of 392 users with those roles. This objective further supports the access control policy by 393 associating each user with a role, which then can be assigned a specific access 394 control policy. 395


TCG PUBLIC REVIEW

O.Import: When data are being imported into the TOE, the TOE must ensure that the 396 data security attributes are being imported with the data and the data is from an 397 authorised source. In addition, the TOE shall verify those security attributes 398 according to the TSF access control rules. TOE supports the protection of 399 confidentiality and the verification of the integrity of imported data. 400

O.Locality includes locality as security attribute of the user to access control and 401 OE.Locality ensures that trusted processes indicate their correct locality to the TPM 402 and untrusted processes are able to assert the locality 0 or Legacy only to the TPM. 403

O.Limit_Actions_Auth requires restricting the actions a user may perform before the 404 TOE verifies the identity of the user. 405

T.Import: A user or attacker may import data without security attributes or with erroneous 406

security attributes, causing key ownership and authorisation to be uncertain or erroneous 407 and the system to malfunction or operate in an insecure manner. 408

T.Import is countered by O.Import, which states: When data are being imported into the 409 TOE, the TOE must ensure that the data security attributes are being imported with the 410 data and the data is from an authorised source. In addition, the TOE shall verify those 411 security attributes according to the TSF access control rules. TOE supports the protection 412 of confidentiality and the verification of the integrity of imported data. The integrity of the 413 data in a sealed data blob is protected by the TOE. 414

T.Insecure_State: The TOE may start-up in an insecure state or enter an insecure state, 415 allowing an attacker to obtain sensitive data or compromise the system. 416

T.Insecure_State is countered by O.Security_Attr_Mgt, O.Fail_Secure, 417 O.General_Integ_Checks and OE.Configuration. These objectives ensure the integrity or 418 secure security attributes and preservation of secure state in case of failure: 419

O.Security_Attr_Mgt: The TOE must allow only authorised users to initialise and to 420 change security attributes of objects and subjects. The management of security 421 attributes shall support the principle of least privilege by means of role based 422 administration and separation of duty. 423

O.General_Integ_Checks: The TOE must provide checks on system integrity and user 424 data integrity. 425

O.Fail_Secure: The TOE must enter a secure failure mode in the event of a failure. 426

OE.Configuration: This security objective requires the IT environment to install and 427 configure the TOE for starting up in a secure way. 428

T.Intercept: An attacker may intercept the communication between a user and the TPM 429 subjects to gain knowledge of the commands and data sent to the subject or manipulate 430 the communication. 431

T.Intercept is directly countered by O.Sessions, which states: The TOE must provide the 432 confidentiality of the parameters of the commands within an authorised session and the 433 integrity of the audit log of the commands. 434


TCG PUBLIC REVIEW

T.Intercept is countered by O.Import which states the TOE supports the protection of 435 confidentiality and the verification of the integrity of imported data and by O.Export which 436 states that when data are exported outside the TPM, the TOE must securely protect the 437 confidentiality and the integrity of the data as defined for the protected capability. 438

T.Malfunction: TOE assets may be modified or disclosed to an unauthorised individual or 439 user of the TOE, through malfunction of the TOE. 440

T.Malfunction is countered by O.Self_Test and O.Fail_Secure. These objectives address 441 detection of and preservation of secure states in case of failure. 442

O.Self_Test: The TOE must provide the ability to test itself, verify the integrity of the 443 shielded data objects and the protected capabilities operate as designed and enter a 444 secure state in case of detected errors. 445

O.Fail_Secure: The TOE must enter a secure failure mode in the event of a failure. 446

T.Modify: An attacker may modify data in shielded locations or their security attributes in 447 order to gain access to the TOE and its assets. The integrity of the information may be 448 compromised due to the unauthorised modification or destruction of the information by an 449 attacker. 450

T.Modify is countered by O.Limit_Actions_Auth, O.I&A, O.DAC and O.Security_Roles. These 451 objectives support the ability of the TOE to limit unauthorised user access and to maintain 452 data and system integrity through appropriate management of cryptographic data in 453 particular: 454

O.Limit_Actions_Auth: The TOE must restrict the actions a user may perform before 455 the TOE verifies the identity of the user. 456

O.I&A: The TOE must identify all users, and shall authenticate the claimed identity 457 except of the role “World” before granting a user access to the TOE facilities. 458

O.DAC: The TOE must control and restrict user access to the TOE protected 459 capabilities and shielded locations in accordance with a specified access control 460 policy where the object owner manages the access rights for their data objects using 461 the principle of least privilege. 462

O.Security_Roles: The TOE must maintain security-relevant roles and association of 463 users with those roles. 464

T.Object_Attr_Change: A user or attacker may create an object with no security attributes 465 or make unauthorised changes to security attribute values for an object to enable attacks. 466

T.Object_Attr_Change is directly countered by O.Security_Attr_Mgt, which states: The TOE 467 shall allow only authorised users to initialise and to change security attributes of objects 468 and subjects. 469

T.Replay: An unauthorised individual may gain access to the system and sensitive data 470 through a “replay” or “man-in-the-middle” attack that allows the individual to capture 471 identification and authentication data. 472


TCG PUBLIC REVIEW

T.Replay is directly countered by O.Single_Auth, which states: The TOE must provide a 473 single user authentication mechanism and require re-authentication to prevent “replay” 474 and “man-in-the-middle” attacks. 475

T.Repudiate_Transact: An originator of data may deny originating the data to avoid 476 accountability. 477

T.Repudiate_Transact is directly countered by O.MessageNR, which states: The TOE must 478 provide user data integrity, source authentication, and the basis for source non-repudiation 479 when exchanging data with a remote system. 480

T.Residual_Info: A user may obtain information that the user is not authorised to have 481 when the data in shielded locations is no longer actively managed by the TOE (“data 482 scavenging”). 483

T.Residual_Info is directly countered by O.No_Residual_Info, which states: The TOE must 484 ensure there is no “object reuse”, i.e. there is no residual information in information 485 containers or system resources upon their reallocation to different users. 486

T.Leak: An attacker may exploit information which is leaked from the TOE during usage of 487 the TSF in order to disclose confidential assets. 488

T.Leak is countered by O.Tamper_Resistance: O.Tamper_Resistance requires the TOE to 489 protect the assets against not only physical tampering but also leakage. Leakage may occur 490 through but not limited to measures of electromagnetic emanations, variations in power 491 consumption or by changes in processing time. 492

Error! Reference source not found.: Error! Reference source not found. 493

The Error! Reference source not found. is implemented by the O.Context_Management, 494 which states: The TOE must ensure a secure wrapping of a resource (except seeds) in a 495 manner that securely protects the confidentiality and the integrity of the data of this 496 resource and allows the restoring of the resource on the same TPM and during the same 497 operational cycle only - TPM operational cycle is a Startup Clear to a Shutdown Clear and 498 contexts cannot be reloaded across a different Startup Clear to Shutdown Clear cycle from 499 the one in which they are created. 500

501

OSP.ECDAA: The ECDAA issuer and the TPM owner establish a procedure for attestation 502 without revealing the attestation information (i.e. the identity of the TPM). 503

The OSP.ECDAA is implemented by the security objectives O.ECDAA for the TOE and 504 OE.ECDAA for the TOE environment. As a result, when a TPM authenticates to a verifier, 505 the attestation information about the TPM is not revealed to the verifier. 506

O.ECDAA: The TPM must support the TPM owner for attestation to the authenticity 507

of measurement digests without revealing the attestation information by 508 implementation of the TPM part of the ECDAA signing operation. 509

OE.ECDAA: The DAA issuer must support a procedure for attestation without 510 revealing the attestation information based on the ECDAA signing operation. 511

Error! Reference source not found.: The TPM supports multiple trusted processes 512 obeying the principle of least privilege by means of role based administration and 513 separation of duty. 514


TCG PUBLIC REVIEW

The Error! Reference source not found. is implemented by the O.DAC and 515 O.Security_Attr_Mgt. These objectives require the access control and the management of 516 the security attributes to support delegation: 517

O.DAC: The TOE must control and restrict user access to the TOE protected 518 capabilities and shielded locations in accordance with a specified access control 519 policy where the object owner manages the access rights for their data objects using 520 the principle of least privilege. 521

O.Security_Attr_Mgt: The TOE must allow only authorised users to initialise and to 522 change security attributes of objects and subjects. The management of security 523 attributes shall support the principle of least privilege by means of role based 524 administration and separation of duty. 525

Error! Reference source not found.: The TCG platform supports multiple transitive trust 526

chains by means of a mechanism known as locality. The Host Platform's trusted processes 527 assert their locality to the TPM. The TPM shall guard access to resources PCRs and NV 528 Storage Space, to keys and data to be imported, and to defined commands depending on 529 the execution environment’s privilege level. 530

The Error! Reference source not found. is implemented by the objective O.Locality and 531 OE.Locality. These objectives address the TOE using locality for access control and the 532 environment providing this security attribute of the user for the TOE. 533

O.Locality: The TOE must control access to objects based on the locality of the 534 process communicating with the TPM. 535

OE.Locality: The developer of the host platform must ensure that trusted processes 536 indicate their correct locality to the TPM and untrusted processes are only able to 537 assert the locality 0 to the TPM. 538

Error! Reference source not found. 539

The root of trust for measurement calculates and stores the measurement digests as hash 540 values of a representation of embedded data or program code (measured values) provided to 541 the TPM by other parts of the root of trust for measurement. 542

The Error! Reference source not found. is implemented by the TOE and a platform part of 543 the root of trust for measurement as follows. 544

O.Record_Measurement: Describes the responsibility of the TOE: The TOE must 545 support calculating hash values and recording the result of a measurement. 546

OE.Measurement: Describes the responsibility of the platform part of the root of trust 547 for measurement: The platform part of the root of trust for measurement provides a 548 representation of embedded data or program code (measured values) to the TPM for 549 measurement 550

Error! Reference source not found.: The root of trust for reporting reports on the contents 551 of the RTS. A RTR reports is typically a digitally signed digest of the contents of selected 552 values within a TPM (measurement, key properties or audit digest). The authenticity of the 553 assets reported is based on the verification of the signature and the credential of the 554 signing key. 555


TCG PUBLIC REVIEW

The Error! Reference source not found. is implemented by the objectives 556

O.Reporting: The TOE must report measurement digests and attest to the 557 authenticity of measurement digests. 558

OE.Credential: Addresses trustworthy procedures for creation of EK and AK 559 credentials for root of trust for reporting. 560

Error! Reference source not found.: The TPM as root of trust for storage protects the 561 assets (listed in Table 8 and Table 9) entrusted to the TPM in confidentiality and integrity. 562

The Error! Reference source not found. is implemented directly by the 563 O.Crypto_Key_Man, O.Export and O.Import and supported by the O.I&A and O.DAC. These 564 objectives require the protection of keys and data under Storage Root Key and the hierarchy 565 of trust for storage outside the TOE: 566

O.Crypto_Key_Man: The TOE must manage cryptographic keys, including generation 567 of cryptographic keys using the TOE random number generator as source of 568 randomness, in a manner to protect their confidentiality and integrity. This objective 569 ensures the security of the key hierarchy used to protect the stored data. 570

O.Export: When data are exported outside the TPM, the TOE must securely protect 571 the confidentiality and the integrity of the data as defined for the protected 572 capability. The TOE shall ensure that the data security attributes being exported are 573 unambiguously associated with the data. This objective ensures the security of the 574 data and their security attributes when exported to the storage outside the TOE. 575

O.Import: When data are being imported into the TOE, the TOE must ensure that the 576 data security attributes are being imported with the data and the data is from an 577 authorised source. In addition, the TOE shall verify those security attributes 578 according to the TSF access control rules. TOE supports the protection of 579 confidentiality and the verification of the integrity of imported data. This objective 580 ensures the security of the data and their security attributes when imported from 581 storage outside the TOE. 582

O.I&A: The TOE must identify all users, and shall authenticate the claimed identity 583 except of the role “World” before granting a user access to the TOE facilities.. This 584 objective ensures authentication and binding of user to the subjects performing 585 export and import of the keys. 586

O.DAC: The TOE must control and restrict user access to the TOE protected 587 capabilities and shielded locations in accordance with a specified access control 588 policy where the object owner manages the access rights for their data objects using 589

the principle of least privilege. This objective addresses the access control for the 590 objects. 591

Error! Reference source not found.: The Platform software is allowed to perform Field 592 Upgrade within the certified TPM or installing a new certified TPM before and after delivery 593 to the end user. The end user shall be aware of the certification and the version of the TPM. 594

The Error! Reference source not found. is implemented by O.FieldUpgradeControl and 595 OE.FieldUpgradeInfo: 596


TCG PUBLIC REVIEW

O.FieldUpgradeControl: Ensures that the field upgrade can only be performed by the 597 Platform firmware and only authentic update data provided by the vendor are 598 accepted. 599

OE.FieldUpgradeInfo: The operational environment is required to ensure that the 600 end user shall be aware of the field upgrade process and its result, whether the 601 installed firmware is certified or not and the version of the certified TPM. 602

A.Configuration: The TOE will be properly installed and configured based on the instruct-603 tions of the user guidance documentation (AGD). 604

The A.Configuration is directly covered by the objective for the TOE environment 605 OE.Configuration, which states: The TOE must be installed and configured properly for 606 starting up the TOE in a secure state. The security attributes of subjects and objects shall 607 be managed securely by the authorised user. 608


TCG PUBLIC REVIEW

6. Extended Components Definition 609

The protection profile under hand defines the extended family Random Number Generation 610 (FCS_RNG) of the class FCS: cryptographic support in order to describe the generation of 611 random numbers for cryptographic purposes. 612

6.1 Family Random Number Generation 613

The family Random Number Generation (FCS_RNG) of the class FCS: cryptographic support 614 describes the security functional requirements for random number generation used for 615 cryptographic purposes. The random number generation is provided to the user and used 616 internally, but it is not limited to generation of authentication data or cryptographic keys. 617

FCS_RNG Generation of random numbers 618

Family behavior 619

This family defines quality requirements for the generation of random numbers which are 620 intended to be used for cryptographic purposes. 621

Component leveling: 622

623

FCS_RNG.1 Generation of random numbers requires that random numbers meet a defined 624 quality metric. 625

Management: FCS_RNG.1 626

There are no management activities foreseen. 627

Audit: FCS_RNG.1 628

There are no actions defined to be auditable. 629

FCS_RNG.1 Random number generation 630

Hierarchical to: No other components. 631

Dependencies: No dependencies. 632

FCS_RNG.1.1 The TSF shall provide a [selection: physical, deterministic, hybrid] 633 random number generator that implements: [assignment: list of security 634 capabilities]. 635

FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a 636

defined quality metric]. 637

638

FCS_RNG Generation of random numbers 1


TCG PUBLIC REVIEW

7. Security Requirements 639

This section describes the security functional requirements (SFR) and the security 640 assurance requirements (SAR) to be fulfilled by the TOE. 641

7.1 Security Functional Requirements 642

This section describes the SFR to be fulfilled by the TOE. It defines the subjects, objects and 643 operations and introduces the notation for the operation of the SFR components. 644

7.1.1 Definitions of Subjects, Objects and TSF data 645

This section defines roles that subjects may use to access objects and their associated TSF 646 data for authorisation. The roles USER, ADMIN and DUP are defined for objects and NV 647 Index and operations that can be performed on or with that object or NV Index. 648

Table 7: Subjects 649

Subject Description TSF data

Platform firmware Entity that controls the platform hierarchy

platformAuth, platformPolicy,

security attributes:

locality, physical presence if supported by the TOE3

Platform owner Entity that controls the owner hierarchy

ownerAuth, ownerPolicy

security attribute:

locality

Privacy administrator Entity that controls the endorsement hierarchy

endorsementAuth, endorsementPolicy

security attribute:

locality

Lockout administrator Entity that controls the lockout mechanism of a TPM

lockoutAuth

USER Entity that uses objects, keys, data in NV memory

authValue, authPolicy assigned to the object

security attribute:

locality

ADMIN Entity that controls the

certification of an object and changing the authValue of an object

authValue, authPolicy

assigned to the object

security attribute:

locality

DUP Entity that is allowed to authValue for authorisation

3 Support of physical presence is an optional feature of the TOE for authorization of the platform

firmware.


TCG PUBLIC REVIEW

Subject Description TSF data

duplicate loaded objects role DUP

World Entity not authenticated (none)

Table 8 defines Protected Objects that are user data or TSF data depending on the context 650 in which they are used, the operations applicable to these objects and their security 651 attributes. 652

Table 8: Protected Objects, operations, security attributes and authorisation data 653

# Protected Objects Operations Security attributes

1 Platform Hierarchy

Set of services to

manage Platform firmware controls

Seed

The PPS may be installed at manufacturing time or

generated automatically on first boot

Disable

(cmd TPM2_HierarchyControl)

Change authorisation

(cmd TPM2_HierarchyChangeAuth)

(cmd TPM2_SetPrimaryPolicy)

Authorisation data:

platformAuth, hierarchy authorisation to change platform

policy or authorisation and disable the platform hierarchy.

platformPolicy, hierarchy policy authorisation to change the authorisation or policy for the Platform hierarchy

Security attributes:

hierarchy proof, secret value used to associate a hierarchy with tickets, objects or contexts

phEnable, logical attribute which determines whether the hierarchy is enabled or disabled

phEnableNV, logical attribute which determines whether platform hierarchy NV indices are enabled or disabled.

2 Endorsement Hierarchy

Set of services to manage Privacy Administrator controls

Seed

The EPS may be installed at manufacturing time or generated automatically on first boot

Enable/Disable



(cmd TPM2_HierarchyChangeAuth)

(cmd TPM2_SetPrimaryPolicy),

Authorisation data:

platformAuth, hierarchy authorisation to enable/disable the Endorsement hierarchy.

platformPolicy, hierarchy policy authorisation to enable/disable the Endorsement hierarchy.

endorsementAuth, hierarchy authorisation to change the authorisation for the Endorsement hierarchy.

endorsementPolicy, hierarchy policy authorisation to change the


TCG PUBLIC REVIEW


(cmd TPM2_Clear) authorisation for the Endorsement hierarchy



ehEnable, logical attribute which determines whether the hierarchy is enabled or disabled

3 Storage Primary Hierarchy

Set of services to manage Owner controls

Seed

The SPS may be installed at manufacturing time or generated automatically on first boot

Clear

(cmd TPM2_Clear)

Enable/Disable



(cmd TPM2_HierarchyChangeAuth, cmd TPM2_SetPrimaryPolicy)

Authorisation data:

platformAuth, hierarchy authorisation to enable/disable the Storage Hierarchy or clear hierarchy objects.

platformPolicy, hierarchy policy authorisation to enable/disable the Storage hierarchy or clear hierarchy objects.

ownerAuth, hierarchy authorisation to use the Storage Primary Seed.

ownerPolicy, hierarchy policy authorisation to use the Storage Primary Seed

lockoutAuth, authorisation used to reset the dictionary attack protection



shEnable, logical attribute which determines whether the hierarchy is enabled or disabled

4 NULL hierachy

Set of services provided to user World

Create

The nullSeed is set to a random value on every TPM reset.

nullProof

5 Platform Primary Create Authorisation data:


TCG PUBLIC REVIEW


Object

A root key created by the TPM that may be stored in the TPM or cached outside the TPM. The resource is instantiated in the Platform Hierarchy.

(cmd TPM2_CreatePrimary, cmd TPM2_CreateLoaded)

Delete

(cmd TPM2_EvictControl)

Make Persistent


userAuth, User auth secret value for the primary key

authPolicy, digest representing a policy calculation

platformAuth, hierarchy authorisation to use the Platform Primary Seed.

platformPolicy, hierarchy policy authorisation to use the Platform Primary Seed


key template, TPMT_PUBLIC, Part 2, §12.2.4, the public parameters used to create the key, set by the cmd TPM2_CreatePrimary or TPM2_CreateLoaded, may be restricted by the cmd TPM2_PolicyTemplate

6 Endorsement Primary Key

A root key created by the TPM that may be stored in the TPM or cached outside the TPM. The resource is instantiated in the Endorsement Hierarchy.

Create


Delete

(cmd TPM2_Clear)


Make Persistent


Authorisation data:

userAuth, User auth secret value




endorsementAuth, hierarchy authorisation to use the Endorsement Primary Seed.

endorsementPolicy, hierarchy

policy authorisation to use the Endorsement Primary Seed

lockoutAuth, authorisation used to reset the dictionary attack protection or clear


key template, TPMT_PUBLIC, Part 2, §12.2.4, the public parameters


TCG PUBLIC REVIEW


used to create the key, set by the cmd TPM2_CreatePrimary or TPM2_CreateLoaded, may be restricted by the cmd TPM2_PolicyTemplate

7 Storage Primary Key

A root key created by the TPM that may be stored in

the TPM or cached outside the TPM. The resource is instantiated in the Storage Hierarchy

Create


Delete

(cmd TPM2_Clear)


Make Persistent


Authorisation data:





ownerAuth, hierarchy authorisation to use the Storage Primary Seed.

ownerPolicy, hierarchy policy authorisation to use the Storage Primary Seed

lockoutAuth, authorisation used to reset the dictionary attack protection or clear


key template, TPMT_PUBLIC, Part 2, §12.2.4, the public parameters used to create the key, set by the cmd TPM2_CreatePrimary or TPM2_CreateLoaded, may be restricted by the cmd TPM2_PolicyTemplate

8 Context Context are applicable to objects (User keys and Primary keys) and also sessions (authorisations and sequence).

create (cmd TPM2_ContextSave),

load (cmd TPM2_ContextLoad)

delete (cmd TPM2_FlushContext)

hierarchy proof, used as secret for authenticity and integrity

objectContextID for transient and sequence objects contextCounter for sessions (for protection against replay attacks)

clearCount: to avoid transient


TCG PUBLIC REVIEW


object load after resume

resetValue: to avoid context load after reset

9 User Key

Any cryptographic key except the primary keys, i.e. ordinary or derived key.

Create

(cmd TPM2_Create, cmd TPM2_CreateLoaded)

Make Persistent


Load

(cmd TPM2_Load, cmd TPM2_CreateLoaded)

Delete


Authorisation data:



platformAuth, hierarchy authorisation to use the Platform Primary Object.

platformPolicy, hierarchy policy authorisation to use the Platform Primary Object

ownerAuth, hierarchy authorisation to use the Storage Primary Key.

ownerPolicy, hierarchy policy authorisation to use the Storage Primary Key


key template, TPMT_PUBLIC, Part 2, §12.2.4, the public parameters used to create the key, set by the cmd TPM2_Create or TPM2_CreateLoaded

10 PCR

Platform Configuration Register (PCR) intended to record measurement

digests and to be used for attestation and access control.

reset: reset the PCR value to zero, if allowed for the specified PCR (cmd TPM2_PCR_ Reset), or set all PCR to their default initial condition or to their save

state (cmd TPM2_Startup)

read: read the value of all PCRs specified in pcrSelect (cmd TPM2_PCR_Read),

allocate: set the desired PCR allocation of PCR and algorithms (cmd TPM2_PCR_Allocate),

Authorisation data:

authValue, authPolicy


All flags are defined in [8], sec. 6.14 TPM_PT_PCR

TPM_PT_PCR_SAVE - indicates that the PCR is saved and restored by TPM_SU_STATE

TPM_PT_PCR_EXTEND_L0, TPM_PT_PCR_EXTEND_L1, TPM_PT_PCR_EXTEND_L2, TPM_PT_PCR_EXTEND_L3, TPM_PT_PCR_EXTEND_L4


TCG PUBLIC REVIEW


quote: hash the selected PCR, sign the value with an identified signing key and export it (cmd TPM2_Quote)

event: calculate the hash value of the eventData and return the digests list, in case an implemented PCR is referenced an extend of the digests list is processed (cmd TPM2_PCR_Event),

extend: calculate the hash value of the PCR value according the digests list or the result of a pending hash calculation (cmd TPM2_PCR_ Extend and TPM2_EventSequenceComplete) and the interface commands _TPM_Hash_Start, _TPM_Hash_Data and _TPM_Hash_End defined in [8].

- indicates that the PCR may be extended from specific locality

TPM_PT_PCR_RESET_L0, TPM_PT_PCR_RESET_L1, TPM_PT_PCR_RESET_L2, TPM_PT_PCR_RESET_L3, TPM_PT_PCR_RESET_L4 - indicates that the PCR may be reset by specific locality

TPM_PT_PCR_NO_INCREMENT - indicates that modifications to this PCR will not increment the pcrUpdateCounter

TPM_PT_PCR_DRTM_RESET - indicates that the PCR is reset by DRTM event

11 NV storage

Non-volatile storage of the TPM provided to the user and protected by access rights managed by the TPM owner.

TPM2_NV_DefineSpace TPM2_NV_UndefineSpace TPM2_NV_UndefineSpaceSpecial TPM2_NV_Read TPM2_NV_ReadPublic TPM2_NV_Increment TPM2_NV_Extend TPM2_NV_SetBits TPM2_NV_Write TPM2_NV_ReadLock TPM2_NV_WriteLock TPM2_NV_ChangeAuthTPM2_NV_Certify

TPM2_EvictControl

TPM_NV_INDEX


platform controls (TPMA_NV_PPWRITE and TPMA_NV_PPREAD)

owner controls (TPMA_NV_OWNERWRITE and TPMA_NV_OWNERREAD)

user controls (TPMA_NV_AUTHREAD and TPMA_NV_AUTHWRITE)

access policy (TPMA_NV_POLICYWRITE,

authPolicy)

additional security attributes: cf. [8], sec. 13.2, table 206, cf. [8] sec. 13.3, table 204

12 RNG

The TPM random number generator

read: read the next random number generated by the TPM (cf. cmd

No security attributes


TCG PUBLIC REVIEW


(RNG) creates random numbers provided to the user and for internal use (e.g. key generation, secrets, nonce).

TPM2_GetRandom),

refresh: provides any data as input to the random number generator to refresh the internal state of the random number generator (cf. cmd TPM2_StirRandom)

13 Credentials

Data object containing encrypted

credential information and the encryption key. It reflects the credential distribution for a key on a TPM.

(cf. Credential Protection ch. 24).

associate of a credential with an object in a way that ensures that the TPM has validated the parameters of the credentialed object.

(cmd TPM2_ActivateCredential)

create the credential which was requested by the CA by encrypting the credential data and creating the credential encryption key

(cmd TPM2_MakeCredential)

No security attributes

14 Clock

Data object representing the TPM time value. It is a volatile value that increments each millisecond that the TPM is powered. A non-volatile value (NV Clock) is updated periodically from Clock.

read: get the current value of time (TPM2_ReadClock, TPM2_GetTime).

advance: modify the value of the TPM’s Clock (TPM2_ClockSet).

adjust: modify the rate of advance of TPM’s Clock (TPM2_ClockRateAdjust).

resetCount: non-volatile counter that is incremented on a successful TPM reset

restartCount: non-volatile counter that is incremented when the TPM executes TPM Resume, TPM Restart or _TPM_Hash_Start

safe flag: non-volatile flag to indicate that an orderly shutdown has occurred

654

7.1.2 Presentation of operations on SFR components 655

The CC allows several operations to be performed on functional requirements; refinement, 656 selection, assignment, and iteration are defined in chapter C.4 of Part 1 of the CC. Each of 657 these operations is used in this PP. 658

The refinement operation is used to add detail to a requirement, and thus further restricts 659 a requirement. Refinement of security requirements is denoted in the changed element in 660 bold text or is added to the component in a paragraph identified by the word “refinement” 661


TCG PUBLIC REVIEW

and printed in bold text. In cases where words from a CC requirement were deleted, the 662 corresponding words are crossed out like this. 663

The selection operation is used to select one or more options provided by the CC in stating 664 a requirement. Selections that have been made by the PP authors are denoted as 665 underlined text and the original text of the component is given by a footnote. Selections to 666 be filled in by the ST author appear in square brackets with an indication that a selection is 667 to be made, [selection:], and are italicised. 668

The assignment operation is used to assign a specific value to an unspecified parameter, 669 such as the values of security attributes. Assignments that have been made by the PP 670 authors are denoted by showing as underlined text and the original text of the component 671 is given by a footnote. Assignments to be filled in by the ST author appear in square 672 brackets with an indication that an assignment is to be made [assignment:], and are 673 italicised. If assignment is performed but require further selection or assignment the 674 operation is printed as underlined text like this [selection:] or [assignment:], and the open 675 operation is printed italicised and underlined. 676

The iteration operation is used when a component is repeated with varying operations. 677 Iteration is denoted by showing a slash “/” and the iteration indicator after the component 678 identifier. 679

7.1.3 SFRs for the General Behavior of the TOE 680

This section contains SFRs that are relevant for the TOE in general or before it is in the 681 operational state. 682

7.1.3.1 Management 683

FMT_SMR.1 Security roles 684

Hierarchical to: No other components. 685 Dependencies: FIA_UID.1 Timing of identification 686

FMT_SMR.1.1 The TSF shall maintain the roles 687

(1) Platform firmware, 688 (2) Platform owner, 689 (3) Privacy Administrator, 690 (4) Lockout Administrator, 691 (5) USER, 692 (6) ADMIN, 693 (7) DUP, 694 (8) World4. 695

FMT_SMR.1.2 The TSF shall be able to associate users with roles. 696

Application note 1: The roles Platform firmware, Platform Owner and Privacy 697 Administrator are defined for the hierarchies. The role Lockout Administrator is used to 698

4 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

reset lockout for authorisation value. The roles USER, ADMIN and DUP are defined for 699 objects and NV Index. 700

FMT_SMF.1 Specification of Management Functions 701

Hierarchical to: No other components. 702 Dependencies: No dependencies. 703

FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 704

(1) Management of hierarchies, 705 (2) Management of authorisation values, 706 (3) Management of security attributes of keys, 707 (4) Management of security attributes of PCR, 708 (5) Management of security attributes of NV storage areas, 709 (6) Management of security attributes of monotonic counters, 710 (7) Reset the Action Flag of TPM dictionary attack mitigation mechanism5. 711

FMT_MSA.2 Secure security attributes 712

Hierarchical to: No other components. 713 Dependencies: [FDP_ACC.1 Subset access control, or 714 FDP_IFC.1 Subset information flow control] 715 FMT_MSA.1 Management of security attributes 716 FMT_SMR.1 Security roles 717

FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for [assignment: list 718 of security attributes]. 719

FPT_STM.1 Reliable time stamps 720 Hierarchical to: No other components. 721 Dependencies: No dependencies. 722

FPT_STM.1.1 The TSF shall be able to provide reliable time stamps as number of 723 milliseconds the TOE has been powered since initialisation of the Clock 724 value. 725

Application note 2: The clock value of the TPM is not an actual universal time clock (UTC). 726 The Clock is a volatile value that increments each millisecond that the TPM is fully powered. 727 If the TPM is powered off or in sleep mode the Clock may not be running or the non-volatile 728 value (NV Clock) may not be updated. It is the responsibility of the caller to associate the 729 ticks to an actual UTC. 730

7.1.3.2 Data Protection and Privacy 731

FDP_RIP.1 Subset residual information protection 732

5 [assignment: list of management functions to be provided by the TSF]


TCG PUBLIC REVIEW


FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is 735 made unavailable upon the deallocation of the resource from6 the following 736 objects: 737 - SPS, 738 - Primary Keys, 739 - User keys, 740 - Context, 741 - PCR data, 742 - NV storage data where (TPMA_NV_PLATFORMCREATE == CLEAR) 743 - Credentials7. 744

7.1.3.3 Cryptographic SFR 745

The TPM offers cryptographic primitives to be used on its external interfaces. Further, 746 cryptographic algorithms are internally used in various situations. Although the TPM 747 library specification defines identifiers for algorithms and parameter sets (where 748 appropriate, see [8]), the concrete set of algorithms is not specified but platform and vendor 749 specific. Hence, the corresponding SFRs (FCS_COP.1) contain open assignments that shall 750 be performed by the ST writer dependent on the intended implementation. 751

The cryptographic key generation provides three different types of keys: ordinary keys, 752 primary keys, and derived keys. Ordinary keys are generated from random bits: The output 753 of the RNG is used to seed the computation of the secret keys that are stored in a shielded 754 location of the TPM. Primary keys are generated from seed values that are usually 755 persistently stored on the TPM. Derived keys are generated from the sensitive value of the 756 parent key. 757

For the generation of keys, seeds and other sensitive data, two different schemes are 758 specified ([7]), one for ECDH and one for all other uses. Both schemes use a hash based key 759 derivation function (KDF), one is called KDFe, for ECDH, and the other KDFa. For the 760 generation of primary keys, [7] specifies an additional scheme which uses a DRBG 761 instantiated with a hierarchy seed. Based on the intended usage of the key, further 762 processing may be required in order to get the appropriate form of the key. 763

FCS_RNG.1 Random number generation 764


FCS_RNG.1.1 The TSF shall provide a [assignment: deterministic, hybrid8] random number 767 generator that implements: NIST SP 800-90A [assignment: Hash_DRBG, 768 HMAC_DRBG, CTR_DRBG] [18]9. 769

6 [selection: allocation of the resource to, deallocation of the resource from] 7 [assignment: list of objects] 8 [selection: physical, deterministic, hybrid] 9 [assignment: list of security capabilities]


TCG PUBLIC REVIEW

FCS_RNG.1.2 The TSF shall provide random numbers that meet: Statistical test suites 770 cannot practically distinguish the random numbers from output sequences of 771 an ideal RNG10. 772

Application note 3: [7], section 11.4.10, describes the RNG in the TPM as hybrid random 773 number generator (RNG), that produces seeds by an entropy source based on physical 774 random processes and the seeds are used for a deterministic random bit generator 775 complying to NIST SP 800-90A [18]. NIST SP 800-90A defines the three types of 776 deterministic random bit generators listed in the SFR and ST author shall identify by 777 assignment in the element FCS_RNG.1.1, which type is implemented in the TOE. The 778 quality metric defined in the element FCS_RNG.1.2 will be fulfilled if the seeds have 779 sufficient entropy and the assigned deterministic random number generator is correctly 780 implemented. The Appendix 8.1 provides more details on evaluation of RNG. The RNG is 781 used internally for generation of Primary Seeds, input to key generation, authorisation 782

values and nonces. 783

FCS_CKM.1/PK Cryptographic key generation (primary keys) 784 Hierarchical to: No other components. 785 Dependencies: [FCS_CKM.2 Cryptographic key distribution, or 786 FCS_COP.1 Cryptographic operation] 787 FCS_CKM.4 Cryptographic key destruction 788

FCS_CKM.1.1/PK The TSF shall generate cryptographic primary [selection: RSA, ECC, 789 symmetric] keys in accordance with a specified cryptographic key generation 790 algorithm [assignment: cryptographic key generation algorithm] and specified 791 cryptographic key sizes [selection: 2048 bits, 256 bits, 384 bits, 128 bits]11 that 792 meet the following: TPM library specification [7], [8], [9], [assignment: list of 793 additional standards].12 794

Application note 4: The two selections shall be performed consistently, i.e. if RSA is 795 selected then the key size shall be 2048 bits, if ECC is selected then the key size shall be 796 256 bits and optionally 384 bits, if symmetric is selected then the key size shall be 128 bits 797 and optionally 256 bits. If more than one primary key generation algorithm is supported by 798 the TOE the ST writer shall iterate the component FCS_CKM.1/PK. 799

Application note 5: The ST author shall specify the used key generation algorithms and 800 key sizes. The TPM library specification [7] defines two key derivation functions called KDFa 801 and KDFe. They use a KDF in counter mode as specified in [22] with HMAC [16] as 802 pseudorandom function. In addition, for the generation of primary keys, [7] defines a DRBG 803 as specified in [18] used as pseudorandom function. In order to generate keys for dedicated 804 algorithms, the generated values may need an appropriate post-processing. Examples for 805 algorithm-specific post-processing are provided in the appendixes B and C of [7], other 806

methods may also be used. The ST writer shall iterate the component FCS_CKM.1 if the 807 TOE supports more than one key generation method. 808

Application note 6: The EPS and/or EK may be generated in the manufacturing 809 environment and injected into the TOE. The manufacturer may only inject an EPS, however, 810

10 [assignment: a defined quality metric] 11 [assignment: cryptographic key sizes] 12 [assignment: list of standards]


TCG PUBLIC REVIEW

an EK cannot be injected without also injecting the EPS. This method is not addressed by 811 this SFR. 812

FCS_CKM.1/RSA Cryptographic key generation (RSA keys) 813 Hierarchical to: No other components. 814 Dependencies: [FCS_CKM.2 Cryptographic key distribution, or 815 FCS_COP.1 Cryptographic operation] 816 FCS_CKM.4 Cryptographic key destruction 817

FCS_CKM.1.1/RSA The TSF shall generate cryptographic RSA keys in accordance with a 818 specified cryptographic key generation algorithm [assignment: cryptographic 819 key generation algorithm] and specified cryptographic key sizes [assignment: 820 cryptographic key sizes] that meet the following: TPM library specification [7], 821 [8], [9], [assignment: list of additional standards].13 822

FCS_CKM.1/ECC Cryptographic key generation (ECC keys) 823 Hierarchical to: No other components. 824 Dependencies: [FCS_CKM.2 Cryptographic key distribution, or 825 FCS_COP.1 Cryptographic operation] 826 FCS_CKM.4 Cryptographic key destruction 827

FCS_CKM.1.1/ECC The TSF shall generate cryptographic ECC keys in accordance with a 828 specified cryptographic key generation algorithm [assignment: cryptographic 829 key generation algorithm] and specified cryptographic key sizes [assignment: 830 cryptographic key sizes] that meet the following: TPM library specification [7], 831 [8], [9], [assignment: list of additional standards].14 832

FCS_CKM.1/SYMM Cryptographic key generation (symmetric keys) 833 Hierarchical to: No other components. 834 Dependencies: [FCS_CKM.2 Cryptographic key distribution, or 835 FCS_COP.1 Cryptographic operation] 836 FCS_CKM.4 Cryptographic key destruction 837

FCS_CKM.1.1/SYMM The TSF shall generate cryptographic symmetric keys in accordance 838 with a specified cryptographic key generation algorithm [assignment: 839 cryptographic key generation algorithm] and specified cryptographic key sizes 840 [assignment: cryptographic key sizes] that meet the following: TPM library 841 specification [7], [8], [9], [assignment: list of additional standards].15 842

Application note 7: The refinements in the SFRs FCS_CKM.1/PK, FCS_CKM.1/ECC, 843 FCS_CKM.1/RSA and FCS_CKM.1/SYMM are defined in order to specify the intended usage 844 of the generated keys more precisely. The algorithms for the generation of these 845

cryptographic keys are dependent on the intended usage of the keys. 846

FCS_CKM.4 Cryptographic key destruction 847

13 [assignment: list of standards] 14 [assignment: list of standards] 15 [assignment: list of standards]


TCG PUBLIC REVIEW

Hierarchical to: No other components. 848 Dependencies: [FDP_ITC.1 Import of user data without security 849

attributes, or 850 FDP_ITC.2 Import of user data with security attributes, or 851 FCS_CKM.1 Cryptographic key generation] 852

FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified 853 cryptographic key destruction method [assignment: cryptographic key 854 destruction method] that meets the following: [assignment: list of standards]. 855

Application note 8: FCS_CKM.4 destroys the cryptographic keys that were used by the 856 operations as defined in FCS_COP.1. The ST author shall specify how the cryptographic 857 keys are destroyed when not required anymore. A possible procedure may be the 858 overwriting with fixed or random data. 859

FCS_COP.1/AES Cryptographic operation (symmetric encryption/decryption) 860 Hierarchical to: No other components. 861 Dependencies: [FDP_ITC.1 Import of user data without security 862

attributes, or 863 FDP_ITC.2 Import of user data with security attributes, or 864 FCS_CKM.1 Cryptographic key generation] 865 FCS_CKM.4 Cryptographic key destruction 866

FCS_COP.1.1/AES The TSF shall perform symmetric encryption and decryption16 in 867 accordance with a specified cryptographic algorithm AES in the mode CFB 868 [selection: CTR, OFB, CBC, and ECB]17 and cryptographic key sizes 128 869 [selection: 192, 256] bits18 that meet the following: NIST Pub 800-38a [23] or 870

ISO/IEC 10116 [28] or ISO/IEC 18033-3 [32]19. 871

Application note 9: The TPM library specification [7], chapter 11.4.6, requires the TOE to 872 implement AES in Cipher Feedback Mode (CFB) and allows support of the other block 873 cipher modes listed for selection in the ST. The PC client specific interface specification [11] 874 recommends that ECB mode should not be used. This selection may be empty. The 875 selection of additional key sizes of AES may be empty. 876

16 [assignment: list of cryptographic operations] 17 [assignment: cryptographic algorithm] 18 [assignment: cryptographic key sizes] 19 [assignment: list of standards]


TCG PUBLIC REVIEW

FCS_COP.1/SHA Cryptographic operation (hash function) 877 Hierarchical to: No other components. 878 Dependencies: [FDP_ITC.1 Import of user data without security 879


FCS_COP.1.1/SHA The TSF shall perform hash value calculation20 in accordance with a 884 specified cryptographic algorithm SHA-1 and SHA-256 [selection: SHA-384]21 885 and cryptographic key sizes none22 that meet the following: FIPS 180-4 [14]23. 886

Application note 10: The TPM shall implement an approved hash algorithm that has 887 approximately the same security strength as its strongest asymmetric algorithm. If the TOE 888 support additional hash functions the ST writer shall iterate the component FCS_COP.1 for 889 these hash functions. The selection may be empty. 890

Application note 11: The usage of the hash algorithms by the TPM shall be implemented 891 in accordance with NIST SP 800-107 [0]. 892

FCS_COP.1/HMAC Cryptographic operation (HMAC calculation) 893 Hierarchical to: No other components. 894 Dependencies: [FDP_ITC.1 Import of user data without security 895


FCS_COP.1.1/HMAC The TSF shall perform HMAC value generation and verification24 in 900 accordance with a specified cryptographic algorithm HMAC with SHA-1 and 901 SHA-256 [selection: SHA-384]25 and cryptographic key sizes [assignment: 902 cryptographic key sizes] that meet the following: FIPS 198-1 [16] or ISO/IEC 903 9797-2 [27]26. 904

20 [assignment: list of cryptographic operations] 21 [assignment: cryptographic algorithm] 22 [assignment: cryptographic key sizes] 23 [assignment: list of standards] 24 [assignment: list of cryptographic operations] 25 [assignment: cryptographic algorithm] 26 [assignment: list of standards]


TCG PUBLIC REVIEW

FCS_COP.1/RSAED Cryptographic operation (asymmetric 905 encryption/decryption) 906



FCS_COP.1.1/RSAED The TSF shall perform asymmetric encryption and decryption27 in 913 accordance with a specified cryptographic algorithm RSA without padding, 914 RSAES-PKCS1-v1_5, RSAES-OAEP28 and cryptographic key sizes 2048 bit29 915 that meet the following: PKCS#1v2.1 [26]30. 916

Application note 12: The TPM library specification part 2 [8] and 3 [9] define RSA 917 encryption schemes 918

- RSA without padding: performing a modular operation with public key for encryption 919 and private key for decryption on the message treated as unsigned integer without 920 any padding (cf. command TPM2_RSA_Encrypt and TPM2_RSA_Decrypt with 921 TPM_ALG_NULL in keyhandle.scheme and inScheme of the command). 922

- RSAES-PKCS1-v1_5 (cf. command TPM2_RSA_Encrypt and TPM2_RSA_Decrypt with 923 TPM_ALG_RSAES in keyhandle.scheme and inScheme of the command) 924

o for encryption: application of the padding algorithm RSAES-PKCS1-v1_5 to the 925 message according to PKCS#1v2.1, chapter 7.2, and then performing a 926 modular operation with public key of keyHandle on the padded message 927 treated as unsigned integer. 928

o for decryption: performing a modular operation with private key of keyHandle 929 on the message treated as unsigned integer application, checking of the 930 padding algorithm according to the message according to PKCS#1v2.1, 931 chapter 7.2, and if padding is correct remove the padding for the decrypted 932 message. 933

- RSAES-OAEP (cf. command TPM2_RSA_Encrypt and TPM2_RSA_Decrypt with 934 TPM_ALG_OAEP in keyhandle.scheme and inScheme of the command) 935

o for encryption: application of the padding algorithm RSAES-OAEP to the 936 message according to PKCS#1v2.1, chapter 7.1, and then performing a 937 modular operation with public key of keyHandle on the padded message 938 treated as unsigned integer. 939

o for decryption: performing a modular operation with private key of keyHandle 940 on the message treated as unsigned integer application, checking of the 941 padding algorithm according to the message according to PKCS#1v2.1, 942

27 [assignment: list of cryptographic operations] 28 [assignment: cryptographic algorithm] 29 [assignment: cryptographic key sizes] 30 [assignment: list of standards]


TCG PUBLIC REVIEW

chapter 7.1, and if padding is correct remove the padding for the decrypted 943 message. 944

FCS_COP.1/RSASign Cryptographic operation (RSA signature 945 generation/verification) 946



FCS_COP.1.1/RSASign The TSF shall perform signature generation and verification31 in 953 accordance with a specified cryptographic algorithm RSASSA_PKCS1v1_5, 954 RSASSA_PSS32 and cryptographic key sizes 2048 bit33 that meet the following: 955 PKCS#1v2.1 [26]34. 956

FCS_COP.1/ECDSA Cryptographic operation (ECC signature 957 generation/verification) 958



FCS_COP.1.1/ECDSA The TSF shall perform signature generation and verification35 in 965 accordance with a specified cryptographic algorithm ECDSA with curve 966 TPM_ECC_NIST_P256 [selection: TPM_ECC_NIST_P384], and [assignment: 967 other elliptic curve]36 and cryptographic key sizes 256 [selection: 384] bit37 that 968 meet the following: FIPS PUB 186-4 [15] or ISO/IEC 14888-3 [30]38. 969

Application note 13: The signature-creation is provided by the command TPM2_Sign and 970 the signature verification is provided by the command TPM2_VerifySignature. The elliptic 971 curve TPM_ECC_NIST_P256 is defined in FIPS PUB 186-4, section D.1.2.3. The optional 972 curve TPM_ECC_NIST_P384 is defined in section D.1.2.4. The ST writer shall assign any 973 other elliptic curve supported for signature creation and verification but this assignment 974 may be empty if no other elliptic curve is supported. 975

FCS_COP.1/ECDAA Cryptographic operation (ECDAA commit) 976

31 [assignment: list of cryptographic operations] 32 [assignment: cryptographic algorithm] 33 [assignment: cryptographic key sizes] 34 [assignment: list of standards] 35 [assignment: list of cryptographic operations] 36 [assignment: cryptographic algorithm] 37 [assignment: cryptographic key sizes] 38 [assignment: list of standards]


TCG PUBLIC REVIEW



FCS_COP.1.1/ECDAA The TSF shall perform signature generation39 in accordance with a 983 specified cryptographic algorithm ECDAA with curve TPM_ECC_NIST_P256 and 984 TPM_ECC_BN_P256 [selection: TPM_ECC_NIST_P384 and TPM_ECC_BN_P384] 985 [assignment: other elliptic curve]40 and cryptographic key sizes 256 [selection: 986 384]41 that meet the following: TPM library specification [7]42. 987

Application note 14: The ECDAA sign operation is a modified Schnorr signature using 988

ECDAA signing keys normally based on Barreto-Naehrig elliptic curve TPM_ECC_BN_P256 989 and optionally TPM_ECC_BN_P384 but the TOE may support other elliptic curves as well. 990 The TPM_ECC_BN_P256 and TPM_ECC_BN_P384 are Barreto-Naehrig (BN) elliptic curves 991 as defined in [ISO/IEC 15946-5: 2008 Clause 7.3 “BN curve”]. The first step of ECC 992 anonymous signing operation is provided by command TPM2_Commit. The output is then 993 used by command TPM2_Sign. The ST writer shall select TPM_ECC_NIST_P256 and 994 TPM_ECC_BN_P256 and shall assign any other elliptic curve if supported for ECDAA. Both 995 commands TPM2_Commit and TPM2_Sign shall use the same elliptic curve in order to run 996 ECDAA protocol. 997

Application note 15: The ECDAA algorithm is not recognised by NIST as approved 998 algorithm. 999

FCS_COP.1/ECDEC Cryptographic operation (decryption) 1000 Hierarchical to: No other components. 1001 Dependencies: [FDP_ITC.1 Import of user data without security 1002


FCS_COP.1.1/ECDEC The TSF shall perform decryption of ECC key43 in accordance with a 1007 specified cryptographic algorithm ECDH with curve [selection: 1008 TPM_ECC_NIST_P256, TPM_ECC_NIST_P384, TPM_ECC_BN_P256, 1009 TPM_ECC_BN_P384], [assignment: other elliptic curve]44 and cryptographic key 1010 sizes 256 bit [selection: 384 bit]45 that that meet the following: TPM library 1011

39 [assignment: list of cryptographic operations] 40 [assignment: cryptographic algorithm] 41 [assignment: cryptographic key sizes] 42 [assignment: list of standards] 43 [assignment: list of cryptographic operations] 44 [assignment: cryptographic algorithm] 45 [assignment: cryptographic key sizes]


TCG PUBLIC REVIEW

specification [7], NIST Special Publication 800-56A [20] or ISO/IEC 15946-1 1012 [31]46. 1013

Application note 16: The key decryption is implemented in the command 1014 TPM2_ECDH_ZGen. 1015

7.1.3.4 Identification and Authentication SFR 1016

The TPM identification and authentication capability is used to authorise the use of a 1017 Protected Object and Protected Capability. Note that the TCG Library Specification 1018 document refers to the identification and authentication process and access control as 1019 authorisation. Two basic mechanisms are provided for authentication: 1020

the prove of knowledge of a shared secret, i.e. password or a secret for HMAC, 1021 assigned to the entity as authValue; and 1022

the authentication of the user and verification of an intended state of the TPM and its 1023 environment encoded in authPolicy and assigned to the entity. 1024

The authorisation may be for a command only or session based. The session type defines 1025 the used authorisation as HMAC session or policy session. 1026

The authValue is linked to user roles. The authValue may be known or set to a randomly 1027 generated value. If the authValue is set to a randomly generated value it will be unknown to 1028 the user and the authentication is blocked. The authPolicy may be empty or set. If the 1029 authPolicy is set to 0 no authentication is possible. If the authPolicy is set it may require 1030 more than authentication of the user, cf. FIA_UAU.5.2 for the list of assertions a authPolicy 1031 may contain. 1032

The session based authorisation uses handles and random nonces. The handle is assigned 1033 when the session is created and identifies the session until the session is closed. The 1034 session requires that a nonce shall be used only for one message and its reply. For 1035 instance, the TPM would create a nonce and send that in a reply. The requestor would 1036 receive that nonce (nonceOlder), generates its own nonce (nonceNewer) and includes both 1037 values in the calculation of the command-dependent authentication value. Then, the caller 1038 sends the command, the authentication value and nonceNewer to the TPM which checks 1039 the authentication value with the knowledge of both nonces and executes the command on 1040 success. The nonces link commands in the command chain and commands and responses. 1041

Protected entities and their authentication data may be stored persistently in the TPM or 1042 outside the TPM. Note that cryptographic keys are considered as entities and do not 1043 undergo a special handling, hence this protection profile does not contain special 1044 requirements for the key management. 1045

FIA_SOS.2 TSF Generation of secrets 1046 Hierarchical to: No other components. 1047 Dependencies: No dependencies. 1048

FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet uniform 1049 distribution of random variable generating the value.47 1050

46 [assignment: list of standards]


TCG PUBLIC REVIEW

FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for 1051 (1) nonce values for authorisation sessions. 1052

Application note 17: The TSF shall take the values to generate nonce from the RNG. 1053

FMT_MSA.4/AUTH Security attribute value inheritance 1054 Hierarchical to: No other components. 1055 Dependencies: [FDP_ACC.1 Subset access control, or 1056 FDP_IFC.1 Subset information flow control] 1057

FMT_MSA.4.1/AUTH The TSF shall use the following rules to set the value of security 1058 attributes: 1059 (1) The bits userWithAuth and adminWithPolicy in the TPMA_OBJECT of an 1060

object are defined when the object is created and can never be changed. 1061

(2) User authorised by policy session is allowed to change the authPolicy by 1062 means of command TPM2_PolicyAuthorize or TPM2_PolicyAuthorizeNV.48 1063

Application note 18: The SFR FMT_MSA.4 describes management of authValue, which 1064 disables not only authentication data, but also management of authPolicy as security 1065 attributes for access control to objects. 1066

FMT_MTD.1/AUTH Management of TSF data (user authorisation) 1067 Hierarchical to: No other components. 1068 Dependencies: FMT_SMR.1 Security roles 1069 FMT_SMF.1 Specification of Management Functions 1070

FMT_MTD.1.1/AUTH The TSF shall restrict the ability to 1071 (1) set49 the platformAuth and platformPolicy50 to the role Platform 1072

firmware51; 1073 (2) set52 the endorsementAuth and endorsementPolicy53 to the role Platform 1074

Owner54; 1075 (3) set55 the endorsementAuth and endorsementPolicy 56 to the role Privacy 1076

Administrator57, 1077 (4) set by TPM2_Duplicate58 the AuthValue or policyAuth of the object 1078

under the new parent to the same AuthValue or policyAuth of the 1079 duplicated object under the old parent59 to the role DUP60. 1080

47 [assignment: a defined quality metric] 48 [assignment: rules for setting the values of security attributes] 49 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 50 [assignment: list of TSF data] 51 [assignment: the authorised identified roles] 52 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 53 [assignment: list of TSF data] 54 [assignment: the authorised identified roles] 55 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 56 [assignment: list of TSF data] 57 [assignment: the authorised identified roles] 58 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 59 [assignment: list of TSF data] 60 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

(5) change61 the lockout parameters (TPM2_DictionaryAttackParameters)62 1081 to the Lockout administrator63. 1082

FIA_AFL.1/Recover Authentication failure handling (recovery) 1083 Hierarchical to: No other components. 1084 Dependencies: FIA_UAU.1 Timing of authentication. 1085

FIA_AFL.1.1/Recover The TSF shall detect when maxTries64 of unsuccessful authentication 1086 attempts occur related to unsuccessful password or HMAC authentication 1087 attempts for 1088

(1) objects where DA is active (i.e. noDA attribute is CLEAR) 1089 (2) NV Index where DA is active (i.e. the TPMA_NV_NO_DA attribute is 1090

CLEAR)65. 1091

FIA_AFL.1.2/Recover When the defined number of unsuccessful authentication attempts has 1092 been met66, the TSF shall block the authorisations for RecoveryTime 1093 seconds67. 1094 The counter failedTries is incremented when the authentication attempt failed. 1095 The counter failedTries is decremented by one after recoveryTime seconds if: 1096

(1) the TPM does not record an authorisation failure of a DA-protected 1097 entity, 1098

(2) there is no power interruption, and 1099 (3) failedTries is not zero. 1100

The counter failedTries is reset to 0 by 1101 (1) command TPM2_Clear() 1102 (2) TPM2_DictionaryAttackLockReset() with lockoutAuth. 1103

Application note 19: The refinement describes the failedTries behaviour the TPM can “self-1104 heal” after a specified amount of time or be programmatically reset using proof of knowledge 1105 of an authorisation value. 1106

FIA_AFL.1/Lockout Authentication failure handling (lockout) 1107 Hierarchical to: No other components. 1108 Dependencies: FIA_UAU.1 Timing of authentication. 1109

FIA_AFL.1.1/Lockout The TSF shall detect when 168 unsuccessful authentication attempts 1110 occur related to failed authentication attempts with lockoutAuth using 1111 command TPM2_DictionaryAttackLockReset()69. 1112

61 [selection: change_default, query, modify, delete, [assignment: other operations]] 62 [assignment: list of TSF data] 63 [assignment: the authorised identified roles] 64 [assignment: positive integer number], an administrator configurable positive integer within

[assignment: range of acceptable values]] 65 [assignment: list of authentication events] 66 [selection: met, surpassed] 67 [assignment: list of actions] 68[assignment: positive integer number], an administrator configurable positive integer within

[assignment: range of acceptable values]] 69 [assignment: list of authentication events]


TCG PUBLIC REVIEW

FIA_AFL.1.2/Lockout When the defined number of unsuccessful authentication attempts has 1113 been met70, the TSF shall block the TPM2_DictionaryAttackLockReset 1114 command for lockoutRecovery seconds71. 1115

FIA_AFL.1/PINPASS Authentication failure handling 1116

Hierarchical to: No other components. 1117 Dependencies: FIA_UAU.1 Timing of authentication. 1118

FIA_AFL.1.1/PINPASS The TSF shall detect when pinCount72 successful authentication events 1119 exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_PASS. 1120

FIA_AFL.1.2/ PINPASS When the defined number of successful authentication events has been 1121 met73, the TSF shall block further authorization attempts74. 1122

FIA_AFL.1/PINFAIL Authentication failure handling 1123


FIA_AFL.1.1/PINFAIL The TSF shall detect when pinCount75 unsuccessful authentication 1126 attempts exceeds pinLimit for an NV Index with the attribute 1127 TPM_NT_PIN_FAIL76. 1128

FIA_AFL.1.2/ PINFAIL When the defined number of unsuccessful authentication attempts has 1129 been met77, the TSF shall block further authorization attempts78. 1130

FIA_UID.1 Timing of identification 1131


FIA_UID.1.1 The TSF shall allow 1134 (1) to execute indication _TPM_Hash_Start, _TPM_Hash_Data and 1135

_TPM_Hash_End, 1136 (2) to execute commands that do not require authentication, 1137 (3) to access objects where the entity owner has defined no authentication 1138

requirements (authValue, authPolicy), 1139 (4) [assignment: other TSF-mediated actions]79 1140 on behalf of the user to be performed before the user is identified. 1141

70 [selection: met, surpassed] 71 [assignment: list of actions] 72 [assignment: positive integer number], an administrator configurable positive integer within

[assignment: range of acceptable values]] 73 [selection: met surpassed] 74 [assignment: list of actions] 75 [selection: [assignment: positive integer number], an administrator configurable positive integer

within [assignment: range of acceptable values]] 76 [assignment: list of authentication events] 77 [selection: met surpassed] 78 [assignment: list of actions] 79 [assignment: list of TSF-mediated actions]


TCG PUBLIC REVIEW

FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing 1142 any other TSF-mediated actions on behalf of that user, e.g. self-test. 1143

FIA_UAU.1 Timing of authentication 1144 Hierarchical to: No other components. 1145 Dependencies: FIA_UID.1 Timing of identification 1146

FIA_UAU.1.1 The TSF shall allow 1147 (1) to execute indication _TPM_Hash_Start, _TPM_Hash_Data and 1148

_TPM_Hash_End, 1149 (2) to execute commands that do not require authentication, 1150 (3) to access objects where the entity owner has defined no authentication 1151

requirements (authValue, authPolicy)80 1152 on behalf of the user to be performed before the user is authenticated. 1153

FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before 1154 allowing any other TSF-mediated actions on behalf of that user. 1155

Application note 20: The commands that do not require authorisation are listed 1156 informatively in Table 11 of [7] and defined in [8]. 1157

FIA_UAU.5 Multiple authentication mechanisms 1158 Hierarchical to: No other components. 1159 Dependencies: No dependencies. 1160

FIA_UAU.5.1 The TSF shall provide 1161 (1) Password based authentication mechanism, 1162 (2) HMAC based authentication mechanism, 1163 (3) Policy based authentication mechanism81 1164 to support user authentication. 1165

FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the 1166 following rules: 1167 (1) If userWithAuth in the TPMA_OBJECT bits is set, for operations that 1168

require USER role, authorisation may be given if the caller provides proof of 1169 knowledge of the authValue of the object with an HMAC authorisation 1170 session or a password. If this attribute is CLEAR, then HMAC or password 1171 authorisations may not be used for USER role authorisations. 1172

(2) If the adminWithPolicy in the TPMA_OBJECT bits is set then HMAC or 1173 password authorisations may not be used for ADMIN role authorisations. If 1174 this attribute is CLEAR, then authorisation for operations that require 1175 ADMIN role may be given if the caller provides proof of knowledge of the 1176

authValue of the object with an HMAC authorisation session or a password. 1177 (3) A password based authentication mechanism is required if the authHandle 1178

parameter of the command shall contain TPM_RS_PW. 1179

80 [assignment: list of TSF mediated actions] 81 [assignment: list of multiple authentication mechanisms]


TCG PUBLIC REVIEW

(4) A HMAC or policy based authentication is required if the authHandle 1180 parameter of the command contain a valid handle of an authorisation 1181 session. 1182

(a) A HMAC based authentication is required if the authorisation 1183 session shall be created with a sessionType of TPM_SE_HMAC, 1184

(b) A policy based authentication is required if the authorisation session 1185 shall be created with a sessionType of TPM_SE_POLICY. 1186

(5) A policy based authentication mechanism verifies that a policy session 1187 provides a sequence of policy assertions combined in logical AND and OR 1188 relations, which policyDigest matches the authPolicy associated with the 1189 object and the other conditions of a policy session context are fulfilled. The 1190 assertions may express conditions for 1191

(a) successful authentication with authValue defined for the 1192 authorised entity and the object to be accessed, 1193

(b) the command code of the authorised command to be executed, 1194 (c) the cpHash of the authorised command to be executed, 1195 (d) special condition for command TPM2_Duplicate(), 1196 (e) the locality of the authorised command to be executed, 1197 (f) the referenced object handle, 1198 (g) the current system time, 1199 (h) the content of the NV memory, 1200 (i) the value of selected PCR, 1201 (j) the assertion of physical presence if supported by the TOE, 1202 (k) the value of a shared secret, 1203 (l) the presence of a valid signature of the given parameters, 1204 (m) the value of the TPMA_NV_WRITTEN attribute of the specified NV 1205

index, 1206 (n) the value of the TPM_NT_PIN_PASS attribute of the specified NV 1207

index, 1208 (o) the value of the TPM_NT_PIN_FAIL attribute of the specified NV 1209

index, 1210 (p) the key template of the commands TPM2_CreatePrimary, 1211

TPM2_Create, and TPM2_CreateLoaded, 1212 (q) the validity of a Ticket. 1213

The TSF shall update the representation of the state of the TPM and its 1214 environment (policyDigest) on execution of the enhanced authorisation 1215 commands defined in [9] section 25. The result of the updated policyDigest 1216 shall depend on the called command and its dedicated parameters. 1217

(6) The command TPM2_PolicyRestart shall reset a policy authorisation 1218 session to its initial state.82 1219

Application note 21: The ST writer shall describe the implemented methods for 1220 physical presence authorisation if supported by the TOE. The Password based 1221 authentication mechanism can be used by human user because it does not need any 1222 cryptographic calculation for authentication as required in HMAC based authentication 1223 mechanism. The policy based authentication mechanism is described in [7], chapter 19. 1224 The policyDigest can be computed in a trial session simulating the policy session required 1225

82 [assignment: rules describing how the multiple authentication mechanisms provide authentication]


TCG PUBLIC REVIEW

for authorisation, read from the TPM by means of the command TPM2_PolicyGetDigest and 1226 used as an object's authPolicy. 1227

FIA_UAU.6 Re-authenticating 1228 Hierarchical to: No other components. 1229 Dependencies: No dependencies. 1230

FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions that multiple 1231 commands need to be executed in one authorisation session.83 1232

FIA_USB.1 User-subject binding 1233 Hierarchical to: No other components. 1234 Dependencies: FIA_ATD.1 User attribute definition 1235

FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects 1236

acting on the behalf of that user: 1237 (1) the shared secret for the TPM objects to access (sessionKey), 1238 (2) the handle of opened authentication session, 1239 (3) the physical presence if supported by the TOE and asserted, 1240 (4) the state of the TPM and its environment (policyDigest)84. 1241

FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user 1242 security attributes with subjects acting on the behalf of users: 1243 (1) The TSF shall initialise the policyDigest value representing the state of the 1244

TPM and its environment with a zero digest (0…0). This shall take place at 1245 execution of the command TPM2_StartAuthSession85. 1246

FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user 1247 security attributes associated with subjects acting on the behalf of users: 1248 (1) The TSF shall create the shared secret (sessionKey) and the session handle 1249

in case of a session based authorisation using the command 1250 TPM2_StartAuthSession. 1251

(2) The TSF shall invalidate the shared secret (sessionKey) and the session 1252 handle in each of the following situations: 1253

(a) The command TPM2_FlushContext is executed for the corresponding 1254 session handle. 1255

(b) The flag continueSession of the session attributes is cleared. 1256 (c) The command TPM2_Startup is executed with the argument 1257

TPM_SU_CLEAR or TPM_SU_STATE.86. 1258

7.1.3.5 TSF Protection 1259

FPT_TST.1 TSF testing 1260

83 [assignment: list of conditions under which re-authentication is required] 84 [assignment: list of user security attributes] 85 [assignment: rules for the initial association of attributes] 86 [assignment: rules for the changing of attributes]


TCG PUBLIC REVIEW


FPT_TST.1.1 The TSF shall run a suite of self tests 1263

(1) at the request of the authorised user “World” 1264 (a) the TPM2_SelfTest command and of selected algorithms using the 1265

TPM2_IncrementalSelfTest command, 1266

(2) at the conditions 1267 (a) Initialisation state after reset and before the reception of the first 1268

command, 1269 (b) prior to execution of a command using a not self-tested function, 1270

(3) [assignment: further conditions under which self test should occur]87 1271

to demonstrate the correct operation of sensitive parts of the TSF88. 1272

FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the 1273 integrity of [assignment: parts of TSF data]89. 1274

FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the 1275 integrity of the TSF90. 1276

Application note 22: The ST writer shall define additional conditions in FPT_TST.1.1 in 1277 case that the TPM manufacturer implements additional self tests. 1278

FPT_FLS.1/FS Failure with preservation of secure state (fail state) 1279 Hierarchical to: No other components. 1280 Dependencies: No dependencies. 1281

FPT_FLS.1.1/FS The TSF shall preserve a secure state by entering the Fail state when 1282 the following types of failures occur: 1283 (1) If during TPM Restart or TPM Resume, the TPM fails to restore the state 1284

saved at the last Shutdown(STATE), the TPM shall enter Failure Mode and 1285 return TPM_RC_FAILURE. 1286

(2) failure detected by TPM2_ContextLoad when the decrypted value of 1287 sequence is compared to the stored value created by TPM2_ContextSave(), 1288

(3) failure detected by self-test according to FPT_TST.1, 1289 (4) [assignment: list of additional types of failures in the TSF]91 1290

Application note 23: The ST writer shall perform the missing operation in the element 1291 FPT_FLS.1/FS according to the additional types of failures for which the TSF preserve a 1292 secure state if implemented by the TOE. The assignment may be “none” if no additional 1293

87 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions[assignment: conditions under which self test should occur]]

88 [selection: [assignment: parts of TSF], the TSF] 89 [selection: [assignment: parts of TSF data], TSF data] 90 [selection: [assignment: parts of TSF], TSF] 91 [assignment: list of types of failures in the TSF]


TCG PUBLIC REVIEW

types of failures are handled by the TSF. For case (2) in element FPT_FLS.1.1 refer to TPM 1294 spec part 3 chapter 11.3.1. 1295

FPT_FLS.1/SD Failure with preservation of secure state (shutdown) 1296 Hierarchical to: No other components. 1297 Dependencies: No dependencies. 1298

FPT_FLS.1.1/SD The TSF shall preserve a secure state by shutdown when the following 1299 types of failures occur: 1300 (1) detection of a physical attack, 1301 (2) detection of environmental condition out of spec values92. 1302

FPT_PHP.3 Resistance to physical attack 1303 Hierarchical to: No other components. 1304

Dependencies: No dependencies. 1305

FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing 1306

[assignment: additional physical tampering scenarios]93 to the TSF94 by 1307

responding automatically such that the SFRs are always enforced. 1308

Application note 24: The ST writer shall perform the missing operation in the element 1309 FPT_PHP.3 by adding specific physical tampering scenarios for which resistance is claimed 1310 for the specific TOE. This assignment may be empty. 1311

1312

FDP_ITT.1 Basic internal transfer protection 1313 Hierarchical to: No other components. 1314 Dependencies: [FDP_ACC.1 Subset access control, or 1315 FDP_IFC.1 Subset information flow control.] 1316

FDP_ITT.1.1 The TSF shall enforce the TPM state control, TPM Object Hierarchy, 1317

Data import and export, Measurement and reporting, Access 1318

Control, NVM and Credential SFPs 95to prevent the disclosure96 of user 1319

data when it is transmitted between physically-separated parts of the 1320

TOE 1321

Refinement: even for single chip implementations, the different memories, the CPU 1322

and other functional units of the TOE (e.g. a cryptographic co-processor) are seen as 1323

physically-separated parts of the TOE. 1324

FPT_ITT.1 Basic internal TSF data transfer protection 1325

92 [assignment: list of types of failures in the TSF] 93 [assignment: physical tampering scenarios] 94 [assignment: list of TSF devices/elements] 95 [assignment: access control SFP(s) and/or information flow control SFP(s)] 96 [selection : disclosure, modification, loss of use]


TCG PUBLIC REVIEW

Hierarchical to: No other components. 1326 Dependencies: No dependencies 1327

FPT_ITT.1.1 The TSF shall protect TSF data from disclosure97 when it is transmitted 1328

between separate parts of the TOE. 1329

Refinement: even for single chip implementations, the different memories, the CPU 1330

and other functional units of the TOE (e.g. a cryptographic co-processor) are seen as 1331

physically-separated parts of the TOE. 1332

1333

7.1.4 SFRs Concerning the Object Hierarchy of the TOE 1334

This section contains SFRs that affect the internal object hierarchy of the TOE. 1335

7.1.4.1 TPM Operational States 1336

The TOE internal states can be considered in different ways and abstraction levels. In this 1337 section the TPM is observed on the abstraction level as described in chapter 12 of [7]. Figure 1338 3 summarises the states and state transitions of the TPM that are used in the subsequent 1339 SFRs. The introduced states can be explained as follows: 1340

Power-Off state: A hardware TPM is in power-off state when no power is applied to 1341 the TPM, or the power is on and a reset is being asserted. This state may be reached 1342 from any other state because power can be lost at any time. In that sense, Figure 3 1343 is incomplete because not all possible state transitions are shown for clarity reasons. 1344 The TPM does not execute any function except transition to the Init state when it 1345 receives the _TPM_Init indication. 1346

Initialisation state: The TPM enters this state when it receives the _TPM_Init 1347 indication. This indication is provided in a platform-specific manner (cf. section 1348 12.2.2 of [7] for details). In the Init state, only the commands TPM2_Startup and field 1349 upgrade and the indication of _TPM_Hash_Start, _TPM_Hash_Data and 1350 _TPM_Hash_End are accepted. All other commands do not change the state and 1351 imply an error return code. The TPM may perform self-test in the Init state and may 1352 enter Failure mode if the self-test detects any failure. 1353

FUM: The Field Upgrade Mode is described in the specification [7] in section 12.5 as 1354 an optional and vendor specific capability for upgrading the TPM firmware. The 1355 specification does not define the detailed behavior of Field Upgrade Mode and allows 1356 vendor specific implementation. According to the library specification the TPM enters 1357 the FUM from operational or Init state after receiving the command 1358 TPM2_FieldUpgradeStart and successful integrity and authenticity validation of the 1359 first upgrade data block, accepts TPM2_FieldUpgradeData commands only in FUM 1360 and exits FUM returning to normal operation or entering a mode that requires 1361 _TPM_Init before normal operations resume. The Field Upgrade Mode can also be 1362 reached after TPM_Init if Field upgrade loading process has been interrupted and 1363 needs to be resumed before the TPM returns to operational state. The TPM shall 1364 perform integrity and authenticity check, but may implement vendor specific 1365

97 [selection : disclosure, modification]


TCG PUBLIC REVIEW

authorisation or vendor specific commands and related state transitions for FUM. 1366 The informative Figure 3 denotes these possible state transitions with dashed lines. 1367

Operational state: In this state the TPM was successfully initialised. The 1368 initialisation of the operational status of the TPM is done by the TPM2_Startup 1369 command and may restore a previously (by TPM2_Shutdown) saved status. Details 1370 are defined in section 12.2.3 and 12.2.4 of [7]. In that state, no restrictions of the 1371 accepted command set exists. Before the TPM may return a result based on a 1372 cryptographic algorithm, it is required to perform a specific self-test of that 1373 algorithm. If a command requires use of an untested algorithm or functional module, 1374 the TPM performs the test and then completes the command actions. This behavior 1375 is modeled in Figure 3 using a state transition to Self-Test. 1376 Please note that the TPM2_Shutdown command does not imply a reset nor any state 1377 change of the TPM: It is used to prepare the TPM for a power cycle and may be used 1378 to save the operational status of the TPM for a later restore. Details can be found in 1379 section 9.4 of [9]. 1380

Self-Test state: This state implements the required tests of cryptographic algorithms 1381 and is not triggered by a dedicated TPM command. When performing a self-test on 1382 demand, the TPM should test only those algorithms needed to complete the 1383 command. The command TPM2_SelfTest may optionally cause the TPM to trigger a 1384 full self-test of all algorithms and functional blocks. Depending on the result, the 1385 TPM changes its state back to Operational or to Fail after completion of the self-test. 1386

Fail state: In Fail state the TPM does not allow any command except 1387 TPM2_GetTestResult and TPM2_GetCapability. The only way to exit Fail state is 1388 when it receives _TPM_Init. 1389

1390

Figure 3: States of the TPM and its Transitions (informative) 1391

Application note 25: Figure 3 illustrates the transitions between the TPM operational 1392 states as defined in the library specification, chapter 12 of [7]. The Field Upgrade Mode is 1393 vendor specific. The state transition and the commands TPM2_FieldUpgradeStart and 1394 TPM2_FieldUpgradeData shown in Figure 3 as described in the library specification are 1395 optional. 1396


TCG PUBLIC REVIEW

The following table defines additional objects, operations and security attributes for the 1397 TPM state control SFP: 1398

Table 9: Objects, operations and security attributes for the TPM state control SFP 1399


1 Shutdown BLOB

A set of variables that represent the operational status of the TPM as it is in the Operational state (see Figure 3).

Generate

The shutdown BLOB is written to the NV memory by the command TPM2_Shutdown with parameter TPM_SU_STATE.

Resume

The shutdown BLOB is read from the NV memory by the command TPM2_Startup with parameter TPM_SU_STATE. The operational variables are restored with the values from the shutdown BLOB. This is called “TPM RESUME”, see section 9.3 in [9].

Restart

The shutdown BLOB is read from the the NV memory by the command TPM2_Startup with the parameter TPM_SU_CLEAR. Some operational variables are restored with the values from the shutdown BLOB. This is called “TPM RESTART”, see section 9.3 in [9].


Validation status, used to check the validity of the Shutdown BLOB. After Generation of the Shutdown BLOB its validation status is positive. The execution of some commands may invalidate this status.

The conditions that invalidate this validation status are defined in section 12.2.4 of [7]. In that document the BLOB is called “saved TPM state”.

2 Firmware update data

Data provided by the vendor in order to replace the firmware or parts of the firmware.

TPM2_FieldUpgradeStart():

Entering FUM and accepting the first data block of Firmware update data

TPM2_FieldUpgradeData()

Read the following Firmware update data blocks.

Authorisation data for TPM2_FieldUpgradeStart():

platformAuth, platformPolicy: hierarchy authorisation to change platform policy or auth and disable the platform hierarchy.

Security attributes of firmware update data:

Signature over the first or the complete digest of Firmware update


TCG PUBLIC REVIEW


data, generated by the TPM manufacturer

Digest over each block or the complete Firmware update data

1400

FDP_ACC.2/States Complete access control (operational states) 1401 Hierarchical to: FDP_ACC.1 Subset access control 1402 Dependencies: FDP_ACF.1 Security attribute based access control 1403

FDP_ACC.2.1/States The TSF shall enforce the TPM State Control SFP98 on all subjects and 1404 objects99 and all operations among subjects and objects covered by the SFP. 1405

FDP_ACC.2.2/States The TSF shall ensure that all operations between any subject controlled 1406 by the TSF and any object controlled by the TSF are covered by an access 1407 control SFP. 1408

FDP_ACF.1/States Security attribute based access control (operational states) 1409 Hierarchical to: No other components. 1410 Dependencies: FDP_ACC.1 Subset access control 1411 FMT_MSA.3 Static attribute initialisation 1412

FDP_ACF.1.1/States The TSF shall enforce the TPM State Control SFP100 to objects based on 1413 the following 1414 Subjects as defined in Table 7: 1415 (1) Platform firmware with the security attributes platformAuth, platformPolicy 1416

and physical presence if supported by the TOE, 1417 (2) all other subjects; their security attributes are irrelevant for this SFP, 1418 Objects as defined in Table 8 and Table 9: 1419 (1) Shutdown BLOB with the security attribute validation status, 1420 (2) Firmware update data with security attributes signature of the TPM 1421

manufacturer and digest, 1422 (3) all other objects; their security attributes are irrelevant for this SFP101. 1423

FDP_ACF.1.2/States The TSF shall enforce the following rules to determine if an operation 1424 among controlled subjects and controlled objects is allowed: 1425 (1) The [assignment: authorised role] is authorised to change the TPM state to 1426

FUM if the authenticity of the first digest or the signature could be 1427 successfully verified. 1428

(2) While in FUM state the Platform firmware is authorised to import or 1429 activate firmware data only after successful verification of its integrity and 1430 authenticity (see FDP_UIT.1/States). 1431

98 [assignment: access control SFP] 99 [assignment: list of subjects and objects] 100 [assignment: access control SFP] 101 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-

relevant security attributes, or named groups of SFP-relevant security attributes]


TCG PUBLIC REVIEW

(3) The FUM state shall only be left when [assignment: rules for a state 1432 transition from FUM to another state]. 1433

(4) In the Init state the subject “World” is authorised to execute the commands 1434 TPM2_HashSequenceStart, TPM2_SequenceUpdate, TPM2_EventSequence-1435 Complete, TPM2_SequenceComplete, TPM2_PCR_Extend, TPM2_Startup, 1436 TPM2_SelfTest, TPM2_GetRandom, TPM2_HierarchyControl, TPM2_Hierar-1437 chyChangeAuth, TPM2_SetPrimaryPolicy, TPM2_GetCapability, 1438 TPM2_NV_Read, and the sequence _TPM_Hash_Start, _TPM_Hash_Data, 1439 and _TPM_Hash_End. 1440

(5) In the Init state every subject is authorised to process the Resume 1441 operation on the Shutdown BLOB with state transition to Operational. 1442

(6) In the Init state every subject is authorised to process the Restart operation 1443 on the Shutdown BLOB with state transition to Operational. 1444

(7) In the Init state, if no Shutdown BLOB was generated or if the Shutdown 1445

BLOB is invalid (see attribute “Validation status”) every subject is 1446 authorised to process the TPM2_Startup command. In case of the 1447 parameter TPM_SU_CLEAR the TPM shall change the state to Operational 1448 and initialise its internal operational variables to default initialisation 1449 values (Reset), otherwise the TPM shall return an error and stay in the 1450 same state. 1451

(8) In the Operational state, nobody is authorised to execute the command 1452 TPM2_Startup. For all other subjects, objects and operations, the access 1453 control rules of the Access Control SFP shall apply (see FDP_ACF.1/AC). 1454

(9) The Operational state shall change to Self-Test state if one of the 1455 commands TPM2_Selftest or TPM2_IncrementalSelfTest is executed or 1456 when a test of a dedicated functionality is required (see FPT_TST.1). In the 1457 Self-Test state, nobody is authorised to execute any other TPM command. 1458

(10) The Self-Test state shall be left only after finishing the intended test of 1459 the dedicated functionality. In case of a successful test result the state 1460 shall change to Operational, otherwise to Fail. 1461

(11) In the Fail state, every subject is authorised to execute the commands 1462 TPM2_GetTestResult and TPM2_GetCapability. 1463

(12) In the Fail state the subject World is authorised to send a _TPM_Init 1464 indication with state change to Init. 1465

(13) Any subject is authorised to prepare the TPM for a power cycle using 1466 the TPM2_Shutdown command and to create a shutdown BLOB by 1467 TPM2_Shutdown(TPM_SU_STATE).102 1468

FDP_ACF.1.3/States The TSF shall explicitly authorise access of subjects to objects based on 1469 the following additional rules: [assignment: rules, based on security attributes, 1470 that explicitly authorise access of subjects to objects]. 1471

FDP_ACF.1.4/States The TSF shall explicitly deny access of subjects to objects based on the 1472 following additional rules: 1473

102 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]


TCG PUBLIC REVIEW

(1) Once the TPM receives a TPM2_SelfTest command and before completion of 1474 all tests, the TPM shall return TPM_RC_TESTING for any command that 1475 uses a command that requires a test.103 1476

Application note 26: The ST writer shall define additional rules in FDP_ACF.1.2/States for 1477 the state transitions while the TPM is in FUM. Section 12.5 of [7] describes optional 1478 protected capabilities for upgrading the TPM firmware. 1479

Application note 27: The _TPM_Init indication is normally signaled by the de-assertion of 1480 the TPM’s reset signal. It may also be signaled by an interface protocol or setting. 1481

Application note 28: When parts of the TSF or the complete TSF is replaced by a firmware 1482 update then the entire TOE needs to be considered as replaced by installation of another 1483 TOE. 1484

FMT_MSA.1/States Management of security attributes (operational states) 1485 Hierarchical to: No other components. 1486 Dependencies: [FDP_ACC.1 Subset access control, or 1487 FDP_IFC.1 Subset information flow control] 1488 FMT_SMR.1 Security roles 1489 FMT_SMF.1 Specification of Management Functions 1490

FMT_MSA.1.1/States TSF shall enforce the TPM state control SFP104 to restrict the ability to 1491 modify105 the security attributes TPM state 1492 (1) FUM106 to Platform firmware107, 1493 (2) other than FUM108 to any role109. 1494

Application note 29: The concrete restrictions in the TPM state control SFP to restrict the 1495 modification of the TPM state by dedicated roles is defined in FMT_MSA.1/States. 1496

FMT_MSA.3/States Static attribute initialisation (operational states) 1497 Hierarchical to: No other components. 1498 Dependencies: FMT_MSA.1 Management of security attributes 1499 FMT_SMR.1 Security roles 1500

FMT_MSA.3.1/States The TSF shall enforce the TPM state control SFP110 to provide 1501 restrictive111 default values for security attributes that are used to enforce the 1502 SFP. 1503

FMT_MSA.3.2/States The TSF shall allow the nobody112 to specify alternative initial values to 1504 override the default values when an object or information is created. 1505

103 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. 104 [assignment: access control SFP(s), information flow control SFP(s)] 105 [selection: change_default, query, modify, delete, [assignment: other operations]] 106 [assignment: list of security attributes] 107 [assignment: the authorised identified roles] 108 [assignment: list of security attributes] 109 [assignment: the authorised identified roles] 110 [assignment: access control SFP, information flow control SFP] 111 [selection, choose one of: restrictive, permissive, [assignment: other property]] 112 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

FDP_UIT.1/States Data exchange integrity (operational states) 1506 Hierarchical to: No other components. 1507 Dependencies: [FDP_ACC.1 Subset access control, or 1508 FDP_IFC.1 Subset information flow control] 1509 [FTP_ITC.1 Inter-TSF trusted channel, or 1510 FTP_TRP.1 Trusted path] 1511

FDP_UIT.1.1/States The TSF shall enforce the TPM state control SFP113 to receive114 user 1512 firmware update data in a manner protected from [selection: modification, 1513 deletion, insertion, replay] errors. 1514

FDP_UIT.1.2/States The TSF shall be able to determine on receipt of user firmware update 1515 data, whether [selection: modification, deletion, insertion, replay] has occurred. 1516

7.1.4.2 Creation and Modification of the TPM Hierarchy 1517

Hierarchies are characterised by a parent-child relationship of objects. The TPM supports 3 1518 hierarchies: the platform hierarchy, the storage hierarchy and the endorsement hierarchy. 1519 For (temporary) objects that are used only until the next TPM reset, a temporary object 1520 hierarchy may be created. The root of each TPM hierarchy is defined by a primary seed: 1521 Primary seeds are random values that are persistently stored in a TPM. The children of 1522 primary seeds are called primary objects. 1523

Objects in a TPM hierarchy may be moved within the TPM hierarchy or even to a hierarchy 1524 of another TPM. This means that the moving object gets another parent object. In that case 1525 all children of the moving object including the whole sub-tree will move to the new position 1526 as well. The ability of objects to move is controlled by their attributes and can be restricted. 1527

If the hierarchy is disabled the authValue and the authPolicy are not applicable. 1528

FDP_SDI.1 Stored data integrity monitoring 1529 Hierarchical to: No other components. 1530 Dependencies: No dependencies. 1531

FDP_SDI.1.1 The TSF shall monitor user data stored in containers controlled by the 1532

TSF for data modifications and modification of hierarchy115 on all 1533

objects, based on the following attributes: HMAC over the sensitive area 1534

of an object of the TPM hierarchy, object creation ticket116. 1535

Application note 30: The mentioned attributes in FDP_SDI.1 shall be generated at object 1536 creation time using the command TPM2_Create, TPM2_CreatePrimary, or 1537 TPM2_CreateLoaded. The HMAC over the sensitive data shall be done according to the 1538

section 27.6 of [7]. The object creation ticket (see section 10.6.3 of [8]) proves the 1539 environment in the object hierarchy at object creation time. 1540

FDP_ACC.1/Hier Subset access control (object hierarchy) 1541

113 [assignment: access control SFP(s) and/or information flow control SFP(s)] 114 [selection: transmit, receive] 115 [assignment: integrity errors] 116 [assignment: user data attributes]


TCG PUBLIC REVIEW

Hierarchical to: No other components. 1542 Dependencies: FDP_ACF.1 Security attribute based access control 1543

FDP_ACC.1.1/Hier The TSF shall enforce the TPM Object Hierarchy SFP117 on 1544 Subjects 1545 (1) Platform firmware, 1546 (2) Platform owner, 1547 (3) Privacy administrator, 1548 (4) Lockout administrator, 1549 (5) USER, 1550 (6) World 1551

Objects 1552 (1) PPS, 1553 (2) EPS, 1554

(3) SPS, 1555 (4) PPO, 1556 (5) EK, 1557 (6) SRK 1558 (7) Null Seed, 1559 (8) object in a TPM hierarchy 1560

Operations 1561 (1) TPM2_CreatePrimary, 1562 (2) TPM2_CreateLoaded 1563 (3) TPM2_HierarchyControl, 1564 (4) TPM2_Clear, 1565 (5) TPM2_ClearControl, 1566 (6) TPM2_HierarchyChangeAuth, 1567 (7) TPM2_SetPrimaryPolicy, 1568 (8) TPM2_Load, 1569 (9) TPM2_LoadExternal, 1570 (10) TPM2_ReadPublic, 1571 (11) Use.118 1572

FDP_ACF.1/Hier Security attribute based access control (object hierarchy) 1573 Hierarchical to: No other components. 1574 Dependencies: FDP_ACC.1 Subset access control 1575 FMT_MSA.3 Static attribute initialisation 1576

FDP_ACF.1.1/Hier The TSF shall enforce the TPM Object Hierarchy SFP119 to objects based 1577 on the following: 1578 Subjects: 1579 (1) Platform firmware with security attribute authorisation state gained by 1580

authentication with platformAuth or platformPolicy, 1581

117 [assignment: access control SFP] 118 [assignment: list of subjects, objects, and operations among subjects and objects covered by the

SFP] 119 [assignment: access control SFP]


TCG PUBLIC REVIEW

(2) Platform owner with security attribute authorisation state gained by 1582 authentication with ownerAuth or ownerPolicy, 1583

(3) Privacy administrator with security attribute authorisation state gained by 1584 authentication with endorsementAuth or endorsementPolicy, 1585

(4) Lockout administrator with security attribute authorisation state, 1586 (5) USER with authentication state gained with userAuth or authPolicy, 1587 (6) World with no security attributes, 1588 Objects: 1589 (1) EPS, 1590 (2) PPS, 1591 (3) SPS, 1592 (4) EK, 1593 (5) PPO, 1594 (6) SRK, 1595 (7) Null Seed, 1596 (8) object in a TPM hierarchy with security attributes: state of the hierarchy, 1597

fixedParent, fixedTpm120 1598

FDP_ACF.1.2/Hier The TSF shall enforce the following rules to determine if an operation 1599 among controlled subjects and controlled objects is allowed: 1600 (1) The subject World is authorised to create an EPS whenever the TPM is 1601

powered on and no EPS is present. 1602 (2) The subject World is authorised to create an PPS whenever the TPM is 1603

powered on and no PPS is present. 1604 (3) The subject World is authorised to create an SPS whenever the TPM is 1605

powered on and no SPS is present. 1606 (4) The subject World is authorised to create a Null Seed whenever the TPM is 1607

reset. 1608 (5) The Platform firmware with platformAuth, platformPolicy or physical 1609

presence if supported by the TOE and the lockout administrator with 1610 lockoutAuth is authorised to change the SPS to a new value from the RNG 1611 (TPM2_Clear). The physical presence is not required if it is not supported 1612 by the TOE or disabled for the TPM2_Clear command. 1613

(6) The Platform firmware is authorised to create a Platform Primary Object 1614 under PPS. The physical presence is not required if it is not if supported by 1615 the TOE or disabled for TPM2_CreatePrimary or TPM2_CreateLoaded 1616 command. 1617

(7) The Platform owner is authorised to create a primary object (SRK) under 1618 SPS. 1619

(8) The privacy administrator is authorised to create a primary object (EK) 1620 under EPS. 1621

(9) The subject World is authorised to create temporary objects for no 1622 hierarchy (using the Null Seed). 1623

(10) The Platform firmware with platformAuth, platformPolicy or physical 1624 presence if supported by the TOE and the lockout administrator with 1625 lockoutAuth are authorised to remove all TPM context associated with a 1626

120 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes]


TCG PUBLIC REVIEW

specific owner (TPM2_Clear). The physical presence is not required if it is 1627 not supported by the TOE or disabled for the TPM2_ClearControl 1628 command. 1629

(11) The Platform firmware with platformAuth, platformPolicy or physical 1630 presence if supported by the TOE and the lockout administrator with 1631 lockoutAuth are authorised to disable and enable the execution of 1632 TPM2_Clear by the command TPM2_ClearControl. The physical presence is 1633 not required if it is not supported by the TOE or disabled for the 1634 TPM2_ClearControl command. 1635

(12) The Platform firmware with platformAuth, platformPolicy or physical 1636 presence if supported by the TOE, the Platform owner, the privacy 1637 administrator and the lockout administrator are authorised to change the 1638 authorisation secret for a hierarchy or lockout 1639 (TPM2_HierarchyChangeAuth). The physical presence is not required if it is 1640 not supported by the TOE or disabled for the TPM2_HierarchyChangeAuth 1641 command. 1642

(13) The Platform firmware with platformAuth, platformPolicy or physical 1643 presence, if supported by the TOE the Platform owner and the privacy 1644 administrator are authorised to set the authorisation policy for the platform 1645 hierarchy (platformPolicy), the storage hierarchy (ownerPolicy) and the 1646 endorsement hierarchy (endorsementPolicy) using the command 1647 TPM2_SetPrimaryPolicy. The physical presence is not required if it is not 1648 supported by the TOE or disabled for the TPM2_SetPrimaryPolicy 1649 command.121 1650

FDP_ACF.1.3/Hier The TSF shall explicitly authorise access of subjects to objects based on 1651 the following additional rules: none122. 1652

FDP_ACF.1.4/Hier The TSF shall explicitly deny access of subjects to objects based on the 1653 following additional rules: 1654 (1) No subject is authorised to use any object of a hierarchy if the 1655

corresponding hierarchy is disabled (i.e phEnable for platform hierarchy is 1656 CLEAR, shEnable for Storage hierarchy is CLEAR, ehEnable for EPS 1657 hierarchy is CLEAR)123. 1658

FMT_MSA.1/Hier Management of security attributes (object hierarchy) 1659


122 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]

123 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]


TCG PUBLIC REVIEW

Hierarchical to: No other components. 1660 Dependencies: [FDP_ACC.1 Subset access control, or 1661 FDP_IFC.1 Subset information flow control] 1662 FMT_SMR.1 Security roles 1663 FMT_SMF.1 Specification of Management Functions 1664

FMT_MSA.1.1/Hier TSF shall enforce the TPM Object Hierarchy SFP124 to restrict the ability 1665 to modify125 the security attributes fixedTPM and fixedParent126 to nobody127.1666 1667

FMT_MSA.3/Hier Static attribute initialisation (object hierarchy) 1668 Hierarchical to: No other components. 1669 Dependencies: FMT_MSA.1 Management of security attributes 1670 FMT_SMR.1 Security roles 1671

FMT_MSA.3.1/Hier The TSF shall enforce the TPM Object Hierarchy SFP128 to provide 1672 restrictive129 default values for security attributes that are used to enforce the 1673 SFP. 1674

FMT_MSA.3.2/Hier The TSF shall allow the creator of an object in a TPM hierarchy130 to 1675 specify alternative initial values to override the default values when an object 1676 or information is created. 1677

FMT_MSA.4/Hier Security attribute value inheritance (hierarchy) 1678 Hierarchical to: No other components. 1679 Dependencies: [FDP_ACC.1 Subset access control, or 1680 FDP_IFC.1 Subset information flow control] 1681

FMT_MSA.4.1/Hier The TSF shall use the following rules to set the value of security 1682 attributes: 1683 (1) The Platform firmware with platformAuth, platformPolicy or physical 1684

presence if supported by the TOE is authorised to enable and to disable the 1685 use of the platform hierarchy and its associated NV storage 1686 (TPM2_HierarchyControl changing phEnable or phEnableNV). The physical 1687 presence is not required if it is not supported by the TOE or disabled for 1688 the TPM2_HierarchyControl command. 1689

(2) The Platform firmware with platformAuth, platformPolicy or physical 1690 presence if supported by the TOE and Platform owner with ownerAuth or 1691 ownerPolicy are authorised to enable and to disable the use of a Storage 1692 hierarchy (TPM2_HierarchyControl changing shEnable). The physical 1693 presence is not required if it is not supported by the TOE or disabled for 1694

the TPM2_HierarchyControl command. 1695

124 [assignment: access control SFP(s), information flow control SFP(s)] 125 [selection: change_default, query, modify, delete, [assignment: other operations]] 126 [assignment: list of security attributes] 127 [assignment: the authorised identified roles] 128 [assignment: access control SFP, information flow control SFP] 129 [selection, choose one of: restrictive, permissive, [assignment: other property]] 130 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

(3) The Platform firmware with platformAuth, platformPolicy or physical 1696 presence if supported by the TOE and privacy administrator with 1697 endorsementAuth or endorsementPolicy are authorised to enable and to 1698 disable the use of a Endorsement hierarchy (TPM2_HierarchyControl 1699 changing ehEnable). The physical presence is not required if it is not 1700 supported by the TOE or disabled for the TPM2_HierarchyControl 1701 command. 1702

(4) The only way to enable platform hierarchy is power-on of the TPM. 1703 (5) The Platform firmware with platformAuth, platformPolicy, or physical 1704

presence if supported by the TOE is authorised to enable the use of the 1705 Endorsement hierarchy and the Storage hierarchy 1706 (TPM2_HierarchyControl). The physical presence is not required if it is not 1707 supported by the TOE or disabled for the TPM2_HierarchyControl 1708 command.131 1709

Application note 31: The TPM2_HierarchyControl command allows the security attributes 1710 phEnable, shEnable, and ehEnable to be changed when the proper authorisation is 1711 provided. 1712

7.1.4.3 Data Import and Export 1713

The TPM supports the creation of hierarchies of entities. A hierarchy is constructed with 1714 Storage Keys as the connectors to which other types of objects may be attached. 1715 Duplication is the process of allowing an object to be a child of additional parent keys. The 1716 new parent may be in a hierarchy of the same TPM or of a different TPM. 1717

In order to summarise the correlations of different TPM commands regarding data import 1718 and export, Figure 4 illustrates possible scenarios: To be able to use an object as part of the 1719 TPM hierarchy, it needs to be previously loaded. The load operation is implemented as 1720 TPM2_Load, TPM2_CreateLoaded, or TPM2_LoadExternal command. The TPM2_Load 1721 command requires a TPM object that could have been created by TPM2_Create from an 1722 object template. TPM2_CreateLoaded combines creation and loading of an object in one 1723 command. The TPM2_LoadExternal command loads only the public area of an object (for 1724 example a public key) that could have been defined by an external system. If an object of 1725 the hierarchy of a TPM should be transferred into another TPM’s object hierarchy, it needs 1726 to be duplicated based on the old object hierarchy first. Then it needs to be imported and 1727 later loaded based on the new object hierarchy, before it becomes part of the new hierarchy 1728 and can be used. 1729

131 [assignment: rules for setting the values of security attributes]


TCG PUBLIC REVIEW

1730

Figure 4: Object Export/Import Scenarios (informative) 1731

FDP_ACC.1/ExIm Subset access control (export and import) 1732

Hierarchical to: No other components. 1733 Dependencies: FDP_ACF.1 Security attribute based access control 1734

FDP_ACC.1.1/ExIm The TSF shall enforce the Data Export and Import SFP132 on 1735 Subjects: 1736 (1) USER, 1737 (2) DUP, 1738

(3) World 1739 Objects: 1740 (1) Platform Primary Object, 1741 (2) Endorsement Primary Key, 1742 (3) User Key, 1743 (4) Context 1744

132 [assignment: access control SFP]


TCG PUBLIC REVIEW

Operations 1745 (1) duplicate by means of TPM2_Duplicate, 1746 (2) export by means of TPM2_Create, 1747 (3) load by means of TPM2_Load, 1748 (4) export and load by means of TPM2_CreateLoaded 1749 (5) load by means of TPM2_LoadExternal, 1750 (6) import by means of TPM2_Import, 1751 (7) unseal by means of TPM2_Unseal, 1752 (8) save by means of TPM2_ContextSave 1753 (9) load by means of TPM2_ContextLoad 1754 (10) remove a context by means of TPM2_FlushContext133 1755

FDP_ACF.1/ExIm Security attribute based access control (export and import) 1756 Hierarchical to: No other components. 1757

Dependencies: FDP_ACC.1 Subset access control 1758 FMT_MSA.3 Static attribute initialisation 1759

FDP_ACF.1.1/ExIm The TSF shall enforce the Data Export and Import SFP134 to objects 1760 based on the following: 1761 Subjects: 1762 (1) USER with authentication state gained with userAuth or authPolicy, 1763 (2) DUP with authentication state gained with authPolicy, 1764 (3) World without any successful authentication 1765 Objects: 1766 (1) Platform Primary Object with the security attributes platformAuth, 1767 (2) Endorsement Primary Key with the security attributes authorisation data 1768 (3) User Key with the security attributes authorisation data 1769 (4) Context with the security attributes sequence number, hierarchy selector, 1770

HMAC135 1771

FDP_ACF.1.2/ExIm The TSF shall enforce the following rules to determine if an operation 1772 among controlled subjects and controlled objects is allowed: 1773 (1) The subject DUP is authorised to duplicate a loaded object under the 1774

following conditions: 1775 (a) the authorisation of the subject shall be provided in an authorisation 1776

session for duplication, 1777 (b) the object attribute “fixedParent” must not be set, and 1778 (c) the object attribute “nameAlg” must not be TPM_ALG_NULL. 1779

(2) The subject USER is authorised to export an object using the TPM2_Create 1780 command. 1781

(3) The subject USER authorised for the parent object is allowed to load 1782

objects into the TPM hierarchy using the command TPM2_Load. 1783 (4) The subject USER is authorized to export and load an object using the 1784

TPM2_CreateLoaded command. 1785

133 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]

134 [assignment: access control SFP] 135 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-



TCG PUBLIC REVIEW

(5) The subject World authorised for the parent object is allowed to load 1786 objects into the TPM hierarchy using the command TPM2_LoadExternal. 1787

(6) The subject USER authorised for the parent object is allowed to import an 1788 object using the TPM2_Import command under the following conditions: 1789

(a) The attributes “fixedTPM” and “fixedParent” of the object shall not 1790 be set. 1791

(b) If an encryption of the object to import is performed, then an 1792 integrity evidence value shall be part of the imported object. 1793

(c) If an integrity evidence value is present, the object shall only be 1794 imported after the integrity was successfully verified. 1795

(7) The subject World is authorised to read the public portion of a TPM object 1796 using the command TPM2_ReadPublic. 1797

(8) The subject USER is authorised to unseal a sealed data object using the 1798 TPM2_Unseal command. 1799

(9) Every subject is authorised to save a context without authorisation. 1800 (10) Every subject is authorised to load a saved context without 1801

authorisation if 1802 (a) the sequence number is in the accepted range, 1803 (b) the integrity of the context is successfully verified, 1804 (c) the TPM was not reset after the context saving and 1805 (d) the hierarchy associated with the context was not changed or 1806

disabled. 1807 (11) Every subject is authorised to remove all context associated with a 1808

loaded object or session from the TPM memory (TPM2_FlushContext).136 1809

FDP_ACF.1.3/ExIm The TSF shall explicitly authorise access of subjects to objects based on 1810 the following additional rules: none137 1811

FDP_ACF.1.4/ExIm The TSF shall explicitly deny access of subjects to objects based on the 1812 following additional rules: 1813 (1) No subject is authorised to move an object to another TPM’s object 1814

hierarchy (using the duplicate and import operation) if the fixedTPM or the 1815 fixedParent attribute of that object is set. 1816

(2) No subject is authorised to move an object to another position in a TPM 1817 object hierarchy (using the duplicate operation) if the fixedParent attribute 1818 of that object is set138. 1819

FMT_MSA.1/ExIm Management of security attributes (export and import) 1820





TCG PUBLIC REVIEW


FMT_MSA.1.1/ExIm TSF shall enforce the Data Export and Import SFP139 to restrict the 1826 ability to use140 the security attributes authorisation data141 to every subject142. 1827

FMT_MSA.3/ExIm Static attribute initialisation (export and import) 1828 Hierarchical to: No other components. 1829 Dependencies: FMT_MSA.1 Management of security attributes 1830 FMT_SMR.1 Security roles 1831

FMT_MSA.3.1/ExIm The TSF shall enforce the Data Export and Import SFP143 to provide 1832 restrictive144 default values for security attributes that are used to enforce the 1833 SFP. 1834

FMT_MSA.3.2/ExIm The TSF shall allow the nobody145 to specify alternative initial values to 1835 override the default values when an object or information is created. 1836

FDP_ETC.2/ExIm Export of user data with security attributes (export and import) 1837 Hierarchical to: No other components. 1838 Dependencies: [FDP_ACC.1 Subset access control, or 1839 FDP_IFC.1 Subset information flow control] 1840

FDP_ETC.2.1/ExIm The TSF shall enforce the Data Export and Import SFP146 when 1841 exporting user data, controlled under the SFP(s), outside of the TOE. 1842

FDP_ETC.2.2/ExIm The TSF shall export the user data with the user data's associated 1843 security attributes. 1844

FDP_ETC.2.3/ExIm The TSF shall ensure that the security attributes, when exported 1845 outside the TOE, are unambiguously associated with the exported user data. 1846

FDP_ETC.2.4/ExIm The TSF shall enforce the following rules when user data is exported 1847 from the TOE: 1848 (1) The sensitive area of an object from the TPM hierarchy shall be integrity-1849

protected with an HMAC before its export using the command TPM2_Create 1850 or TPM2_CreateLoaded. The used key and the IV shall be derived from the 1851 secret seed of the parent in the TPM hierarchy. 1852

139 [assignment: access control SFP(s), information flow control SFP(s)] 140 [selection: change_default, query, modify, delete, [assignment: other operations]] 141 [assignment: list of security attributes] 142 [assignment: the authorised identified roles] 143 [assignment: access control SFP, information flow control SFP] 144 [selection, choose one of: restrictive, permissive, [assignment: other property]] 145 [assignment: the authorised identified roles] 146 [assignment: access control SFP(s) and/or information flow control SFP(s)]


TCG PUBLIC REVIEW

(2) The sensitive area of an object from the TPM hierarchy shall be 1853 symmetrically encrypted before its export using the command TPM2_Create 1854 or TPM2_CreateLoaded. The used key and the IV should be derived from 1855 the secret seed of the parent in the TPM hierarchy. 1856

(3) An exported context (using the command TPM2_ContextSave) shall be 1857 symmetrically encrypted and integrity protected with a HMAC. 1858

(4) When exporting an object using the command TPM2_Duplicate then the 1859 following actions shall be performed: 1860

(a) If the encryptedDuplication attribute is set or the caller provides a 1861 symmetric algorithm then the sensitive part of the data shall be 1862 symmetrically encrypted and integrity protected (called: inner 1863 duplication wrapper). 1864

(b) If the encryptedDuplication attribute is set or the caller provides a 1865 new parent in a TPM hierarchy then the inner duplication wrapper 1866 shall be symmetrically encrypted and integrity protected (called 1867 outer duplication wrapper). The used key shall be derived from a 1868 seed that shall be asymmetrically encrypted with the public key of 1869 the intended new parent in the TPM object hierarchy.147 1870

Application note 32: The details of the derivation of the key and IV for the symmetric 1871 encryption and HMAC generation for export of the sensitive area of objects are specified in 1872 section 22.4 and 22.5 of [7]. 1873

Application note 33: The details of the derivation of the key and IV for the symmetric 1874 encryption and HMAC generation for export of contexts are specified in section 30.3 of [7]. 1875

Application note 34: The details of the inner duplication wrapper for the TPM2_Duplicate 1876 command are defined in section 23.3.2 of [7]. 1877

FDP_ITC.2/ExIm Import of user data with security attributes (export and import) 1878 Hierarchical to: No other components. 1879 Dependencies: [FDP_ACC.1 Subset access control, or 1880 FDP_IFC.1 Subset information flow control] 1881 [FTP_ITC.1 Inter-TSF trusted channel, or 1882 FTP_TRP.1 Trusted path] 1883 FPT_TDC.1 Inter-TSF basic TSF data consistency 1884

FDP_ITC.2.1/ExIm The TSF shall enforce the Data Export and Import SFP148 when 1885 importing user data, controlled under the SFP, from outside of the TOE. 1886

FDP_ITC.2.2/ExIm The TSF shall use the security attributes associated with the imported 1887 user data. 1888

FDP_ITC.2.3/ExIm The TSF shall ensure that the protocol used provides for the 1889 unambiguous association between the security attributes and the user data 1890 received. 1891

147 [assignment: additional exportation control rules] 148 [assignment: access control SFP(s) and/or information flow control SFP(s)]


TCG PUBLIC REVIEW

FDP_ITC.2.4/ExIm The TSF shall ensure that interpretation of the security attributes of the 1892 imported user data is as intended by the source of the user data. 1893

FDP_ITC.2.5/ExIm The TSF shall enforce the following rules when importing user data 1894 controlled under the SFP from outside the TOE: 1895 (1) If an inner or an outer wrapper is present then a valid integrity value shall 1896

be present.149 1897

FDP_UCT.1/ExIm Basic data exchange confidentiality (export and import) 1898 Hierarchical to: No other components. 1899 Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or 1900 FTP_TRP.1 Trusted path] 1901 [FDP_ACC.1 Subset access control, or 1902 FDP_IFC.1 Subset information flow control] 1903

FDP_UCT.1.1/ExIm The TSF shall enforce the Data Export and Import SFP150 to transmit151 1904 user data in a manner protected from unauthorised disclosure. 1905

FDP_UIT.1/ExIm Data exchange integrity (export and import) 1906 Hierarchical to: No other components. 1907 Dependencies: [FDP_ACC.1 Subset access control, or 1908 FDP_IFC.1 Subset information flow control] 1909 [FTP_ITC.1 Inter-TSF trusted channel, or 1910 FTP_TRP.1 Trusted path] 1911

FDP_UIT.1.1/ExIm The TSF shall enforce the Data Export and Import SFP152 to transmit 1912 and receive153 user data in a manner protected from modification154 errors. 1913

FDP_UIT.1.2/ExIm The TSF shall be able to determine on receipt of user data, whether 1914 modification155 has occurred. 1915

7.1.4.4 Measurement and Reporting 1916

An integrity measurement is a value that represents a possible change in the trust state of 1917 the platform. The TPM supports this measurement using the extension of an accumulative 1918 hash in a PCR. Integrity reporting is the process of attesting integrity measurements 1919 recorded in a PCR. PCR may also be used to gate access to an object. If selected PCR do not 1920 have the required values, the TPM will not allow use of the object. A TPM may maintain 1921 multiple banks of PCR. A PCR bank is a collection of PCR that are extended with the same 1922 hash algorithm. 1923

Another aspect of measurement and reporting is the concept of tickets: A ticket is a HMAC 1924 signature that uses a proof value as the HMAC key. It is used as a replacement of an 1925

149 [assignment: additional importation control rules] 150 [assignment: access control SFP(s) and/or information flow control SFP(s)] 151 [selection: transmit, receive] 152 [assignment: access control SFP(s) and/or information flow control SFP(s)] 153 [selection: transmit, receive] 154 [selection: modification, deletion, insertion, replay] 155 [selection: modification, deletion, insertion, replay]


TCG PUBLIC REVIEW

asymmetric digital signature in order to avoid the required computational effort of 1926 asymmetric operations. 1927

FDP_ACC.1/M&R Subset access control (measurement and reporting) 1928 Hierarchical to: No other components. 1929 Dependencies: FDP_ACF.1 Security attribute based access control 1930

FDP_ACC.1.1/M&R The TSF shall enforce the Measurement and Reporting SFP156 on 1931 subjects 1932 (1) Platform firmware, 1933 (2) USER, 1934 (3) ADMIN, 1935 (4) World, 1936

objects 1937 (1) PCR, 1938

(2) TPM objects, 1939

operations 1940 (1) TPM2_PCR_Allocate, 1941 (2) TPM2_PCR_Reset, 1942 (3) TPM2_PCR_Extend, 1943 (4) TPM2_PCR_Event, 1944 (5) TPM2_PCR_Read, 1945 (6) TPM2_Quote, 1946 (7) TPM2_CertifyCreation157 1947

FDP_ACF.1/M&R Security attribute based access control (measurement and 1948 reporting) 1949

Hierarchical to: No other components. 1950 Dependencies: FDP_ACC.1 Subset access control 1951 FMT_MSA.3 Static attribute initialisation 1952

FDP_ACF.1.1/M&R The TSF shall enforce the Measurement and Reporting SFP158 to objects 1953 based on the following: 1954 Subjects: 1955 (1) Platform firmware with security attribute authorisation state gained by 1956

authentication with platformAuth or platformPolicy or locality, 1957 (2) USER with authentication state gained with authValue or authPolicy, 1958 (3) ADMIN with authentication state gained with authValue or authPolicy, 1959 (4) World with no security attributes, 1960 Objects: 1961 (1) PCR with the security attribute PCR-attributes TPM_PT_PCR, 1962 (2) TPM objects with the security attributes authentication data (authValue, 1963

authPolicy)159 1964


SFP] 158 [assignment: access control SFP] 159 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-



TCG PUBLIC REVIEW

FDP_ACF.1.2/M&R The TSF shall enforce the following rules to determine if an operation 1965 among controlled subjects and controlled objects is allowed: 1966 (1) The Platform firmware platformAuth, platformPolicy or with physical 1967

presence if supported by the TOE is authorised to set the desired PCR 1968 allocation of the PCR and the algorithms (TPM2_PCR_Allocate). The 1969 physical presence is not required if it is not supported by the TOE or 1970 disabled for TPM2_PCR_Allocate command. 1971

(2) Authorised subjects of role USER are allowed to extend the PCR using the 1972 command TPM2_PCR_Extend if the command locality permits the 1973 extension of the intended PCR. 1974

(3) Authorised subjects of role USER are allowed to update the PCR using the 1975 command TPM2_PCR_Event if the command locality permits the extension 1976 of the intended PCR. 1977

(4) Authorised subjects of role USER are allowed to reset the PCR using the 1978 commands TPM2_PCR_Reset if the command locality permits the reset 1979 attribute of the PCR. 1980

(5) The subject World is authorised to read values of PCR using the command 1981 TPM2_PCR_Read. 1982

(6) Authorised subjects of role USER are allowed to quote PCR values using 1983 the command TPM2_Quote. The authorisation shall be done based on the 1984 key that is used for the quotation. 1985

(7) Authorised subjects of role USER are allowed to prove the association 1986 between an object and its creation data by creation of a ticket using the 1987 command TPM2_CertifyCreation. The authorisation shall be done based on 1988 the key that is used to sign the attestation block.160 1989

FDP_ACF.1.3/M&R The TSF shall explicitly authorise access of subjects to objects based on 1990 the following additional rules: none161. 1991

FDP_ACF.1.4/M&R The TSF shall explicitly deny access of subjects to objects based on the 1992 following additional rules: none162. 1993

FMT_MSA.1/M&R Management of security attributes (measurement and reporting) 1994 Hierarchical to: No other components. 1995 Dependencies: [FDP_ACC.1 Subset access control, or 1996 FDP_IFC.1 Subset information flow control] 1997 FMT_SMR.1 Security roles 1998 FMT_SMF.1 Specification of Management Functions 1999

FMT_MSA.1.1/M&R TSF shall enforce the Measurement and Reporting SFP163 to restrict the 2000 ability to modify164 the security attributes PCR attributes, PCR extension 2001 algorithm, used hash algorithm165 to Platform firmware166. 2002



162 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 163 [assignment: access control SFP(s), information flow control SFP(s)] 164 [selection: change_default, query, modify, delete, [assignment: other operations]]


TCG PUBLIC REVIEW

FMT_MSA.3/M&R Static attribute initialisation (measurement and reporting) 2003 Hierarchical to: No other components. 2004 Dependencies: FMT_MSA.1 Management of security attributes 2005 FMT_SMR.1 Security roles 2006

FMT_MSA.3.1/M&R The TSF shall enforce the Measurement and Reporting SFP167 to provide 2007 restrictive168 default values for security attributes that are used to enforce the 2008 SFP. 2009

FMT_MSA.3.2/M&R The TSF shall allow the nobody169 to specify alternative initial values to 2010 override the default values when an object or information is created. 2011

FCO_NRO.1/M&R Selective proof of origin (measurement and reporting) 2012 Hierarchical to: No other components. 2013

Dependencies: FIA_UID.1 Timing of identification 2014

FCO_NRO.1.1/M&R The TSF shall be able to generate evidence of origin for transmitted 2015 attestation structure (TPM2B_ATTEST) and object creation tickets170 at the 2016 request of the originator171. 2017

FCO_NRO.1.2/M&R The TSF shall be able to relate the 2018 (1) magic number for identification whether the TPM produced the signed 2019

digest or any external entity, 2020 (2) type of the attestation structure indicating the contents of the attested 2021

parameter, 2022 (3) qualified name of the key used to sign the attestation data (qualifiedSigner), 2023 (4) external information supplied by the caller, 2024 (5) values of clock, resetCount, restartCount and Safe, 2025 (6) the firmware version172 2026

of the originator of the information, and the command depending value of 2027 either 2028 (1) PCR data (using the command TPM2_Quote), or 2029 (2) audit digests (using the command TPM2_GetSessionAuditDigest), or 2030 (3) a ticket that was produces by the TPM (using the command 2031

TPM2_CertifyCreation)173 2032

of the information to which the evidence applies. 2033

FCO_NRO.1.3/M&R The TSF shall provide a capability to verify the evidence of origin of 2034 information to recipient174 given as soon as the recipient can verify the 2035 signature and has confidence to the key that is used to sign175. 2036

165 [assignment: list of security attributes] 166 [assignment: the authorised identified roles] 167 [assignment: access control SFP, information flow control SFP] 168 [selection, choose one of: restrictive, permissive, [assignment: other property]] 169 [assignment: the authorised identified roles] 170 [assignment: list of information types] 171 [selection: originator, recipient, [assignment: list of third parties]] 172 [assignment: list of attributes] 173 [assignment: list of information fields]


TCG PUBLIC REVIEW

Application note 35: The key used for signing may be any key with the sign attribute set. If 2037 a key is not restricted to a dedicated scheme then the caller of the corresponding command 2038 may indicate the signing scheme to be used. If an anonymous scheme (TPM_ALG_ECDAA) is 2039 used for signing, the qualifiedSigner parameter of the corresponding command shall be an 2040 empty buffer. 2041

Application note 36: If the used signature key is not in the endorsement or platform 2042 hierarchy, then the mentioned attribute values resetCount, restartCount and 2043 firmwareVersion shall be obfuscated according to section 20 of [9] for privacy protection 2044 reasons. 2045

7.1.5 SFRs for the TOE Operation 2046

7.1.5.1 Access SFR 2047

FDP_ACC.1/AC Subset access control (access control) 2048 Hierarchical to: No other components. 2049 Dependencies: FDP_ACF.1 Security attribute based access control 2050

FDP_ACC.1.1/AC The TSF shall enforce the Access Control SFP176 on 2051 subjects 2052 (1) Platform firmware, 2053 (2) Platform owner, 2054 (3) Privacy administrator, 2055 (4) Lockout administrator, 2056 (5) USER, 2057 (6) DUP, 2058 (7) ADMIN, 2059 (8) World; 2060

objects 2061 (1) User key, 2062 (2) TPM objects, 2063 (3) Clock 2064 (4) Data (to which cryptographic operation applies); 2065

operations 2066 (1) TPM2_EvictControl, 2067 (2) TPM2_ClockSet, 2068 (3) TPM2_ClockRateAdjust, 2069 (4) TPM2_ReadClock, 2070 (5) TPM2_GetTime, 2071 (6) TPM2_VerifySignature, 2072

(7) TPM2_Sign, 2073 (8) TPM2_GetRandom, 2074 (9) TPM2_StirRandom, 2075 (10) TPM2_RSA_Encrypt, 2076 (11) TPM2_RSA_Decrypt, 2077

174 [selection: originator, recipient, [assignment: list of third parties]] 175 [assignment: limitations on the evidence of origin] 176 [assignment: access control SFP]


TCG PUBLIC REVIEW

(12) TPM2_ECDH_KeyGen, 2078 (13) TPM2_ECDH_ZGen, 2079 (14) TPM2_ECC_Parameters, 2080 (15) TPM2_HMAC_Start, 2081 (16) TPM2_HashSequenceStart, 2082 (17) TPM2_SequenceUpdate, 2083 (18) TPM2_SequenceComplete, 2084 (19) TPM2_EventSequenceComplete, 2085 (20) TPM2_HMAC, 2086 (21) TPM2_Hash177 2087

2088

FDP_ACF.1/AC Security attribute based access control (access control) 2089 Hierarchical to: No other components. 2090

Dependencies: FDP_ACC.1 Subset access control 2091 FMT_MSA.3 Static attribute initialisation 2092

FDP_ACF.1.1/AC The TSF shall enforce the Access Control SFP178 to objects based on the 2093 following 2094 Subjects: 2095 (1) Platform firmware with security attribute authorisation state gained by 2096

authentication with platformAuth, platformPolicy or physical presence if 2097 supported by the TOE, 2098

(2) Platform owner with security attribute authorisation state gained by 2099 authentication with ownerAuth or ownerPolicy, 2100

(3) Privacy administrator with security attribute authorisation state gained by 2101 authentication with endorsementAuth or endorsementPolicy, 2102

(4) Lockout administrator with security attribute authorisation state, 2103 (5) USER with authentication state gained with userAuth or authPolicy, 2104 (6) DUP with authentication state gained with authPolicy, 2105 (7) ADMIN with authentication state gained with userAuth or authPolicy, 2106 (8) World with no security attributes, 2107 Objects: 2108 (1) User key with security attributes TPM_ALG_ID, TPMA_OBJECT, 2109 (2) TPM objects, 2110 (3) Clock with security attributes: resetCount, restartCount, safe-flag, 2111 (4) Data with security attribute “externally provided”179. 2112

FDP_ACF.1.2/AC The TSF shall enforce the following rules to determine if an operation 2113 among controlled subjects and controlled objects is allowed: 2114 (1) The Platform firmware platformAuth, platformPolicy or with physical 2115

presence if supported by the TOE and the Platform owner are authorised to 2116 control the persistence of loadable objects in TPM memory 2117





TCG PUBLIC REVIEW

(TPM2_EvictControl). The physical presence is not required if it is not 2118 supported by the TOE or disabled for TPM2_EvictControl command. 2119

(2) The Platform firmware platformAuth, platformPolicy or with physical 2120 presence if supported by the TOE and the Platform owner are authorised to 2121 advance the value and to adjust the rate of advance of the TPMs clock 2122 (TPM2_ClockSet, TPM2_ClockRateAdjust). The physical presence is not 2123 required if it is not supported by the TOE or disabled for the 2124 TPM2_ClockSet respective TPM2_ClockRateAdjust command. 2125

(3) Any subject is authorised to get the current value of time, clock, 2126 resetCount and restartCount (TPM2_ReadClock). 2127

(4) A subject with the role USER endorsed by the Privacy administrator or the 2128 keyHandle identifier of a loaded key that can perform digital signatures is 2129 authorised to get the current value of time and clock (TPM2_GetTime). 2130

(5) No subject is authorised to set the clock to a value less than the current 2131 value of clock using the TPM2_ClockSet command. 2132

(6) No subject is authorised to set the clock to a value greater than its 2133 maximum value (0xFFFF000000000000) using the TPM2_ClockSet 2134 command. 2135

(7) A subject with the role USER is authorised to generate digital signatures 2136 using the command TPM2_Sign for externally provided data (hash). The 2137 user authorisation shall be done based on the required authorisation of the 2138 key that will perform signing. The key attributes shall allow the signing 2139 operation for externally provided data. 2140

(8) Any subject is authorised to verify digital signatures using the command 2141 TPM2_VerifySignature. 2142

(9) Any subject is authorised to request data from the random number 2143 generator using the command TPM2_GetRandom. 2144

(10) Any subject is authorised to add additional information to the state of 2145 the random number generator using the command TPM2_StirRandom. 2146

(11) Any subject is authorised to perform RSA encryption using the 2147 command TPM2_RSA_Encrypt for externally provided data. The key 2148 attributes shall allow the encrypt operation for externally provided data. 2149

(12) A subject with the role USER is authorised to perform RSA decryption 2150 using the command TPM2_RSA_Decrypt for externally provided data. The 2151 user authorisation shall be done based on the required authorisation of the 2152 key that will be used for decryption. The key attributes shall allow the 2153 decrypt operation for externally provided data. 2154

(13) Any subject is authorised to generate ECC ephemeral key pairs using 2155 the command TPM2_ECDH_KeyGen. 2156

(14) A subject with the role USER is authorised to recover a value that is 2157 used in ECC based key sharing protocols using the command 2158

TPM2_ECDH_ZGen. The user authorisation shall be done based on the 2159 required authorisation of the involved private key. 2160

(15) Any subject is authorised to request the parameters of an identified 2161 ECC curve using the command TPM2_ECC_Parameters. 2162

(16) The subject USER is authorised to start a HMAC sequence using the 2163 command TPM2_HMAC_Start. 2164

(17) The subject World is authorised to start a hash or event sequence using 2165 the command TPM2_HashSequenceStart. 2166


TCG PUBLIC REVIEW

(18) The subject USER is authorised to add data to a hash, event or HMAC 2167 sequence using the command TPM2_SequenceUpdate. 2168

(19) The subject USER is authorised to add the last part of data (if any) to a 2169 hash or HMAC sequence using the command TPM2_ SequenceComplete. 2170

(20) The subject USER is authorised to add the last part of data (if any) to an 2171 event sequence using the command TPM2_EventSequenceComplete. 2172

(21) Any subject is authorised to perform hash operations on a data buffer 2173 using the command TPM2_Hash. 2174

(22) A subject with the role USER is authorised to perform HMAC operations 2175 on a data buffer. The user authorisation shall be done based on the 2176 required authorisation of the involved symmetric key. 2177

(23) A subject with the role USER is authorised to generate HMACs using 2178 the command TPM2_HMAC for externally provided data (hash). The user 2179 authorisation shall be done based on the required authorisation of the key 2180 that will perform the HMAC. The key attributes shall allow the signing 2181 operation for externally provided data. 180 2182 2183

FDP_ACF.1.3/AC The TSF shall explicitly authorise access of subjects to objects based on 2184 the following additional rules: [assignment: rules, based on security attributes, 2185 that explicitly authorise access of subjects to objects]181 2186

FDP_ACF.1.4/AC The TSF shall explicitly deny access of subjects to objects based on the 2187 following additional rules: [assignment: rules, based on security attributes, that 2188 explicitly deny access of subjects to objects]. 2189

FMT_MSA.1/AC Management of security attributes (access control) 2190 Hierarchical to: No other components. 2191 Dependencies: [FDP_ACC.1 Subset access control, or 2192 FDP_IFC.1 Subset information flow control] 2193 FMT_SMR.1 Security roles 2194 FMT_SMF.1 Specification of Management Functions 2195

FMT_MSA.1.1/AC TSF shall enforce the Access Control SFP182 to restrict the ability to 2196

(1) query183 the security attributes digital signature of the audit session digest 2197 (TPM2_GetSessionAuditDigest)184 to privacy administrator185 2198

(2) query186 the security attributes TPMT_PUBLIC_PARMS187 2199 (TPM2_TestParms) to World188. 2200



182 [assignment: access control SFP(s), information flow control SFP(s)] 183 [selection: change_default, query, modify, delete, [assignment: other operations]] 184 [assignment: list of security attributes] 185 [assignment: the authorised identified roles] 186 [selection: change_default, query, modify, delete, [assignment: other operations]] 187 [assignment: list of security attributes]


TCG PUBLIC REVIEW

(3) query189 the security attributes TPMS_ALGORITHM_DETAILS_ECC190 2201 (TPM2_ECC_Parameters) to World191. 2202

(4) increment192 the security attributes resetCount and restartCount193 to every 2203 subject194, 2204

(5) reset195 the security attributes resetCount, restartCount and the safe-flag 2205 of the TPM Clock196 by means of command TPM2_Clear to Platform 2206 firmware authorised by platformAuth, platformPolicy or physical presence 2207 (if supported by the TOE) and the lockout administrator197, 2208

(6) if supported by the TOE: change198 the security attribute Physical Presence 2209 requirement for all commands in the setList of TPM2_PP_Comands to 2210 “required” and all commands in the clearList to “not required” of 2211

TPM2_PP_Comands199 to Platform firmware authorised by platformAuth, 2212 platformPolicy or physical presence200, 2213

(7) change201 the security attributes authorisation secret (authValue) of TPM 2214 objects (TPM2_ObjectChangeAuth)202 to ADMIN203. 2215

FMT_MSA.3/AC Static attribute initialisation (access control) 2216 Hierarchical to: No other components. 2217 Dependencies: FMT_MSA.1 Management of security attributes 2218 FMT_SMR.1 Security roles 2219

FMT_MSA.3.1/AC The TSF shall enforce the Access Control SFP204 to provide restrictive205 2220 default values for security attributes that are used to enforce the SFP. 2221

FMT_MSA.3.2/AC The TSF shall allow the USER, ADMIN206 to specify alternative initial 2222 values to override the default values when an object or information is created. 2223

188 [assignment: the authorised identified roles] 189 [selection: change_default, query, modify, delete, [assignment: other operations]] 190 [assignment: list of security attributes] 191 [assignment: the authorised identified roles] 192 [selection: change_default, query, modify, delete, [assignment: other operations]] 193 [assignment: list of security attributes] 194 [assignment: the authorised identified roles] 195 [selection: change_default, query, modify, delete, [assignment: other operations]] 196 [assignment: list of security attributes] 197 [assignment: the authorised identified roles] 198 [selection: change_default, query, modify, delete, [assignment: other operations]] 199 [assignment: list of security attributes] 200 [assignment: the authorised identified roles] 201 [selection: change_default, query, modify, delete, [assignment: other operations]] 202 [assignment: list of security attributes] 203 [assignment: the authorised identified roles] 204 [assignment: access control SFP, information flow control SFP] 205 [selection, choose one of: restrictive, permissive, [assignment: other property]] 206 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

Application note 37: The default values are defined on object creation using the command 2224 TPM2_Create, TPM2_CreatePrimary, or TPM2_CreateLoaded. 2225

FDP_UCT.1/AC Basic data exchange confidentiality (access control) 2226 Hierarchical to: No other components. 2227 Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or 2228 FTP_TRP.1 Trusted path] 2229 [FDP_ACC.1 Subset access control, or 2230 FDP_IFC.1 Subset information flow control] 2231

FDP_UCT.1.1/AC The TSF shall enforce the Access Control SFP207 to transmit208 user data 2232 in a manner protected from unauthorised disclosure. 2233

Application note 38: The SFR FDP_UCT.1/AC requires the ability to encrypt the command 2234

data in a TPM command. 2235

FTP_ITC.1/AC Inter-TSF trusted channel (access control) 2236 Hierarchical to: No other components. 2237 Dependencies: No dependencies. 2238

FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another 2239 trusted IT product that is logically distinct from other communication 2240 channels and provides assured identification of its end points and protection 2241 of the channel data from modification or disclosure. 2242

FTP_ITC.1.2 The TSF shall permit another trusted IT product209 to initiate communication 2243 via the trusted channel. 2244

FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for 2245 (1) an authorisation session, 2246 (2) an encryption session, identified by the encrypt or decrypt attribute of the 2247

session 2248 in order to transfer commands and responses between the other trusted IT 2249 product and the TOE.210 2250

Application note 39: An authorisation session or an encryption session is established by 2251 the command TPM2_StartAuthSession. The integrity protection of an authorisation session 2252 shall be implemented using a HMAC digest over the command or response data including 2253 the parameters as defined in [7]. In an encrypted session, only the first parameter shall be 2254 encrypted as long as the parameter has a size field [7]. 2255

FMT_MOF.1/AC Management of security functions behaviour (access control) 2256

207 [assignment: access control SFP(s) and/or information flow control SFP(s)] 208 [selection: transmit, receive] 209 [selection: the TSF, another trusted IT product] 210 [assignment: list of functions for which a trusted channel is required]


TCG PUBLIC REVIEW

Hierarchical to: No other components. 2257 Dependencies: FMT_SMR.1 Security roles 2258 FMT_SMF.1 Specification of Management Functions 2259

FMT_MOF.1.1/AC The TSF shall restrict the ability to disable and enable211 the functions 2260 TPM2_Clear212 to Platform firmware and the lockout administrator213. 2261

2262

7.1.5.2 Non-Volatile Storage 2263

The non-volatile memory (NV memory) is used to memorise values across power events. 2264 Especially the following values are stored in the NV memory: 2265

NV index values, 2266

objects in the TPM object hierarchy that were made persistent using the 2267

TPM2_EvictControl command (see section 37.3 of [7]), 2268

saved operational variables by TPM2_Shutdown(TPM_SU_STATE) as addressed in 2269 Table 9 and the corresponding SFRs, 2270

persistent NV data as defined in section 37.5 of [7]. 2271

NV index values may be implemented as hybrid indices in order to maintain high frequency 2272 updates. In that case the values are held in the TPM RAM as well as in the NV memory. The 2273 update is processed on the values in RAM. On index-type dependent events the values in 2274 NV memory are synchronised with the values in RAM (see section 37.2.4 of [7]). 2275

Application note 40: The TPM library specification allows usage of an external device for 2276 storing non-volatile NV data (see section 37.7.2 of [7]). If this option will be implemented, 2277 the ST writer shall model this inter-TSF user data transfer by additional SFRs FDP_UCT.1 2278 and FDP_UIT.1. 2279

FDP_ACC.1/NVM Subset access control (non-volatile memory) 2280 Hierarchical to: No other components. 2281 Dependencies: FDP_ACF.1 Security attribute based access control 2282

FDP_ACC.1.1/NVM The TSF shall enforce the NVM SFP214 on 2283 Subjects: 2284 (1) Platform firmware, 2285 (2) Platform owner, 2286 (3) USER, 2287 (4) ADMIN, 2288 (5) World 2289

Objects: 2290 (1) (ordinary, counter, bit field, extended, pin pass, pin fail) NV index, 2291 (2) objects of the TPM hierarchy 2292 Operations: 2293

211 [selection: determine the behavior of, disable, enable, modify the behaviour of] 212 [assignment: list of functions] 213 [assignment: the authorised identified roles] 214 [assignment: access control SFP]


TCG PUBLIC REVIEW

(1) TPM2_NV_DefineSpace 2294 (2) TPM2_NV_UndefineSpace 2295 (3) TPM2_NV_UndefineSpaceSpecial 2296 (4) TPM2_NV_Read 2297 (5) TPM2_NV_ReadPublic 2298 (6) TPM2_NV_Increment 2299 (7) TPM2_NV_Extend 2300 (8) TPM2_NV_SetBits 2301 (9) TPM2_NV_Write 2302 (10) TPM2_NV_ReadLock 2303 (11) TPM2_NV_WriteLock 2304 (12) TPM2_NV_Certify 2305 (13) TPM2_EvictControl215. 2306

FDP_ACF.1/NVM Security attribute based access control (non-volatile memory) 2307 Hierarchical to: No other components. 2308 Dependencies: FDP_ACC.1 Subset access control 2309 FMT_MSA.3 Static attribute initialisation 2310

FDP_ACF.1.1/NVM The TSF shall enforce the NVM SFP216 to objects based on the following: 2311 Subjects as defined in Table 7: 2312 (1) Platform firmware, Platform owner, USER, ADMIN, World with the security 2313

attributes 2314 (a) authentication status, 2315 (b) physical presence if supported by the TOE 2316

Objects as defined in Table 8: 2317 (1) NV index, NV counter index, NV bit field index, NV extend index, NV pin 2318

pass index, NV pin fail index with the security attributes: 2319 (a) NV attributes, 2320 (b) status whether physical presence is required for Platform firmware 2321

authorisation217 2322

FDP_ACF.1.2/NVM The TSF shall enforce the following rules to determine if an operation 2323 among controlled subjects and controlled objects is allowed: 2324 (1) The Platform firmware authenticated with platformAuth, platformPolicy or 2325

physical presence if supported by the TOE and the Platform owner are 2326 authorised to reserve space to hold the data associated with that index 2327 (TPM2_NV_DefineSpace). The physical presence is not required if it is not 2328 supported by the TOE or disabled for TPM2_NV_DefineSpace command. 2329

(2) The Platform firmware authenticated with platformAuth, platformPolicy or 2330 physical presence if supported by the TOE and the Platform owner are 2331

authorised to remove a NV index (TPM2_NV_UndefineSpace). The physical 2332 presence is not required if it is not supported by the TOE or disabled for 2333 TPM2_NV_UndefineSpace command. 2334





TCG PUBLIC REVIEW

(3) The Platform firmware authenticated with platformAuth, platformPolicy or 2335 physical presence if supported by the TOE is authorised to remove a 2336 platform created NV index that has the attribute 2337 TPMA_NV_POLICY_DELETE set (TPM2_NV_UndefineSpaceSpecial). The 2338 physical presence is not required if it is not supported by the TOE or 2339 disabled for TPM2_NV_UndefineSpaceSpecial command. 2340

(4) Any subject is authorised to read the public area of a NV index by the 2341 command TPM2_NV_ReadPublic. 2342

(5) The subject Platform firmware with the role USER is authorised to read a 2343 NV index by the command TPM2_NV_Read if the TPMA_NV_PPREAD value 2344 of the NV index attribute is set and the NV index is not temporarily blocked 2345 by its attribute TPMA_NV_READ_STCLEAR. If the TPMA_NV_AUTHREAD 2346 attribute is set then the authentication shall use authValue of the index, if 2347 the TPMA_NV_POLICYREAD attribute is set then the authentication shall 2348 use authPolicy of the index. 2349

(6) The subject Platform owner with the role USER is authorised to read a NV 2350 index by the command TPM2_NV_Read if the TPMA_NV_OWNERREAD 2351 value of the NV index attribute is set and the NV index is not temporarily 2352 blocked by its attribute TPMA_NV_READ_STCLEAR. If the 2353 TPMA_NV_AUTHREAD attribute is set then the authentication shall use 2354 authValue of the index, if the TPMA_NV_POLICYREAD attribute is set then 2355 the authentication shall use authPolicy of the index. 2356

(7) The subject Platform firmware with the role USER is authorised to write to 2357 a NV index if the TPMA_NV_PPWRITE value of the NV index attribute is set 2358 and the NV index is not temporarily blocked by its attribute 2359 TPMA_NV_WRITE_STCLEAR or permanently blocked by its attribute 2360 TPM_NV_WRITEDEFINE. If the TPMA_NV_AUTHWRITE attribute is set then 2361 the authentication shall use authValue of the index, if the 2362 TPMA_NV_POLICYWRITE attribute is set then the authentication shall use 2363 authPolicy of the index. 2364

(8) The subject Platform owner with the role USER is authorised to write to a 2365 NV index if the TPMA_NV_OWNERWRITE value of the NV index attribute is 2366 set and the NV index is not temporarily blocked by its attribute 2367 TPMA_NV_WRITE_STCLEAR or permanently blocked by its attribute 2368 TPM_NV_WRITEDEFINE. If the TPMA_NV_AUTHWRITE attribute is set then 2369 the authentication shall use authValue of the index, if the 2370 TPMA_NV_POLICYWRITE attribute is set then the authentication shall use 2371 authPolicy of the index. 2372

(9) An authorised subject to write a NV index (see number 7 and 8) is allowed 2373 to update a NV counter index only in the following way: 2374

a) The modification shall only be possible using the command 2375

TPM2_NV_Increment. The command TPM2_NV_Increment shall 2376 increment the value of the NV counter index by one. 2377

b) The TPM shall ensure that, when a NV counter index is read, its 2378 value is not less than a previously reported value of the counter. 2379

(10) An authorised subject to write a NV index (see number 7 and 8) is 2380 allowed to update a NV index of type “Extend” only by the command 2381 TPM2_NV_Extend. 2382


TCG PUBLIC REVIEW

(11) An authorised subject to write a NV index (see number 7 and 8) is 2383 allowed to update a NV index of type “Bit Field” only by the command 2384 TPM2_NV_SetBits. 2385

(12) An authorised subject to write a NV index (see number 7 and 8) is 2386 allowed to update a NV index that is not of type “Bit Field”, “Counter” or 2387 “Extend” by the command TPM2_NV_Write. 2388

(13) The subject platform firmware with platformAuth, platformPolicy or 2389 physical presence if supported by the TOE and the Platform owner are 2390 authorised to import transient TPM objects if they are part of any TPM 2391 hierarchy, if the object attributes allow the import and if the objects 2392 contain both public and private portions. This shall be done by the 2393 command TPM2_EvictControl. The physical presence is not required if it is 2394 not supported by the TOE or disabled for the TPM2_EvictControl command. 2395

(14) The subject platform firmware with platformAuth, platformPolicy or 2396 physical presence if supported by the TOE and the Platform owner are 2397 authorised to delete persistent TPM objects if the object attributes allow the 2398 deletion. This shall be done by the command TPM2_EvictControl. The 2399 physical presence is not required if it is not supported by the TOE or 2400 disabled for the TPM2_EvictControl command. 2401

(15) An authorised subject is allow to certify the contents of an NV index or a 2402 portion of an NV index using the command TPM2_NV_Certify218 2403

FDP_ACF.1.3/NVM The TSF shall explicitly authorise access of subjects to objects based on 2404 the following additional rules: none219. 2405

FDP_ACF.1.4/NVM The TSF shall explicitly deny access of subjects to objects based on the 2406 following additional rules: 2407 (1) If phEnableNV is CLEAR 2408

a) NV indices that have TPMA_PLATFORM_CREATE SET may not be read 2409 by TPM2_NV_Read, TPM2_NV_ReadPublic, TPM2_NV_Certify, 2410 TPM2_PolicyNV or written, by TPM2_NV_Write, TPM2_NV_Increment, 2411 TPM2_NV_Extend, TPM2_NV_SetBits (TPM_RC_HANDLE). 2412

b) The platform cannot define (TPM_RC_HIERARCHY) or undefined 2413 (TPM_RC_HANDLE) indices220. 2414

Application note 41: The blocking of read or write access to NV indices shall be reset on 2415 TPM Reset or TPM Restart. This is addressed in the TPM state control SFP, see 2416 FDP_ACF.1/States and Table 9. 2417

FMT_MSA.1/NVM Management of security attributes (non-volatile memory) 2418





TCG PUBLIC REVIEW


FMT_MSA.1.1/NVM TSF shall enforce the NVM SFP221 to restrict the ability to query and 2424 modify222 the security attributes NV index attributes223 to the authorised role of 2425 the subject that executes the NV related command.224 2426

FMT_MSA.3/NVM Static attribute initialisation (non-volatile memory) 2427 Hierarchical to: No other components. 2428 Dependencies: FMT_MSA.1 Management of security attributes 2429 FMT_SMR.1 Security roles 2430

FMT_MSA.3.1/NVM The TSF shall enforce the NVM SFP225 to provide restrictive226 default 2431 values for security attributes that are used to enforce the SFP. 2432

FMT_MSA.3.2/NVM The TSF shall allow the nobody227 to specify alternative initial values to 2433 override the default values when an object or information is created. 2434

FMT_MSA.4/NVM Security attribute value inheritance (NVM) 2435 Hierarchical to: No other components. 2436 Dependencies: [FDP_ACC.1 Subset access control, or 2437 FDP_IFC.1 Subset information flow control] 2438

FMT_MSA.4.1/NVM The TSF shall use the following rules to set the value of security 2439 attributes: 2440 (1) If TPMA_NV_READ_STCLEAR of the NV Index is SET and the authPolicy of 2441

the NV Index is provided and 2442 a) TPMA_NV_PPREAD is set and platformAuth is provided or 2443 b) TPMA_NV_OWNERREAD is set and ownerAuth is provided or 2444 c) TPMA_NV_AUTHREAD is set and authValue is provided 2445 the command TPM2_NV_ReadLock shall SET TPMA_NV_READLOCKED for 2446 the NV Index. TPMA_NV_READLOCKED will be CLEAR by the next 2447 TPM2_Startup(TPM_SU_CLEAR). 2448

(2) If TPMA_NV_WRITEDEFINE or TPMA_NV_WRITE_STCLEAR attributes of an 2449 NV location are SET and the authPolicy of the NV Index is provided and 2450 a) TPMA_NV_PPWRITE is set and platformAuth is provided or 2451 b) TPMA_NV_OWNERWRITE is set and ownerAuth is provided or 2452 c) TPMA_NV_AUTHWRITE is set and authValue is provided 2453

221 [assignment: access control SFP(s), information flow control SFP(s)] 222 [selection: change_default, query, modify, delete, [assignment: other operations]] 223 [assignment: list of security attributes] 224 assignment: the authorised identified roles] 225 [assignment: access control SFP, information flow control SFP] 226 [selection, choose one of: restrictive, permissive, [assignment: other property]] 227 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

the command TPM2_NV_WriteLock shall SET TPMA_NV_WRITELOCKED 2454 for the NV Index. TPMA_NV_WRITELOCKED will be clear on the next 2455 TPM2_Startup(TPM_SU_CLEAR) unless TPMA_NV_WRITEDEFINE is SET. 2456

Application note 42: If TPMA_NV_READ_STCLEAR of the NV Index is CLEAR, then the 2457 TPM shall return on command TPM2_NV_ReadLock the TPM_RC_NV_ATTRIBUTE. If neither 2458 TPMA_NV_WRITEDEFINE nor TPMA_NV_WRITE_STCLEAR of the NV Index is SET, then the 2459 TPM shall return on command TPM2_NV_WriteLock the TPM_RC_ATTRIBUTES. 2460

FMT_MTD.1/NVM Management of TSF data (non-volatile memory) 2461 Hierarchical to: No other components. 2462 Dependencies: FMT_SMR.1 Security roles 2463 FMT_SMF.1 Specification of Management Functions 2464

FMT_MTD.1.1/NVM The TSF shall restrict the ability to modify228 the authorisation secret 2465 (authValue) for a NV index229 to ADMIN230 using the command 2466 TPM2_NV_ChangeAuth. 2467

FDP_ITC.1/NVM Import of user data without security attributes (non-volatile 2468 memory) 2469

Hierarchical to: No other components. 2470 Dependencies: [FDP_ACC.1 Subset access control, or 2471 FDP_IFC.1 Subset information flow control] 2472 FMT_MSA.3 Static attribute initialisation 2473

FDP_ITC.1.1/NVM The TSF shall enforce the NVM SFP231 when importing user data, 2474 controlled under the SFP, from outside of the TOE. 2475

FDP_ITC.1.2/NVM The TSF shall ignore any security attributes associated with the user 2476 data when imported from outside the TOE. 2477

FDP_ITC.1.3/NVM The TSF shall enforce the following rules when importing user data 2478 controlled under the SFP from outside the TOE: none232 2479

FDP_ETC.1/NVM Export of user data without security attributes (non-volatile 2480 memory) 2481

Hierarchical to: No other components. 2482 Dependencies: [FDP_ACC.1 Subset access control, or 2483 FDP_IFC.1 Subset information flow control] 2484

FDP_ETC.1.1/NVM The TSF shall enforce the NVM SFP233 when exporting user data, 2485 controlled under the SFP(s), outside of the TOE. 2486

228 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 229 [assignment: list of TSF data] 230 [assignment: the authorised identified roles] 231 [assignment: access control SFP(s) and/or information flow control SFP(s)] 232 [assignment: additional importation control rules] 233 [assignment: access control SFP(s) and/or information flow control SFP(s)]


TCG PUBLIC REVIEW

FDP_ETC.1.2/NVM The TSF shall export the user data without the user data's associated 2487 security attributes. 2488

7.1.5.3 Credentials 2489

Credentials in the context of this PP are understood as a means to provide evidence that a 2490 dedicated TPM object is resident on an authentic TPM. To get a credential, the protocol 2491 involves two parties: the initiator of the credential process and the credential provider. On 2492 request by the initiator the credential provider shall generate the evidence. For privacy 2493 reasons, the generated credential shall not contain the identity of a particular TPM where 2494 the object belongs to. Instead, the credential shall prove that the object is resident on a TPM 2495 that the credential provider believes to be authentic. 2496

FDP_ACC.1/Cre Subset access control (credentials) 2497 Hierarchical to: No other components. 2498

Dependencies: FDP_ACF.1 Security attribute based access control 2499

FDP_ACC.1.1/Cre The TSF shall enforce the Credential SFP234 on 2500 Subjects 2501 (1) USER, 2502 (2) ADMIN, 2503 (3) World 2504

Objects 2505 (1) Credential 2506

Operations 2507 (1) TPM2_ActivateCredential.235 2508

FDP_ACF.1/Cre Security attribute based access control (credentials) 2509 Hierarchical to: No other components. 2510 Dependencies: FDP_ACC.1 Subset access control 2511 FMT_MSA.3 Static attribute initialisation 2512

FDP_ACF.1.1/Cre The TSF shall enforce the Credential SFP236 to objects based on the 2513 following: 2514 Subjects 2515 (1) USER with authentication state gained with userAuth or authPolicy, 2516 (2) ADMIN with authentication state gained with adminAuth or authPolicy, 2517 (3) World with no security attributes 2518

Objects 2519 (1) Credential with security attribute HMAC over the credential BLOB237. 2520


SFP] 236 [assignment: access control SFP] 237 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-



TCG PUBLIC REVIEW

FDP_ACF.1.2/Cre The TSF shall enforce the following rules to determine if an operation 2521 among controlled subjects and controlled objects is allowed: 2522 (1) The subject World is authorised to create a credential using the command 2523

TPM2_MakeCredential. 2524 (2) The subject of role ADMIN regarding the object for which the credential was 2525

created and the role USER regarding the key for the decryption of the 2526 credential BLOB is authorised to activate the credential using the 2527 command TPM2_ActivateCredential238. 2528

FDP_ACF.1.3/Cre The TSF shall explicitly authorise access of subjects to objects based on 2529 the following additional rules: none239. 2530

FDP_ACF.1.4/Cre The TSF shall explicitly deny access of subjects to objects based on the 2531 following additional rules: none240. 2532

FMT_MSA.3/Cre Static attribute initialisation (credentials) 2533 Hierarchical to: No other components. 2534 Dependencies: FMT_MSA.1 Management of security attributes 2535 FMT_SMR.1 Security roles 2536

FMT_MSA.3.1/Cre The TSF shall enforce the Credential SFP241 to provide restrictive242 2537 default values for security attributes that are used to enforce the SFP. 2538

FMT_MSA.3.2/Cre The TSF shall allow the nobody243 to specify alternative initial values to 2539 override the default values when an object or information is created. 2540

FMT_MSA.1/Cre Management of security attributes (credentials) 2541 Hierarchical to: No other components. 2542 Dependencies: [FDP_ACC.1 Subset access control, or 2543 FDP_IFC.1 Subset information flow control] 2544 FMT_SMR.1 Security roles 2545 FMT_SMF.1 Specification of Management Functions 2546

FMT_MSA.1.1/Cre TSF shall enforce the Credential SFP244 to restrict the ability to use245 2547 the security attributes HMAC in the credential BLOB246 to USER247. 2548

FCO_NRO.1/Cre Selective proof of origin (credentials) 2549



240 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 241 [assignment: access control SFP, information flow control SFP] 242 [selection, choose one of: restrictive, permissive, [assignment: other property]] 243 [assignment: the authorised identified roles] 244 [assignment: access control SFP(s), information flow control SFP(s)] 245 [selection: change_default, query, modify, delete, [assignment: other operations]] 246 [assignment: list of security attributes] 247 [assignment: the authorised identified roles]


TCG PUBLIC REVIEW

Hierarchical to: No other components. 2550 Dependencies: FIA_UID.1 Timing of identification 2551

FCO_NRO.1.1/Cre The TSF shall be able to generate evidence of origin for transmitted TPM 2552 objects248 at the request of the originator249. 2553

FCO_NRO.1.2/Cre The TSF shall be able to relate the information whether the object is 2554 resident in an authentic TPM250 of the originator of the information, and the 2555 name and the public area of the TPM object251 of the information to which the 2556 evidence applies. 2557

FCO_NRO.1.3/Cre The TSF shall provide a capability to verify the evidence of origin of 2558 information to the initiator252 given based on a credential BLOB that was 2559 generated by the credential provider253. 2560

7.2 Security assurance requirements 2561

The Security Assurance Requirements (SAR) for the TOE are the assurance components of 2562 Evaluation Assurance Level 4 (EAL4) as defined in CC part 3 and augmented with 2563 ALC_FLR.1 and AVA_VAN.4. 2564

Table 10: Security assurance requirements for the TOE 2565

Assurance Class Assurance components

ADV: Development ADV_ARC.1 Security architecture description

ADV_FSP.4 Complete functional specification

ADV_IMP.1 Implementation representation of the TSF

ADV_TDS.3 Basic modular design

AGD: Guidance documents AGD_OPE.1 Operational user guidance

AGD_PRE.1 Preparative procedures

ALC: Life-cycle support ALC_CMC.4 Production support, acceptance procedures and automation

ALC_CMS.4 Problem tracking CM coverage

ALC_DEL.1 Delivery procedures

ALC_DVS.1 Identification of security measures

ALC_LCD.1 Developer defined life-cycle model

ALC_FLR.1 Basic flow remediation

248 [assignment: list of information types] 249 [selection: originator, recipient, [assignment: list of third parties]] 250 [assignment: list of attributes] 251 [assignment: list of information fields] 252 [selection: originator, recipient, [assignment: list of third parties]] 253 [assignment: limitations on the evidence of origin]


TCG PUBLIC REVIEW

Assurance Class Assurance components

ALC_TAT.1 Well-defined development tools

ASE: Security Target evaluation ASE_CCL.1 Conformance claims

ASE_ECD.1 Extended components definition

ASE_INT.1 ST introduction

ASE_OBJ.2 Security objectives

ASE_REQ.2 Derived security requirements

ASE_SPD.1 Security problem definition

ASE_TSS.1 TOE summary specification

ATE: Tests ATE_COV.2 Analysis of coverage

ATE_DPT.1 Testing: security enforcing modules

ATE_FUN.1 Functional testing

ATE_IND.2 Independent testing - sample

AVA: Vulnerability assessment AVA_VAN.4 Methodical vulnerability analysis

2566


TCG PUBLIC REVIEW

7.3 Security Requirements rationale 2567

7.3.1 Sufficiency of SFR 2568

The following table demonstrates that each security objective for the TOE is covered by at 2569 least one SFR and each SFR is traced back to at least one security objective for the TOE. 2570

Table 11: Security requirements rationale 2571

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

FMT_SMR.1 x x

FMT_SMF.1 x

FMT_MSA.2 x

FCS_RNG.1 x

FPT_STM.1 x

FIA_SOS.2 x

FMT_MTD.1/AUTH x

FIA_AFL.1/Lockout x x

FIA_AFL.1/Recover x x

FIA_AFL.1/PINFAIL x x

FIA_AFL.1/PINPASS x x

FIA_AFL.1/PINPASS Authentication failure handling

Hierarchical to:

No

x x


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

oth

er components.

Dependencies: FIA_UAU.1 Timing of authentication.

FIA_AFL.1.1/PINPASS

The TSF shall detect when pinCou

nt successful authentication events exceeds pinLimit for an


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

NV Index with the

attribute TPM_NT_PIN_PASS.

FIA_AFL.1.2/ PINPASS

When the defined number of successful authentication events has been met, the TSF shall block further authorization attempt

s.

FIA_AFL.1/PINFAIL Authentication failure handling

Hierarchic


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

al

to:

No other components.


FIA_AFL.1.1/PINFAIL

The TSF shall detect when


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

pinCount unsucc

essful authentication attempts exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_FAIL.

FIA_AFL.1.2/ PINFAIL

When the defined number of unsuccessful authentication

attempts has been met, the TSF shall block further


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

authorization attempt

s.

FIA_UID.1

FIA_UAU.1 x x

FIA_UAU.5 x x x x x

FIA_UAU.6 x x

FIA_USB.1 x x x x

FMT_MSA.4/AUTH x x x

FDP_ACC.2/States x x

FDP_ACF.1/States x x

FMT_MSA.1/States x x x

FMT_MSA.3/States x x x

FDP_UIT.1/States x x

FPT_TST.1 x x x

FDP_ACC.1/AC x x

FDP_ACF.1/AC x x

FMT_MSA.1/AC x x x

FMT_MSA.3/AC x x x

FDP_UCT.1/AC x

FTP_ITC.1/AC x

FMT_MOF.1/AC x

FCS_CKM.1/PK x

FCS_CKM.1/ECC x x x x

FCS_CKM.1/RSA x

FCS_CKM.1/SYMM x

FCS_CKM.4 x

FCS_COP.1/AES x x x x x

FCS_COP.1/SHA x x x

FCS_COP.1/HMAC x x x x x x


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

FCS_COP.1/RSAED x x x

FCS_COP.1/RSASign x x

FCS_COP.1/ECDSA x x

FCS_COP.1/ECDAA x

FCS_COP.1/ECDEC x x

FDP_ACC.1/NVM x

FDP_ACF.1/NVM x

FMT_MSA.1/NVM x x

FMT_MSA.3/NVM x x

FMT_MSA.4/NVM x x

FMT_MTD.1/NVM x x

FDP_ITC.1/NVM x

FDP_ETC.1/NVM x

FDP_ACC.1/ExIm x x x

FDP_ACF.1/ExIm x x x

FMT_MSA.1/ExIm x x x x

FMT_MSA.3/ExIm x x x x

FDP_ETC.2/ExIm x x

FDP_ITC.2/ExIm x x

FDP_UCT.1/ExIm x x x

FDP_UIT.1/ExIm x x x x

FDP_ACC.1/Cre x

FDP_ACF.1/Cre x

FMT_MSA.1/Cre x x

FMT_MSA.3/Cre x x

FCO_NRO.1/Cre x x x

FDP_ACC.1/M&R x x

FDP_ACF.1/M&R x x x

FMT_MSA.1/M&R x x x x

FMT_MSA.3/M&R x x x x

FCO_NRO.1/M&R x x x


TCG PUBLIC REVIEW

O.C

on

text_

Man

agem

en

t

O.C

rypto

_K

ey_M

an

O.E

CD

AA

O.D

AC

O.E

xport

O.F

ail_S

ecu

re

O.G

en

era

l_In

teg_C

hecks

O.I

&A

O.I

mport

O.L

imit

_A

cti

on

s_A

uth

O.L

ocality

O.R

ecord

_M

easu

rem

en

t

O.M

essageN

R

O.N

o_R

esid

ual_

Info

O.R

eport

ing

O.S

ecu

rity

_A

ttr_

Mgt

O.S

ecu

rity

_R

ole

s

O.S

elf_Test

O.S

ingle

_A

uth

O.S

essio

ns

O.T

am

per_

Resis

tan

ce

O.F

ield

Upgra

deC

on

trol

FDP_RIP.1 x

FPT_FLS.1/FS x x

FPT_FLS.1/SD x x

FPT_PHP.3 x

FDP_ITT.1 x

FPT_ITT.1 x

FDP_SDI.1 x x x

FDP_ACC.1/Hier x

FDP_ACF.1/Hier x

FMT_MSA.1/Hier x x

FMT_MSA.3/Hier x x

FMT_MSA.4/Hier x x

2572

A detailed justification required for suitability of the security functional requirements to 2573 achieve the security objectives is given below. 2574

The security objective O.Context_Management requires that the TOE protects the 2575 confidentiality and integrity of the data of a resource and allows the restoring of the 2576 resource on the same TPM and during the same operational cycle only. This objective is 2577 addressed by the following SFRs: 2578

FDP_ETC.2/ExIm requires that the TSF shall apply a policy when exporting user 2579 data. The policy rules require the protection of data integrity and confidentiality at 2580 export of objects from the TPM hierarchy. 2581

FDP_ITC.2/ExIm require that the TSF shall apply a policy when importing user data. 2582 The security attributes shall be unambiguously associated with the user data while 2583 importing. 2584

FDP_UCT.1/ExIm require that the TSF protects the confidentiality of transmitted 2585 user data while data export and import. 2586

FDP_UIT.1/ExIm require that the TSF protects the integrity of transmitted user data 2587 while data export and import. 2588

FCS_COP.1/HMAC requires that the TSF provides the ability to generate and verify 2589 HMAC values. 2590

FCS_COP.1/AES requires that the TSF provides the ability to perform symmetric 2591 encryption and decryption of data. 2592


TCG PUBLIC REVIEW

The security objective O.Crypto_Key_Man requires the secure management of 2593 cryptographic keys including its generation using the TOE random number generator as 2594 source of randomness. This objective is addressed by the following SFRs: 2595

FCS_CKM.1/PK requires the TSF to generate primary cryptographic keys by means 2596 of defined key generation functions. 2597

FCS_CKM.1/RSA requires the TSF to generate cryptographic RSA keys in accordance 2598 with a assigned key generation algorithm. 2599

FCS_CKM.1/ECC requires the TSF to generate cryptographic ECC keys in 2600 accordance with a assigned key generation algorithm. 2601

FCS_CKM.1/SYMM requires the TSF to generate cryptographic symmetric keys in 2602 accordance with a assigned key generation algorithm. 2603

FCS_CKM.4 requires the TSF to be able destroy cryptographic keys in accordance 2604 with a specific key destruction method. 2605

FCS_COP.1/HMAC requires that the TSF provides the ability to generate and verify 2606 HMAC values. This is required for the specified key generation algorithm according to 2607 FCS_CKM.1/PK. 2608


FCS_RNG.1 requires the TSF to provide a random number generator. This is used as 2611 source of randomness in the specified key generation algorithm according to 2612 FCS_CKM.1/PK. 2613

The security objective O.ECDAA requires that the TOE to implement the TPM part of the 2614 ECDAA signing operation. This is directly addressed by the SFRs FCS_CKM.1/ECC and 2615 FCS_COP.1/ECDAA: While FCS_CKM.1/ECC requires the ability of the TSF to generate 2616 ECC keys, the SFR FCS_COP.1/ECDAA requires the TSF to implement the ECDAA 2617 algorithm, and to the proof of origin FDP_ACF.1/M&R and FCO_NRO.1/M&R. 2618

The security objective O.DAC requires that the TOE controls and restricts user access to the 2619 TOE protected capabilities and shielded locations in accordance with the specified access 2620 control policies. The object owner shall manage the access rights using the principle of least 2621 privilege. This objective is addressed by the following SFRs: 2622

FIA_USB.1 addresses the association between subjects and its security attributes. 2623 The SFR defines rules for initial association and changes of these associations. 2624

FDP_ACC.2/States requires that the TSF enforces the TPM State Control SFP on all 2625 subjects, objects and operations among subjects and objects covered by the SFP. The 2626 operations shall be covered by an access control SFP. 2627

FDP_ACF.1/States defines rules to enforce a policy regarding the TOE states, 2628

transitions between states and required authorisations to change the state of the 2629 TOE. 2630

FMT_MSA.1/States requires that a TSF shall enforce the TPM State Control SFP to 2631 restrict the ability to modify the TOE state. 2632

FMT_MSA.3/States requires that the TSF shall enforce the TPM State Control SFP to 2633 provide restrictive default values for security attributes and nobody is authorised to 2634 specify alternative default initial values. 2635


TCG PUBLIC REVIEW

FDP_ACC.1/AC requires that the TSF enforces a SPF for access control regarding 2636 dedicated subjects, objects and operations among subjects and objects covered by 2637 the SFP. 2638

FDP_ACF.1/AC defines rules to enforce a policy regarding the TOE access control 2639 and the required authorisations to perform dedicated operations. 2640

FMT_MSA.1/AC requires that a TSF shall enforce a SFP to restrict the ability to 2641 perform dedicated operations on security attributes to dedicated authorised roles. 2642

FMT_MSA.3/AC requires that the TSF shall enforce a SFP to provide restrictive 2643 default values for security attributes and only dedicated roles are authorised to 2644 specify alternative default initial values. 2645

FMT_MSA.4/AUTH defines rules to disable the security attributes authValue and 2646 authPolicy. 2647

FMT_MOF.1/AC requires the TSF to restrict the ability to disable and enable the 2648 TPM2_Clear function to dedicated authorised roles. 2649

FDP_ACC.1/NVM requires that the TSF enforces a SPF for access control regarding 2650 dedicated subjects, objects and NVM related operations among subjects and objects 2651 covered by the SFP. 2652

FDP_ACF.1/NVM defines rules to enforce a policy regarding the NVM access control 2653 and the required authorisations to perform dedicated operations. 2654

FMT_MSA.1/NVM requires that a TSF shall enforce a SFP to restrict the ability to 2655 query and modify NV index attributes. 2656

FMT_MSA.3/NVM requires that the TSF shall enforce a SFP to provide restrictive 2657 default values for security attributes and nobody is authorised to specify alternative 2658 default initial values. 2659

FMT_MSA.4/NVM requires management of security attributes controlling read access 2660 to NVM. 2661

FMT_MTD.1/NVM requires that the TSF restricts the ability to change the 2662 authorisation secret for an NV index to a special role. 2663

FDP_ACC.1/ExIm requires that the TSF enforces a SPF for access control regarding 2664 dedicated subjects, objects and export/import operations among subjects and 2665 objects covered by the SFP. 2666

FDP_ACF.1/ExIm defines rules to enforce a policy regarding the access control and 2667 the required authorisations to perform export and import related operations. 2668

FMT_MSA.1/ExIm requires that a TSF shall enforce a SFP to restrict the ability to 2669 use the security attribute authorisation data for export and import related functions. 2670

FMT_MSA.3/ExIm requires that the TSF shall enforce a SFP to provide restrictive 2671 default values for security attributes for export and import related functions. Nobody 2672

is authorised to specify alternative default initial values for those security attributes. 2673

FDP_ACC.1/M&R requires that the TSF enforces a SPF for access control regarding 2674 dedicated subjects, PCR and corresponding operations covered by the SFP. 2675

FDP_ACF.1/M&R defines rules to enforce a policy regarding the PCR access control 2676 and the required authorisations to perform PCR related operations. 2677

FMT_MSA.1/M&R requires that a TSF shall enforce a SFP to restrict the ability to 2678 modify the PCR related security attributes. 2679


TCG PUBLIC REVIEW

FMT_MSA.3/M&R requires that the TSF shall enforce a SFP to provide restrictive 2680 default values for security attributes for measurement and reporting related 2681 functions. Nobody is authorised to specify alternative default initial values for those 2682 security attributes. 2683

FDP_ACC.1/Hier requires that the TSF enforces a SPF for access control regarding 2684 dedicated subjects, objects and TPM hierarchy related operations among subjects 2685 and objects covered by the SFP. 2686

FDP_ACF.1/Hier defines rules to enforce a policy regarding the access control and 2687 the required authorisations to perform TPM hierarchy related operations. 2688

FMT_MSA.1/Hier requires that a TSF shall enforce a SFP to restrict the ability to 2689 modify the security attributes fixedTPM and fixedParent. 2690

FMT_MSA.3/Hier requires that the TSF shall enforce a SFP to provide restrictive 2691 default values for security attributes for TPM hierarchy related operations. The 2692 creator of the TPM object is authorised to specify alternative default initial values for 2693 those security attributes. 2694

FMT_MSA.4/Hier limits the management of security attributes of hierarchies. 2695

The security objective O.Export requires that the TOE protects the confidentiality and 2696 integrity of data in case of export. Further, the TOE shall unambiguously associate the data 2697 security attributes with the data to be exported. This objective is addressed by the following 2698 SFRs: 2699

FCS_COP.1/RSAED requires that the TSF provides the ability to perform RSA based 2700 asymmetric encryption and decryption of data. 2701

FCS_COP.1/ECDEC requires that the TSF provides the ability to perform elliptic 2702 curve based asymmetric decryption of data. 2703

FCS_CKM.1/ECC requires that the TSF provides the ability to generate keys for 2704 elliptic curve based algorithms. 2705



FDP_ETC.1/NVM requires that the TSF enforces a SFP when exporting user data 2710 from NV memory. 2711




FMT_MSA.3/ExIm requires that the TSF shall enforce a SFP to provide restrictive 2719 default values for security attributes for export and import related functions. Nobody 2720 is authorised to specify alternative default initial values for those security attributes. 2721


TCG PUBLIC REVIEW

FDP_ETC.2/ExIm requires that the TSF shall apply a policy when exporting user 2722 data. The policy rules require the protection of data integrity and confidentiality at 2723 export of objects from the TPM hierarchy. 2724



FDP_SDI.1 requires that the TSF shall monitor stored user data for modification and 2729 modification of the TPM hierarchies. 2730

The security objective O.Fail_Secure requires that the TOE enters a secure failure mode in 2731 case of a failure. To address this security objective, FPT_FLS.1/FS requires the TSF to 2732 preserve a secure state by entering a fail state and FPT_FLS.1/SD requires the TSF to 2733 preserve a secure state by shutdown of the TOE. FPT_TST.1 requires the TSF to provide self 2734

tests in order to detect failure situations. 2735

The security objective O.General_Integ_Checks requires the ability of the TOE to check the 2736 system integrity and user data integrity. This objective is addressed by the following SFRs: 2737

FPT_TST.1 requires the TSF to provide self tests in order to detect failure situations. 2738 This self tests may include tests of the system and data integrity. 2739

FCO_NRO.1/Cre requires the TSF to be able to generate evidence of origin for 2740 transmitted TPM objects and to verify this evidence. 2741


The security objective O.I&A requires that the TOE identifies all users and authenticates 2744 the claimed identity except the role “World” before granting a user access to the TOE 2745 facilities. This objective is addressed by the following SFRs: 2746

FIA_SOS.2 requires the TSF to generate secrets for usage in the authentication 2747 functionality. 2748

FMT_MTD.1/AUTH requires the TSF to restrict the management of authentication 2749 data to dedicated authorised roles. 2750

FMT_MSA.4/AUTH defines rules for management of the security attributes 2751 controlling the use of authentication mechanisms for authorisation of objects. 2752

FIA_AFL.1/Lockout and FIA_AFL.1/Recover require the TSF to detect attacks to the 2753 authentication system by a number of ongoing unsuccessful authentication requests. 2754 On detection the TSF shall block that authentication method. 2755

FIA_AFL.1/PINPASS Authentication failure handling 2756 Hierarchical to: No other components. 2757

Dependencies: FIA_UAU.1 Timing of authentication. 2758

FIA_AFL.1.1/PINPASS The TSF shall detect when pinCount successful authentication events 2759 exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_PASS. 2760

FIA_AFL.1.2/ PINPASS When the defined number of successful authentication events has been 2761 met, the TSF shall block further authorization attempts. 2762

FIA_AFL.1/PINFAIL Authentication failure handling 2763


TCG PUBLIC REVIEW


FIA_AFL.1.1/PINFAIL The TSF shall detect when pinCount unsuccessful authentication 2766 attempts exceeds pinLimit for an NV Index with the attribute 2767 TPM_NT_PIN_FAIL. 2768

FIA_AFL.1.2/ PINFAIL When the defined number of unsuccessful authentication attempts has 2769 been met, the TSF shall block further authorization attempts. 2770

FIA_UID.1 requires the TSF to allow dedicated commands before an user is 2771 identified. For any other TSF mediated action the TSF shall require the successful 2772 identification of the user. 2773

FIA_UAU.1 requires the TSF to allow dedicated commands before an user is 2774 authenticated. For any other TSF mediated action the TSF shall require the 2775

successful authentication of the user. 2776

FIA_UAU.5 requires the TSF to provide dedicated authentication mechanisms. 2777 Further, the TSF shall follow the given rules when authenticating any user’s identity. 2778

FIA_UAU.6 requires the TSF to re-authenticate the user when multiple commands 2779 need to be executed in one authorisation session. 2780


FCS_COP.1/HMAC requires that the TSF provides the ability to generate and verify 2783 HMAC values. This is used for integrity and authenticity verification. 2784

FCS_CKM.1/ECC requires that the TSF provides the ability to generate keys for 2785 elliptic curve based algorithms. 2786

FCS_COP.1/ECDEC requires that the TSF provides the ability to perform elliptic 2787 curve based asymmetric decryption of data. 2788

The security objective O.Import requires that the TOE ensures that the data security 2789 attributes are being imported with the imported data and that the data is from authorised 2790 source. Further, the TOE shall verify the security attributes according to the TSF access 2791 control rules. The TOE shall support the protection of confidentiality and the verification of 2792 the integrity of imported data (except the verification of the integrity of the data within a 2793 sealed data blob). This objective is addressed by the following SFRs: 2794

FDP_UIT.1/States requires that the TSF shall enforce a SFP to provide and use 2795 integrity protection capabilities for firmware update data on reception of that data. 2796

FCS_COP.1/RSAED requires that the TSF provides the ability to perform asymmetric 2797 encryption and decryption of data. 2798

FCS_COP.1/HMAC requires that the TSF provides the ability to generate and verify 2799

HMAC values. 2800


FDP_ITC.1/NVM requires that the TSF enforces a SFP when importing user data 2803 controlled under the SFP. The TSF shall enforce given rules on import of those user 2804 data. 2805


TCG PUBLIC REVIEW




FMT_MSA.3/ExIm requires that the TSF shall enforce a SFP to provide restrictive 2813 default values for security attributes for export and import related functions. Nobody 2814 is authorised to specify alternative default initial values for those security attributes. 2815

FDP_ITC.2/ExIm require that the TSF shall apply a policy when importing user data. 2816 The security attributes shall be unambiguously associated with the user data while 2817 importing. 2818




The security objective O.Limit_Actions_Auth requires that the TOE restricts the actions a 2825 user may perform before the TOE verified the identity of the user. This includes 2826 requirements for physical presence of the platform firmware if physical presence is 2827 supported and enabled for the required command. This is directly addressed by the SFR 2828 FIA_UAU.1 which requires the TSF to allow only dedicated commands before an user is 2829 authenticated. For any other TSF mediated action the TSF shall require the successful 2830 authentication of the user. 2831

The security objective O.Locality requires that the TOE controls the access to objects based 2832 on the locality of the process communicating with the TPM. This objective is addressed by 2833 the following SFRs: 2834

FIA_UAU.5 requires the TSF to provide dedicated authentication mechanisms. 2835 Further, the TSF shall follow the given rules when authenticating any user’s identity. 2836

FDP_ACC.1/AC requires that the TSF enforces a SPF for access control regarding 2837 dedicated subjects, objects and operations among subjects and objects covered by 2838 the SFP. 2839

FDP_ACF.1/AC defines rules to enforce a policy regarding the TOE access control 2840 and the required authorisations to perform dedicated operations. 2841

FMT_MSA.1/AC requires that a TSF shall enforce a SFP to restrict the ability to 2842 perform dedicated operations on security attributes to dedicated authorised roles. 2843

FMT_MSA.3/AC requires that the TSF shall enforce a SFP to provide restrictive 2844 default values for security attributes and only dedicated roles are authorised to 2845 specify alternative default initial values. 2846



TCG PUBLIC REVIEW

The security objective O.Record_Measurement requires that the TOE supports calculating 2849 hash values and recording the result of a measurement. This is directly addressed by the 2850 SFR FCS_COP.1/SHA which requires the TSF to be able to perform hash value calculations. 2851 The aspect of recording the results is realised by the ability of the TOE to derive access 2852 control measures based on the result of measurement. The SFRs FIA_UAU.5, 2853 FMT_MSA.1/M&R and FMT_MSA.3/M&R are involved in that ability: FIA_UAU.5 requires 2854 the TSF to provide dedicated authentication mechanisms including policy based 2855 authentication using the value of PCR. Further, the TSF shall follow the given rules when 2856 authenticating any user’s identity. The SFR FMT_MSA.1/M&R requires that a TSF shall 2857 enforce a SFP to restrict the ability to modify the PCR related security attributes, 2858 FMT_MSA.3/M&R requires that the TSF shall enforce a SFP to provide restrictive default 2859 values for security attributes for measurement and reporting related functions. Nobody is 2860 authorised to specify alternative default initial values for those security attributes. 2861 Regarding the access control of PCR related operations the following SFRs support the 2862 security objective: 2863

FDP_ACC.1/M&R requires that the TSF enforces a SPF for access control regarding 2864 dedicated subjects, PCR and corresponding operations covered by the SFP. 2865

FDP_ACF.1/M&R defines rules to enforce a policy regarding the PCR access control 2866 and the required authorisations to perform PCR related operations. 2867

The security objective O.MessageNR requires that the TOE provides user data integrity, 2868 source authentication and the basis for source non-repudiation when exchanging data with 2869 a remote system. This objective is addressed by the following SFRs: 2870

FPT_STM.1 requires that the TSF is able to provide reliable timestamps. 2871

FCS_COP.1/SHA requires the TSF to be able to perform hash value calculations. 2872 This can be used to support data integrity protection. 2873

FCS_COP.1/RSASign requires the TSF to be able to perform signature generation 2874 and verification. This can be used to support source authentication and source non-2875 repudiation when exchanging data with a remote system. 2876

FCS_COP.1/ECDSA requires the TSF to be able to perform signature generation and 2877 verification. This can be used to support source authentication and source non-2878 repudiation when exchanging data with a remote system. 2879


FDP_ACC.1/Cre requires that the TSF enforces a SPF for access control regarding 2882 the handling of credentials. 2883

FDP_ACF.1/Cre defines rules to enforce a policy regarding the handling of 2884 credentials. 2885

FMT_MSA.1/Cre requires that a TSF shall enforce a SFP to restrict the ability to 2886 manage credentials for TPM objects. 2887

FMT_MSA.3/Cre requires that the TSF shall enforce a SFP to provide restrictive 2888 default values for security attributes and nobody is authorised to specify alternative 2889 default initial values. 2890



TCG PUBLIC REVIEW

FCO_NRO.1/M&R requires the TSF to be able to generate evidence of origin for 2893 transmitted attestation structures and to verify this evidence. 2894

The security objective O.No_Residual_Info requires that there is no residual information in 2895 information containers or system resources upon their reallocation to different users. This 2896 objective is directly addressed by the SFR FDP_RIP.1 that requires that the TSF ensures 2897 that any previous information content of any object is made unavailable upon the 2898 deallocation of the resource. 2899

The security objective O.Reporting requires that the TOE reports measurement digests and 2900 attests to the authenticity of measurement digests. This objective is addressed by the 2901 following SFRs: 2902

FCS_COP.1/RSASign requires the TSF to be able to perform signature generation 2903 and verification. This can be used to support authentication of measurement digests. 2904

FCS_COP.1/ECDSA requires the TSF to be able to perform signature generation and 2905 verification. This can be used to support authentication of measurement digest. 2906


FMT_MSA.1/M&R requires that a TSF shall enforce a SFP to restrict the ability to 2909 modify the PCR related security attributes. 2910

FMT_MSA.3/M&R requires that the TSF shall enforce a SFP to provide restrictive 2911 default values for security attributes for measurement and reporting related 2912 functions. Nobody is authorised to specify alternative default initial values for those 2913 security attributes. 2914

FCO_NRO.1/M&R requires the TSF to be able to generate evidence of origin for 2915 transmitted attestation structures and to verify this evidence. 2916

The security objective O.Security_Attr_Mgt requires that the TOE allows only authorised 2917 users to initialise and to change security attributes of objects and subjects. This 2918 management shall be based on least privilege by means of role based administration and 2919 separation of duty. This objective is addressed by the following SFRs: 2920

FMT_SMF.1 requires the TSF to be able to perform different management functions 2921 which are listed in the SFR. 2922

FMT_MSA.2 requires that the TSF only accepts secure values for the security 2923 attributes that are listed in the SFR. 2924

FMT_MSA.4/AUTH defines rules to disable the security attributes authValue and 2925 authPolicy. 2926

FMT_MSA.1/States requires that a TSF shall enforce the TPM state control SFP to 2927 restrict the ability to modify the TOE state. 2928

FMT_MSA.3/States requires that the TSF shall enforce the TPM state control SFP to 2929 provide restrictive default values for security attributes and nobody is authorised to 2930 specify alternative default initial values. 2931

FMT_MSA.1/AC requires that a TSF shall enforce the Access Control SFP to restrict 2932 the ability to modify the TOE state. 2933

FMT_MSA.3/AC requires that the TSF shall enforce the Access Control SFP to 2934 provide restrictive default values for security attributes and only dedicated roles are 2935 authorised to specify alternative default initial values. 2936


TCG PUBLIC REVIEW

FMT_MSA.1/NVM requires that a TSF shall enforce the NVM SFP to restrict the 2937 ability to query and modify NV index attributes. 2938

FMT_MSA.3/NVM requires that the TSF shall enforce the NVM SFP to provide 2939 restrictive default values for NVM related security attributes and nobody is 2940 authorised to specify alternative default initial values. 2941

FMT_MSA.4/NVM requires that the TSF shall enforce rules for setting the security 2942 attributes of NVM. 2943

FMT_MTD.1/NVM requires that the TSF restricts the ability to change the 2944 authorisation secret for an NV index to a special role. 2945

FMT_MSA.1/ExIm requires that a TSF shall enforce the Data Export and Import SFP 2946 to restrict the ability to use the security attribute authorisation data for export and 2947 import related functions. 2948

FMT_MSA.3/ExIm requires that the TSF shall enforce the Data Export and Import 2949 SFP to provide restrictive default values for security attributes for export and import 2950 related functions. Nobody is authorised to specify alternative default initial values for 2951 those security attributes. 2952

FMT_MSA.1/Cre requires that a TSF shall enforce the Credential SFP to restrict the 2953 ability to modify the PCR related security attributes. 2954

FMT_MSA.3/Cre requires that the TSF shall enforce the Credential SFP to provide 2955 restrictive default values for security attributes for measurement and reporting 2956 related functions. Nobody is authorised to specify alternative default initial values for 2957 those security attributes. 2958

FMT_MSA.1/M&R requires that a TSF shall enforce the Measurement and Reporting 2959 SFP to restrict the ability to modify the PCR related security attributes. 2960

FMT_MSA.3/M&R requires that the TSF shall enforce the Measurement and 2961 Reporting SFP to provide restrictive default values for security attributes for 2962 measurement and reporting related functions. Nobody is authorised to specify 2963 alternative default initial values for those security attributes. 2964

FMT_MSA.1/Hier requires that a TSF shall enforce the TPM Object Hierarchy SFP to 2965 restrict the ability to modify the security attributes fixedTPM and fixedParent. 2966

FMT_MSA.3/Hier requires that the TSF shall enforce the TPM Object Hierarchy SFP 2967 to provide restrictive default values for security attributes for TPM hierarchy related 2968 operations. The creator of the TPM object is authorised to specify alternative default 2969 initial values for those security attributes. 2970

FMT_MSA.4/Hier requires that the TSF shall enforce rules for setting the security 2971 attributes of TPM object hierarchies. 2972

The security objective O.Security_Roles requires that the TOE maintains security relevant 2973

roles and associates users with those roles. The SFR FMT_SMR.1 defines a set of roles that 2974 the TSF shall maintain. Also, the association of users with these roles is required by this 2975 SFR. Further, FIA_USB.1 addresses the association between subjects and its security 2976 attributes. The SFR defines rules for initial association and changes of these associations. 2977

The security objective O.Self_Test requires the TOE to provide the ability to test itself and 2978 verify the integrity of the shielded data objects. Further, protected capabilities shall operate 2979 as designed and enter a secure state in case of detected errors. This is directly addressed by 2980 the SFRs FPT_TST.1, FPT_FLS.1/SD and FPT_FLS.1/FS: 2981


TCG PUBLIC REVIEW

FPT_TST.1 requires the TSF to run self tests under special conditions that are 2982 defined in the SFR. 2983

FPT_FLS.1/FS requires the TSF to preserve a secure state when failures occur. The 2984 types of failures are given in the SFR. 2985

FPT_FLS.1/SD requires the TSF to preserve a safe state by shutdown of the TOE in 2986 case of a detected physical attack or when the environmental conditions are out of 2987 spec. 2988

The security objective O.Single_Auth requires that the TOE provides a single user 2989 authentication mechanism. To prevent “replay” and “man-in-the-middle” attacks the TOE 2990 shall require re-authentication. This objective is addressed by the following SFRs: 2991

FIA_AFL.1/Lockout and FIA_AFL.1/Recover require the TSF to detect attacks to the 2992 authentication system by a number of ongoing unsuccessful authentication requests. 2993 On detection the TSF shall block that authentication method. 2994

FIA_UAU.6 requires the TSF to re-authenticate the user when multiple commands 2995 need to be executed in one authorisation session. 2996

The security objective O.Sessions requires that the TOE provides the confidentiality of the 2997 parameters of commands within an authorised session and the integrity of the audit log of 2998 commands. This objective is addressed by the following SFRs: 2999

FIA_UAU.5 requires the TSF to provide dedicated authentication mechanisms. 3000 Further, the TSF shall follow the given rules when authenticating any user’s identity. 3001 The given authentication mechanisms are used as basis for the establishment of the 3002 integrity and confidentiality protected communication channels. 3003

FDP_UCT.1/AC requires the TSF to enforce a policy to transmit user data in a 3004 confidential manner. 3005

FTP_ITC.1/AC requires that the TSF shall provide a communication channel between 3006 itself and the user of the TOE in a manner that protects the confidentiality and 3007 integrity of the transmitted data. This channel is used by authorisation sessions, 3008 audit sessions and encryption sessions of the TPM and used to transfer commands 3009 and responses between the TOE and the user of the TOE. 3010

FCS_COP.1/RSAED requires that the TSF provides the ability to perform asymmetric 3011 encryption and decryption of data. 3012

FCS_COP.1/SHA requires the TSF to be able to perform hash value calculations. 3013 This can be used to support data integrity protection. 3014



The security objective O.Tamper_Resistance requires the TOE to resist physical tampering 3019 of the TSF by hostile users. This security objective is directly addressed by the SFR 3020 FPT_PHP.3 which requires that the TSF resists physical manipulation and physical probing 3021 but also by the SFRs FDP_ITT.1 and FPT_ITT.1 that require the TSF to prevent the 3022 disclosure of user data when transmitted between physically separated parts of the TOE. 3023


TCG PUBLIC REVIEW

The security objective O.FieldUpgradeControl requires that the TOE restricts the Field 3024 Upgrade to the Platform firmware and accepts only authentic update data provided by the 3025 TOE vendor. This objective is addressed by the following SFRs: 3026

FMT_SMR.1 defines a set of roles that the TSF shall maintain. Also, the association 3027 of users with these roles is required by this SFR. 3028

FDP_ACC.2/States requires that the TSF enforces the TPM State Control SFP on all 3029 subjects, objects and operations among subjects and objects covered by the SFP. The 3030 operations shall be covered by an access control SFP. 3031

FDP_ACF.1/States defines rules to enforce a policy regarding the TOE states, 3032 transitions between states and required authorisations to change the state of the 3033 TOE. This includes the state transition regarding the FUM state and the rules for the 3034 required authorisations. 3035

FMT_MSA.1/States requires that a TSF shall enforce a SFP to restrict the ability to 3036

modify the TOE state. 3037

FMT_MSA.3/States requires that the TSF shall enforce a SFP to provide restrictive 3038 default values for security attributes and nobody is authorised to specify alternative 3039 default initial values. 3040

FDP_UIT.1/States requires that the TSF shall enforce the TPM State Control SFP to 3041 provide and use integrity protection capabilities for firmware update data on 3042 reception of that data. 3043

FIA_UAU.5: requires the TSF to provide dedicated authentication mechanisms. 3044 Further, the TSF shall follow the given rules when authenticating any user’s identity. 3045

7.3.2 Dependency Rationale 3046

The dependency rationale demonstrates that the dependencies of the SFR are fulfilled or 3047 provides an explanation in case that dependencies are not fulfilled. 3048

Table 12: SFR Dependency rationale 3049

SFR Dependency Rationale/ fulfilled by

FMT_SMR.1 FIA_UID.1 Timing of identification Fulfilled by FIA_AFL.1/PINPASS Authentication failure handling

Hierarchical t

o:

No oth


TCG PUBLIC REVIEW


er components

. Dependencies: FIA_UAU.1 Timing of authentication.

FIA_AFL.1.1/PINPASS The TSF shall detect when pinCount successful authentication events exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_PASS.


Wh

en the defined number of successful authentication events has been


TCG PUBLIC REVIEW


met, the TSF shall block further authorization attempts.


Hierarchical to:



FIA_AFL.1.1/PINFAIL The TSF shall detect when


TCG PUBLIC REVIEW


pinCount unsuccessful authentication attempts exceeds pinLimit for an NV Index with the attribute TPM_NT_

PIN_FAIL. FIA_AFL.1.2/ PINFAIL

When the defined number of unsuccessful authentication attempts has been met, the TSF shall block further authorization attempts.

FIA_UID.1

FMT_SMF.1 No dependencies n. a.

FMT_MSA.2 [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.1 Management of security attributes

FMT_SMR.1 Security roles

Fulfilled by FDP_ACC.1/AC, FMT_MSA.1/AC, FMT_SMR.1

FMT_MSA.4/AUTH [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

Fulfilled by FDP_ACC.1/Hier,

FCS_RNG.1 No dependencies n. a.

FPT_STM.1 No dependencies n. a.

FIA_SOS.2 No dependencies n. a.

FMT_MTD.1/AUTH FMT_SMR.1 Security roles Fulfilled by


TCG PUBLIC REVIEW


FMT_SMF.1 Specification of Management Functions

FMT_SMR.1, FMT_SMF.1

FIA_AFL.1/Lockout FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1

FIA_AFL.1/Recover FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1


Hierarchical t

o:



FIA_AFL.1.1/PINPASS The TSF shall detect when pinCount successful authentication events

No dependencies n. a.


TCG PUBLIC REVIEW


exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_PASS.


When the defined number of successful authentication events has been met, the TSF shall block further authorization attempts.


Hierarchical to:

No o

ther comp


TCG PUBLIC REVIEW


onents.


FIA_AFL.1.1/PINFAIL The TSF shall detect when pinCount unsuccessful authentication attempts exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_FAIL.


When the defined number of unsuccessful authentication attempts

has been met, the TSF shall block further authorization attempts.


TCG PUBLIC REVIEW


FIA_UID.1

FIA_UAU.1 FIA_UID.1 Timing of identification Fulfilled by FIA_AFL.1/PINPASS Authentication failure handling

Hierarchical to:



FIA_AFL.1.1/PINPASS The TSF shall

detect when pinCount successful authentication events


TCG PUBLIC REVIEW


exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_PASS.




Hierarchical to:

N

o other c


TCG PUBLIC REVIEW


omponents.

Dependencies: FIA_UAU.1 Timing

of authentication.

FIA_AFL.1.1/PINFAIL The TSF shall detect when pinCount unsuccessful authentication attempts exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_FAIL.


When the defined number of unsuccessful

authentication attempts has been met, the TSF shall block further authorizat


TCG PUBLIC REVIEW


ion attempts.

FIA_UID.1

FIA_UAU.5 No dependencies n. a.

FIA_UAU.6 No dependencies n. a.

FIA_USB.1 FIA_ATD.1 User attribute definition Because the TOE does not identify or manage individual users, the SFR FIA_ATD.1 is not applicable here.

FDP_ACC.2/States FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/States

FDP_ACF.1/States FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.2/States, FMT_MSA.3/States

FMT_MSA.1/States [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACC.2/States, FMT_SMR.1, FMT_SMF.1

FMT_MSA.3/States FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/States, FMT_SMR.1

FDP_UIT.1/States [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]

Fulfilled by FDP_ACC.2/States, see rationale (1) below this table

FPT_TST.1 No dependencies n. a.

FDP_ACC.1/AC FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/AC

FDP_ACF.1/AC FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/AC, FMT_MSA.3/AC

FMT_MSA.1/AC [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACC.1/AC, FMT_SMR.1, FMT_SMF.1

FMT_MSA.3/AC FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/AC, FMT_SMR.1

FDP_UCT.1/AC [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]

Fulfilled by FTP_ITC.1/AC,


TCG PUBLIC REVIEW


[FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

FDP_ACC.1/AC

FTP_ITC.1/AC No dependencies n. a.

FMT_MOF.1/AC FMT_SMR.1 Security roles, FMT_SMF.1 Specification of Management Functions

Fulfilled by FMT_SMR.1, FMT_SMF.1

FCS_CKM.1/PK [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_COP.1/AES FCS_COP.1/RSAED, FCS_COP.1/RSASign FCS_CKM.4

FCS_CKM.1/RSA [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_COP.1/RSAED, FCS_COP.1/RSASign FCS_CKM.4

FCS_CKM.1/ECC [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_COP.1/ECDEC, FCS_COP.1/ECDSA, FCS_COP.1/ECDAA FCS_CKM.4

FCS_CKM.1/SYMM [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_COP.1/AES FCS_CKM.4

FCS_CKM.4 [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]

Fulfilled by FCS_CKM.1/PK

FCS_COP.1/RSAED [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_CKM.1/PK, FCS_CKM.1/RSA, FCS_CKM.4

FCS_COP.1/SHA [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

because hash functions do not use any keys, the dependencies regarding key generation/destruction are not applicable here

FCS_COP.1/HMAC [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]

Fulfilled by FCS_CKM.1/PK, FCS_CKM.1/SYMM, FCS_CKM.4


TCG PUBLIC REVIEW


FCS_CKM.4 Cryptographic key destruction

FCS_COP.1/RSASign [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_CKM.1/PK, FCS_CKM.1/RSA FCS_CKM.4

FCS_COP.1/ECDSA [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_CKM.1/ECC, FCS_CKM.4

FCS_COP.1/ECDAA [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_CKM.1/ECC, FCS_CKM.4

FCS_COP.1/AES [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_CKM.1/PK, FCS_CKM.1/SYMM, FCS_CKM.4

FCS_COP.1/ECDEC [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by FCS_CKM.1/PK, FCS_CKM.1/ECC FCS_CKM.4

FDP_ACC.1/NVM FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/NVM

FDP_ACF.1/NVM FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/NVM, FMT_MSA.3/NVM

FMT_MSA.1/NVM [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACC.1/NVM, FMT_SMR.1,

FMT_SMF.1

FMT_MSA.3/NVM FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/NVM, FMT_SMR.1

FMT_MSA.4/NVM [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow

Fulfilled by FDP_ACC.1/NVM


TCG PUBLIC REVIEW


control]

FMT_MTD.1/NVM FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FMT_SMR.1, FMT_SMF.1

FDP_ITC.1/NVM [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/NVM, FMT_MSA.3/NVM

FDP_ETC.1/NVM [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

Fulfilled by FDP_ACC.1/NVM

FDP_ACC.1/ExIm FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/ExIm

FDP_ACF.1/ExIm FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/ExIm, FMT_MSA.3/ExIm

FMT_MSA.1/ExIm [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACC.1/ExIm, FMT_SMR.1, FMT_SMF.1

FMT_MSA.3/ExIm FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/ExIm, FMT_SMR.1

FDP_ETC.2/ExIm [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

Fulfilled by FDP_ACC.1/ExIm

FDP_ITC.2/ExIm [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FPT_TDC.1 Inter-TSF basic TSF data consistency

Fulfilled by FDP_ACC.1/ExIm, see rationale (2) and (3) below this table

FDP_UCT.1/ExIm [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow

control]

Fulfilled by FDP_ACC.1/ExIm, see rationale (3) below this table

FDP_UIT.1/ExIm [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]

Fulfilled by FDP_ACC.1/ExIm, see rationale (3) below this table

FDP_ACC.1/Cre FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/Cre


TCG PUBLIC REVIEW


FDP_ACF.1/Cre FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/Cre, FMT_MSA.3/Cre

FMT_MSA.3/Cre FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/Cre, FMT_SMR.1

FMT_MSA.1/Cre [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACC.1/Cre, FMT_SMR.1, FMT_SMF.1

FCO_NRO.1/Cre FIA_UID.1 Timing of identification Fulfilled by


Hierarchical to:




TCG PUBLIC REVIEW





FIA_AFL.1/PINFAIL Authentication failure

handling

Hierarchical to:


TCG PUBLIC REVIEW


No other com

ponents.


FIA_AFL.1.1/PINFAIL The TSF shall detect when pinCount unsuccessful authentication attempts exceeds pinLimit for an NV Index

with the attribute TPM_NT_PIN_FAIL.


When the defined number of


TCG PUBLIC REVIEW


unsuccessful authentication attempts has been met, the TSF shall block further authorization attempts.

FIA_UID.1

FDP_ACC.1/M&R FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/M&R

FDP_ACF.1/M&R FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/M&R, FMT_MSA.3/M&R

FMT_MSA.1/M&R [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACF.1/M&R, FMT_SMR.1, FMT_SMF.1

FMT_MSA.3/M&R FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/M&R, FMT_SMR.1

FCO_NRO.1/M&R FIA_UID.1 Timing of identification Fulfilled by FIA_AFL.1/PINPASS Authentication failure handling

Hierarchical to:

No othe


TCG PUBLIC REVIEW


r components.




When the

defined number of successful authentication events has been met, the


TCG PUBLIC REVIEW


TSF shall block further authorization attempts.


Hierarchical to:


Dependencies:

FIA_UAU.1 Timing of authentication.

FIA_AFL.1.1/PINFAIL The TSF shall detect when pinCount


TCG PUBLIC REVIEW


unsuccessful authentication attempts exceeds pinLimit for an NV Index with the attribute TPM_NT_PIN_FAIL.


When the defined number of unsuccessful authentication attempts has been met, the TSF shall block further authorization attempts.

FIA_UID.1

FDP_RIP.1 No dependencies n. a.

FPT_FLS.1/FS No dependencies n. a.

FPT_FLS.1/SD No dependencies n. a.

FPT_PHP.3 No dependencies n. a.

FDP_ITT.1 [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow

control]

Fulfilled by FDP_ACC.1/AC,

FDP_ACC.1/Hier, FDP_ACC.1/NVM, FDP_ACC.1/ExIm, FMT_MSA.1/Cre, FDP_ACC.1/M&R, FDP_ACC.2/States

FPT_ITT.1 [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

Fulfilled by FDP_ACC.1/AC, FDP_ACC.1/Hier,


TCG PUBLIC REVIEW


FDP_ACC.1/NVM, FDP_ACC.1/ExIm, FMT_MSA.1/Cre, FDP_ACC.1/M&R, FDP_ACC.2/States

FDP_SDI.1 No dependencies n. a.

FDP_ACC.1/Hier FDP_ACF.1 Security attribute based access control

Fulfilled by FDP_ACF.1/Hier

FDP_ACF.1/Hier FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

Fulfilled by FDP_ACC.1/Hier, FMT_MSA.3/Hier

FMT_MSA.1/Hier [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Fulfilled by FDP_ACC.1/Hier, FMT_SMR.1, FMT_SMF.1

FMT_MSA.3/Hier FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

Fulfilled by FMT_MSA.1/Hier, FMT_SMR.1

FMT_MSA.4/Hier [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

Fulfilled by FDP_ACC.1/Hier,

Rationales for dependencies that are not fulfilled: 3050

(1) The firmware update procedure as kind of user data import is realised based on 3051 commands that transfer single data packets into the TOE. No secure channel will be 3052 established and used for that process, the protection of the user data is done based on 3053 checks of each single packet. Hence the SFRs regarding trusted channel and trusted 3054 path are not applicable. 3055

(2) The SFR FDP_ITC.2/ExIm addresses export and import of user data with security 3056 attributes. The data consistency is ensured because the other trusted IT product is 3057 always a system that is equivalent to the TOE. Especially the same TPM or another TPM 3058 may be used for import of exported data. Hence the SFR FPT_TDC.1 is not applicable. 3059

(3) The exported and imported user data is based on data objects and not channel-based. 3060 The security attributes are part of the exported object and the object is integrity and 3061 confidentiality protected. Hence the SFRs regarding trusted channel and trusted path 3062 are not applicable. 3063

7.3.3 Assurance Rationale 3064

This protection profile requires the TOE to be evaluated on Evaluation Assurance Level 4 3065 (EAL4) as defined in CC [3] and augmented with ALC_FLR.1 and AVA_VAN.4 listed in table 3066 10. 3067

EAL4 was selected because the objective of the TOE is to provide developers or users with a 3068 moderate to high level of independently assured security in conventional commodity TOEs 3069 and assumes that developers or users are prepared to incur additional security-specific 3070


TCG PUBLIC REVIEW

engineering costs. EAL4 permits a developer to gain maximum assurance from positive 3071 security engineering based on good commercial development practices which, though 3072 rigorous, do not require substantial specialist knowledge, skills, and other resources. 3073

The developer and manufacturer ensure that the TOE is designed and fabricated so that the 3074 TSF achieves the desired properties and it requires a combination of equipment, knowledge, 3075 skill, and time to be able to derive design information or affect the development and 3076 manufacturing process which could be used to compromise security through attack. This is 3077 addressed by the SAR of the class ALC especially by the component ALC_DVS.1. 3078

Further the AVA_VAN.4 requires the developer and the manufacturer to provide necessary 3079 evaluation evidence that the TOE fulfills its security objectives and is resistant to attack 3080 with Moderate potential. The component AVA_VAN.4 will analyze and assess the resistance 3081 of the TOE to attacks with Moderate attack potential. 3082

EAL4 is also augmented with ALC_FLR.1 to track and correct the reported and found 3083

security flaws in the product. 3084

The component AVA_VAN.4 Methodical vulnerability analysis has the following 3085 dependencies: 3086

ADV_ARC.1 Security architecture description 3087 ADV_FSP.2 Security-enforcing functional specification 3088 ADV_TDS.3 Basic modular design 3089 ADV_IMP.1 Implementation representation of the TSF 3090 AGD_OPE.1 Operational user guidance 3091 AGD_PRE.1 Preparative procedures 3092

All these components are contained in the EAL4 package. The component ALC_FLR.1 Basic 3093 flow remediation has no dependencies. Therefore all these dependencies are satisfied by 3094 EAL4. 3095

3096


TCG PUBLIC REVIEW

8. Appendix 3097

8.1 Random Number Generator (informative) 3098

The internal RNG shall comply with the NIST Special Publication 800-90A [18]. Hence, its 3099 primary nature is that of a deterministic random bit generator (DRBG). According to [18] 3100 the entropy is taken from a seed given as input to the DRBG mechanism. The DRBG can be 3101 reseeded in order to add new entropy to the internal state. 3102

In the TPM architecture specification [7], the RNG architecture is given in section 11.4.10. 3103 As shown in figure 4 of [7], the RNG contains (at least) one entropy source in order to seed 3104 or reseed the DRBG. The entropy should be collected in a state register of the RNG that is 3105 not visible to an outside process or other TPM capability. Using the command 3106 TPM2_StirRandom, additional data can be injected into the status registers, but the 3107 security of the DRBG itself does not rely on the secrecy of this information. 3108

In order to meet the certification requirements of the intended market, the quality metric of 3109 the RNG depends on the quality of the entropy source and the seed period: If the seeding 3110 takes place only on initialisation time, the resulting RNG is a pure deterministic RNG. On 3111 the other hand, if the reseeding mechanism ensures that the entropy inserted into the RNG 3112 always exceeds the amount of entropy that is taken as output from the RNG, the RNG can 3113 be seen as physical RNG. Also, the reseeding could be implemented on a periodic base. In 3114 that case the amount of output data taken from the RNG may be bigger than the amount of 3115 entropy that was injected by reseeding. In that case the character of the RNG is hybrid. In 3116 summary, the character of the RNG can be determined by choosing the seed period: An 3117 infinite seed period creates a deterministic RNG while a very short seed period creates a 3118 physical RNG. 3119 Regarding the quality of the entropy source, the NIST DRAFT Special Publication 800-90B 3120 [19] can be taken into consideration. It also contains testing strategies to determine the 3121 entropy provided by the entropy source. 3122

8.2 Acronyms 3123

For the purposes of this document, the acronyms given in CC Parts 2 and 3 and the 3124 following apply. 3125

Acronym Description

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

AuthData Authentication Data or Authorisation Data, depending on the context

CA Certificate Authority

CFB Cipher Feedback mode

CRTM Core Root of Trust for Measurement

CTR Counter-mode encryption

DA Dictionary Attack

DAA Direct Autonomous Attestation

DRBG Deterministic Random Bit Generator

EAL evaluated assurance level


TCG PUBLIC REVIEW

Acronym Description

ECB Electronic Codebook

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

HMAC Hash Message Authentication Code

HW Hardware Interface

I/O Input/Output

IV Initialisation Vector

KDF key derivation function

MMIO Memory Mapped I/O

NIST National Institute of Standards and Technology

NV Non-volatile

NVM Non-Volatile Memory

OAEP Optimal Asymmetric Encryption Padding

PCR platform configuration register(s)

PK Primary Key

PP Physical Presence, Protection Profile

PPO Platform Primary Object

PPS Platform Primary Seed

PRIVEK Private Endorsement Key

PRNG Pseudo Random Number Generator

PUBEK Public Endorsement Key

RNG Random Number Generator

RSA Algorithm for public-key cryptography. The letters R, S, and A represent the initials of the first public describers of the algorithm Rivest, Shamir and Adleman.

RTM Root of Trust for Measurement

RTR Root of Trust for Reporting

RTS Root of Trust for Storage

SHA Secure Hash Algorithm

SPS Storage Primary Seed

SRK Storage Root Key

TCB trusted computing base

TCG Trusted Computing Group

TOE Target of Evaluation

TPM Trusted Platform Module

TPM2_ Prefix for a command defined in the TPM2 Library specification


TCG PUBLIC REVIEW

Acronym Description

UTC Universal Time Clock

8.3 Normative references 3126

The following referenced documents are indispensable for the application of this document. 3127 For dated references, only the edition cited applies. For undated references, the latest 3128 edition of the referenced document (including any amendments) applies. 3129

[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction 3130 and General Model; Version 3.1, Revision 5, CCMB-2017-04-001, April 2017 3131

[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security 3132 Functional Requirements; Version 3.1, Revision 5, CCMB-2017-04-002, April 2017 3133

[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security 3134 Assurance Requirements; Version 3.1, Revision 5, CCMB-2017-04-003, April 2017 3135

[4] Common Methodology for Information Technology Security Evaluation Methodology, 3136 Evaluation Methodology, Version 3.1, Revision 5, CCMB-2017-04-004, April 2017 3137

[5] Common Criteria Recognition Arrangement Management Committee, Policies and 3138 Procedures, Supporting Documents for Smartcards and similar devices, document 3139 number 2006-06-001 3140

[6] Supporting Document Guidance Smartcard Evaluation, February 2010, Version 2.0, 3141 CCDB-2010-03-001 3142

[7] TPM Library Part 1: Architecture, Specification Version 2.0, Revision 1.38, September 3143 2016, Trusted Computing Group, Incorporated 3144

[8] TPM Library Part 2: TPM Structures, Specification Version 2.0, Revision 1.38, September 3145 2016, Trusted Computing Group, Incorporated 3146

[9] TPM Library Part 3: Commands, Specification Version 2.0, Revision 1.38, September 3147 2016, Trusted Computing Group, Incorporated 3148

[10] TPM Library Part 4: Supporting Routines, Specification Version 2.0, Revision 1.38, 3149 September 2016, Trusted Computing Group, Incorporated 3150

[11] TCG PC Client Specific Platform TPM Profile for TPM 2.0 (PTP), Family “2.0”, Level 00 3151 Revision01.03 August 2017, 3152

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

[13] FIPS-140-2, Federal Information Processing Standard 140-2 3156

[14] FIPS-180-4, Federal Information Processing Standard 180-4 Secure Hash Standard 3157 (SHS) 3158

[15] FIPS PUB 186-4 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION 3159 Digital Signature Standard (DSS) 3160

[16] FIPS 198-1 Federal Information Processing Standards Publication, The Keyed-Hash 3161 Message Authentication Code (HMAC), July 2008 3162

[17] FIPS-197, Federal Information Processing Standard 197 3163


TCG PUBLIC REVIEW

[18] NIST Special Publication 800-90A: Recommendation for Random Number Generation 3164 Using Deterministic Random Bit Generators. January 2012 3165

[19] NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources 3166 Used for Random Bit Generation. August 2012 3167

[20] NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment 3168 Schemes Using Discrete Logarithm Cryptology. March 2007 3169

[21] NIST Special Publication 800-107: Recommendation for Applications Using Approved 3170 Hash Algorithms. August 2012 3171

[22] NIST Special Publication 800-108: Recommendation for Key Derivation Using 3172 Pseudorandom Functions. October 2009 3173

[23] NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of 3174 Operation. December 2001 3175

[24] IETF RFC 2104, Internet Engineering Task Force Request for Comments 2104: 3176 HMAC: Keyed-Hashing for Message Authentication 3177

[25] IETF RFC 2119, Internet Engineering Task Force Request for Comments 2119: Key 3178 words for use in RFCs to Indicate Requirement Levels 3179

[26] IETF RFC 3447, PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 3180 14, 2002 3181

[27] ISO/IEC 9797-2, Information technology -- Security techniques -- Message 3182 Authentication Codes (MACs) -- Part 2: Mechanisms using a dedicated hash-function 3183

[28] ISO/IEC 10116:2006, Information technology — Security techniques — Modes of 3184 operation for an n-bit block cipher 3185

[29] ISO/IEC 10118-3, Information technology — Security techniques — Hash-functions — 3186 Part 3: Dedicated hash function 3187

[30] ISO/IEC 14888-3, Information technology -- Security techniques -- Digital signature 3188 with appendix -- Part 3: Discrete logarithm based mechanisms 3189

[31] ISO/IEC 15946-1, Information technology — Security techniques — Cryptographic 3190 techniques based on elliptic curves — Part 1: General 3191

[32] ISO/IEC 18033-3, Information technology — Security techniques — Encryption 3192 algorithms — Part 3: Block ciphers 3193

3194

3195

3196

Protection Profile PC Client Specific TPM...Add leakage protection to O.Tamper_Resistance Add...

Documents

Transcript of Protection Profile PC Client Specific TPM...Add leakage protection to O.Tamper_Resistance Add...