Please read the Important Notice and Warnings at the end of this document Revision 1.0 www.infineon.com 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ SLS 32TLC100(M) CIPURSE™ Security Controller V1.2.0 Compliant to OSPT™ Alliance CIPURSE™T Profile Optimized for Contactless Transport & Ticketing Applications ISO/IEC 14443 Type A Contactless Interface Optional Mifare Compatible Interface Resistance to attackers with HIGH attack potential Author: Steffen Heinkel Revision 1.0 as of 2017-01-31 Security Target 2 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) Table of Contents 1 Security Target Introduction (ASE_INT)............................................................................ 4 1.1 Security Target reference........................................................................................................................4 1.2 Target of Evaluation reference ...............................................................................................................4 1.3 TOE overview...........................................................................................................................................4 1.4 TOE description.......................................................................................................................................5 1.4.1 Logical scope of the TOE....................................................................................................................5 1.4.2 Physical scope of the TOE..................................................................................................................6 1.4.3 Interfaces to the TOE..........................................................................................................................8 1.4.4 Lifecycle and delivery.........................................................................................................................8 2 Conformance Claims (ASE_CCL)......................................................................................10 2.1 CC Conformance Claim .........................................................................................................................10 2.2 PP Claim.................................................................................................................................................10 2.3 Package Claim.......................................................................................................................................10 3 Security Problem Definition (ASE_SPD)...........................................................................11 3.1 Assets.....................................................................................................................................................11 3.2 Threats...................................................................................................................................................11 3.3 Organisational Security Policies...........................................................................................................13 3.4 Assumptions about the operational environment ..............................................................................13 4 Security Objectives (ASE_OBJ) .......................................................................................14 4.1 Security Objectives of the environment of the TOE.............................................................................14 4.2 Security Objectives of the TOE..............................................................................................................14 4.3 Security Objectives Rationale...............................................................................................................15 5 Extended Component Definition (ASE_ECD).....................................................................16 6 Security Requirements (ASE_REQ)..................................................................................17 6.1 TOE Security Functional Requirements ...............................................................................................17 6.2 SFRs of this ST .......................................................................................................................................17 6.2.1 SFRs related to access control.........................................................................................................17 6.2.2 SFR related to transaction mechanism...........................................................................................20 6.2.3 SFR related to randomized UID .......................................................................................................20 6.2.4 SFR related to cryptography............................................................................................................20 6.2.5 SFRs related to authentication and secure messaging..................................................................21 6.2.6 SFRs related to key generation and destruction ............................................................................23 6.2.7 CIPURSE™ Access control and security management policy .........................................................24 6.2.8 Session key and secure messaging key generation policy.............................................................25 6.2.9 Session key and secure messaging key destruction policy............................................................25 6.3 Consistency of SFRs...............................................................................................................................25 6.4 Rationale for the Security Functional Requirements ..........................................................................26 6.5 TOE Security Assurance Requirements ................................................................................................27 6.6 Rationale for the Assurance Requirements..........................................................................................28 7 TOE Summary Specification (ASE_TSS) ...........................................................................29 7.1 TOE security features ............................................................................................................................29 8 Statement of compatibility............................................................................................31 8.1 IP_SFR (Irrelevant Platform SFRs) and RP_SFR (Relevant Platform SFRs) of [5]................................31 9 References...................................................................................................................33 10 List of Abbreviations .....................................................................................................34 11 Glossary ......................................................................................................................35 Security Target 3 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) Revision History ............................................................................................................................36 Security Target 4 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) 1 Security Target Introduction (ASE_INT) 1.1 Security Target reference The title of this document is Security Target, Common Criteria EAL5 augmented / EAL5+, SLS 32TLC100(M) CIPURSE™ Security Controller v1.2.0. Its version is Revision 1.0 dated 2017-01-31. 1.2 Target of Evaluation reference The Target of Evaluation (TOE) is a composite based on the platform M7791 B12 and G11 (for details see [5]). The name of the TOE is “SLS 32TLC100(M) CIPURSE™ Security Controller”. It provides a file system oriented operating system. Its version is v1.2.0. This Security Target is compatible to [5] 1.3 TOE overview The TOE provides a file system oriented operating system and is based on the M7791 B12 and G11 security controller by Infineon Technologies AG. Its file system meets [ISO/IEC 7816-4]. The TOE is targeted for contactless ticketing and payment applications compliant to CIPURSE™V2. Different and flexible access rights to application functions and secure messaging rules can be configured for each file. CIPURSE™V2 also defines a protocol, which primarily aims at providing mutual authentication and secure messaging between the TOE and a subject e.g. terminal. Secure messaging allows the protection of integrity and/or confidentiality of the exchanged messages. The major security features of the TOE include: − Supports the creation of applications with up to 8 keys per application, which allows to implement 8 different access levels;128-bit key length for AES encryption − Flexible key management − Flexible access rights and secure messaging rules configurable for each file − Mutual authentication (3-pass as per [ISO/IEC 9798-2]), using AES − Secure messaging based on [ISO/IEC 7816-4], with AES-MAC or AES-encryption − Secure messaging mode configurable for each data exchange − Data exchange protocol inherently DPA and DFA resistant − Sequence integrity protection The TOE is a smartcard device based on the M7791 B12 and G11 hardware and supports contactless I/O communication in [ISO/IEC 14443-4] Type A. The device contains a software part compliant to CIPURSE™V2, which provides a file system according to [ISO/IEC 7816-4] with flexible access rights, a mutual authentication method (3-pass as per [ISO/IEC 9798-2]) using AES with a terminal and secure messaging for integrity and confidentiality (AES-MAC or AES-encryption). Optionally the product provides a Mifare compatible system in addition. The Mifare compatible system is part of the firmware of the underlying platform and does not contribute to the security features of the TOE. The TOE is connected to a terminal via contactless interface providing both energy for operation and data exchange. The terminal is application specific and may be either connected to a host system (online terminal) or work standalone (offline terminal). After anti-collision and selection as per [ISO/IEC 14443-3], the terminal may either enter Mifare compatible emulation or [ISO/IEC 14443-4] transmission protocol to transmit e.g. CIPURSE™V2 compatible commands to the TOE. Security Target 5 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) 1.4 TOE description 1.4.1 Logical scope of the TOE Figure 1 provides an overview of the TOE’s logical components: Figure 1 TOE logical components overview The TOE is a smartcard device based on the M7791 B12 respectively M7791 G11 hardware (dark blue rectangle) and supports contactless I/O communication in [ISO/IEC 14443-4] Type A. The device contains a software part compliant to CIPURSE™V2, which provides a file system according to [ISO/IEC 7816-4] with flexible key management, flexible access rights, a mutual authentication method (3-pass as per [ISO/IEC 9798-2]) using AES with a terminal and secure messaging for integrity and confidentiality (AES-MAC or AES-encryption). If the authentication process is requested by a terminal the TOE provides two high quality random numbers derived from the platform’s physical random number generator as challenge to the external subject. First random number and a key known to an authorized user are used to derive the session key and encrypt the second number provided by the TOE. The result is send back to the TOE, which validates the terminal’s authenticity. The TOE provides the ability to define a minimum secure messaging requirement for each application and file inside the TOE’s file system. The secure messaging requirements consist of the levels: no protection, integrity protection using AES-MAC, confidentiality protection using AES encryption and no access. The secure messaging requirements are defined as Secure Messaging Rules for predefined groups of commands for each Application and elementary file. For each single data exchange a secure messaging mode equal to or above the defined minimum security messaging requirement can be configured. For further information about the Secure Messaging Rules please see [6] chapter 4.2.3. The usage of high quality random numbers, the session key derivation mechanism and a unique use of each frame key secure the TOE against DPA and DFA attacks. The access control mechanism is based on up to 8 keys for each application. The access rules defined for each application and each underlying elementary file specify which operation is allowed for a user authenticated Security Target 6 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) using one of the keys. The access rights are defined in Access Rights Tables (ART) for each key and file. For further information about the Access Rights Tables please see [6] chapter 4.2.2. The TOE provides a rollback mechanism which allows a user to group commands to a transaction. The commands, which modify elementary files or directory files can be reversed or rolled back in case the transaction did not complete. This means, that either all changes to the data of the file system are reflected or none. The CIPURSE™V2 file system based operating system further provides commands and features particularly for personalisation and administration. The command set for application operation complies with [ISO/IEC 7816-4] and [ISO/IEC 7816-9], completed with proprietary coded commands in [ISO/IEC 7816-4] APDU format. The product may also contain a Mifare compatible system to support migration to CIPURSE™V2 (dark grey area). Whether the Mifare compatible system is part of the product and whether 1k or 4k functionality is provided is an ordering option. In case the Mifare compatible system is part of the product, the external subject communicating with TOE decides during the startup phase of the TOE, whether the CIPURSE™V2 file system based operating system or the Mifare compatible system is started. The Mifare compatible system does not provide any TSF. Neither does it interfere with any of the TSF provided by the TOE. Logically all TSF of the TOE belong to the white area. Please note the Mifare compatible system is part of the firmware of the underlying platform and that it is not in scope of this evaluation. Concerning the no-traceability of the TOE the TOE provides a functionality to prevent external subjects (e.g. terminals operated by attackers) to trace and localize the individual TOE. The TOE can be configured such, that a randomized UID is provided during the anti-collision procedure instead of a fixed UID. 1.4.2 Physical scope of the TOE The TOE consists of a hardware part, firmware part, software part and the user guidance. The hardware and firmware parts (M7791 B12 respectively M7791 G11) are described in [5]. Table 1 describes the platform configuration used for this TOE. Table 1 Platform configuration Module / Feature Values Hardware Platform M7791 B12 M7791 G11 Memories SOLID FLASH™ 100 kBytes RAM for the user 4 kBytes Modules µSCP Available Interfaces RFI – ISO 14443 generally Available RFI Input Capacity 27pF (SLE 77CLF1001PM), 56pF (SLE 77CLF1007PM), 78pF (SLE 77CLF100APM) ISO 14443 Type A card mode Available Security Target 7 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) Module / Feature Values ISO 14443 Type B card mode Available ISO 14443 Type C card mode1 Available Advanced Communication Mode Available/unavailable Mifare compatible availability Available Mifare compatible Hardware support card mode Available Advanced Mode for Mifare-Compatible Technology (AMM) Available/unavailable SW support for Mifare compatible 4k cards Available SW support for Mifare compatible 1k cards Available Direct data transfer (DDT) Available/unavailable 4 byte UID Available 7 byte UID Available Miscellaneous Maximum System Frequency 33MHz to 45MHz Metal configuration number 0x0 Used Firmware with identifier V77.014.11.2 1.4.2.1 Software of the TOE The software uses the hardware and the firmware as platform. It is stored on the hardware NVM and builds the file system based operating system. Its version is v1.2.0. 1.4.2.2 User guidance The user guidance comprises: − CIPURSE™Security Controller, SLS 32TLC100(M), Data Book, Revision 1.1, 2015-09-24 This document is a description of the SLS 32TLC100(M) CIPURSE™ Security Controller. − CIPURSE™V2 Operation and Interface Specification, Revision 2.0, 2013-12-20 This document specifies the feature set available to all members of the CIPURSE™V2 family. − CIPURSE™V2 Operation and Interface Specification R2.0 Errata and Precision List, Revision 1.0, 2014-09-18 This document specifies the Errata and Precisions for CIPURSE™V2 Operation and Interface Specification. − CIPURSE™V2 CIPURSE™ T Profile Specification, Revision 2.0, 2013-12-20 This document focuses on the application level, personalization and administration features that shall be supported by a CIPURSE™T PICC. − CIPURSE™V2 CIPURSE™ T Profile Specification R2.0 Errata and Precision List, Revision 1.0, 2014- 09-18 This document specifies the Errata and Precisions for CIPURSE™V2 T Profile Specification. − CIPURSE™V2 Cryptographic Protocol, Revision 1.0, 2012-09-28 This document specifies the cryptographic mechanisms of cards (i.e. PICCs) and terminals (i.e. PCDs) compliant to this CIPURSE™ specification. 1 Also known as ISO 18092 (card mode) Security Target 8 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) − CIPURSE™V2 Cryptographic Protocol R1.0 Errata and Precision List, Revision 1.0, 2014-09-18 This document specifies the Errata and Precisions for The CIPURSE™V2 CIPURSE™ Cryptographic Protocol. − CIPURSE™Security Controller, SLS 32TLC100(M), Personalization Manual, Revision 1.0, 2015-01-25 This document provides information to developers to ease personalization of SLS 32TLC100(M) devices. − CIPURSE™ PICC, Chip Identification Guide, V1.1, 2016-07-08 This document provides guidance, how to identify the platform of the TOE. − CIPURSE™Security Controller, SLS 32TLC100(M) V1.2.0, Release Notes, Revision 1.0, 2017-01-19 This document provides a summary of product key features and operational hints to the user. 1.4.3 Interfaces to the TOE − The physical interface of the TOE to the external environment is the entire surface of the IC. − The RF interface (radio frequency power and signal interface) enables contactless communication between a PICC (proximity integration chip card, PICC) and a terminal reader/writer (proximity coupling device, terminal). The transmission protocol meets [ISO/IEC 14443-4]. Commands for RF initialisation and bit frame anti-collision meet [ISO/IEC 14443-3] and [ISO/IEC 14443-4] type A. − The command interface to the TOE is provided by the CIPURSE™ operating system. 1.4.4 Lifecycle and delivery The lifecycle of the TOE consists of 4 phases 1.4.4.1 Phase 1: Development This phase includes the development of IC, firmware and software. 1.4.4.2 Phase 2: Manufacturing This phase includes the production of the IC containing firmware and software. It may also include dicing, packaging and antenna mounting, however these processes are optional. The TOE can be delivered in the form of complete modules, as plain wafers, in an IC case (e.g. DSO20) or in bare dies. 1.4.4.3 Phase 3: Personalization The personalization process contains 2 sub-stages as follows: 1. Personalization of MF and predefined files under the MF 2. Personalization of other initialisation data: this includes e.g. configuration of access rights, secure messaging rules, file content and AES keys. This sub stage prepares the TOE for operational use by consumers. It may overlap with phase 4, e.g. the TOE’s personalization phase might be finished during its operational use. 1.4.4.4 Phase 4: Operational use Subjects within the TOEs environment can make use of the TOE depending on the TOE´s configuration and the subjects’ authority. The TOE in this phase contains relevant and integrity and/or confidentiality protected file content. Security Target 9 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Target Introduction (ASE_INT) 1.4.4.5 Delivery of the TOE The TOE is delivered after sub-stage 1 of phase 3. Phase 3 sub-stage 2 and phase 4 are not part of this evaluation process. 1.4.4.6 Lifecycle roles There are three roles during the lifecycle: Producer, Personalization Agent and User. The producer covers phase 1 and 2 and is Infineon Technologies AG. The Personalization Agent covers phase 3. The user may be any subject, who makes use of the TOE within its operational environment (e.g. system administrator, consumer). Security Target 10 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Conformance Claims (ASE_CCL) 2 Conformance Claims (ASE_CCL) 2.1 CC Conformance Claim The Security Target and the TOE is Common Criteria version v3.1 part 2 [3] conformant and Common Criteria version v3.1 part 3 [4] conformant 2.2 PP Claim This TOE is a composite based on M7791 B12 and M7791 G11. The Security Target of the Hardware [5] is in strict conformance to the Security IC Platform Protection Profile [1]. The current ST has no conformance to any PP. 2.3 Package Claim The assurance level for the TOE is EAL5 augmented with the components ALC_DVS.2 and AVA_VAN.5 Security Target 11 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Problem Definition (ASE_SPD) 3 Security Problem Definition (ASE_SPD) 3.1 Assets The table as follows provides an overview of the assets to be protected: Table 2 Assets of the TOE and their protection level Protection kind Assets Integrity Confidentiality Keys X X Security attributes X - Security services X - System file content X1 X1 User file content X2 X2 UID - X3 The keys include the authentication keys, session keys and frame keys used for secure messaging. The security attributes consist of: − The key security attributes for the authentication keys, which define the rights for updating the key. − The access rights assignments, which assign the right to execute particular commands to a dedicated set of authentication keys. − The secure messaging rules, which define the communication security levels for transferring data between an external subject and TOE. The Security Services include: − Secure messaging − Access rights protection and Secure Messaging rules enforcement − Mutual authentication − Consistent Transaction Mechanism 3.2 Threats The TOE faces threats as follows: T.Access Unallowed execution of commands and unallowed access of assets Adverse action: − Bypassing or manipulating access control. Threat agent: 1 Security services enable the system provider to protect file content. It’s up to the system provider to decide, which system file content to protect. 2 Security services enable the user to protect file content. It’s up to the user to decide, which user file content to protect. 3 A security service allows a user to hide the UID during a transaction. Security Target 12 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Problem Definition (ASE_SPD) − Attacker with attack potential high Targeted asset: − All assets T.Access_UID Access UID by non authorized terminals to link and trace user sessions Adverse action: − Non authenticated terminals link user sessions to specific TOE users via UID. Threat agent: − Attacker with attack potential high Targeted asset: − UID T.Forge-Auth An attacker may try to forge authentication data to obtain unallowed authorization Adverse action: − Obtain unallowed security user role by forging authentication data or manipulating the authentication mechanism. Threat agent: − Attacker with attack potential high Targeted asset: − All assets T.Hijack-Session An attacker may hijack an authorized session of a subject e.g. by a man-in-the-middle or replay attack. Adverse action: − Hijack an existing authorized session to obtain a security user role without having to present authentication data Threat agent: − Attacker with attack potential high Targeted asset: − All assets Security Target 13 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Problem Definition (ASE_SPD) T.Tearing An attacker may try to create an inconsistent state within the TOE to compromise an asset Adverse action: − Interrupt power supply of the TOE to create an inconsistent state within the TOE. E.g. an attacker may try to interrupt during a memory write operation in order to manipulate its content. Threat agent: − Attacker with attack potential high Targeted asset: − All assets 3.3 Organisational Security Policies There are no organisational security policies defined for this TOE. 3.4 Assumptions about the operational environment Due to the authentication process with an external subject (terminal), two assumptions are necessary for this TOE: A.Secure-Authentication-Data CIPURSE™ relies on confidential keys for authentication purposes, which need to be generated externally and downloaded to the TOE. During this process the operational environment is responsible to keep these keys confidential. These keys are used to derive session keys on the TOE. A.Terminal-Support The terminal ensures integrity and confidentiality. The terminal verifies data (e.g. authentication data, MAC) sent by the TOE and follows the minimum communication security level defined by the TOE to ensure integrity and confidentiality of the transferred data. Security Target 14 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Objectives (ASE_OBJ) 4 Security Objectives (ASE_OBJ) 4.1 Security Objectives of the environment of the TOE Due to the assumptions of the TOE, environmental objectives are defined as follows: OE.Secure-Authentication-Data Generation of secure authentication data Secure and confidential keys for authentication purposes shall be generated by the environment. These values are then personalised onto the TOE during lifecycle phase 3. OE.Terminal-Support Integrity and confidentiality of data exchanged The terminal shall verify data (e.g. authentication data, MAC) sent by the TOE and follow the minimum communication security level defined by the TOE to ensure integrity and confidentiality of transferred data. 4.2 Security Objectives of the TOE The TOE security objectives are defined as follows: O.Access-Control The TOE shall provide a mechanism to restrict access to user data, security attributes and authentication keys to dedicated subjects. O.Authentication The TOE shall provide a mechanism to differentiate between authorised and non-authorised subjects and also to allow a dedicated attribution of access rights to authorised subjects. Further the TOE shall provide verification data to allow external subjects to validate the authenticity of the TOE. O.Confidentiality The TOE shall provide a functionality to exchange confidential messages by means of encryption via the communication interface. Security attributes shall allow enforcing the encryption of certain messages. O.Integrity The TOE shall provide a functionality to exchange integrity protected messages via the communication interface. Therefore the TOE shall send verification data to the recipient in order for the recipient to check its integrity. O.Rollback-Buffer Security Target 15 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Objectives (ASE_OBJ) The TOE shall provide a functionality to cluster commands to a tearing safe transaction, which means, that in case a tearing has occurred or the transaction has been cancelled, either the file system reflects all the changes or none of these changes are reflected. O.No-Trace The TOE shall offer a configuration option, which does not allow user traceability by a “none” authorised subject in case the CIPURSE™V2 file system based operating system is activated during startup. 4.3 Security Objectives Rationale The security objectives rationale from [1] and [5] are also applicable to this ST. Table 3 provides a mapping of the additional threats and policies to the objectives of the TOE. The rationale explains how the objectives cover the threat or policy. Table 3 Security Objectives mapping and rationale Threat/Policy/Assumption Security Objective Rationale T.Access O.Access-Control O.Confidentiality O.Integrity O.Authentication O.Access-Control uses the outcome of the authentication process to limit accessibility. O.Confidentiality and O.Integrity protect the communication between terminal and TOE. O.Authentication provides access to functions to authorized users. T.Access_UID O.No-Trace O.No-Trace hides the UID. T.Forge-Auth O.Authentication Definition of O.Authentication directly upholds this threat. T.Hijack-Session O.Authentication O.Confidentiality O.Integrity O.Authentication requests resistance against man-in-the- middle and replay attacks. O.Confidentiality and O.Integrity protect the communication between the terminal and the TOE. T.Tearing O.Rollback-Buffer O.Rollback-Buffer allows clustering commands to a tearing safe transaction. A.Secure-Authentication-Data OE.Secure-Authentication-Data Objective directly upholds assumption. A.Terminal-Support OE.Terminal-Support Objective directly upholds assumption. Security Target 16 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Extended Component Definition (ASE_ECD) 5 Extended Component Definition (ASE_ECD) There are no extended components defined for this TOE. Security Target 17 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) 6 Security Requirements (ASE_REQ) 6.1 TOE Security Functional Requirements The security functional requirements (SFR) for this TOE are defined in this chapter. Table 4 lists all SFRs used for this TOE and refinements, if available: Table 4 TOE SFRs TOE SFR Refinement FMT_SMR.1 Not refined FMT_SMF.1/CIPURSE Not refined FMT_MSA.1/CIPURSE Not refined FMT_MSA.3/CIPURSE Not refined FDP_ACF.1/CIPURSE Not refined FDP_ACC.1/CIPURSE Not refined FDP_ROL.1 Not refined FIA_UID.2 Not refined FIA_UAU.2 Not refined FIA_UAU.3 Not refined FIA_UAU.5 Not refined FPR_UNL.1 Not refined FPT_RPL.1 Not refined FTP_TRP.1 Not refined FCS_COP.1/CIPURSE/AES Not refined FCS_CKM.4 Not refined FCS_CKM.1 Not refined There are no refinements available. 6.2 SFRs of this ST The software part of this composite TOE provides additional functionality compared to [5]. Therefore an iteration operation (see [2] section 8.1.1 “The iteration operation”) is used on several SFRs, which are already selected and assigned in either [1] or [5]. All iterations within this ST are uniquely identified using the naming convention “/CIPURSE”. 6.2.1 SFRs related to access control The TOE shall meet the requirement “Security roles (FMT_SMR.1)” as specified below: FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification FMT_SMR.1.1 The TSF shall maintain the roles Security Target 18 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ)  Keyx_ARTy: Each Key x of each access right assignment y defines a security role with dedicated access rights;  NonAuth: This role refers to a non-authenticated user; FMT_SMR.1.2 The TSF shall be able to associate users with roles. The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1/CIPURSE)” as specified below: FMT_SMF.1/CIPURSE Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies FMT_SMF.1.1/CIPURSE The TSF shall be capable of performing the following management functions:  TSF data management: Changing authentication keys;  Security attribute management: Changing key security attributes, secure messaging rules and access right assignments; The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1/CIPURSE)” as specified below: FMT_MSA.1/CIPURSE Management of security attributes Hierarchical to: No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FMT_MSA.1.1/CIPURSE The TSF shall enforce the “CIPURSE™ Access control and security management policy” (see chapter 6.2.7) to restrict the ability to modify the security attributes all security attributes to any role. The TOE shall meet the requirement “Static attribute initialization (FMT_MSA.3/CIPURSE)” as specified below: FMT_MSA.3/CIPURSE Static attribute initialisation Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1/CIPURSE The TSF shall enforce the “CIPURSE™ Access control and security management policy” (see chapter 6.2.7) to provide  ART: permissive for MF and read/modify for EF.IO_CONFIG and read only for all other predefined EFs  key security attributes: permissive Security Target 19 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ)  SMRs: SM_PLAIN for Command and Response SM-APDU for MF and all predefined EFs default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/CIPURSE The TSF shall allow the1 no role to specify alternative initial values to override the default values when an object or information is created. Note: The only security attributes with default or initial values are the ones for the predefined files including MF. For all other security attributes explicit initial values have to be provided by the external subject during their creation. The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1/CIPURSE)” as specified below: FDP_ACF.1/CIPURSE 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/CIPURSE The TSF shall enforce the “CIPURSE™ Access control and security management policy” (see chapter 6.2.7) to objects based on the following:  access rights assignment FDP_ACF.1.2/CIPURSE The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed:  allowance exists, if an object´s corresponding security attribute “access rights assignment” grants a subject’s identity to perform the targeted operation. FDP_ACF.1.3/CIPURSE The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/CIPURSE The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. Note: Objects of the TOE are card toplevel, application and elementary file. Card toplevel, application and elementary file objects can only be accessed using commands provided by this TOE. Subject in this context refers to the terminal. The TOE shall meet the requirement “Subset access control (FDP_ACC.1/CIPURSE)” as specified below: FDP_ACC.1/CIPURSE Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control 1 the should be the Security Target 20 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) FDP_ACC.1.1/CIPURSE The TSF shall enforce the “CIPURSE™ Access control and security management policy” (see chapter 6.2.7) on all subjects, objects and security attributes. 6.2.2 SFR related to transaction mechanism The TOE shall meet the requirement “Basic rollback (FDP_ROL.1)” as specified below: FDP_ROL.1 Basic rollback Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_ROL.1.1 The TSF shall enforce “CIPURSE™ Access control and security management policy” (see chapter 6.2.7) for the commands, which are combined to form a transaction in order to permit the rollback of the modifications of the transaction on the  elementary files (EF)  directory files (DF) FDP_ROL.1.2 The TSF shall permit operations to be rolled back within the limited number of u updates and n bytes to be modified1 . 6.2.3 SFR related to randomized UID The TOE shall meet the requirement “Unlinkability (FPR_UNL.1)” as specified below: FPR_UNL.1 Unlinkability Hierarchical to: No other components. Dependencies: No dependencies. FPR_UNL.1.1 The TSF shall ensure that non-authorized subjects are unable to determine whether any operation of the TOE were caused by the same user. Note: The enforcement of this SFR is dependent of the TOE configuration and in responsibility of a customer. This SFR is only enforced, if random UID is configured for the TOE. 6.2.4 SFR related to cryptography Preface regarding Security Level related to Cryptography The strength of the cryptographic algorithms was not rated in the course of the product certification (see [11] Section 9, Para.4, Clause 2). But Cryptographic Functionalities with a security level of lower than 100 bits can no longer be regarded as secure without considering the application context. Therefore for these functionalities it shall be checked whether the related crypto operations are appropriate for the intended system. Some further hints and guidelines can be derived from the 'Technische Richtlinie BSI TR-02102', www.bsi.bund.de. Any Cryptographic Functionality that is marked in column 'Security Level above 100 Bits' of the following table with 'No' achieves a security level of lower than 100 Bits (in general context). 1 u and n are defined in [8] section 5.1.1 “Structure“ Security Target 21 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) Table 5 TOE cryptographic functionality Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Security level above 100 Bits Session key agreement AES [7], section 5.3 "Session Key Derivation and Authentication Algorithm" |KID| = 128 Yes Authentication AES [7], section 5.3 "Session Key Derivation and Authentication Algorithm" and [7], section 6.3 "Integrity Protection" |K| = 128 Yes Secure Messaging for Integrity MAC based on AES [7], section 6.3 "Integrity Protection" |K| = 128 No Secure Messaging for Confidentiality AES [7], section 6.4 "Confidential Communication" |K| = 128 Yes The AES operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below: FCS_COP.1/CIPURSE/AES 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/CIPURSE/AES The TSF shall perform encryption and decryption in accordance to a specified cryptographic algorithm Advanced Encryption Standard (AES) and cryptographic key sizes of 128 bit that meet the following:  U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory (ITL),  Advanced Encryption Standard (AES), FIPS PUB 197, modes of usage: [7] section 5.2 “Session Key Derivation”, [7] section 6.2 “Key Derivation for the first Frame”, [7] section 6.3 “Integrity Protection” and [7] section 6.4 “Confidential Communication”. 6.2.5 SFRs related to authentication and secure messaging The TOE shall meet the requirement “User identification before any action (FIA_UID.2)” as specified below: FIA_UID.2 User identification before any action Hierarchical to: FIA_UID.1 Timing of identification Security Target 22 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) Dependencies: No dependencies. FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of the user. Note: “None” authentication is also an authentication method. Identification in this context means determining the user’s role. The TOE shall meet the requirement “User authentication before any action (FIA_UAU.2)” as specified below: FIA_UAU.2 User authentication before any action Hierarchical to: FIA_UAU.1 Timing of authentication Dependencies: FIA_UID.1 Timing of identification. FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Note: “None” authentication is also an authentication method. The TOE shall meet the requirement “Unforgeable authentication (FIA_UAU.3)” as specified below: FIA_UAU.3 Unforgeable authentication Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.3.1 The TSF shall detect and prevent use of authentication data that has been forged by any user of the TSF. FIA_UAU.3.2 The TSF shall detect and prevent use of authentication data that has been copied from any other user of the TSF. The TOE shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)” as specified below: FIA_UAU.5 Multiple authentication mechanism Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1 The TSF shall provide none, three-way cryptographic authentication protocol to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the rules described below:  None: Any subject, which does not go through an explicit authentication protocol, is authenticated to have access to commands clustered in ACGs with the flag “ALWAYS” for MF, secured ADFs and EFs and some dedicated Security Target 23 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) further commands1 . In case of unsecured ADFs or EFs, there are no access restrictions.  Three-way cryptographic authentication protocol: three-way challenge- and-response protocol, cf [ISO9798], Part 2 section 5.2.2 “Three pass authentication”, and [7] section 5 “Authentication” The TOE shall meet the requirement “Replay detection (FPT_RPL.1)” as specified below: FPT_RPL.1 Replay detection Hierarchical to: No other components. Dependencies: No dependencies. FPT_RPL.1.1 The TSF shall detect replay for the following entities:  three way cryptographic authentication,  secure messaging for integrity and confidentiality. FPT_RPL.1.2 The TSF shall perform output of failure and rejection to enter security state2 when replay is detected. The TOE shall meet the requirement “Trusted Path (FTP_TRP.1)” as specified below: FTP_TRP.1 Trusted Path Hierarchical to: No other components. Dependencies: No dependencies. FTP_TRP.1.1 The TSF shall provide a communication path between itself and remote users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and/or modification. FTP_TRP.1.2 The TSF shall permit remote users to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for data exchanges between external subject and TOE according to “CIPURSE™ Access control and security management policy” (see chapter 6.2.7) based on the security attribute “Secure messaging rules” 6.2.6 SFRs related to key generation and destruction The TOE shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” as specified below: FCS_CKM.1 Cryptographic key generation Hierarchical to: No other components. 1 SELECT, GET_CHALLENGE, MUTUAL_AUTHENTICATE 2 A security state of the TOE is entered by successful authentication terminal to TOE with a valid key. Security Target 24 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) Dependencies: [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 Session key and secure messaging key generation policy (see chapter 6.2.8) and specified cryptographic key sizes 128 Bit that meet the following:  CIPURSE™ Cryptographic Protocol [7] The TOE shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as specified below: 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 cryptographic key destruction method Session key and secure messaging key destruction policy (see chapter 6.2.9) that meets the following: None. 6.2.7 CIPURSE™ Access control and security management policy 6.2.7.1 Objects Objects of the TOE are card toplevel, application and elementary file. Card toplevel, application and elementary file objects can only be accessed using commands provided by this TOE. 6.2.7.2 Security attributes CIPURSE™ access control is based on the security attributes − Access rights assignment − Key security attributes − Secure messaging rules Security attributes exist on three different levels: card toplevel, application level and elementary file level. 6.2.7.3 Mutual Authentication A security state is entered by a successful three-way challenge-and-response protocol between an external subject and TOE with a valid key. By this, the external subject acquires the right to execute all commands on objects that are restricted to exactly this authentication key, as given in the access rights assignment (see section 6.2.7.4). The security state is linked to exactly one key and one application or card top-level. Mutual authentication is done by virtue of a three-way challenge-and-response protocol plus verification by the terminal of a MAC’ed PICC response. Both TOE and external subject are in the possession of a common secret kID, from which another commonly known temporary secret k0 is dynamically derived. k0 is different in Security Target 25 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) each session, hence it is called the session key. It is then used as an AES key for encrypting random values that are passed between the two parties. The responses to the random challenges are verified by the two parties, followed by an acceptance or rejection of the terminal by the PICC. An acceptance or rejection of the PICC by the terminal is completed once a MAC’ed PICC response is verified by the terminal. 6.2.7.4 Access rights assignment See [6] section 4.2.2 “Access rights assignment”. 6.2.7.5 Key security attributes See [6] section 4.2.1 “Keys”. 6.2.7.6 Secure Messaging Rules See [6] section 4.2 “Security Architecture”, See [6] section 4.2.3 “General Secure Messaging Rules”, See [6] section 4.2.4 “Object-specific Secure Messaging Rules” 6.2.8 Session key and secure messaging key generation policy See [7] section 5.2 “Session Key Derivation”, See [7] section 5.3 “Session Key Derivation and Authentication Algorithm” See [7] section 6.2 “Key Derivation for the first Frame” See [7] section 6.3 “Integrity Protection” See [7] section 6.4 “Confidential Communication” 6.2.9 Session key and secure messaging key destruction policy The session key K0 is destroyed after the first frame key k1 is generated by memory overwrite with a 128-bit random value. All secure messaging keys are destroyed after they have been used by memory overwrite with a 128-bit random value. Each 128-bit random value used for key destruction is only used once. 6.3 Consistency of SFRs Following table lists the dependencies of SFRs and shows, that all SFRs are met within this ST. Table 6 Dependencies of SFRs SFRs Dependencies Met by FMT_SMR.1 FIA_UID.1 FIA_UID.2 FMT_SMF.1/CIPURSE none - FMT_MSA.1/CIPURSE [FDP_ACC.1 or FDP_IFC.1] FMT_SMF.1 FMT_SMR.1 FDP_ACC.1/CIPURSE FMT_SMF.1/CIPURSE FMT_SMR.1 FMT_MSA.3/CIPURSE FMT_MSA.1 FMT_MSA.1/CIPURSE Security Target 26 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) SFRs Dependencies Met by FMT_SMR.1 FMT_SMR.1 FDP_ACF.1/CIPURSE FDP_ACC.1 FMT_MSA.3 FDP_ACC.1/CIPURSE FMT_MSA.3/CIPURSE FDP_ACC.1/CIPURSE FDP_ACF.1 FDP_ACF.1/CIPURSE FDP_ROL.1 [FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1/CIPURSE FPR_UNL.1 none - FCS_COP.1/CIPURSE/AES [FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2], FCS_CKM.4 FCS_CKM.1, FCS_CKM.4 FIA_UID.2 none - FIA_UAU.2 FIA_UID.1 FIA_UID.2 FIA_UAU.3 none - FIA_UAU.5 none - FPT_RPL.1 none - FTP_TRP.1 none - FCS_CKM.4 [FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2]] FCS_CKM.1 FCS_CKM.1 [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_COP.1/CIPURSE/AES FCS_CKM.4 6.4 Rationale for the Security Functional Requirements Following table provides a mapping between objectives and SFRs: Table 7 Mapping of SFRs to security objectives Security objectives SFRs O.Access-Control FMT_SMR.1: access rights are based on security roles FMT_MSA.1/CIPURSE: access to security attributes is restricted FMT_MAS.3/CIPURSE: definition of initial values for security attributes FDP_ACF.1/CIPURSE: access rights are based on security attributes FDP_ACC.1/CIPURSE: scope of access control FMT_SMF.1/CIPURSE: Specification of Management Functions O.Authentication FCS_COP.1/CIPURSE/AES: cryptographic algorithm AES used for authentication FCS_CKM.1: derived session key is used for authentication FIA_UID.2, FIA_UAU.2: User identification and authentication required before any action FIA_UAU.3: authentication must be unforgeable FIA_UAU.5: multiple authentication mechanism supported FTP_TRP.1: trusted path enables integrity protected messaging FMT_SMR.1: allows association of users to roles O.Confidentiality FCS_COP.1/CIPURSE/AES: cryptographic algorithm AES used for secure messaging for confidentiality Security Target 27 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) Security objectives SFRs FPT_RPL.1: requirement to detect replay attacks FTP_TRP.1: trusted path enables confidential messaging FCS_CKM.1: appropriate key generation required for trusted path FCS_CKM.4: appropriate key destruction required for trusted path O.Integrity FCS_COP.1/CIPURSE/AES: cryptographic algorithm AES used for secure messaging for integrity FPT_RPL.1: requirement to detect replay attacks FTP_TRP.1: trusted path enables integrity protected messaging FCS_CKM.1: appropriate key generation required for trusted path FCS_CKM.4: appropriate key destruction required for trusted path O.Rollback-Buffer FDP_ROL.1: rollback buffer requirement upholds objective directly O.No-Trace FPR_UNL.1: prevents linking different sessions to the same TOE user by non- authorized subjects 6.5 TOE Security Assurance Requirements Table 8 lists the TOE’s assurance requirements. None of the assurance requirements is refined: Table 8 TOE assurance requirements Aspect Acronym Description Development ADV_ARC.1 Security Architecture Description ADV_FSP.5 Complete semi-formal functional specification with additional error information ADV_IMP.1 Implementation representation of the TSF ADV_INT.2 Well-structured internals ADV_TDS.4 Semi-formal modular design Guidance Documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Life-Cycle Support ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMS.5 Development tools CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.2 Sufficiency of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.2 Compliance with implementation standards Security Target Evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification Security Target 28 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Security Requirements (ASE_REQ) Aspect Acronym Description Tests ATE_COV.2 Analysis of coverage ATE_DPT.3 Testing: modular design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample Vulnerability Assessment AVA_VAN.5 Advanced methodical vulnerability analysis 6.6 Rationale for the Assurance Requirements The assurance level EAL5 and the augmentation with the requirements ALC_DVS.2, and AVA_VAN.5 were chosen in order to meet assurance expectations explained in the following paragraph. An assurance level of EAL5 with the augmentations AVA_VAN.5 and ALC_DVS.2 are required for this type of TOE since it is intended to defend against sophisticated attacks. All threat agents in chapter 3.2 are attackers with attack potential high. This evaluation assurance package was selected for a card issuer to gain maximum assurance from positive security engineering based on good commercial practices. Security Target 29 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ TOE Summary Specification (ASE_TSS) 7 TOE Summary Specification (ASE_TSS) The Security Features of the TOE are described below and the relation to the security functional requirements is shown. 7.1 TOE security features SF.Authenticate The TOE provides a Three-way cryptographic challenge-and-response mechanism according to [ISO9798-2] and [7]. After successfully performing this challenge-and-response mechanism the TOE enters an authenticated state. During the authentication a session key is generated by the TOE, which is used to subsequently derive the initial key for secure messaging activities. The authentication is finished, once a MAC’ed response of the PICC is verified by the terminal. A authentication process allows the TOE to determine the user`s role. SF.SM The TOE supports secure messaging for integrity and confidentiality with AES-MAC and AES-encryption based on [ISO/IEC 7816-4], using standardised secure messaging APDU format (denoted as SM-APDU format, specified in [7]). SF.Access The TOE provides flexible access rights and secure messaging rules for each file. Up to 8 keys can be configured per application. Chapter 6.2.7 provides more information. SF.Rollback The TOE provides a mechanism to group commands to a transaction. The commands, which modify elementary files or directory files can be reversed or rolled back in case the transaction did not complete. This means, that either all changes to the data of the file system are reflected or none. Therefore the TOE provisionally stores intermediate results of a transaction. SF.NoTrace According to [ISO/IEC 14443-3], during anti-collision the UID can be retrieved. The TOE can be configured such, that a randomized UID is provided instead of a fixed UID. This feature prevents external subjects (e.g. terminals operated by attackers) to trace and localize individual TOEs. Table 9 provides a mapping between SFs and SFRs: Table 9 Mapping of SFRs to TOE security features SFR SF FMT_SMR.1 SF.Access, SF.Authenticate FMT_SMF.1/CIPURSE SF.Access FMT_MSA.1/CIPURSE SF.Access FMT_MSA.3/CIPURSE SF.Access FDP_ACF.1/CIPURSE SF.Access FDP_ACC.1/CIPURSE SF.Access FIA_UID.2 SF.Authenticate FIA_UAU.2 SF.Authenticate Security Target 30 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ TOE Summary Specification (ASE_TSS) SFR SF FIA_UAU.3 SF.Authenticate FIA_UAU.5 SF.Authenticate FPT_RPL.1 SF.SM, SF.Authenticate FTP_TRP.1 SF.SM FCS_CKM.1 SF.SM, SF.Authenticate FCS_CKM.4 SF.SM FDP_ROL.1 SF.Rollback FPR_UNL.1 SF.NoTrace FCS_COP.1/CIPURSE/AES SF.SM, SF.Authenticate All SFRs are mapped by SFs. The justification for the SFRs of this TOE to SFs is as follows: The SFRs FMT_SMR.1, FMT_SMF.1/CIPURSE, FMT_MSA.1/CIPURSE, FMT_MSA.3/CIPURSE, FDP_ACF.1/CIPURSE and FDP_ACC.1/CIPURSE deal with access rights, roles and management of security attributes and are therefore mapped to SF.Access. Successful replay (FPT_RPL.1) is prevented by the CIPURSE™ secure messaging protocol (SF.SM) with changing frame keys. The CIPURSE™ secure messaging protocol (SF.SM) meets the SFR of a trusted path (FTP_TRP.1). The cryptographic algorithm used for secure messaging is AES, therefore FCS_COP.1/CIPURSE/AES, FCS_CKM.1 and FCS_CKM.4 are also mapped to SF.SM. The family FIA_UAU sets requirements for user authentication. Therefore its components (FIA_UAU.2, FIA_UAU.3, FIA_UAU.5) used for this ST are all mapped to SF.Authenticate. Successful replay (FPT_RPL.1) during the CIPURSE™ authentication process is prevented by using a challenge and response protocol based on random numbers. The cryptographic algorithm used is AES, therefore FCS_COP.1/CIPURSE/AES and FCS_CKM.1 are also mapped to SF.Authenticate. Authentication is required to determine the subject´s role. No authentication is defined here as an implicit kind of authentication and casts the user´s role “none”. Therefore the CIPURSE™ authentication process meets the SFRs FIA_UID.2 and FMT_SMR.1. SF.Rollback meets the requirements of a basic rollback buffer FDP_ROL.1. SF.NoTrace allows to use random instead of fixed UID, which prevents to trace the TOE across sessions. FPR_UNL.1 requires to ensure that none authorized subjects are unable to determine whether any operation of the TOE were caused by the same user. New random UID is chosen for each session preventing such user traceability. Security Target 31 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Statement of compatibility 8 Statement of compatibility The TOE indirectly depends on following platform TSFs from [5] to meet its additional SFR requirements: SF_DPM, SF_PS, SF_PMA, SF_PLA and SF_CS. Table 10 provides a mapping of additional TOE SFRs and indirect contribution of platform TSFs: Table 10 Indirect contribution of platform TSFs Additional TOE SFRs Contribution of FMT_SMR.1 SF_PMA, SF_PLA, SF_DPM FMT_SMF.1/CIPURSE SF_PS, SF_PMA, SF_PLA, SF_DPM FMT_MSA.1/CIPURSE SF_PMA, SF_PLA, SF_DPM FMT_MSA.3/CIPURSE SF_DPM FDP_ACF.1/CIPURSE SF_PMA, SF_PLA, SF_DPM FDP_ACC.1/CIPURSE SF_PMA, SF_PLA, SF_DPM FIA_UID.2 SF_PS, SF_CS FIA_UAU.2 SF_PS, SF_CS FIA_UAU.3 SF_PS, SF_CS FIA_UAU.5 SF_PS, SF_CS FPT_RPL.1 none FTP_TRP.1 SF_PS FCS_COP.1/CIPURSE/AES SF_PS, SF_PMA, SF_PLA, SF_DPM FCS_CKM.4 none FDP_ROL.1 SF_PMA, SF_PLA FCS_CKM.1 SF_CS FPR_UNL.1 none The TOE relies and is dependent on all SFs from [5]. 8.1 IP_SFR (Irrelevant Platform SFRs) and RP_SFR (Relevant Platform SFRs) of [5] RP_SFR: FRU_FLT.2, FPT_FLS.1, FMT_LIM.1. FMT_LIM.2, FAU_SAS.1, FPT_PHP.3, FDP_ITT.1, FPT_ITT.1, FDP_IFC.1, FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FDP_SDC.1, FDP_SDI.2, FCS_RNG.1. IP_SFR: FMT_LIM.1/Loader, FMT_LIM.2/Loader. The rationale for the irrelevance of these two SFRs is given by the platform Security Target [5]: “The security functional requirements FMT_LIM.1/Loader and FMT_LIM.2/Loader apply only to TOE products with Flash Loader enabled for software or data download by the user. In other cases the Flash Loader is not available anymore and the user software or data download is completed.” For this TOE the flash loader is disabled. Following table shows the assumptions of [5] rated according to ASE_COMP.1.2C (IrPA, CfPA or SgPA): Security Target 32 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Statement of compatibility Table 11 Rating of assumptions Assumption Rating Comment A.Process-Sec-IC CfPA Covered by lifecycle assurance A.Resp-Appl CfPA Product defines its assets This means, that all platform assumptions are automatically fulfilled by this TOE. The objectives of this TOE and its environment do not contradict any objectives of the platform TOE and its environment. There are no significant assumptions, which have to be included into this ST. Security Target 33 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ References 9 References [1] Security IC Platform Protection Profile with Augmentation Packages, registered and certified by Bundesamt fuer Sicherheit in der Informationstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Rev 1.0, 13 January 2014. [2] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model; Version 3.1 Revision 4 September 2012, CCMB-2012-09-001 [3] Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Requirements; Version 3.1 Revision 4 September 2012, CCMB-2012-09-002 [4] Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements; Version 3.1 Revision 4 September 2012, CCMB-2012-09-003 [5] Security Target M7791 B12 and G11, Revision 1.4, 2017-01-24, Infineon Technologies AG. [6] CIPURSE™V2 Operation and Interface Specification, Revision 2.0, 2013-12-20 [7] CIPURSE™V2 Cryptographic Protocol, Revision 1.0, 2012-09-28 [8] CIPURSE™V2 CIPURSE™ T Profile Specification, Revision 2.0, 2013-12-20 [9] CIPURSE™Security Controller, SLS 32TLC100(M), Data Book, Revision 1.1, 2015-09-24 [10] Act of the Federal Office for Information Security (BSI-Gesetz – BSIG), Bundesgesetzblatt I p. 2821. [11] CIPURSE™V2 Operation and Interface Specification R2.0 Errata and Precision List, Revision 1.0, 2014-09-18 [12] CIPURSE™V2 Cryptographic Protocol R1.0 Errata and Precision List, Revision 1.0, 2014-09-18 [13] CIPURSE™V2 CIPURSE™ T Profile Specification R2.0 Errata and Precision List, Revision 1.0, 2014-09-18 [ISO/IEC 7816-4] ISO/IEC 7816 International Standard: Identification cards - Integrated circuit cards; Part 4: Organization, security and commands for interchange. Edition 2005 [ISO/IEC 7816-9] ISO/IEC InternationalStandard: Identification cards - Integrated circuit(s) cards with contacts; Part 9: Commands for card management Edition 2004 [ISO/IEC 9798-2] ISO/IEC 9798 Information technology - Securitytechniques - Entity authentication; Part 2: Mechanisms using symmetric encipherment algorithms. Second edition, 1999-07-15, ISO/IEC 9798-2:1999(E) and Technical Corrigendum 1, 2004-02-01, ISO/IEC 9798-2:1999/Cor.1:2004(E) [ISO/IEC 14443-3] ISO/IEC International Standard: Identification cards - Contactless integrated circuit(s) cards -Proximity cards; Part3: Initialization and anticollision Edition 2011 [ISO/IEC 14443-4] ISO/IEC International Standard: Identification cards - Contactless integrated circuit(s) cards - Proximity cards; Part4: Transmission protocols Edition 2008 [FIPS-197] U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197, 2001-11-26 Security Target 34 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ List of Abbreviations 10 List of Abbreviations AES Advanced Encryption Standard ACG Access Group ART Access Rights Table CC Common Criteria CPU Central Processing Unit CRC Cyclic Redundancy Check DF Dedicated File DFA Differential Fault Analysis DPA Differential Power Analysis EF Elementary File EMA Electro Magnetic Analysis HW Hardware IC Integrated Circuit IMM Interface Management Module I/O Input/Output ITSEC Information Technology Security Evaluation Criteria MAC Message Authentication Code MF Master File OS Operating system PCD Proximity Coupling Device (i.e. CIPURSE™V2-compliant terminal) PICC Proximity Integrated Circuit Card (i.e. CIPURSE™V2-compliant card or any other object which hosts a CIPURSE™V2-compliant card application implementation) SCL Symmetric Crypto Library SMG Secure Messaging Group SMR Secure Messaging Rules TSF TOE Security Functionality Security Target 35 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Glossary 11 Glossary Chip Integrated Circuit Controller IC with integrated memory, CPU and peripheral devices Firmware Part of the software implemented as hardware Hardware Physically present part of a functional system (item) Integrated Circuit Component comprising several electronic circuits implemented in a highly miniaturized device using semiconductor technology Mechanism Logic or algorithm which implements a specific security function in hardware or software Memory Hardware part containing digital information (binary data) Microprocessor CPU with peripherals Object Physical or non-physical part of a system which contains information and is acted upon by subjects Operating System Software which implements the basic TOE actions necessary for operation Random Access Memory Volatile memory which permits write and read operations Random Number Generator Hardware part for generating random numbers Security Function Part(s) of the TOE used to implement part(s) of the security objectives Security Target Description of the intended state for countering threats SmartCard Plastic card in credit card format with built-in chip Software Information (non-physical part of the system) which is required to implement functionality in conjunction with the hardware (program code) Subject Entity, the TOE communicates with, e.g. in the form of a terminal, which performs actions Target of Evaluation Product or system which is being subjected to an evaluation Threat Action or event that might prejudice security Security Target 36 Revision 1.0 2017-01-31 Security Target Common Criteria EAL5 augmented / EAL5+ Revision History Revision History Major changes since the last revision Page or Reference Description of change 0.1 Initial version 0.2 Changes related to OR v1 2016-05-20 0.3 Table 1: FW identifier added Chapter 1.4.2.2: version numbers of documents adjusted, CIPURSE™V2 CIPURSE™ T Profile Specification R2.0 Errata and Precision List added Chapter 9: references [11]-[13] added 0.4 Clarification of Mifare compatible system 0.5 Document references updated, SW version update 0.6 User guidance and document references updated 0.7 User guidance and document references updated 0.8 Platform configuration options update, SW version update, user guidance and document references updated 0.9 Document references updated 0.10 Physical scope of the TOE updated 0.11 Physical scope of the TOE updated 1.0 Figure 1 updated Trademarks of Infineon Technologies AG µHVIC™, µIPM™, µPFC™, AU-ConvertIR™, AURIX™, C166™, CanPAK™, CIPOS™, CIPURSE™, CoolDP™, CoolGaN™, COOLiR™, CoolMOS™, CoolSET™, CoolSiC™, DAVE™, DI-POL™, DirectFET™, DrBlade™, EasyPIM™, EconoBRIDGE™, EconoDUAL™, EconoPACK™, EconoPIM™, EiceDRIVER™, eupec™, FCOS™, GaNpowIR™, HEXFET™, HITFET™, HybridPACK™, iMOTION™, IRAM™, ISOFACE™, IsoPACK™, LEDrivIR™, LITIX™, MIPAQ™, ModSTACK™, my-d™, NovalithIC™, OPTIGA™, OptiMOS™, ORIGA™, PowIRaudio™, PowIRStage™, PrimePACK™, PrimeSTACK™, PROFET™, PRO-SIL™, RASIC™, REAL3™, SmartLEWIS™, SOLID FLASH™, SPOC™, StrongIRFET™, SupIRBuck™, TEMPFET™, TRENCHSTOP™, TriCore™, UHVIC™, XHP™, XMC™ Trademarks updated November 2015 Other Trademarks All referenced product or service names and trademarks are the property of their respective owners. ifx1owners. Edition 2017-01-31 ifx1 Published by Infineon Technologies AG 81726 Munich, Germany © 2017 Infineon Technologies AG. All Rights Reserved. Do you have a question about this document? Email: erratum@infineon.com Document reference IMPORTANT NOTICE The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics (“Beschaffenheitsgarantie”) . With respect to any examples, hints or any typical values stated herein and/or any information regarding the application of the product, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation warranties of non-infringement of intellectual property rights of any third party. In addition, any information given in this document is subject to customer’s compliance with its obligations stated in this document and any applicable legal requirements, norms and standards concerning customer’s products and any use of the product of Infineon Technologies in customer’s applications. The data contained in this document is exclusively intended for technically trained staff. It is the responsibility of customer’s technical departments to evaluate the suitability of the product for the intended application and the completeness of the product information given in this document with respect to such application. For further information on the product, technology, delivery terms and conditions and prices please contact your nearest Infineon Technologies office (www.infineon.com). WARNINGS Due to technical requirements products may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies office. Except as otherwise explicitly approved by Infineon Technologies in a written document signed by authorized representatives of Infineon Technologies, Infineon Technologies’ products may not be used in any applications where a failure of the product or any consequences of the use thereof can reasonably be expected to result in personal injury.