SECURITY TARGET COMMON CRITERIA DOCUMENTS | Version 1.1 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB) Secure signature creation device with key generation Certification-ID: BSI-DSZ-CC-1001    Public Version MaskTech International GmbH | Nordostpark 45 | Nuernberg | www.masktech.com | +49 (0)911 95 51 49-0 SECURITY TARGET Contents 1 Normative references 3 2 Conventions and Terminology 4 2.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Terms and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Abbreviated Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 Security Target Introduction (ASE_INT.1) 9 3.1 ST and TOE Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Security Target Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 TOE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Conformance Claims (ASE_CCL.1) 21 4.1 CC Conformance Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 PP Claim, Package Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Conformance Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 PP Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5 Security Problem Definition (ASE_SPD.1) 25 5.1 Assets, Users and Threat Agents . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6 Security Objectives (ASE_OBJ.2) 29 6.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2 Security Objectives for the Operational Environment . . . . . . . . . . . . . 31 6.3 Security Objective Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7 Extended Components Definition (ASE_ECD.1) 43 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 1 SECURITY TARGET 8 Security Requirements (ASE_REQ.2) 44 8.1 Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2 TOE Security Assurance Requirements . . . . . . . . . . . . . . . . . . . . . 69 9 Rationale 71 9.1 Security Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . . 71 10 TOE Summary Specification (ASE_TSS.1) 85 10.1 TOE Security Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.2 Assurance Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.3 Statement of Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 11 Revision History 111 A Overview Cryptographic Algorithms 112 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 2 SECURITY TARGET 1 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited ap- plies. For undated references, the latest edition of the referenced document (including any amendments) applies. • prEN 419211-1, Protection profiles for secure signature creation device – Part 1: Overview1 • ISO/IEC 15408-1:20092 Information technology – Security techniques – Evaluation cri- teria for IT security – Part 1: Introduction and general model • ISO/IEC 15408-22 , Information technology – Security techniques – Evaluation criteria for IT security – Part 2: Security functional components • ISO/IEC 15408-32 , Information technology – Security techniques – Evaluation criteria for IT security – Part 3: Security assurance components 1 To be published. This document was submitted to the Enquiry procedure under reference prEN 14169-1. 2 ISO/IEC 15408-1, -2 and -3 respectively correspond to Common Criteria for Information Technology Secu- rity Evaluation, Parts 1, 2 and 3. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 3 SECURITY TARGET 2 Conventions and Terminology 2.1 Conventions The content and structure of this document follow the rules and conventions laid out in ISO/IEC 15408-1. Normative aspects of content in this European Standard are specified according to the Common Criteria rules and not specifically identified by “shall”. 2.2 Terms and definitions For the purposes of this document, the following terms and definitions apply. 2.2.1 Legislative references The European standard EN 419211 reflects the requirement of a European directive in the technical terms of a protection profile. The following terms are used in the text to reference this directive: 2.2.1.1 The Directive Directive 1999/93/EC of the European parliament and of the council of 13 December 1999 on “a Community framework for electronic signatures” [DIR_1999/93/EC] Note: References in this document to a specific article and paragraph of Directive 1999/93/ec are of the form “(the directive: n.m)”. 2.2.1.2 Annex one of the annexes, Annex I, Annex II or Annex III of the directive 2.2.2 Technical Terms 2.2.2.1 Administrator userwhoperformsTOEinitialization, TOEpersonalization, orotherTOEadministrativefunc- tions MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 4 SECURITY TARGET 2.2.2.2 Advanced electronic signature digital signature which meets specific requirements in (the directive: 2.2) Note 1 to entry: according to the directive a digital signature qualifies as an advanced electronic signature if it: • is uniquely linked to the signatory; • is capable of identifying the signatory; • is created using means that the signatory can maintain under their sole control; and • is linked to the data to which it relates in such a manner that any subsequent change of the data are detectable. 2.2.2.3 Authentication data information used to verify the claimed identity of a user 2.2.2.4 Certificate digital signature used as electronic attestation binding signature verification data to a per- son confirming the identity of that person as legitimate signer (the directive: 2.9) 2.2.2.5 Certificate info information associated with an SCD/SVD pair that may be stored in a secure signature cre- ation device Note 1 to entry: Certificate info may include: • a signer’s public key certificate or, • one or more hash values of a signer’s public key certificate together with an identifier of the hash function used to compute the hash values, or • a public key certificate as defined in X.509. Note 2 to entry: Certificate info may contain information to allow the user to distinguish between several certificates. 2.2.2.6 Certificate generation application CGA collection of application components that receive the SVD from the SSCD to generate a certificate obtaining data to be included in the certificate and to create a digital signature of the certificate 2.2.2.7 Certification service provider CSP entity that issues certificates or provides other services related to electronic signature (the directive: 2.11) MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 5 SECURITY TARGET 2.2.2.8 Data to be signed DTBS all of the electronic data to be signed including a user message and signature at- tributes 2.2.2.9 Data to be signed or its unique representation DTBS/R data received by a secure signature creation device as input in a single signature creation operation Note 1 to entry: Examples of DTBS/R are: • a hash value of the data to be signed (DTBS), or • an intermediate hash value of a first part of the DTBS complemented with a remaining part of the DTBS, or • the DTBS. 2.2.2.10 Legitimate user user of a secure signature creation device who gains possession of it from an SSCD- provisioning service provider and who can be authenticated by the SSCD as its signatory 2.2.2.11 Qualified certificate public key certificate that meets the requirements laid down in Annex I and that is provided by a CSP that fulfills the requirements laid down in Annex II (the directive: 2.10) 2.2.2.12 Qualified electronic signature an advanced electronic signature which is based on a qualified certificate and which is cre- ated by an SSCD 2.2.2.13 Reference authentication data RAD data persistently stored by the TOE for authentication of the signatory 2.2.2.14 Secure signature-creation device SSCD a signature-creation device which meets the requirements laid down in Annex III Note 1 to entry: An SSCD may be evaluated according to this security target conforming to PP SSCD KG and PP SSCD KI as defined in the series of European Standards EN 419211 2.2.2.15 Signatory a person who holds (and is a legitimate user) of an SSCD and acts either on their own behalf or on behalf of the natural or legal person or entity they represent MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 6 SECURITY TARGET 2.2.2.16 Signature creation application SCA application complementing an SSCD with a user interface with the purpose to create an electronic signature 2.2.2.17 Signature creation data SCD unique data, such as codes or private cryptographic keys, which are used by the sig- natory to create an electronic signature Note 1 to entry: For the PPs of this standard the SCD is held in the SSCD. 2.2.2.18 Signature creation system SCS complete system that creates an electronic signature consisting of an SCA and an SSCD 2.2.2.19 Signature verification data SVD data, such as codes or public cryptographic keys, which are used for the purpose of verifying an electronic signature 2.2.2.20 SSCD-provisioning service service to prepare and provide an SSCD to a subscriber and to support the signatory with certification of generated keys and administrative functions of the SSCD 2.2.2.21 User entity (human user or external IT entity) outside the TOE that interacts with the TOE 2.2.2.22 User message data determined by the signatory as the correct input for signing 2.2.2.23 Verification authentication data VAD data input to an SSCD for authentication of the signatory MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 7 SECURITY TARGET 2.3 Abbreviated Terms CC Common Criteria1 CGA certificate generation application DTBS data to be signed DTBS/R data to be signed or its unique representation EAL evaluation assurance level1 HID human interface device IT information technology PP protection profile1 RAD reference authentication data SCA signature creation application SCD signature creation data SCS signature creation system SDO signed data object SFP security function policy SSCD secure signature creation device ST security target1 SVD signature verification data TOE target of evaluation1 TSF TOE security functionality1 VAD verification authentication data 1 See [CC_Part1, CC_Part2, CC_Part3] for details on the specification of Common Criteria. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 8 SECURITY TARGET 3 Security Target Introduction (ASE_INT.1) 3.1 ST and TOE Reference Title Security Target – MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB) Version 1.1 Author MASKTECH INTERNATIONAL GMBH Publication date 2018-02-16 Registration BSI-DSZ-CC-1001 CC Version 3.1 (Revision 4) Editor MASKTECH INTERNATIONAL GMBH Compliant to Protection profiles for Secure signature creation device Part 2: Device with key generation, version 2.0.1, BSI-CC-PP-0059 [CC_PP-0059] (PP SSCD KG) Part 4: Extension for device with key generation and trusted commu- nication with certificate generation application, version 1.0.1, BSI-CC- PP-0071 [CC_PP-0071] (PP SSCD KG TCCGA) Part 5: Extension for device with key generation and trusted commu- nication with signature creation application, version 1.0.1, BSI-CC-PP- 0072 [CC_PP-0072] (PP SSCD KG TCSCA) Assurance Level The assurance level for this ST is EAL5 augmented Keywords secure signature creation device, electronic signature, digital signa- ture, key generation, trusted communication with certificate genera- tion application, trusted communication with signature creation ap- plication 3.2 Security Target Overview This Security Target claims conformance on the following protection profiles covering a number of requirements for a secure signature creation device: Protection profiles PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA are estab- lished by CEN as a European standard for products to create electronic signatures. They MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 9 SECURITY TARGET fulfill requirements of directive1 1999/93/ec of the European parliament and of the council of 13 December 1999 on a community framework for electronic signatures. In accordance with article 9 of this European directive this standard can be indicated by the European commission in the Official Journal of the European Communities as generally recognized standard for electronic signature products. The core protection profile PP SSCD KG defines security functional requirements and se- curity assurance requirements that comply with those defined in Annex III of the directive for a secure signature creation device (SSCD). This secure signature creation device is the target of evaluation (TOE) for protection profile PP SSCD KG. European Union Member States may presume that there is compliance with the require- ments laid down in Annex III of the directive when an electronic signature product is eval- uated to a Security Target (ST) that is compliant with protection profile PP SSCD KG. PP SSCD KG describes core security requirements for a secure device that can generate a signing key2 (signature creation data, SCD) and operates to create electronic signatures with the generated key. A device evaluated according to PP SSCD KG and used in the specified environments can be trusted to create any type of digital signature. As such PP SSCD KG can be used for any device that has been configured to create a digital signature. Specifically PP SSCD KG allows the qualification of a product as a device for creating a qualified electronic signature as defined in the directive. When operated in a secure environment for signature creation a signer may use an SSCD that fulfills only these core security requirements to create a qualified electronic signature.3 PP SSCD KG TCCGA is an extension and conforms4 to the core PP SSCD KG. It defines the security requirements for a trusted communication to a certificate generation application (CGA). These security features allow a changed life cycle of the TOE, i.e. the signatory may generate an SCD/SVD key pair suitable to create qualified electronic signatures and transfer the corresponding public key (signature verification data, SVD) as input to the CGA after the delivery of the SSCD. The TOE supports its authentication as SSCD by the CGA of the Certi- fication service provider (CSP) and a trusted communication with this CGA for protection of the SVD. PPSSCDKGTCSCA isan extensionandconforms4 tothe corePPSSCDKG.Itdefines these- curity requirements for an SSCD used in environments, where the communication between SSCD and the signature creation application (SCA) is assumed to be protected by the SSCD and the SCA. These security features allow using the TOE in a more complex operational environment. The TOE supports a trusted communication with an SCA for protection of au- thentication data and data to be signed. 1 This European directive is referred to in the ST as “the directive”. 2 An SSCD that can generate its own SCD/SVD was defined in the previous version of PP SSCD KG (CWA 14169) as a Type 3 SSCD. The notion of types does not exist anymore in this series of ENs. 3 An advanced electronic signature is defined as an electronic signature created by an SSCD using a public key with a public key certificate created as specified in the directive. 4 See [CC_Part1] for the usage of multiple protection profiles. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 10 SECURITY TARGET For convenience, extensive parts that refer mainly to only one PP are marked as: PP SSCD KG TCSCA is marginalized with SCA PP SSCD KG TCCGA is marginalized with CGA In addition, margins PACE or EAC, respectively, are applied, when large text passages concern the PACE or EAC functionality. 3.3 TOE Overview The TOE “MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB)”, which is realized by a smartcard (for contact-based and contactless usage), comprises of: Hardware * NXP Semiconductors P60D145VB_J (P6022y VB)5 , dual in- terface Smartcard IC (certified compliant to BSI-CC-PP-0084- 2014[CC_PP-0084]: BSI-DSZ-CC-0973-V2 [NXP_ST-P60] including * Libraries RSA, EC and SHA-2 (certified compliant to BSI-CC-PP-0084- 2014 [CC_PP-0084]: CC-17-67206 [NXP_ST-P60_CL]) Software * Operating System MTCOS Pro V2.5 * SSCD application Documentation * Product Manual [MT_Manual] * MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB) User Guidance [AGD] MTCOS Pro V2.5 is a fully interoperable multi-application smart card operating system compliant to [ISO_7816]. It is included in the non-volatile non-programmable memory area (ROM) of the integrated circuit. Some part may also reside in the non-volatile pro- grammable area (EEPROM). The SSCD application is written to the EEPROM in the devel- opment phase (see also section 3.3.3). The application’s file system follows the PKCS #15 structure [PKCS_15]. Note 1: The product contains an MRTD application, which is not part of the TOE, but subject to BSI-DSZ-CC-0995 and BSI-DSZ-CC-0996. Security Features and Access Control MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB) supports the following methods: PACE according to [BSI_TR-03110-1, BSI_TR-03110-2, ICAO_SAC] for • the identification and authentication of the user as the legitimate card holder • the establishment of a trusted channel between the terminal and the card • the protection against tracking and eavesdropping • proof the authenticity of the chip to the terminal (PACE Chip Authentication Map- ping) 5 The configuration ’J’ includes MIFARE and DESFIRE functionality. However, these features are not used by the TOE, so that the used configuration is equivalent to ’P’. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 11 SECURITY TARGET The TOE provides the following secrets to be used within the PACE protocol (PINQES assigns an additional password for authentication to create qualified electronic sig- natures): Secret Minimum length Initial value set by Used to authenticate for PIN 6 digits Signatory on first usage Advanced signature creation, verification of PINQES, change reference data of PINQES ‡ and change reference data of PIN PUK 8 digits Administrator on personalization Signature key generation, certificate import, key termination, activation of PIN, activation of PINQES, reset retry counter of PIN, reset retry counter of PINQES and change reference data of PIN CAN 6 digits Administrator on personalization Verification of PINQES, change reference data of PINQES ‡ and unblock PIN and PUK ‡ Additionally requires authentication against PINQES. Table 3.1: Secrets used within the PACE protocol. PIN and PUK are protected against denial-of-service attacks by setting the chip into a suspended state, before the retry counter of the secret in question is exhausted after consecutive failed authentication attempts. Before the very last retry to authenticate against PIN or PUK, respectively, can be done, an authentication against CAN must be performed. Chip Authentication Version 1 according to [BSI_TR-03110-1] to • proof the authenticity of the chip to the terminal • establish a trusted channel between the terminal and the card Terminal Authentication Version 1 according to [BSI_TR-03110-1] to restrict the service provisions to authorized SCAs and CGAs. The SSCD application offers one signature key appropriate for the creation of qualified electronic signatures (key #1) and two keys appropriate for the creation of advanced elec- tronic signatures (key #2 and key #3). Some configurations (see below) provide a decryp- tion key (key #4) in addition to the signature keys. The key sizes are specified during per- sonalization according [AGD]. To create an electronic signature, the legitimate user must authenticate himself against the RAD, which consists of one or more secrets stored on the chip. The RAD also ensures that the SSCD is in an non-operational state when delivered to the signatory. In the preparation phase (see also section 3.3.3) CAN and PUK are set in the personalization step and delivered to the signatory. The creation of a qualified electronic signature is additionally protected by the secret PINQES, which is a password with a minimum length of 6 digits stored on the MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 12 SECURITY TARGET chip in a hashed representation. For PIN and PINQES no initial values are set in the person- alization step. The secrets must be activated by the signatory on first usage. For this, the authentication against PUK is required. Table 3.2 lists the keys and the corresponding RADs: Key # To be used for Corresponding RAD Remarks 1 qualified signature PIN and PINQES or CAN and PINQES After each qualified signature creation, the authentication state of PINQES is reset to ’not verified’. 2 advanced signature PIN – 3 advanced signature PIN – Table 3.2: Available signature keys and corresponding RADs. To use the decryption key #4, authentication against PIN is required. Note that this func- tionality is not within the scope of this certification. Configurations In order to meet customer requirements, the product is provided in various configurations. These differ in the provided key set and the requirement for Terminal Authentication Ver- sion 1 for the communication between the TOE and the signature creation application (SCA) or the certificate generation application (CGA), respectively. Some configurations include an additional decryption key. The configurations are: No. Configuration-ID Description 1 RSA-PSS(-PUF) 3 RSA keys for signature creation 2 RSA-PSS-ta(-PUF) 3 RSA keys for signature creation, TA required 3 RSA-PSS-dec(-PUF) 3 RSA keys for signature creation, 1 RSA key for decryption 4 EC(-PUF) 2 ECDSA keys and 1 RSA key for signature creation 5 EC-ta 2 ECDSA keys and 1 RSA key for signature creation, TA required 6 EC-dec 2 ECDSA keys and 1 RSA key for signature creation, 1 RSA key for decryption 7 RSA-raw-dec(-PUF) 2 RSA keys and 1 ECDSA key for signature creation, 1 RSA key for decryption 8 RSA-raw-dec-ta(-PUF) 2 RSA keys and 1 ECDSA key for signature creation, 1 RSA key for decryption, TA required Table 3.3: Available file system layouts. The configuration identifiers indicate the algorithm (RSA-PSS, RSA ’raw’ or EC), the presence of a decryption key and whether Terminal Authen- tication is required or not. Note that some configurations are available with the hardware functionality physical unclonable function (PUF) being enabled as well as PUF being dis- abled. Both variants do not differ neither in their behavior nor in security relevant aspects and are thus treated as one configuration. The extension ’-PUF’ is assigned to ensure the correct identification of the TOE. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 13 SECURITY TARGET Further details are given in the User Guidance [AGD]. Note that some security require- ments (see chapter 8) apply only to those configurations requiring Terminal Authentication for the communication with the SCA and CGA. Note 2: Those configurations requiring Terminal Authentication (i.e. RSA-PSS-ta, EC-ta and RSA-raw-dec-ta) for the communication between the TOE and the SCA and the CGA also offer the possibility for SCD-import by the signatory. Note that the key import is not within the scope of the certification. 3.3.1 Operation of the TOE This section presents a functional overview of the TOE and its distinct operational environ- ments (Fig. 3.1). Each interaction requires user authentication using the PACE protocol or, for personalization, symmetric authentication. In any case a Secure Messaging session is started providing a trusted channel for communication. Figure 3.1: SSCD functions and operational environments including trusted channels for communication. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 14 SECURITY TARGET The TOEs interactions comprise of: Preparation environment • Interaction with a certificate generation application (CGA) to obtain a certificate for the signature validation data (SVD) corresponding with the SCD the TOE has generated. The trusted channel allows the CGA to check the authenticity of the SVD. • Interaction with an SSCDissuingapplication to personalize the TOE with personal informationofthelegitimateuser. Optionallyoneormoresignaturekeypairscan be generated on the card or written to the card. Signing environment • Interaction with a signer through a signature creation application (SCA) to sign data after authenticating the signer as its signatory. The SCA provides the data to be signed (DTBS), or a unique representation thereof (DTBS/R) as input to the TOE signature creation function and obtains the resulting digital signature6 . The communication through a trusted channel ensures the integrity of the DTBS re- spective DTBS/R. Management environment • Interaction with a signatory SSCD management application to activate the RAD or change its reference data. • Interaction with a issuer SSCD management application to reset a blocked RAD or terminate a signature key. The TOE stores reference authentication data (RAD, i.e. PIN, CAN and PINQES) and mul- tiple instances of signature creation data (SCD). It provides a function to identify each SCD and the signature creation application (SCA) can provide an interface to the signer to select an SCD for use in the signature creation function of the SSCD. The TOE protects the confi- dentiality and integrity of the SCD and restricts its use in signature creation to its signatory. The digital signature created by the TOE may be used to create an advanced electronic sig- nature as defined in in Article 5.1 of the directive. Determining the state of the certificate as qualified is beyond the scope of EN 419211. However, key #1 of the signature key set meets the requirements for the generation of qualified electronic signatures. The SCA is assumed to protect the integrity of the input it provides to the TOE signature creation function as being consistent with the user data authorized for signing by the sig- natory. Unless implicitly known to the TOE, the SCA indicates the kind of the signing input (as DTBS/R) it provides and computes any hash value required. The TOE may augment the DTBS/R with signature parameters it stores and then computes a hash value over the input as needed by the kind of input and the used cryptographic algorithm. The TOE and the SCA communicate through a trusted channel in order to protect the integrity of the DTBS/R. The TOE stores signatory RAD to authenticate a user as its signatory (see Table 3.2). The TOE protects the confidentiality and integrity of the RAD. The TOE receives the VAD from the SCA. If the signature creation application handles, is requesting or obtaining a VAD from the user, it is assumed to protect the confidentiality and integrity of this data. 6 At a pure functional level the SSCD creates a digital signature; for an implementation of the SSCD, in that meeting the requirements of PP SSCD KG and with the key certificate created as specified in the directive, Annex I, the result of the signing process can be used as to create a qualified electronic signature. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 15 SECURITY TARGET Note 3: Within the PACE protocol, not the VAD (i.e. the password for PIN or CAN, respec- tively) is transmitted from the terminal to the card, but a nonce encrypted with the VAD (zero-knowledge protocol). 3.3.2 Target of Evaluation The TOE is a combination of hardware and software configured to securely create, use and manage signature creation data (SCD). The SSCD protects the SCD during its whole life cycle as to be used in a signature creation process solely by its signatory. The TOE comprises all IT security functionality necessary to ensure the secrecy of the SCD and the security of the electronic signature. The TOE provides the following functions: a) to generate SCD and the correspondent signature verification data (SVD), b) to export the SVD for certification through a trusted channel to the CGA, c) to prove the identity as SSCD to external entities, d) to, optionally, receive and store certificate info, e) to switch the TOE from a non-operational state to an operational state, and f) if in an operational state, to create digital signatures for data with the following steps: 1) select a set of SCD, 2) authenticate the signatory and determine its intent to sign, 3) receive data to be signed or a unique representation thereof (DTBS/R) through a trusted channel from SCA, 4) apply an appropriate cryptographic signature creation function using the se- lected SCD to the DTBS/R. The TOE is prepared for the signatory’s use by a) optionally, generating at least one SCD/SVD pair, and b) personalizing for the signatory by storing in the TOE: 1) authentication data (i.e. PUK) for the signatory to be able to activate the RAD 2) optionally, certificate info for at least one SCD in the TOE. After preparation the SCD is in a non-operational state. Upon receiving a TOE the signa- tory shall verify its non-operational state and change the SCD state to operational by acti- vating the RAD. As the initial value of the RAD is set by the legitimate user, the verification authentication data (VAD) required for use of the TOE in signing is implicitly known only by the legitimate user. After preparation he must be informed of the PUK value enabling him to activate (and set) the RAD. The means of providing this information is expected to protect the confiden- tiality and the integrity of the PUK. If the use of an SCD is no longer required, then it shall be destroyed by erasing the SCD data as well as the associated certificate info, if any exists. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 16 SECURITY TARGET 3.3.3 TOE Life Cycle 3.3.3.1 General The TOE life cycle distinguishes stages for development production, preparation and oper- ational use. Figure 3.2: TOE life cycle; the asterisks * marks the optional import of the SVD and certificate infoduringTOEpreparationandcertificateinfodeletionwhenSCDisdestroyed; thesubjects to the evaluation are indicated by a red frame . The development phase comprises the development and production of the TOE. The steps are in detail: Development • Development of the IC and integrated software by NXP Semiconductors. • Development of the embedded software (operating system) by MASKTECH INTER- NATIONAL GMBH. Production • Manufacturing of the chip (IC/integrated software/embedded software) by NXP Semiconductors. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 17 SECURITY TARGET • Initialization/pre-personalization by MASKTECH INTERNATIONAL GMBH, SMAR- TRAC TECHNOLOGY Ltd., Thailand (see [SC_Smartrac]), HID Global, Ireland (see [SC_HID]) or Gemalto AG, Switzerland (former Trüb AG, see [SC_Gemalto]). In the initialization step the chip is configured, the MF is created and the person- alization keys are written. In the pre-personalization step, the SSCD application including all files is created. The steps of the development phase performed by MASKTECH INTERNATIONAL GMBH (i.e. the development of the embedded software and the initialization/pre-personalization) are subject of the evaluation according to the assurance life cycle (ALC) class. The steps performed by NXP Semiconductors are evaluated within the certification of the platform ([NXP_ST-P60]) and the cryptographic library ([NXP_ST-P60_CL]). The development phase ends with the delivery of the TOE to the SSCD-provisioning service. The operational usage of the TOE comprises the preparation stage and the operational use stage. In the preparation stage the personal information of the legitimate user is writ- ten and, optionally, one or more SCD/SVD pairs are generated and the according certificates stored on the card. In the preparation stage SCD/SVD pairs may also be imported to the card SSCD-provisioning service (note that the key import is not within the scope of this certifica- tion). The TOE operational use stage begins when the signatory has obtained both the PUK value and the TOE. Enabling the TOE for signing requires at least one set of SCD stored in its memory.7 The life cycle (Fig. 3.2 ) allows the generation of an SCD/SVD pair before as well as after the delivery to the signatory. 3.3.3.2 Preparation Stage An SSCD-provisioning service provider having accepted the TOE from a manufacturer pre- pares the TOE for use and delivers it to its legitimate user. The preparation phase ends when the legitimate user has received the TOE from the SSCD-provisioning service and any SCD it might already hold have been enabled for use in signing. DuringpreparationoftheTOE,asspecifiedabove, anSSCD-provisioningserviceprovider performs the following tasks: a) InitializethesecurityfunctionsintheTOEfortheidentificationasSSCD,fortheproofof CGA thisSSCDidentitytoexternalentities,andfortheprotectedexportoftheSVD(required by PP SSCD KG TCCGA). b) LinkstheidentityoftheTOEasSSCDandtheidentityofthelegitimateuseraspotential CGA applicantforcertificatesforSVDgeneratedbytheTOE(requiredbyPPSSCDKGTCCGA). c) Obtain information on the intended recipient of the device as required for the prepa- ration process and for identification as a legitimate user of the TOE. d) Set a PUK to enable the legitimate user to activate the RAD and prepare information about the PUK value for delivery to the legitimate user. e) Optionally, generate a certificate for at least one SCD by (more details about the SVD certification task are given below): 7 Note that according to PP SSCD KG the operational use stage begins before the preparation stage ends, because the signatory must enable the SCD for use (by setting the VAD) after receiving the TOE and the PUK. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 18 SECURITY TARGET 1) the TOE generating an SCD/SVD pair and obtaining a certificate for the SVD ex- ported from the TOE, or 2) initializing security functions in the TOE for protected export of the SVD and ob- taining a certificate for the SVD after receiving a protected request from the TOE. f) Optionally, present certificate info to the SSCD. g) Deliver the TOE and the accompanying PUK value info to the legitimate user. The SVD certification task of an SSCD-provisioning service provider as specified in PP SSCDKG may support a centralized, pre-issuing key generation process, with at least one key generated and certified, before delivery to the legitimate user. Alternatively, or additionally, that task may support key generation by the signatory after delivery and outside the secure preparation environment. A TOE may support both key generation processes, for example with a first key generated centrally and additional keys generated by the signatory in the operational use stage. Data required for inclusion in the SVD certificate at least includes (cf. [DIR_1999/93/EC], Annex II): • the SVD which correspond to SCD under the control of the signatory; • the name of the signatory or a pseudonym, which is to be identified as such; • an indication of the beginning and end of the period of validity of the certificate. The data included in the certificate may have been stored in the SSCD during personal- ization. Before initiating the actual certificate signature the CGA verifies the SVD received from the TOE by: a) establishing the sender as genuine SSCD b) establishing the integrity of the SVD to be certified as sent by the originating SSCD, c) establishing that the originating SSCD has been personalized for the legitimate user, d) establishing correspondence between SCD and SVD, and e) an assertion that the signing algorithm and key size for the SVD are approved and ap- propriate for the type of certificate. The proof of correspondence between an SCD stored in the TOE and an SVD may be im- plicit in the security mechanisms applied by the CGA. Prior to generating the certificate the CSP asserts the identity of the signatory specified in the certification request as the legitimate user of the TOE. If the TOE is used for creation of qualified or advanced electronic signatures, the certifi- cate links the signature verification data to the person (i.e. the signatory) and confirms the identity of that person (cf. [DIR_1999/93/EC], article 2, clause 9). 3.3.3.3 Operational Use Stage In this life cycle stage the signatory can use the TOE to create qualified or advanced elec- tronic signatures. TheTOEoperationalusestagebeginswhenthesignatoryhasobtainedboththePUKand the TOE . Enabling the TOE for signing requires at least one set of SCD stored in its memory. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 19 SECURITY TARGET The signatory can also interact with the SSCD through a trusted channel to perform man- agement tasks, e.g. reset a RAD value or use counter if the PIN in the reference data has been lost or blocked. The signatory can render an SCD in the TOE permanently unusable. Rendering the last SCD in the TOE permanently unusable ends the life of the TOE as SSCD. In the usage phase, SCD/SVD generation by the TOE and SVD export from the TOE may CGA take place in the preparation stage (by the SSCD-provisioning service provider) and/or in the operational use stage (usually by the signatory). The TOE provides a trusted channel to the CGA protecting the integrity of the SVD. For a key generated by the signatory he may be allowed to choose the kind of certificate (qualified, or not) to obtain for the SVD of the new key. The signatory may also be allowed to choose some of the data in the certificate request for instance to use a pseudonym instead of the legal name in the certificate8 . If the conditions to obtain a qualified certificate are met the new key can also be used to create advanced electronic signatures. The optional TOE functions for additional key generation and certification in the oper- ational use stage require additional security functions in the TOE and an interaction with the SSCD-provisioning service provider through a trusted channel. Before generating the certificate including the SVD exported from the TOE, the CGA additionally establishes a) the identity of the TOE as SSCD, b) that the originating SSCD has been personalized for the applicant for the certificate as legitimate user, and c) the correspondence between SCD stored in the SSCD and the received SVD. The TOE life cycle as SSCD ends when all set of SCD stored in the TOE are destructed. This may include deletion of the corresponding certificates. 8 The certificate request in this case will contain the name of the signatory as the requester, as for instance it may be signed by the signatory’s existing SCD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 20 SECURITY TARGET 4 Conformance Claims (ASE_CCL.1) 4.1 CC Conformance Claim This ST is conforming to the Common Criteria version 3.1 Revision 4: • Part 1 [CC_Part1], • Part 2 [CC_Part2] extended, and • Part 3 [CC_Part3] conformant. 4.2 PP Claim, Package Claim Strict conformance of this ST to the following Common Criteria protection profiles is claimed: • “Protection profiles for secure signature creation device – Part 2: Device with key gen- eration”, BSI-CC-PP-0059-2009-MA-02 [CC_PP-0059] • “Protection profiles for secure signature creation device – Part 4: Extension for device CGA with key generation and trusted communication with certificate generation applica- tion”, BSI-CC-PP-0071-2012-MA-01 [CC_PP-0071] • “Protection profiles for secure signature creation device – Part 5: Extension for device SCA with key generation and trusted communication with signature creation application”, BSI-CC-PP-0072-2012-MA-01 [CC_PP-0072] This ST is conforming to assurance package EAL5 augmented with ALC_DVS.2 and AVA_ VAN.5 defined in CC part 3 [CC_Part3]. 4.3 Conformance Rationale This ST claims conformance to PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA. This CGA SCA implies for this ST: a) The security problem definition (SPD) for PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA are described by the same threats, organizational security policies and assumptions. b) The security objectives for the TOE include all the security objectives for the TOE of PP SSCD KG and in addition: MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 21 SECURITY TARGET 1) OT.TOE_SSCD_Auth (Authentication proof as SSCD) defined in PP SSCD KG TCCGA 2) OT.TOE_TC_SVD_Exp (Trusted channel for SVD) defined in PP SSCD KG TCCGA 3) OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) defined in PP SSCD KG TCSCA 4) OT.TOE_TC_DTBS_Imp (Trusted channel for DTBS) defined in PP SSCD KG TCSCA c) The security objectives for the operational environment include all the security objec- tives for the TOE of PP SSCD KG and in addition: 1) OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) de- fined in PP SSCD KG TCCGA 2) OE.CGA_TC_SVD_Imp (CGA trusted channel for SVD import) defined in PP SSCD KG TCCGA Furthermore, the following modifications are performed: 1) PP SSCD KG TCCGA substitutes OE.SSCD_Prov_Service (Authentic SSCD provided by SSCD-provisioning service) by OE.Dev_Prov_Service. 2) PPSSCDKGTCSCAsubstitutesOE.HI_VADbyOE.HID_TC_VAD_Exp(tosupportthe security objective for the TOE OT.TOE_TC_VAD_Imp) 3) PP SSCD KG TCSCA substitutes OE.DTBS_Protect by OE.SCA_TC_DTBS_Exp (to support the security objective for the TOE OT.TOE_TC_DTBS_Imp) d) The security functional requirements (SFRs) for the TOE include all SFRs of PP SSCD KG and in addition: 1) FIA_API.1 (Authentication Proof of Identity) specified in PP SSCD KG TCCGA 2) FDP_DAU.2/SVD (Data Authentication with Identity of Guarantor) specified in PP SSCD KG TCCGA 3) FTP_ITC.1/SVD (Inter-TSF trusted channel) specified in PP SSCD KG TCCGA 4) FDP_UIT.1/DTBS (Data exchange integrity) specified in PP SSCD KG TCSCA 5) FTP_ITC.1/VAD (Inter-TSF trusted channel – TC Human Interface Device) specified in PP SSCD KG TCSCA 6) FTP_ITC.1/DTBS (Inter-TSF trusted channel – Signature creation Application) specified in PP SSCD KG TCSCA e) PP SSCD KG TCCGA provides operation of the SFR FIA_UAU.1 of PP SSCD KG. f) PP SSCD KG TCSCA provides refinements for the SFR FIA_UAU.1 of PP SSCD KG. g) The SARs specified in PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA are iden- tical. 4.4 PP Additions Password Authenticated Connection Establishment (PACE) including PACE Chip Authentica- tion Mapping and Extended Access Control Version 1 (EACv1) (i.e. Chip Authentication Version 1 (CAv1) and Terminal Authentication Version 1 (TAv1) ) functionality to provide a secure au- thentication protocol and a secure channel for the communication with authorized termi- nals in phase usage/operational has been added. PACE can also be used for the personaliza- tion. This implies the following augmentations, which are adapted from protection profiles [CC_PP-0056-V2] and [CC_PP-0068-V2]: MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 22 SECURITY TARGET 1) FCS_CKM.1/DH_PACE 2) FCS_CKM.1/CA 3) FCS_COP.1/CA_ENC 4) FCS_COP.1/CA_MAC 5) FCS_COP.1/SIG_VER 6) FCS_COP.1/PACE_ENC 7) FCS_COP.1/PACE_MAC 8) FCS_RND.1 9) FDP_ACC.1/TRM 10) FDP_ACF.1/TRM 11) FIA_UID.1 (the existing SFR has been extended) 12) FIA_UAU.4/PACE 13) FIA_UAU.5/PACE 14) FIA_UAU.6 15) FMT_MTD.1/CVCA_UPD 16) FMT_MTD.1/CVCA_DATE 17) FMT_MTD.1/KEY_READ 18) FPT_EMS.1/KEYS ECC key generation in order to create the Chip Authentication key pair has been taken into account by adding the SFR: 19) FCS_CKM.1/CA_STATIC The RAD is stored on the SSCD in hashed representation. This is taken into account by: 20) FCS_COP.1/SHA which is adapted from protection profile [CC_PP-0086]. Additional protection against attacks against the RAD is addressed by 21) FIA_AFL.1/Suspend_PIN 22) FIA_AFL.1/Block_PIN taken from protection profile [CC_PP-0086]. The SFRs 23) FDP_ACC.1/Signature_Creation/N-QES 24) FDP_ACF.1/Signature_Creation/N-QES are added as iterations of the SFRs FDP_ACC.1/Signature_Creation and FDP_ACF.1/ Sig- nature_Creation to address the different authentication requirement for non-qualified elec- tronic signature creation. Table 9.3 takes the dependencies of the SFRs into account. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 23 SECURITY TARGET Some SFRs as defined in PP SSCD KG have been renamed to avoid mistakes with the newly added SFRs listed above. These are: SFR in PP SSCD KG SFR in this ST FCS_CKM.1 FCS_CKM.1/SCD FCS_COP.1 FCS_COP.1/SCD FIA_AFL.1 FIA_AFL.1/RAD FPT_EMS.1 FPT_EMS.1/SSCD MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 24 SECURITY TARGET 5 Security Problem Definition (ASE_SPD.1) 5.1 Assets, Users and Threat Agents The Common Criteria define assets as entities that the owner of the TOE presumably places value upon. The term “asset” is used to describe the threats in the operational environment of the TOE. Assets and objects a) SCD: private key used to perform an electronic signature operation. The confi- dentiality, integrity and signatory’s sole control over the use of the SCD shall be maintained. b) SVD: public key linked to the SCD and used to perform electronic signature veri- fication. The integrity of the SVD when it is exported shall be maintained. c) DTBS and DTBS/R: set of data, or its representation, which the signatory intends to sign. Their integrity and the unforgeability of the link to the signatory provided by the electronic signature shall be maintained. Secondary assets taken from [CC_PP-0056-V2] respectively [CC_PP-0068-V2] PACE EAC a) Accessibility to the TOE functions and data only for authorized subjects: property of the TOE to restrict access to TSF and TSF-data stored in the TOE to authorized subjects only. b) TOEinternalsecretcryptographickeys: permanentlyortemporarilystoredsecret cryptographic material used by the TOE in order to enforce its security function- ality. The confidentiality and integrity of the cryptographic keys must be main- tained. c) TOE internal non-secret cryptographic material: permanently or temporarily stored non-secret cryptographic (public) keys and other non-secret material (Document Security Object SOD containing digital signature) used by the TOE in order to enforce its security functionality. The integrity and authenticity of the non-secret cryptographic material must be maintained. Users and subjects acting for users a) User: end user of the TOE who can be identified as administrator or signatory. The subject S.User may act as S.Admin in the role R.Admin or as S.Sigy in the role R.Sigy. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 25 SECURITY TARGET b) Administrator: user who is in charge to perform the TOE initialization, TOE per- sonalizationorotherTOEadministrativefunctions. ThesubjectS.Adminisacting in the role R.Admin for this user after successful authentication as administrator. c) Signatory: user who hold the TOE and use it on their own behalf or on behalf of the natural or legal person or entity they represent. The subject S.Sigy is acting in the role R.Sigy for this user after successful authentication as signatory. Subject referring the EACv1 functionality adapted from [CC_PP-0056-V2] EAC 1. Certification Service Provider (corresponding to “Country Verifying Certification Authority” in [CC_PP-0056-V2], which does not exist within the SSCD-context) 2. Document Verifier 3. Legitimate Terminal (CGA and SCA) (corresponding to “Domestic Extended In- spection System” in [CC_PP-0056-V2], which does not exist within the SSCD- context) Threat agents a) Attacker: human or process acting on their behalf located outside the TOE. The maingoalofthe attackeristoaccesstheSCDor tofalsifytheelectronicsignature. The attacker has a high attack potential and knows no secret. 5.2 Threats 5.2.1 T.SCD_Divulg Storing, copying and releasing of the signature creation data An attacker stores or copies the SCD outside the TOE. An attacker can obtain the SCD during generation, storage and use for signature creation in the TOE. 5.2.2 T.SCD_Derive Derive the signature creation data An attacker derives the SCD from publicly known data, such as SVD corresponding to the SCD or signatures created by means of the SCD or any other data exported outside the TOE, which is a threat against the secrecy of the SCD. 5.2.3 T.Hack_Phys Physical attacks through the TOE interfaces An attacker interacts physically with the TOE to exploit vulnerabilities, resulting in arbitrary security compromises. This threat is directed against SCD, SVD and DTBS. 5.2.4 T.SVD_Forgery Forgery of the signature verification data An attacker forges the SVD presented by the CSP to the CGA. This results in loss of SVD in- tegrity in the certificate of the signatory. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 26 SECURITY TARGET 5.2.5 T.SigF_Misuse Misuse of the signature creation function of the TOE An attacker misuses the signature creation function of the TOE to create SDO for data the signatory has not decided to sign. The TOE is subject to deliberate attacks by experts pos- sessingahighattackpotentialwithadvancedknowledgeofsecurityprinciplesandconcepts employed by the TOE. 5.2.6 T.DTBS_Forgery Forgery of the DTBS/R An attacker modifies the DTBS/R sent by the SCA. Thus the DTBS/R used by the TOE for sign- ing does not match the DTBS the signatory intended to sign. 5.2.7 T.Sig_Forgery Forgery of the electronic signature An attacker forges a signed data object, maybe using an electronic signature that has been created by the TOE, and the violation of the integrity of the signed data object is not de- tectable by the signatory or by third parties. The signature created by the TOE is subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. 5.3 Organizational Security Policies 5.3.1 P.CSP_QCert Qualified certificate The CSP uses a trustworthy CGA to generate a qualified certificate or non-qualified certifi- cate (cf. the directive, article 2, clause 9, and Annex I) for the SVD generated by the SSCD. The certificates contain at least the name of the signatory and the SVD matching the SCD implemented in the TOE under sole control of the signatory. The CSP ensures that the use of the TOE as SSCD is evident with signatures through the certificate or other publicly available information. 5.3.2 P.QSign Qualified electronic signatures The signatory uses a signature creation system to sign data with an advanced electronic signature (cf. the directive, article 1, clause 2), which is a qualified electronic signature if it is based on a valid qualified certificate (according to the directive Annex I)1 . The DTBS are presented to the signatory and sent by the SCA as DTBS/R to the SSCD. The SSCD creates the electronic signature created with an SCD implemented in the SSCD that the signatory maintain under their sole control and is linked to the DTBS/R in such a manner that any subsequent change of the data is detectable. 1 It is a non-qualified advanced electronic signature if it is based on a non-qualified certificate for the SVD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 27 SECURITY TARGET 5.3.3 P.Sigy_SSCD TOE as secure signature creation device The TOE meets the requirements for an SSCD laid down in Annex III of the directive [DIR_1999/93/EC]. This implies the SCD is used for digital signature creation under sole con- trol of the signatory and the SCD can practically occur only once. 5.3.4 P.Sig_Non-Repud Non-repudiation of signatures The life cycle of the SSCD, the SCD and the SVD shall be implemented in a way that the sig- natory is not able to deny having signed data if the signature is successfully verified with the SVD contained in their unrevoked certificate. 5.4 Assumptions 5.4.1 A.CGA Trustworthy certification generation application The CGA protects the authenticity of the signatory’s name or pseudonym and the SVD in the (qualified) certificate by a qualified electronic signature of the CSP. 5.4.2 A.SCA Trustworthy signature creation application The signatory uses only a trustworthy SCA. The SCA generates and sends the DTBS/R of the data the signatory wishes to sign in a form appropriate for signing by the TOE. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 28 SECURITY TARGET 6 Security Objectives (ASE_OBJ.2) 6.1 Security Objectives for the TOE 6.1.1 Relation between the Claimed PPs For relation between PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA see section Con- formance rationale on page 21. 6.1.2 OT.Lifecycle_Security Life cycle security The TOE shall detect flaws during the initialization, personalization and operational usage. The TOE shall securely destroy the SCD on demand of the signatory. Note 4: The TOE may contain more than one set of SCD. There is no need to destroy the SCD in case of repeated SCD generation. The signatory shall be able to destroy the SCD stored in the SSCD, e.g. after the (qualified) certificate for the corresponding SVD has been expired. 6.1.3 OT.SCD/SVD_Auth_Gen Authorized SCD/SVD generation The TOE shall provide security features to ensure that authorized users only may invoke the generation of the SCD and the SVD. 6.1.4 OT.SCD_Unique Uniqueness of the signature creation data The TOE shall ensure the cryptographic quality of an SCD/SVD pair it creates as suitable for the advanced or qualified electronic signature. The SCD used for signature creation shall practically occur only once and shall not be reconstructable from the SVD. In that context ’practically occur once’ means that the probability of equal SCDs is negligible. 6.1.5 OT.SCD_SVD_Corresp Correspondence between SVD and SCD The TOE shall ensure the correspondence between the SVD and the SCD generated by the TOE. This includes unambiguous reference of a created SVD/SCD pair for export of the SVD and in creating an electronic signature creation with the SCD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 29 SECURITY TARGET 6.1.6 OT.SCD_Secrecy Secrecy of the signature creation data The secrecy of the SCD (used for signature creation) shall be reasonably assured against attacks with a high attack potential. Note 5: The TOE shall keep the confidentiality of the SCD at all times, in particular during SCD/SVD generation, signature creation operation, storage and secure destruction. 6.1.7 OT.Sig_Secure Cryptographic security of the electronic signature The TOE shall create digital signatures that cannot be forged without knowledge of the SCD through robust encryption techniques. The SCD shall not be reconstructable using the dig- ital signatures or any other data exportable from the TOE. The digital signatures shall be resistant against these attacks, even when executed with a high attack potential. 6.1.8 OT.Sigy_SigF Signature creation function for the legitimate signatory only TheTOEshallprovidethedigitalsignaturecreationfunctionforthelegitimatesignatoryonly and protects the SCD against the use of others. The TOE shall resist attacks with high attack potential. 6.1.9 OT.DTBS_Integrity_TOE DTBS/R integrity inside the TOE The TOE shall not alter the DTBS/R. As by definition of the DTBS/R this may consist of the DTBS themselves, this objective does not conflict with a signature creation process where the TOE hashes the provided DTBS (in part or entirely) for signature creation. 6.1.10 OT.EMSEC_Design Provide physical emanation security The TOE shall be designed and built in such a way as to control the production of intelligible emanations within specified limits. 6.1.11 OT.Tamper_ID Tamper detection The TOE shall provide system features that detect physical tampering of its components, and uses those features to limit security breaches. 6.1.12 OT.Tamper_Resistance Tamper resistance The TOE shall prevent or resist physical tampering with specified system devices and com- ponents. 6.1.13 OT.TOE_SSCD_Auth Authentication proof as SSCD CGA The TOE shall hold unique identity and authentication data as SSCD and provide security mechanisms to identify and to authenticate itself as SSCD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 30 SECURITY TARGET 6.1.14 OT.TOE_TC_SVD_Exp TOE trusted channel for SVD export CGA The TOE shall provide a trusted channel to the CGA to protect the integrity of the SVD ex- ported to the CGA. The TOE shall enable the CGA to detect alteration of the SVD exported by the TOE. 6.1.15 OT.TOE_TC_VAD_Imp Trusted channel of TOE for VAD import SCA TheTOEshallprovideatrustedchannelfortheprotectionoftheconfidentialityandintegrity of the VAD received from the HID as needed by the authentication method employed. Note 6: This security objective for the TOE is partly covering OE.HID_VAD from the core PP SSCDKG. While OE.HID_VAD in PPSSCDKG requires only the operational environment to pro- tect VAD, PP SSCD KG TCSCA requires the HID and the TOE to implement a trusted channel for the protection of the VAD: the HID exports the VAD and establishes one end of the trusted channel according to OE.HID_TC_VAD_Exp, the TOE imports VAD at the other end of the trusted channel according to OT.TOE_TC_VAD_Imp. Therefore PP SSCD KG TCSCA re-assigns partly the VAD protection from the operational environment as described by OE.HID_VAD to the TOE as described by OT.TOE_TC_VAD_Imp and leaves only the necessary functionality by the HID. 6.1.16 OT.TOE_TC_DTBS_Imp Trusted channel for DTBS SCA The TOE shall provide a trusted channel to the SCA to detect alteration of the DTBS/R re- ceived from the SCA. The TOE shall not generate electronic signatures with the SCD for al- tered DTBS. Note 7: This security objective for the TOE is partly covering OE.DTBS_Protect from the core PP SSCD KG. While OE.DTBS_Protect in PP SSCD KG requires only the operational en- vironment to protect DTBS, PP SSCD KG TCSCA requires the SCA and the TOE to implement a trusted channel for the protection of the DTBS: the SCA exports the DTBS and estab- lishes one end of the trusted channel according to OE.SCA_TC_DTBS_Exp, the TOE imports DTBS at the other end of the trusted channel according to OT.TOE_TC_DTBS_Imp. There- fore PP SSCD KG TCSCA re-assigns partly the DTBS protection from the operational environ- ment as described by OE.DTBS_Protect to the TOE as described by OT.TOE_TC_DTBS_Imp and leaves only the necessary functionality by the SCA. 6.2 Security Objectives for the Operational Environment 6.2.1 Relation between the Claimed PPs For relation between PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA see section Con- formance rationale on page 21. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 31 SECURITY TARGET 6.2.2 OE.SVD_Auth Authenticity of the SVD The operational environment shall ensure the integrity of the SVD sent to the CGA of the CSP. The CGA verifies the correspondence between the SCD in the SSCD of the signatory and the SVD in the qualified certificate. 6.2.3 OE.CGA_QCert Generation of qualified certificates The CGA shall generate a qualified certificate that includes (amongst others): a) the name of the signatory controlling the TOE, b) the SVD matching the SCD stored in the TOE and being under sole control of the sig- natory c) the qualified signature of the CSP. The CGA shall confirm with the generated qualified certificate that the SCD correspond- ing to the SVD is stored in a SSCD. 6.2.4 OE.HID_VAD Protection of the VAD If an external device provides the human interface for user authentication, this device shall ensure confidentiality and integrity of the VAD as needed by the authentication method em- ployed from import through its human interface until import through the TOE interface. In particular, if the TOE requires a trusted channel for import of the VAD, the HID shall support usage of this trusted channel. 6.2.5 OE.DTBS_Intend SCA sends data intended to be signed The signatory shall use a trustworthy SCA that • generates the DTBS/R of the data that has been presented as DTBS and which the sig- natory intends to sign in a form which is appropriate for signing by the TOE, • sends the DTBS/R to the TOE and enables verification of the integrity of the DTBS/R by the TOE, • attaches the signature produced by the TOE to the data or provides it separately. Note 8: The SCA should be able to support advanced electronic signatures. Currently, there are three formats defined by ETSI recognized as meeting the requirements needed by ad- vanced electronic signatures: CAdES, XAdES and PAdES. These three formats mandate to include the hash of the signer’s public key certificate in the data to be signed. In order to support for the mobility of the signer, it is recommended to store the certificate info on the SSCD for use by SCA and identification of the corresponding SCD if more than one SCD is stored on the SSCD. 6.2.6 OE.DTBS_Protect SCA protects the data intended to be signed The operational environment shall ensure that the DTBS/R cannot be altered in transit be- tween the SCA and the TOE. In particular, if the TOE requires a trusted channel for import of the DTBS/R, the SCA shall support usage of this trusted channel. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 32 SECURITY TARGET 6.2.7 OE.Signatory Security obligation of the signatory The signatory shall check that the SCD stored in the SSCD received from SSCD-provisioning service is in non-operational state. The signatory shall keep their VAD confidential. 6.2.8 OE.Dev_Prov_Service AuthenticSSCDprovidedbySSCD-ProvisioningSer- vice CGA The SSCD-Provisioning Service handles authentic devices that implement the TOE, prepares the TOE for proof as SSCD to external entities, personalizes the TOE for the legitimate user as signatory, links the identity of the TOE as SSCD with the identity of the legitimate user, and delivers the TOE to the signatory. Note9: ThisobjectivereplacesOE.SSCD_Prov_ServicefromPPSSCDKG,whichispossibleas it does not imply any additional requirements for the operational environment when com- pared to OE.SSCD_Prov_Service (OE.Dev_Prov_Service is a subset of OE.SSCD_Prov_ Ser- vice). 6.2.9 OE.CGA_SSCD_Auth Pre-initialization of the TOE for SSCD authentication CGA The CSP shall check by means of the CGA whether the device presented for application of a (qualified) certificate holds unique identification as SSCD, successfully proved this identity as SSCD to the CGA, and whether this identity is linked to the legitimate holder of the device as applicant for the certificate. 6.2.10 OE.CGA_TC_SVD_Imp CGA trusted channel for SVD import CGA The CGA shall detect alteration of the SVD imported from the TOE with the claimed identity of the SSCD. The developer prepares the TOE by pre-initialization for the delivery to the customer (i.e. the SSCD-Provisioning Service) in the development phase not addressed by a security objective for the operational environment. The SSCD-Provisioning Service performs initial- ization and personalization as TOE for the legitimate user (i.e. the Device Holder). If the TOE is delivered to the Device Holder with SCD the TOE is an SSCD. This situation is ad- dressed by OE.SSCD_Prov_Service except the additional initialization of the TOE for proof as SSCD and trusted channel to the CGA. If the TOE is delivered to the Device Holder with- out an SCD the TOE will be an SSCD only after generation of the first SCD/SVD pair. Be- cause this SCD/SVD pair generation is performed by the Signatory in the operational use stage the TOE provides additional security functionality addressed by OT.TOE_SSCD_Auth and OT.TOE_TC_ SVD_Exp. But this security functionality shall be initialized by the SSCD- ProvisioningServiceasdescribedinOE.Dev_Prov_Service. ThereforePPSSCDKGTCCGAsub- stitutes OE.SSCD_Prov_Service by OE.Dev_Prov_Service allowing generation of the first SCD/SVD pair after delivery of the TOE to the Device Holder and requiring initialization of security functionality of the TOE. Nevertheless the additional security functionality shall be used by the operational environment as described in OE.CGA_SSCD_Auth and OE.CGA_TC_ SVD_Imp. This approach does not weaken the security objectives of and requirements to MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 33 SECURITY TARGET the TOE but enforce more security functionality of the TOE for additional method of use. Therefore it does not conflict with the CC conformance claim to the core PP SSCD KG. 6.2.11 OE.HID_TC_VAD_Exp Trusted channel of HID for VAD export SCA The HID provides the human interface for user authentication. The HID will ensure confiden- tiality and integrity of the VAD as needed by the authentication method employed including export to the TOE by means of a trusted channel. Note 10: This security objective for the TOE is partly covering OE.HID_VAD from the core PP SSCD KG. While OE.HID_VAD in PP SSCD KG requires only the operational environment to protect VAD, PP SSCD KG TCSCA requires the HID and the TOE to implement a trusted channel for the protection of the VAD: the HID exports the VAD and establishes one end of the trusted channel according to OE.HID_TC_VAD_Exp, the TOE imports VAD at the other end of the trusted channel according to OT.TOE_TC_VAD_Imp. Therefore PP SSCD KG TC- SCA re-assigns partly the VAD protection from the operational environment as described by OE.HID_VAD to the TOE as described by OT.TOE_TC_VAD_Imp and leaves only the necessary functionality by the HID. 6.2.12 OE.SCA_TC_DTBS_Exp Trusted channel of SCA for DTBS export SCA The SCA provides a trusted channel to the TOE for the protection of the integrity of the DTBS to ensure that the DTBS/R cannot be altered undetected in transit between the SCA and the TOE. Note 11: This security objective for the TOE is partly covering OE.DTBS_Protect from the core PP SSCD KG. While OE.DTBS_Protect in PP SSCD KG requires only the operational en- vironment to protect DTBS, PP SSCD KG TCSCA requires the SCA and the TOE to imple- ment a trusted channel for the protection of the DTBS: the SCA exports the DTBS and estab- lishes one end of the trusted channel according to OE.SCA_TC_DTBS_Exp, the TOE imports DTBS at the other end of the trusted channel according to OT.TOE_TC_DTBS_Imp. There- fore PP SSCD KG TCSCA re-assigns partly the DTBS protection from the operational environ- ment as described by OE.DTBS_Protect to the TOE as described by OT.TOE_TC_DTBS_Imp and leaves only the necessary functionality by the SCA. 6.3 Security Objective Rationale 6.3.1 Security Objectives Backtracking The following tables show how the security objectives for the TOE (table 6.1) and the secu- rity objectives for the operational environment(table 6.2) cover the threats, organizational security policies and assumptions. Security objectives that are added by PP SSCD KG TCCGA or PP SSCD KG TCSCA are color coded for better readability. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 34 SECURITY TARGET OT.Lifecycle_Security OT.SCD/SVD_Auth_Gen OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.Sigy_SigF OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance OT.TOE_SSCD_Auth OT.TOE_TC_SVD_Exp OT.TOE_TC_VAD_Imp OT.TOE_TC_DTBS_Imp T.SCD_Divulg x T.SCD_Derive x x T.Hack_Phys x x x x T.SVD_Forgery x x T.SigF_Misuse x x x x x T.DTBS_Forgery x x T.Sig_Forgery x x P.CSP_QCert x x x P.QSign x x P.Sigy_SSCD x x x x x x x x x x x P.Sig_Non-Repud x x x x x x x x x x x x Table 6.1: Mapping of security problem definition to security objectives of the TOE (assump- tions are mapped in table 6.2) OE.CGA_QCert OE.SVD_Auth OE.SSCD_Prov_Service OE.Dev_Prov_Service OE.HID_VAD OE.DTBS_Intend OE.DTBS_Protect OE.Signatory OE.CGA_SSCD_Auth OE.CGA_TC_SVD_Imp OE.HID_TC_VAD_Exp OE.SCA_TC_DTBS_Exp T.SCD_Divulg T.SCD_Derive T.Hack_Phys T.SVD_Forgery x x T.SigF_Misuse x x x x x x T.DTBS_Forgery x x x T.Sig_Forgery x P.CSP_QCert x x P.QSign x x P.Sigy_SSCD x x x x P.Sig_Non-Repud x x x x x x x x x x x A.CGA x x A.SCA x Table 6.2: Mapping of security problem definition to security objectives of the operational MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 35 SECURITY TARGET environment 6.3.2 Security Objectives Sufficiency Countering of threats by security objectives: T.SCD_Divulg (Storing, copying and releasing of the signature creation data) addresses the threat against the legal validity of electronic signature due to storage and copying of SCD outside the TOE, as expressed in the directive [DIR_1999/93/EC], recital (18). This threat is countered by • OT.SCD_Secrecy, which assures the secrecy of the SCD used for signature creation. T.SCD_Derive (Derive the signature creation data) deals with attacks on the SCD via public known data produced by the TOE, which are the SVD and the signatures created with the SCD. • OT.SCD/SVD_Auth_Gen counters this threat by implementing cryptographically se- cure generation of the SCD/SVD pair. • OT.Sig_Secure ensures cryptographically secure electronic signatures. T.Hack_Phys (Exploitationofphysicalvulnerabilities)dealswithphysicalattacksexploiting physical vulnerabilities of the TOE. • OT.SCD_Secrecy preserves the secrecy of the SCD. • OT.EMSEC_Design counters physical attacks through the TOE interfaces and observa- tion of TOE emanations. • OT.Tamper_ID and • OT.Tamper_Resistance counter the threat T.Hack_Phys by detecting and by resisting tampering attacks. T.SVD_Forgery (Forgery of the signature verification data) deals with the forgery of the SVD exported by the TOE to the CGA for certificate generation. T.SVD_Forgery is addressed by • OT.SCD_SVD_Corresp, which ensures correspondence between SVD and SCD and un- ambiguous reference of the SVD/SCD pair for the SVD export and signature creation with the SCD, and • OE.SVD_Auth that ensures the integrity of the SVD exported by the TOE to the CGA. It ensures verification of the correspondence between the SCD in the SSCD of the signa- tory and the SVD in the input it provides to the certificate generation function of the CSP. Additionally T.SVD_Forgery is addressed by CGA • OT.TOE_TC_SVD_Exp, which ensures that the TOE sends the SVD in a verifiable form through a trusted channel to the CGA, as well as by • OE.CGA_TC_SVD_Imp, which provides verification of SVD authenticity by the CGA. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 36 SECURITY TARGET T.SigF_Misuse (Misuse of the signature creation function of the TOE) addresses the threat of misuse of the TOE signature creation function to create SDO by others than the signatory to create SDO for data for which the signatory has not decided to sign, as required by the directive [DIR_1999/93/EC], Annex III, paragraph 1, literal (c). • OT.Lifecycle_SecurityrequirestheTOEtodetectflawsduringtheinitialization,person- alization and operational usage including secure destruction of the SCD on demand of the signatory. • OT.Sigy_SigF ensures that the TOE provides the signature creation function for the le- gitimate signatory only. • OE.DTBS_Intend ensures that the SCA sends the DTBS/R only for data the signatory intends to sign and OE.DTBS_Protect counters manipulation of the DTBS during trans- mission over the channel between the SCA and the TOE. • OT.DTBS_Integrity_TOE prevents the DTBS/R from alteration inside the TOE. • OE.Signatory ensures that the signatory checks that an SCD stored in the SSCD when received from an SSCD-provisioning service provider is in non-operational state, i.e. the SCD cannot be used before the signatory becomes control over the SSCD and also ensures that the signatory keeps their VAD confidential. The combination of SCA • OT.TOE_TC_DTBS_Imp and • OE.SCA_TC_DTBS_Exp counters the undetected manipulation of the DTBS during the transmission form the SCA to the TOE. If the SCA provides a human interface for user authentication, OE.HID_TC_VAD_Exp re- quires the HID to protect the confidentiality and the integrity of the VAD as needed by the authentication method employed. The HID and the TOE will protect the VAD by a trusted channel between HID and TOE according to • OE.HID_TC_VAD_Exp and • OT.TOE_TC_VAD_Imp. T.DTBS_Forgery (ForgeryoftheDTBS/R) addresses the threat arising from modifications of the data sent as input to the TOE’s signature creation function that does not represent the DTBS as presented to the signatory and for which the signatory has expressed its intent to sign. The TOE IT environment addresses T.DTBS_Forgery by the means of • OE.DTBS_Intend, which ensures that the trustworthy SCA generates the DTBS/R of the datathathasbeenpresentedasDTBSandwhichthesignatoryintendstosigninaform appropriate for signing by the TOE, and • OE.DTBS_Protect, whichensuresthattheDTBS/Rcannotbealteredintransitbetween the SCA and the TOE. The TOE counters this threat by the means of • OT.DTBS_Integrity_TOE by ensuring the integrity of the DTBS/R inside the TOE. The threat T.DTBS_Forgery is addressed by the security objectives SCA MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 37 SECURITY TARGET • OT.TOE_TC_DTBS_Imp and • OE.SCA_TC_DTBS_Exp that ensure that the DTBS/R is sent through a trusted channel and cannot be altered undetected in transit between the SCA and the TOE. T.Sig_Forgery (Forgeryoftheelectronicsignature) deals with non-detectable forgery of the electronic signature. • OT.Sig_Secure, • OT.SCD_Unique and • OE.CGA_QCert address this threat in general. • OT.Sig_Secure ensures by means of robust cryptographic techniques that the signed data and the electronic signature are securely linked together. • OT.SCD_Unique ensures that the same SCD cannot be generated more than once and the corresponding SVD cannot be included in another certificate by chance. • OE.CGA_QCert prevents forgery of the certificate for the corresponding SVD, which would result in false verification decision concerning a forged signature. Enforcement of OSPs by security objectives: P.CSP_QCert (CSPgeneratesqualifiedcertificates)establishestheCSPgeneratingqualified certificate or non-qualified certificate linking the signatory and the SVD implemented in the SSCD under sole control of this signatory. P.CSP_QCert is addressed by: • OT.Lifecycle_Security, which requires the TOE to detect flaws during the initialization, personalization and operational usage, • OT.SCD_SVD_Corresp, which requires to ensure the correspondence between the SVD and the SCD during their generation, and • OE.CGA_QCert for generation of qualified certificates or non-qualified certificates, which requires the CGA to certify the SVD matching the SCD implemented in the TOE under sole control of the signatory. According to: CGA • OT.TOE_SSCD_Auth the copies of the TOE will hold unique identity and authentication data as SSCD and provide security mechanisms enabling the CGA to identify and to authenticate the TOE as SSCD to prove this identity as SSCD to the CGA. • OE.CGA_SSCD_Auth ensures that the SP checks the proof of the device presented of the applicant that it is an SSCD. P.QSign (Qualified electronic signatures) provides that the TOE and the SCA may be em- ployed to sign data with a qualified electronic signature, which is a qualified electronic sig- nature if based on a valid qualified certificate. • OT.Sigy_SigF ensures signatory’s sole control of the SCD by requiring the TOE to pro- vide the signature creation function for the legitimate signatory only and to protect the SCD against the use of others. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 38 SECURITY TARGET • OT.Sig_Secure ensures that the TOE creates electronic signatures, which cannot be forged without knowledge of the SCD through robust encryption techniques. • OE.CGA_QCert addresses the requirement of qualified or non-qualified electronic cer- tificates building a base for the electronic signature. • OE.DTBS_Intend ensures that the SCA provides only those DTBS to the TOE, which the signatory intends to sign. P.Sigy_SSCD (TOE as secure signature creation device) requires the TOE to meet the Annex III of the directive [DIR_1999/93/EC]. This is ensured as follows: Paragraph 1(a) of the directive, Annex III requires that the SCD used for signature cre- ation can practically occur only once; this is ensured by: • OT.SCD_Unique. Paragraph 1(a) of the directive, Annex III requires to ensure the secrecy of the SCD; this is ensured by: • OT.SCD_Unique, • OT.SCD_Secrecy and • OT.Sig_Secure. • OT.EMSEC_ Design and • OT.Tamper_Resistance address specific objectives to ensure secrecy of the SCD against specific attacks. Paragraph 1(b) of the directive, Annex III requires to ensure that the SCD cannot be derived from SVD, the electronic signatures or any other data exported outside the TOE; this is ensured by: • OT.SCD_Secrecy and • OT.Sig_Secure. Paragraph 1(c) of the directive, Annex III requires to ensure that the TOE provides the signature creation function for the legitimate signatory only and protects the SCD against the use of others; this is ensured by: • OT.Sigy_SigF. Paragraph 2 of the directive, Annex III requires that the TOE shall not alter the DTBS/R; this is ensured by: • OT.DTBS_Integrity_TOE. Paragraph 2 of Annex III requires that an SSCD does not prevent the data to be signed from being presented to the signatory prior to the signature process is obviously fulfilled by the method of TOE usage: the SCA will present the DTBS to the signatory and send it to the SSCD for signing. The usage of SCD under sole control of the signatory is ensured by • OT.Lifecycle_Security requiring the TOE to detect flaws during the initialization, per- sonalization and operational usage, • OT.SCD/SVD_Auth_Gen, which limits invocation of the generation of the SCD and the SVD to authorized users only and MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 39 SECURITY TARGET • OT.Sigy_SigF, which requires the TOE to provide the signature creation function for the legitimate signatory only and to protect the SCD against the use of others. • OE.SSCD_Prov_Service ensures that the signatory obtains an authentic copy of the TOE, initialized and personalized as SSCD from the SSCD-provisioning service. • OE.Dev_Prov_Service ensures that the legitimate user obtains a TOE sample as an au- CGA thentic, initialized and personalized TOE from an SSCD-Provisioning Service through the TOE delivery procedure. If the TOE implements SCD generated under control of the SSCD-Provisioning Service the legitimate user receives the TOE as SSCD. If the TOE is delivered to the legitimate user without SCD in the operational phase he or she applies for the (qualified) certificate as the Device Holder and legitimate user of the TOE. The CSP will use the TOE security features to check whether the following requirements are fulfilled: • OE.CGA_SSCD_Auth (the device presented is an SSCD linked to the applicant) and CGA • OE.CGA_TC_SVD_Imp (the received SVD is sent by this SSCD). CGA This is addressed by the TOE security features: • OT.TOE_SSCD_Auth and CGA • OT.TOE_TC_SVD_Exp. CGA Thus the obligation of the SSCD provision service for the first SCD/SVD pair is comple- mented in an appropriate way by the CSP for the SCD/SVD pair generated outside the secure preparation environment. P.Sig_Non-Repud (Non-repudiation of signatures) deals with the repudiation of signed data by the signatory, although the electronic signature is successfully verified with the SVD contained in their certificate valid at the time of signature creation. This policy is imple- mented by the combination of the security objectives for the TOE and its operational envi- ronment, which ensures the aspects of signatory’s sole control over and responsibility for the electronic signatures created with the TOE. • OE.SSCD_Prov_Service ensures that the signatory uses an authentic copy of the TOE, initialized and personalized for the signatory. • OE.CGA_QCert ensures that the certificate allows to identify the signatory and thus to link the SVD to the signatory. • OE.SVD_Auth and • OE.CGA_QCert require the environment to ensure the authenticity of the SVD as being exported by the TOE and used under sole control of the signatory. • OT.SCD_SVD_Corresp ensures that the SVD exported by the TOE corresponds to the SCD that is implemented in the TOE. • OT.SCD_Unique provides that the signatory’s SCD can practically occur just once. • OE.CGA_SSCD_Auth requires that the verification whether the device presented by the CGA applicant is an SSCD and • OE.CGA_TC_SVD_Imp requires that the received SVD is sent by the device holding the CGA corresponding SCD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 40 SECURITY TARGET This is addressed by the TOE security objectives • OT.TOE_SSCD_Auth and CGA • OT.TOE_TC_SVD_Exp supported by CGA • OE.Dev_Prov_Service. CGA • OE.Signatory ensures that the signatory checks that the SCD, stored in the SSCD re- ceived from an SSCD-Provisioning Service is in non-operational state (i.e. the SCD can- not be used before the signatory becomes into sole control over the SSCD). • OT.Sigy_SigF provides that only the signatory may use the TOE for signature creation. As prerequisite OE.Signatory ensures that the signatory keeps their VAD confidential. • OE.HID_TC_VAD_Exp and SCA • OT.TOE_TC_VAD_Imp protect the confidentiality of VAD during the transmission be- SCA tween the HI device and TOE. The following security objectives ensure that the TOE generates electronic signatures only for a DTBS/R that the signatory has decided to sign as DTBS. • OE.DTBS_Intend, • OT.DTBS_Integrity_TOE, • OE.DTBS_Protect, or respectively • OE.SCA_TC_DTBS_Exp and SCA • OT.TOE_TC_DTBS_Imp. SCA • OT.Sig_Secure requires robust cryptographic techniques to ensure that only this SCD may create a valid electronic signature that can be successfully verified with the cor- responding SVD used for signature verification. • OT.Lifecycle_Security, • OT.SCD_Secrecy, • OT.EMSEC_Design, • OT.Tamper_ID and • OT.Tamper_Resistance protect the SCD against any compromise. Upkeep of assumptions by security objectives: A.SCA (Trustworthy signature creation application) establishes the trustworthiness of the SCA with respect to generation of DTBS/R. This is addressed by • OE.DTBS_Intend which ensures that the SCA generates the DTBS/R of the data that have been presented to the signatory as DTBS and which the signatory intends to sign in a form which is appropriate for being signed by the TOE. A.CGA (Trustworthy certification generation application) establishes the protection of the authenticity of the signatory’s name and the SVD in the qualified certificate by the advanced signature of the CSP by means of the CGA. This is addressed by • OE.CGA_QCert, which ensures the generation of qualified certificates, and by MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 41 SECURITY TARGET • OE.SVD_Auth, whichensurestheprotectionoftheintegrityofthereceivedSVDandthe verification of the correspondence between the SVD and the SCD that is implemented by the SSCD of the signatory. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 42 SECURITY TARGET 7 Extended Components Definition (ASE_ECD.1) This Security Target uses the following extended components: FPT_EMS as defined in [CC_PP-0059], FIA_API as defined in [CC_PP-0071] and FCS_RND as defined in [CC_PP-0068-V2] (see also note 36). No other components are used. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 43 SECURITY TARGET 8 Security Requirements (ASE_REQ.2) 8.1 Security Functional Requirements 8.1.1 Use of Requirement Specifications Common Criteria allow several operations to be performed on functional requirements; re- finement, selection, assignment, and iteration. Each of these operations is used in this ST. A refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinement of security requirements is either (i) denoted by the word “re- finement” in bold text and the added or changed words are in bold text or (ii) included in text as bold text and marked by a footnote. In cases where words from a CC requirement were deleted, a separate attachment indicates the words that were removed or the removed words are simply striked through (e.g., like in removed words). A selection operation is used to select one or more options provided by the CC in stating arequirement. SelectionsthathavebeenmadebythePPauthorsaredenotedasunderlined text and the original text of the component is given by a footnote. Selections filled in by the ST author are denoted as double-underlined text. An assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing as underlined text denotes assignments, which have been made by the PP authors, and the original text of the component is given by a footnote. Assignments filled in by the ST author are denoted as double-underlined text. An iteration operation is used when a component is repeated with varying operations. Iteration is denoted by showing a slash “/”, and the iteration indicator after the component identifier. 8.1.2 Cryptographic Support (FCS) FCS_CKM.1/SCD Cryptographic key generation – SCD Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 44 SECURITY TARGET FCS_CKM.1.1/SCD The TSF shall generate an SCD/SVD pair in accordance with a speci- fied cryptographic key generation algorithm RSA and specified cryp- tographic key sizes 2048 bit - 4096 bit that meet the following: [PKCS_1_v22] and ECDSA and specified cryptographic key sizes 224 bit - 521 bit that meet the following: [BSI_TR-03111]. Note 12: The SFR also covers the generation of asymmetric key pairs to be used for decryp- tion. Note 13: The standard PKCS #1 version 2.2 [PKCS_1_v22] supersedes the standard PKCS #1 version 2.1, which is referenced in the [NXP_ST-P60_CL]. However, version 2.2 only includes compatible techniques, both versions are equivalent in this context. PACE FCS_CKM.1/DH_PACE Cryptographic key generation – Diffie-Hellman for PACE session keys Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] Justification: A Diffie-Hellman key agreement is used in order to have no key distribution, therefore FCS_CKM.2 makes no sense in this case. FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/ DH_PACE The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to [BSI_TR-03111] and specified cryptographic key sizes 112 bits, 128 bits, 192 bits and 256 bits that meet the following: [ICAO_SAC] and [ISO_15946-3]. Note 14: The TOE generates a shared secret value K with the terminal during the PACE pro- tocol, see [ICAO_SAC]. The shared secret value K is used for deriving the AES or DES session keys for message encryption and message authentication (PACE-KMAC, PACE-KEnc) according to [ICAO_SAC] for the TSF required by FCS_COP.1/PACE_ENC and FCS_COP.1/PACE_MAC. Note 15: FCS_CKM.1/DH_PACE implicitly contains the requirements for the hashing func- tions used for key derivation by demanding compliance to [ICAO_SAC]. Note 16: This SFR has been adapted from [CC_PP-0068-V2]. EAC FCS_CKM.1/CA_STATIC Cryptographic key generation – ECC key pair generation for Chip Authentication Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 45 SECURITY TARGET FCS_CKM.1.1/CA_STATIC The TSF shall generate cryptographic keys in accordance with a spec- ified cryptographic key generation algorithm ECC key pair and speci- fied cryptographic key sizes 224 bit - 521 bit that meet the following: [BSI_TR-03111]. Note 17: This SFR has been added in order to create an ECC key pair to be used for Chip Au- thentication. It follows the SFR FCS_CKM.1/SCD (FCS_CKM.1 in BSI-CC-PP-0059), but revokes the refinement ’SCD/SVD pair’. EAC FCS_CKM.1/CA Cryptographic key generation – Diffie-Hellman for Chip Authenti- cation session keys 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/CA The TSF shall generate cryptographic keys in accordance with a speci- fied cryptographic key generation algorithm ECDH and specified cryp- tographic key sizes 112, 128, 192 and 256 bits that meet the following: based on an ECDH protocol compliant to [BSI_TR-03111] Note 18: FCS_CKM.1/CA implicitly contains the requirements for the hashing functions used for key derivation by demanding compliance to [BSI_TR-03110-1]. Note 19: The TOE shall destroy any session keys in accordance with FCS_CKM.4 after (i) de- tection of an error in a received command by verification of the MAC and (ii) after successful run of the Chip Authentication Protocol v.1. (iii) The TOE shall destroy the PACE session keys after generation of a Chip Authentication session keys and changing the Secure Messaging to the Chip Authentication session keys. (iv) The TOE shall clear the memory area of any ses- sion keys before starting the communication with the terminal in a new after-reset-session as required by FDP_RIP.1. Concerning the Chip Authentication keys FCS_CKM.4 is also ful- filled by FCS_CKM.1/CA. Note 20: This SFR has been adapted from [CC_PP-0056-V2]. Note 21: If PACE Chip Authentication Mapping is performed, the Secure Messaging session established by the PACE protocol is sustained. In this case FCS_CKM.1/DH_PACE applies in- stead of FCS_CKM.1/CA. 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] MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 46 SECURITY TARGET FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with the cryp- tographic key destruction method physical deletion of key value by overwriting it with ’00’ or random bytes that meets the following: [FIPS_140-2]. Note 22: The cryptographic key SCD will be destroyed on demand of the signatory. The signatory may want to destruct the SCD stored in the SSCD e.g. after the qualified certificate for the corresponding SVD is not valid any more. Note 23: The TOE shall destroy the PACE or CA session keys after detection of an error in PACE EAC a received command by verification of the MAC. The TOE shall clear the memory area of any session keys before starting the communication with the terminal in a new after-reset- session as required by FDP_RIP.1. FCS_COP.1/SCD Cryptographic operation – SCD 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/SCD The TSF shall perform digital signature creation in accordance with a specified cryptographic algorithm RSASSA-PSS and raw RSA and cryp- tographic key sizes 2048 bit - 4096 bit that meet the following: PKCS#1 v2.2 [PKCS_1_v22] and in accordance with a specified cryptographic algorithm RSA-PKCS1-v1_5 and cryptographic key sizes 2048 bit - 4096 bit that meet the following: [PKCS_1_v22] and in accordance with a specified cryptographic algorithm ECDSA and cryptographic key sizes 224 bit and 521 bit that meet the following: [BSI_TR-03111]. See also Note 13. FCS_COP.1/SHA Cryptographic operation – Hashes 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/SHA The TSF shall perform hashing in accordance with a specified crypto- graphicalgorithmSHA-256andcryptographickeysizesnonethatmeet the following: [FIPS_180-4]. Note 24: SHA-256 is used for the hash representation in which the PINs are stored. The requirements for the hashing functions used for PACE and Chip Authentication are included in SFRs FCS_CKM.1/DH_PACE and FCS_CKM.1/CA implicitly. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 47 SECURITY TARGET Note 25: This SFR has been adapted from [CC_PP-0086]. EAC FCS_COP.1/CA_ENC Cryptographic operation – Symmetric encryption / decryption 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/CA_ENC TheTSFshallperformSecureMessaging-encryptionanddecryptionin accordance with a specified cryptographic algorithm AES in CBC mode and cryptographic key sizes 128 bit, 192 bit and 256 bit and 3DES in CBC mode and cryptographic key sizes 112 bit that meet the following: [FIPS_197], [FIPS_46-3], and [NIST_SP800-38A]. Note 26: This SFR requires the TOE to implement the cryptographic primitives (e.g. Triple- DES and/or AES) for Secure Messaging with encryption of the transmitted data. The keys are agreed between the TOE and the terminal as part of the Chip Authentication Protocol Version 1 according to the FCS_CKM.1/CA. Note 27: This SFR has been adapted from [CC_PP-0056-V2]. EAC FCS_COP.1/CA_MAC Cryptographic operation – MAC 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/CA_MAC The TSF shall perform Secure Messaging - message authentication code in accordance with a specified cryptographic algorithm CMAC-AES and cryptographic key sizes 128 bit, 192 bit and 256 bit and Retail-MAC and cryptographic key sizes 112 bit that meet the following: [FIPS_197], [FIPS_46-3], [NIST_SP800-38B], Section 6, and [ISO_9797], MAC algorithm 3 with block cipher DES, key KMAC and IV=SSC. Note 28: This SFR requires the TOE to implement the cryptographic primitive for Secure Messagingwithencryptionandmessageauthenticationcodeoverthetransmitteddata. The key is agreed between the TSF by Chip Authentication protocol version 1 according to the FCS_CKM.1/CA. Furthermore the SFR is used for authentication attempts of a terminal as Personalization Agent by means of the authentication mechanism. Note 29: This SFR has been adapted from [CC_PP-0056-V2]. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 48 SECURITY TARGET EAC FCS_COP.1/SIG_VER Cryptographic operation – Signature verification 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/ SIG_VER The TSF shall perform digital signature verification in accordance with a specified cryptographic algorithm ECDSA with SHA-224, SHA-256, SHA-384 or SHA-512 and cryptographic key sizes 224 - 521 bits that meet the following: [FIPS_186-4], chapter 6, [FIPS_180-4], section 6.2, [ISO_15946-2], and [BSI_TR-03111], Section 6 (r1). Note 30: This SFR has been adapted from [CC_PP-0056-V2]. It applies only to the configu- rations RSA-PSS-ta, EC-ta and RSA-raw-dec-ta. PACE FCS_COP.1/PACE_ENC Cryptographic operation – Encryption / decryption AES/3DES 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/ PACE_ENC The TSF shall perform Secure Messaging - encryption and decryption in accordance with the cryptographic algorithm AES in CBC mode and cryptographic key sizes 128 bit, 192 bit and 256 bit and 3DES in CBC mode and cryptographic key sizes 112 bit that meet the follow- ing: [FIPS_197], [FIPS_46-3], and [NIST_SP800-38A], Section 6.2 compliant to [ICAO_SAC]. Note 31: This SFR requires the TOE to implement the cryptographic primitive AES or 3DES for Secure Messaging with encryption of transmitted data and encrypting the nonce in the first step of PACE. The related session keys are agreed between the TOE and the terminal as part of the PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KEnc). Note 32: This SFR has been adapted from [CC_PP-0068-V2]. PACE FCS_COP.1/PACE_MAC Cryptographic operation – MAC 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 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 49 SECURITY TARGET FCS_COP.1.1/ PACE_MAC The TSF shall perform Secure Messaging - message authentication codeinaccordancewithaspecifiedcryptographicalgorithmCMACand cryptographic key sizes 128 bit, 192 bit and 256 bit and Retail-MAC and cryptographic key sizes 112 bit that meet the following: [FIPS_197], [FIPS_46-3], [NIST_SP800-38B], Section6, and[ISO_9797], MACal- gorithm 3 with block cipher DES, key KMAC and IV=SSC compliant to [ICAO_SAC]. Note33: ThisSFRrequirestheTOEtoimplementthecryptographicprimitiveforSecureMes- saging with message authentication code over transmitted data. The related session keys are agreed between the TOE and the terminal as part of either the PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KMAC). Note 34: This SFR has been adapted from [CC_PP-0068-V2]. PACE EAC FCS_RND.1 Quality metric for random numbers Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a physical random number generator that imple- ments: (PTG.2.1) A total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output. (PTG.2.2) If a total failure of the entropy source occurs while the RNG is being operated, the RNG prevents the output of any internal random number that depends on some raw random numbers that have been generated after the total failure of the entropy source. (PTG.2.3) The online test shall detect non-tolerable statistical defects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test has finished successfully or when a defect has been detected. (PTG.2.4) The online test procedure shall be effective to detect non-tolerable weaknesses of the random numbers soon. (PTG.2.5) The online test procedure checks the quality of the raw random number sequence. It is triggered at regular intervals or continuously. The online test is suitable for detecting non-tolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time. FCS_RND.1.2 The TSF shall provide octets of bits that meet: (PTG.2.6) Test procedure A does not distinguish the internal random numbers from output sequences of an ideal RNG. (PTG.2.7) The average Shannon entropy per internal random bit exceeds 0.997. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 50 SECURITY TARGET Note35: ThisSFRrequirestheTOEtogeneraterandomnumbersusedfortheauthentication protocols as required by FIA_UAU.4. Note 36: This SFR has been adapted from [CC_PP-0068-V2] and changed according to [CC_PP-0084](FCS_RNG.1)tomeet[BSI_AIS31v3]. Thenaming’FCS_RND.1’hasbeenkeptfor consistence with the certification procedure for the MRTD application (BSI-DSZ-CC-0995). 8.1.3 User Data Protection (FDP) The security attributes and related status for the subjects and objects are: Subject or object the security attribute is associated with Security attribute type Value of the security attribute S.User Role R.Admin R.Sigy S.User SCD / SVD Management authorized not authorized SCD SCD Operational no yes SCD SCD Identifier arbitrary value SVD (This ST does not define secu- rity attributes for SVD) (This ST does not define secu- rity attributes for SVD) Table 8.1: Subjects and security attributes for access control PACE FDP_ACC.1/TRM Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/TRM The TSF shall enforce the Access Control SFP on terminals gaining access to the User Data and data stored in EF.SOD of the electronic document. Note 37: This SFR has been adapted from [CC_PP-0068-V2]. The term logical travel docu- ment has been changed to electronic document. PACE FDP_ACF.1/TRM Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 51 SECURITY TARGET FDP_ACF.1.1/TRM The TSF shall enforce the Access Control SFP to objects based on the following: 1) Subjects: a) Legitimate Terminal 2) Objects: a) data stored in EF.DG14 and EF.SOD of the TOE, b) all TOE intrinsic secret cryptographic keys stored in the electronic document. 3) Security attributes: a) authorization of the Legitimate Terminal FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an op- eration among controlled subjects and controlled objects is al- lowed: A Legitimate Terminal is allowed to read data objects from FDP_ACF.1/TRM according to [ICAO_SAC] after a successful PACE authentication as required by FIA_UAU.1. FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1) Any terminal being not authenticated as Legitimate Terminal is not allowed to read, to write, to modify, to use any User Data stored on the electronic document. 2) Terminals not using Secure Messaging are not allowed to read, to write, to modify, to use any data stored on the electronic document. Note 38: This SFR has been adapted from [CC_PP-0068-V2]. The term travel document has been changed to electronic document, BIS-PACE has been changed to Legitimate Terminal. FDP_ACC.1/ SCD/SVD_Generation Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ SCD/SVD_Generation The TSF shall enforce the SCD/SVD_Generation_SFP on 1) subjects: S.User, 2) objects: SCD, SVD, 3) operations: generation of SCD/SVD pair. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 52 SECURITY TARGET FDP_ACF.1/ SCD/SVD_Generation Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ SCD/SVD_Generation The TSF shall enforce the SCD/SVD_Generation_SFP to objects based on the following: the user S.User is associated with the security attribute “SCD/SVD Management”. FDP_ACF.1.2/ SCD/SVD_Generation The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: S.User with the security attribute “SCD/SVD Management” set to “authorized” is allowed to generate SCD/SVD pair. Refinement: S.UserisallowedtogenerateSCD/SVDpairafterasuc- cessfulPACEauthenticationusingthePUKasthesharedpassword. FDP_ACF.1.3/ SCD/SVD_Generation The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACC.1/ SVD_Transfer Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ SVD_Transfer The TSF shall enforce the SVD_Transfer_SFP on 1) subjects: S.User, 2) objects: SVD, 3) operations: export. FDP_ACF.1/ SVD_Transfer Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ SVD_Transfer The TSF shall enforce the SVD_Transfer_SFP to objects based on the following: 1) the S.User is associated with the security attribute Role, 2) the SVD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 53 SECURITY TARGET FDP_ACF.1.2/ SVD_Transfer The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: R.Admin and R.Sigy are allowed to export SVD. Refinement for the configurations RSA-PSS-ta, EC-ta and RSA-raw- dec-ta: R.Sigy is allowed to export SVD after a successful Terminal Authentication. FDP_ACF.1.3/ SVD_Transfer The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/ SVD_Transfer The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none FDP_ACC.1/ Signature_Creation Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ Signature_Creation The TSF shall enforce the Signature_Creation_SFP on 1) subjects: S.User, 2) objects: DTBS/R, SCD, 3) operations: signature creation. FDP_ACF.1/ Signature_Creation Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ Signature_Creation The TSF shall enforce the Signature_Creation_SFP to objects based on the following: 1) the S.User is associated with the security attribute “Role” and, 2) the SCD with the security attribute “SCD Operational”. FDP_ACF.1.2/ Signature_Creation The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: R.Sigy is allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “yes”. Refinement for the configurations RSA-PSS-ta, EC-ta and RSA-raw- dec-ta: R.Sigy is allowed to create qualified electronic signatures for DTBS/R with SCD after successful Terminal Authentication and successful authentication against RAD. FDP_ACF.1.3/ Signature_Creation The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 54 SECURITY TARGET FDP_ACF.1.4/ Signature_Creation The TSF shall explicitly deny access of subjects to objects based on the following additional rules: S.User is not allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “no”. FDP_ACC.1/ Signature_Creation/ N-QES Subset access control – Non-qualified electronic signature Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ Signature_Creation/ N-QES The TSF shall enforce the Signature_Creation_SFP on 1) subjects: S.User, 2) objects: DTBS/R, SCD, 3) operations: signature creation. FDP_ACF.1/ Signature_Creation/ N-QES Security attribute based access control – Non-qualified electronic signature Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ Signature_Creation/ N-QES The TSF shall enforce the Signature_Creation_SFP to objects based on the following: 1) the S.User is associated with the security attribute “Role” and, 2) the SCD with the security attribute “SCD Operational”. FDP_ACF.1.2/ Signature_Creation/ N-QES The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: R.Sigy is allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “yes”. Refinement for the configurations RSA-PSS-ta, EC-ta and RSA-raw- dec-ta: R.Sigy is allowed to create non-qualified electronic signa- tures for DTBS/R with SCD after successful Terminal Authentica- tion. FDP_ACF.1.3/ Signature_Creation/ N-QES The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/ Signature_Creation/ N-QES The TSF shall explicitly deny access of subjects to objects based on the following additional rules: S.User is not allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “no”. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 55 SECURITY TARGET SCA FDP_UIT.1/DTBS Data exchange integrity Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_UIT.1.1/DTBS The TSF shall enforce the Signature_Creation_SFP to receive user data in a manner protected from modification and insertion errors. FDP_UIT.1.2/DTBS The TSF shall be able to determine on receipt of user data, whether modification and insertion has occurred. FDP_RIP.1 Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1.1 The TSF shall ensure that any previous information content of a re- source is made unavailable upon the de-allocation of the resource from the following objects: SCD. The following data persistently stored by the TOE shall have the user data attribute “in- tegrity checked persistent stored data”: 1) SCD 2) SVD (if persistently stored by the TOE). The DTBS/R temporarily stored by the TOE has the user data attribute “integrity checked stored data”: FDP_SDI.2/Persistent Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring. Dependencies: No dependencies. FDP_SDI.2.1/Persistent The TSF shall monitor user data stored in containers controlled by the TSF for integrity error on all objects, based on the following attributes: integrity checked stored data. FDP_SDI.2.2/Persistent Upon detection of a data integrity error, the TSF shall 1) prohibit the use of the altered data, 2) inform the S.Sigy about integrity error. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 56 SECURITY TARGET FDP_SDI.2/DTBS Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring. Dependencies: No dependencies. FDP_SDI.2.1/DTBS The TSF shall monitor user data stored in containers controlled by the TSF for integrity error on all objects, based on the following attributes: integrity checked stored DTBS. FDP_SDI.2.2/DTBS Upon detection of a data integrity error, the TSF shall 1) prohibit the use of the altered data, 2) inform the S.Sigy about integrity error. Note 39: The integrity of TSF data like RAD shall be protected to ensure the effectiveness of the user authentication. This protection is a specific aspect of the security architecture (cf. ADV_ARC.1). CGA FDP_DAU.2/SVD Data authentication with identity of guarantor Hierarchical to: FDP_DAU.1 Basic data authentication. Dependencies: FIA_UID.1 Timing of identification. FDP_DAU.2.1/SVD The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of SVD. FDP_DAU.2.2/SVD The TSF shall provide CGA with the ability to verify evidence of the va- lidity of the indicated information and the identity of the user that gen- erated the evidence. 8.1.4 Identification and Authentication (FIA) PACE EAC FIA_UID.1 Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 57 SECURITY TARGET FIA_UID.1.1 The TSF shall allow: 1) self-test according to FPT_TST.1 2) to establish the communication channel 3) carrying out the PACE Protocol according to [ICAO_SAC] 4) to read the initialization data in phase “usage/preparation” 5) to read the random identifier in phase “Usage/Preparation” 6) to carry out the Chip Authentication protocol v.1 according to [BSI_TR-03110-1] 7) to carry out the Terminal Authentication protocol v.1 according to [BSI_TR-03110-1] 8) to carry out the PACE Chip Authentication Mapping protocol according to [ICAO_SAC] 9) none 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 al- lowing any other TSF-mediated actions on behalf of that user. Note 40: This SFR has been amended with items from [CC_PP-0056-V2] and with PACE Chip Authentication Mapping. Item (7) of FIA_UID.1.1 applies only to the configurations RSA-PSS- ta, EC-ta and RSA-raw-dec-ta. CGA SCA 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) self-test according to FPT_TST.1 2) identification of the user by means of TSF required by FIA_UID.1 3) establishing a trusted channel between the CGA and the TOE by means of TSF required by FTP_ITC.1/SVD, 4) establishing a trusted channel between the HID and the TOE by means of TSF required by FTP_ITC.1/VAD, 5) none on behalf of the user to be performed before the user is identified. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. PACE EAC FIA_UAU.4/PACE Single-useauthenticationmechanisms-Single-useauthentication of the Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 58 SECURITY TARGET FIA_UAU.4.1/PACE The TSF shall prevent reuse of authentication data related to 1) PACE protocol according to [ICAO_SAC], 2) authentication mechanism based on Triple-DES or AES, 3) Terminal Authentication protocol v.1 according to [BSI_TR-03110-1]. Note 41: The authentication mechanisms may use either a challenge freshly and randomly generated by the TOE to prevent reuse of a response generated by a terminal in a suc- cessful authentication attempt. However, the authentication of Administrator may rely on other mechanisms ensuring protection against replay attacks, such as the use of an internal counter as a diversifier. Note 42: This SFR has been adapted from [CC_PP-0056-V2]. Item (3) of FIA_UAU.4.1 applies only to the configurations RSA-PSS-ta, EC-ta and RSA-raw-dec-ta. Note 43: Authentication data related to PACE protocol according to [ICAO_SAC] include au- thentication data related to PACE Chip Authentication Mapping. PACE EAC FIA_UAU.5/PACE Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/PACE The TSF shall provide: 1) PACE protocol according to [ICAO_SAC], 2) Passive Authentication according to [ICAO_9303_11], 3) Secure Messaging in MAC-ENC mode according to [ICAO_SAC], 4) Symmetric authentication mechanism based on Triple-DES or AES, 5) Chip Authentication protocol v.1 according to [BSI_TR-03110-1], 6) Terminal Authentication protocol v.1 according to [BSI_TR-03110-1]. to support user authentication. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 59 SECURITY TARGET FIA_UAU.5.2/PACE The TSF shall authenticate any user’s claimed identity according to the following rules: 1. Having successfully run the PACE protocol the TOE accepts only received commands with correct message authentication code sent by means of Secure Messaging with the key agreed with the terminal by means of the PACE protocol. 2. The TOE accepts the authentication attempt as Personalization Agent by the symmetric authentication mechanism with Personalization Agent keys. 3. After run of the Chip Authentication protocol version 1 the TOE accepts only received commands with correct message authentication code sent by means of Secure Messaging with key agreed with the terminal by means of the Chip Authentication mechanism v.1. 4. The TOE accepts the authentication attempt by means of the Terminal Authentication protocol v.1 only if the terminal uses the public key presented during the Chip Authentication protocol v.1 and the Secure Messaging established by the Chip Authentication mechanism v.1. 5. The TOE accepts the authentication attempt by means of the Chip Authentication protocol v.1 only if Secure Messaging is established by PACE. 6. none Note44: ThisSFRhasbeenadaptedfrom[CC_PP-0056-V2]. Item(6)ofFIA_UAU.5.1anditem (3) of FIA_UAU.5.2 apply only to the configurations RSA-PSS-ta, EC-ta and RSA-raw-dec-ta. Note 45: PACE Chip Authentication Mapping followed directly by Terminal Authentication v.1, i.e. without preceding Chip Authentication v.1, is not supported by the TOE. This applies only to the configurations RSA-PSS-ta, EC-ta and RSA-raw-dec-ta. PACE EAC FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the PACE protocol or the Chip Authentication protocol version 1 shall be verified as being sent by the Legitimate Terminal. Note 46: This SFR has been adapted from [CC_PP-0068-V2] or [CC_PP-0056-V2], respec- tively. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 60 SECURITY TARGET FIA_AFL.1/RAD Authentication failure handling Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1/RAD The TSF shall detect when 3 unsuccessful authentication attempt oc- curs related to consecutive failed authentication attempts. FIA_AFL.1.2/RAD When the defined number of unsuccessful authentication attempts has been met, the TSF shall block RAD. FIA_AFL.1/Suspend_PIN Authentication failure handling – Suspending PIN Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1/Suspend_PIN The TSF shall detect when 2 unsuccessful authentication attempts oc- currelatedtoconsecutivefailedauthenticationattemptsusingthePIN as the shared password for PACE. FIA_AFL.1.2/Suspend_PIN When the defined number of unsuccessful authentication attempts has been met, the TSF shall suspend the reference value of the PIN according to [BSI_TR-03110-2]. Note 47: This SFR has been adapted from [CC_PP-0086]. FIA_AFL.1/Block_PIN Authentication failure handling – Blocking PIN Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1/Block_PIN The TSF shall detect when 1 unsuccessful authentication attempts oc- cur related to consecutive failed authentication attempts using the suspended PIN as the shared password for PACE. FIA_AFL.1.2/Block_PIN When the defined number of unsuccessful authentication attempts has been met, the TSF shall block the reference value of PIN according to [BSI_TR-03110-2]. Note 48: This SFR has been adapted from [CC_PP-0086]. CGA FIA_API.1 Authentication proof of identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide a Chip Authentication protocol version 1 according to [BSI_TR-03110-1] to prove the identity of the SSCD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 61 SECURITY TARGET 8.1.5 Security Management (FMT) FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification FMT_SMR.1.1 TheTSFshallmaintaintheroles: R.AdminandR.SigyandCertification Service Provider and Document Verifier and Legitimate Terminal FMT_SMR.1.2 The TSF shall be able to associate users with roles. 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) creation and modification of RAD, 2) enabling the signature creation function, 3) modification of the security attribute SCD/SVD management, SCD operational, 4) change the default value of the security attribute SCD Identifier, 5) none. FMT_MOF.1 Management of security functions behavior Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of management functions. FMT_MOF.1.1 The TSF shall restrict the ability to enable the functions signature creation function to R.Sigy. FMT_MSA.1/Admin 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_SMR.1 Security roles FMT_SMF.1 Specification of management functions. FMT_MSA.1.1/Admin TheTSFshallenforcetheSCD/SVD_Generation_SFPtorestricttheabil- ity to modify and none the security attributes SCD/SVD management to R.Admin. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 62 SECURITY TARGET FMT_MSA.1/Signatory 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_SMR.1 Security roles FMT_SMF.1 Specification of management functions. FMT_MSA.1.1/Signatory TheTSFshallenforcetheSignature_Creation_SFPtorestricttheability to modify the security attributes SCD operational to R.Sigy. FMT_MSA.2 Secure security attributes Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles. FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for SCD/SVD Management and SCD operational. FMT_MSA.3 Static attribute initialization Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles. FMT_MSA.3.1 The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_Transfer_SFP and Signature_Creation_SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 TSF shall allow the R.Admin to specify alternative initial values to over- ride the default values when an object or information is created. FMT_MSA.4 Security attribute value inheritance Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 63 SECURITY TARGET FMT_MSA.4.1 The TSF shall use the following rules to set the value of security at- tributes: 1) If S.Admin successfully generates an SCD/SVD pair without S.Sigy being authenticated the security attribute “SCD operational of the SCD” shall be set to “no” as a single operation. 2) If S.Sigy successfully generates an SCD/SVD pair the security attribute “SCD operational of the SCD” shall be set to “yes” as a single operation. Note 49: The TOE may not support generating an SVD/SCD pair by the signatory alone, in which case rule (2) is not relevant. EAC FMT_MTD.1/CVCA_UPD Management of TSF data – Country Verifier Certification Authority Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/CVCA_UPD The TSF shall restrict the ability to update the 1) Certification Authority Public Key, 2) Certification Authority Certificate, to Certification Service Provider Note 50: The Certification Service Provider updates its asymmetric key pair and distributes the public key be means of the CA link-certificates (cf. [BSI_TR-03110-1]). The TOE up- dates its internal trust-point if a valid CA link-certificates is provided by the terminal (cf. [BSI_TR-03110-1]). Note 51: This SFR has been adapted from [CC_PP-0056-V2]. The objects Country Verifying Certification Authority Public Key and Country Verifier Certification Authority Certificate have been changed to Certification Authority Public Key and Certification Authority Certificate, re- spectively. The role Country Verifying Certification Authority, which does not exist in this con- text, has been changed to Certification Service Provider. This SFR applies only to the config- urations RSA-PSS-ta, EC-ta and RSA-raw-dec-ta. EAC FMT_MTD.1/DATE Management of TSF data – Current date Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/DATE The TSF shall restrict the ability to modify the current date to 1) Certification Service Provider, 2) Document Verifier, 3) Legitimate Terminal. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 64 SECURITY TARGET Note 52: The authorized roles are identified in their certificate (cf. [BSI_TR-03110-1]) and authorizedbyvalidationofthecertificatechain. Theauthorizedroleoftheterminalispartof theCertificateHolderAuthorizationinthecardverifiablecertificateprovidedbytheterminal for the identification and the Terminal Authentication v.1 (cf. to [BSI_TR-03110-1]). Note 53: This SFR has been adapted from [CC_PP-0056-V2]. The role Country Verifying Cer- tification Authority, which does not exist in this context, has been changed to Certification Service Provider. The role Domestic Extended Inspection System, which does not exist in this context, has been changed to Legitimate Terminal. This SFR applies only to the configura- tions RSA-PSS-ta, EC-ta and RSA-raw-dec-ta. PACE EAC FMT_MTD.1/KEY_READ Management of TSF data – Key read Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read the 1) PACE passwords, 2) Chip Authentication private key, 3) PACE Chip Authentication Mapping private key, 4) Personalization keys 5) Electronic signature keys to none Note 54: This SFR has been adapted from [CC_PP-0056-V2]. The object electronic signature keys has been added. FMT_MTD.1/Admin Management of TSF data Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of management functions FMT_MTD.1.1/Admin The TSF shall restrict the ability to create the RAD to R.Admin FMT_MTD.1/Signatory Management of TSF data Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of management functions FMT_MTD.1.1/Signatory The TSF shall restrict the ability to modify and none the RAD to R.Sigy MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 65 SECURITY TARGET 8.1.6 Protection of the TSF (FPT) FPT_EMS.1/SSCD TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1/SSCD The TOE shall not emit information about IC power consumption and command execution time in excess of non-useful information enabling access to RAD and SCD. FPT_EMS.1.2/SSCD The TSF shall ensure any unauthorized users are unable to use the fol- lowing interface smart card circuit contacts to gain access to RAD and SCD. PACE EAC FPT_EMS.1/KEYS TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1/KEYS The TOE shall not emit information about IC power consumption and command execution time in excess of non-useful information enabling access to 1) Chip Authentication session keys, 2) PACE session keys (PACE-KMAC, PACE-KEnc), 3) the ephemeral private key ephem-SKPICC-PACE, 4) Manufacturer authentication key, 5) administration keys, 6) personalization keys, 7) Chip Authentication private keys, 8) PACE Chip Authentication Mapping private keys, 9) decryption keys. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 66 SECURITY TARGET FPT_EMS.1.2/KEYS TheTSFshallensureanyusersareunabletousethefollowinginterface smart card circuit contacts to gain access to 1) Chip Authentication session keys, 2) PACE session keys (PACE-KMAC, PACE-KEnc), 3) the ephemeral private key ephem-SKPICC-PACE, 4) Manufacturer authentication key, 5) administration keys, 6) personalization keys, 7) Chip Authentication private keys, 8) PACE Chip Authentication Mapping private keys, 9) decryption keys. Note 55: This SFR has been adapted from [CC_PP-0056-V2]. FPT_FLS.1 Failure with preservation of secure state Hierarchical to: No other components. Dependencies: No dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of fail- ures occur: 1) self-test according to FPT_TST fails 2) exposure to out-of-range operating conditions where therefore a malfunction could occur FPT_PHP.1 Passive detection of physical attack Hierarchical to: No other components. Dependencies: No dependencies. FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical tampering with the TSF’s devices or TSF’s elements has occurred. FPT_PHP.3 Resistance to physical attack Hierarchical to: No other components. Dependencies: No dependencies. FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing to the TSF by responding automatically such that the SFRs are always en- forced. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 67 SECURITY TARGET FPT_TST.1 TSF testing Hierarchical to: No other components. Dependencies: No dependencies. FPT_TST.1.1 The TSF shall run a suite of self-tests during initial start-up to demon- strate the correct operation of the TSF. FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of TSF data. FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of TSF. CGA FTP_ITC.1/SVD Inter-TSF trusted channel Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/SVD The TSF shall provide a communication channel between itself and an- other trusted IT product CGA that is logically distinct from other com- munication channels and provides ensured identification of its end points and protection of the channel data from modification or disclo- sure. FTP_ITC.1.2/SVD The TSF shall permit another trusted IT product to initiate communi- cation via the trusted channel. FTP_ITC.1.3/SVD The TSF or the CGA shall initiate communication via the trusted chan- nel for 1) data authentication with identity of guarantor according to FIA_API.1 and FDP_DAU.2/SVD, 2) none. SCA FTP_ITC.1/VAD Inter-TSF trusted channel – TC Human Interface Device Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/VAD The TSF shall provide a communication channel between itself and an- other trusted IT product HID that is logically distinct from other com- munication channels and provides ensured identification of its end points and protection of the channel data from modification or disclo- sure. FTP_ITC.1.2/VAD The TSF shall permit the remote trusted IT product to initiate commu- nication via the trusted channel. FTP_ITC.1.3/VAD The TSF or the HID shall initiate communication via the trusted chan- nel for 1) user authentication according to FIA_UAU.1, 2) none. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 68 SECURITY TARGET Note 56: The PACE protocol used for authentication is a zero-knowledge protocol and thus protects the confidentiality of the VAD implicitly. SCA FTP_ITC.1/DTBS Inter-TSF trusted channel Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/DTBS The TSF shall provide a communication channel between itself and an- other trusted IT product SCA that is logically distinct from other com- munication channels and provides ensured identification of its end points and protection of the channel data from modification or disclo- sure. FTP_ITC.1.2/DTBS The TSF shall permit the remote trusted IT product to initiate commu- nication via the trusted channel. FTP_ITC.1.3/DTBS The TSF or the SCA shall initiate communication via the trusted chan- nel for 1) signature creation, 2) none. 8.2 TOE Security Assurance Requirements Assurance class Assurance components ADV: Development ADV_ARC.1 ArchitecturalDesignwithdomainsepara- tion and non-bypassability ADV_FSP.5 Complete semi-formal functional specifi- cation with additional error information ADV_IMP.1 Implementation representation of the TSF ADV_INT.2 Well-structured internals ADV_TDS.4 Semiformal modular design AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC: Life-cycle support ALC_CMC.4 Production support, acceptance proce- dures 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 stan- dards MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 69 SECURITY TARGET Assurance class Assurance components ASE: Security Target evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE: Tests ATE_COV.2 Analysis of coverage ATE_DPT.3 Testing: modular design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA: Vulnerability assessment AVA_VAN.5 Advanced methodical vulnerability anal- ysis Table 8.3: Assurance Requirements: EAL5 augmented with ALC_DVS.2 and AVA_VAN.5 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 70 SECURITY TARGET 9 Rationale 9.1 Security Requirements Rationale 9.1.1 Security Requirements Coverage Security objectives and security functional requirements that are added by PP SSCD KG TC- CGA or PP SSCD KG TCSCA are color coded for better readability. Security functional require- ments taken from [CC_PP-0056-V2] or [CC_PP-0068-V2] or modified to meet those PPs, re- spectively, are given in italics, security functional requirements taken from [CC_PP-0086] are given in bold face. OT.Lifecycle_Security OT.SCD/SVD_Auth_Gen OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.Sigy_SigF OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance OT.TOE_SSCD_Auth OT.TOE_TC_SVD_Exp OT.TOE_TC_VAD_Imp OT.TOE_TC_DTBS_Imp FCS_CKM.1/SCD x x x x FCS_CKM.1/DH_PACE x x x x x FCS_CKM.1/CA_STATIC x x x x x FCS_CKM.1/CA x x x x FCS_CKM.4 x x x x x FCS_COP.1/SCD x x FCS_COP.1/SHA x x FCS_COP.1/CA_ENC x x x x FCS_COP.1/CA_MAC x x x x FCS_COP.1/SIG_VER x x x x FCS_COP.1/PACE_ENC x x x x x FCS_COP.1/PACE_MAC x x x x x FCS_RND.1 x x x x x FDP_ACC.1/TRM x x FDP_AFC.1/TRM x x MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 71 SECURITY TARGET OT.Lifecycle_Security OT.SCD/SVD_Auth_Gen OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.Sigy_SigF OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance OT.TOE_SSCD_Auth OT.TOE_TC_SVD_Exp OT.TOE_TC_VAD_Imp OT.TOE_TC_DTBS_Imp FDP_ACC.1/ SCD/SVD_Generation x x FDP_AFC.1/ SCD/SVD_Generation x x FDP_ACC.1/ SVD_Transfer x x FDP_AFC.1/ SVD_Transfer x x FDP_ACC.1/ Signature_Creation x x FDP_AFC.1/ Signature_Creation x x FDP_ACC.1/ Signature_Creation/ N-QES x x FDP_AFC.1/ Signature_Creation/ N-QES x x FDP_UIT.1/ DTBS x FDP_RIP.1 x x FDP_SDI.2/Persistent x x x FDP_SDI.2/DTBS x x FDP_DAU.2/SVD x FIA_UID.1 x x x x x x FIA_UAU.1 x x x FIA_UAU.4/PACE x x x x x FIA_UAU.5/PACE x x x x x FIA_UAU.6 x x x x x FIA_AFL.1/RAD x FIA_AFL.1/ Suspend_PIN x FIA_AFL.1/Block_PIN x FIA_API.1 x x FMT_SMR.1 x x FMT_SMF.1 x x x FMT_MOF.1 x x MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 72 SECURITY TARGET OT.Lifecycle_Security OT.SCD/SVD_Auth_Gen OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.Sigy_SigF OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance OT.TOE_SSCD_Auth OT.TOE_TC_SVD_Exp OT.TOE_TC_VAD_Imp OT.TOE_TC_DTBS_Imp FMT_MSA.1/Admin x x FMT_MSA.1/Signatory x x FMT_MSA.2 x x x FMT_MSA.3 x x x FMT_MSA.4 x x x x FMT_MTD.1/CVCA_UPD x x x x FMT_MTD.1/DATE x x x x FMT_MTD.1/KEY_READ x x x x FMT_MTD.1/Admin x x FMT_MTD.1/Signatory x x FPT_EMS.1/SSCD x x FPT_EMS.1/KEYS x x FPT_FLS.1 x FPT_PHP.1 x FPT_PHP.3 x x FPT_TST.1 x x x FTP_ITC.1/SVD x FTP_ITC.1/VAD x FTP_ITC.1/DTBS x Table 9.1: Mapping of functional requirements to security objectives for the TOE 9.1.2 Security Functional Requirements Sufficiency OT.Lifecycle_Security (Life cycle security) is provided by the SFRs • FCS_CKM.1/SCD (for SCD/SVD generation), • FCS_COP.1/SCD (for SCD usage) and • FCS_CKM.4 (for SCD destruction) ensuring cryptographically secure life cycle of the SCD. The SCD/SVD generation is controlled by TSF according to • FDP_ACC.1/SCD/SVD_Generation and • FDP_ACF.1/SCD/SVD_Generation. The SVD transfer for certificate generation is controlled by TSF according to • FDP_ACC.1/SVD_Transfer and MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 73 SECURITY TARGET • FDP_ACF.1/SVD_Transfer. The SCD usage is ensured by access control • FDP_ACC.1/Signature_Creation, • FDP_AFC.1/Signature_Creation, • FDP_ACC.1/Signature_Creation/N-QES, • FDP_AFC.1/Signature_Creation/N-QES which is based on the security attribute secure TSF management according to • FMT_MOF.1, • FMT_MSA.1/Admin, • FMT_MSA.1/Signatory, • FMT_MSA.2, • FMT_MSA.3, • FMT_MSA.4, • FMT_MTD.1/Admin, • FMT_MTD.1/Signatory, • FMT_SMF.1 and • FMT_SMR.1. The test functions • FPT_TST.1 provides failure detection throughout the life cycle. (Life cycle security) in the phase “usage/preparation” is provided by the SFRs • FCS_CKM.1/DH_PACE, • FCS_CKM.1/CA_STATIC, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_COP.1/SHA, • FCS_RND.1, • FIA_UID.1, • FIA_UAU.4/PACE, • FIA_UAU.4/PACE, • FIA_UAU.6 and • FMT_MTD.1/KEY_READ. (Life cycle security) in the phase “usage/operational” is provided by the SFRs • FCS_CKM.1/DH_PACE, • FCS_CKM.1/CA, • FCS_COP.1/SHA, MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 74 SECURITY TARGET • FCS_COP.1/CA_ENC, • FCS_COP.1/CA_MAC, • FCS_COP.1/SIG_VER, • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_RND.1, • FDP_ACC.1/TRM, • FDP_AFC.1/TRM, • FIA_API.1, • FIA_UID.1, • FIA_UAU.4/PACE, • FIA_UAU.4/PACE, • FIA_UAU.6, • FMT_MTD.1/CVCA_UPD, • FMT_MTD.1/DATE and • FMT_MTD.1/KEY_READ. OT.SCD/SVD_Auth_Gen (Authorized SCD/SVD generation) addresses that generation of a SCD/SVD pair requires proper user authentication. The TSF specified by • FIA_UID.1 and • FIA_UAU.1 provide user identification and user authentication prior to enabling access to autho- rized functions. The SFR • FDP_ACC.1/SCD/SVD_Generation and • FDP_ACF.1/SCD/SVD_ Generation provideaccesscontrolfortheSCD/SVDgeneration. Thesecurityattributesoftheauthen- ticated user are provided by • FMT_MSA.1/Admin, • FMT_MSA.2 and • FMT_MSA.3 for static attribute initialization. The SFR • FMT_MSA.4 defines rules for inheritance of the security attribute “SCD operational” of the SCD. OT.SCD_Unique (Uniqueness of the signature creation data) implements the requirement of practically unique SCD as laid down in Annex III, paragraph 1(a), which is provided by the cryptographic algorithms specified by • FCS_CKM.1/SCD. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 75 SECURITY TARGET OT.SCD_SVD_Corresp (CorrespondencebetweenSVDandSCD) addressesthattheSVDcor- responds to the SCD implemented by the TOE. This is provided by the algorithms specified by • FCS_CKM.1/SCD to generate corresponding SVD/SCD pairs. The security functions specified by • FDP_SDI.2/Persistent ensure that the keys are not modified, so to retain the correspondence. Moreover, the SCD Identifier allows the environment to identify the SCD and to link it with the appropriate SVD. The management functions identified by • FMT_SMF.1 and by • FMT_MSA.4 allow R.Admin to modify the default value of the security attribute SCD Identifier. OT.SCD_Secrecy (Secrecy of signature creation data) is provided by the security functions specified by the following SFRs. • FCS_CKM.1/SCD ensures the use of secure cryptographic algorithms for SCD/SVD gen- eration. CryptographicqualityofSCD/SVDpairshallpreventdisclosureofSCDbycryp- tographic attacks using the publicly known SVD. • FDP_RIP.1 and • FCS_CKM.4 ensure that residual information on SCD is destroyed after the SCD has been used for signature creation and that destruction of SCD leaves no residual infor- mation. • FDP_SDI.2/Persistent ensures that no critical data is modified which could alter the efficiency of the security functions or leak information of the SCD. • FPT_TST.1 tests the working conditions of the TOE and • FPT_FLS.1 guarantees a secure state when integrity is violated and thus assures that the specified security functions are operational. An example where compromising er- ror conditions are countered by FPT_FLS.1 is fault injection for differential fault analy- sis (DFA). • FPT_EMS.1/SSCD and • FPT_PHP.3 require additional security features of the TOE to ensure the confidentiality of the SCD. OT.Sig_Secure (Cryptographic security of the electronic signature) is provided by the cryp- tographic algorithms specified by • FCS_COP.1/SCD, which ensures the cryptographic robustness of the signature algo- rithms, • FDP_SDI.2/Persistent corresponds to the integrity of the SCD implemented by the TOE and • FPT_TST.1 ensures self-tests ensuring correct signature creation. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 76 SECURITY TARGET OT.Sigy_SigF (Signature creation function for the legitimate signatory only) is provided by an SFR for identification, authentication and access control. • FIA_UAU.1 and • FIA_UID.1 ensure that no signature creation function can be invoked before the signa- tory is identified and authenticated. • FMT_MTD.1/Admin and • FMT_MTD.1/Signatory manage the authentication function. • FIA_AFL.1/RAD provides protection against a number of attacks, such as cryptographic extraction of residual information, or brute force attacks against authentication. • FIA_AFL.1/Suspend_PIN provides protection against denial-of-service attacks. • FIA_AFL.1/Block_PIN provides protection against brute force attacks against authen- tication. • FDP_SDI.2/DTBS ensures the integrity of stored DTBS and • FDP_RIP.1 prevents misuse of any resources containing the SCD after de-allocation (e.g. after the signature creation process). • FDP_ACC.1/Signature_Creation, • FDP_ACF.1/Signature_Creation, • FDP_ACC.1/Signature_Creation/N-QES and • FDP_ACF.1/Signature_Creation/N-QESprovideaccesscontrolbasedonthesecurityat- tributes managed according to the SFRs • FMT_MTD.1/Signatory, • FMT_MSA.2, • FMT_MSA.3 and • FMT_MSA.4. • FMT_SMF.1 and • FMT_SMR.1 list these management functions and the roles. These ensure that the sig- nature process is restricted to the signatory. • FMT_MOF.1 restricts the ability to enable the signature creation function to the signa- tory. • FMT_MSA.1/Signatory restricts the ability to modify the security attributes SCD oper- ational to the signatory. In the phase “usage/operational” Signature creation function for the legitimate signatory only is additionally provided by the SFRs • FCS_CKM.1/DH_PACE, • FCS_COP.1/SHA, • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_RND.1, • FIA_UID.1, MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 77 SECURITY TARGET • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, • FIA_UAU.6 and • FIA_API.1. OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) ensures that the DTBS/R is not altered by the TOE. The integrity functions specified by • FDP_SDI.2/DTBS require that the DTBS/R has not been altered by the TOE. OT.EMSEC_Design (Provide physical emanations security) covers that no intelligible infor- mation is emanated. This is provided by • FPT_EMS.1.1/SSCD and • FPT_EMS.1.1/KEYS. OT.Tamper_ID (Tamper detection) is provided by • FPT_PHP.1 by the means of passive detection of physical attacks. OT.Tamper_Resistance (Tamper resistance) is provided by • FPT_EMS.1.1/KEYS and • FPT_PHP.3 to resist physical attacks. OT.TOE_SSCD_Auth (Authentication proof as SSCD) requires the TOE to provide security CGA mechanisms to identify and to authenticate themselves as SSCD, which is directly provided by • FIA_API.1. • FIA_UAU.1 allows (additionally to PP SSCD KG) establishment of the trusted channel before (human) user is authenticated. Furthermore • FCS_CKM.1/CA_STATIC provides the keys for the Chip Authentication protocol. OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export) requires the TOE to provide a CGA trusted channel to the CGA to protect the integrity of the SVD exported to the CGA, which is directly provided by • the SVD transfer for certificate generation controlled by TSF according to – FDP_ACC.1/SVD_Transfer and – FDP_ACF.1/SVD_Transfer. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 78 SECURITY TARGET • FDP_DAU.2/SVD, which requires the TOE to provide CGA with the ability to verify ev- idence of the validity of the SVD and the identity of the user that generated the evi- dence. • FTP_ITC.1/SVD, which requires the TOE to provide a trusted channel to the CGA. The functionality for integrity and confidentiality is provided by • FCS_CKM.1/DH_PACE, • FCS_CKM.1/CA_STATIC, • FCS_CKM.1/CA, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/CA_ENC, • FCS_COP.1/CA_MAC, • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_RND.1, • FDP_ACC.1/TRM, • FDP_AFC.1/TRM, • FIA_UID.1, • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, • FIA_UAU.6, • FMT_MTD.1/CVCA_DIS, • FMT_MTD.1/DATE and • FMT_MTD.1/KEY_READ. OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) is provided by SCA • FTP_ITC.1/VAD to provide a trusted channel to protect the VAD provided by the HID to the TOE. The functionality for integrity and confidentiality is provided by • FCS_CKM.1/DH_PACE, • FCS_CKM.1/CA_STATIC, • FCS_CKM.1/CA, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/CA_ENC, • FCS_COP.1/CA_MAC, • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_RND.1, • FIA_UID.1, MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 79 SECURITY TARGET • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, • FIA_UAU.6, • FMT_MTD.1/CVCA_DIS, • FMT_MTD.1/DATE and • FMT_MTD.1/KEY_READ. OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS) is provided by SCA • FTP_ITC.1/DTBS to provide a trusted channel to protect the DTBS provided by the SCA to the TOE and by • FDP_UIT.1/DTBS, which requires the TSF to verify the integrity of the received DTBS. The functionality for integrity and confidentiality is provided by • FCS_CKM.1/DH_PACE, • FCS_CKM.1/CA_STATIC, • FCS_CKM.1/CA, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/CA_ENC, • FCS_COP.1/CA_MAC, • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_RND.1, • FIA_UID.1, • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, • FIA_UAU.6, • FMT_MTD.1/CVCA_DIS, • FMT_MTD.1/DATE and • FMT_MTD.1/KEY_READ. 9.1.3 Satisfaction of Dependencies of Security Requirements Functional requirements Dependencies Satisfied by FCS_CKM.1/SCD [FCS_CKM.2 or FCS_COP.1], FCS_CKM.4 FCS_COP.1/SCD, FCS_CKM.4 FCS_CKM.1/DH_PACE [FCS_CKM.2 or FCS_COP.1], FCS_CKM.4 FCS_COP.1/PACE_ENC, FCS_COP.1/PACE_MAC, FCS_CKM.4 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 80 SECURITY TARGET Functional requirements Dependencies Satisfied by FCS_CKM.1/CA_STATIC [FCS_CKM.2 or FCS_COP.1], FCS_CKM.4 FCS_COP.1/CA_ENC, FCS_COP.1/CA_MAC, FCS_CKM.4 FCS_CKM.1/CA [FCS_CKM.2 or FCS_COP.1], FCS_CKM.4 FCS_COP.1/CA_ENC, FCS_COP.1/CA_MAC, FCS_CKM.4 FCS_CKM.4 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1/SCD, FCS_CKM.1/DH_PACE, FCS_CKM.1/CA FCS_COP.1/SCD [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 FCS_CKM.1/SCD, FCS_CKM.4 FCS_COP.1/SHA [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 see justification FCS_COP.1/CA_ENC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 FCS_CKM.1/CA, FCS_CKM.4 FCS_COP.1/CA_MAC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 FCS_CKM.1/CA, FCS_CKM.4 FCS_COP.1/SIG_VER [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 FCS_CKM.1/CA, FCS_CKM.4 FCS_COP.1/PACE_ENC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 FCS_CKM.1/DH_PACE, FCS_CKM.4 FCS_COP.1/PACE_MAC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 FCS_CKM.1/DH_PACE, FCS_CKM.4 FCS_RND.1 No dependencies n/a FDP_ACC.1/TRM FDP_ACF.1 FDP_ACF.1/TRM FDP_ACF.1/TRM FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/TRM, FMT_MSA.3 FDP_ACC.1/ SCD/SVD_Generation FDP_ACF.1 FDP_ACF.1/ SCD/SVD_Generation FDP_ACF.1/ SCD/SVD_Generation FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/ SCD/SVD_Generation, FMT_MSA.3 FDP_ACC.1/SVD_Transfer FDP_ACF.1 FDP_ACF.1/SVD_Transfer FDP_ACF.1/SVD_Transfer FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/SVD_Transfer, FMT_MSA.3 FDP_ACC.1/ Signature_Creation FDP_ACF.1 FDP_ACF.1/ Signature_Creation FDP_ACF.1/ Signature_Creation FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/ Signature_Creation, FMT_MSA.3 FDP_ACC.1/Signature_ Creation/N-QES FDP_ACF.1 FDP_ACF.1/Signature_ Creation/N-QES MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 81 SECURITY TARGET Functional requirements Dependencies Satisfied by FDP_ACF.1/Signature_ Creation/N-QES FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/Signature_ Creation/N-QES, FMT_MSA.3 FDP_UIT.1/DTBS [FDP_ACC.1 or FDP_IFC.1], [FTP_ITC.1 or FTP_TRP.1] FDP_ACC.1/ Signature_Creation, FDP_ACC.1/Signature_ Creation/N-QES, FTP_ITC.1/DTBS FDP_RIP.1 No dependencies n/a FDP_SDI.2/Persistent No dependencies n/a FDP_SDI.2/DTBS No dependencies n/a FDP_DAU.2/SVD FIA_UID.1 FIA_UID.1 FIA_UID.1 No dependencies n/a FIA_UAU.1 FIA_UID.1 FIA_UID.1 FIA_UAU.4/PACE No dependencies n.a. FIA_UAU.5/PACE No dependencies n.a. FIA_UAU.6 No dependencies n.a. FIA_AFL.1/RAD FIA_UAU.1 FIA_UAU.1 FIA_AFL.1/Suspend_PIN FIA_UAU.1 FIA_UAU.1 FIA_AFL.1/Block_PIN FIA_UAU.1 FIA_UAU.1 FIA_API.1 No dependencies n/a FMT_SMR.1 FIA_UID.1 FIA_UID.1 FMT_SMF.1 No dependencies n/a. FMT_MOF.1 FMT_SMR.1, FMT_SMF.1 FMT_SMR.1, FMT_SMF.1 FMT_MSA.1/Admin [FDP_ACC.1 or FDP_IFC.1], FMT_SMR.1, FMT_SMF.1 FDP_ACC.1/ SCD/SVD_Generation, FMT_SMR.1, FMT_SMF.1 FMT_MSA.1/Signatory [FDP_ACC.1 or FDP_IFC.1], FMT_SMR.1, FMT_SMF.1 FDP_ACC.1/ Signature_Creation, FMT_SMR.1, FMT_SMF.1 FMT_MSA.2 [FDP_ACC.1 or FDP_IFC.1], FMT_MSA.1, FMT_SMR.1 FDP_ACC.1/SCD/SVD_ Generation, FDP_ACC.1/ Signature_Creation, FDP_ACC.1/Signature_ Creation/N-QES, FMT_SMR.1, FMT_MSA.1/Admin, FMT_MSA.1/Signatory FMT_MSA.3 FMT_MSA.1, FMT_SMR.1 FMT_MSA.1/Admin, FMT_MSA.1/Signatory, FMT_SMR.1 MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 82 SECURITY TARGET Functional requirements Dependencies Satisfied by FMT_MSA.4 [FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1/SCD/SVD_ Generation, FDP_ACC.1/ Signature_Creation, FDP_ACC.1/Signature_ Creation/N-QES FMT_MTD.1/CVCA_UPD FMT_SMR.1, FMT_SMF.1, FMT_SMR.1. FMT_SMF.1 FMT_MTD.1/DATE FMT_SMR.1, FMT_SMF.1, FMT_SMR.1. FMT_SMF.1 FMT_MTD.1/KEY_READ FMT_SMR.1, FMT_SMF.1, FMT_SMR.1. FMT_SMF.1 FMT_MTD.1/Admin FMT_SMR.1, FMT_SMF.1, FMT_SMR.1. FMT_SMF.1 FMT_MTD.1/Signatory FMT_SMR.1, FMT_SMF.1, FMT_SMR.1. FMT_SMF.1 FPT_EMS.1/SSCD No dependencies n/a FPT_EMS.1/KEYS No dependencies n/a FPT_FLS.1 No dependencies n/a FPT_PHP.1 No dependencies n/a FPT_PHP.3 No dependencies n/a. FPT_TST.1 No dependencies n/a FTP_ITC.1/SVD No dependencies n/a FTP_ITC.1/VAD No dependencies n/a FTP_ITC.1/DTBS No dependencies n/a Table 9.3: Satisfaction of dependencies of security functional requirements Justification The hash algorithm required by the SFR FCS_COP.1/SHA does not need any key material. Therefore neither a key generation (FCS_CKM.1 nor an import (FDP_ITC.1/2) is necessary. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 83 SECURITY TARGET Assurance requirement(s) Dependencies Satisfied by EAL5 package (dependencies of EAL5 package are not reproduced here) By construction, all dependen- cies are satisfied in a CC EAL package ALC_DVS.2 no dependencies AVA_VAN.5 ADV_ARC.1 ADV_ARC.1 ADV_FSP.4 ADV_FSP.5 ADV_TDS.3 ADV_TDS.4 ADV_IMP.1 ADV_IMP.1 AGD_OPE.1 AGD_OPE.1 AGD_PRE.1 AGD_PRE.1 ATE_DPT.1 ATE_DPT.3 (all are included or exceeded in EAL5 package) Table 9.4: Satisfaction of dependencies of security assurance requirements 9.1.4 Rationale for Chosen Security Assurance Requirements The assurance level for PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA is EAL5 aug- mented by AVA_VAN.5 Advanced methodical vulnerability analysis The TOE is intended to function in a variety of signature creation systems for qualified electronic signatures. Due to the nature of its intended application, i.e. the TOE may be issued to users and may not be directly under the control of trained and dedicated admin- istrators. As a result, it is imperative that misleading, unreasonable and conflicting guid- ance is absent from the guidance documentation, and that secure procedures for all modes of operation have been addressed. Insecure states should be easy to detect. The TOE shall be shown to be highly resistant to penetration attacks to meet the security objectives OT.SCD_Secrecy, OT.Sigy_SigF and OT.Sig_Secure. This ST chooses the higher assurance level EAL5 augmented by AVA_VAN.5 Advanced methodical vulnerability analysis ALC_DVS.2 Sufficiency of security measures The requirements of the claimed protection profiles are met or exceeded and the de- pendencies are fulfilled as shown in table 9.4. The augmentation ALC_DVS.2 is chosen in addition to the requirements of the protection profiles and the EAL5 package. It provides higher assurance of the security of the TOEs development and manufacturing. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 84 SECURITY TARGET 10 TOE Summary Specification (ASE_TSS.1) This chapter describes the TOE security functions and the assurance measures covering the requirements of the previous chapter. 10.1 TOE Security Functions This chapter gives the overview description of the different TOE security functions compos- ing the TSF. 10.1.1 TOE Security Functions from Hardware (IC) and Cryptographic Library 10.1.1.1 F.IC_CL: Security Functions of the Hardware (IC) and Cryptographic Library Thissecurityfunctioncoversthesecurityfunctionsofthehardware(IC)aswellasofthecryp- tographic library. The Security Target of the hardware [NXP_ST-P60] defines the following security services and security features: SS.RNG Random number generator SS.TDES Triple-DES coprocessor SS.AES AES coprocessor SS.RECONFIG Post delivery configuration SF.OPC Control of operating conditions SF.PHY Protection against physical manipulation of the • IC hardware • Security IC Dedicated Software in ROM • Security IC Embedded Software in ROM and EEPROM • Application data in EEPROM and RAM including TSF data in the security rows • User data and TSF data against disclosure by physical probing SF.LOG Logical protection SF.COMP Protection of mode control for • Boot mode • Test mode MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 85 SECURITY TARGET • Firmware mode SF.MEM_ACC Memory access control SF.SFR_ACC Special function register access control SF.FFW Firmware firewall SF.FIRMWARE Firmware support SF.PUF User data protection using PUF Note: The security functionality concerning MIFARE and DESFire defined in the Se- curity Target of the hardware is not used by the TOE and, thus, not listed here. The Security Target of the crypto library [NXP_ST-P60_CL] defines the following security functionality: SS.SW_AES AES cryptographic function SS.SW_DES DES cryptographic function SS.RSA RSA Implementation for data en- and decryption and signature and verification SS.RSA_Pad RSA implementation supporting EME-OAEP and EMSA-PSS signature schemes SS.RSA_PublicExp RSAimplementationforcomputationofanRSApublickey(notused by TOE) SS.ECDSA ECDSA signature generation and signature verification SS.ECC_ DHKE Diffie-Hellman key exchange according to ISO/IEC 15946-3 SS.ECC_Additional Full ECC point addition and check for EC domain parameter SS.RSA_KeyGen Functions to generate RSA key pairs SS.ECC_KeyGen ECC over GF(p) key generation SS.SHA Functions for secure hash algorithms SHA-1, -224, -256, -384 and -512 according to FIPS 180-4 SS.SW_RNG Implementation of the software RNG and tests for the hardware RNG SS.COPY Functionality to copy memory content in a secure manner SS.COMPARE Functionality to compare memory content in a secure manner SS.ModMultiply Functionality to modular multiply different blocks of memory content in a secure manner SS.ModAddSub Functionality to modular add and subtract different blocks of memory content in a secure manner (not used by TOE) SF.Object_Reuse Internal security measures to clear memory areas after usage 10.1.2 TOE Security Functions from Embedded Software (ES) – Operat- ing system 10.1.2.1 F.Access_Control This TSF regulates all access by external entities to operations of the TOE which are only executed after this TSF allowed access. This function consists of following elements: MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 86 SECURITY TARGET 1. Access to objects is controlled based on subjects, objects (any file) and security at- tributes. 2. No access control policy allows reading of any key. 3. Any access not explicitly allowed is denied. 4. Access Control in development phase enforces development policy: Configuration of the TOE, configuring of access control policy and doing key management (PACE and EACv1) only by the Manufacturer or on behalf of him (see F.Management). 5. Access Control in usage/preparation phase enforces personalization policy: Writing of user data, authentication data and SCD/SVD only by the Administrator identified with its authentication key (see F.Management). 6. Access Control in usage/operational phase enforces operational use policy: Opera- tion of the signature creation function only by the Signatory who must activate the SSCD application before first usage; generation and writing of SCD/SVD only by the Signatory identified with its authentication key (see F.Management). 10.1.2.2 F.Identification_Authentication This function provides identification/authentication of the user roles • Administrator • Signatory • Certificate Service Provider • Document Verifier • Legitimate Terminal by the methods: • PACE authentication method according to [BSI_TR-03110-1, BSI_TR-03110-2] with the following properties: – It uses PIN, PUK or CAN. – The method is configured to set the card to a suspended state before the secret is finally blocked (only PIN and PUK) or to delay the processing of the authenti- cation command after a failed authentication (CAN). – The cryptographic method for confidentiality is AES/CBC or 3DES/CBC provided by F.Crypto. – The cryptographic method for authenticity is CMAC or Retail-MAC provided by F.Crypto. – On error (wrong MAC, wrong challenge) the user role is not identi- fied/authenticated. – A usage counter of 50.000 prevents the unlimited usage of PIN and PUK. – On success the session keys are created and stored for Secure Messaging. – The Secure Messaging session is limited by a Secure Messaging counter of 500.000; the decrease of the counter is depending on the length of the command and response APDUs. – Keys and data in transient memory are overwritten after usage. – PACE Chip Authentication Mapping can optionally be used to authenticate the chip. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 87 SECURITY TARGET • Chip Authentication with the following properties: – According to [BSI_TR-03110-1] using ECDH from F.IC_CL. – A usage counter of 50.000 prevents the unlimited usage of the key. – Session keys are created and stored for Secure Messaging replacing existing ses- sion keys. – The Secure Messaging session is limited by a Secure Messaging counter of 500.000; the decrease of the counter is depending on the length of the command and response APDUs. • Terminal Authentication with the following properties: – According to [BSI_TR-03110-1] checking certificates with ECDSA from F.IC_CL. – It uses a challenge from the card. – Usable only in a Secure Messaging session with Chip Authentication key. – It distinguishes between the roles: * Certificate Service Provider * Document Verifier * Legitimate Terminal – Update of CVCA certificate is allowed for Certificate Service Provider. – Update of current date is allowed for Certificate Service Provider, Document Ver- ifier and Legitimate Terminal. – The challenge-response authentication is only performed with a public key from an IS certificate. – Verifying validity of certificate chain: * Certificates must be in the sequence: known CVCA [> CVCA...]> DV > IS. * Expiration dates must not be before the current date with the exception of CVCA. • Secure Messaging with the following properties: – The cryptographic method for confidentiality is AES/CBC or 3DES/CBC provided by F.Crypto. – The cryptographic method for authenticity is CMAC or Retail-MAC provided by F.Crypto. – In a Secure Messaging protected command the method for confidentiality and the method for authenticity must be present. – The Secure Messaging session is limited by a Secure Messaging counter of 500.000; the decrease of the counter is depending on the length of the command and response APDUs. – The initialization vector is a zero-IV for 3DES encryption and an encrypted Send Sequence Counter (SSC) for AES encryption, CMAC and Retail-MAC. – A session key is used. – On any command that is not protected correctly with the session keys these are overwritten according to FIPS 140-2 [FIPS_140-2] (or better) and a new PACE au- thentication or (in phase usage/operational) CA authentication, is required. – Keys and data in transient memory are overwritten after usage. • Verification of the PIN for qualified signature with a minimum length of 6 bytes for authentication data that is blocked after three failed authentications, the reset of the MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 88 SECURITY TARGET retry counter is limited to 10. The PIN is stored on the card in a SHA-256 hash repre- sentation; the transmission of the PIN must be protected by Secure Messaging with PACE. • RSA with 2048 bit - 4096 bit key length or ECDSA with 224 bit - 521 bit key length for both qualified and advanced signature; the qualified signature creation requires au- thentication before each signature creation (i.e. the authentication state is reset im- mediately after usage). 10.1.2.3 F.Management In development phase the configuration of the file layout including security attributes is performed. In the install process the TOE is configured for the SSCD in a specific configura- tion (see Table 3.3). The configuration is defined by the file system layout including all files necessary for administration and functionality. Note 57: Some configurations require Terminal Authentication (TA) for the communication betweenthe TOEandtheSCAor CGA(i.e. RSA-PSS-ta, EC-taand RSA-raw-dec-ta). Onlythese layouts offer the data structures necessary to perform TA. As this feature is provided in addition to the requirements of PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA, also the configurations that do not require TA do not conflict the strict conformance claim given in chapter 4. The layout defines that the parameters given in F.Access_Control for the us- age/preparation phase and usage/operational phase are enforced. Key management (PACE and EACv1) and other administrative tasks can also be performed. In usage/preparation phase the Administrator performs the following steps: • configuring the card for usage as SSCD, • writing of all the required user data to the appropriate files (PUK and CAN), • optionally, generating an SCD/SVD key pair, exporting the SVD and writing the certifi- cate to the card and • delivering the SSCD and the PUK to the user. In usage/operational phase the Signatory may perform the following steps: • activating the SSCD functionality by activating the RAD, • changing the RAD value, • generation of SCD/SVD and exporting of SVD using a trusted channel and • destruction of the a signature key by deleting and overwriting the key value. 10.1.2.4 F.Crypto This function provides a high level interface to • DES (supplied by F.IC_CL) • Triple-DES/CBC MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 89 SECURITY TARGET • AES (supplied by F.IC_CL) • DES/Retail MAC • CMAC • ECC (supplied by F.IC_CL) • RSA (supplied by F.IC_CL) 10.1.2.5 F.Verification TOE internal functions ensures correct operation. 10.2 Assurance Measures The assurance measures fulfilling the requirements of EAL5 augmented by ALC_DVS.2 and AVA_VAN.5 are given in table 10.2. Measure Description ADV_ARC.1 Security architecture description ADV_FSP.5 Completesemi-formalfunctionalspecificationwithadditionalerrorinfor- mation ADV_IMP.1 Implementation representation of the TSF ADV_INT.2 Well-structured internals ADV_TDS.4 Semiformal modular design AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.4 Production support, acceptance procedures, 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 ATE_COV.2 Analysis of coverage ATE_DPT.3 Testing: modular design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample AVA_VAN.5 Advanced methodical vulnerability analysis Table 10.2: Assurance Measures MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 90 SECURITY TARGET 10.2.1 TOE Summary Specification Rationale Table 10.4 shows the coverage of the SFRs by TSFs. SFR TSFs FCS_CKM.1/SCD F.IC_CL, F.Crypto FCS_CKM.1/DH_PACE F.IC_CL FCS_CKM.1/CA_STATIC F.IC_CL FCS_CKM.1/CA F.IC_CL FCS_CKM.4 F.Management, F.Identification_Authentication FCS_COP.1/SCD F.IC_CL, F.Crypto FCS_COP.1/SHA F.IC_CL FCS_COP.1/CA_ENC F.IC_CL, F.Crypto FCS_COP.1/CA_MAC F.IC_CL, F.Crypto FCS_COP.1/SIG_VER F.IC_CL FCS_COP.1/PACE_ENC F.IC_CL, F.Crypto FCS_COP.1/PACE_MAC F.IC_CL, F.Crypto FCS_RND.1 F.IC_CL FDP_ACC.1/TRM F.Access_Control FDP_AFC.1/TRM F.Access_Control FDP_ACC.1/SCD/SVD_Generation F.Access_Control, F.Identification_Authentication, F.Management FDP_AFC.1/SCD/SVD_Generation F.Access_Control, F.Identification_Authentication, F.Management FDP_ACC.1/SVD_Transfer F.Access_Control, F.Identification_Authentication FDP_AFC.1/SVD_Transfer F.Access_Control, F.Identification_Authentication FDP_ACC.1/Signature_Creation F.Access_Control, F.Identification_Authentication FDP_AFC.1/Signature_Creation F.Access_Control, F.Identification_Authentication FDP_ACC.1/Signature_Creation/ N-QES F.Access_Control, F.Identification_Authentication FDP_AFC.1/Signature_Creation/ N-QES F.Access_Control, F.Identification_Authentication FDP_UIT.1/DTBS F.Access_Control, F.Identification_Authentication FDP_RIP.1 F.Identification_Authentication, F.Management FDP_SDI.2/Persistent F.Management, F.Verification FDP_SDI.2/DTBS F.Management, F.Verification FDP_DAU.2/SVD F.Crypto, F.Identification_Authentication FIA_UID.1 F.Identification_Authentication FIA_UAU.1 F.Identification_Authentication MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 91 SECURITY TARGET SFR TSFs FIA_UAU.4/PACE F.Identification_Authentication FIA_UAU.5/PACE F.Access_Control, F.Identification_Authentication FIA_UAU.6 F.Identification_Authentication FIA_AFL.1/RAD F.Access_Control, F.Identification_Authentication FIA_AFL.1/Suspend_PIN F.Access_Control FIA_AFL.1/Block_PIN F.Access_Control FIA_API.1 F.Identification_Authentication FMT_SMR.1 F.Identification_Authentication FMT_SMF.1 F.Identification_Authentication, F.Management FMT_MOF.1 F.Access_Control, F.Identification_Authentication, F.Management FMT_MSA.1/Admin F.Identification_Authentication, F.Management FMT_MSA.1/Signatory F.Access_Control, F.Identification_Authentication FMT_MSA.2 F.Identification_Authentication, F.Management FMT_MSA.3 F.Identification_Authentication, F.Management FMT_MSA.4 F.Identification_Authentication, F.Management FMT_MTD.1/CVCA_UPD F.Identification_Authentication FMT_MTD.1/DATE F.Identification_Authentication FMT_MTD.1/KEY_READ F.Access_Control FMT_MTD.1/Admin F.Identification_Authentication, F.Management FMT_MTD.1/Signatory F.Identification_Authentication, F.Management FPT_EMS.1/SSCD F.IC_CL FPT_EMS.1/KEYS F.IC_CL FPT_FLS.1 F.IC_CL FPT_PHP.1 F.IC_CL FPT_PHP.3 F.IC_CL FPT_TST.1 F.IC_CL, F.Verification FTP_ITC.1/SVD F.Access_Control, F.Identification_Authentication FTP_ITC.1/VAD F.Access_Control, F.Identification_Authentication FTP_ITC.1/DTBS F.Access_Control Table 10.4: Coverage of SFRs for the TOE by TSFs. The SFR FCS_CKM.1/SCD requires the key generation algorithm, which is supplied by F.Crypto and F.IC_CL (SS.RSA_KeyGen, SS.ECC_KeyGen). TheSFRFCS_CKM.1/DH_PACErequirestheECDHalgorithm. Thisisprovidedbythecryp- tographic library function F.IC_CL (SS.ECC_DHKE). MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 92 SECURITY TARGET The SFR FCS_CKM.1/CA_STATIC requires ECDSA key generation. This is provided by the cryptographic library function F.IC_CL (SS.ECC_KeyGen). The SFR FCS_CKM.1/CA requires the ECDH algorithm. This is provided by the crypto- graphic library function F.IC_CL (SS.ECC_DHKE). The SFR FCS_CKM.4 requires the destroying of cryptographic keys. This is done in the case of SCD in F.Management (“Destruction of the qualified signature key by deleting the key file”), in the case of session keys in F.Identification_Authentication (“Keys and data in transient memory are overwritten after usage”). The SFR FCS_COP.1/SCD requires RSA and cryptographic key sizes 2048 - 4096 bit and ECDSA and cryptographic key sizes 224 - 521 bit to perform digital signature generation. This is provided in F.IC_CL (SS.RSA, SS.RSA_Pad, SS.ECDSA) and F.Crypto. The SFR FCS_COP.1/SHA requires the SHA-256 hash algorithm used for the storage of the PINs as hash representation, which is provided by F.IC_CL (SS.SHA). The SFR FCS_COP.1/CA_ENC requires AES and 3DES in CBC mode. F.IC_CL (SS.AES, SS.SW_AES, SS.TDES, SS.SW_DES) and F.Crypto provide this algorithm. The SFR FCS_COP.1/CA_MAC requires AES and 3DES in CBC mode. F.IC_CL (SS.AES, SS.SW_AES, SS.TDES, SS.SW_DES) and F.Crypto provide this algorithm. The SFR FCS_COP.1/SIG_VER requires ECDSA and cryptographic key sizes 224 - 521 bits to perform digital signature verification. F.IC_CL (SS.ECDSA) provides functions to verify signatures based on ECC. The SFR FCS_COP.1/PACE_ENC requires AES and 3DES in CBC mode. F.IC_CL (SS.AES, SS.SW_AES, SS.TDES, SS.SW_DES) and F.Crypto provide this algorithm. The SFR FCS_COP.1/PACE_MAC requires AES and 3DES in CBC mode. F.IC_CL (SS.AES, SS.SW_AES, SS.TDES, SS.SW_DES) and F.Crypto provide this algorithm. The SFR FCS_RND.1 requires the generation of random numbers which is provided by F.IC_CL (SS.RNG). The provided random number generator produces cryptographically strong random numbers which are used at the appropriate places as written in the addition there. The SFR FDP_ACC.1/TRM requires the enforcement of the terminal access control policy on terminals gaining write, read, modification and usage access to user data stored in the card. This is done by F.Access_Control. The SFR FDP_ACF.1/TRM requires the enforcement of the terminal access control policy on objects which is done by F.Access_Control. The SFRs FDP_ACC.1/SCD/SVD_Generation and FDP_ACF.1/SCD/SVD_Generation re- quire the enforcement of SCD/SVD_Generation_SFP. This is done by F.Access_Control, F.Identification_Authentication and F.Management. The SFRs FDP_ACC.1/SVD_Transfer and FDP_ACF.1/SVD_Transfer require the enforce- ment of SVD_Transfer_SFP. This is done by F.Access_Control and F.Identification_ Authen- tication. The SFRs FDP_ACC.1/Signature_Creation, FDP_ACF.1/Signature_Creation, FDP_ACC.1/Signature_Creation/N-QES and FDP_ACF.1/Signature_Creation/N-QES require the enforcement of Signature_Creation_SFP. This is done by F.Access_Control and MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 93 SECURITY TARGET F.Identification_Authentication. The SFR FDP_UIT.1/DTBS requires the enforcement of Signature_Creation_SFP. This is done by F.Access_Control and F.Identification_Authentication. The SFR FDP_RIP.1 requires residual information protection. This is done by F.Identification_ Authentication and F.Management. The SFR FDP_SDI.2/Persistent requires the monitoring of persistent stored data in- tegrity and the prohibition of the use of the altered data in case of an integrity error. This is done by F.Management and F.Verification. The SFR FDP_SDI.2/DTBS requires the monitoring of stored DTBS integrity and the prohibition of the use of the altered data in case of an integrity error. This is done by F.Management and F.Verification. The SFR FDP_DAU.2/SVD requires data authentication with identity of guarantor. This is provided by F.Crypto and F.Identification_Authentication. The SFRs FIA_UID.1 requires timing of identification. This is done by F.Identification_ Authentication. The SFR FIA_UAU.1 requires timing of authentication. This is done by F.Identification_ Authentication. The SFR FIA_UAU.4/PACE requires prevention of authentication data reuse. This is in particular fulfilled by using changing initialization vectors in Secure Messaging. Secure Mes- saging is provided by F.Identification_Authentication. The SFR FIA_UAU.5/PACE requires Passive Authentication protocol, Secure Messaging in encrypt-then-authenticate mode and PACE protocol based on 3DES or AES. In addi- tion SFR FIA_UAU.5/PACE also requires the authentication of any user’s claimed identity. F.Identification_Authentication and F.Access_Control fulfill these requirements. The SFR FIA_UAU.6 requires re-authentication for each command after successful au- thentication. This is done by F.Identification_Authentication providing Secure Messaging. The SFR FIA_AFL.1/RAD requires the detection of an unsuccessful authentication at- tempt and the blocking of the RAD in the case of 3 unsuccessful authentication attempts. This is done by F.Access_Control and F.Identification_Authentication. The SFR FIA_AFL.1/Suspend_PIN requires to set the reference value of the PIN into a suspended state after 2 unsuccessful authentication attempts before the secret is finally blocked. This is done by F.Access_Control. The SFR FIA_AFL.1/Block_PIN requires to the blocking of the RAD after 1 unsuccessful authentication attempt. This is done by F.Access_Control. The SFR FIA_API.1 requires the proving of the identity of the TOE. The Chip Authentica- tion is done by F.Identification_Authentication. The SFR FMT_SMR.1 requires the maintenance of roles. The roles are managed by F.Identification_Authentication. The SFR FMT_SMF.1 requires security management functions. This is done by F.Identification_Authentication and F.Management. The SFR FMT_MOF.1 requires the management of security functions behavior. This is done by F.Access_Control, F.Identification_Authentication and F.Management. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 94 SECURITY TARGET The SFR FMT_MSA.1/Admin requires the management of security attributes for the role “Administrator”. This is done by F.Identification_Authentication and F.Management. The SFR FMT_MSA.1/Signatory requires the management of security attributes for the role “Signatory”. This is done by F.Access_Control and F.Identification_Authentication. TheSFRFMT_MSA.2requiresthemanagementofsecuresecurityattributes. Thisisdone by F.Identification_Authentication and F.Management. The SFR FMT_MSA.3 requires the management of static attribute initialization. This is done by F.Identification_Authentication and F.Management. The SFR FMT_MSA.4 requires the management of security attribute value inheritance. This is done by F.Identification_Authentication and F.Management. The SFR FMT_MTD.1/CVCA_UPD requires only Certificate Service Provider to be able to update CVCA public key and CVCA certificate. This is provided by F.Identification_Authentication (properties of Terminal Authentication). The SFR FMT_MTD.1/DATE requires only Certificate Service Provider, Document Veri- fier and Legitimate Terminal to be able to modify the current date. This is provided by F.Identification_Authentication (properties of Terminal Authentication). The SFR FMT_MTD.1/KEY_READ requires the personalization keys and the Chip Authen- tication private key to never be readable. This is enforced by F.Access_Control, which does not allow reading of any key to any role. The SFR FMT_MTD.1/Admin requires the management of TSF data for the role “Admin- istrator”. This is done by F.Identification_Authentication and F.Management. The SFR FMT_MTD.1/Signatory requires the management of TSF data for the role “Sig- natory”. This is done by F.Identification_Authentication and F.Management. The SFRs FPT_EMS.1/SSCD and FPT_EMS.1/KEYS require limiting of emanations. This is provided by F.IC_CL (SF.OPC). The SFR FPT_FLS.1 requires failure detection and preservation of a secure state. The control of operating conditions of F.IC_CL (SF.OPC) is directly designed for this SFR. It au- dits continually and reacts to environmental and other problems by bringing it into a secure state. The SFR FPT_PHP.1 requires passive detection of physical manipulation and probing. This is provided by F.IC_CL (SF.PHY) which is provided by the hardware to detect attacks. The SFR FPT_PHP.3 requires resistance to physical manipulation and probing. This is provided by F.IC_CL (SF.PHY) which is provided by the hardware to resist attacks. The SFR FPT_TST.1 requires testing for the integrity of TSF data and the integrity of TSF. F.Verification does this testing. The SFR FTP_ITC.1/SVD requires a communication channel between itself and another trusted IT product for data authentication with identity of guarantor. This is provided by F.Access_Control and F.Identification_Authentication. The SFR FTP_ITC.1/VAD requires a communication channel between itself and another trusted IT product for user authentication. This is provided by F.Access_Control and F.Identification_Authentication. The SFR FTP_ITC.1/DTBS requires a communication channel between itself and another MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 95 SECURITY TARGET trusted IT product for signature creation. This is provided by F.Access_Control. 10.3 Statement of Compatibility This is a statement of compatibility between this composite security target and the security targets of the hardware and cryptographic library [NXP_ST-P60, NXP_ST-P60_CL]. Note that the security functionality concerning MIFARE and DESFire defined in the Security Target of the hardware is not used by the TOE and, thus, not listed here. 10.3.1 Relevance of Hardware TSFs Table 10.6 shows the relevance of the hardware security functions for the composite ST. HW-TSFs Description Relevant Not relevant SS.RNG Hardware random number generator x SS.TDES Triple-DES coprocessor x SS.AES AES coprocessor x SS.RECONFIG Post delivery configuration x SF.OPC Control of operating conditions x SF.PHY Protection against physical manipula- tion x SF.LOG Logical protection x SF.COMP Protection of mode control x SF.MEM_ACC Memory access control x SF.SFR_ACC Special function register access control x SF.FFW Firmware firewall x SF.FIRMWARE Firmware support x SF.PUF User data protection x Table 10.6: Relevance of hardware TSFs for composite ST Table 10.8 shows the relevance of the cryptographic library TSFs for the composite ST. HW-TSFs Description Relevant Not relevant SS.SW_AES AES-encryption/decryption x SS.SW_DES 3DES-encryption/decryption x SS.RSA RSA-encryption/decryption/ signature/verification x SS.RSA_Pad RSAformessageandsignatureencoding x SS.RSA_PublicExp Compute RSA public key from private CRT key x MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 96 SECURITY TARGET HW-TSFs Description Relevant Not relevant SS.ECDSA ECDSA signature generation and verifi- cation x SS.ECC_DHKE Diffie-Hellman key exchange x SS.ECC_Additional Full ECC point addition x SS.RSA_KeyGen Generation of RSA key pairs x SS.ECC_KeyGen ECC over GF(p) key generation x SS.SHA SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 x SS.SW_RNG Software random number generator x SS.COPY Copy memory content in a secure man- ner x SS.COMPARE Compare blocks of memory in a secure manner x SS.ModMultiply Modular multiplication in a secure man- ner x SS.ModAddSub Modular addition and subtraction in a secure manner x SF.Object_Reuse Clear memory areas after usage x Table 10.8: Relevance of cryptographic library TSFs for composite ST 10.3.2 Compatibility: TOE Security Environment 10.3.2.1 Assumptions The following list shows that neither assumptions of the TOE nor of the hardware have any conflicts between each other. They are either not relevant for this ST or are covered by ap- propriate security objectives. • Assumptions of the TOE – A.CGA (trustworthy certification-generation application): no conflict – A.SCA (trustworthy signature creation application): no conflict • Assumptions of the hardware – A.Process-Sec-IC (protection during packaging, finishing and personalization): no conflict – A.Resp-Appl (treatment of user data): covered by OT.SCD_Secrecy and OT.Sigy_SigF of the TOE ST – A.Check-Init-Plain (check of initialization data by the security IC Embedded Soft- ware): no conflict MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 97 SECURITY TARGET 10.3.2.2 Threats The threats of the TOE and the hardware can be mapped (see Table 10.9) or are not relevant. They show no conflicts between each other. • Threats of the TOE – T.SCD_Divulg (storing, copying, and releasing of the signature creation data): matches T.Leak-Inherent and T.Leak-Forced of the hardware ST – T.SCD_Derive (derive the signature creation data): no conflict – T.Hack_Phys (physical attacks through the TOE interfaces): matches T.Phys- Probing, T.Phys-Manipulation and T.Unauthorised-Access of the hardware ST – T.SVD_Forgery (forgery of the signature verification data): no conflict – T.SigF_Misuse (misuse of the signature creation function of the TOE): matches T.Abuse-Func and T.Unauthorised-Access of the hardware ST – T.DTBS_Forgery (forgery of the DTBS/R): no conflict – T.Sig_Forgery (forgery of the digital signature): no conflict • Threats of the hardware – T.Leak-Inherent(inherentinformationleakage): matchesT.SCD_DivulgoftheTOE ST – T.Phys-Probing (physical probing): matches T.Hack_Phys of the TOE ST – T.Malfunction (malfunction due to environmental stress): no conflict – T.Phys-Manipulation (physical manipulation): matches T.Hack_Phys of the TOE ST – T.Leak-Forced (forced information leakage): matches T.SCD_Divulg of the TOE ST – T.Abuse-Func (abuse of functionality): matches T.SigF_Misuse of the TOE ST – T.RND (deficiency of random numbers): basic threat concerning especially the PACE functionality of the TOE, no conflict – T.Unauthorised-Access (unauthorised memory or hardware access): matches T.Hack_Phys and T.SigF_Misuse of the TOE ST T.SCD_Divulg T.Hack_Phys T.SigF_Misuse T.Leak-Inherent x T.Phys-Probing x T.Phys-Manipulation x T.Leak-Forced x T.Abuse-Func x T.Unauthorised-Access x x Table 10.9: Mapping of hardware to TOE threats MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 98 SECURITY TARGET 10.3.2.3 Organizational Security Policies The organizational security policies of the TOE and the hardware have no conflicts between each other. They are shown in the following list. • Organizational security policies of the TOE – P.CSP_QCert (qualified certificate): no conflict – P.QSign (qualified electronic signatures): no conflict – P.Sigy_SSCD (TOE as secure signature creation device): no conflict – P.Sig_Non-Repud (non-repudiation of signatures): no conflict • Organizational security policies of the hardware – P.Process-TOE (identification during TOE development and production): no con- flict – P.Crypto-Service (cryptographic services of the TOE): no conflict – P.Add-Components-Plain (additional specific security components): no conflict – P.Add-Func (additional specific security functionality): no conflict 10.3.2.4 Security Objectives Some of the security objectives of the TOE and the hardware can be mapped directly (see Table 10.10). None of them show any conflicts between each other. • Security objectives for the TOE – OT.Lifecycle_Security (life cycle security): no conflicts – OT.SCD/SVD_Auth_Gen (authorized SCD/SVD generation): no conflicts – OT.SCD_Unique (uniqueness of the signature creation data): covered by O.RSA of the cryptographic library ST – OT.SCD_SVD_Corresp (correspondence between SVD and SCD): covered by O.RSA_KeyGen of the cryptographic library ST – OT.SCD_Secrecy (secrecy of the signature creation data): covered by O.Leak- Forced of the hardware ST and O.RSA of the cryptographic library ST – OT.Sig_Secure (cryptographic security of the digital signature): covered by O.RSA of the cryptographic library ST – OT.Sigy_SigF (signature creation function for the legitimate signatory only): no conflicts – OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE): no conflicts – OT.EMSEC_Design (provide physical-emanation security): covered by O.Leak- Inherent of the hardware ST – OT.Tamper_ID (tamper detection): covered by O.Phys-Probing, O.Malfunction and O.Phys-Manipulation of the hardware ST – OT.Tamper_Resistance (tamper resistance): covered by O.Phys-Probing, O.Malfunction and O.Phys-Manipulation of the hardware ST – OT.TOE_SSCD_Auth (authentication proof as SSCD): no conflicts – OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export): no conflicts – OT.TOE_TC_VAD_Imp (trusted channel of TOE for VAD import): no conflicts – OT.TOE_TC_DTBS_Imp (trusted channel of TOE for DTBS import): no conflicts • Security objectives for the operational environment: no conflict for any of the security objectives MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 99 SECURITY TARGET • Security objectives for the hardware – O.Leak-Inherent (protection against inherent information leakage): covered by OT.EMSEC_Design of the TOE ST – O.Phys-Probing (protection against physical probing): covered by OT.Tamper_ID and OT.Tamper_Resistance of the TOE ST – O.Malfunction (protection against malfunctions): covered by OT.Tamper_ID and OT.Tamper_Resistance of the TOE ST – O.Phys-Manipulation (protection against physical manipulation): covered by OT.Tamper_ID and OT.Tamper_Resistance of the TOE ST – O.Leak-Forced (protection against forced information leakage): covered by OT.SCD_Secrecy of the TOE ST – O.Abuse-Func (protection against abuse of functionality): no conflict – O.Identification (TOE identification): no conflict – O.RND(randomnumbers): basicobjectiveforthesecurityoftheTOE;noconflicts – O.TDES (cryptographic service Triple-DES): no conflicts – O.AES (cryptographic service AES): no conflicts – O.CUST_RECONFIG_PLAIN (post delivery configuration): no conflicts – O.EEPROM_INTEGRITY (integrity support of data stored in EEPROM): no conflicts – O.FM_FW (firmware mode firewall): no conflicts – O.MEM_ACCESS (area based memory access control): no conflicts – O.SFR_ACCESS (special function register access control): no conflicts – O.PUF (sealing/unsealing user data): no conflicts – OE.Resp-Appl (treatment of user data of the composite TOE): no conflicts – OE.Process-Sec-IC (protection during composite product manufacturing): no conflicts – OE.Check-Init(checkofinitializationdatabythesecurityICEmbeddedSoftware): no conflicts • Security objectives for the cryptographic library – O.SW_AES (AES functionality): no conflicts – O.SW_DES (DES functionality): no conflicts – O.RSA (RSA-encryption/decryption/signature/verification): covered by OT.SCD_Unique, OT.SCD_Secrecy and OT.Sig_Secure of the TOE ST – O.RSA_PubExp (compute RSA public key from private CRT key): no conflicts – O.RSA_KeyGen (generation of RSA key pairs): covered by OT.SCD_SVD_Corresp of the TOE ST – O.ECDSA (ECDSA signature generation and verification): no conflicts – O.ECC_DHKE (EC Diffie-Hellman key exchange): no conflicts – O.ECC_KeyGen (ECC over GF(p) key generation): no conflicts – O.ECC_Add (full ECC point addition): no conflicts – O.SHA (SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512): no conflicts – O.COPY (copy memory in a secure manner): no conflicts – O.COMPARE (compare memory in a secure manner): no conflicts – O.ModMultiply (modular multiplication in a secure manner): no conflicts – O.ModAddSub (modular addition and subtraction in a secure manner): no con- flicts – O.REUSE (clear memory content after usage): no conflicts MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 100 SECURITY TARGET – OE.Process-Sec-IC (protection during composite product manufacturing): no conflicts – OE.Check-Init (check of initialization data by the security card Embedded Soft- ware): no conflicts OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance O.Leak-Inherent x O.Phys-Probing x x O.Malfunction x x O.Phys-Manipulation x x O.Leak-Forced x O.RSA x x x O.RSA_KeyGen x Table 10.10: Mapping of hardware to TOE security objectives including those of the environ- ment (only those that can be mapped directly are shown) 10.3.2.5 Security Requirements The relevant security requirements of the TOE and the hardware can be mapped directly (see Table 10.11). None of them show any conflicts between each other. • Relevant security requirements of the TOE – FCS_CKM.1/SCD (cryptographic key generation - SCD): matches FCS_CKM.1[RSA] and FCS_CKM.1[ECC] of the cryptographic library ST – FCS_CKM.1/DH_PACE (cryptographic key generation - Diffie-Hellman for PACE session keys): matches FCS_COP.1[ECC_DHKE], FCS_COP.1[ECC_Additional] and FCS_COP.1[SHA] of the cryptographic library ST – FCS_CKM.1/CA_STATIC (cryptographic key generation - ECC key pair generation for Chip Authentication): matches FCS_CKM.1[ECC] of the cryptographic library ST – FCS_CKM.1/CA (cryptographic key generation - Diffie-Hellman for Chip Authenti- cation session keys): matches FCS_COP.1[ECC_DHKE] and FCS_COP.1[SHA] of the cryptographic library ST – FCS_CKM.4 (cryptographic key destruction): matches FCS_CKM.4 of the crypto- graphic library ST – FCS_COP.1/SCD (cryptographic operation - SCD): matches FCS_COP.1[RSA], FCS_COP.1[RSA_Pad] and FCS_COP.1[ECDSA] of the cryptographic library ST – FCS_COP.1/SHA (cryptographic operation - hashes): matches FCS_COP.1/SHA of the cryptographic library ST MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 101 SECURITY TARGET – FCS_COP.1/CA_ENC (cryptographic operation - symmetric encryption / decryp- tion): matches FCS_COP.1[SW-AES] and FCS_COP.1[SW-DES] of the cryptographic library ST – FCS_COP.1/SIG_VER (cryptographic operation - signature verification): matches FCS_COP.1[ECDSA] of the hardware/cryptographic library ST – FCS_COP.1/CA_MAC (cryptographic operation - MAC): matches FCS_COP.1[SW- AES] and FCS_COP.1[SW-DES] of the cryptographic library ST – FCS_COP.1/PACE_ENC (cryptographic operation - encryption / decryption AES/3DES): matches FCS_COP.1[SW-AES] and FCS_COP.1[SW-DES] of the crypto- graphic library ST – FCS_COP.1/PACE_MAC (cryptographic operation - MAC): matches FCS_COP.1[SW- AES] and FCS_COP.1[SW-DES] of the cryptographic library ST – FCS_RND.1 (quality metric for random numbers): matches FCS_RNG.1 of the hard- ware ST – Class FIA (identification and authentication): no conflicts – FDP_ACC.1/* (user data protection - subset access control): matches FDP_ACC.1/* of the hardware ST – FDP_ACF.1/* (user data protection - security attribute based access control): matches FDP_ACF.1/* of the hardware ST – FDP_RIP.1 (subset residual information protection): covered by FDP_RIP.1 of the cryptographic library ST – Other Class FDP (user data protection): no conflicts – Class FMT (management of TSF data): no conflicts – FPT_EMS.1/* (TOE emanation): matches FDP_ITT.1, FPT_ITT.1 and FDP_IFC.1 of the hardware ST – FPT_FLS.1 (failure with preservation of secure state): matches FPT_FLS.1 and FRU_FLT.2 of the hardware ST – FPT_PHP.1 (passive detection physical attack): no conflict – FPT_PHP.3 (resistance to physical attack): matches FPT_PHP.3 of the hardware ST – FPT_TST.1 (TSF testing): matches FRU_FLT.2 of the hardware ST – FTP_ITC.1/SVD (inter-TSF trusted channel): no conflicts – FTP_ITC.1/VAD (inter-TSF trusted channel): no conflicts – FTP_ITC.1/DTBS (inter-TSF trusted channel): no conflicts • Security requirements of the hardware – FAU_SAS.1[HW] (audit storage): no conflicts – FCS_RNG.1 (generation of random numbers): covered by FCS_RND.1 of the TOE ST – FDP_IFC.1 (subset information flow control): covered by FPT_EMS.1/* of the TOE ST – FDP_ITT.1 (basic internal transfer protection): covered by FPT_EMS.1/* of the TOE ST – FMT_LIM.1 (limited capabilities): no conflicts – FMT_LIM.2 (limited availability): no conflicts – FPT_FLS.1 (failure with preservation of secure state): covered by FPT_FLS.1 of the TOE ST MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 102 SECURITY TARGET – FPT_ITT.1 (basic internal TSF data transfer protection): covered by FPT_EMS.1/* of the TOE ST – FPT_PHP.3 (resistance to physical attack): covered by FPT_PHP.3 of the TOE ST – FRU_FLT.2 (limited fault tolerance): covered by FPT_FLS.1 and FPT_TST.1 of the TOE ST – FDP_SDC.1 (stored data confidentiality): no conflicts – FDP_SDI.2 (stored data integrity monitoring and action): no conflicts – FCS_COP.1[TDES] (cryptographic operation (TDES)): used implicitly, no conflicts – FCS_CKM.4[TDES] (cryptographic key destruction - TDES): used implicitly, no conflicts – FCS_COP.1[AES] (cryptographic operation (AES)): used implicitly, no conflicts – FCS_CKM.4[AES] (cryptographic key destruction - AES): used implicitly, no con- flicts – FCS_CKM.1[PUF] (cryptographic key generation): used implicitly, no conflicts – FCS_CKM.4[PUF] (cryptographic key destruction): used implicitly, no conflicts – FCS_COP.1[PUF_AES] (cryptographic operation): used implicitly, no conflicts – FCS_COP.1[PUF_MAC] (cryptographic operation): used implicitly, no conflicts – FDP_ACC.1[MEM] (subset access control): covered by FDP_ACC.1/* of the TOE ST – FDP_ACC.1[SFR] (subset access control): covered by FDP_ACC.1/* of the TOE ST – FDP_ACF.1[MEM] (security attribute based access control): covered by FDP_ACF.1/* of the TOE ST – FDP_ACF.1[SFR] (security attribute based access control): covered by FDP_ACF.1/* of the TOE ST – FMT_MSA.3[MEM] (static attribute initialization): used implicitly, no conflicts – FMT_MSA.3[SFR] (static attribute initialization): used implicitly, no conflicts – FMT_MSA.1[MEM] (management of security attributes): used implicitly, no con- flicts – FMT_MSA.1[SFR] (management of security attributes): used implicitly, no con- flicts – FMT_SMF.1[HW] (specification of management functions): used implicitly, no conflicts • Security requirements of the cryptographic library – FCS_COP.1[SW_AES] (cryptographic operation - AES): covered by FCS_COP.1/ PACE_ENC, FCS_COP.1/PACE_MAC, FCS_COP.1/CA_ENC and FCS_COP.1/ CA_MAC of the TOE ST – FCS_COP.1[SW_DES] (cryptographic operation - DES and TDES): covered by FCS_COP.1/ PACE_ENC, FCS_COP.1/PACE_MAC, FCS_COP.1/CA_ENC and FCS_COP.1/ CA_MAC of the TOE ST – FCS_COP.1[RSA] (cryptographic operation (RSA encryption, decryption, signa- ture and verification)): covered by FCS_COP.1/SCD of the TOE ST – FCS_COP.1[RSA_Pad] (cryptographic operation (RSA message and signature en- coding)): covered by FCS_COP.1/SCD of the TOE ST – FCS_COP.1[RSA_PubExp] (cryptographic operation (RSA public key computa- tion)): not relevant – FCS_COP.1[ECDSA] (cryptographic operation (ECC over GF(p) signature genera- tion and verification)): covered by FCS_COP.1/SCD and FCS_COP.1/SIG_VER of the TOE MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 103 SECURITY TARGET – FCS_COP.1[ECC_DHKE] (cryptographic operation (ECC Diffie-Hellman key ex- change)): covered by FCS_CKM.1/DH_PACE and FCS_CKM.1/CA of the TOE ST – FCS_COP.1[ECC_Additional] (cryptographic operation (ECC point addition)): cov- ered by FCS_CKM.1/DH_PACE of the TOE ST – FCS_COP.1[SHA] (cryptographic operation (SHA-1, SHA-224, SHA-256, SHA- 384 and SHA-512)): covered by FCS_CKM.1/DH_PACE, FCS_CKM.1/CA and FCS_COP.1/SHA of the TOE ST – FCS_CKM.1[RSA] (cryptographic key generation (RSA key generation)): covered by FCS_CKM.1/SCD of the TOE ST – FCS_CKM.1[ECC] (cryptographic key generation (ECC over GF(p) key generation)): covered by FCS_CKM.1/SCD and FCS_CKM.1/CA_STATIC of the TOE ST – FCS_CKM.4 (cryptographic key destruction): covered by FCS_CKM.4 of the TOE ST – FDP_RIP.1 (subset residual information protection): covered by FDP_RIP.1 of the TOE ST – FDP_SOP.1[Copy] (secure basic operations (secure copy)): used implicitly, no conflicts – FDP_SOP.1[Compare] (secure basic operations (secure compare)): used implic- itly, no conflicts – FDP_SOP.1[ModMultiply] (secure basic operations (secure modular multiply)): used implicitly, no conflicts – FDP_SOP.1[ModAddSub] (secure basic operations (secure modular add and sub- tract)): not relevant MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 104 SECURITY TARGET FCS_CKM.1/SCD FCS_CKM.1/DH_PACE FCS_CKM.1/CA_STATIC FCS_CKM.1/CA FCS_CKM.4 FCS_COP.1/SCD FCS_COP.1/SHA FCS_COP.1/CA_[ENC, MAC] FCS_COP.1/SIG_VER FCS_COP.1/PACE_[ENC, MAC] FCS_RND.1 FDP_ACC.1/* FDP_ACF.1/* FDP_RIP.1 FPT_EMS.1/* FPT_FLS.1 FPT_PHP.3 FPT_TST.1 FRU_FLT.2 x x FPT_FLS.1 x FPT_PHP.3 x FDP_ITT.1 x FPT_ITT.1 x FDP_IFC.1 x FCS_RNG.1 x FDP_ACC.1[MEM, SFR] x FDP_ACF.1[MEM, SFR] x FCS_COP.1[SW-AES] x x FCS_COP.1[SW-DES] x x FCS_COP.1[RSA] x FCS_COP.1[RSA_Pad] x FCS_COP.1[ECDSA] x x FCS_COP.1[ECC_DHKE] x x FCS_COP.1[ECC_Add.] x FCS_COP.1[SHA] x x x FCS_CKM.1[RSA] x FCS_CKM.1[ECC] x x FCS_CKM.4 x FDP_RIP.1 x Table 10.11: Mapping of of hardware and cryptographic library to TOE security SFRs (only SFRs that can be mapped directly are shown) 10.3.2.6 Assurance Requirements The level of assurance of the • TOE is EAL5 augmented with ALC_DVS.2 and AVA_VAN.5 • hardware is EAL5 augmented with ALC_FLR.1 and ASE_TSS.2 This shows that the assurance requirements of the hardware exceed that of the TOE and thus all assurance requirements of the TOE are met. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 105 SECURITY TARGET 10.3.3 Conclusion Overall no contradictions between the Security Targets of the TOE and the hardware can be found. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 106 SECURITY TARGET Bibliography [AGD] MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB) User Guidance, Mask- Tech International GmbH, Version 0.6, 2018-02-16. [ANSI_X9.63] American National Standard X9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using El- liptic Curve Cryptography, ANSI, 2001-11-20. [BSI_AIS31v3] AIS 31, Version 3, Anwendungshinweise und Interpretationen zum Schema – Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, BSI, 2013-05-15. [BSI_TR-03110-1] TR-03110-1, Technical Guideline TR-03110-1: Advanced Security Mecha- nisms forMachine Readable Travel Documents and eIDAS Token – Part 1 – eMRTDs with BAC/PACEv2 and EACv1, BSI, Version 2.20, 2015-02-26. [BSI_TR-03110-2] TR-03110-2, Technical Guideline TR-03110-2: Advanced Security Mecha- nisms for Machine Readable Travel Documents and eIDAS Token – Part 2 – Protocols for electronic IDentification, Authentication and trust Ser- vices (eIDAS), BSI, Version 2.20, 2015-02-03. [BSI_TR-03111] TR-03111, Technical Guideline TR-03111: Elliptic Curve Cryptography, BSI, Version 2.0, 2012-06-28. [BSI_TR-03116-2] TR-03116-2, Technische Richtlinie – Kryptographische Verfahren für Pro- jekte der Bundesregierung - Teil 2 – Hoheitliche Ausweisdokumente, BSI, Stand 2014, 2014-04-14. [CC_Part1] CCMB-2012-09-001, Version 3.1, Revision 4, Common Criteria for Informa- tion Technology Security Evaluation, Part 1: Introduction and General Model, Common Criteria Maintenance Board, 2012-09. [CC_Part2] CCMB-2012-09-002, Version 3.1, Revision 4, Common Criteria for Informa- tion Technology Security Evaluation, Part 2: Security Functional Compo- nents, Common Criteria Maintenance Board, 2012-09. [CC_Part3] CCMB-2012-09-003, Version 3.1, Revision 4, Common Criteria for Informa- tion Technology Security Evaluation, Part 3: Security Assurance Compo- nents, Common Criteria Maintenance Board, 2012-09. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 107 SECURITY TARGET [CC_PP-0056-V2] BSI-CC-PP-0056-V2-2012, Common Criteria Protection Profile / Machine ReadableTravelDocumentwith’ICAOApplication’, ExtendedAccessCon- trol with PACE, BSI, Version 1.3.2, 2012-12-05. [CC_PP-0059] BSI-CC-PP-0059-2009-MA-02, Protection profiles for Secure signature creation device – Part 2: Device with key generation, Information Soci- ety Standardization System CEN/ISSS, EN 419211-2:2013, 2016-06-30. [CC_PP-0068-V2] BSI-CC-PP-0068-V2-2011, Common Criteria Protection Profile / Machine Readable Travel Document using Standard Inspection Procedure with PACE (ePass_PACE PP), BSI, Version 1.0, 2011-11-02. [CC_PP-0071] BSI-CC-PP-0071-2012-MA-01, Protection profiles for Secure signature cre- ation device – Part 4: Extension for device with key generation and trusted communication with certificate generation application, Informa- tion Society Standardization System CEN/ISSS, EN 419211-4:2013, 2016- 06-30. [CC_PP-0072] BSI-CC-PP-0072-2012-MA-01, Protection profiles for Secure signature cre- ation device – Part 5: Extension for device with key generation and trusted communication with signature creation application, Information Society Standardization System CEN/ISSS, EN 419211-5:2013, 2016-06-30. [CC_PP-0084] BSI-CC-PP-0084-2014, Security IC Platform Protection Profile with Aug- mentation Packages, BSI, Version 1.0, 2014-01-13. [CC_PP-0086] BSI-CC-PP-0086-2015, Common Criteria Protection Profile / Electronic document implementing Extended Access Control Version 2 (EAC2) based on BSI TR-03110 (EAC2_PP), BSI, Version 1.01, 2015-05-20. [DIR_1999/93/EC] European Parliament. DIRECTIVE 1999/93/EC OF THE EUROPEAN PAR- LIAMENT AND OF THE COUNCIL of 13 December 1999 on a Community framework for electronic signatures. Official Journal of the European Communities, L13:12 – 20, 2000. [FIPS_140-2] FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Na- tional Institute of Standards and Technology, 2001-05. [FIPS_180-4] FIPS PUB 180-4, Secure Hash Standard, National Institute of Standards and Technology, 2012-03. [FIPS_186-4] FIPS PUB 186-4, DIGITAL SIGNATURE STANDARD (DSS), National Institute of Standards and Technology, 2013-07. [FIPS_197] FIPS PUB 197, ADVANCED ENCRYPTION STANDARD (AES), National Insti- tute of Standards and Technology, 2001-11-26. [FIPS_46-3] FIPS PUB 46-3, DATA ENCRYPTION STANDARD (DES), National Institute of Standards and Technology, 1999-10. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 108 SECURITY TARGET [ICAO_9303_11] ICAO Doc 9303, Machine Readable Travel Documents: Part 11 – Security Mechanisms for MRTDs, ICAO, 2015. [ICAO_SAC] TR-SAC, Supplemental Access Control for Machine Readable Travel Doc- uments, ICAO, Version 1.1, 2014-04-15. [ISO_15946-1] ISO/IEC 15946-1:2002, Information technology – Security techniques – Cryptographic techniques based on elliptic curves – Part 1: General, ISO/IEC, 2002. [ISO_15946-2] ISO/IEC 15946-2:2002, Information technology – Security techniques – Cryptographic techniques based on elliptic curves – Part 2: Digital Sig- natures, ISO/IEC, 2002. [ISO_15946-3] ISO/IEC 15946-3:2002, Information technology – Security techniques – Cryptographic techniques based on elliptic curves – Part 3: Key Estab- lishment, ISO/IEC, 2002. [ISO_18013-3] ISO/IEC 18013-3:2009, Personal Identification – ISO Compliant Driving Li- cense – Part 3: Access Control, Authentication and Integrity Validation, ISO/IEC, 2009-03-01. [ISO_7816] ISO/IEC 7816:2008, Information technology – Identification cards – Inte- grated circuit cards – Multipart Standard, ISO/IEC, 2008. [ISO_9797] ISO/IEC 9797:1999, 2002, Information technology – Security techniques – Message Authentication Codes (MACs) – Multipart Standard, ISO/IEC, 1999, 2002. [MT_Manual] MTCOS Pro V2.5 on P60D145VB_J (P6022y VB) – Manual, MaskTech GmbH, 2017-10-05. Version 1.0. [NIST_SP800-38A] NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, National Institute of Stan- dards and Technology, 2001-12. [NIST_SP800-38B] NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, National Insti- tute of Standards and Technology, 2005-05. [NIST_SP800-67] NISTSpecialPublication800-67, RecommendationfortheTripleDataEn- cryption Algorithm (TDEA) Block Cipher, version 1.1, NIST. [NXP_ST-P60] NXP Semiconductors, Security Target Lite ’NXP Secure Smart Card Con- troller P6022y VB’, BSI-DSZ-CC-0973-V2, Rev. 1.52, 2016-07-27. [NXP_ST-P60_CL] NXP Semiconductors, Security Target ’Crypto Library V3.1.x on P6022y VB’, NSCIB-CC-15-67206-CR2, Rev. 1.6, 2017-08-08. [PKCS_15] PKCS #15: Cryptographic Token Information Syntax Standard, Version 1.1, 2000-06-06. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 109 SECURITY TARGET [PKCS_1_v22] PKCS #1, RSA Cryptography Standard, v2.2, 2012-10-27. [SC_Gemalto] BSI-DSZ-CC-S-0064-2016, Gemalto AG, Site Security Target lite of Gemalto AG, Site Switzerland with locations Aarau and Unterentfelden, Version 6.0, 2016-03-08. [SC_HID] BSI-DSZ-CC-S-0073-2016, HID Global GmbH, Site Security Target Lite of HID Global Ireland Teoranta in Galway, Ireland, Rev. 2.04, 2016-08-09. [SC_Smartrac] BSI-DSZ-CC-S-0097-2017, SMARTRAC Technology Ltd., Site Security Tar- get for AY1, Version 2.1, 2017-12-06. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 110 SECURITY TARGET 11 Revision History Version Date Author Changes 1.0 2018-01-29 Gudrun Schürer Public version 1.1 2018-02-16 Gudrun Schürer Revised references MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 111 SECURITY TARGET A Overview Cryptographic Algorithms The following cryptographic algorithms are used by the TOE to enforce its security policy: Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments ST-Reference 1 Authenticity RSA-signature gen- eration (raw RSA, RSASSA-PSS, RSASSA- PKCS1-v1_5), using SHA-1, SHA-224, SHA- 256, SHA-384 or SHA-512 [PKCS_1_v22], [FIPS_186-4] 2048 - 4096 Digital signature cre- ation FCS_COP.1/SCD 2 ECDSA-signature gener- ation [BSI_TR-03111] 224 - 521 Digital signature cre- ation FCS_COP.1/SCD 3 Terminal Authentica- tion, ECDSA-signature verification (r1 curve type) using SHA-224, SHA-256, SHA-384 or SHA-512 [ISO_15946-2] (Digital signatures), [FIPS_186-4], chapter 6, [FIPS_180-4], section 6.2 224 - 521 [BSI_TR-03110-1] Verification of cer- tificates (Terminal Authentication), FCS_COP.1/SIG_VER 4 Authentication PACEv2 (Generic Map- ping), Password Au- thenticated Connection Establishment [BSI_TR-03110-1] (PACEv2) |MRZ|=160 |Nonce|=128 [ICAO_SAC], [BSI_TR-03110-1] - 5 Implicit authentication during Secure Mes- saging, 3DES in CBC mode [NIST_SP800-38A] sec- tion 6.2 (CBC), [NIST_SP800-67] ver- sion 1.1 (3DES) 112 [ICAO_SAC], [BSI_TR-03110-1] BIS-PACE-key PACE, 1st step (opt.) FCS_COP.1/PACE_ENC FCS_COP.1/CA_ENC 6 Implicit authentication during Secure Mes- saging, AES in CBC mode [FIPS_197] (AES), [NIST_SP800-38A] section 6.2 (CBC) 128, 192, 256 [ICAO_SAC], [BSI_TR-03110-1], [ISO_18013-3] Personalization-key, PACE, 1st step (opt.) FCS_COP.1/PACE_ENC FCS_COP.1/CA_ENC 7 Key Agreement Chip Authentication, ECC key pair generation (r1 curve type) [FIPS_186-4]AnnexB.4.2 (Candidate Testing), [ISO_15946-1], [ANSI_X9.63] 224 - 521 [ICAO_SAC], [BSI_TR-03110-1] FCS_CKM.1/CA_STATIC 8 Chip Authentication, Key derivation ECDH using SHA-1, SHA-256 [ISO_15946-1], [ANSI_X9.63] 112, 128, 192, 256 [ICAO_SAC], [BSI_TR-03110-1] FCS_CKM.1.1/CA 9 Confidentiality Secure Messaging, 3DES in CBC mode [NIST_SP800-38A] sec- tion 6.2 (CBC), [NIST_SP800-67] ver- sion 1.1 (3DES) 112 [ICAO_SAC], [BSI_TR-03110-1] FCS_COP.1/CA_ENC FCS_COP.1/PACE_ENC 10 Secure Messaging, AES in CBC mode [FIPS_197] (AES), [NIST_SP800-38A] section 6.2 (CBC) 128, 192, 256 [ICAO_SAC], [BSI_TR-03110-1] FCS_COP.1/CA_ENC FCS_COP.1/PACE_ENC MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 112 SECURITY TARGET Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments ST-Reference 11 Integrity Secure Messaging, 3DES in Retail MAC mode (MAC algorithm 3, Send Sequence Counter, padding mode 2) [NIST_SP800-38B] sec- tion 6 (CMAC), [ISO_9797] algorithm 3 (Retail-MAC), [NIST_SP800-67] ver- sion 1.1 (3DES) 112 [ICAO_SAC], [BSI_TR-03110-1] FCS_COP.1/CA_MAC FCS_COP.1/PACE_MAC 12 Secure Messaging, CMAC-AES [FIPS_197] (AES), [NIST_SP800-38B] section 6 (CMAC) 128, 192, 256 [ICAO_SAC], [BSI_TR-03110-1] FCS_COP.1/CA_MAC FCS_COP.1/PACE_MAC 13 Trusted Channel Secure Messaging in ENC/MAC mode estab- lished during PACE [BSI_TR-03110-1] (PACE) additionally cf. lines 2, 4, 5, 8-11 - [ICAO_SAC], [BSI_TR-03110-1] FTP_ITC.1/SCD FTP_ITC.1/VAD FTP_ITC.1/DTBS 14 Secure Messaging in ENC/MAC mode es- tablished during Chip Authentication after PACE [BSI_TR-03110-1] ad- ditionally cf. lines 2, 4-11 - [BSI_TR-03110-1] FTP_ITC.1/SCD FTP_ITC.1/VAD FTP_ITC.1/DTBS FCS_CKM.1/CA 15 Cryptographic primitive PTG.2 Random number generator [BSI_AIS31v3] - [BSI_TR-03116-2] - 16 SHA-1, SHA-224, SHA- 256, SHA-384, SHA-512 [FIPS_180-4] chapter 6 - [BSI_TR-03110-1] Signature verification Key derivation Table A.2: Overview Cryptographic Algorithms According to [ICAO_SAC], [BSI_TR-03110-1], and [BSI_TR-03116-2] the algorithms are suit- able for authenticity, authentication, key agreement, confidentiality and integrity. An ex- plicit validity period is not given. MTCOS Pro 2.5 SSCD / P60D145VB_J (P6022y VB), Version 1.1 113