Public SLB9635TT1.2/m1566a13 Security Target V1.0 2009-09-28 Infineon Technologies AG, Chipcard & Security Page 1 of 63 Public Infineon Technologies AG Chipcard & Security Evaluation Documentation SLB9635TT1.2 / m1566a13 Security Target Version 1.0 Date 2009-09-28 Author Jürgen Noller ©2009 Infineon Technologies AG. All rights reserved. This document and all information contained therein is considered confidential and proprietary of Infineon Technologies AG. The recipient of this document shall not disclose this document or the information contained herein in whole or in part to any third party. Infineon Technologies AG reserves the right to change the specification or parts of it without prior notice. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 2 of 63 Filename: SLB9635TT12_SecTar Author: Jürgen Noller, Infineon Technologies AG, CCS M PS Revision History: Version Date Subject 0.1 2008-04-22 Initial revision 1.0 2009-09-28 Final Version Public SLB9635TT1.2/m1566a13 Security Target V1.0 2009-09-28 Infineon Technologies AG, Chipcard & Security Page 3 of 63 List of Contents 1 Security Target Introduction 5 1.1 Security Target and Target of Evaluation Reference 5 1.2 Target of Evaluation Overview 7 2 Target of Evaluation Description 8 2.1.1 TOE Definition 8 2.2 Scope of the TOE 18 2.2.1 Hardware of the TOE 18 2.2.2 Guidance documentation 20 2.2.3 Forms of delivery 20 2.2.4 Production sites 20 2.2.5 Life cycle of the TOE 20 3 Conformance Claims 21 3.1 CC Conformance Claim 21 3.2 PP Claim 21 3.3 Package Claim 21 3.4 Conformance Claim Rationale 21 4 Security Problem Definition 22 4.1 Threats 22 4.2 Organisational Security Policies 22 4.3 Assumptions 22 5 Security Objectives 23 5.1 Security Objectives for the TOE 23 5.2 Security Objectives for the Operational Environment 23 5.3 Security Objectives Rationale 23 6 Extended Components Definition 24 7 IT Security Requirements 25 7.1 Security Functional Requirements for the TOE 25 7.2 Objects, Subjects, User Roles and Operations 43 7.3 Security Assurance Requirements 43 7.4 Security Requirements Rationale 45 8 TOE Summary Specification 46 8.1 TOE Security Features 46 8.1.1 SF_CRY - Cryptographic Support 46 8.1.2 SF_I&A - Authentication and Identification 47 8.1.3 SF_ACC – Access Control 49 8.1.4 SF_GEN – General 51 8.1.5 SF_P&T – Protection and Test 52 8.1.6 Assignment of Security Functional Requirements 54 8.2 Security Function Policy 56 8.2.1 Operational roles 56 8.2.2 Subjects 57 8.2.3 Objects, Operations and Security Attributes 58 9 Reference 59 9.1 Literature 59 9.2 List of Abbreviations 60 9.3 Glossery 61 Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 4 of 63 List of Tables Table 1: Identification ...............................................................................................................6 Table 2: Production site in chip identification .........................................................................20 Table 3: Assurance components............................................................................................44 Table 4: Assignment security functional requirement to security features .............................55 List of Figures Figure 1: Block diagram of the SLB9635TT1.2 ......................................................................16 Figure 2: Firmware block diagram of the SLB9635TT1.2.......................................................17 Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 5 of 63 1 Security Target Introduction This section contains the document management and provides an information overview. The Security Target (ST) identification provides the labelling and descriptive information neces- sary to identify, catalogue, register, and cross-reference a ST. The ST overview summarizes the profile in narrative form and provides sufficient information for a potential user to deter- mine whether the ST is of interest. The overview can also be used as a standalone abstract for ST catalogues and registers. 1.1 Security Target and Target of Evaluation Reference The title of the security target (ST) is SLB9635TT1.2 / m1566a13 Security Target. The security target has the revision 1.0 and is dated 2009-09-28. The Target of Evaluation (TOE) is a security IC (Security Controller) with integrated firmware (operating system) and guidance documentation, which is named SLB9635TT1.2, is inter- nally registered under the development code m1566a13 and has the version number a13. The Security Target is based on the Trusted Computing Group Protection Profile PC Client Specific Trusted Platform Module TPM Family 1.2; Level 2; Version 1.1 (PP, [8]). The Protection Profile and the Security Target are built in accordance with Common Criteria V3.1. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 6 of 63 Version Date Registration Security Target 1.0 2009-09-28 SLB9635TT1.2/m1566a13 Security Target Target of Evaluation SLB9635TT1.2 Hardware a13 m1566a13 Firmware 03.17.0 008.00 03.17.0008.00 Protection Profile 1.1 10-07-2008 Trusted Computing Group Protection Profile PC Client Specific Trusted Platform Module TPM Family 1.2; Level 2 Guidance Documentation V1.3 V1.2 V1.2 V1.0 V3.2 2008-01-22 2006-03-29 2005-07-11 2009-07-24 Sept 2009 TPM SLB9635TT1.2 TCG Rev 103 Trusted Platform Module Databook TPM Main Part 1 Design Principles, Specification Version 1.2 Revision 94 Part 2 TPM Structures Specification Version 1.2 Revision 94 Part 3 Commands Specification Version 1.2 Revision 94 TCG PC Client Specific TPM Interface Specification (TIS) for TPM Family 1.2; Level 2, Version 1.2 Final, Revision 1.00 TPM SLB9635TT1.2 Basic Platform Manufacturer Guideline for TPM 1.2, Application Note, Infineon Technologies AG TPM1.2 SLB9635TT1.2 Errata and Updates Common Criteria 3.1 2007-09 Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model CCMB-2006-09-001 Part 2: Security functional requirements CCMB-2007-09-002 Part 3: Security Assurance Components CCMB-2007-09-003 Table 1: Identification Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 7 of 63 1.2 Target of Evaluation Overview This Security Target (ST) describes the target of evaluation (TOE) known as the Infineon SLB9635TT1.2 Trusted Platform Module (TPM) and gives a summary product definition. The SLB9635TT1.2 Trusted Platform Module, called TPM or SLB9635TT1.2 in the following text, is an integrated circuit and software platform that provides computer manufacturers with the core components of a subsystem used to assure authenticity, integrity and confidentiality in e-commerce and internet communications within a Trusted Computing Platform. The SLB9635TT1.2 is a complete solution implementing the version 1.2 of the TCG Trusted Plat- form Module Main, Specification Version 1.2, [5] [6] [7] and the TCG PC Client Specific TPM Interface Specification, Version 1.2 Final, Revision 1.00 [9]. The SLB9635TT1.2 uses the LPC interface (Low Pin Count) as defined by Intel for the inte- gration into existing PC mainboards. The SLB9635TT1.2 is basically a secure controller with the following added functionality: • Random number generator • Asymmetric key generation (RSA keys with key length up to 2048 bit) • Symmetric key generation (Triple-DES keys, for internal use only) • Symmetric and asymmetric key procedures (encryption/decryption, generation and verification of digital signatures) • Hash algorithms (SHA-1) and MAC (HMAC) • Secure key and data storage • Identification and Authentication mechanisms • Tick and Monotonic Counter In this security target the TOE (target of evaluation) is described and a summary specification is given. The security environment of the TOE is defined. The assets are identified which have to be protected through the security policy. The threats against these assets are de- scribed. The security objectives as the objectives of the security policy are defined as well as the security requirements. The applicable IT security requirements are taken from the Com- mon Criteria, with appropriate refinements. The security requirements are constructed out of the security functional requirements as part of the security policy and the security assurance requirements, as the steps during the evaluation and certification to prove that the TOE meet this requirements. The functionality of the TOE to meet the requirements is described. The assets, threats, security objectives and the security functional requirements are defined in the Trusted Computing Group Protection Profile PC Client Specific Trusted Platform Mod- ule TPM Family 1.2; Level 2; Version 1.1 [8], and are referenced here. The TOE summary specification consisting of the security features, the assurance require- ments and the security function policies are defined in the ST as property of this specific TOE, the SLB9635TT1.2. The rationale presents evidence that the ST is a complete and cohesive set of requirements and that a conformant TOE would provide an effective set of IT security countermeasures within the security environment. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 8 of 63 2 Target of Evaluation Description The TOE description helps to understand the specific security environment and the security policy. In this context the assets, threats, security objectives and security functional require- ments can be employed. The following is a more detailed description of the TOE than in the Trusted Computing Group Protection Profile PC Client Specific Trusted Platform Module TPM Family 1.2; Level 2 [8] as it belongs to the specific TOE. 2.1.1 TOE Definition The Target of Evaluation (TOE) is the “Infineon SLB9635TT1.2 Trusted Platform Module” of the Infineon Technologies AG called “SLB9635TT1.2” or “TPM” in the following description. The TOE is an integrated circuit and software platform that provides computer manufacturers with the core components of a subsystem used to assure authenticity, integrity and confiden- tiality in e-commerce and internet communications within a Trusted Computing Platform as defined in the TPM Main Specification. The SLB9635TT1.2 is a complete solution implement- ing the TCG TPM Main Specification Version 1.2, [5] [6] [7] and the TCG PC Client Specific TPM Interface Specification (TIS) Version 1.2 Final, Revision 1.00 [9]. A Trusted Platform is a platform that can be trusted by local users and by remote entities. The basis for trusting a platform is a declaration by a known authority that a platform with a given identity can be trusted to measure and report the way it is operating. That operating information can be associated with data stored on the platform, to prevent the release of that data if the platform is not operating as expected. Other authorities provide declarations that describe the operating information the platform ought to produce when it is operating prop- erly. The local user and remote entities trust the judgment of the authorities; so, when they receive proof of the identity of the platform, information about the current platform environ- ment, and proof about the expected platform environment, they can decide whether to trust the platform to behave in a sufficiently trustworthy and predictable manner. The local user and/or remote entities must take this decision themselves because the level of trust in a plat- form can vary with the intended use of that platform, and only the local user and/or remote entities know that intended purpose. The trusted mechanism of the platform uses cryptographic processes, including secrets. The trusted mechanisms are required to be isolated from the platform in order to protect secrets from disclosure and protect methods from subversion. The subsystem protects itself against physical and software attacks to provide protection against attacks to the platform. Some, but not all, subsystem capabilities must be trustworthy for the subsystem to be trust- worthy. These are called the “Trusted Set” (TS). Other capabilities must work properly if the subsystem is to work properly, but they do not affect the level of trust in a Subsystem. These are called the “Trusted platform Support Set” (TSS). The Trusted Set of capabilities can be partitioned into measurement capabilities, reporting capabilities, and storage capabilities. The trusted measurement capabilities are called the “Root of Trust for Measurement” (RTM). The trusted reporting capabilities are called the “Root of Trust for Reporting” (RTR). The trusted storage capabilities are called the “Root of Trust for Storage” (RTS). The RTM makes reliable measurements about the platform and puts the measurement results into the RTR. The RTR prevents unauthorized changes to the Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 9 of 63 measurement results, and reliably reports those measurement results. The RTS provides methods to minimize the amount of trusted storage that is required. The “Root of Trust for Measurement” and the “Root of Trust for Reporting” cooperate to permit an entity to believe measurements that describe the current computing environment in the platform. An entity can assess those measurement results and compare them with values that are to be ex- pected if the platform is operating as expected. If there is sufficient match between the measurement results and the expected values, the entity can trust computations within the platform (not just within the TS) to execute as expected. The RTR have a cryptographic identity in order to prove to a remote entity that RTR mes- sages come from genuine trusted capabilities, and not from bogus trusted capabilities. The SLB9635TT1.2 is basically a secure controller with the following added TOE security services (TOSS): Random number generation (RNG) The RNG capability is only accessible for valid TPM commands. Intermediate results from the RNG are not available to any user. When the data is for internal use by the TPM (e.g. asymmetric key generation) the data is held in a shielded location and is not acces- sible to any user. Algorithms: RSA, SHA-1, DES, AES, MGF1 The SLB9635TT1.2 supports the RSA algorithm for encryption and digital signatures with key sizes of 512, 1024 and 2048 bits. The RSA implementation provides protection and detection of failures during the Chinese Remainder Theorem (CRT) process. The TPM storage keys and TPM identity keys are of strength equivalent to a 2048 bit RSA key. A storage key whose strength is less than that of a 2048 RSA key could not be stored in the SLB9635TT1.2. The TPM identity keys are RSA keys with key size of 2048 bits. The RSA algorithm is used for signature and verification operations according PKCS#1 V2 for the format and design of the signature output. The SLB9635TT1.2 supports the Secure Hash Algorithm-1 (SHA-1) hash algorithm as defined by United States Federal Information Processing Standard 180-2. The output of the SHA-1 is a 160 bit hash value and all areas that expect a hash value are required to support the full 160 bits. The SLB9635TT1.2 supports the Triple-DES algorithm with key sizes of 168 bits for en- cryption and decryption. The function is used to support the temporary cashing of keys outside the TPM and for the personalisation of code and data. The SLB9635TT1.2 supports the AES algorithm with key sizes of 128 bits for encryption and decryption. The function is used to support the transportation functionality. SLB9635TT1.2 supports the MGF1 algorithm with key sizes of 160 bits for encryption and decryption. The function is used to support the transportation functionality. Key Generation The SLB9635TT1.2 generates asymmetric key pairs (algorithm RSA) in accordance with P1363 and Triple-DES keys with key sizes of 168 bits (for internal use). The generation function is a protected capability and the private key and the Triple-DES key is held in a shielded location. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 10 of 63 For the HMAC key generation and for the creation of all nonce values the next n bits are taken from the internal TPM RNG. The keys managed by the TPM may be non-migratable or migratable. A non-migratable key is a key that cannot be transported outside a specific TPM. A migratable key is a key that may be transported outside the specific TPM. The certified migratable key allows for migration but still has properties that the TPM can certify. Self-Tests The SLB9635TT1.2 provides startup self-tests and a mechanism to allow self-tests to be run on demand. The response from self-tests is pass or fail. Self-tests include checks of the following: ƒ RNG functionality (according AIS20 K3). ƒ Reading and extending the integrity registers. ƒ Endorsement key pair integrity. This test verifies the RSA sign and verify engine by signing and verifying a known value with the endorsement key pair. ƒ Integrity of the protected capabilities of the SLB9635TT1.2 by checking a hash value of the “microcode” (TPM firmware) to ensure that the microcode has not changed. ƒ Test of the tamper-resistance markers. If a failure during any self-test is detected, the part experiencing the failure will enter a shutdown mode and an error code is returned. Identification and Authentication The TPM identification and authentication capability is used to authenticate an entity owner and to authorize use of an entity. The basic premise is to prove knowledge of a shared secret. This shared secret is the identification and authentication data. The TCG specification calls the identification and authentication process and this data authorization. The identification and authentication (authorization) data for the TPM Owner and the owner of the Storage Root Key are held within the TPM itself. The identification and au- thentication (authorization) data for other owners of entities are held and protected with the entity. The identification and authentication protocols use a random nonce. This requires that a nonce from one side be in use only for a message and its reply. For instance, the TPM would create a nonce and send that on a reply. The requestor would receive that nonce and then include it in the next request. The TPM would validate that the correct nonce was in the request and then create a new nonce for the reply. This mechanism is in place to prevent replay attacks and man-in-the-middle attacks. Access control Access control is enforced in the SLB9635TT1.2 on all data and operations performed on that data. The TPM provides access control by denying access to some data and opera- tions and allowing access to other data and operations based on the value of different flags called security attributes (e.g. TPM_AUTH_DATA_USAGE, TPM_KEY_FLAGS, TPM_KEY_USAGE) which are defined in the PP [8], Table 1. For example the security attribute TPM_AUTH_DATA_USAGE defines access as either “never” or “always”. Al- Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 11 of 63 ways must be authenticated with a shared secret. Never means that usage of the key is permitted by anyone without authentication. The security attribute TPM_KEY_FLAGS de- fines information regarding a key, e.g. a key is a migratable, non-migratable or certifiable migratable. A non-migratable key is a key that cannot be transported outside a specific TPM. A migratable key is a key that may be transported outside the specific TPM. In ad- dition some keys must be bound to a specific TPM but should be able to be backuped or migrated under certain circumstances. The certified migration allows a Migration Selec- tion Authority therefore to control a migration process without handle the migrated key it- self or respectively uses a Migration Authority to control the migration process with the knowledge of the data of the migrated key. Those keys which are planed for certified mi- gration are called certifiable migratable keys. The security attribute TPM_KEY_USAGE identifies the permitted usage of a key. Depending on the key type (e.g. signing key, stor- age key and identity key) certain operations may or may not be allowed using the particu- lar key. Upon appropriate identification and authentication associated with the keys, us- ers can use the key for the purposes permitted by the security attribute TPM_KEY_USAGE. The security attributes are stored as flags in the TPM or associated with the data in an encrypted blob. Tick and Monotonic Counter The SLB9635TT1.2 provides a “tick counter” as a count of the numbers of ticks that have occurred since the start of a timing session. The time between the ticks is identified by the “tick rate” but it is the responsibility of the caller to associate the ticks to an actual UTC time. The SLB9635TT1.2 provides also a monotonic counter as an ever-increasing incremental value for external use. Root of Trust for Storage The SLB9635TT1.2 provides non-volatile storage as shielded location for data of external entities. The TPM owner controls access to the non-volatile storage. The access control may include the need of authentication of the user, delegations, PCR values and other controls. Additionally the SLB9635TT1.2 has the capability of secure storage for an unlimited umber of private keys or other data by using RSA key technology to encrypt data and keys. The resulting encrypted file, which contains header information in addition to the data or key, is called a blob and is output by the TPM, it can be re-loaded in the TPM when needed. The functionality of the SLB9635TT1.2 can also be used that private keys generated on the TPM can be stored outside the TPM (encrypted) in a way allowing the TPM to use them later without ever exposing such keys in the clear outside the TPM. The functionality used to provide secure storage is: ƒ TPM_Seal and TPM_Unseal, which performs RSA encrypt and decrypt functions, re- spectively, 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: 1) the appropriate key must be available for unseal, 2) the TPM PCRs must contain the values defined at the time of the seal operation, and 3) the value of tpmProof must be the same as that en- Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 12 of 63 crypted 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 decrypt to only occur on the specified TPM. ƒ TPM_Unbind, which RSA decrypts a blob created outside the TPM that has been en- crypted using a public key where the associated private key is stored in the TPM. A number of key types are defined within the TPM. The keys may be migratable or non- migratable. A migratable key is a key that may be transported outside a specific TPM. A non-migratable key is a key that cannot be transported outside a specific 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 migatable data or non-migratable data. ƒ Storage keys, which are used to RSA encrypt and RSA decrypt other keys and their security attributes in the Protected Storage hierarchy, only. ƒ Binding keys, which are used for TPM_Unbind operations only. A bound 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 bind- ing 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. Root of Trust for Reporting The root of trust for reporting (RTR) exposes the measurement digests stored in the PCRs and attest to the authenticity of these measurement digests based on trusted plat- form identities or 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 SLB9635TT1.2 is identified and validated by its Endorsement Key. The Endorse- ment Key is an asymmetric key pair that is used as proof that a SLB9635TT1.2 is genu- ine. The Endorsement Key pair is generated and encrypted (using a three key Triple-DES algorithm in CBC mode) outside the SLB9635TT1.2 in a secure environment by the manufacturer Infineon Technologies AG and then loaded encrypted into the SLB9635TT1.2 during the production phase. The Endorsement Key is transitively bound to the Platform via the SLB9635TT1.2 as follows: • An Endorsement Key is bound to one and only one SLB9635TT1.2 (i.e., that is a one to one correspondence between an Endorsement Key and a SLB9635TT1.2.) • A SLB9635TT1.2 is bound to one and only one Platform, (i.e., there is a one to one correspondence between a SLB9635TT1.2 and a Platform.) Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 13 of 63 • 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 Creden- tials and to establish a platform owner. The Direct Anonymous Attestation Protocol (DAA) provides evidence that the TPM holds a valid Attestation Identity Key without revealing the attestation information. Support for the Root of Trust for Measurement The TPM supports the integrity measurement of the trusted platform by calculation, stor- age and reporting of measurement digests of measured values. The measurement values are representation 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 sup- ports 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 PCR are shielded locations of the TPM which can be reset by TPM reset or trusted process, written only through measurement digest extensions and read. Generation and import of the Endorsement Key pair The Endorsement Key (EK) pair stored in the TPM is generated outside the TPM with the TPM Personalization Certification Authority (TPM-CA) located within the secure produc- tion area of the TOE. The EK pair and the associated EK credential are loaded into the TPM during the manufacturing process at the TOE lifecycle phase “Manufacturing”. The TPM-CA is located at the production site of the TOE in a secure room. The TPM-CA con- sists of a Personalization Dataset Generator (PDG) including a hardware security model (HSM-PDA), a Certification Authority (INCA) and a database server. The HSM-PDG gen- erates the EK pair and encrypts the key pair using a master key and the algorithm three key Triple-DES in CBC mode. The encrypted EK pair is then stored in the database server. The INCA creates the EK credential by certifying the public part of the EK. The EK credential is also stored at the database server. For the production process the plain EK pair is encrypted with a TPM individual transport key and transported to the production facility. The personalization process generates the TPM individual transport key and loads this key together with the encrypted EK pair and the EK credential into the TPM. Within the TPM the EK pair is encrypted with the transport key and stored in a shielded location. The generation and import process of the Endorsement Key pair is done com- pletely in the secure production area of the TOE. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 14 of 63 To simplify system integration into existing PC mainboards, the SLB9635TT1.2 uses the LPC interface (Low Pin Count) as defined by Intel. With these capabilities, the SLB9635TT1.2 is able to realize the issue of the TPM Main Specification to insert a trusted subsystem – called the “root of trust” – into the PC platform, which is able to extend its trust to other parts of the whole platform by building a “chain of trust”, where each link extends its trust to the next one. As a result, the TPM extends its trustworthiness, providing a Trusted PC for secure transactions. As an example the TPM is able to calculate hash-values of the BIOS at boot time as integrity metric. Once this metric is available, it is saved in a secure memory location. Optionally, it could be compared to some predefined values and the boot process could be aborted on mismatch. During the boot process, other integrity metrics are collected from the platform, e.g. the boot loader and the operating system itself. Device drivers may be hashed and even hardware like PCI cards can be detected and identified. Every metric obtained is concatenated to the al- ready available metrics. This gives a final metric, which describes the operational state of the whole platform and the state of its system integrity. A challenger may now ask the platform for these metrics and make informed decisions on whether to trust it based on the metric values obtained. To support the privacy issue, the user of the platform may restrict the SLB9635TT1.2 in answering to any challenge, but the user is never able to make the SLB9635TT1.2 report false metrics. Moreover, the user is able to create several identities for his interactions. Offering these features to a system, the SLB9635TT1.2 can be used in a wide field of appli- cations, e.g. in a remote access network to authenticate platforms to a server and vice versa. Concerning e-commerce transactions, contracts can be signed with digital signatures using the SLB9635TT1.2 asymmetric encryption functionality. Regarding a network scenario, the client PCs equipped with a SLB9635TT1.2 are able to report their platform status to the server so that the network administration is aware of their trustworthiness. In conclusion, the SLB9635TT1.2 acting as a service provider to a system helps to make transactions more secure and trustworthy. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 15 of 63 The Target of Evaluation (TOE), the SLB9635TT1.2, consists of the following hardware and firmware components. The hardware of the SLB9635TT1.2 is based on the SLE66CX680PE architecture with addi- tional components. The hardware is manufactured by the Infineon Technologies AG in a 0,22 µm CMOS technology. As a side effect of this porting the most components are unchanged. The IC, whose block diagram is shown in Figure 1, consists of a dedicated microprocessor (CPU) with a MMU (Memory Management Unit), several different memories, security logic, shield, a timer, an interrupt-controlled I/O interface and a RNG (Random Number Generator) are integrated on the chip. Additionally, a hardware hash accelerator and a specialized inter- face the Low Pin Count interface (LPC) have been added. This LPC interface is the main interface of the chip. The CPU is compatible with the SAB 8051 instruction set and is 6 times faster than the stan- dard processor. The memory comprises 256 bytes of internal RAM (IRAM), 12 kByte of ex- tended RAM (XRAM), 196 kByte of user ROM, 8kByte of test ROM and 68 kByte of EEPROM. It thus meets the requirements of the new generation of operating systems. The CPU accesses the memory via the integrated Memory Encryption and Decryption unit (MED). The access rights of the application to the memories can be controlled with the memory man- agement unit (MMU). Security, sleep mode and interrupt logic as well as the RNG are spe- cially designed for secure applications. The sleep mode logic is used to reduce the overall power consumption. The SLB9635TT1.2 uses an external clock of 33 MHz where is compli- ant to the definition of the LPC interface. The PLL unit allows operating the core controller of the SLB9635TT1.2 with a multiplication factor over the divided external clock signal or free running with maximum frequency. The checksum module allows simple calculation of check- sums per ISO 3309 (16 bit CRC). Three modules for cryptographic operations are implemented on the TOE. The ACE (Ad- vanced Crypto Engine) is used for calculation of asymmetric algorithms like RSA. This mod- ule is especially designed for high-performance applications with respect to the security and power consumption The DDC module provides the DES algorithm. This module computes the complete DES algorithm within a few clock cycles. The DDC is especially designed to counter attacks like DPA or EMA. The third module named HASH provides the Secure Hash Algorithm-1 (SHA-1). To sum up, the TOE is a powerful security IC with a large amount of memory and special peripheral devices with both improved performance and optimised power consumption at minimal chip size. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 16 of 63 Security Logic CLK RST I/O GND VCC Address and Data Bus CPU, MED, MMU and IRAM Interrupt Module Memory EEPROM LPC Interface I N P Memory Coprocessors User- ROM Test- ROM XRAM HASH CRC DDC ACE Timer RNG LPC Peripherals Coun- ter Figure 1: Block diagram of the SLB9635TT1.2 Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 17 of 63 The firmware required for operating the chip includes an operating system that provides the TCG functionality specified in the TPM Main Specification. The chip initialisation routine with security checks and identification mode as well as test routines for production testing are located in a separate test ROM. The firmware also provides the mechanism for updating the protected capabilities once the TOE is in the field as defined in the TPM_FieldUpgrade com- mand of the TPM Main Specification. The field upgrade can only be downloaded to the chip if it has been encrypted and signed by the manufacturer Infineon Technologies AG. The Figure 2 shows the firmware block diagram of the SLB9635TT1.2. Field-Upgrade I / O- Interface TPM- Dispatcher TPM- Command Test Memory Archive RSA 2048 Security State-Machine Authorization HASH 3DES Transportation DictionaryAttack Logic Tick Counter AES FW-Upgrade- Dispatcher FW-Upgrade RND PCR Tcpa Flags DAA Key Class System Startup Locality HMA C MGF1 Figure 2: Firmware block diagram of the SLB9635TT1.2 Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 18 of 63 2.2 Scope of the TOE The TOE manufactured by Infineon Technologies, comprises the hardware of the security controller, type SLB9635TT1.2, and the associated firmware required for operation provided in ROM and EEPROM 2.2.1 Hardware of the TOE The hardware part of the TOE (cf. Figure 1) as defined in the PP [8] is comprised of: • Security logic (SEC) • Microcontroller type ECO2000 (CPU) with the subcomponents memory encryption and decryption unit (MED), memory management unit (MMU) and 256 bytes of internal RAM (IRAM) • External memory comprising: − 12 kByte extended RAM (XRAM) − 196 kByte user ROM, including the routines for chip management (RMS) − 8 KB test ROM containing the test routines (STS), and − a total of 68 kByte non-volatile memory (EEPROM) • Random number generator (RNG) • Checksum module (CRC) • Interrupt module (INT) • Timer (TIM) • Address and data bus (BUS) • ACE for long integer modulo calculations, which are used in asymmetric algorithms like RSA • DES accelerator (DDC) used for fast calculations of the DES algorithm • Low Pin Count interface (LPC) • Hash accelerator (HASH) for the algorithms SHA-1 • Tick Counter • Input logic (INP) Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 19 of 63 • Firmware of the TOE The entire firmware of the TOE consists of two different parts. The one is the operating sys- tem called firmware in the following document. The firmware includes operating system and the Endorsement Key and is used to operate the IC. The firmware includes also the capabil- ity for updating the protected capabilities once the TOE is in the field (TPM_FieldUpgrade). Note that it is possible to update an old TPM firmware version e.g. v3.16 to a certified firm- ware version v3.17.0008.00 The other is the Self Test Software (STS). The STS routines are stored in the especially pro- tected test ROM and are not accessible for the user software (application). The entire firmware of the TOE (cf. Figure 2) as defined in the PP [8] is comprised of: • I/O-Interface • Transportation • TPM-Dispatcher • State-Machine • Authorization • Dictionary Attack Logic • TPM-Command • HASH • HMAC • 3DES • AES • RSA2048 • MGF1 • Memory • Security • Archive • Test • Tick Counter • DAA • RND • PCR • Field-Upgrade • TcpaFlags • Locality • Key Class • System Startup Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 20 of 63 2.2.2 Guidance documentation The guidance documentation consists of a set of information containing the description of all interfaces to operate the TOE. The list of the guidance documentation is given in Table 1, section Guidance Documentation. 2.2.3 Forms of delivery The TOE is delivered in form of complete chips which include the hardware, the firmware (operating system), the Endorsement Key Pair, and the guidance documentation. The TOE is finished and the extended test features are removed. 2.2.4 Production sites The TOE is produced in the production site Dresden. The Chip Ident Mode data is coded as shown in Table 2. Table 2: Production site in chip identification Production Site Chip Identification (first nibble, hex format) Dresden 2 The delivery measures are described in the ALC_DVS aspect. 2.2.5 Life cycle of the TOE The life cycle of the TOE as part of the evaluation covers phase 1 “Development” and phase 2 “Manufacturing” as defined in the PP [8] section 1.3.3. The phase 1 includes the TPM de- velopment, the phase 2 includes the TPM manufacturing, the TPM conformance testing, the TPM-Mfg EK key pair download and the TPM-Mfg EK credential issuance. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 21 of 63 3 Conformance Claims 3.1 CC Conformance Claim This Security Target is conformant to Common Criteria version v3.1 part 1 [1]. The Security Target is conformant to Common Criteria version V3.1 part 2 extended [2]. The Security Target is conformant to Common Criteria version V3.1 part 3 conformant [3]. 3.2 PP Claim This Security Target is in strict conformance to the Trusted Computing Group Protection Profile PC Client Specific Trusted Platform Module TPM Family 1.2; Level 2 [8]. The Protection Profile (PP) [8] is registered and certified by the Bundesamt für Sicherheit in der Informationstechnik1 (BSI) under the reference BSI-PP-0030-2008, Version 1.1, dated 10.07.2008. 3.3 Package Claim This ST is conforming to assurance package EAL4 augmented with ALC_FLR.1 and AVA_VAN.4 defined in CC part 3 [3]. 3.4 Conformance Claim Rationale This security target claims strict conformance only to one PP, the PP [8]. The Target of Evaluation (TOE) is a complete solution implementing the TCG Trusted Plat- form Module Main, Specification Version 1.2, [5] [6] [7] and the TCG PC Client Specific TPM Interface Specification, Version 1.2 Final, Revision 1.00 [9] as defined in the PP [8] section 1.3.1, so the TOE is consistent with the TOE type in the PP [8]. The security problem definition of this security target are consistent with the statement of the security problem definition in the PP [8], as the security target claimed strict conformance to the PP [8] and no other threats, organisational 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 [8], as the security target claimed strict conformance to the PP [8] and no other security objectives are added. The security requirements of this security target are consistent with the statement of the se- curity requirements in the PP [8], as the security target claimed strict conformance to the PP [8] and no other security requirements are added. All assignments and selections of the se- curity functional requirements are done in the PP [8] and in this security target section 7.1. 1 BSI is the German abbreviation for Federal Authority for Information Security Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 22 of 63 4 Security Problem Definition The content of the PP [8] applies to this chapter completely. 4.1 Threats The threats are directed against the assets. The threats to security are defined in the PP [8] section 4.1, no other threats are added. The primary assets concern the TSF and the User Data that includes the data as well as program code (Embedded Firmware). These assets have to be protected while being exe- cuted as well as when the TOE is not in operation. This leads to the following primary assets: • Embedded Firmware • User Data • TSF Data • Hardware of TOE 4.2 Organisational Security Policies The organisational security policies are defined in the PP [8] section 4.2, no other organisa- tional security policies are added. 4.3 Assumptions The TOE environment is highly variable. In general, the TOE is assumed to be in an uncon- trolled environment with no guarantee of the TOE’s physical security. The TOE assumptions to the IT environment are defined in the PP [8] section 4.3, no other assumptions are added. The TCG subsystem, in which the TPM is used, is a trusted subsystem that is an integral part of a computing platform that consists of logical components including the TPM, the Connec- tion module (PCCON) and the Trusted Platform Support Services (TSS). In general the TPM provides cryptographic capabilities and protected storage. The Connection module (PCCON) provides the connection to the computing platform and the Root of Management Trust (RMT). The TPM relies on the PCCON module for all communica- tion with the platform and for the RMT. The TSS is a set of functions and data that are common to all types of platforms, which are not required to be trustworthy and therefore do not need to be part of the TPM. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 23 of 63 5 Security Objectives This section shows the security objectives which are relevant for the TOE. For this section the PP [8] can be applied completely. 5.1 Security Objectives for the TOE The security objectives of the TOE are defined and described in the PP [8] section 5.1, no other security objectives are added. 5.2 Security Objectives for the Operational Environment The security objectives for the operational environment are described in the PP [8] section 5.2, no other security objectives for the operational environment are added. 5.3 Security Objectives Rationale The security objectives rationale is described in the PP [8] section 5.3. No other security ob- jectives rationale are added. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 24 of 63 6 Extended Components Definition The extended component “FCS_RNG Generation of random numbers” (FCS_RNG.1) is al- ready described in the PP [8]. No other extended components are added. Family Random Number Generation To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the Class FCS (cryptographic support) is defined here. This family describes the functional requirements for random number generation used for cryptographic purposes. The random number generation is provided to the user and used internally, but it is not limited to genera- tion of authentication data or cryptographic keys. FCS_RNG Generation of random numbers Family behavior This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes. Component leveling: 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 imple- ments: [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 Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 25 of 63 7 IT Security Requirements For this section the PP [8] section 6 can be applied completely. 7.1 Security Functional Requirements for the TOE The security functional requirements (SFR) for the TOE are defined and described in the PP [8] section 6.1. All assignments and selections of the security functional requirements are done in the PP [8] with the exception of the following SFRs. The operations completed in the ST are marked in italic font. FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. Dependencies: 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) None. FPT_TDC.1 Inter-TSF basic TSF data consistency Hierarchical to: No other components. Dependencies: No dependencies. FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret authentication reference data of the User using operatorAuth, TPM owner, delegated 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 [6] and [7] when interpreting the TSF data from another trusted IT product. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 26 of 63 FCS_CKM.1/3DES Cryptographic key generation Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/3DES The TSF shall generate cryptographic keys in accordance with a speci- fied cryptographic key generation algorithm 3DES key generator and specified cryptographic key sizes 168 bits that meet the following: the 3DES key is a 168 bit random number. FCS_RNG.1 Random number generation Hierarchical to: No other components. Dependencies: No dependencies. FCS_RNG.1.1 The TSF shall provide a hybrid random number generator that implements: generation of random numbers. FCS_RNG.1.2 The TSF shall provide random numbers that meet AIS20 K3, [AIS20]. FCS_CKM.4 Cryptographic key destruction Hierarchical to: No other components. Dependencies: [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 cryp- tographic key destruction method: key destruction that meets the following: FIPS PUB 140-1 [FIPS_140], section 4.8.5 (overwriting all bits with “1” or with a random value). FCS_COP.1/RSA_Sig Cryptographic operation Hierarchical to: No other components. Dependencies: [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_Sig The TSF shall perform signature generation and signature verification in ac- cordance with a specified cryptographic algorithm RSA signature scheme [5] section 31.2.1, 31.2.2 and 31.2.3 and cryptographic key sizes RSA 512, 1024, 2048 that meet the following: PKCS#1 V2.0 [PKCS]. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 27 of 63 FCS_COP.1/RSA_Enc Cryptographic operation Hierarchical to: No other components. Dependencies: [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 speci- fied cryptographic algorithm RSA encryption scheme] [5] section 31.1.1, 31.1.2 and 31.1.3 and cryptographic key sizes RSA 512, 1024, 2048 that meet the following: PKCS#1 V2.0 [PKCS]. FCS_COP.1/SymEnc2 Cryptographic operation Hierarchical to: No other components. Dependencies: [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 - 3DES, mode CBC and cryptographic key sizes - 168 bit for 3DES, that meet the following: - Data Encryption Standard (DES), FIPS PUB 46-3, 1999 October 25, U.S. Department of Commerce / National Bureau of Standards; [FIPS_46] FCS_COP.1/SymEnc3 Cryptographic operation Hierarchical to: No other components. Dependencies: [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/SymEnc3 The TSF shall perform symmetric encryption and decryption in accordance with a specified cryptographic algorithm - AES, mode CTR and cryptographic key sizes - 128 bit for AES that meet the following: - Advanced Encryption Standard (AES), FIPS PUB 197 ,2001 November 26 Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 28 of 63 U.S. Department of Commerce, National Institute of Standards and Technology; [FIPS_197]. FIA_UID.1 Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1 The TSF shall allow (1) to execute commands indicated in the PP [8], 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 commands TPM_HASH_START, TPM_HASH_DATA and TPM_HASH_END 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: No other components. Dependencies: FIA_UID.1 Timing of identification FIA_UAU.1.1 The TSF shall allow (1) to execute commands indicated in the PP [8] 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 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 al- lowing any other TSF-mediated actions on behalf of that user. FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1 The TSF shall provide Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 29 of 63 (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 au- thorization session to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the rule “dictionary attack”. The dictionary attack is a mechanism to manage authenti- cation failure handling to mitigate dictionary attacks. The dictionary attack pro- vides two different objects, a single object mode, which means that all de- tected authentication failure are collected at the same counter, and the full ob- ject mode, which means that the detected authentication error could be distin- guished and collected on different counters. If the dictionary attack mecha- nism has the maximum number of authentication errors detected, the Activa- tion Flag is set to TRUE and two different ways of processing could be started. For the first way logic is activated to add a delay time into the processing be- fore the next command could be processed. For each detected authentication error the delay time duration is doubled until a maximum value. For the sec- ond way the same procedure as for the first way is started, additionally the TOE is deactivated after a predefined number of detected authentication fail- ures. The reset of the failure counter and delay timer is done with a correct au- thentication process, after predefined time duration or by the TPM owner. The activation of the TPM could be done only by the TPM owner. FIA_AFL.1 Authentication failure handling Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1 The TSF shall detect when ten unsuccessful authentication attempts occur related to authentication attempts for the same user. 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) Two different ways of processing could be started. For the first way logic is activated to add a delay time into the processing before the next command could be processed. For each detected authentication error the delay time duration is doubled until a maximum value. For the sec- ond way the same procedure as for the first way is started, additionally the TOE is deactivated after a predefined number of detected authenti- cation failures. Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 30 of 63 FDP_ACF.1/Deleg Security attribute based access control Hierarchical to: No other components. Dependencies: 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], sec- tion 20.2.1 “Owner Permission Settings” 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 rule: if the TPM command is listed in the table at [6], section 20.2.2 “Owner com- mands not delegated” or the key is listed in the table at [6], section 20.2.4 “Key commands not delegated”, then the command can not be delegated. FDP_ACF.1/KeyMan Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset 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 fol- lowing: Public SLB9635TT1.2/m1566a13 Security Target V1.0 Infineon Technologies AG, Chipcard & Security Page 31 of 63 (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 and disableForceClear of the TOE, (c) User keys with the security attributesauth