SECURITY TARGET COMMON CRITERIA DOCUMENTS | Version 1.3 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892) Secure signature creation device with key generation Certification-ID: BSI-DSZ-CC-1036    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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.3 Statement of Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 11 Revision History 108 A Overview Cryptographic Algorithms 109 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 prEN 14169 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 prEN 14169 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 8 SECURITY TARGET 3 Security Target Introduction (ASE_INT.1) 3.1 ST and TOE Reference Title Security Target – MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892) Version 1.3 Author MASKTECH INTERNATIONAL GMBH Publication date 2019-07-03 Registration BSI-DSZ-CC-1036 CC Version 3.1 (Revision 5) 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- MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 9 SECURITY TARGET lished by CEN as a European standard for products to create electronic signatures. They 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. For convenience, extensive parts that refer mainly to only one PP are marked as: PP SSCD KG TCSCA is marginalized with SCA 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 10 SECURITY TARGET 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892)”, which is real- ized by a smartcard (for contact-based and contactless usage), comprises of: Hardware * Infineon Technologies AG SLE78CLFX400VPHM/BPHM/7PHM (M7892), dual interface Smartcard IC (certified compliant to BSI-CC-PP-0084- 2014[CC_PP-0084]: BSI-DSZ-CC-0891-V3 [IFX_ST-SLE78] using the derivatives with sales code: • SLE78CLFX400VPHM, • SLE78CLFX400BPHM and • SLE78CLFX4007PHM These derivatives differ only in the antenna capacity (input capaci- tance of the RF interface) of the module. This difference is not security- relevant, thus all derivatives are taken as one configuration. Software * Operating System MTCOS Pro V2.5 * SSCD application Documentation * Product Manual [MT_Manual] * MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892) User Guidance [AGD] MTCOS Pro V2.5 is a fully interoperable multi-application smart card operating system compliant to [ISO_7816]. The SSCD application is written to the non-volatile memory (NVM) in the development phase (see also section 3.3.3). The application’s file system follows the PKCS #15 structure [ISO_7816-15]. Note 1: The product contains an MRTD application, which is not part of the TOE, but subject to BSI-DSZ-CC-1033 and BSI-DSZ-CC-1034. Security Features and Access Control MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892) 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) MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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.5 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 5 Note that the decryption key is beyond the scope of the certification. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 12 SECURITY TARGET 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 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 (see footnote 5). 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 (see footnote 5). The configurations are: No. Configuration-ID Description 1 RSA-PSS 3 RSA keys for signature creation 2 RSA-PSS-ta 3 RSA keys for signature creation, TA required 3 RSA-PSS-dec 3 RSA keys for signature creation, 1 RSA key for decryption 4 EC 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 decryp- tion 7 RSA-raw-dec 2 RSA keys and 1 ECDSA key for signature creation, 1 RSA key for decryp- tion 8 RSA-raw-dec-ta 2 RSA keys and 1 ECDSA key for signature creation, 1 RSA key for decryp- tion, 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. 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 13 SECURITY TARGET 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. The TOEs interactions comprise of: MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 14 SECURITY TARGET 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.7 Determining the state of the certificate as qualified is beyond the scope of prEN 14169. 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. 7 Note that this Security Target takes all requirements of the eIDAS regulation [REG_910/2014] and the com- mission implementing regulation [CID_2016/650] into account. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 Infineon Technologies AG. • Development of the embedded software (operating system) by MASKTECH INTER- NATIONAL GMBH. Production • Manufacturing of the chip (IC/integrated software software) by Infineon Tech- nologies AG. Writing of the embedded software and deactivation of the Flash MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 17 SECURITY TARGET Loader by Infineon Technologies AG or MASKTECH INTERNATIONAL GMBH (see also note 4 below). • Initialization/pre-personalization by MASKTECH INTERNATIONAL GMBH, SMAR- TRAC TECHNOLOGY Ltd., Thailand (see [SC_Smartrac]), HID Global Ireland Teo- ranta (see [SC_HID]), HID Global Malaysia (see [SC_HID_MY]), Gemalto AG, Switzerland(formerTrübAG,see[SC_Gemalto])orInfineonTechnologiesAG(see [IFX_ST-SLE78]). In the initialization step the chip is configured, the MF is cre- ated and the personalization keys are written. In the pre-personalization step, the SSCD application including all files is created. Note 4: In the case of Infineon Technologies AG performing initialization and pre- personalization, the deactivation of the Flash Loader can also be performed after the initialization/pre-personalization step. The steps of the development phase performed by MASKTECH INTERNATIONAL GMBH (i.e. the development of the embedded software and, conditionally, the writing of the embed- ded software to the chip and the initialization/pre-personalization) are subject of the eval- uation according to the assurance life cycle (ALC) class. The steps performed by Infineon Technologies AG are evaluated within the certification of the platform ([IFX_ST-SLE78]). 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.8 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). 8 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 18 SECURITY TARGET 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): 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). MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 19 SECURITY TARGET 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. 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 certificate9 . 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. 9 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 5: • 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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.2 takes the dependencies of the SFRs into account. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 5: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 6: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 7: 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 8: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 9: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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. Note 10: This objective replaces OE.SSCD_Prov_Service from PP SSCD KG, which is possi- ble as it does not imply any additional requirements for the operational environment when compared to OE.SSCD_Prov_Service (OE.Dev_Prov_Service is a subset of OE.SSCD_Prov_ Service). 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 11: 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 12: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 34 SECURITY TARGET Threats, Policies 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 37). No other components are used. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 [IEEE_P1363] and ECDSA and specified crypto- graphic key sizes BP(r1): 224, 256, 320, 384, 512 bits, NIST: 224, 256, 384, 521 bits that meet the following: [BSI_TR-03111], sec. 4.1.3 and [ANSI_X9.62], sec. G.5.2. Note 13: The generation of asymmetric key pairs to be used for decryption (beyond the scope of the certification) also follow the SFR. Note 14: The standard PKCS #1 version 2.2 [PKCS_1_v22] supersedes the standard PKCS #1 version 2.1, which is referenced in the [IFX_ST-SLE78]. 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]. Note 15: 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 16: 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 17: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 BP(r1): 224, 256, 320, 384, 512 bits, NIST: 224, 256, 384, 521 bits that meet the following: [BSI_TR-03111] and [ANSI_X9.62] sec. G.5.2. Note 18: 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 3DES: 112, AES: 128, 192 and 256 bits that meet the following: based on an ECDH protocol compliant to [BSI_TR-03111] Note 19: 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 20: 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 21: This SFR has been adapted from [CC_PP-0056-V2]. Note 22: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 23: 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 24: 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 BP(r1): 224, 256, 320, 384, 512 bits, NIST: 224, 256, 384, 521 bits that meet the following: [BSI_TR-03111]. See also Note 14. 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 25: 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 47 SECURITY TARGET in SFRs FCS_CKM.1/DH_PACE and FCS_CKM.1/CA implicitly. Note 26: 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], [NIST_SP800-67], and [ISO_10116]. Note 27: 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 28: 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], [NIST_SP800-67], [NIST_SP800-38B], Section 6, and [ISO_9797-1], MAC algorithm 3 with block cipher DES, key KMAC and IV=SSC. Note 29: 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 30: This SFR has been adapted from [CC_PP-0056-V2]. EAC MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 48 SECURITY TARGET 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 BP(r1): 224, 256, 320, 384, 512 bits, NIST: 224, 256, 384, 521 bits that meet the following: [ANSI_X9.62], sec. 7, [FIPS_180-4], section 6.2, and [BSI_TR-03111], Section 6 (r1). Note 31: This SFR has been adapted from [CC_PP-0056-V2]. It applies only to the configura- tions 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], [NIST_SP800-67], and [ISO_10116] sec. 7 compliant to [ICAO_SAC]. Note 32: 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 33: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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], [NIST_SP800-67], [NIST_SP800-38B], Section 6, and [ISO_9797-1], MAC algorithm 3 with block cipher DES, key KMAC and IV=SSC compliant to [ICAO_SAC]. Note 34: This SFR requires the TOE to implement the cryptographic primitive for Secure Messaging 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 ac- cording to the FCS_CKM.1/DH_PACE (PACE-KMAC). Note 35: This SFR has been adapted from [CC_PP-0068-V2]. PACE EAC FCS_RND.1 Random number generation (Class PTG.3) Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a [hybrid physical] random number generator that implements: (PTG.3.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.3.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.3.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 and theseedingoftheDRG.3post-processingalgorithmhavebeenfinished successfully or when a defect has been detected. (PTG.3.4) The online test procedure shall be effective to detect non-tolerable weaknesses of the random numbers soon. (PTG.3.5) The online test procedure checks the raw random number sequence. It is triggered continuously. The online test is suitable for detecting nontolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time. (PTG.3.6) The algorithmic post-processing algorithm belongs to Class DRG.3 with cryptographic state transition function and cryptographic output function, and the output data rate of the post-processing algorithm shall not exceed its input data rate. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 50 SECURITY TARGET FCS_RND.1.2 The TSF shall provide octets of bits that meet: (PTG.3.7) Statistical test suites cannot practically distinguish the internal random numbers from output sequences of an ideal RNG. The internal random numbers must pass test procedure A1 none. (PTG.3.8) The internal random numbers shall use PTRNG of class PTG.2 as random source for the postprocessing. Note36: ThisSFRrequirestheTOEtogeneraterandomnumbersusedfortheauthentication protocols as required by FIA_UAU.4. Note 37: This SFR has been adapted from [CC_PP-0068-V2] and changed accord- ing to [CC_PP-0084] (FCS_RNG.1), justified in [KiSch-RNG] chapter 3 (PTG.3) and [NIST_SP800-90a-R1], sec. 10.2, 10.3.2 to meet [BSI_AIS31v3]. The naming ’FCS_RND.1’ has been kept for consistence with the certification procedure for the MRTD application (BSI-DSZ-CC-1033). 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. 1 See [KiSch-RNG] Section 2.4.4. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 51 SECURITY TARGET Note 38: 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 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 39: 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 52 SECURITY TARGET 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. 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_ACF.1.4/ SCD/SVD_Generation The TSF shall explicitly deny access of subjects to objects based on the following additional rules: S.User with the security attribute “SCD/SVD management” set to “not authorised” is not allowed to generate SCD/SVD pair). 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 53 SECURITY TARGET 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. 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”. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 54 SECURITY TARGET 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. 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”. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 55 SECURITY TARGET 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”. 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”: MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 56 SECURITY TARGET 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. 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 40: 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 57 SECURITY TARGET Dependencies: No dependencies. 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 41: 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 58 SECURITY TARGET Dependencies: No dependencies. 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 42: 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 43: 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 44: 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], 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 Note 45: 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 46: 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 47: This SFR has been adapted from [CC_PP-0068-V2] or [CC_PP-0056-V2], respec- tively. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 48: 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 49: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 50: 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 51: 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 52: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 64 SECURITY TARGET Note 53: 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 54: 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 55: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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. 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 66 SECURITY TARGET Note 56: 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. 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 67 SECURITY TARGET 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. Note 57: 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 68 SECURITY TARGET 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 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 69 SECURITY TARGET Assurance class Assurance components 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.2: Assurance Requirements: EAL5 augmented with ALC_DVS.2 and AVA_VAN.5 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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.2: 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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.3: 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.3. 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 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 This security function covers the security functions of the hardware (IC). The Security Target of the hardware [IFX_ST-SLE78] defines the following security features: SF_DPM Device phase management SF_PS Protection against snooping SF_PMA Protection against modification attacks SF_PLA Protection against logical attacks SF_CS Cryptographic support including the components • Triple DES (only hardware-implemented Triple DES used by the TOE) • AES (only hardware-implemented AES used by the TOE) • RSA (encryption, decryption, signature generation and verification, asymmetric key generation) • EC (signature generation and verification, asymmetric key generation, asymmet- ric key agreement) • SHA-2 (not used by the TOE) • (PTRNG respectively) TRNG MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 85 SECURITY TARGET 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: 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 86 SECURITY TARGET – 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. • 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 87 SECURITY TARGET – 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 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 58: 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. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 88 SECURITY TARGET 10.1.2.4 F.Crypto Thisfunctionprovidestheimplementationor,ifthefunctionalityofthecryptographiclibrary (F.IC_CL) is used, the high level interface to • DES • Triple-DES/CBC • AES • DES/Retail MAC • CMAC • ECC (supplied by F.IC_CL) • RSA (supplied by F.IC_CL) This function implements the hash algorithms according to FIPS 180-4 [FIPS_180-4] • SHA-1 • SHA-224 • SHA-256 • SHA-384 • SHA-512 This function implements the post-processing of the random number generator • RNG (PTG.3, 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.1. 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 89 SECURITY TARGET Measure Description 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.1: Assurance Measures 10.2.1 TOE Summary Specification Rationale Table 10.2 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.Identification_Authentication, F.Management FCS_COP.1/SCD F.IC_CL, F.Crypto FCS_COP.1/SHA F.Crypto FCS_COP.1/CA_ENC F.Crypto FCS_COP.1/CA_MAC F.Crypto FCS_COP.1/SIG_VER F.IC_CL FCS_COP.1/PACE_ENC F.Crypto FCS_COP.1/PACE_MAC F.Crypto FCS_RND.1 F.IC_CL, F.Crypto 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 90 SECURITY TARGET SFR TSFs 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 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 MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 91 SECURITY TARGET SFR TSFs 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.2: 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 (SF_CS(EC, RSA)). TheSFRFCS_CKM.1/DH_PACErequirestheECDHalgorithm. Thisisprovidedbythecryp- tographic library function F.IC_CL (SF_CS(EC)). The SFR FCS_CKM.1/CA_STATIC requires ECDSA key generation. This is provided by the cryptographic library function F.IC_CL (SF_CS(EC, RSA)). The SFR FCS_CKM.1/CA requires the ECDH algorithm. This is provided by the crypto- graphic library function F.IC_CL (SF_CS(EC)). 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 ECDSAandcryptographickeysizesBP(r1): 224,256,320,384,512bits,NIST:224,256,384,521 bits to perform digital signature generation. This is provided in F.IC_CL (SF_CS(EC, RSA)) 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.Crypto. The SFR FCS_COP.1/CA_ENC requires AES and 3DES in CBC mode. F.Crypto provides these algorithms. The SFR FCS_COP.1/CA_MAC requires AES and 3DES in CBC mode. F.Crypto provides these algorithms. The SFR FCS_COP.1/SIG_VER requires ECDSA and cryptographic key sizes BP(r1): 224, 256, 320, 384, 512 bits, NIST: 224, 256, 384, 521 bits to perform digital signature verification. F.IC_CL (SF_CS(EC)) provides functions to verify signatures based on ECC. The SFR FCS_COP.1/PACE_ENC requires AES and 3DES in CBC mode. F.Crypto provides these algorithms. The SFR FCS_COP.1/PACE_MAC requires AES and 3DES in CBC mode. F.Crypto provides these algorithms. The SFR FCS_RND.1 requires the generation of random numbers which is provided by MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 92 SECURITY TARGET F.IC_CL (SF_CS(TRNG)) and F.Crypto. The provided random number generator produces cryptographically strong random numbers which are used at the appropriate places as writ- ten 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 enforcement of SVD_Transfer_SFP. This is done by F.Access_Control and F.Identification_Authentication. 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 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- MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 93 SECURITY TARGET 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. 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_PS). MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 94 SECURITY TARGET The SFR FPT_FLS.1 requires failure detection and preservation of a secure state. This is provided by F.IC_CL (SF_PS, SF_PMA, SF_PLA). The security functions audit continually and react to environmental and other problems by bringing the chip 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_DPM, SF_PS, SF_PMA, SF_PLA) which is provided by the hardware to detect attacks. The SFR FPT_PHP.3 requires resistance to physical manipulation and probing. This is providedbyF.IC_CL(SF_DPM,SF_PS,SF_PMA,SF_PLA)whichisprovidedbythehardware 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 trusted IT product for signature creation. This is provided by F.Access_Control. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 95 SECURITY TARGET 10.3 Statement of Compatibility This is a statement of compatibility between this composite security target and the security targets of the hardware [IFX_ST-SLE78]. 10.3.1 Relevance of Hardware TSFs Table 10.3 shows the relevance of the hardware security functions for the composite ST. HW-TSFs Description Relevant Not relevant SF_DPM Device phase management x SF_PS Protection against snooping x SF_PMA Protection against modification attacks x SF_PLA Protection against logical attacks x SF_CS (Triple DES)* Cryptographic support x SF_CS (AES)* Cryptographic support x SF_CS (RSA) Cryptographic support x SF_CS (EC) Cryptographic support x SF_CS (SHA-2) Cryptographic support x SF_CS (TRNG) Cryptographic support x SF_MAE Mutual Authentication Extension x * only the hardware-implementation is used by the TOE Table 10.3: Relevance of hardware 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, not contradictory to the security objectives of this ST or covered by appropriate 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.Key-Function (usage of key-dependent functions): no conflict MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 96 SECURITY TARGET 10.3.2.2 Threats The threats of the TOE and the hardware can be mapped (see Table 10.4) 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.Phys-Manipulation (physical manipulation): matches T.Hack_Phys of the TOE ST – T.Phys-Probing (physical probing): matches T.Hack_Phys of the TOE ST – T.Malfunction (malfunction due to environmental stress): no conflict – T.Leak-Inherent(inherentinformationleakage): matchesT.SCD_DivulgoftheTOE 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.Mem-Access (memory access violation): matches T.Hack_Phys and T.SigF_Misuse of the TOE ST – T.Masquerade_TOE (masquerade the TOE): not applicable – T.Mem-Access (memory access violation): matches T.Malfunction, T.Abuse-Func and T.Phys-Tamper of the TOE ST T.SCD_Divulg T.Hack_Phys T.SigF_Misuse T.Phys-Manipulation x T.Phys-Probing x T.Leak-Inherent x T.Leak-Forced x T.Abuse-Func x T.Mem-Access x x Table 10.4: Mapping of hardware to TOE Threats MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 97 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.Add-Functions (additional specific security functionality): no conflict – P.Crypto-Service (cryptographic services of the TOE): no conflict – P.Lim_Block_Loader (limiting and blocking the loader 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.5). 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.Add- Functions of the hardware ST – OT.SCD_SVD_Corresp (correspondence between SVD and SCD): covered by O.Add-Functions of the hardware ST – OT.SCD_Secrecy (secrecy of the signature creation data): covered by O.Add- Functions of the hardware ST – OT.Sig_Secure (cryptographic security of the digital signature): covered by O.Add-Functions of the hardware 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, O.Phys-Manipulation and O.Leak-Forced of the hardware ST – OT.Tamper_Resistance (tamper resistance): covered by O.Phys-Probing, O.Malfunction, O.Phys-Manipulationand O.Leak-Forced 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 98 SECURITY TARGET • Security objectives for the hardware – O.Phys-Manipulation (protection against physical manipulation): covered by OT.Tamper_ID and – 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.Leak-Inherent (protection against inherent information leakage): covered by OT.EMSEC_Design of the TOE ST – O.Leak-Forced (protection against forced information leakage): covered by OT.Tamper_ID and OT.Tamper_Resistance 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.Cap_Avail_Loader (capability and availability of the loader): no conflict – O.TDES (cryptographic service Triple-DES): no conflicts – O.AES (cryptographic service AES): no conflicts – O.SHA (cryptographic service Hash function): no conflicts – O.Authentication (authentication to external entities): no conflicts – O.Prot_TSF_Confidentiality (protection of the confidentiality of the TSF): no con- flicts – O.Ctrl_Auth_Loader/Package1+ (access control and authenticity for the loader): no conflicts – O.Add-Functions (additional specific security functionality): covered by OT.SCD_Unique, OT.SCD_SVD_Corresp, OT.SCD_Secrecy and OT.Sig_Secure of the TOE ST – O.Mem-Access (area based memory access control): no conflicts – OE.Lim_Block_Loader (limitation of capability and blocking the loader): no con- flict – OE.Loader_Usage/Package1+ (secure usage of the Loader): no conflicts – OE.TOE_Auth (external entities authenticating of the TOE): no conflicts – OE.Resp-Appl (treatment of user data): no conflicts – OE.Process-Sec-IC (protection during packaging, finishing and personalization): no conflicts MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 99 SECURITY TARGET OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance O.Phys-Manipulation x x x O.Phys-Probing x x x O.Malfunction x x O.Leak-Inherent x x O.Leak-Forced x x O.Add-Functions x x x x Table 10.5: 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.6). 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/EC of the hardware ST – FCS_CKM.1/DH_PACE (cryptographic key generation - Diffie-Hellman for PACE session keys): matches FCS_COP.1/ECDH of the hardware ST – FCS_CKM.1/CA_STATIC (cryptographic key generation - ECC key pair generation for Chip Authentication): matches FCS_CKM.1/EC of the hardware ST – FCS_CKM.1/CA (cryptographic key generation - Diffie-Hellman for Chip Authenti- cation session keys): matches FCS_COP.1/ECDH of the hardware ST – FCS_CKM.4 (cryptographic key destruction): no conflicts – FCS_COP.1/SCD (cryptographic operation - SCD): matches FCS_COP.1/RSA and FCS_COP.1/ECDSA of the hardware ST – FCS_COP.1/SHA (cryptographic operation - hashes): no conflicts – FCS_COP.1/CA_ENC (cryptographic operation - symmetric encryption / decryp- tion): matches FCS_COP.1/TDES and FCS_COP.1/AES of the hardware ST – FCS_COP.1/SIG_VER (cryptographic operation - signature verification): matches FCS_COP.1/ECDSA of the hardware ST – FCS_COP.1/CA_MAC (cryptographic operation - MAC): matches FCS_COP.1/TDES and FCS_COP.1/AES of the hardware ST – FCS_COP.1/PACE_ENC (cryptographic operation - encryption / decryption AES/3DES): matches FCS_COP.1/TDES and FCS_COP.1/AES of the hardware ST – FCS_COP.1/PACE_MAC(cryptographicoperation-MAC):matchesFCS_COP.1/TDES and FCS_COP.1/AES of the hardware ST MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 100 SECURITY TARGET – FCS_RND.1 (quality metric for random numbers): matches FCS_RNG.1/TRNG of the hardware 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): no conflicts – 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, FDP_IFC.1 and FPT_ITT.1 of the hardware ST – FPT_FLS.1 (failure with preservation of secure state): matches FRU_FLT.2 and FPT_FLS.1 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 and FPT_TST.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 (audit storage): no conflicts – FMT_LIM.1 (limited capabilities): no conflicts – FMT_LIM.2 (limited availability): no conflicts – FMT_LIM.1/Loader (limited capabilities - loader): no conflicts – FMT_LIM.2/Loader (limited availability - loader): no conflicts – FDP_ACC.1 (subset access control): covered by FDP_ACC.1/* of the TOE ST – FDP_ACF.1 (security attribute based access control): covered by FDP_ACF.1/* of the TOE ST – FDP_ACC.1/Loader (subset access control - loader): not applicable – FDP_ACF.1/Loader (security attribute based access control - loader): not applica- ble – FIA_API.1 (authentication proof of identity): not applicable – FPT_PHP.3 (resistance to physical attack): covered by FPT_PHP.3 of the TOE ST – FDP_ITT.1 (basic internal transfer protection): covered by FPT_EMS.1/* of the TOE ST – FDP_SDC.1 (stored data confidentiality): no conflicts – FDP_SDI.2 (stored data integrity monitoring and action): no conflicts – FDP_IFC.1 (subset information flow control): covered by FPT_EMS.1/* of the TOE ST – FMT_MSA.1 (management of security attributes): used implicitly, no conflicts – FMT_MSA.3 (static attribute initialization): used implicitly, no conflicts – FMT_SMF.1 (specification of management functions): no conflicts – FRU_FLT.2 (limited fault tolerance): covered by FPT_FLS.1 and FPT_TST.1 of the TOE ST MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 101 SECURITY TARGET – FPT_ITT.1 (basic internal TSF data transfer protection): covered by FPT_EMS.1/* of the TOE ST – FPT_TST.2 (subset TOE testing): covered by FPT_TST.1 of the TOE ST – FPT_FLS.1 (failure with preservation of secure state): covered by FPT_FLS.1 of the TOE ST – FCS_RNG.1/TRNG (generation of random numbers): covered by FCS_RND.1 of the TOE ST – FCS_COP.1/TDES (cryptographic operation - TDES): covered by FCS_COP.1/PACE_ENC, FCS_COP.1/CA_ENC, FCS_COP.1/PACE_MAC and FCS_COP.1/CA_MAC of the TOE ST – FCS_CKM.4/TDES(cryptographickeydestruction-TDES):usedimplicitly, nocon- flicts – FCS_COP.1/AES(cryptographicoperation-AES):coveredbyFCS_COP.1/PACE_ENC, FCS_COP.1/CA_ENC, FCS_COP.1/PACE_MAC and FCS_COP.1/CA_MAC of the TOE ST – FCS_CKM.4/AES (cryptographic key destruction - AES): used implicitly, no con- flicts – FCS_COP.1/SHA(cryptographicoperation(SHA-1,SHA-224andSHA-256)): notrel- evant – FCS_COP.1/RSA(cryptographicoperation(RSA)):coveredbyFCS_COP.1/SCDofthe TOE ST – FCS_CKM.1/RSA (cryptographic key generation (RSA key generation)): covered by FCS_CKM.1/SCD of the TOE ST – FCS_COP.1/ECDSA (cryptographic operation (ECDSA)): covered by FCS_COP.1/SCD of the TOE ST – FCS_COP.1/ECDH (cryptographic operation (ECDH)): covered by FCS_CKM.1/DH_PACE and FCS_CKM.1/CA of the TOE ST – FCS_CKM.1/EC (cryptographic key generation (EC key generation)): covered by and FCS_CKM.1/SCD and FCS_CKM.1/CA_STATIC of the TOE ST – FCS_COP.1/TDES_SCL (cryptographic operation - TDES - SCL): not relevant – FCS_CKM.4/TDES_SCL (cryptographic key destruction - TDES - SCL): not relevant – FCS_COP.1/AES_SCL (cryptographic operation - AES - SCL): not relevant – FCS_CKM.4/AES_SCL (cryptographic key destruction - AES - SCL): not relevant MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 102 SECURITY TARGET FCS_CKM.1/SCD FCS_CKM.1/DH_PACE FCS_CKM.1/CA_STATIC FCS_CKM.1/CA FCS_COP.1/SCD 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/* FPT_EMS.1/* FPT_FLS.1 FPT_PHP.3 FPT_TST.1 FDP_ACC.1 x FDP_ACF.1 x FPT_PHP.3 x FDP_ITT.1 x FDP_IFC.1 x FRU_FLT.2 x FPT_ITT.1 x FPT_TST.2 x FPT_FLS.1 x FCS_RNG.1 x FCS_COP.1/TDES x x FCS_COP.1/AES x x FCS_COP.1/RSA x FCS_CKM.1/RSA x FCS_COP.1/ECDSA x x FCS_COP.1/ECDH x x FCS_CKM.1/EC x x Table 10.6: 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 EAL6 augmented with ALC_FLR.1 This shows that the assurance requirements of the hardware exceed that of the TOE and thus all assurance requirements of the TOE are met. 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 / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 103 SECURITY TARGET Bibliography [AGD] MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892) – User Guidance, MaskTech International GmbH, Version 1.3, 2019-07- 03. [ANSI_X9.62] ANSI X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), Inc. Accredited Standards Committee X9, 2005-11-16. [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-02102-1] BSI TR-02102-1, Kryptographische Verfahren: Empfehlungen und Schlüssellängen, BSI, Version 2018-01, 2018-01-22. [BSI_TR-03110-1] TR-03110-1, Technical Guideline TR-03110-1: Advanced Security Mech- anisms 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 Mechanisms for Machine Readable Travel Documents and eIDAS To- ken – Part 2 – Protocols for electronic IDentification, Authentication and trust Services (eIDAS), BSI, Version 2.21, 2016-12-21. [BSI_TR-03110-3] TR-03110-3, Technical Guideline 03110: Advanced Security Mecha- nisms for Machine Readable Travel Documents and eIDAS Token - Part 3 – Common Specifications, BSI, Version 2.21, 2016-12-21. [BSI_TR-03111] TR-03111, Technical Guideline TR-03111: Elliptic Curve Cryptography, BSI, Version 2.1, 2018-06-01. [BSI_TR-03116-2] TR-03116-2, Technische Richtlinie – Kryptographische Verfahren für Projekte der Bundesregierung - Teil 2 – Hoheitliche Ausweisdoku- mente, BSI, Stand 2018, 2018-04-12. [CC_Part1] CCMB-2017-04-001, Version 3.1, Revision 5, Common Criteria for In- formation Technology Security Evaluation, Part 1: Introduction and General Model, Common Criteria Maintenance Board, 2017-04. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 104 SECURITY TARGET [CC_Part2] CCMB-2017-04-002,Version3.1,Revision5,CommonCriteriaforInfor- mation Technology Security Evaluation, Part 2: Security Functional Components, Common Criteria Maintenance Board, 2017-04. [CC_Part3] CCMB-2017-04-003, Version 3.1, Revision 5, Common Criteria for In- formationTechnologySecurityEvaluation, Part3: SecurityAssurance Components, Common Criteria Maintenance Board, 2017-04. [CC_PP-0056-V2] BSI-CC-PP-0056-V2-2012, Common Criteria Protection Profile / Ma- chine Readable Travel Document with ’ICAO Application’, Extended Access Control with PACE, BSI, Version 1.3.2, 2012-12-05. [CC_PP-0059] BSI-CC-PP-0059-2009-MA-02, Protection profiles for Secure signa- ture creation device – Part 2: Device with key generation, Information Society 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 / Ma- chine Readable Travel Document using Standard Inspection Proce- dure 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 creation device – Part 4: Extension for device with key generation and trustedcommunicationwithcertificategenerationapplication, Infor- mation 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 creation device – Part 5: Extension for device with key generation and trusted communication with signature creation application, Infor- mation 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 Augmentation Packages, BSI, Version 1.0, 2014-01-13. [CC_PP-0086] BSI-CC-PP-0086-2015, Common Criteria Protection Profile / Elec- tronic document implementing Extended Access Control Version 2 (EAC2) based on BSI TR-03110 (EAC2_PP), BSI, Version 1.01, 2015-05- 20. [CID_2016/650] European Commission. COMMISSION IMPLEMENTING DECISION (EU) 2016/650 of 25 April 2016 laying down standards for the security as- sessment of qualified signature and seal creation devices pursuant to Articles 30(3) and 39(2) of Regulation (EU) No 910/2014 of the Eu- ropean Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market. Official Journal of the European Union, L109:40 – 42, 2016. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 105 SECURITY TARGET [DIR_1999/93/EC] European Parliament. DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999 on a Com- munity 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, National Institute of Standards and Technology, 2001-05. [FIPS_180-4] FIPS PUB 180-4, Secure Hash Standard, National Institute of Stan- dards and Technology, 2012-03. [FIPS_186-4] FIPS PUB 186-4, DIGITAL SIGNATURE STANDARD (DSS), National Insti- tute of Standards and Technology, 2013-07. [FIPS_197] FIPS PUB 197, ADVANCED ENCRYPTION STANDARD (AES), National In- stitute of Standards and Technology, 2001-11-26. [ICAO_9303] ICAO Doc 9303, Machine Readable Travel Documents, ICAO, 2015. [ICAO_SAC] TR-SAC, Supplemental Access Control for Machine Readable Travel Documents, ICAO, Version 1.1, 2014-04-15. [IEEE_P1363] IEEE-P1363: 2000, Standard Specifications for Public-Key Cryptogra- phy, IEEE, 2000. [IFX_ST-SLE78] BSI-DSZ-CC-0891-V3-2018, Infineon Technologies AG, Security Target Lite ’M7892 Design Steps D11 and G12’, Version 1.2, 2017-11-21. [ISO_10116] ISO/IEC 10116:2006, Information technology – Security techniques – Modes of operation for an n-bit block cipher, ISO/IEC, 2006-02-01. [ISO_7816] ISO/IEC7816:2008,Informationtechnology–Identificationcards–In- tegrated circuit cards – Multipart Standard, ISO/IEC, 2008. [ISO_7816-15] ISO/IEC 7816-15:2016, Information technology – Identification cards – Integrated circuit(s) cards with contacts – Part 15: Cryptograhpic in- formation application, ISO/IEC, 2016-05-15. [ISO_9797-1] ISO/IEC 9797-1:2011, Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher, ISO/IEC, 2011. [KiSch-RNG] Version 2.0, A proposal for: Functionality classes for random number generators, W. Killmann and W. Schindler, 2011-09-18. [MT_Manual] MTCOS Pro V2.5 on IFX SLE78C(L)FX40xxPH(M) – Manual, MaskTech GmbH, 2019-01-10. Version 1.2. [NIST_SP800-38B] NISTSpecialPublication800-38B,RecommendationforBlockCipher Modes of Operation: The CMAC Mode for Authentication, National In- stitute of Standards and Technology, 2005-05. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 106 SECURITY TARGET [NIST_SP800-56A] NIST Special Publication 800-56A Rev. 2, Recommendation for Pair- Wise Key Establishment Schemes Using Discrete Logarithm Cryptog- raphy, National Institute of Standards and Technology, May 2013. [NIST_SP800-67] NIST Special Publication 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, version 1.1, NIST. [NIST_SP800-90a-R1] NIST Special Publication 800-90A Rev. 1, Recommendation for Ran- dom Number Generation Using Deterministic Random Bit Genera- tors, National Institute of Standards and Technology, 2015-06. [PKCS_1_v22] PKCS #1, PKCS #1 v2.2: RSA Cryptography Standard, v2.2, 2012-10-27. [REG_910/2014] European Parliament. REGULATION (EU) No 910/2014 OF THE EU- ROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on elec- tronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Official Journal of the European Union, L257:73 – 114, 2014. [SC_Gemalto] BSI-DSZ-CC-S-0104-2018, Gemalto AG, CC Site Certification Gemalto AG, Version 3.0, 2018-05-08. [SC_HID] BSI-DSZ-CC-S-0114-2018, HID Global GmbH, Site Security Target Lite of HID Global Ireland Teoranta in Galway, Ireland, Doc. No: F-10-138d, Rev. B, 2018-09-13. [SC_HID_MY] BSI-DSZ-CC-S-0085-2018, HID Global GmbH, Site Security Target Lite for HID Global Malaysia, Rev. C, 2018-04-12. [SC_Smartrac] BSI-DSZ-CC-S-0097-2017, SMARTRAC Technology Ltd., Site Security Target for AY1, Version 2.1, 2017-12-06. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 107 SECURITY TARGET 11 Revision History Version Date Author Changes 1.0 2018-11-06 Gudrun Schürer Public version 1.1 2019-01-25 Thomas Rölz Updatecryptodisclaimer, added note to eIDAS regulation and commission implementing deci- sion in section 3.3 1.2 2019-05-03 Thomas Rölz, Gudrun Schürer Update crypto disclaimer and references 1.3 2019-07-03 Gudrun Schürer Inclusion of platform derivative SLE78CLFX4007PHM MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 108 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 / Security Level Comments ST-Reference 1 Authenticated Key Agree- ment / Authentication PACEv2 (Generic Map- ping), PACE-CAM (Chip Authen- tication Mapping), PACE (key agreement, authentication), Elliptic Curve Diffie-Hellman, Nonce Encryption, Authentication Token [BSI_TR-03110-1] [BSI_TR-03110-2] [BSI_TR-03110-3] [ICAO_SAC] [ICAO_9303] [BSI_TR-03111], sec. 4.3.2.1 also cf. line 8 |MRZ| = 160 |Nonce| = 128 BP(r1): 224, 256, 320, 384, 512 NIST: 224, 256, 384, 521 Session keys: 3DES: 112 AES: 128, 192, 256 [BSI_TR-03110-1] [BSI_TR-03110-2] [BSI_TR-03110-3] [ICAO_SAC] [ICAO_9303] FCS_CKM.1/DH_PACE FIA_UAU.1 FIA_UAU.4/PACE FIA_UAU.5/PACE FIA_AFL.1/RAD FIA_AFL.1/ Suspend_PIN FIA_AFL.1/Block_PIN 2 Authentication Chip Authentication V1 [ICAO_9303] [ICAO_SAC] [BSI_TR-03110-1] [ICAO_9303] [ICAO_SAC] [BSI_TR-03110-1] FCS_CKM.1/CA FIA_UAU.5/PACE FIA_UAU.6 FIA_API.1 ECDH [NIST_SP800-56A], sec. 5.5 [BSI_TR-03111] also cf. line 8 BP(r1): 224, 256, 320, 384, 512 NIST: 224, 256, 384, 521 Session keys: 3DES: 112 AES: 128, 192, 256 3 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] sec. 5.2 [FIPS_180-4] sec. 6 [FIPS_186-4] sec. 5 2048 - 4096 1 32 Bit steps. Security Level > 100 bits according to [BSI_TR-02102-1] sec. 1.1 Digital signature cre- ation FCS_COP.1/SCD FDP_UIT.1/DTBS FDP_SDI.2/Persistent FDP_SDI.2/DTBS FDP_DAU.2/SVD 4 Authenticity ECDSA-signature gener- ation [BSI_TR-03111] sec. 4.2.1 [ANSI_X9.62] sec. 7 Brainpool(r1): 224, 256, 320, 384, 512 NIST: 224, 256, 384, 521 Security Level > 100 bits according to [BSI_TR-02102-1] sec. 1.1 Digital signature cre- ation FCS_COP.1/SCD FDP_UIT.1/DTBS FDP_SDI.2/Persistent FDP_SDI.2/DTBS FDP_DAU.2/SVD 1 Technical range. Usual values: 2048, 3072, 4096 bits. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 109 SECURITY TARGET Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application / Security Level Comments ST-Reference 5 Authentication Terminal Authentication V1, ECDSA-signature ver- ification using SHA-224, SHA-256, SHA-384 or SHA-512 [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_9303] [ICAO_SAC] [BSI_TR-03111] sec. 6 [ANSI_X9.62] sec. 7 [FIPS_180-4] sec. 6 also cf. line 16 Brainpool(r1): 224, 256, 320, 384, 512 NIST: 224, 256, 384, 521 [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_9303] [ICAO_SAC] Verification of cer- tificates (Terminal Authentication), FCS_COP.1/SIG_VER FIA_UAU.5/PACE 6 Key Generation ECC key pair generation for Chip Authentication V1 [ICAO_9303] [ICAO_SAC] [BSI_TR-03110-1] [BSI_TR-03110-3] [ANSI_X9.62] sec. G.5.2 [BSI_TR-03111] sec. 4.1.3 Brainpool(r1): 224, 256, 320, 384, 512 NIST: 224, 256, 384, 521 [ICAO_9303] [ICAO_SAC] [BSI_TR-03110-1] [BSI_TR-03110-3] FCS_CKM.1/CA_STATIC 7 Key Generation SCD/SVDpairgeneration Security Level > 100 bits according to [BSI_TR-02102-1] sec. 1.1 FCS_CKM.1/SCD RSA [PKCS_1_v22] sec. 3 [IEEE_P1363] 2048 - 40961 32 Bit steps. ECDSA [BSI_TR-03111] sec. 4.1.3 [ANSI_X9.62] sec. G.5.2 BP(r1): 224, 256, 320, 384, 512 NIST: 224, 256, 384, 521 8 Key Derivation Chip Authentication V1, PACE, Key derivation using SHA-[1, 256] [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_SAC] [ICAO_9303] [FIPS_180-4] sec. 6 [BSI_TR-03111] sec. 4.3.3 3DES: 112 AES: 128, 192, 256 [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_SAC] [ICAO_9303] FCS_CKM.1/CA FCS_CKM.1/DH_PACE 9 Confidentiality 3DES in CBC mode for Secure Messaging [ICAO_SAC], [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] [NIST_SP800-67] (3DES) [ISO_10116] sec. 7 (CBC) 112 [ICAO_SAC], [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] FCS_COP.1/CA_ENC FCS_COP.1/PACE_ENC 10 Confidentiality AES in CBC mode for Se- cure Messaging [ICAO_SAC], [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] [FIPS_197] (AES), [ISO_10116] sec. 7 (CBC) 128, 192, 256 [ICAO_SAC], [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] FCS_COP.1/CA_ENC FCS_COP.1/PACE_ENC 11 Integrity 3DES in Retail-MAC mode for Secure Mes- saging [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_SAC] [ICAO_9303] [NIST_SP800-67] (3DES) [ISO_9797-1] sec. 7.4 (Retail-MAC) 112 [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_SAC] [ICAO_9303] FCS_COP.1/PACE_MAC FCS_COP.1/CA_MAC 12 Integrity CMAC-AES for Secure Messaging [ICAO_SAC], [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] [FIPS_197] (AES) [NIST_SP800-38B]sec. 6 (CMAC) 128, 192, 256 [ICAO_SAC], [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] FCS_COP.1/CA_MAC FCS_COP.1/PACE_MAC 13 Trusted Channel Secure Messaging in ENC/MAC mode estab- lished during PACE [ICAO_SAC] [ICAO_9303] [BSI_TR-03110-1] (PACE) [BSI_TR-03110-3] also cf. lines 8-12 - [ICAO_SAC] [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] FTP_ITC.1/SVD FTP_ITC.1/VAD FTP_ITC.1/DTBS FDP_UIT.1/DTBS MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 110 SECURITY TARGET Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application / Security Level Comments ST-Reference 14 Trusted Channel Secure Messaging in ENC/MAC mode es- tablished during Chip Authentication after PACE [ICAO_SAC] [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] also cf. lines 8-12 - [ICAO_SAC] [ICAO_9303] [BSI_TR-03110-1] [BSI_TR-03110-3] FTP_ITC.1/SCD FTP_ITC.1/VAD FTP_ITC.1/DTBS FCS_CKM.1/CA FDP_UIT.1/DTBS 15 Cryptographic primitive PTG.3 Random num- ber generator (PTG.2 and cryptographic post-processing) [BSI_AIS31v3] [NIST_SP800-90a-R1] sec. 10.2, 10.3.2 - [BSI_TR-03116-2] FCS_RND.1 16 Cryptographic Primitive SHA-[1, 224, 256, 384, 512] [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_9303] [ICAO_SAC] [FIPS_180-4] sec. 6 - [BSI_TR-03110-1] [BSI_TR-03110-3] [ICAO_9303] [ICAO_SAC] Signature Creation Signature Verification Key Derivation Table A.1: Overview Cryptographic Algorithms According to [ICAO_9303], [ICAO_SAC], [BSI_TR-03110-1], [BSI_TR-03110-3] and [BSI_TR-03116-2] the algorithms are suitable for authenticity, authentication, key agree- ment, confidentiality and integrity. An explicit validity period is not given. MTCOS Pro 2.5 SSCD / SLE78CLFX400VPHM/BPHM/7PHM (M7892), Version 1.3 111