Page 1 of 55 Public STMICROELECTRONICS COMMON CRITERIA FOR IT SECURITY EVALUATION ST33TPMF2ESPI SECURITY TARGET - PUBLIC VERSION Page 2 of 55 Public DOCUMENT REVISION Version Date Author Modifications 01-00 30/04/2015 Olivier Collart First release 01-01 09/10/2015 Olivier Collart Evaluator comments update 01-01p 16/10/2015 Olivier Collart Public release Page 3 of 55 Public Table of Contents 1 INTRODUCTION.................................................................................................................................. 5 1.1 ST REFERENCE .............................................................................................................................. 5 1.2 PURPOSE ....................................................................................................................................... 5 1.3 CONTEXT ....................................................................................................................................... 5 2 TOE DESCRIPTION............................................................................................................................. 6 2.1 TOE REFERENCE............................................................................................................................ 6 2.2 TOE OVERVIEW ............................................................................................................................. 6 2.2.1 TOE Definition ...................................................................................................................... 6 2.2.2 TOE Major Security features ................................................................................................ 6 2.3 TOE DESCRIPTION ....................................................................................................................... 10 2.3.1 TOE hardware description.................................................................................................. 10 2.3.2 TOE Firmware description.................................................................................................. 12 2.4 TOE GUIDANCE DOCUMENTATION.................................................................................................. 13 2.5 TOE LIFECYCLE............................................................................................................................ 13 3 CONFORMANCE CLAIM .................................................................................................................. 14 3.1 CC CONFORMANCE CLAIM ............................................................................................................ 14 3.2 PP CLAIM..................................................................................................................................... 14 3.3 PACKAGE CLAIM............................................................................................................................ 14 3.4 CONFORMANCE RATIONALE........................................................................................................... 14 3.5 APPLICATION NOTE ....................................................................................................................... 14 4 SECURITY PROBLEM DEFINITION................................................................................................. 15 4.1 THREATS...................................................................................................................................... 15 4.2 ORGANIZATIONAL SECURITY POLICIES ........................................................................................... 15 4.3 TOE OPERATIONAL ENVIRONMENT ASSUMPTIONS .......................................................................... 15 5 SECURITY OBJECTIVES.................................................................................................................. 16 5.1 SECURITY OBJECTIVES FOR THE TOE............................................................................................ 16 5.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ........................................................ 16 5.3 SECURITY OBJECTIVES RATIONALE ................................................................................................ 17 6 EXTENDED COMPONENT DEFINITION.......................................................................................... 19 7 SECURITY REQUIREMENTS ........................................................................................................... 20 7.1 SECURITY FUNCTIONAL REQUIREMENTS FOR THE TOE .................................................................. 20 7.1.1 Security Functional Requirements listed by the TPM1.2 Protection Profile....................... 20 7.1.2 Security Functional Requirements related to TPM Field Upgrade SFP............................. 36 7.2 SECURITY ASSURANCE REQUIREMENTS......................................................................................... 39 7.3 SECURITY REQUIREMENTS RATIONALE........................................................................................... 40 7.3.1 Rationale for the Security Functional Requirements.......................................................... 40 7.3.2 SFR Dependency Rationale............................................................................................... 41 8 TOE SUMMARY SPECIFICATIONS ................................................................................................. 42 8.1 TOE SECURITY FEATURES ............................................................................................................ 42 8.1.1 SF_CRY: Cryptographic support........................................................................................ 42 8.1.2 SF_I&A: Authentication and Identification .......................................................................... 43 8.1.3 SF_ACC: Access control .................................................................................................... 45 8.1.4 SR_GEN: General .............................................................................................................. 47 8.1.5 SF_PNB: Protection and non-bypassability ....................................................................... 48 8.1.6 SF_TST: Test ..................................................................................................................... 48 8.1.7 Security Functional Requirements coverage by security features ..................................... 49 APPENDIX A ABBREVIATIONS.......................................................................................................... 52 A.1 ABBREVIATIONS ............................................................................................................................ 52 APPENDIX B REFERENCED DOCUMENTS....................................................................................... 53 Page 4 of 55 Public List of Tables TABLE 1: TARGET OF EVALUATION: CHIP REFERENCE........................................................................................ 6 TABLE 2: TARGET OF EVALUATION: FIRMWARE IMAGE REFERENCE..................................................................... 6 TABLE 3: ORGANIZATIONAL SECURITY POLICIES FOR THE TOE........................................................................ 15 TABLE 4: SECURITY OBJECTIVES FOR THE TOE.............................................................................................. 16 TABLE 5: SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .......................................................... 16 TABLE 8: ASSURANCE COMPONENTS............................................................................................................. 39 TABLE 9: SECURITY REQUIREMENTS RATIONALE ............................................................................................. 40 TABLE 10: SFR DEPENDENCY RATIONALE...................................................................................................... 41 TABLE 11: SUMMARY TABLE OF SFR COVERAGE BY SECURITY FEATURES........................................................ 49 TABLE 12: ABBREVIATIONS............................................................................................................................ 52 List of Figures FIGURE 1: ST33HTPM BLOCK DIAGRAM........................................................................................................ 10 FIGURE 2: TPM2E FIRMWARE BLOCK DIAGRAM.............................................................................................. 12 Page 5 of 55 Public 1 INTRODUCTION 1.1 ST Reference This security target is referenced with the following information • Filename: ST33TPMF2ESPI_ST (01.01p) • Revision: 01.01p, • Internal documentation system reference: SSS_ST33TPMF2ESPI_ST_15_001 • Date: 16 th of October 2015 This security target is strictly conformant to the TPM Protection Profile [TPM1.2 PP rev116]. 1.2 Purpose This document presents the Security Target (ST) of the ST33TPMF2ESPI product. The reference and definition of the TOE are provided in Chapter 2. A list of abbreviation definition is provided in Appendix A 1.3 Context The original text from the protection profile [TPM1.2 PP rev116] is indicated with a light grey font. Page 6 of 55 Public 2 TOE DESCRIPTION 2.1 TOE reference This security target covers two targets of evaluation: Table 1: Target of evaluation: chip reference TOE Hardware Version (Ext/Int) Firmware Version (TPM 1.2 major.minor) Product ordering information Printed Marking TOE 1 A/C 0x01.0x02.0x46.0x00 ST33HTPM2ExxAAD8 P68MAAD8 Table 2: Target of evaluation: firmware image reference TOE Firmware Version (TPM 1.2.major.minor) Supported chip for firmware image download TOE 2 0x01.0x02.0x46.0x08 ST33HTPM2ExxAAD8 The package information is defined by the “xx” field in the product ordering information. The package is not part of the TOE. It is only possible to load a firmware with a minor version strictly higher than the minor version of the current firmware. 2.2 TOE Overview 2.2.1 TOE Definition The TOE is the TCG PC Client Specific Trusted Platform Module (PCCS TPM). This TPM is hardware, firmware and/or software that implements the functions defined in the TCG Trusted Platform Module Main Specification, version 1.2, [5] [6] [7] and the PC client specific interface specification [8]. The TCG Trusted Platform Module Specification describes the design principles [5], the TPM structures [6] and the TPM commands [7]. The PC Client Interface Specification [8] describes the platform-specific set of requirements of the TPM for the PC Client, the details of what interfaces and protocols are used to communicate with the TPM and specific items like the minimum number of PCRs required and NV Storage available. The primitives provided by the TOE include cryptographic algorithms for key generation, digital signatures, random number generation, sealing data to system state, protected storage, binding information to the TPM, support of direct anonymous attestation and physical protection. Attestation by the TOE is an operation that provides proof of data known to the TPM. This is done by digitally signing specific internal TPM data using an Attestation Identity Key (AIK). The acceptance and validity of both the integrity measurements and the AIK itself are determined by the Verifier. The AIK is obtained using either the Privacy Certification Authority or the Direct Anonymous Attestation (DAA) protocol. The DAA is a protocol for vouching for an AIK using zero-knowledge-proof technology. 2.2.2 TOE Major Security features The PCCS TPM provides all services required for a TPM in the TCG Trusted Platform Module Main Specification, version 1.2, [5] [6] [7] and additional services that are optional in the main TPM specification but mandatory in the PC client specific interface specification [8]. The PCCS TPM provides physical protection for internal user data and TSF data. Page 7 of 55 Public In TCG systems roots of trust are components that must be trusted because misbehavior might not be detected. There are commonly three Roots of Trust in a trusted platform; a root of trust for measurement (RTM), root of trust for storage (RTS) and root of trust for reporting (RTR). The RTM is a computing engine capable of making inherently reliable integrity measurements. Typically the normal platform computing engine is controlled by the core root of trust for measurement (CRTM). The CRTM is the instructions executed by the platform when it acts as the RTM. The RTM is also the root of the chain of transitive trust. The RTS is a computing engine capable of maintaining an accurate summary of values of integrity digests and the sequence of digests. The RTR is a computing engine capable of reliably reporting information held by the RTS. The TCG Specification Architecture Overview [11] provides a more detailed description. Support for the Root of Trust for Measurement The TPM supports the integrity measurement of the trusted platform by calculation and reporting of measurement digests of measured values. The measurement values are representations of embedded data or program code scanned and provided to the TPM by the measurement agent, such as the Root-of-Trust-for-Measurement. The TPM supports cryptographic hashing of measured values and calculates the measurement digest by extending the value of a Platform Configuration Register (PCR) with a calculated or provided hash value by means of the SHA-1. The PCRs are shielded locations of the TPM which can be reset by TPM reset or a trusted process, written only through measurement digest extensions and read. Root of Trust for Reporting The root of trust for reporting (RTR) exposes the measurement digests stored in the PCRs and attests to the authenticity of these measurement digests based on trusted platform identities or the Direct Anonymous Attestation Protocol. The trusted platform identities for RTR are defined by Attestation Identity Credentials for Attestation Identity Keys (AIK) generated by the TPM. The TPM creates digital signatures over the PCR values using an Attestation Identity Key. Each TPM is identified and validated using its Endorsement Key. A TPM has only one endorsement key pair. The Endorsement Key is transitively bound to the Platform via the TPM as follows: • An Endorsement Key is bound to one and only one TPM (i.e., there is a one to one correspondence between an Endorsement Key and a TPM.) • A TPM is bound to one and only one Platform, (i.e., there is a one to one correspondence between a TPM and a Platform.) • Therefore, an Endorsement Key is bound to a Platform, (i.e., there is a one to one correspondence between an Endorsement Key and a Platform. The Endorsement Key is used in the process of issuance the Attestation Identity Credentials and to establish a platform owner. Root of Trust for Storage The TPM may be used to provide secure storage for an unlimited number of private keys or other data by means of encryption. The resulting encrypted file, which contains header information in addition to the data or key, is called a BLOB (Binary Large Object) and is output by the TPM and can be loaded in the TPM when needed. The functionality of the TPM can also be used so that private keys generated on the TPM can be stored outside the TPM (encrypted) in a way that allows the TPM to use them later without ever exposing such keys in the clear outside the TPM. The TPM uses RSA key technology to encrypt data and keys and may implement cryptographic algorithms of equivalent strength. The functionality used to provide secure storage is: Page 8 of 55 Public • TPM_Seal and TPM_Unseal, which perform RSA encrypt and decrypt, respectively, on data that is externally generated. The sealing operation encrypts not only the data, but also the values of the selected PCRs and the locality that must exist during for unseal and tpmProof, which is a unique secret identifier for the TPM sealing the data. To unseal the data, three conditions must exist: (i) the appropriate key must be available for unseal, (ii) the TPM PCRs must contain the values defined at the time of the seal operation, and (iii) the value of tpmProof must be the same as that encrypted during the seal operation. By requiring the PCR values to be duplicated at unseal and the tpmProof value to be checked, the seal operation allows software to explicitly state the future “trusted” configuration that the platform must be in for the decrypted key to be used and for decryption to only occur on the specified TPM. • TPM_Unbind, which RSA decrypts a blob created outside the TPM that has been encrypted using a public key where the associated private key is stored in the TPM. The key types used for the Root for Trust of Storage include: • The Storage Root Key (SRK), which is the root key of a hierarchy of keys associated with a TPM; it is generated within a TPM and is a non-migratable key. Each owned TPM contains a SRK, generated by the TPM at the request of the Owner. Under that SRK may be organized different trees dealing with migratable data or non-migratable data. • Storage keys, which are used to RSA encrypt and RSA decrypt other keys and sealed data with their security attributes in the Protected Storage hierarchy, only. • Binding Keys, which are used for TPM_Unbind operations only. A binding operation (performed outside the TPM) associates identification and authentication data with a particular data set and the entire data blob is encrypted outside the TPM using a binding key, which is an RSA key. The TPM_Unbind operation uses a private key stored in the TPM to decrypt the blob so that the data (often a key pair) stored in the blob may be used. Other security services and features The TPM provides cryptographic services hashing of arbitrary data by means of the hash function SHA-1 and creation of digital signatures with signing keys which must be a leaf of the Storage Root Key hierarchy. The private key of a singing key pair is used for signing operations only. The TPM provides non-volatile storage as a shielded location for data of external entities. The TPM owner controls access to the non-volatile storage. The access control may include the need for authentication of the user, delegations, PCR values and other controls. Keys managed by the TPM may be non-migratable, migratable or certifiable migratable. A non- migratable key is a key that cannot be transported outside beyond a specific TPM. A migratable key is a key that may be transported outside the specific TPM. In addition some keys must be bound to a specific TPM but should be able to be backed-up or migrated under certain circumstances. The certified migration allows a Migration Selection Authority therefore to control a migration process without handling the migrated key itself or respectively uses a Migration Authority to control the migration process without the knowledge of the data or the migrated key. Those keys which are intended for certified migration are called certifiable migratable keys The TPM provides a “tick counter” as a count of the number of ticks that have occurred since the start of a timing session. The time between the ticks is identified via a “tick rate” but it is the responsibility of the caller to associate the ticks to an actual UTC time. Page 9 of 55 Public The TPM provides also a monotonic counter as an ever-increasing incremental value for external use. Generation and import of the Endorsement key pair and certificate The Endorsement Key (EK) pair and associated EK certificate (EK credential) are stored in the TPM during the manufacturing process at the TOE lifecycle phase “Manufacturing”. The Endorsement key pair is generated by a HSM (Hardware Security Module) and then stored encrypted with a 2-DES transport key on a key server. The Endorsement Key certificate is generated also by a HSM that stores the STMicroelectronics intermediate CA (Certification Authority) keys. The certificates are stored on a certificate server. CA keys are stored outside the HSM in backup encrypted with a 3- DES key. This backup key is generated under dual control by 3 different security officers; The importation of the EK and EK certificate in the TOE is done by the personalization infrastructure that requests EK and EK certificate to the key and certificate servers. The personalization infrastructure decrypts the EK private key and writes it encrypted on the chip with the EK certificate. The key server, certificate server, HSM and the personalization infrastructure are all located within the secure production area of the TOE. The STMicroelectronics intermediate certificates and the Certificate Practice Statement are available from the STMicroelectronics website: http://www.st.com/TPM/repository/ Page 10 of 55 Public 2.3 TOE Description 2.3.1 TOE hardware description The TOE is based on the ST33HTPM hardware platform based on the ST33 product family. The ST33HTPM is a serial access microcontroller designed for Trusted Platform Module applications that incorporates the most recent generation of ARM processors for embedded secure systems. Its SecurCore® SC300™ 32-bit RISC core is built on the Cortex™ M3 core with additional security features to help to protect against advanced forms of attacks. The SC300™ core brings great performance and excellent code density thanks to the Thumb®-2 instruction set. The ST33HTPM features 3 hardware accelerators for advanced cryptographic functions • The EDES peripheral provides a secure DES (Data Encryption Standard) algorithm implementation, • The AES peripheral provides a secure AES (Advanced Encryption Standard) algorithm implementation, • the NESCRYPT crypto-processor efficiently supports the public key algorithm. Figure 1: ST33HTPM block diagram Page 11 of 55 Public The ST33HTPM supports a SPI interface compliant with [8]. Moreover the ST33HTPM hardware includes also the following security features: • Active shield • Memory protection unit (MPU) • Monitoring of environmental parameters • Code/Data Signature for Protection against fault attacks • ISO 3309 CRC calculation block • AIS-31 Class PTG2 compliant true random generator (TRNG) • Hardware security-enhanced DES accelerator • NESCRYPT coprocessor for public key cryptography • The ST ROM is located in non-volatile memory protected by a firewall. This ST firmware includes: • Test program used to validate the TOE production (OST) • ST Firmware providing boot and flash management services Page 12 of 55 Public 2.3.2 TOE Firmware description The ST33TPM1.2 firmware is an implementation compliant with the TPM specifications [5] [6] [7] and PCClient platform specifications [8]. Figure 2: TPM2E Firmware block diagram I/O Interface Transport TPM Execution State machine Startup Authorization & DAM TPM COMMAND Neslib Tick Key Storage Security RND PCR Field Upgrade Locality Crypto Monotonic Counter Delegation The firmware of the TOE includes the following modules • I/O Interface: configured to support exclusively SPI interface • Transport: wrapper-unwrapper for transport sessions • TPM Execution: dispatcher for TPM processing • State Machine: TPM state machine • Authorization & DAM: module managing the authorization and dictionary attack mitigation countermeasure • Startup: module responsible for TOE test at startup and TOE self test • TPM Command: processing of TPM commands • Delegation: module responsible for delegation • Monotonic counter: module responsible for management of monotonic counter logic • Neslib: cryptographic library providing basic crypto services protected against fault attacks: RSA, SHA1, SHA256, HMAC and HDRBG Page 13 of 55 Public • Crypto: modules providing crypto services: AES in CTR and CFB modes, HMAC; PKCS signature and encryption, MGF, key derivation function • Tick: module providing services for Tick Counters management • Key storage: module managing key repository • PCR: module managing Platform Configuration Registers • RND: Random Number generation services • Security: security configuration • Locality: locality management as defined in [8] • Field Upgrade: module managing the secure download of additional code in the field. The additional code must be encrypted with a AES 128-bit key and signed with a RSA 2048-bit authentication key to modify the protected capabilities of the TOE. 2.4 TOE guidance documentation The TOE user is invited to consult the product documentation [23] [24] [25] [26] [27] and [28]. 2.5 TOE lifecycle The life cycle of the TOE as part of this evaluation includes • phase 1 “Development” and • phase 2 “Manufacturing” as defined in the PP [10] section 1.3.3. The phase 1 that includes TPM development involves the sites of • ST ROUSSET (FRANCE) • ST ANGMO KIO (SINGAPORE) for the hardware development activities and • ST ROUSSET (FRANCE) • ST RENNES (FRANCE) • ST ZAVENTEM (BELGIUM) for the embedded software development activities. The phase 2 that includes the TPM manufacturing, the TPM conformance testing, the TPM- Mfg EK key pair download and the TPM-Mfg EK credential issuance involves the sites of • ST ROUSSET (FRANCE) • ST CROLLES (FRANCE) • ST TOA PAYOH.(SINGAPORE) Page 14 of 55 Public 3 CONFORMANCE CLAIM 3.1 CC Conformance Claim This security target is conformant to the Common Criteria version 3.1 R4. This security target claims to be Common Criteria version 3.1 R4 • Part 1 conformant, • Part 2 extended and • Part 3 conformant. The extended Security Function Requirement is the one defined in the protection profile. 3.2 PP Claim This security target is in strict conformance to the Protection Profile PC Client Specific TPM, Family 1.2 Level 2 Revision 116 (Version 1.3) released by the Trusted Computing Group dated 14 July 2014. The protection profile is registered and certified through an assurance continuity maintenance report by the Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference BSI-PP-0030-2008-MA-02, Version 1.3,dated 14 July 2014. 3.3 Package claim This security target does not claim conformance to a package of the PP [10] This ST is conforming to assurance package EAL4 augmented with • ALC_FLR.1 • AVA_VAN.4 defined in CC Part 3 [CCMB-2012-09-003]. 3.4 Conformance Rationale This security target claims strict conformance to only one PP [TPM1.2 PP rev116]. The Target of Evaluation (TOE) is a complete solution implementing the TCG Trusted Platform Module main specifications Version 1.2 level 2 revision 116 ([TPM Part1 116], [TPM Part2 116] and [TPM Part3 116]) and the TCG PC Client Specific TPM Interface Specification, Version 1.3 Final, Release 026 0 ([PC Client TIS 1.3]) as defined in the PP section 1.3.1. So the TOE is consistent with the TOE type in the PP. The security problem definition of this security target is consistent with the statement of the security problem definition in the PP, as the security target claims strict conformance to the PP and no other threats, organizational security policies and assumptions are added. The security objectives of this security target are consistent with the statement of the security objectives in the PP as the security target claims strict conformance to the PP and no other security objectives are added. The security requirements of this security target are consistent with the statement of the security requirements in the PP as the security target claims strict conformance to the PP. One security functional requirement is added in this security target to cover the authenticity verification of the field upgrade binary file. All assignments and selections of the security functional requirements are done in the PP section 6.1 and in this security target section 7.1. 3.5 Application note This security target claims compliance with the application note [22] released by the ANSSI (French CC Certification scheme) and defining security requirements for post-delivery code loading. Page 15 of 55 Public 4 SECURITY PROBLEM DEFINITION The content of the PP [TPM1.2 PP rev116] applies to this chapter completely. 4.1 Threats The threats are defined in the PP section 4.1, no other threats are added. The primary assets that have to be protected by the TOE against the listed threats are: • User data • TSF Data. In order to protect the access to the primary assets, the following components are also considered are assets: • Hardware of TOE • Embedded firmware. 4.2 Organizational Security Policies The organizational security policies are defined in the PP section 4.2. The following security policy is added to this TOE: Table 3: Organizational security policies for the TOE # OSP Description 1 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. 4.3 TOE Operational environment assumptions The TOE environment is highly variable. In general the TOE is assumed to be in an uncontrolled environment with no guarantee of the TOE’s physical security. The TOE assumptions to the IT environment are defined in the PP section 4.3, no other assumptions are added. Page 16 of 55 Public 5 SECURITY OBJECTIVES This section shows the security objectives which are relevant for the TOE. For this section the PP can be applied completely. 5.1 Security Objectives for the TOE The security objectives of the TOE are defined and described in the PP, section 5.1.The following security objectives are added to this TOE comply with [22]. Table 4: Security objectives for the TOE # Objective Description 1 O.FieldUpgradeControl The TOE restricts the Field Upgrade to authorised role and accepts only authentic update data provided by the TOE vendor. 2 O.Secure_Load_ACode The Loader of the Initial TOE shall check an evidence of authenticity and integrity of the loaded Additional Code. The Loader enforces that only the allowed version of the Additional Code can be loaded on the Initial TOE. The Loader shall forbid the loading of an Additional Code not intended to be assembled with the Initial TOE. 3 O.Secure_AC_Activation Activation of the Additional Code and update of the Identification Data shall be performed at the same time in an Atomic way. All the operations needed for the code to be able to operate as in the Final TOE shall be completed before activation. If the Atomic Activation is successful, then the resulting product is the Final TOE, otherwise (in case of interruption, or incident which prevents the forming of the final TOE), the Initial TOE shall remain in its initial state of fail secure. 4 O.TOE_Identification The Identification Data identifies the Initial TOE and Additional Code. The TOE provides means to store Identification Data in its non-volatile memory and guarantees the integrity of these data. After Atomic Activation of the Additional Code, the identification Data of the Final TOE allows identifications of the initial TOE and Additional Code. The user shall be able to uniquely identify Initial TOE and Additional Code(s) which are embedded in the Final TOE. 5.2 Security Objectives for the operational environment The security objectives for the operational environment are described in the PP, section 5.2. The following security objective for the operational environment is added for this TOE: Table 5: Security objectives for the operational environment # Objective Name Objective Description 1 OE.FieldUpgradeInfo The developer via AGD documentation will instruct the admin doing the upgrade 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. Page 17 of 55 Public 5.3 Security Objectives rationale The following table provides an overview of the mapping between the security objective for the TOE and the functional security requirements. The table shows and the rationale demonstrates that each security objective for the TOE is traced back to threats countered by that security objective and OSPs enforced by that security objective; each security objective for the operational environment is traced back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective. All security objectives counter all threats, enforce all organisational security policies and uphold all assumptions. The security objectives for the TOE and for the operational environment listed in the PP are covered by the table and rationale described in the PP, section 5.3. The following table and rationale covers the security objectives for the TOE and for the operational environment listed in this security target. Table 6: Security objectives rationale TOE O.FieldUpgradeControl O.Secure_Load_ACode O.Secure_AC_Activation O.TOE_Identification OE.FieldUpgradeInfo T.Imperson X T.Bypass X T.Insecure_State X T.Modify X OSP.FieldUpgrade X X X X X T.Imperson: An unauthorised individual may impersonate an authorised user of the TOE and thereby gain access to TOE data in shielded locations and protected capabilities. T.Imperson is countered by O.FieldUpgradeControl. This objective prevents impersonation by authentication based on managed roles with their security attributes and access control considering security attributes of the users securely provided by the TOE environment: • O.FieldUpgradeControl: This objective requires that only platform firmware or TPM owner are allowed to perform Field Upgrade. T.Bypass: An unauthorized individual or user may tamper with TSF, security attributes or other data in order to bypass TOE security functions and gain unauthorized access to TOE assets. T.Bypass is countered by O.Secure_Load_ACode: • O.Secure_Load_ACode: This objective requires that only authorized and authentic Additional code can be loaded in the TOE. 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. T.Insecure_State is countered by O.Secure_AC_Activation. This objectives ensure the preservation of secure state in case of failure: • O.Secure_AC_Activation: this Objective requires that if the Atomic Activation is successful, then the resulting product is the Final TOE, otherwise (in case of interruption, or incident which prevents the forming of the final TOE), the Initial TOE shall remain in its initial state of fail secure. 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. The integrity of the information may be compromised due to the unauthorised modification or destruction of the information by an attacker. Page 18 of 55 Public T.Modify is countered by O.TOE_Identification: • O.TOE_Identification: . this Objective requires that after Atomic Activation of the Additional Code, the identification Data of the Final TOE allows identifications of the initial TOE and Additional Code OSP.FieldUpgrade: The Platform software or the TPM owner 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. The OSP.FieldUpgrade is implemented by O.FieldUpgradeControl, O.Secure_Load_ACode, O.Secure_AC_Activation, O.TOE_Identification and OE.FieldUpgradeInfo: • O.FieldUpgradeControl: Ensures that o the field upgrade can only be performed by the platform software or TPM owner and o only authentic update data provided by the vendor are accepted. • O.Secure_Load_ACode: Ensures that o the Loader of the Initial TOE shall check an evidence of authenticity and integrity of the loaded Additional Code and o the Loader enforces that only the allowed version of the Additional Code can be loaded on the Initial TOE. The Loader shall forbid the loading of an Additional Code not intended to be assembled with the Initial TOE. • O.Secure_AC_Activation: Ensures that o Activation of the Additional Code and update of the Identification Data shall be performed at the same time in an Atomic way. o All the operations needed for the code to be able to operate as in the Final TOE shall be completed before activation. o If the Atomic Activation is successful, then the resulting product is the Final TOE, otherwise (in case of interruption, or incident which prevents the forming of the final TOE), the Initial TOE shall remain in its initial state of fail secure • O.TOE_Identification: Ensures that o The Identification Data identifies the Initial TOE and Additional Code. o The TOE provides means to store Identification Data in its non-volatile memory and guarantees the integrity of these data. o After Atomic Activation of the Additional Code, the identification Data of the Final TOE allows identifications of the initial TOE and Additional Code. The user shall be able to uniquely identify Initial TOE and Additional Code(s) which are embedded in the Final TOE. • OE.FieldUpgradeInfo: The operational environment is required to ensure that the end user shall be aware of the field upgrade process and its result, whether the installed firmware is certified or not and the version of the certified TPM. Page 19 of 55 Public 6 EXTENDED COMPONENT DEFINITION The extended component “FCS_RNG Generation of random numbers” (FCS_RNG.1) is already described in the PP. No other extended components are added. FCS_RNG Generation of random numbers Family behaviour This family defines quality requirements for the generation of random numbers which are intended to be used for cryptographic purposes. Component levelling: FCS_RNG.1 Generation of random numbers requires that random numbers meet a defined quality metric. Management: FCS_RNG.1 There are no management activities foreseen. Audit: FCS_RNG.1 There are no actions defined to be auditable. FCS_RNG.1 Random number generation Hierarchical to: No other components. Dependencies: No dependencies. FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybrid] random number generator that implements: [assignment: list of security capabilities]. FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric]. FCS_RNG Generation of random numbers 1 Page 20 of 55 Public 7 SECURITY REQUIREMENTS 7.1 Security Functional Requirements for the TOE 7.1.1 Security Functional Requirements listed by the TPM1.2 Protection Profile The security functional requirements (SFRs) for the TOE are defined in the PP section 6.1. All assignments and selections of the Security Functional Requirements are done in the PP with the exception of the following SFRs that required to be completed in the security target. The operations completed in this security target are marked in italic font. FMT_SMF.1 Specification of Management Functions Hierarchical to: Dependencies: No other components No dependencies FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 1. Management of the TPM modes of operation, 2. Management of Delegation Tables and Family Tables, 3. Management of security attributes of keys, 4. Management of security attributes of PCR, 5. Management of security attributes of NV storage areas, 6. Management of security attributes of monotonic counters, 7. Reset the Action Flag of TPM dictionary attack mitigation mechanism, 8. Management of TPM Field Upgrade FMT_MSA.2 Secure security attributes Hierarchical to: Dependencies: No other components [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 FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes of keys, PCR, NV storage areas and monotonic counters. FPT_TDC.1 Inter-TSF basic TSF data consistency Hierarchical to: Dependencies: No other components No dependencies FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret authentication data of the user using OperatorAuth, TPM Owner, delegation entities, owner of entities, user of entities when shared between the TSF and another trusted IT product. FPT_TDC.1.2 The TSF shall use roles defined in [TPM Part2 116] and [TPM Part3 116] when interpreting the TSF data from another trusted IT product. Page 21 of 55 Public FCS_RNG.1 Random number generation Hierarchical to: Dependencies: No other components No dependencies FCS_RNG.1.1 (DRG.3.1) (DRG.3.2) (DRG.3.3) The TSF shall provide a deterministic random number generator that implements: AIS20 Class DRG.3 according to [20]. if initialized with a random seed using a PTRNG of class PTG.2 as random source, the internal state of the RNG shall have at least 100 bit of min-entropy The RNG provides forward secrecy The RNG provides backward secrecy even if the current internal state is known FCS_RNG.1.2 (DRG.3.4) (DRG.3.5) The TSF shall provide random numbers that meet The RNG initialized with a random seed before the first use of the RNG after each product power up and reseeded after 2 32 requests generates output for more than 2 34 stings of bit length 128 that are mutually different with probability of w>1-2 -16 Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass FIPS 140-2 statistical test suite. FCS_CKM.1 /AES Cryptographic key generation Hierarchical to: Dependencies: No other components [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm: AES key generator and specified cryptographic key sizes 128 bits that meet the following: none FCS_CKM.4 Cryptographic key destruction Hierarchical to: Dependencies: No other components [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.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method: key overwriting with “0” or generation of new key encryption key that meets the following: none FCS_COP.1 /RSA_Sig Cryptographic operation Hierarchical to: Dependencies: No other components [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with Page 22 of 55 Public security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1 /RSA_Sig The TSF shall perform signature generation and signature verification in accordance with a specified cryptographic algorithm RSA signature scheme [5] section 31.2.1, 31.2.2, 31.2.3 and cryptographic key sizes RSA 512, 1024, 2048 that meet the following: PKCS#1 V2.0 ([PKCS#1]) FCS_COP.1 /RSA_Enc Cryptographic operation Hierarchical to: Dependencies: No other components [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 FCS_COP.1.1 /RSA_Enc The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm RSA encryption scheme [5] sections 31.1.1 and 31.1.2 and cryptographic key sizes RSA 512, 1024, 2048 that meet the following: PKCS#1 V2.0 [PKCS#1]. FCS_COP.1 /SymEnc2 Cryptographic operation Hierarchical to: Dependencies: No other components [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 FCS_COP.1.1 /SymEnc2 The TSF shall perform symmetric encryption and decryption in accordance with a specified cryptographic algorithm AES mode CTR as described in [5] section 31.1.3 and mode CFB with cryptographic key size of 128 bits that meet the following: FIPS PUB 197, 2001 November 26 and NIST Pub 800-38a FIA_UID.1 Timing of identification Hierarchical to: Dependencies: No other components No dependencies FIA_UID.1.1 The TSF shall allow: 1. to execute commands indicated in PP [TPM1.2 PP rev116] table 12 column RQU as not requesting authentication, 2. accessing objects where entity owner has given the user “World” access based on the value of TPM_AUTH_DATA_USAGE, 3. to execute the TPM Interface commands TPM_HASH_START, TPM_HASH_DATA and TPM_HASH_END Page 23 of 55 Public on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.1 Timing of authentication Hierarchical to: Dependencies: No other components FIA_UID.1 Timing of identification FIA_UAU.1.1 The TSF shall allow 1. to execute commands indicated in table 12 column RQU as not requesting authentication, 2. accessing objects where entity owner has given the user “World” access based on the value of TPM_AUTH_DATA_USAGE, 3. to execute the TPM Interface commands TPM_HASH_START, TPM_HASH_DATA and TPM_HASH_END on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: Dependencies: No other components No dependencies FIA_UAU.5.1 The TSF shall provide 1. OIAP authorization session, 2. OSAP authorization session, 3. DSAP authorization session, 4. Transport session, 5. Commands which require authorization and are executed outside a authorization session to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the following rule: the TOE maintains a counter of unsuccessful authentication. This counter is incremented each time a wrong authentication value is provided for OIAP, OSAP, DSAP authorization sessions. When the counters reaches a specific value (40dec), the activation Flag is set to True which makes that the response will be delayed. For each new unsuccessful authentication the response time is doubled until a maximum value. When this maximum value is reached the response time is always the maximum value FIA_AFL.1 Authentication failure handling Hierarchical to: Dependencies: No other components FIA_UAU.1 Timing of authentication FIA_AFL.1.1 The TSF shall detect when 40 unsuccessful authentication attempts occur related to authentication attempts for the same user. Page 24 of 55 Public FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall 1. Set the Action Flag to TRUE, 2. Add a delay in command response time for authorized commands, non authorized commands time is kept unchanged. This forbids another authorized command to be processed. Each new failed authentication doubles the response time up to a maximum value. FDP_ACF.1/ Deleg Security attribute based access control Hierarchical to: Dependencies: No other components FDP_ACC.1 Subset of access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/ Deleg The TSF shall enforce the Delegation SFP to objects based on the following: Delegated Entities and commands with the delegated permission defined in the delegation table row, locality, pcrInfo and key handle of the key in the Delegation owner blob. FDP_ACF.1.2/ Deleg The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 1. The TSF shall disallow the execution of a command in a DSAP session if the permission of this command is not set in the delegation table row in the Delegation owner blob used for the DSAP session, 2. The TSF shall disallow the execution of a command in a DSAP session if the PCR_SELECTION of the DSAP session is not NULL and the pcrInfo of the DSAP session does not match the current PCR value of the PCR_SELECTION and locality. FDP_ACF.1.3/ Deleg The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: if the TPM command is listed in the table at [6], section 20.2.1 “Owner Permission Settings” including TPM_KeyControlOwner 1 at bit 31 or the key is listed in the table at [6] section 20.2.3 “Key Permission Settings”, then the TPM owner or the key user can delegate that capability to a trusted process. FDP_ACF.1.4/ Deleg The TSF shall explicitly deny access of subjects to objects based on the rules: 1. if the TPM command is listed in the table at [6], section 20.2.2 “Owner commands not delegated” 2. if the key is listed in the table at [6], section 20.2.4 “Key commands not delegated”, then the command can not be delegated. 3. The delegation is denied if family linked to delegation row, delegation owner blob or delegation key blob flag TPM_FAMFLAG_ENABLED is set to false 4. The delegation family configuration is no more editable when TPM is unowned if family flag TPM_DELEGATE_ADMIN_LOCK is set to TRUE 1 TPM_KeyControlOwner at bit 31 in section 20.2.1 “Owner Permission Settings” was added in revision 116. Page 25 of 55 Public FDP_ACF.1/ KeyMan Security attribute based access control Hierarchical to: Dependencies: No other components FDP_ACC.1 Subset of access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/ KeyMan The TSF shall enforce the Key Management SFP to objects based on the following: 1. subjects: commands with security attributes ownerAuth, srkAuth, AuthData,locality, physical presence; 2. objects: (a) EK with the SFR-related security attribute ownership of the TOE, (b) SRK with the SRF related security attributes disableOwnerClear anddisableForceClear of the TOE, (c) User keys with the security attributesauth