Security Target ’CardOS V6.0 ID R1.2’ Rev. 2.50R, Edition 05/2026 Contents Contents 1 About this Document 2 1.1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 ST Introduction (ASE_INT) 5 2.1 ST Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 TOE Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 TOE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Usage and major security features of the TOE . . . . . . . . . . . . . . . . . . . . 6 2.3.2 TOE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.3 File System of the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.4 Non-TOE hardware/software/firmware . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.5 Conformance to eIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 TOE Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 Life Cycle Phases Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 TOE Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.1 TOE Physical Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.2 TOE Logical Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.3 TOE Delivery Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Conformance Claim 14 3.1 CC Conformance Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 CC:2022 Conformance of the Platform ST . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 PP Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4 Package Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5 Conformance Claim Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Security Problem Definition 17 4.1 Assets and External Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 T.Skimming (Skimming travel document / Capturing Card-Terminal Communication) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.2 T.Eavesdropping (Eavesdropping on the communication between the TOE and the PACE terminal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.3 T.Tracing (Tracing travel document) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.4 T.Forgery (Forgery of Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.5 T.Abuse-Func (Abuse of Functionality) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.6 T.Information_Leakage (Information Leakage from travel document) . . . . 23 4.2.7 T.Phys-Tamper (Physical Tampering) . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.8 T.Malfunction (Malfunction due to Environmental Stress) . . . . . . . . . . . . 24 4.2.9 T.Read_Sensitive_Data (Read the sensitive biometric reference data) . . . . 24 4.2.10 T.Counterfeit (Counterfeit of travel document chip data) . . . . . . . . . . . . . 25 4.2.11 T.SCD_Divulg (Storing, copying and releasing of the signature creation data) 25 4.2.12 T.SCD_Derive (Derive the signature creation data) . . . . . . . . . . . . . . . . . . 25 4.2.13 T.Hack_Phys (Physical attacks through the TOE interfaces) . . . . . . . . . . . 25 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC i Contents 4.2.14 T.SVD_Forgery (Forgery of the signature verification data) . . . . . . . . . . . . 25 4.2.15 T.SigF_Misuse (Misuse of the signature creation function of the TOE) . . . . . 26 4.2.16 T.DTBS_Forgery (Forgery of the DTBS/R) . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.17 T.Sig_Forgery (Forgery of the electronic signature) . . . . . . . . . . . . . . . . . 26 4.3 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1 P.Manufact (Manufacturing of the travel document’s chip) . . . . . . . . . . . 26 4.3.2 P.Pre-Operational (Pre-operational handling of the travel document) . . . . 26 4.3.3 P.Card_PKI (PKI for Passive Authentication (issuing branch)) . . . . . . . . . . 27 4.3.4 P.Trustworthy_PKI (Trustworthiness of PKI) . . . . . . . . . . . . . . . . . . . . . . 27 4.3.5 P.Terminal (Abilities and trustworthiness of terminals) . . . . . . . . . . . . . . 27 4.3.6 P.Sensitive_Data (Privacy of sensitive biometric reference data) . . . . . . . . 28 4.3.7 P.Personalisation (Personalisation of the travel document by issuing State or Organisation only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.8 P.CSP_QCert (Qualified certificate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.9 P.QSign (Qualified electronic signatures) . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.10 P.Sigy_SSCD (TOE as secure signature creation device) . . . . . . . . . . . . . . 29 4.3.11 P.Sig_Non-Repud (Non-repudiation of signatures) . . . . . . . . . . . . . . . . . 29 4.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4.1 A.Passive_Auth (PKI for Passive Authentication) . . . . . . . . . . . . . . . . . . . 29 4.4.2 A.Insp_Sys (Inspection Systems for global interoperability) . . . . . . . . . . . . 30 4.4.3 A.Auth_PKI (PKI for Inspection Systems) . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4.4 A.CGA (Trustworthy certificate generation application) . . . . . . . . . . . . . . 30 4.4.5 A.SCA (Trustworthy signature creation application) . . . . . . . . . . . . . . . . . 30 4.4.6 A.Env_Admin (Environment for administrator) . . . . . . . . . . . . . . . . . . . . 31 4.4.7 A.Env_Mass_Signature (Environment for a mass signature TOE) . . . . . . . . 31 5 Security Objectives 32 5.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1.1 OT.Data_Integrity (Integrity of Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1.2 OT.Data_Authenticity (Authenticity of Data) . . . . . . . . . . . . . . . . . . . . . . 32 5.1.3 OT.Data_Confidentiality (Confidentiality of Data) . . . . . . . . . . . . . . . . . . 33 5.1.4 OT.Tracing (Tracing travel document) . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.5 OT.Prot_Abuse-Func (Protection against Abuse of Functionality) . . . . . . . 33 5.1.6 OT.Prot_Inf_Leak (Protection against Information Leakage) . . . . . . . . . . . 33 5.1.7 OT.Prot_Phys-Tamper (Protection against Physical Tampering) . . . . . . . . . 34 5.1.8 OT.Prot_Malfunction (Protection against Malfunctions) . . . . . . . . . . . . . . 34 5.1.9 OT.Identification (Identification of the TOE) . . . . . . . . . . . . . . . . . . . . . . 34 5.1.10 OT.AC_Pers (Access Control for Personalisation of logical MRTD) . . . . . . . 34 5.1.11 OT.Sens_Data_Conf (Confidentiality of sensitive biometric reference data) . 35 5.1.12 OT.Chip_Auth_Proof (Proof of the travel document’s chip authenticity) . . . 35 5.1.13 OT.AA_Proof (Proof of the travel document’s chip authenticity) . . . . . . . . 36 5.1.14 OT.Lifecycle_Security (Lifecycle security) . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1.15 OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) . . . . . . . . . . . . 36 5.1.16 OT.SCD_Unique (Uniqueness of the signature creation data) . . . . . . . . . . 36 5.1.17 OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) . . . . . . . . 36 5.1.18 OT.SCD_Secrecy (Secrecy of the signature creation data) . . . . . . . . . . . . . 37 5.1.19 OT.Sig_Secure (Cryptographic security of the electronic signature) . . . . . . 37 5.1.20 OT.Sigy_SigF (Signature creation function for the legitimate signatory only) 37 5.1.21 OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) . . . . . . . . . . . . 37 5.1.22 OT.EMSEC_Design (Provide physical emanations security) . . . . . . . . . . . . 37 5.1.23 OT.Tamper_ID (Tamper detection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.24 OT.Tamper_Resistance (Tamper resistance) . . . . . . . . . . . . . . . . . . . . . . 38 5.1.25 OT.TOE_SSCD_Auth (Authentication proof as SSCD) . . . . . . . . . . . . . . . . 38 5.1.26 OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export) . . . . . . . . . . . 38 5.1.27 OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) . . . . . . . . 38 5.1.28 OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) . . . . . . . 39 5.2 Security Objectives for the Operational Environment . . . . . . . . . . . . . . . 39 5.2.1 OE.Legislative_Compliance (Issuing of the travel document) . . . . . . . . . . 39 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC ii Contents 5.2.2 OE.Passive_Auth_Sign (Authentication of travel document by Signature) . . 39 5.2.3 OE.Personalisation (Personalisation of travel document) . . . . . . . . . . . . . 40 5.2.4 OE.Terminal (Terminal operating) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.5 OE.Travel_Document_Holder (Travel document holder Obligations) . . . . . 41 5.2.6 OE.Auth_Key_Travel_Document (Travel document Authentication Key) . . . 41 5.2.7 OE.AA_Key_Travel_Document (Travel document Authentication Key) . . . . 41 5.2.8 OE.Authoriz_Sens_Data (Authorization for Use of Sensitive Biometric Reference Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.9 OE.Exam_Travel_Document (Examination of the physical part of the travel document) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.10 OE.Prot_Logical_Travel_Document (Protection of data from the logi- cal travel document) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.11 OE.Ext_Insp_Systems (Authorization of Extended Inspection Systems) . . . 43 5.2.12 OE.SVD_Auth (Authenticity of the SVD) . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.13 OE.CGA_QCert (Generation of qualified certificates) . . . . . . . . . . . . . . . . 43 5.2.14 OE.SSCD_Prov_Service (Authentic SSCD provided by SSCD- provisioning service) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.15 OE.HID_VAD (Protection of the VAD) . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.16 OE.HID_TC_VAD_Exp (Trusted channel of HID for VAD export) . . . . . . . . . 44 5.2.17 OE.DTBS_Intend (SCA sends data intended to be signed) . . . . . . . . . . . . 44 5.2.18 OE.DTBS_Protect (SCA protects the data intended to be signed) . . . . . . . 44 5.2.19 OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS export) . . . . . . . 45 5.2.20 OE.Signatory (Security obligation of the signatory) . . . . . . . . . . . . . . . . . 45 5.2.21 OE.Dev_Prov_Service (Authentic SSCD provided by SSCD Provisioning Service) 45 5.2.22 OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) 46 5.2.23 OE.CGA_TC_SVD_Imp (CGA trusted channel for SVD import) . . . . . . . . . . 46 5.2.24 OE.Env_Admin (Administrator works in trusted environment) . . . . . . . . . 47 5.2.25 OE.Env_Mass_Signature (Mass signatures are generated intrusted environment only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.3 Security Objective Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.3.1 Security Objectives Backtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.3.2 Security Objectives Sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6 Extended Components Definition 58 7 Security Requirements (ASE_REQ) 59 7.1 Elliptic curves used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2 RSA key support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.3 Hash functions implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.4 Security attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.5 Keys and certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.6 Security Functional Requirements for the TOE . . . . . . . . . . . . . . . . . . . . 65 7.6.1 Class FCS Cryptographic support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.6.1.1 FCS_CKM.1/CA_EC Cryptographic key generation - EC Diffie-Hellman for Chip Authentication session keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.6.1.2 FCS_CKM.1/CA_RSA Cryptographic key generation - RSA DH for Chip Authentication session keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.6.1.3 FCS_CKM.1/DH_PACE_EC Cryptographic key generation - EC Diffie- Hellman for PACE session keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.6.1.4 FCS_CKM.1/DH_PACE_RSA Cryptographic key generation - RSA Diffie- Hellman for PACE session keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.6.1.5 FCS_CKM.1/EC (Cryptographic key generation – EC) . . . . . . . . . . . . . . . . . 69 7.6.1.6 FCS_CKM.1/RSA (Cryptographic key generation – RSA) . . . . . . . . . . . . . . . 70 7.6.1.7 FCS_CKM.4 Cryptographic key destruction . . . . . . . . . . . . . . . . . . . . . . 71 7.6.1.8 FCS_COP.1/EC (Cryptographic operation – EC) . . . . . . . . . . . . . . . . . . . . 71 7.6.1.9 FCS_COP.1/RSA (Cryptographic operation – RSA) . . . . . . . . . . . . . . . . . . 72 7.6.1.10 FCS_COP.1/SHA (Cryptographic operation – Hash calculation) . . . . . . . . . . 73 7.6.1.11 FCS_COP.1/AES_MAC (Cryptographic operation – MACing with AES) . . . . . 74 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC iii Contents 7.6.1.12 FCS_COP.1/CA_ENC (Cryptographic operation - Symmetric Encryp- tion / Decryption) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.6.1.13 FCS_COP.1/CA_MAC (Cryptographic operation - MAC) . . . . . . . . . . . . . . . 75 7.6.1.14 FCS_COP.1/PACE_ENC (Cryptographic operation - Encryption / De- cryption AES ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.6.1.15 FCS_COP.1/PACE_MAC (Cryptographic operation - MAC) . . . . . . . . . . . . . 77 7.6.1.16 FCS_COP.1/SIG_VER_EC (Cryptographic operation - Signature verifi- cation by travel document with EC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.6.1.17 FCS_COP.1/SIG_VER_RSA (Cryptographic operation - Signature verifi- cation by travel document with RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.6.1.18 FCS_COP.1/AA_SGEN_EC (Cryptographic operation - Signature gen- eration for AA with EC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.6.1.19 FCS_RNG.1 (Random number generation) . . . . . . . . . . . . . . . . . . . . . . . 80 7.6.2 Class FIA Identification and Authentication . . . . . . . . . . . . . . . . . . . . . . 81 7.6.2.1 FIA_UID.1/PACE (Timing of identification) . . . . . . . . . . . . . . . . . . . . . . . . 82 7.6.2.2 FIA_UID.1 (Timing of identification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.6.2.3 FIA_UAU.1/PACE (Timing of authentication) . . . . . . . . . . . . . . . . . . . . . . 83 7.6.2.4 FIA_UAU.1 (Timing of authentication) . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.6.2.5 FIA_UAU.4/PACE (Single-use authentication mechanisms - Single-use authentication of the Terminal by the TOE) . . . . . . . . . . . . . . . . . . . . . . 85 7.6.2.6 FIA_UAU.5/PACE (Multiple authentication mechanisms) . . . . . . . . . . . . . 86 7.6.2.7 FIA_UAU.6/EAC (Re-authenticating - Re-authenticating of Terminal by the TOE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.6.2.8 FIA_UAU.6/PACE (Re-authenticating of Terminal by the TOE) . . . . . . . . . . 87 7.6.2.9 FIA_UAU.6/CA (Re-authenticating – Re-authenticating of Terminal by the TOE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.6.2.10 FIA_UAU.6/Signature_Creation (Re-authenticating for Signature Creation) . 88 7.6.2.11 FIA_API.1/CA (Authentication Proof of Identity by Chip Authentication) . . . 89 7.6.2.12 FIA_API.1/AA (Authentication Proof of Identity by Active Authentication) . . 89 7.6.2.13 FIA_AFL.1/PACE (Authentication failure handling - PACE authentica- tion using non-blocking authorization data) . . . . . . . . . . . . . . . . . . . . . 89 7.6.2.14 FIA_AFL.1/RAD (Authentication failure handling – for Signatory PIN) . . . . . 90 7.6.2.15 FIA_AFL.1/Suspend_PIN (Authentication failure handling – Suspend- ing PIN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.6.2.16 FIA_AFL.1/Block_PIN (Authentication failure handling – Blocking PIN) . . . . 91 7.6.2.17 FIA_AFL.1/AuthAdmin (Authentication failure handling – of adminis- trator for personalization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.6.2.18 FIA_API.1 (Authentication proof of identity) . . . . . . . . . . . . . . . . . . . . . . 92 7.6.3 Class FDP User Data Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.6.3.1 FDP_ACC.1/TRM (Subset access control) . . . . . . . . . . . . . . . . . . . . . . . . 93 7.6.3.2 FDP_ACF.1/TRM (Security attribute based access control) . . . . . . . . . . . . . 93 7.6.3.3 FDP_RIP.1 (Subset residual information protection) . . . . . . . . . . . . . . . . . 95 7.6.3.4 FDP_UCT.1/TRM (Basic data exchange confidentiality - MRTD) . . . . . . . . . 96 7.6.3.5 FDP_UIT.1/TRM (Data exchange integrity – Terminal) . . . . . . . . . . . . . . . . 96 7.6.3.6 FDP_ACC.1/SCD/SVD_Generation (Subset access control) . . . . . . . . . . . . . 97 7.6.3.7 FDP_ACF.1/SCD/SVD_Generation (Security attribute based access control) . 97 7.6.3.8 FDP_ACC.1/SVD_Transfer (Subset access control) . . . . . . . . . . . . . . . . . . 98 7.6.3.9 FDP_ACF.1/SVD_Transfer (Subset access control) . . . . . . . . . . . . . . . . . . 98 7.6.3.10 FDP_ACC.1/Signature_Creation (Subset access control) . . . . . . . . . . . . . . 99 7.6.3.11 FDP_ACF.1/Signature_Creation (Security attribute based access control) . . 99 7.6.3.12 FDP_UIT.1/DTBS (Data exchange integrity – DTBS) . . . . . . . . . . . . . . . . . . 100 7.6.3.13 FDP_SDI.2/Persistent (Stored data integrity monitoring and action) . . . . . 100 7.6.3.14 FDP_SDI.2/DTBS (Stored data integrity monitoring and action) . . . . . . . . . 101 7.6.3.15 FDP_DAU.2/SVD (Data Authentication with Identity of Guarantor) . . . . . . 101 7.6.4 Class FTP Trusted Path/Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 7.6.4.1 FTP_ITC.1/PACE (Inter-TSF trusted channel after PACE) . . . . . . . . . . . . . . 101 7.6.4.2 FTP_ITC.1/SVD (Inter-TSF trusted channel) . . . . . . . . . . . . . . . . . . . . . . . 102 7.6.4.3 FTP_ITC.1/VAD (Inter-TSF trusted channel – TC Human Interface Device) . . 103 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC iv Contents 7.6.4.4 FTP_ITC.1/DTBS (Inter-TSF trusted channel – Signature creation Application) 103 7.6.5 Class FMT Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.6.5.1 FMT_SMR.1/PACE (Security roles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.6.5.2 FMT_SMR.1 (Security roles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.6.5.3 FMT_LIM.1 (Limited capabilities) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6.5.4 FMT_LIM.2 (Limited availability) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6.5.5 FMT_MTD.1/INI_ENA (Management of TSF data - Writing Initialization and Pre-personalization Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.5.6 FMT_MTD.1/INI_DIS (Management of TSF data - Reading and Using Initialization and Pre-personalization Data) . . . . . . . . . . . . . . . . . . . . . . 106 7.6.5.7 FMT_MTD.1/PA (Management of TSF data - Personalization Agent) . . . . . . 107 7.6.5.8 FMT_MTD.1/CVCA_INI (Management of TSF data - Initialization of CVCA Certificate and Current Date) . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.6.5.9 FMT_MTD.1/CVCA_UPD (Management of TSF data - Country Verifying Certification Authority) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.6.5.10 FMT_MTD.1/DATE (Management of TSF data - Current date) . . . . . . . . . . . 108 7.6.5.11 FMT_MTD.1/CA_AA_PK (Management of TSF data - CA and AA Private Key) 109 7.6.5.12 FMT_MTD.1/CAPK (Management of TSF data - Chip Authentication Private Key) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.6.5.13 FMT_MTD.1/KEY_READ (Management of TSF data - Key Read) . . . . . . . . . 110 7.6.5.14 FMT_MTD.1/RAD (Management of TSF data) . . . . . . . . . . . . . . . . . . . . . . 110 7.6.5.15 FMT_MTD.1/Signatory (Management of TSF data) . . . . . . . . . . . . . . . . . . 111 7.6.5.16 FMT_MTD.3 (Secure TSF data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.6.5.17 FMT_SMF.1 (Specification of Management Functions) . . . . . . . . . . . . . . . 112 7.6.5.18 FMT_MOF.1 (Management of security functions behavior) . . . . . . . . . . . . 112 7.6.5.19 FMT_MSA.1/Admin (Management of security attributes) . . . . . . . . . . . . . 113 7.6.5.20 FMT_MSA.1/Signatory (Management of security attributes) . . . . . . . . . . . . 113 7.6.5.21 FMT_MSA.2 (Secure security attributes) . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.6.5.22 FMT_MSA.3 (Static attribute initialization) . . . . . . . . . . . . . . . . . . . . . . . 114 7.6.5.23 FMT_MSA.4 (Security attribute value inheritance) . . . . . . . . . . . . . . . . . . 114 7.6.6 Class FAU Security Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.6.6.1 FAU_SAS.1 (Audit storage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.6.7 Class FPT Protection of the Security Functions . . . . . . . . . . . . . . . . . . . . 115 7.6.7.1 FPT_EMS.1 (TOE Emanation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.6.7.2 FPT_EMS.1/SSCD (TOE Emanation of SCD and RAD) . . . . . . . . . . . . . . . . 116 7.6.7.3 FPT_FLS.1 (Failure with preservation of secure state) . . . . . . . . . . . . . . . . 117 7.6.7.4 FPT_TST.1 (TSF testing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.6.7.5 FPT_PHP.1 (Passive detection of physical attack) . . . . . . . . . . . . . . . . . . . 118 7.6.7.6 FPT_PHP.3 Resistance to physical attack . . . . . . . . . . . . . . . . . . . . . . . . 118 7.7 Security Assurance Requirements for the TOE . . . . . . . . . . . . . . . . . . . . 119 7.8 Security Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.8.1 Security Functional Requirements Coverage . . . . . . . . . . . . . . . . . . . . . 120 7.8.2 TOE Security Requirements Sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.9 Satisfaction of Dependencies of Security Requirements . . . . . . . . . . . . . 134 7.10 Rationale for Chosen Security Assurance Requirements . . . . . . . . . . . . . 137 7.11 Security Requirements - Mutual Support and Internal Consistency . . . . . . 138 8 TOE Summary Specification (ASE_TSS) 140 8.1 TOE Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 8.1.1 User Identification and Authentication (ePass) . . . . . . . . . . . . . . . . . . . . 140 8.1.1.1 Travel document manufacturer Identification and Authentication . . . . . . 141 8.1.1.2 Personalization Agent Identification and Authentication . . . . . . . . . . . . . 141 8.1.1.3 PACE Terminal Identification and Authentication . . . . . . . . . . . . . . . . . . 142 8.1.1.4 Establishing the trusted channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 8.1.2 User Identification and Authentication (eSign) . . . . . . . . . . . . . . . . . . . . 144 8.1.2.1 Administrator Identification and Authentication . . . . . . . . . . . . . . . . . . 146 8.1.2.2 Signatory Identification and Authentication . . . . . . . . . . . . . . . . . . . . . . 147 8.1.2.3 PACE Terminal Identification and Authentication . . . . . . . . . . . . . . . . . . 149 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC v Contents 8.1.2.4 EIS-AIP-PACE Identification and Authentication . . . . . . . . . . . . . . . . . . . 150 8.1.3 Advanced Inspection Procedure with PACE . . . . . . . . . . . . . . . . . . . . . . 150 8.1.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 8.1.4.1 PACE or “PACE with CAM” protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 8.1.4.2 Chip Authentication Protocol v.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 8.1.4.3 Active Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.1.4.4 Terminal Authentication Protocol v.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.1.4.5 Passive Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 8.1.5 Access Control (General and ePass) . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 8.1.5.1 Read access to the data of the ePass application at phase Operational Use 154 8.1.5.2 Write access to data of the ePass application at phase Operational Use . . 154 8.1.5.3 General access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.1.6 Access Control (eSign) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.1.6.1 Access Control provided by the Signature_Creation_SFP . . . . . . . . . . . . . 156 8.1.6.2 Access Control provided by the SCD/SVD_Generation_SFP . . . . . . . . . . . 156 8.1.6.3 Access Control provided by the SVD_Transfer_SFP . . . . . . . . . . . . . . . . . 157 8.1.7 Key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 8.1.8 Signature Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.1.8.1 Signature Creation with EC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.1.8.2 Signature Creation with RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.1.8.3 TOE IT environment generated hash values . . . . . . . . . . . . . . . . . . . . . . 159 8.1.8.4 TOE generated hash values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.1.8.4.1 Hash last round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.1.9 Test features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.1.10 Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.2 Compatibility between the Composite ST and the Platform-ST . . . . . . . . 163 8.2.1 Assurance requirements of the composite evaluation . . . . . . . . . . . . . . . 163 8.2.2 Security objectives for the environment of the platform . . . . . . . . . . . . . 163 8.2.3 Usage of platform TSF by TOE TSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 8.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 A Overview of Cryptographic Algorithms 166 Bibliography 172 Index 175 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC vi Contents © Eviden Germany GmbH 2026. All rights reserved. The reproduction, transmission or use of this docu- ment or its contents is not permitted without express written authority. Offenders will be liable for damages. All rights, including rights created by patent grant or registration of a utility model or design, are reserved. Eviden Germany GmbH Otto-Hahn-Ring 6 D-81739 Munich Germany Disclaimer of Liability We have checked the contents of this manual for agree- ment with the hardware and software described. Since deviations cannot be precluded entirely, we cannot guarantee full agreement. However, the data in this manual are reviewed regularly and any necessary cor- rections included in subsequent editions. Suggestions for improvement are welcome. Subject to change without notice. © Eviden Germany GmbH 2026. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 1 1 About this Document 1 About this Document 1.1 Revision History Table 1.1: History of released Versions Version Release date Remarks 1.91R 2021-10-21 Release Version R1.0 2.00R 2022-06-07 Release Version R1.1 (Maintenance) 2.10R 2023-09-18 Release Version R1.1 (Re-certification) 2.40R 2024-11-20 Release Version R1.2 (Re-certification) 2.50R 2026-05-04 Release Version R1.2 (Re-certification) 1.2 Acronyms 5 BAC Basic Access Control BIS-BAC Basic Inspection System - Basic Access Control, see [BSI-CC-PP-0068-V2-2011-MA-01] CAN 10 Card Access Number, see [BSI-TR-03110-1-V220], section 2.3. DTBS Data To Be Signed EAC Extended Access Control 15 MRTD Machine Readable Travel Documents MRZ Non-block static secret key from Machine-Readable Zone, see [BSI-TR-03110-1-V220], section 2.3. 20 PACE Password Authenticated Connection Establishment, see [ICAO-9303-2015], Part 11. PIN Personal Identification Number (equivalent to CHV) PTRNG 25 Physical True Random Generator (short: physical RNG) QES Qualified Electronic Signature RAD Reference Authentication Data 30 SVD Signature Verification Data TOE Target Of Evaluation VAD 35 Verification Authentication Data Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 2 1 About this Document 1.3 Terms and Definitions Advanced Inspection Procedure AIP A specific order of authentication steps between a travel document and a terminal 40 as required by [ICAO-TR-101], namely (i) PACE, (ii) Chip Authentication v.1, (iii) Passive Authentication with SOD and (iv) Terminal Authentication v.1. AIP can generally be used by EIS-AIP-PACE. Common Criteria Set of rules and procedures for evaluating the security properties of a product Note 1 to 45 entry: see bibliography for details on the specification of Common Criteria. Evaluation Assurance Level Set of assurance requirements for a product, its manufacturing process and its security evaluation specified by Common Criteria. Protection Profile 50 Document specifying security requirements for a class of products that conforms in structure and content to rules specified by Common Criteria. Reference Authentication Data (RAD) data persistently stored by the TOE for authentication of the signatory. Security Target 55 Document specifying security requirements for a particular product that conforms in structure and content to rules specified by common criteria, which may be based on one or more Protection Profile. Signature Creation Data (SCD) unique data, such as codes or private cryptographic keys, which are used by the 60 signatory to create an electronic signature (the Directive: 2.4). Note 1 to entry: For the PPs of this standard the SCD is held in the SSCD. Signature Verification Data (SVD) data, such as codes or public cryptographic keys, which are used for the purpose of verifying an electronic signature (the Directive: 2.7). 65 Standard Inspection Procedure SIP A specific order of authentication steps between an travel document and a terminal as required by [ICAO-TR-101], namely (i) PACE or BAC and (ii) Passive Authentication with SOD. SIP can generally be used by BIS-PACE and BIS-BAC. 70 Target of Evaluation Abstract reference in a document, such as a Protection Profile, for a particular product that meets specific security requirements. TOE Security Functions Functions implemented by the TOE to meet the requirements specified for it in a 75 Protection Profile or Security Target. Verification Authentication Data (VAD) data input to an SSCD for authentication of the signatory. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 3 1.4 List of Tables 1.1 History of released Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 80 7.1 Terminal Authentication Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.2 Terminal Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.3 Security Attributes for SSCD related SFPs . . . . . . . . . . . . . . . . . . . . . . . 61 7.4 Keys and certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.5 Overview on authentication SFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 85 7.6 Subjects and security attributes for access control . . . . . . . . . . . . . . . . . 93 7.7 Secure values of the combinations of security attributes . . . . . . . . . . . . . 114 7.8 Security assurance requirements: EAL4 augmented with ALC_DVS.2, ATE-DPT.2 and AVA_VAN.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.9 Dependencies between the SFR for the TOE . . . . . . . . . . . . . . . . . . . . . 134 90 7.10 Satisfaction of dependencies of security assurance requirements . . . . . . . 137 8.1 Relevant Platform SFRs used as services . . . . . . . . . . . . . . . . . . . . . . . . 164 8.2 Relevant Platform SFRs used as mechanisms . . . . . . . . . . . . . . . . . . . . . 165 A.1 Used Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 1.5 List of Figures 95 5.1 Security Objective Rationale overview . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.1 Functional Requirement to TOE security objective mapping . . . . . . . . . . 121 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 4 2 ST Introduction (ASE_INT) 2 ST Introduction (ASE_INT) This section provides document management and overview information that are required by a potential user of the TOE to determine, whether the TOE fulfills her requirements. 100 For convenience, extensive parts that refer mainly to only one PP are marked as follows: • PP PACE [BSI-CC-PP-0068-V2-2011-MA-01] is marginalzed with PACE • PP PACE EAC [BSI-CC-PP-0056-V2-2012-MA-02] is marginalized with EAC • PP SSCD [BSI-CC-PP-0059-2009-MA-02] is marginalized with SSCD • PP SSCD KG TCCGA [BSI-CC-PP-0071-2012-MA-01] is marginalized with CGA 105 • PP SSCD KG TCSCA [BSI-CC-PP-0072-2012-MA-01] is marginalized with SCA In addition, margins SSCD, PACE or EAC, respectively, are applied, when large text passages concern the SSCD, PACE or EAC functionality. 2.1 ST Reference Title Security Target ‘CardOS V6.0 ID R1.2’ 110 TOE ‘CardOS V6.0 ID R1.2’ Sponsor Eviden Germany GmbH Editor(s) Eviden Germany GmbH CC Version 3.1 (Revision 5) Assurance Level EAL4 augmented with ALC_DVS.2, ATE_DPT.2, and AVA_VAN.5. 115 Status Release Version 2.50R Date 2026-05-04 Certification ID BSI-DSZ-CC-1162-V4 Keywords ICAO, PACE, EAC, Extended Access Control, ID-Card, Machine Readable 120 Travel Document, CardOS 2.2 TOE Reference This Security Target refers to the Product ‘CardOS V6.0 ID R1.2’ (TOE) of Eviden Germany GmbH for CC evaluation. 2.3 TOE Overview 125 The Target of Evaluation (TOE) ‘’CardOS V6.0 ID R1.2’’ addressed by this Security Target is a smart card with contact-based and contactless interfaces according to TR-03110. The smart card contains at least one application described in the following. In this ST the TOE as a whole is also called card, electronic document or travel document. Here, an application is a collection of data (data groups) and their access conditions. We 130 mainly distinguish between common user data, and sensitive user-data. Depending on the protection mechanisms involved, these user data can further be distinguished as follows: Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 5 2 ST Introduction (ASE_INT) • EAC1-protected data: Sensitive user data protected by EAC1 (cf. [BSI-TR-03110-1-V220]), • all other (common) user data. Other user data are protected by Password Authenti- cated Connection Establishment (PACE, cf. also [BSI-TR-03110-2-V221]). Note that EAC1 135 recommends prior execution of PACE. Due to existing migration periods both PACE and Basic Access Control (BAC) according to [ICAO-9303-2015] must be supported by MRTD products. However, a terminal or product configuration performing BAC instead of PACE is acting outside of the security policy defined by this ST. 140 In addition to the above user data, there is also data required for TOE security functionality (TSF). Such data is necessary to execute the access control protocols, to verify integrity and authenticity of user data, or to generate cryptographic signatures. Applications considered in [BSI-TR-03110-1-V220] and [BSI-TR-03110-2-V221] are • an electronic passport (ePass1 ) application, 145 • an electronic identity (eID) application, and • a signature (eSign) application. Eviden Germany GmbH implemented all these applications in the TOE. Only ePass and eSign application are subject of CC Evaluation. 2.3.1 Usage and major security features of the TOE 150 The following TOE security features are the most significant for its operational use. The TOE ensures that • only authenticated terminals can get access to the user data stored on the TOE and use security functionality of the card according to the access rights of the terminal, • the card holder can control access by consciously presenting his card and/or by entering 155 his secret PIN, • authenticity and integrity of user data can be verified, • confidentiality of user data in the communication channel between the TOE and the connected terminal is provided, • inconspicuous tracing of the card is averted, 160 • its security functionality and the data stored inside are self-protected, and • digital signatures can be created. For further details, refer to the chapter Security Requirements (ASE_REQ) and chapter TOE Summary Specification (ASE_TSS). 2.3.2 TOE Type 165 The TOE’s type addressed by this ST is a smart card with several applications. With the eSign Application the TOE implements a Secure Signature Creation Device according to Regulation (EU) No 910/2014 and the corresponding Implementing Decision [EU-Reg-910-2014]. The ePassport application provides an ICAO-compliant ([ICAO-9303-2015]) ePass Application. 1 The notation of this application is different in the references; both ePass and ePassport are used. In this ST they are used synonymously, too. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 6 2 ST Introduction (ASE_INT) 2.3.3 File System of the TOE 170 The TOE is configured with one of the dedicated file systems during Initialization. Depending on the intended use, the file system of a desired configuration may not contain all applications listed in this ST. Although not all data groups will be present, all mechanisms, such as e.g. access controls and cryptographic operations described in the SFRs of this ST are implemented in these products too. The corresponding security requirements are fulfilled, as soon as the 175 application is available. The available major Configurations of the file system related to this ST are described in detail in other documents [Eviden-V60-ADM]. They do not differ in security-relevant ways. For example, the product configured as ePassport provides the same security functionality of an electronic travel document as the product configured as eID. Though the latter can be 180 used as a Qualified Signature Creation Device, if the eSign application is present, this has no impact on the security functionality of a ePassport, not providing this functionality. The three Major Configurations of the TOE in this Security Target, which differ only in the description of the object system, are: • ePassport: User data are stored in an ICAO-compliant ([ICAO-9303-2015]) ePass Ap- 185 plication protected by PACE and EAC1. Here, EAC1 is used only for data groups 3 and 4. • SSCD: User data are stored in [BSI-CC-PP-0059-2009-MA-02] conformant eSign Applica- tion. • eID: User data are contained in an ICAO-compliant ([ICAO-9303-2015]) ePass Application, 190 in a [BSI-CC-PP-0059-2009-MA-02] conformant eSign Application, and optional eID applications. The described technical capabilities of the product as well as the conformance claims of this evaluation aim also at enabling the use of the product as a residence permit using the ePass application. 195 Observe that the security claims of the security target apply to the ePass and eSign application only. The additional eID applications can be configured in different ways. The Trust Center acting as the qualified trusted service provider preparing the eSign ap- plication can deliver the card in different configurations to the end user. However, in any case the processes in the guidance documentation have to be followed, which ensure that 200 the signature creation functionality of the eSign application is blocked until the legitimate signatory has set the reference authentication data (RAD). 2.3.4 Non-TOE hardware/software/firmware In order to be powered up and to communicate with the ‘external world’ the TOE needs a terminal (card reader) with contacts according to [ISO-IEC-7816-part-4] or supporting the 205 contactless communication according to [ISO-IEC-14443-2018]. According to [BSI-TR-03110-2-V221], section 2.1 the TOE is able to recognize the following terminal types: • PACE terminal: A PACE terminal is a basic inspection system. It performs the standard inspection procedure, i.e. PACE followed by Passive Authentication. Afterwards user 210 data are read by the terminal. A PACE terminal is allowed to read only common user data. • EAC1 terminal: An EAC1 terminal is an extended inspection system according to [BSI-TR- 03110-1-V220]. It performs the advanced inspection procedure ([BSI-TR-03110-1-V220]) using EAC1, i.e. PACE, then Chip Authentication 1 followed by Passive Authentication, 215 and finally Terminal Authentication 1. Afterwards user data are read by the terminal. An EAC1 terminal is allowed to read both EAC1 protected data, and common user data. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 7 2 ST Introduction (ASE_INT) In general, the authorization level of a terminal is determined by the effective terminal authorization. The authorization is calculated from the certificate chain presented by the terminal to the TOE. It is based on the Certificate Holder Authorization Template (CHAT). 220 A CHAT is calculated as an AND-operation from the certificate chain of the terminal and the card presenter’s restricting input at the terminal. The final CHAT reflects the effective authorization level and is then sent to the TOE [BSI-TR-03110-3-V221]. For the access rights, cf. also the SFR component FDP_ACF.1/TRM. All necessary certificates of the related public key infrastructure – Country Verifying Cer- 225 tification Authority (CVCA) Link Certificates, Document Verifiers Certificates and Terminal Certificates – must be available in the card verifiable format defined in [BSI-TR-03110-3-V221]. The term terminal within this ST usually refers to any kind of terminal, if not explicitly mentioned otherwise. Which of the above terminals are related to what application and which data group is accessible by these terminals was given already in chapter File System of 230 the TOE. A terminal shall always start a communication session using PACE. If successfully, it should then proceed with passive authentications. Others than above listed terminals are out of scope of this ST. In particular, terminals using Basic Access Control (BAC) may be functionally supported by the card, but the TOE is not in a certified mode as long as it is operated with 235 BAC (cf. Application note 5 of [BSI-CC-PP-0068-V2-2011-MA-01]). For communication to the terminal the TOE supports contact-based and contactless com- munication but requires non-TOE hardware technology (bound-outs, module plates, inlays, antenna technology, etc.) for the physical communication layer. There is no other explicit non-TOE hardware, software or firmware required by the TOE to 240 perform its claimed security features. 2.3.5 Conformance to eIDAS In [EU-Reg-910-2014] the European Parliament and the Council of the European Union has codified the conceptional requirements for qualified electronic signature devices used in the European Union. In the supporting Implementing Decision is stated that an electronic 245 signature device according to eIDAS must be certified using the Common Criteria, claiming conformance to one or more of the protection profiles for Secure Signature Creation Devices. As shown in this ST (see CC Conformance Claims) the TOE fulfills these standards and is therefore compliant to signature creation devices according to points (a) of Article 30(3) or 39(2) of the Regulation for qualified electronic signature or seal creation devices. 250 2.4 TOE Description According to the Technical Guideline TR-03110 (cf. [BSI-TR-03110-1-V220], section 2.4) the ePass application supports the Standard Inspection Procedure and the Advanced Inspection Procedure: Both inspection procedures execute preferably Password Authenticated Connection Estab- 255 lishment (PACE) with CAN and MRZ or alternatively Basic Access Control (BAC) as well as Passive Authentication and optionally Active Authentication. The Advanced Inspection Procedure additionally executes Extended Access Control (EAC) with Chip Authentication Version 1 and Terminal Authentication Version 1. Note, that while technically supported BAC is not part of this TOE. 260 The ePass Application can be accessed both through the contact-based and the contactless interface of the TOE according to [BSI-CC-PP-0056-V2-2012-MA-02]. For the eSign Application the interface is not specified in the SSCD PP ([BSI-CC-PP-0059-2009-MA-02]) and both the contact-based or the contactless interface can be used. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 8 2 ST Introduction (ASE_INT) For the ePass Application, the card holder can control the access to his user data by conscious 265 presenting his document to authorities2 (CAN or MRZ authentication as specified in [BSI-TR- 03110-1-V220], section 3.3). For the eSign application, the card holder can control the access to the digital signature functionality by conscious presenting his document to a Service Provider and using his secret Verification Authentication Data for this application: eSign-PIN3 . 270 Using a secret PIN represents a manifestation of declaration of intent bound to this secret PIN. In order to reflect this fact, the ePass and the eSign Applications shall organizationally get different values of the respective secret PINs (PIN and eSignPIN). It is especially important, since qualified electronic signatures will be generated by the eSign Application. For security reasons this policy will not be enforced by the TOE. 275 The cryptographic algorithms used by the TOE are configurable. Personalization must be conducted according to the organizational security policies P.Personalization [BSI-CC-PP- 0056-V2-2012-MA-02] and P.QSign [BSI-CC-PP-0059-2009-MA-02]. Algorithms and security parameters (e.g. the length of cryptographic keys) of configurations for the certified applica- tions are chosen in accordance to international recommendations [ECCG-ACM-V2.0]. 280 The TOE supports standardized domain parameters defined in the Brainpool standard [RFC- 5639-2010-03] and in the NIST standard [NIST-FIPS-186-4] with various key lengths including the corresponding hash functions. For RSA the TOE also supports various key lengths. For further details of the supported crypto protocol configurations and parameters refer to 285 section Elliptic curves used, RSA key support, Hash functions implemented, and Overview of Cryptographic Algorithms. PACE and hence the Advanced Inspection Procedure require the use of AES, whereas due to compatibility reasons the Advanced Inspection Procedure with BAC may be used with 3DES (cf. [BSI-TR-03110-3-V221], sections A.2.3.1 and A.2.4.1). Observe that this security target 290 only contains security claims for the inspection procedures involving PACE. The configura- tion depends on the Initialization of the TOE. A more detailed description is given in the Administrator Guidance [Eviden-V60-ADM]. The TOE comprises of • the circuitry of the chip including all IC Dedicated Software being active in the Opera- 295 tional Phase of the TOE (the integrated circuit, IC), • the IC Embedded Software (Card Operating System, COS) including configuration and initialization data related to the security functionality of the chip, • the selected Applications implemented in the file-system to be installed, and • the associated guidance documentation including description of the file system installa- 300 tion procedure. The components of the TOE are therefore the hardware (IC) with the operating system CardOS (OS) ready for initialization with a selected dedicated object system. The TOE Design Specification gives a detailed description of the parts of TOE. The dedicated object systems (file systems) are specified in detail in the Admin Guidance. 305 The file systems support all security functionality and mechanisms described within the ST. After initialization and during personalization, applications (data groups) required for the intended functionality and mechanisms and their access rights are created. Creation of the applications (i.e. the [ISO-IEC-7816-part-4] conforming file structure) including data groups and their access rights) is subject to a limited availability and limited capability policy defined 310 in the family FMT_LIM. In particular, the TOE initialization mechanisms ensure that creation or alteration of the file system is not possible after the manufacturing phase (this excludes 2 CAN or MRZ user authentication 3 CAN and eSign-PIN (VAD as specified in [BSI-CC-PP-0059-2009-MA-02], section 3.2.3.5), user authentication, see [BSI-TR-03110-2-V221], section 2.3. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 9 2 ST Introduction (ASE_INT) populating data groups with values, as is done in the personalization phase). This is necessary for the manufacturer to use a single IC for different configurations. The Guidance documentation ([Eviden-V60-ADM]) provides further requirements for the 315 manufacturer and security measures required for protection of the TOE until reception by the end-user. The hardware platform of the TOE is identified as SLC52GDA448* (CC certification identifier IFX_CCI_000005 Design Step H13), which means that this ST applies to all derivates of the IFC_CCI_000005. For the TOE the following derivates will be used which differ only in the 320 input capacities on the contactless interface: • SLC52GDA448A8, 27pF • SLC52GDA448A9, 78pF The chips can be delivered as wafer, or packaged in the modules M8.8, MCC8, MCS8 (27pF) or COM10.6, COM 10.8 (78pF) or other modules or packages. In case of a contactless module, 325 the module may be integrated in an antenna inlay, which is then used to build a optically and machine readable smart card or ePassport booklet. A dual interface module may be integrated in a smart card. Note that the different contact technologies are not considered part of the TOE. Since CardOS is implemented on an already certified IC (certification number BSI-DSZ-CC- 330 1110-V8-2025) the evaluation considers the composite evaluation aspects ([BSI-AIS36-V5]). This composite ST is based on the ST of the underlying platform ([Infineon-ST-SLC52-H13]), which claims conformance to Security IC Platform Protection Profile ([BSI-CC-PP-0084-2014]). The compatibility between this ST and the platform ST is considered in detail in section Compatibility between the Composite ST and the Platform-ST. 335 2.4.1 Life Cycle Phases Mapping The typical life cycle phases for the current TOE type are development, manufacturing, card issuing and operational use. The life cycle phase development includes development of the IC itself and IC embedded software. Manufacturing includes IC manufacturing and smart card manufacturing, and installation of a card operating system. Card issuing includes 340 completion of the operating system, installation of the smart card applications and their electronic personalization, i.e. tying the application data up to the card holder. Operational use of the TOE is explicitly in the focus of the Protection Profiles. Nevertheless, some TOE functionality is already available in the manufacturing and the card issuing life cycle phases. Therefore it is also considered by the Protection Profiles and this ST. 345 In compliance to the Protection Profiles, the TOE life cycle is described in terms of the following four life cycle phases, divided in steps. Life cycle phase A “Development” Step 1: The TOE is developed in phase 1. The IC developer develops • the integrated circuit, 350 • the IC dedicated software and • the guidance documentation associated with these TOE components. Step 2: The software developer uses the guidance documentation for the integrated circuit and the guidance documentation for relevant parts of the IC dedicated software, and develops the IC embedded software (operating system), the card application(s) and the guidance 355 documentation associated with these TOE components. The software developer ships the IC embedded software in accordance with the certified delivery and loading procedures to the IC manufacturer. Furthermore, the software developer ships load scripts which in particular contain the certified object system layout(s) for the various configurations as well as the relevant guidance documentation securely to the Initializer. 360 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 10 2 ST Introduction (ASE_INT) Life cycle phase B “IC Manufacturing” Step 3: In a first step, the TOE integrated circuit is produced. The IC manufacturer writes IC identification data onto the chip in order to track and control the IC as dedicated card material during IC manufacturing, and during delivery to the electronic document manufac- turer. Additionally, the IC manufacturer adds the IC embedded software in the non-volatile 365 programmable memory using the certified loading mechanisms of the IC. The IC is securely delivered from the IC manufacturer to the composite product manufacturer. The IC may be delivered as a wafer, module or a packaged component. Life cycle phase C “Composite Product Integration and Initialization” Step 4 (optional): The composite product manufacturer 370 • produces modules, or packaged components, combined with hardware for the contact- based or contactless interfaces (e.g. inlays) Step 5: The initializer • equips the card’s chip with pre-personalization data, and • creates the application(s). 375 The creation of the application(s) is conducted by the Initialization of the card using secured load scripts to create the object system(s) for the certified ePass and/or eSign application(s) on the card. The Initialization also optionally includes the creation of the SCD/SVD pair for the signatory in the eSign application (cf. Application note 1 of [BSI-CC-PP-0068-V2-2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]). 380 Observe that additional eID applications can be loaded in this step as well. The Initialization can also be organizationally and or physically separated from the other card manufacturing steps. After the Initialization the card is ready for import of user data (Personalization). The pre-personalized TOE together with the IC identifier is securely delivered from the 385 Initializer to the Personalization. The Initializer also provides the relevant parts of the guidance documentation. The Administrator Personalization Key is also delivered securely to the Personalization. Life cycle phase D “Personalization” Step 6: The Personalization of the card includes for the ePass application: 390 1) the survey of the card holder’s biographical data, 2) the enrollment of the card holder’s biometric reference data, such as a digitized portrait or other biometric reference data, 3) printing the visual readable data onto the physical part of the card, and 4) configuration of the TSF, if necessary. 395 and for the eSign application: 1) optional creation of the SCD/SVD pair for the signatory 2) export of the SVD to for creation and subsequent storage of the card holder certificate Parts of the configuration of the TSF is performed during Personalization and includes, but is not limited to, the creation of the digitized version of the textual, printed data, the digitized 400 version of e.g. a portrait, or a cryptographic signature of a cryptographic hash of the data that are stored on the chip. The personalized electronic document, if required together with appropriate guidance for TOE use, is handed over to the card holder for operational use. The TSF data (data created by and for the TOE, that affects the operation of the TOE; cf. [CC-Part1-V3.1] § 92) comprise (but are not limited to) the Personalization Agent Authen- 405 tication Key(s), the Terminal Authentication trust anchor, the effective date and the Chip Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 11 2 ST Introduction (ASE_INT) Authentication Private Key. (cf. Application note 2 of [BSI-CC-PP-0068-V2-2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]). This ST distinguishes between the Personalization Agent as entity known to the TOE and the Document Signer as entity in the TOE IT environment signing the Document security 410 object as described in [ICAO-9303-2015]. This approach allows but does not enforce the separation of these roles. (cf. Application note 3 of [BSI-CC-PP-0068-V2-2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]) From a hardware point of view, this cycle phase is already an operational use of the composite product and not a personalization of the hardware. The hardware’s “Personalization” (cf. 415 [Infineon-ST-SLC52-H13]) ends with the Installation of the TOE (installation of the object system). The Personalization with User Data, e.g. card holder identification data, may be separated from the personalization of the TOE as Qualified Signature Creation Device, e.g. the generation of a signature key. 420 The Personalization as a personalized SSCD includes the SVD certification for the intended user according to [EU-Reg-910-2014] and the delivery to the legitimate user. Life cycle phase E “Operational Use” Step 7: The chip of the TOE is used by the card and terminals that verify the chip’s data during the phase operational use. The user data can be read and modified according to the 425 security policy of the issuer. Note that RSA key generation is only allowed to be performed in a trustworthy environment. This ST considers at least the phases A and B (i.e. Step1 to Step3) as part of the evaluation and therefore to define the TOE delivery according to CC after this phase. (cf. Application note 4 of [BSI-CC-PP-0068-V2-2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]). 430 Correspondence to the Life-Cycle Description in the Protection Profile Following the [BSI-CC-PP-0084-2014] Protection Profile, section 1.2.3 the life cycle phases of a smart card can be divided into the following seven phases: Phase 1: IC Embedded Software Development Phase 2: IC Development 435 Phase 3: IC Manufacturing Phase 4: IC Packaging Phase 5: Composite Product Integration Phase 6: Personalization Phase 7: Operational Use 440 Phase A “Development”, step 1 and step 2 cover exactly phase 1 and phase 2 of [BSI-CC-PP- 0084-2014]. Phase B “IC Manufacturing” covers phase 3 of [BSI-CC-PP-0084-2014] completely and is conducted based on the certified production procedures of the IC. The TOE can be delivered in various form factors. Thus, IC packaging i.e. phase 4 of [BSI-CC- 445 PP-0084-2014] is conducted either in the IC Manufacturing already (phase B) or at a later stage during the composite product integration (phase C). Phase C also covers phase 5 of [BSI-CC-PP-0084-2014] completely. Phase D “Personalization” directly corresponds to phase 6 of [BSI-CC-PP-0084-2014]. Observe, that the TOE has reached its secure state already at the delivery point which is 450 between phase B to phase C. Up to this point, the secure handling is controlled by the guidelines and security mechanisms provided by the IC manufacturer. After this point, the secure handling during Initialization and Personalization is controlled by the guidelines Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 12 2 ST Introduction (ASE_INT) and security mechanisms provided by the TOE developer. In particular, observe that both the Initialization and the Personalization must be conducted in a trusted environment (c.f. 455 OE.Env_Admin). The security environment for the TOE and the ST of the underlying platform match, the IC life cycle phases up to 6 are covered by a controlled environment as required in [Infineon-ST- SLC52-H13], section 7.3.1.2. In IC life cycle phase 7 no restrictions apply. The last life cycle phase E corresponds to the first step of Phase 7 of [BSI-CC-PP-0084-2014]. 460 2.4.2 TOE Boundaries 2.4.2.1 TOE Physical Boundaries Smart card as used in this ST means an integrated circuit containing a microprocessor, (CPU), a coprocessor for special (cryptographic) operations, a random number generator, volatile and non-volatile memory, and associated software, packaged and embedded in a carrier. The 465 integrated circuit is a single chip incorporating CPU and memory, which include RAM, ROM, and non-volatile memory. The chip is embedded in a module, which provides the capability for standardized connection to systems separate from the chip through TOE’s interfaces in accordance with ISO standards. The physical constituent of the TOE is IC with the operating system loaded using the certified 470 loading processes of the IC manufacturer and a set of load scripts which allow for installing the object system in a dedicated configuration. The IC can be physically delivered on wafers, or as modules, or inlays but the physical boundary of the TOE is the IC itself excluding the connection technology. After the Installation of the object system, the TOE can be personalized for the end-usage 475 phase for the document holder as a card. 2.4.2.2 TOE Logical Boundaries All card accepting devices (Host Applications) will communicate through the I/O interface of the operating system by sending and receiving octet strings. The logical boundaries of the TOE are given by the complete set of commands of the CardOS operating system for access, 480 reading, writing, updating or erasing data. The input to the TOE is transmitted over the physical interface as an octet string that has the structure of Command Application Protocol Data Unit (CAPDU). The output octet string from the TOE has the structure of a Response Application Protocol Data Unit (RAPDU). The Application Protocol Data Units or CardOS commands that can be used in the operating 485 systems are described in more detail in the guidance [Eviden-V60-ADM], [Eviden-V60-USR]. 2.4.2.3 TOE Delivery Format In summary the delivery of the TOE consists of: • the integrated circuit (IC) with the operation system pre-loaded • the administrator and user guidance documentation [Eviden-V60-ADM], [Eviden-V60- 490 USR] • personalization information package, required for the secure personalization of the TOE. Further details about the secure personalization are provided in the guidance documentation. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 13 3 Conformance Claim 3 Conformance Claim 495 3.1 CC Conformance Claims This Security Target claims conformance to Common Criteria for Information Technology Security Evaluation [CC], Part 1: Introduction and general model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017, [CC-Part1-V3.1] 500 Part 2: Security functional components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017, [CC-Part2-V3.1] Part 3: Security assurance components; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017, [CC-Part3-V3.1] as follows: 505 Part 2 extended, Part 3 conformant. The Common Methodology for Information Technology Security Evaluation, Evaluation methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017, [CEM-V3.1] has to be taken into account. 3.2 CC:2022 Conformance of the Platform ST 510 The ST of the hardware platform [Infineon-ST-SLC52-H13] claims conformance to the CC:2022 Standard. In the platform ST the new definitions and dependency structure in the functional components FCS_COP and FCS_CKM are considered by replacing deprecated FCS_CKM.4 requirement for cryptographic key destruction with the new more precise FCS_CKM.6 variant of the requirement. But since the TOE ST refers to CC V3.1 R5 FCS_CKM.4 is used and 515 considered compatible to FCS_CKM.6 from the platform ST. 3.3 PP Claims This ST claims strict conformance to • Common Criteria Protection Profile ‘Machine Readable Travel Document with “ICAO Application”, Extended Access Control with PACE (EAC PP)’, [BSI-CC-PP-0056-V2-2012- 520 MA-02] Since this PP claims strict conformance to [BSI-CC-PP-0068-V2-2011-MA-01], this ST implicitly also claims strict conformance to • Common Criteria Protection Profile ‘Machine Readable Travel Document using Standard Inspection Procedure with PACE’, [BSI-CC-PP-0068-V2-2011-MA-01]. 525 However, since [BSI-CC-PP-0056-V2-2012-MA-02] already claims strict conformance to [BSI- CC-PP-0068-V2-2011-MA-01], and basically extends this PP by the use of PACE within the EAC protocol this implicit conformance claim is not always made explicit for the sake of presentation. Nonetheless, if necessary to yield a better overview, references to this Protection Profile are given or the relation with this PP is explained. 530 This ST claims also strict conformance to • Common Criteria Protection Profiles for Secure Signature Creation Device – Part 2: Device with key generation, EN 419211-2:2013, [BSI-CC-PP-0059-2009-MA-02] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 14 3 Conformance Claim • Common Criteria Protection Profiles for Secure Signature Creation Device – Part 4: Extension for device with key generation and trusted communication with certificate 535 generation application, EN 419211-4:2013, [BSI-CC-PP-0071-2012-MA-01] • Common Criteria Protection Profiles for Secure Signature Creation Device – Part 5: Extension for device with key generation and trusted communication with signature creation application, EN 419211-5:2013, [BSI-CC-PP-0072-2012-MA-01] Application Note 6: The conformance claim to the Secure Signature Creation Device protec- 540 tion profiles covers the part of the security policy for the eSign application of the TOE, and hence are applicable, if the eSign application is operational. 3.4 Package Claims The evaluation of the TOE is a composite evaluation and uses the results of the CC evaluation provided by [Infineon-ST-SLC52-H13]. The IC hardware platform and its primary embedded 545 software are evaluated according to CC:2022 - EAL5 and EAL6 augmented. The evaluation assurance level of the TOE is EAL4 as defined in [CC-Part3-V3.1] augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. 3.5 Conformance Claim Rationale The TOE type is a chip consistent with the TOE type of the claimed PPs [BSI-CC-PP-0056-V2- 550 2012-MA-02] and [BSI-CC-PP-0059-2009-MA-02], [BSI-CC-PP-0071-2012-MA-01], and [BSI-CC- PP-0072-2012-MA-01]. This implies for this ST: 1. The TOE type of this ST is the same as the TOE type of the claimed PPs: The Target of Evaluation (TOE) is an electronic document implemented as a smart card programmed according to TR-03110, and additionally representing for the eSign application a com- 555 bination of hardware and software configured to securely create, use and manage signature-creation data. 2. The implementation standards have developed further since the last publication of the PACE/EAC Protection Profiles. However, the standards contain primarily extensions that are not related to the PACE and EAC protocol steps. The only exception is the 560 introduction of the PACE-Chip Authentication Mapping but this is just a combination of the existing mechanisms for optimization purposes. Therefore, this ST assumes that the protection profile can still be used “mutatis mutandis” also with newer versions of the implementation standards. Some clarifications have been added to the various ele- ments of the security problem definitions, security objectives and the security functional 565 requirements but all of these do not change the original definitions. 3. The security problem definition (SPD) of this ST contains the SPD of the claimed PPs. The SPD contains all threats, organizational security policies and assumptions of the claimed PPs. Two assumptions have been added to the ST: • A.Env_Admin and A.Env_Mass_Signature capture assumptions on the specific use 570 of TOE functions in the Initialization and Personalization as well as using the TOE for mass signature generation. These assumptions do not contradict the original security problem definition. 4. The security objectives for the TOE in this ST include all the security objectives for the TOE of the claimed PPs. One additional security objective is added to the ST: 575 • OT.AA_Proof models the additional objective of the TOE to provide the Active Authentication feature. There are no corresponding additions to the SPD because Active Authentication is just another mean (in addition to the Chip Authentication Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 15 3 Conformance Claim modelled in the PP) to counter the threat T.Counterfeit. Therefore, this extension does not contradict the protection profiles this ST claims conformance to. 580 5. The security objectives for the operational environment in this ST include all security objectives for the operational environment of the claimed PPs. The following objectives for the environment have been added or refined in this ST: • OE.Env_Admin and OE.Env_Mass_Signature capture the additional assumptions A.Env_Admin and A.Env_Mass_Signature and therefore, don’t contradict the protec- 585 tion profiles. • OE.AA_Key_Travel_Document has been added and OE.Exam_Travel_Document has been refined to mandate that the Inspection system uses Active Authentication (c.f. OT.AA_Proof) when supported in the configuration and Chip Authentication is not used. This extension obviously does not contradict to the objectives definitions in 590 the PPs. 6. The SFRs specified in this ST include all security functional requirements (SFRs) specified in the claimed PPs. There are several refined or added SFRs within this ST: • The SFR FIA_UAU.1/SSCDPP is redefined from [BSI-CC-PP-0059-2009-MA-02] by additional assignments, this does not violate strict conformance to [BSI-CC-PP- 595 0059-2009-MA-02]. • Multiple iterations of FDP_ACF.1 and FMT_SMR.1 exist from imported PPs to define the access control SFPs and security roles for (common) user data and EAC1 pro- tected user data. These access control SFPs and security roles are unified to FDP_ ACF.1/TRM and FMT_SMR.1 600 • The SFRs FIA_API.1/AA, FMT_MTD.1/CA_AA_PK and FCS_COP.1/AA_SGEN_EC are added to model the additional Active Authentication feature for the ePass appli- cation. Since this feature does not interfere with the other security features this extension does not contradict to the definitions in the protection profiles • The SFR FIA_UAU.6/Signature_Creation was added to model the specific behavior 605 of the TOE when generating mass signatures. This extensions does not contradict the definitions in the protection profiles because the TOE offers this functionality under control of the signatory. • The SFRs FIA_AFL.1/Suspend_PIN and FIA_AFL.1/Block_PIN have been added to explicitly include the suspend and blocking mechanisms for PACE-PINs. Since 610 these SFRs have been directly taken over from the PP [BSI-CC-PP-0086-2015] which updates the PPs that this ST claims conformance to including newer protocol variants, the addition does not contradict the conformance claims. 7. The SARs specified in this ST are the same as specified in the claimed PPs or extend them. 615 The TOE type definitions of the claimed PPs ([BSI-CC-PP-0056-V2-2012-MA-02], [BSI-CC-PP- 0059-2009-MA-02]) differ slightly, however the TOE type definitions are not inconsistent. To avoid renaming in this ST all the notations of the different PPs are taken over here. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 16 4 Security Problem Definition 4 Security Problem Definition 4.1 Assets and External Entities 620 Primary Assets user data stored on the TOE All data (being not authentication data) stored in the context PACE EAC of the ePassport application of the travel document as defined in [ICAO-TR-110] and being allowed to be read out solely by an authenticated terminal acting as Basic Inspection System with PACE (in the sense of [ICAO-TR-110]). This asset covers ‘User Data on the 625 MRTD’s chip’, ‘Logical MRTD Data’ and ‘Sensitive User Data’ in [BSI-CC-PP-0055-110]. user data transferred between the TOE and the terminal connected All data (being not PACE EAC authentication data) being transferred in the context of the ePassport application of the travel document as defined in [ICAO-TR-110] between the TOE and an authenticated terminal acting as Basic Inspection System with PACE (in the sense of [ICAO-TR-110]). 630 User data can be received and sent (exchange <=> {receive, send}). travel document tracing data Technical information about the current and previous loca- PACE EAC tions of the travel document gathered unnoticeable by the travel document holder recognising the TOE not knowing any PACE password. TOE tracing data can be provided / gathered. 635 Logical travel document sensitive User Data Sensitive biometric reference data (EF.DG3, EAC EF.DG4) Due to interoperability reasons the ICAO standard [ICAO-TR-110] requires that Basic Inspection Systems may have access to logical travel document data DG1, DG2, DG5 to DG16. The TOE is not in certified mode, if it is accessed using BAC. Note that the BAC 640 mechanism cannot resist attacks with high attack potential. If supported, it is therefore recommended to used PACE instead of BAC. If nevertheless BAC has to be used, it is recommended to perform Chip Authentication v.1 before getting access to data (except DG14), as this mechanism is resistant to high potential attacks. Authenticity of the travel document’s chip The authenticity of the travel document’s chip EAC 645 personalised by the issuing State or Organisation for the travel document holder is used by the traveller to prove his possession of a genuine travel document. SCD private key used to perform an electronic signature operation. SSCD CGA SCA The confidentiality, integrity and signatory’s sole control over the use of the SCD shall be maintained. 650 SVD public key linked to the SCD and used to perform electronic signature verification. SSCD CGA SCA The integrity of the SVD when it is exported shall be maintained. DTBS, DTBS/R set of data, or its representation, which the signatory intends to sign. SSCD CGA SCA Their integrity and the unforgeability of the link to the signatory provided by the electronic signature shall be maintained. 655 In order to achieve a sufficient protection of the primary assets listed above, the following secondary assets are also protected by the TOE. The secondary assets represent TSF and TSF data in the sense of CC. Secondary Assets Accessibility to the TOE functions and data only for authorised subjects Property of the PACE 660 TOE to restrict access to TSF and TSF-data stored in the TOE to authorised subjects only. Genuineness of the TOE Property of the TOE to be authentic in order to provide claimed PACE security functionality in a proper way. This asset also covers ‘Authenticity of the MRTD’s chip’ in [BSI-CC-PP-0055-110]. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 17 4 Security Problem Definition TOE internal secret cryptographic keys Permanently or temporarily stored secret crypto- PACE 665 graphic material used by the TOE in order to enforce its security functionality. TOE internal non-secret cryptographic material Permanently or temporarily stored non- PACE 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. 670 travel document communication establishment authorisation data Restricted- PACE revealable1 authorisation information for a human user being used for verification of the authorisation attempts as authorised user (PACE password). These data are stored in the TOE and are not to be send to it. Since the travel document does not support any secret travel document holder authen- 675 tication data and the latter may reveal, if necessary, his or her verification values of the PACE password to an authorised person or device, a successful PACE authentication of a terminal does not unambiguously mean that the travel document holder is using TOE (cf. Application note 7 of [BSI-CC-PP-0068-V2-2011-MA-01]). travel document communication establishment authorisation data are represented by 680 two different entities: (i) reference information being persistently stored in the TOE and (ii) verification information being provided as input for the TOE by a human user as an authorisation attempt. The TOE shall secure the reference information as well as – together with the terminal connected2 – the verification information in the ‘TOE <-> terminal’ channel, if it has to be transferred to the TOE. Please note that PACE passwords 685 are not to be send to the TOE (cf. Application note 8 of [BSI-CC-PP-0068-V2-2011-MA-01]). Subjects and external entities travel document holder A person for whom the travel document Issuer has personalised PACE EAC the travel document3 . This entity is commensurate with ‘MRTD Holder’ in [BSI-CC-PP- 0055-110]. 690 Please note that a travel document holder can also be an attacker (s. below). travel document presenter traveller A person presenting the travel document to a terminal4 and claiming the identity PACE EAC of the travel document holder. This external entity is commensurate with ‘Traveller’ in [BSI-CC-PP-0055-110]. 695 Please note that a travel document presenter can also be an attacker (s. below). Terminal A terminal is any technical system communicating with the TOE through the PACE EAC contactless/contact interface. The role ‘Terminal’ is the default role for any terminal being recognised by the TOE as not being PACE authenticated (‘Terminal’ is used by the travel document presenter). This entity is commensurate with ‘Terminal’ in [BSI-CC-PP- 700 0055-110]. Basic Inspection System with PACE BIS-PACE A technical system being used by an inspecting authority5 and verifying the travel PACE EAC document presenter as the travel document holder (for ePassport: by comparing the real biometric data (face) of the travel document presenter with the stored biometric 705 data (DG2) of the travel document holder). BIS-PACE implements the terminal’s part of the PACE protocol and authenticates itself to the travel document using a shared password (PACE password) and supports Passive Authentication. Document Signer 1 The travel document holder may reveal, if necessary, his or her verification values of CAN and MRZ to an authorised person or device who definitely act according to respective regulations and are trustworthy. 2 the input device of the terminal 3 i.e. this person is uniquely associated with a concrete electronic Passport 4 in the sense of [ICAO-TR-110] 5 concretely, by a control officer Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 18 4 Security Problem Definition DS An organisation enforcing the policy of the CSCA and signing the Document Security PACE EAC 710 Object stored on the travel document for passive authentication. A Document Signer is authorised by the national CSCA issuing the Document Signer Certificate (CDS ), see [ICAO-9303-2015]. This role is usually delegated to a Personalisation Agent. Country Signing Certification Authority CSCA An organisation enforcing the policy of the travel document Issuer with respect to PACE EAC 715 confirming correctness of user and TSF data stored in the travel document. The CSCA represents the country specific root of the PKI for the travel document and creates the Document Signer Certificates within this PKI. The CSCA also issues the self-signed CSCA Certificate (CCSCA ) having to be distributed acc. to [ICAO-9303-2015], Part 12, 5 Personalisation Agent An organisation acting on behalf of the travel document Issuer to PACE EAC 720 personalise the travel document for the travel document holder by some or all of the following activities: (i) establishing the identity of the travel document holder for the biographic data in the travel document, (ii) enrolling the biometric reference data of the travel document holder, 725 (iii) writing a subset of these data on the physical travel document (optical personalisa- tion) and storing them in the travel document (electronic personalisation) for the travel document holder as defined in [ICAO-9303-2015], (iv) writing the document details data, (v) writing the initial TSF data, 730 (vi) signing the Document Security Object defined in [ICAO-9303-2015] (in the role of DS). Please note that the role ‘Personalisation Agent’ may be distributed among several institutions according to the operational policy of the travel document Issuer. This entity is commensurate with ‘Personalisation agent’ in [BSI-CC-PP-0055-110]. 735 Manufacturer Generic term for the IC Manufacturer producing integrated circuit and the PACE EAC travel document Manufacturer completing the IC to the travel document. The Manufac- turer is the default user of the TOE during the manufacturing life cycle phase. The TOE itself does not distinguish between the IC Manufacturer and travel document Manufac- turer using this role Manufacturer. This entity is commensurate with ‘Manufacturer’ in 740 [BSI-CC-PP-0055-110]. Attacker A threat agent (a person or a process acting on his behalf) trying to undermine the PACE security policy defined by the current PP, especially to change properties of the assets having to be maintained. The attacker is assumed to possess an at most high attack potential. Please note that the attacker might ‘capture’ any subject role recognised by 745 the TOE. This external entity is commensurate with ‘Attacker’ in [BSI-CC-PP-0055-110]. EAC A threat agent trying (i) to manipulate the logical travel document without authorization, (ii) to read sensitive biometric reference data (i.e. EF.DG3, EF.DG4), (iii) to forge a genuine travel document, or 750 (iv) to trace a travel document. SSCD CGA SCA Human or process acting on their behalf located outside the TOE. The main goal of the attacker is to access the SCD or to falsify the electronic signature. The attacker has got a high attack potential and knows no secret. Country Verifying Certification Authority 755 CVCA The Country Verifying Certification Authority (CVCA) enforces the privacy policy of EAC the issuing State or Organisation with respect to the protection of sensitive biometric Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 19 4 Security Problem Definition reference data stored in the travel document. The CVCA represents the country specific root of the PKI of Inspection Systems and creates the Document Verifier Certificates within this PKI. The updates of the public key of the CVCA are distributed in the form of 760 Country Verifying CA Link- Certificates. DV Document Verifier The Document Verifier (DV) enforces the privacy policy of the receiving EAC State with respect to the protection of sensitive biometric reference data to be handled by the Extended Inspection Systems. The Document Verifier manages the authorization 765 of the Extended Inspection Systems for the sensitive data of the travel document in the limits provided by the issuing States or Organisations in the form of the Document Verifier Certificates. Inspection system IS A technical system used by the border control officer of the receiving State EAC 770 (i) examining an travel document presented by the traveller and verifying its authen- ticity and (ii) verifying the traveller as travel document holder. Extended Inspection System EIS The Extended Inspection System (EIS) performs the Advanced Inspection Procedure EAC 775 and therefore (i) contains a terminal for the communication with the travel document’s chip, (ii) implements the terminals part of PACE and/or BAC; (iii) gets the authorization to read the logical travel document either under PACE or BAC by optical reading the travel document providing this information. 780 (iv) implements the Terminal Authentication and Chip Authentication Protocols both Version 1 according to [BSI-TR-03110-1-V220] and (v) is authorized by the issuing State or Organisation through the Document Verifier of the receiving State to read the sensitive biometric reference data. Security attributes of the EIS are defined by means of the Inspection System Certificates. 785 BAC may only be used if supported by the TOE. If both PACE and BAC are supported by the TOE and the BIS-PACE, PACE must be used. User End user of the TOE who can be identified as administrator or signatory. SSCD CGA SCA The subject S.User may act as S.Admin in the role R.Admin or as S.Sigy in the role R.Sigy. Administrator User who is in charge to perform the TOE initialisation, TOE personalisation SSCD CGA SCA 790 or other TOE administrative functions. The subject S.Admin is acting in the role R.Admin for this user after successful authenti- cation as administrator. Signatory User who hold the TOE and use it on their own behalf or on behalf of the natural SSCD CGA SCA or legal person or entity they represent. 795 The subject S.Sigy is acting in the role R.Sigy for this user after successful authentication as signatory. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 20 4 Security Problem Definition 4.2 Threats This section describes the threats to be averted by the TOE independently or in collaboration with its IT environment. These threats result from the assets protected by the TOE and the 800 method of TOE’s use in the operational environment. 4.2.1 T.Skimming (Skimming travel document / Capturing Card-Terminal Communication) PACE EAC Adverse action An attacker imitates an inspection system in order to get access to the user data stored on or transferred between the TOE and the inspecting 805 authority connected via the contactless/contact interface of the TOE. Threat agent having high attack potential, cannot read and does not know the correct value of the shared password (PACE password) in advance. Asset confidentiality of logical travel document data 810 Notes 1. This TOE does not support BAC. 2. A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this ST. (cf. application note 10 of [BSI-CC-PP-0068-V2-2011-MA-01]). 3. MRZ is printed and CAN is printed or stuck on the travel document. Please note that 815 neither CAN nor MRZ effectively represent secrets, but are restricted-revealable, cf. OE.Travel_Document_Holder (Travel document holder Obligations). (cf. application note 11 of [BSI-CC-PP-0068-V2-2011-MA-01]). 4.2.2 T.Eavesdropping (Eavesdropping on the communication between the TOE and the PACE terminal) 820 PACE EAC Adverse action An attacker is listening to the communication between the travel document and the PACE authenticated BIS-PACE in order to gain the user data transferred between the TOE and the terminal connected. Threat agent having high attack potential, cannot read and does not know the correct value of the shared password (PACE password) in advance. 825 Asset confidentiality of logical travel document data Notes 1. This TOE does not support BAC. 2. A product using BIS-BAC cannot avert this threat in the context of the security policy 830 defined in this ST. (cf. application note 10 of [BSI-CC-PP-0068-V2-2011-MA-01]). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 21 4 Security Problem Definition 4.2.3 T.Tracing (Tracing travel document) PACE EAC Adverse action An attacker tries to gather TOE tracing data (i.e. to trace the movement of the travel document) unambiguously identifying it remotely by establishing or listening to a communication via the contactless/contact 835 interface of the TOE. Threat agent having high attack potential, cannot read and does not know the correct value of the shared password (PACE password) in advance. Asset privacy of the travel document holder 840 Notes 1. This threat completely covers and extends “T.Chip-ID” from BAC PP [BSI-CC-PP-0055-110], (cf. application note 13 of [BSI-CC-PP-0068-V2-2011-MA-01]). 2. A product using BAC (whatever the type of the inspection system is: BIS-BAC) cannot avert this threat in the context of the security policy defined in this ST. (cf. application 845 note 14 of [BSI-CC-PP-0068-V2-2011-MA-01]). 4.2.4 T.Forgery (Forgery of Data) PACE EAC Adverse action An attacker fraudulently alters the User Data or/and TSF-data stored on the travel document or/and exchanged between the TOE and the terminal connected in order to outsmart 850 (i) the PACE authenticated BIS-PACE or EAC (ii) the authenticated Extended Inspection System6 by means of changed travel document holder’s related reference data (like biographic or biometric data). The attacker does it in such a way that the terminal connected perceives these modified data as authentic one. 855 Threat agent having high attack potential Asset integrity of the travel document 4.2.5 T.Abuse-Func (Abuse of Functionality) PACE EAC Adverse action An attacker may use functions of the TOE which shall not be used in TOE operational phase in order 860 (i) to manipulate or to disclose the User Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored in the TOE or (iii) to manipulate (bypass, deactivate or modify) soft-coded security function- ality of the TOE. This threat addresses the misuse of the functions for the initialisation and 865 personalisation in the operational phase after delivery to the travel document holder. Threat agent having high attack potential, being in possession of one or more legitimate travel documents Asset integrity and authenticity of the travel document, availability of the func- 870 tionality of the travel document 6 T.Forgery is extended by (ii) due to PP [BSI-CC-PP-0056-V2-2012-MA-02] Application note 8. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 22 4 Security Problem Definition Note 1. Details of the relevant attack scenarios depend, for instance, on the capabilities of the test features provided by the IC Dedicated Test Software being not specified here (cf. 875 application note 16 of [BSI-CC-PP-0068-V2-2011-MA-01]). 4.2.6 T.Information_Leakage (Information Leakage from travel document) PACE EAC Adverse action An attacker may exploit information leaking from the TOE during its usage in order to disclose confidential User Data or/and TSF-data stored on the travel document or/and exchanged between the TOE and the terminal 880 connected. The information leakage may be inherent in the normal operation or caused by the attacker. Threat agent having high attack potential Asset confidentiality of User Data and TSF-data of the travel document 4.2.7 T.Phys-Tamper (Physical Tampering) 885 PACE EAC Adverse action An attacker may perform physical probing of the travel document in order (i) to disclose the TSF-data, or (ii) to disclose/reconstruct the TOE’s Embedded Software. An attacker may physically modify the travel document in order to alter 890 (i) its security functionality (hardware and software part, as well), (ii) the User Data or the TSF-data stored on the travel document. Threat agent having high attack potential, being in possession of one or more legitimate travel documents Asset integrity and authenticity of the travel document, availability of the func- 895 tionality of the travel document, confidentiality of User Data and TSF-data of the travel document Note 1. Physical tampering may be focused directly on the disclosure or manipulation of the 900 user data (e.g. the biometric reference data for the inspection system) or the TSF data (e.g. authentication key of the travel document) or indirectly by preparation of the TOE to following attack methods by modification of security features (e.g. to enable information leakage through power analysis). Physical tampering requires a direct interaction with the travel document’s internals. Techniques commonly employed in IC 905 failure analysis and IC reverse engineering efforts may be used. Before that, hardware security mechanisms and layout characteristics need to be identified. Determination of software design including treatment of the user data and the TSF data may also be a pre-requisite. The modification may result in the deactivation of a security function. Changes of circuitry or data can be permanent or temporary. (cf. application note 18 of 910 [BSI-CC-PP-0068-V2-2011-MA-01]). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 23 4 Security Problem Definition 4.2.8 T.Malfunction (Malfunction due to Environmental Stress) PACE EAC Adverse action An attacker may cause a malfunction the travel document’s hard- ware and Embedded Software by applying environmental stress in order to (i) deactivate or modify security features or functionality of the TOE’ hardware 915 or to (ii) circumvent, deactivate or modify security functions of the TOE’s Embedded Software. This may be achieved e.g. by operating the travel document outside the normal operating conditions, exploiting errors in the travel document’s Embedded 920 Software or misusing administrative functions. To exploit these vulnerabilities an attacker needs information about the functional operation. Threat agent having high attack potential, being in possession of one or more le- gitimate travel documents, having information about the functional operation Asset integrity and authenticity of the travel document, availability of the func- 925 tionality of the travel document, confidentiality of User Data and TSF-data of the travel document Note 1. A malfunction of the TOE may also be caused using a direct interaction with elements 930 on the chip surface. This is considered as being a manipulation (refer to the threat T.Phys-Tamper) assuming a detailed knowledge about TOE’s internals. (cf. application note 19 of [BSI-CC-PP-0068-V2-2011-MA-01]). 4.2.9 T.Read_Sensitive_Data (Read the sensitive biometric reference data) EAC Adverse action An attacker tries to gain the sensitive biometric reference data 935 through the communication interface of the travel document’s chip. The attack T.Read_Sensitive_Data is similar to the threat T.Skimming (cf. [BSI-CC- PP-0055-110]) in respect of the attack path (communication interface) and the motivation (to get data stored on the travel document’s chip) but differs from those in the asset under the attack (sensitive biometric reference data vs. 940 digital MRZ, digitized portrait and other data), the opportunity (i.e. knowing the PACE Password) and therefore the possible attack methods. Note, that the sensitive biometric reference data are stored only on the travel document’s chip as private sensitive personal data whereas the MRZ data and the portrait are visually readable on the physical part of the travel document 945 as well. Threat agent having high attack potential, knowing the PACE Password, being in possession of a legitimate travel document Asset confidentiality of logical travel document sensitive user data (i.e. biometric reference) 950 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 24 4 Security Problem Definition 4.2.10 T.Counterfeit (Counterfeit of travel document chip data) EAC Adverse action An attacker with high attack potential produces an unauthorized copy or reproduction of a genuine travel document’s chip to be used as part of a counterfeit travel document. This violates the authenticity of the travel document’s chip used for authentication of a traveller by possession of a travel 955 document. The attacker may generate a new data set or extract completely or partially the data from a genuine travel document’s chip and copy them to another appropriate chip to imitate this genuine travel document’s chip. Threat agent having high attack potential, being in possession of one or more legitimate travel documents 960 Asset authenticity of user data stored on the TOE 4.2.11 T.SCD_Divulg (Storing, copying and releasing of the signature cre- ation data) SSCD CGA SCA Adverse action An attacker stores or copies the SCD outside the TOE. An attacker can obtain the SCD during generation, storage and use for signature creation 965 in the TOE. 4.2.12 T.SCD_Derive (Derive the signature creation data) SSCD CGA SCA Adverse action 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 970 of the SCD. 4.2.13 T.Hack_Phys (Physical attacks through the TOE interfaces) SSCD CGA SCA Adverse action An attacker interacts physically with the TOE to exploit vulnerabil- ities, resulting in arbitrary security compromises. This threat is directed against SCD, SVD and DTBS. 975 Note PACE 1. This threat is also directed against the PACE session keys (PACE-KMAC, PACE-KEnc), the ephemeral private key ephem-SKPICC-PACE, Chip Authentication private key, Adminis- trator Personalization Key and Chip Authentication session keys (CA-K MAC, CA-KEnc). 980 4.2.14 T.SVD_Forgery (Forgery of the signature verification data) SSCD CGA SCA Adverse action An attacker forges the SVD presented by the CSP to the CGA. This results in loss of SVD integrity in the certificate of the signatory. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 25 4 Security Problem Definition 4.2.15 T.SigF_Misuse (Misuse of the signature creation function of the TOE) SSCD CGA SCA Adverse action An attacker misuses the signature creation function of the TOE to 985 create SDO for data the signatory has not decided to sign. 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. 4.2.16 T.DTBS_Forgery (Forgery of the DTBS/R) SSCD CGA SCA Adverse action An attacker modifies the DTBS/R sent by the SCA. Thus the DTBS/R 990 used by the TOE for signing does not match the DTBS the signatory intended to sign. 4.2.17 T.Sig_Forgery (Forgery of the electronic signature) SSCD CGA SCA Adverse action 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 995 the signed data object is not detectable by the signatory or by third parties. The signature created by the TOE is subject to deliberate attacks by experts pos- sessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. 4.3 Organizational Security Policies 1000 The TOE and/or its environment shall comply with the following Organizational Security Policies (OSP) as security rules, procedures, practices, or guidelines imposed by an organization upon its operations (see [CC-Part1-V3.1], sec. A.6.3). This ST includes the OSPs from the claimed protection profiles as listed below and provides no further OSPs. 4.3.1 P.Manufact (Manufacturing of the travel document’s chip) 1005 PACE EAC The Initialization Data are written by the IC Manufacturer to identify the IC uniquely. The travel document Manufacturer writes the Pre-personalisation Data which contains at least the Personalisation Agent Key. Note 1010 1. OSP P.Manufact covers OSP “P.Process-TOE” of [Infineon-ST-SLC52-H13] which inherits OSP “P.Process-TOE” from PP [BSI-CC-PP-0084-2014]. 4.3.2 P.Pre-Operational (Pre-operational handling of the travel document) PACE EAC 1) The travel document Issuer issues the travel document and approves it using the termi- nals complying with all applicable laws and regulations. 1015 2) The travel document Issuer guarantees correctness of the user data (amongst other of those, concerning the travel document holder) and of the TSF-data permanently stored in the TOE7 . 7 cf. Table 1 and Table 2 in [BSI-CC-PP-0068-V2-2011-MA-01] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 26 4 Security Problem Definition 3) The travel document Issuer uses only such TOE’s technical components (IC) which enable traceability of the travel documents in their manufacturing and issuing life cycle phases, 1020 i.e. before they are in the operational phase, cf. sec. 1.2.3 in [BSI-CC-PP-0068-V2-2011- MA-01]. 4) If the travel document Issuer authorises a Personalisation Agent to personalise the travel document for travel document holders, the travel document Issuer has to ensure that the Personalisation Agent acts in accordance with the travel document Issuer’s policy. 1025 4.3.3 P.Card_PKI (PKI for Passive Authentication (issuing branch)) Note 1. The description below states the responsibilities of involved parties and represents the logical, but not the physical structure of the PKI. Physical distribution ways shall be 1030 implemented by the involved parties in such a way that all certificates belonging to the PKI are securely distributed / made available to their final destination, e.g. by using directory services. PACE EAC 1) The travel document Issuer shall establish a public key infrastructure for the passive authentication, i.e. for digital signature creation and verification for the travel docu- 1035 ment. For this aim, he runs a Country Signing Certification Authority (CSCA). The travel document Issuer shall publish the CSCA Certificate (CCSCA) . 2) The CSCA shall securely generate, store and use the CSCA key pair. The CSCA shall keep the CSCA Private Key secret and issue a self-signed CSCA Certificate (CCSCA) having to be made available to the travel document Issuer by strictly secure means, [ICAO-9303-2015]. 1040 The CSCA shall create the Document Signer Certificates for the Document Signer Public Keys (CDS) and make them available to the travel document Issuer, see [ICAO-9303-2015]. 3) A Document Signer shall (i) generate the Document Signer Key Pair, (ii) hand over the Document Signer Public Key to the CSCA for certification, 1045 (iii) keep the Document Signer Private Key secret and (iv) securely use the Document Signer Private Key for signing the Document Security Objects of travel documents. 4.3.4 P.Trustworthy_PKI (Trustworthiness of PKI) PACE EAC The CSCA shall ensure that it issues its certificates exclusively to the rightful organisations 1050 (DS) and DSs shall ensure that they sign exclusively correct Document Security Objects to be stored on the travel document. 4.3.5 P.Terminal (Abilities and trustworthiness of terminals) PACE EAC The Basic Inspection Systems with PACE (BIS-PACE) shall operate their terminals as follows: 1) The related terminals (basic inspection system, cf. above) shall be used by terminal 1055 operators and by travel document holders as defined in [ICAO-9303-2015]. 2) They shall implement the terminal parts of the PACE protocol [ICAO-TR-110], of the Passive Authentication [ICAO-9303-2015] and use them in this order8 . The PACE terminal shall use randomly and (almost) uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellmann). 1060 8 This order is commensurate with [ICAO-TR-110]. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 27 4 Security Problem Definition 3) The related terminals need not to use any own credentials. 4) They shall also store the Country Signing Public Key and the Document Signer Public Key (in form o fCCSCA and CDS) in order to enable and to perform Passive Authentication (determination of the authenticity of data groups stored in the travel document, [ICAO- 9303-2015]). 1065 5) The related terminals and their environment shall ensure confidentiality and integrity of respective data handled by them (e.g. confidentiality of PACE passwords, integrity of PKI certificates, etc.), where it is necessary for a secure operation of the TOE according to the current PP. 1070 Note 1. P.Terminal holds also for Extended Inspection System with PACE. 4.3.6 P.Sensitive_Data (Privacy of sensitive biometric reference data) EAC The biometric reference data of finger(s) (EF.DG3) and iris image(s) (EF.DG4) are sensitive private personal data of the travel document holder. The sensitive biometric reference data can be 1075 used only by inspection systems which are authorized for this access at the time the travel document is presented to the inspection system (Extended Inspection Systems). The issuing State or Organisation authorizes the Document Verifiers of the receiving States to manage the authorization of inspection systems within the limits defined by the Document Verifier Certificate. The travel document’s chip shall protect the confidentiality and integrity of the 1080 sensitive private personal data even during transmission to the Extended Inspection System after Chip Authentication Version 1 or PACE Chip Authentication Mapping, respectively9 . 4.3.7 P.Personalisation (Personalisation of the travel document by issuing State or Organisation only) EAC The issuing State or Organisation guarantees the correctness of the biographical data, the 1085 printed portrait and the digitized portrait, the biometric reference data and other data of the logical travel document with respect to the travel document holder. The personalisation of the travel document for the holder is performed by an agent authorized by the issuing State or Organisation only. 4.3.8 P.CSP_QCert (Qualified certificate) 1090 SSCD CGA SCA The CSP uses a trustworthy CGA to generate a qualified certificate or non-qualified certificate (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 1095 information. 9 since Chip Authentication functionally is part of PACE Chip Authentication Mapping Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 28 4 Security Problem Definition 4.3.9 P.QSign (Qualified electronic signatures) SSCD CGA SCA 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)10 . The DTBS are 1100 presented to the signatory and sent by the SCA as DTBS/R to the SSCD. The SSCD creates the electronic signature created with a 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. 4.3.10 P.Sigy_SSCD (TOE as secure signature creation device) 1105 SSCD CGA SCA 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 control of the signatory and the SCD can practically occur only once. 4.3.11 P.Sig_Non-Repud (Non-repudiation of signatures) SSCD CGA SCA The lifecycle of the SSCD, the SCD and the SVD shall be implemented in a way that the 1110 signatory is not able to deny having signed data if the signature is successfully verified with the SVD contained in their unrevoked certificate. 4.4 Assumptions The assumptions describe the security aspects of the environment in which the TOE will be used or is intended to be used. 1115 4.4.1 A.Passive_Auth (PKI for Passive Authentication) PACE EAC The issuing and receiving States or Organisations establish a public key infrastructure for passive authentication i.e. digital signature creation and verification for the logical travel document. The issuing State or Organisation runs a Certification Authority (CA) which securely generates, stores and uses the Country Signing CA Key pair. The CA keeps the Country Signing 1120 CA Private Key secret and is recommended to distribute the Country Signing CA Public Key to ICAO, all receiving States maintaining its integrity. The Document Signer (i) generates the Document Signer Key Pair, (ii) hands over the Document Signer Public Key to the CA for certification, (iii) keeps the Document Signer Private Key secret and 1125 (iv) uses securely the Document Signer Private Key for signing the Document Security Objects of the travel documents. The CA creates the Document Signer Certificates for the Document Signer Public Keys that are distributed to the receiving States and Organisations. It is assumed that the Personalisation Agent ensures that the Document Security Object contains only the hash values of genuine 1130 user data according to [ICAO-9303-2015]. 10 It is a non-qualified advanced electronic signature if it is based on a non-qualified certificate for the SVD. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 29 4 Security Problem Definition 4.4.2 A.Insp_Sys (Inspection Systems for global interoperability) EAC The Extended Inspection System (EIS) for global interoperability (i) includes the Country Signing CA Public Key and (ii) implements the terminal part of PACE [ICAO-TR-110] and/or BAC [BSI-CC-PP-0055-110]. 1135 BAC may only be used if supported by the TOE. If both PACE and BAC are supported by the TOE and the IS, PACE must be used. The EIS reads the logical travel document under PACE or BAC and performs the Chip Authentication v.1 to verify the logical travel document and establishes secure messaging. If PACE Chip Authentication Mapping is used, Chip Authentication v.1 may be skipped11 . EIS supports the Terminal Authentication Protocol 1140 v.1 in order to ensure access control and is authorized by the issuing State or Organisation through the Document Verifier of the receiving State to read the sensitive biometric reference data. Optionally the Inspection Systems implements Active Authentication.12 Justification: The assumption A.Insp_Sys does not confine the security objectives of the [BSI-CC-PP-0068-V2-2011-MA-01] as it repeats the requirements of P.Terminal and adds only 1145 assumptions for the Inspection Systems for handling the the EAC functionality of the TOE. 4.4.3 A.Auth_PKI (PKI for Inspection Systems) EAC The issuing and receiving States or Organisations establish a public key infrastructure for card verifiable certificates of the Extended Access Control. The Country Verifying Certification Authorities, the Document Verifier and Extended Inspection Systems hold authentication key 1150 pairs and certificates for their public keys encoding the access control rights. The Country Verifying Certification Authorities of the issuing States or Organisations are signing the certifi- cates of the Document Verifier and the Document Verifiers are signing the certificates of the Extended Inspection Systems of the receiving States or Organisations. The issuing States or Organisations distribute the public keys of their Country Verifying Certification Authority to 1155 their travel document’s chip. Justification: This assumption only concerns the EAC part of the TOE. The issuing and use of card verifiable certificates of the Extended Access Control is neither relevant for the PACE part of the TOE nor will the security objectives of the [BSI-CC-PP-0068-V2-2011-MA-01] be restricted by this assumption. For the EAC functionality of the TOE the assumption is necessary because 1160 it covers the pre-requisite for performing the Terminal Authentication Protocol Version 1. 4.4.4 A.CGA (Trustworthy certificate generation application) SSCD CGA SCA The CGA protects the authenticity of the signatory’s name or pseudonym and the SVD in the (qualified) certificate by an advanced electronic signature of the CSP. 4.4.5 A.SCA (Trustworthy signature creation application) 1165 SSCD CGA SCA 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. 11 since Chip Authentication functionally is part of PACE Chip Authentication Mapping 12 cf. [BSI-TR-03110-1-V220], section 2.4 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 30 4 Security Problem Definition 4.4.6 A.Env_Admin (Environment for administrator) TOE initialization, TOE personalization by the Administrator only takes place within a trusted environment. 1170 (Re-)Generation of RSA SCD/SVD pair only takes place within a trusted environment. Fur- ther eSign update functions (generation of EC SCD/SVD pair,export of SVD and optional creation/update of EFs / DFs) are performed by the Administrator through a trusted channel as a trusted environment. 1175 Notes 1. “A.Env_Admin” is added to the security problem definitions of the claimed protection profiles. 2. For initialization and personalization both TOE and Administrator reside in a trusted environment. 1180 3. For (re-)generation of RSA SCD/SVD pair both TOE and Administrator reside in a trusted environment. 4. For further eSign update functions the administrator resides in a trusted environment. After authentication and trusted channel establishment communication via trusted channel is considered to be a trusted environment. 1185 4.4.7 A.Env_Mass_Signature (Environment for a mass signature TOE) Mass signature generation only takes place within a trusted environment. Notes 1. “A.Env_Mass_Signature” is added to the security problem definitions of the claimed 1190 protection profiles. 2. Trusted Environment means for mass signature generation a physically trusted environ- ment. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 31 5 Security Objectives 5 Security Objectives This chapter describes the security objectives for the TOE and for the TOE environment. 1195 The security objectives for the TOE environment are separated into security objectives for the development, and production environment and security objectives for the operational environment. 5.1 Security Objectives for the TOE The following TOE security objectives address the protection provided by the TOE independent 1200 of the TOE environment. 5.1.1 OT.Data_Integrity (Integrity of Data) PACE EAC The TOE must ensure integrity of the User Data and the TSF-data1 stored on it by protecting these data against unauthorised modification (physical manipulation and unauthorised modi- fying). The TOE must ensure integrity of the User Data and the TSF-data during their exchange 1205 between the TOE and the terminal connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. Note 1. OT.Data_Integrity holds also for Extended Inspection System which has used an authen- 1210 ticated BIS-PACE for authentication. 5.1.2 OT.Data_Authenticity (Authenticity of Data) PACE EAC The TOE must ensure authenticity of the User Data and the TSF-data2 stored on it by enabling verification of their authenticity at the terminal-side3 . The TOE must ensure authenticity of the User Data and the TSF-data during their exchange between the TOE and the terminal 1215 connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. It shall happen by enabling such a verification at the terminal-side (at receiving by the terminal) and by an active verification by the TOE itself (at receiving by the TOE)4 . Note 1220 1. REFINEMENT OT.Data_Authenticity holds also for Extended Inspection System which has used an authenticated BIS-PACE for authentication. 1 where appropriate, see [BSI-CC-PP-0068-V2-2011-MA-01], Table 2 2 where appropriate, see [BSI-CC-PP-0068-V2-2011-MA-01], Table 2 3 verification of SOD 4 secure messaging after the PACE authentication, see also [ICAO-TR-110] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 32 5 Security Objectives 5.1.3 OT.Data_Confidentiality (Confidentiality of Data) PACE EAC The TOE must ensure confidentiality of the User Data and the TSF-data5 by granting read access only to the PACE authenticated BIS-PACE connected. The TOE must ensure confi- 1225 dentiality of the User Data and the TSF-data during their exchange between the TOE and the terminal connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. Note 1230 1. REFINEMENT OT.Data_Confidentiality holds also for Extended Inspection System which has used an authenticated BIS-PACE for authentication. 5.1.4 OT.Tracing (Tracing travel document) PACE EAC The TOE must prevent gathering TOE tracing data by means of unambiguous identifying the travel document remotely through establishing or listening to a communication via the 1235 contactless/contact interface of the TOE without knowledge of the correct values of shared passwords (PACE passwords) in advance. 5.1.5 OT.Prot_Abuse-Func (Protection against Abuse of Functionality) PACE EAC The TOE must prevent that functions of the TOE, which may not be used in TOE operational phase, can be abused in order 1240 (i) to manipulate or to disclose the User Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored in the TOE, (iii) to manipulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. 5.1.6 OT.Prot_Inf_Leak (Protection against Information Leakage) 1245 PACE EAC The TOE must provide protection against disclosure of confidential User Data or/and TSF-data stored and/or processed by the travel document • by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines, 1250 • by forcing a malfunction of the TOE and/or • by a physical manipulation of the TOE. Note 1. This objective pertains to measurements with subsequent complex signal processing 1255 due to normal operation of the TOE or operations enforced by an attacker (cf. application note 22 of [BSI-CC-PP-0068-V2-2011-MA-01]). 5 where appropriate, see [BSI-CC-PP-0068-V2-2011-MA-01], Table 2 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 33 5 Security Objectives 5.1.7 OT.Prot_Phys-Tamper (Protection against Physical Tampering) PACE EAC The TOE must provide protection of confidentiality and integrity of the User Data, the TSF-data and the travel document’s Embedded Software by means of 1260 • measuring through galvanic contacts representing a direct physical probing on the chip’s surface except on pads being bonded (using standard tools for measuring voltage and current) or • measuring not using galvanic contacts, but other types of physical interaction between electrical charges (using tools used in solid-state physics research and IC failure analysis), 1265 • manipulation of the hardware and its security functionality, as well as • controlled manipulation of memory contents (User Data, TSF-data) with a prior • reverse-engineering to understand the design and its properties and functionality. 5.1.8 OT.Prot_Malfunction (Protection against Malfunctions) 1270 PACE EAC The TOE must ensure its correct operation. The TOE must prevent its operation outside the normal operating conditions where reliability and secure operation have not been proven or tested. This is to prevent functional errors in the TOE. The environmental conditions may include external energy (esp. electromagnetic) fields, voltage (on any contacts), clock frequency or temperature. 1275 The following two TOE security objectives (OT.Identification and OT.AC_Pers) address the aspects of identified threats to be countered involving TOE’s environment. 5.1.9 OT.Identification (Identification of the TOE) PACE EAC The TOE must provide means to store Initialisation6 and Pre-Personalisation Data in its non- volatile memory. The Initialisation Data must provide a unique identification of the IC during 1280 the manufacturing and the card issuing life cycle phases of the travel document. The storage of the Pre-Personalisation data includes writing of the Personalisation Agent Key(s). Note 1. The OT.AC_Pers implies that the data of the LDS groups written during personalization 1285 for travel document holder (at least EF.DG1 and EF.DG2) cannot be changed using write access after personalization. (cf. application note 23 of [BSI-CC-PP-0068-V2-2011-MA-01]). 5.1.10 OT.AC_Pers (Access Control for Personalisation of logical MRTD) PACE EAC The TOE must ensure that the logical travel document data in EF.DG1 to EF.DG16, the Docu- ment Security Object according to LDS [ICAO-9303-2015] and the TSF data can be written by 1290 authorized Personalisation Agents only. The logical travel document data in EF.DG1 to EF.DG16 and the TSF data may be written only during and cannot be changed after personalisation of the document. 6 amongst other, IC Identification data Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 34 5 Security Objectives 5.1.11 OT.Sens_Data_Conf (Confidentiality of sensitive biometric reference data) 1295 EAC The TOE must ensure the confidentiality of the sensitive biometric reference data (EF.DG3 and EF.DG4) by granting read access only to authorized Extended Inspection Systems. The authorization of the inspection system is drawn from the Inspection System Certificate used for the successful authentication and shall be a non-strict subset of the authorization defined in the Document Verifier Certificate in the certificate chain to the Country Verifier Certification 1300 Authority of the issuing State or Organisation. The TOE must ensure the confidentiality of the logical travel document data during their transmission to the Extended Inspection System. The confidentiality of the sensitive biometric reference data shall be protected against attacks with high attack potential. 5.1.12 OT.Chip_Auth_Proof (Proof of the travel document’s chip authentic- 1305 ity) EAC The TOE must support the Inspection Systems to verify the identity and authenticity of the travel document’s chip as issued by the identified issuing State or Organisation by means of the Chip Authentication Version 1 as defined in [BSI-TR-03110-1-V220] and by means of PACE Chip Authentication Mapping as defined in [ICAO-TR-110], [BSI-TR-03110-1-V220]. The 1310 authenticity proof provided by travel document’s chip shall be protected against attacks with high attack potential. Note The OT.Chip_Auth_Proof implies the travel document’s chip to have 1315 (i) a unique identity as given by the travel document’s Document Number, (ii) a secret to prove its identity by knowledge i.e. a private authentication key as TSF data. The TOE shall protect this TSF data to prevent their misuse. The terminal shall have the reference data to verify the authentication attempt of travel document’s chip i.e. • in the case of Chip Authentication v.1: a certificate for the Chip Authentication Public 1320 Key that matches the Chip Authentication Private Key of the travel document’s chip. This certificate is provided by (i) the Chip Authentication Public Key (EF.DG14) in the LDS defined in [ICAO-9303-2015] and (ii) the hash value of DG14 in the Document Security Object signed by the Document 1325 Signer. • in the case of PACE Chip Authentication Mapping: a certificate for the Public Key that matches the PACE-CAM Private Key of the travel document’s chip. This certificate is provided by (i) the Public Key (EF.CardSecurity) in the LDS defined in [ICAO-TR-110] and 1330 (ii) the hash value of EF.CardSecurity in the Document Security Object signed by the Document Signer. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 35 5 Security Objectives 5.1.13 OT.AA_Proof (Proof of the travel document’s chip authenticity) The TOE must support the Inspection Systems to verify the identity and authenticity of the travel document’s chip as issued by the identified issuing State or Organization by means of 1335 the Active Authentication as defined in [ICAO-9303-2015]. The authenticity proof provided by travel document’s chip shall be protected against attacks with high attack potential.7 5.1.14 OT.Lifecycle_Security (Lifecycle security) SSCD CGA SCA The TOE shall detect flaws during the initialisation, personalisation and operational usage. The TOE shall securely destroy the SCD on demand of the signatory. 1340 Note 1. This TOE can contain several SCDs (RSA or EC based). 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 1345 been expired. 5.1.15 OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) SSCD CGA SCA The TOE shall provide security features to ensure that authorised users only may invoke the generation of the SCD and the SVD. 1350 Note 1. This objective is defined in [BSI-CC-PP-0059-2009-MA-02] as OT.SCD/SVD_Auth_Gen and referenced by [BSI-CC-PP-0071-2012-MA-01] and [BSI-CC-PP-0072-2012-MA-01] as OT.SCD/SVD_Auth_Gen. 5.1.16 OT.SCD_Unique (Uniqueness of the signature creation data) 1355 SSCD CGA SCA 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. 5.1.17 OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) 1360 SSCD CGA SCA 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. 7 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 36 5 Security Objectives 5.1.18 OT.SCD_Secrecy (Secrecy of the signature creation data) SSCD CGA SCA The secrecy of the SCD (used for signature creation) shall be reasonably assured against 1365 attacks with a high attack potential. Notes 1. 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. 1370 2. RSA key generation is only allowed to be performed in a trustworthy environment. For details refer to the guidance documentation. 5.1.19 OT.Sig_Secure (Cryptographic security of the electronic signature) SSCD CGA SCA 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 digital 1375 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. 5.1.20 OT.Sigy_SigF (Signature creation function for the legitimate signa- tory only) SSCD CGA SCA The TOE shall provide the digital signature creation function for the legitimate signatory only 1380 and protects the SCD against the use of others. The TOE shall resist attacks with high attack potential. 5.1.21 OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) SSCD CGA SCA 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 1385 TOE hashes the provided DTBS (in part or entirely) for signature creation. 5.1.22 OT.EMSEC_Design (Provide physical emanations security) SSCD CGA SCA The TOE shall be designed and built in such a way as to control the production of intelligible emanations within specified limits. 5.1.23 OT.Tamper_ID (Tamper detection) 1390 SSCD CGA SCA The TOE shall provide system features that detect physical tampering of its components, and uses those features to limit security breaches. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 37 5 Security Objectives 5.1.24 OT.Tamper_Resistance (Tamper resistance) SSCD CGA SCA The TOE shall prevent or resist physical tampering with specified system devices and compo- nents. 1395 5.1.25 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. Note 1400 1. This security objective only applies in case a communication channel to the CGA (via trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. 5.1.26 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 exported to the CGA. The TOE shall enable the CGA to detect alteration of the SVD exported 1405 by the TOE. Note 1. This security objective only applies for the Life Cycle Phase “Usage/Operational” as the TOE provides a communication channel to the CGA (via trusted channel) only in the Life 1410 Cycle Phase “Usage/Operational”. 5.1.27 OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) SCA The TOE shall provide a trusted channel for the protection of the confidentiality and integrity of the VAD received from the HID as needed by the authentication method employed. 1415 Note 1. This security objective for the TOE is partly covering OE.HID_VAD (Protection of the VAD) from [BSI-CC-PP-0059-2009-MA-02]. While OE.HID_VAD in [BSI-CC-PP-0059-2009-MA- 02] requires only the operational environment to protect VAD, [BSI-CC-PP-0072-2012- MA-01] requires the HID and the TOE to implement a trusted channel for the protection 1420 of the VAD: the HID exports the VAD and establishes one end of the trusted channel according to OE.HID_TC_VAD_Exp (Trusted channel of HID for VAD export), the TOE imports VAD at the other end of the trusted channel according to OT.TOE_TC_VAD_ Imp. Therefore [BSI-CC-PP-0072-2012-MA-01] re-assigns partly the VAD protection from the operational environment as described by OE.HID_VAD to the TOE as described by 1425 OT.TOE_TC_VAD_Imp and leaves only the necessary functionality by the HID. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 38 5 Security Objectives 5.1.28 OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) SCA The TOE shall provide a trusted channel to the SCA to detect alteration of the DTBS/R received from the SCA. The TOE shall not generate electronic signatures with the SCD for altered DTBS. 1430 Note 1. This security objective for the TOE is partly covering OE.DTBS_Protect from [BSI-CC-PP- 0059-2009-MA-02]. While OE.DTBS_Protect in [BSI-CC-PP-0059-2009-MA-02] requires only the operational environment to protect DTBS, [BSI-CC-PP-0072-2012-MA-01] re- quires the SCA and the TOE to implement a trusted channel for the protection of the 1435 DTBS: the SCA exports the DTBS and establishes one end of the trusted channel ac- cording to OE.SCA_TC_DTBS_Exp, [BSI-CC-PP-0072-2012-MA-01] TOE imports DTBS at the other end of the trusted channel according to OT.TOE_TC_DTBS_Imp. Therefore PP re-assigns partly the DTBS protection from the operational environment as described by OE.DTBS_Protect to the TOE as described by OT.TOE_TC_DTBS_Imp and leaves only the 1440 necessary functionality by the SCA. 5.2 Security Objectives for the Operational Environment Travel document Issuer as the general responsible The travel document Issuer as the general responsible for the global security policy related will implement the following security objectives for the TOE environment: 1445 5.2.1 OE.Legislative_Compliance (Issuing of the travel document) PACE EAC The travel document Issuer must issue the travel document and approve it using the terminals complying with all applicable laws and regulations. Travel document Issuer and CSCA: travel document’s PKI (is- suing) branch 1450 The travel document Issuer and the related CSCA will implement the following security objectives for the TOE environment: (see also the note in the definition of P.Card_PKI (PKI for Passive Authentication (issuing branch)) above) 5.2.2 OE.Passive_Auth_Sign (Authentication of travel document by Signa- ture) 1455 PACE EAC The travel document Issuer has to establish the necessary public key infrastructure as follows: the CSCA acting on behalf and according to the policy of the travel document Issuer must (i) generate a cryptographically secure CSCA Key Pair, (ii) ensure the secrecy of the CSCA Private Key and sign Document Signer Certificates in a secure operational environment, and 1460 (iii) publish the Certificate of the CSCA Public Key (CCSCA ). Hereby authenticity and integrity of these certificates are being maintained. A Document Signer acting in accordance with the CSCA policy must Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 39 5 Security Objectives (i) generate a cryptographically secure Document Signing Key Pair, (ii) ensure the secrecy of the Document Signer Private Key, 1465 (iii) hand over the Document Signer Public Key to the CSCA for certification, (iv) sign Document Security Objects of genuine travel documents in a secure operational environment only. The digital signature in the Document Security Object relates to all hash values for each data group in use according to [6]. The Personalisation Agent has to ensure that the Document 1470 Security Object contains only the hash values of genuine user data according to [6]. The CSCA must issue its certificates exclusively to the rightful organisations (DS) and DSs must sign exclusively correct Document Security Objects to be stored on travel document. 5.2.3 OE.Personalisation (Personalisation of travel document) PACE EAC The travel document Issuer must ensure that the Personalisation Agents acting on his behalf 1475 (i) establish the correct identity of the travel document holder and create the biographical data for the travel document, (ii) enrol the biometric reference data of the travel document holder, (iii) write a subset of these data on the physical Passport (optical personalisation) and store them in the travel document (electronic personalisation) for the travel document holder 1480 as defined in [ICAO-9303-2015]8 , (iv) write the document details data, (v) write the initial TSF data, (vi) sign the Document Security Object defined in [ICAO-9303-2015] (in the role of a DS). Terminal operator: Terminal’s receiving branch 1485 5.2.4 OE.Terminal (Terminal operating) PACE EAC The terminal operators must operate their terminals as follows: 1) The related terminals (basic inspection systems, cf. above) are used by terminal operators and by travel document holders as defined in [ICAO-9303-2015]. 2) The related terminals implement the terminal parts of the PACE protocol [ICAO-TR- 1490 110], of the Passive Authentication [ICAO-TR-110] (by verification of the signature of the Document Security Object) and use them in this order9 . The PACE terminal uses randomly and (almost) uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellmann). 3) The related terminals need not to use any own credentials. 1495 4) The related terminals securely store the Country Signing Public Key and the Document Signer Public Key (in form of CCSCA and CDS) in order to enable and to perform Passive Authentication of the travel document (determination of the authenticity of data groups stored in the travel document, [ICAO-9303-2015]). 5) The related terminals and their environment must ensure confidentiality and integrity 1500 of respective data handled by them (e.g. confidentiality of the PACE passwords, integrity of PKI certificates, etc.), where it is necessary for a secure operation of the TOE according to the current PP. 8 see also [ICAO-9303-2015], part 10 9 This order is commensurate with [ICAO-TR-110]. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 40 5 Security Objectives Note 1505 1. OE.Terminal completely covers and extends “OE.Exam_MRTD”, “OE.Passive_Auth_Verif” and “OE.Prot_Logical_MRTD” from BAC PP [BSI-CC-PP-0055-110]. (cf. application note 24 of [BSI-CC-PP-0068-V2-2011-MA-01]). Travel document holder Obligations 5.2.5 OE.Travel_Document_Holder (Travel document holder Obligations) 1510 PACE EAC The travel document holder may reveal, if necessary, his or her verification values of the PACE password to an authorized person or device who definitely act according to respective regulations and are trustworthy. Issuing State or Organisation The issuing State or Organisation will implement the following security objectives of the TOE 1515 environment. 5.2.6 OE.Auth_Key_Travel_Document (Travel document Authentication Key) EAC The issuing State or Organisation has to establish the necessary public key infrastructure in order to 1520 (i) generate the travel document’s Chip Authentication Key Pair, (ii) sign and store the Chip Authentication Public Key in the Chip Authentication Public Key data in EF.DG14 and (iii) support inspection systems of receiving States or Organisations to verify the authenticity of the travel document’s chip used for genuine travel document by certification of the 1525 Chip Authentication Public Key by means of the Document Security Object. 5.2.7 OE.AA_Key_Travel_Document (Travel document Authentication Key) The issuing State or Organization has to establish the necessary public key infrastructure in order to 1530 (i) generate the travel document’s Active Authentication Key Pair, (ii) sign and store the Active Authentication Public Key data in EF.DG15 and (iii) support inspection systems of receiving States or Organizations to verify the authenticity of the travel document’s chip used for genuine travel document by certification of the Active Authentication Public Key by means of the Document Security Object.10 1535 10 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 41 5 Security Objectives 5.2.8 OE.Authoriz_Sens_Data (Authorization for Use of Sensitive Biomet- ric Reference Data) EAC The issuing State or Organisation has to establish the necessary public key infrastructure in order to limit the access to sensitive biometric reference data of travel document holders to authorized receiving States or Organisations. The Country Verifying Certification Authority of 1540 the issuing State or Organisation generates card verifiable Document Verifier Certificates for the authorized Document Verifier only. Receiving State or Organisation The receiving State or Organisation will implement the following security objectives of the TOE environment. 1545 5.2.9 OE.Exam_Travel_Document (Examination of the physical part of the travel document) EAC The inspection system of the receiving State or Organisation must examine the travel docu- ment presented by the traveller to verify its authenticity by means of the physical security measures and to detect any manipulation of the physical part of the travel document. The 1550 Basic Inspection System for global interoperability (i) includes the Country Signing CA Public Key and the Document Signer Public Key of each issuing State or Organisation, and (ii) implements the terminal part of PACE [ICAO-TR-110] and/or the Basic Access Control [ICAO-9303-2015]. 1555 Extended Inspection Systems perform additionally to these points the PACE Chip Authenti- cation Mapping or/and Chip Authentication Protocol Version 1 to verify the Authenticity of the presented travel document’s chip. OE.Exam_Travel_Document also repeats partly the requirements from OE.Terminal in [BSI- CC-PP-0068-V2-2011-MA-01] and therefore also counters T.Forgery and A.Passive_Auth from 1560 [BSI-CC-PP-0068-V2-2011-MA-01] . This is done because a new type of Inspection System is introduced in this PP as the Extended Inspection System is needed to handle the additional features of a travel document with Extended Access Control. Inspection Systems not able to perform EAC perform additionally to these points Active Authentication (if optionally available and the terminal’s ability allows to perform AA) 1565 to verify the Authenticity of the presented travel document’s chip.11 5.2.10 OE.Prot_Logical_Travel_Document (Protection of data from the log- ical travel document) EAC The inspection system of the receiving State or Organisation ensures the confidentiality and integrity of the data read from the logical travel document. The inspection system will prevent 1570 eavesdropping to their communication with the TOE before secure messaging is successfully established based on the Chip Authentication Protocol Version 1. 11 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 42 5 Security Objectives 5.2.11 OE.Ext_Insp_Systems (Authorization of Extended Inspection Sys- tems) EAC The Document Verifier of receiving States or Organisations authorizes Extended Inspection 1575 Systems by creation of Inspection System Certificates for access to sensitive biometric refer- ence data of the logical travel document. The Extended Inspection System authenticates themselves to the travel document’s chip for access to the sensitive biometric reference data with its private Terminal Authentication Key and its Inspection System Certificate. Environmental security objectives for SSCD 1580 5.2.12 OE.SVD_Auth (Authenticity of the SVD) SSCD CGA SCA 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. 5.2.13 OE.CGA_QCert (Generation of qualified certificates) 1585 SSCD CGA SCA 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 signatory; c) the advanced signature of the CSP. 1590 The CGA shall confirm with the generated qualified certificate that the SCD corresponding to the SVD is stored in a SSCD. 5.2.14 OE.SSCD_Prov_Service (Authentic SSCD provided by SSCD- provisioning service) SSCD SCA The SSCD-provisioning service shall initialise and personalise for the signatory an authentic 1595 copy of the TOE and deliver this copy as SSCD to the signatory. 5.2.15 OE.HID_VAD (Protection of the VAD) SSCD CGA 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 employed from import through its human interface until import through the TOE interface. 1600 In particular, if the TOE requires a trusted channel for import of the VAD, the HID shall support usage of this trusted channel. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 43 5 Security Objectives 5.2.16 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 1605 export to the TOE by means of a trusted channel. Note 1. This security objective for the TOE is partly covering OE.HID_VAD (Protection of the VAD) from the core [BSI-CC-PP-0059-2009-MA-02]. While OE.HID_VAD in [BSI-CC-PP-0059- 1610 2009-MA-02] requires only the operational environment to protect VAD, [BSI-CC-PP- 0072-2012-MA-01] 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 (Trusted channel of TOE for VAD 1615 import). Therefore [BSI-CC-PP-0072-2012-MA-01] 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. 5.2.17 OE.DTBS_Intend (SCA sends data intended to be signed) SSCD CGA SCA The signatory shall use a trustworthy SCA that: 1620 • generates the DTBS/R of the data that has been presented as DTBS and which the signatory 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. 1625 Note 1. 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 advanced electronic signatures: CadES, XadES and PadES. These three formats mandate 1630 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. 5.2.18 OE.DTBS_Protect (SCA protects the data intended to be signed) 1635 SSCD CGA The operational environment shall ensure that the DTBS/R cannot be altered in transit between 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. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 44 5 Security Objectives 5.2.19 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 1640 to ensure that the DTBS/R cannot be altered undetected in transit between the SCA and the TOE. Note 1. This security objective for the TOE is partly covering OE.DTBS_Protect (SCA protects 1645 the data intended to be signed) from the core [BSI-CC-PP-0059-2009-MA-02]. While OE.DTBS_Protect in [BSI-CC-PP-0059-2009-MA-02] requires only the operational envi- ronment to protect DTBS, [BSI-CC-PP-0072-2012-MA-01] requires the SCA and the TOE to implement a trusted channel for the protection of the DTBS: the SCA exports the DTBS and establishes one end of the trusted channel according to OE.SCA_TC_DTBS_ 1650 Exp, the TOE imports DTBS at the other end of the trusted channel according to OT.TOE_ TC_DTBS_Imp (Trusted channel of TOE for DTBS import). Therefore [BSI-CC-PP-0072- 2012-MA-01] re-assigns partly the DTBS protection from the operational environment 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. 1655 5.2.20 OE.Signatory (Security obligation of the signatory) SSCD CGA SCA 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. Note 1660 1. The signatory may reveal, if necessary, his or her verification values of the PACE password to an authorized person or device (PACE Terminal) who are trustworthy. 5.2.21 OE.Dev_Prov_Service (Authentic SSCD provided by SSCD Provision- ing Service) CGA The SSCD Provisioning Service handles authentic devices that implement the TOE, prepares 1665 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. Notes 1670 1. This objective replaces OE.SSCD_Prov_Service (Authentic SSCD provided by SSCD- provisioning service) from the core PP, which is possible as it does not imply any addi- tional requirements for the operational environment when compared to OE.SSCD_Prov_ Service (OE.Dev_Prov_Service is a subset of OE.SSCD_Prov_Service). 2. The preparation of the TOE for proof as SSCD to external entities only applies in case 1675 a communication channel to the CGA (via trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 45 5 Security Objectives 5.2.22 OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authen- tication) CGA The CSP shall check by means of the CGA whether the device presented for application of a 1680 (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. Note 1685 1. This security objective only applies in case a communication channel to the CGA (via trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. 5.2.23 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. 1690 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 initialization 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 a SSCD. This situation is addressed by OE.SSCD_ 1695 Prov_Service (Authentic SSCD provided by SSCD-provisioning 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 without a SCD the TOE will be a SSCD only after generation of the first SCD/SVD pair. Because this SCD/SVD pair generation is performed by the signatory in the Phase “Usage/Operational” the TOE provides additional security functionality addressed by 1700 OT.TOE_SSCD_Auth (Authentication proof as SSCD) and OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export). But this security functionality shall be initialized by the SSCD Provisioning Service as described in OE.Dev_Prov_Service. Therefore [BSI-CC-PP-0071-2012- MA-01] substitutes 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 1705 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 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 [BSI-CC-PP-0059-2009-MA-02] 1710 . Note 1. This security objective only applies for the Life Cycle Phase “Usage/Operational” as the TOE provides a communication channel to the CGA (via trusted channel) only in the Life 1715 Cycle Phase “Usage/Operational”. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 46 5 Security Objectives 5.2.24 OE.Env_Admin (Administrator works in trusted environment) The administrative functions of “Administrator” users are performed within a trusted environ- ment. 1720 Notes 1. “OE.Env_Admin” is added to the contents of the claimed protection profiles. 2. After authentication and trusted channel establishment communication via trusted channel is considered to be a trusted environment. 3. RSA SCD/SVD pair generation is only allowed to be performed if the TOE is located in a 1725 trustworthy environment. For details refer to the guidance documentation. 5.2.25 OE.Env_Mass_Signature (Mass signatures are generated intrusted environment only) Mass signature generation only takes place within a trusted environment. 1730 Note 1. “OE.Env_Mass_Signature” is added to the contents of the claimed protection profiles. 5.3 Security Objective Rationale 5.3.1 Security Objectives Backtracking Fig. 5.1 shows that 1735 • all threats and OSPs are addressed by the security objectives and • that all assumptions are addressed by the security objectives for the TOE environment. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 47 5 Security Objectives Fig. 5.1: Security Objective Rationale overview 5.3.2 Security Objectives Sufficiency Countering of threats by security objectives SSCD T.SCD_Divulg (Storing, copying and releasing of the signature creation data) addresses the 1740 threat against the legal validity of electronic signature due to storage and copying of SCD outside the TOE, as expressed in the Directive, recital (18). This threat is countered by • OT.SCD_Secrecy (Secrecy of the signature creation data), which assures the secrecy of the SCD used for signature creation. SSCD T.SCD_Derive (Derive the signature creation data) deals with attacks on the SCD via public 1745 known data produced by the TOE, which are the SVD and the signatures created with the SCD. • OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) counters this threat by imple- menting cryptographically secure generation of the SCD/SVD pair. • OT.Sig_Secure (Cryptographic security of the electronic signature) ensures cryptograph- 1750 ically secure electronic signatures. SSCD T.Hack_Phys (Physical attacks through the TOE interfaces) deals with physical attacks exploiting physical vulnerabilities of the TOE. • OT.SCD_Secrecy (Secrecy of the signature creation data) preserves the secrecy of the SCD. 1755 • OT.EMSEC_Design (Provide physical emanations security) counters physical attacks through the TOE interfaces and observation of TOE emanations. • OT.Tamper_ID (Tamper detection) and Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 48 5 Security Objectives • OT.Tamper_Resistance (Tamper resistance) counter the threat T.Hack_Phys by detecting and by resisting tampering attacks. 1760 CGA T.SVD_Forgery (Forgery of the signature verification data) deals with the forgery of the SVD exported by the TOE to the CGA for the generation of the certificate12 . T.SVD_Forgery is addressed by • OT.SCD_SVD_Corresp (Correspondence between SVD and SCD), which ensures corre- spondence between SVD and SCD and unambiguous reference of the SVD/SCD pair for 1765 the SVD export and signature creation with the SCD, and • OE.SVD_Auth (Authenticity of the SVD) that ensures the integrity of the SVD exported by the TOE to the CGA and verification of the correspondence between the SCD in the SSCD of the signatory and the SVD in the input it provides to the certificate generation function of the CSP. 1770 Additionally T.SVD_Forgery is addressed by • OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export), 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 (CGA trusted channel for SVD import), which provides verification of SVD authenticity by the CGA. 1775 SSCD 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 an electronic signature on data for which the signatory has not expressed the intent to sign, as required by Annex III of the Directive, paragraph 1, literal (c). • OT.Lifecycle_Security (Lifecycle security) requires the TOE to detect flaws during the 1780 initialization, personalization and operational usage including secure destruction of the SCD, which may be initiated by the signatory. • OT.Sigy_SigF (Signature creation function for the legitimate signatory only) ensures that the TOE provides the signature creation function for the legitimate signatory only. • OE.DTBS_Intend (SCA sends data intended to be signed) ensures that the SCA sends 1785 the DTBS/R only for data the signatory intends to sign. • OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) prevents the DTBS/R from alteration inside the TOE. • OE.Signatory (Security obligation of the signatory) ensures that the signatory checks that an SCD stored in the SSCD when received from an SSCD-provisioning service provider 1790 is in non-operational state, i.e. the SCD cannot be used before the signatory becomes control over the SSCD. OE.Signatory ensures also that the signatory keeps their VAD confidential. SCA The combination of – OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) and 1795 – OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS export) counters the undetected manipulation of the DTBS during the transmission from the SCA to the TOE If the SCA provides a human interface for user authentication, OE.HID_TC_VAD_Exp (Trusted channel of HID for VAD export) requires the HID to protect the confidentiality 1800 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 (Trusted channel of HID for VAD export) and – OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import). 1805 12 The TOE provides a communication channel to the CGA (via trusted channel) only in the Life Cycle Phase “Usage/Operational”. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 49 5 Security Objectives – OE.DTBS_Protect (SCA protects the data intended to be signed) counters manip- ulation of the DTBS during transmission over the channel between SCA and the TOE. – OE.HID_VAD (Protection of the VAD) provides confidentiality and integrity of the VAD as needed by the authentication method employed. 1810 SSCD T.DTBS_Forgery (Forgery of the DTBS/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 signature has expressed its intent to sign. The TOE IT environment addresses T.DTBS_Forgery by the means of 1815 • OE.DTBS_Intend (SCA sends data intended to be signed), which ensures that the trustworthy SCA generates the DTBS/R of the data that has been presented as DTBS and which the signatory intends to sign in a form appropriate for signing by the TOE. The TOE counters this threat by the means of • OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) by ensuring the integrity of 1820 the DTBS/R inside the TOE. SCA The threat T.DTBS_Forgery (Forgery of the DTBS/R) is addressed by the security objectives – OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) and – OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS export), which ensure that the DTBS/R is sent through a trusted channel and cannot be altered undetected in 1825 transit between the SCA and the TOE. The TOE IT environment addresses T.DTBS_Forgery by the means of – OE.DTBS_Protect (SCA protects the data intended to be signed), which ensures that the DTBS/R cannot be altered in transit between the SCA and the TOE. SSCD T.Sig_Forgery (Forgery of the electronic signature) deals with non-detectable forgery of the 1830 electronic signature. • OT.Sig_Secure (Cryptographic security of the electronic signature), • OT.SCD_Unique (Uniqueness of the signature creation data) and • OE.CGA_QCert (Generation of qualified certificates) address this threat in general. • OT.Sig_Secure (Cryptographic security of the electronic signature) ensures by means of 1835 robust cryptographic techniques that the signed data and the electronic signature are securely linked together. • OT.SCD_Unique (Uniqueness of the signature creation data) and ensures that the same SCD cannot be generated more than once and the corresponding SVD cannot be included in another certificate by chance. 1840 • OE.CGA_QCert (Generation of qualified certificates) prevents forgery of the certificate for the corresponding SVD, which would result in false verification decision concerning a forged signature. PACE T.Skimming (Skimming travel document / Capturing Card-Terminal Communication) ad- dresses accessing the VAD (stored on the TOE or transferred between the TOE and the 1845 terminal) using the TOE’s contactless/contact interface. This threat is countered by the security objective • OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) through the PACE authentication. The objective 1850 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 50 5 Security Objectives • OE.Signatory (Security obligation of the signatory) ensures that a PACE session can only be established either by the legitimate user itself or by an authorised person or device (PACE Terminal), and, hence, cannot be captured by an attacker. PACE T.Skimming (Skimming travel document / Capturing Card-Terminal Communication), T.Eavesdropping (Eavesdropping on the communication between the TOE and the PACE 1855 terminal), T.Tracing (Tracing travel document), are countered exactly by the same objectives according to the rationale in the protection profile [BSI-CC-PP-0068-V2-2011-MA-01]. EAC The threat T.Forgery (Forgery of Data) addresses the fraudulent, complete or partial alteration of the User Data or/and TSF-data stored on the TOE or/and exchanged between the TOE and the terminal. Additionally to the security objectives from PACE PP [BSI-CC-PP-0068- 1860 V2-2011-MA-01] which counter this threat, the examination of the presented MRTD passport book according to OE.Exam_Travel_Document (Examination of the physical part of the travel document) shall ensure its authenticity by means of the physical security measures and detect any manipulation of the physical part of the travel document. PACE T.Abuse-Func (Abuse of Functionality), T.Information_Leakage (Information Leakage from 1865 travel document), T.Phys-Tamper (Physical Tampering), and T.Malfunction (Malfunction due to Environmental Stress) are countered directly by one security objective namely OT.Prot_ Abuse-Func, OT.Prot_Inf_Leaka, OT.Prot_Phys-Tamper, and OT.Malfunction respectively all in direct correspondence to [BSI-CC-PP-0068-V2-2011-MA-01]. EAC T.Read_Sensitive_Data (Read the sensitive biometric reference data) is countered by 1870 OT.Sens_Data_Conf, OE.Ext_Insp_Systems, and OE.Authorized_Sens_Data in direct corre- spondence to [BSI-CC-PP-0068-V2-2011-MA-01]. The threat T.Counterfeit (Counterfeit of travel document chip data) addresses the attack of unauthorized copy or reproduction of the genuine travel document’s chip. This attack is thwarted by chip an identification and authenticity proof required by OT.Chip_Auth_Proof 1875 (Proof of the travel document’s chip authenticity) using an authentication key pair to be generated by the issuing State or Organization. The Public Chip Authentication Key has to be written into EF.DG14 or, for PACE Chip Authentication Mapping, to EF.CardSecurity and signed by means of Documents Security Objects as demanded by OE.Auth_Key_Travel_ Document (Travel document Authentication Key). According to OE.Exam_Travel_Document 1880 (Examination of the physical part of the travel document) the General Inspection system has to perform PACE Chip Authentication Mapping or the Chip Authentication Protocol Version 1 to verify the authenticity of the travel document’s chip. Please note that the paragraph “The threat T.Counterfeit (Counterfeit of travel document chip data)...” above is copied due to optional Active Authentication because a refined 1885 copy can be read easier. The threat T.Counterfeit (Counterfeit of travel document chip data) addresses the attack of unauthorized copy or reproduction of the genuine travel document’s chip. This attack is thwarted by chip an identification and authenticity proof required by OT.AA_Proof (Proof of the travel document’s chip authenticity)13 using an authentication key pair to be generated 1890 by the issuing State or Organization. The Public Active14 Authentication Key has to be written into EF.DG1515 and signed by means of Documents Security Objects as demanded by OE.AA_Key_Travel_Document (Travel document Authentication Key)16 . According to OE.Exam_Travel_Document (Examination of the physical part of the travel document) the General Inspection system has to perform the Active Authentication Protocol17 to verify the 1895 authenticity of the travel document’s chip. 13 REFINEMENT OT.Chip_Auth_Proof 14 REFINEMENT Chip 15 REFINEMENT EF.DG14 16 OE.Auth_Key_Travel_Document 17 Chip Authentication Protocol Version 1 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 51 5 Security Objectives Enforcement of OSPs by security objectives CGA P.CSP_QCert (Qualified certificate) provides that the TOE and the SCA may be employed to sign data with (qualified) electronic signatures, as defined by the Directive, Article 5, paragraph 1. the Directive, recital (15) refers to SSCDs to ensure the functionality of advanced 1900 signatures. The • OE.CGA_QCert (Generation of qualified certificates) addresses the requirement of quali- fied (or advanced) electronic signatures as being based on qualified (or non-qualified) certificates. According to 1905 • OT.TOE_SSCD_Auth (Authentication proof as SSCD) 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 CGA18 . • The OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) ensures 1910 that the SP checks the proof of the device presented of the applicant that it is a SSCD19 . • The OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) ensures that the SVD exported by the TOE to the CGA corresponds to the SCD stored in the TOE and used by the signatory. • The OT.Lifecycle_Security (Lifecycle security) ensures that the TOE detects flaws during 1915 the initialization, personalization and operational usage. P.QSign (Qualified electronic signatures) provides that the TOE and the SCA may be employed to sign data with an advanced electronic signature, which is a qualified electronic signature if based on a valid qualified certificate. • OT.Sigy_SigF (Signature creation function for the legitimate signatory only) ensures 1920 signatory’s sole control of the SCD by requiring the TOE to provide the signature creation function for the legitimate signatory only and to protect the SCD against the use of others. • OT.Sig_Secure (Cryptographic security of the electronic signature) ensures that the TOE creates electronic signatures, which cannot be forged without knowledge of the SCD 1925 through robust encryption techniques. • OE.CGA_QCert (Generation of qualified certificates) addresses the requirement of quali- fied or non-qualified electronic certificates building a base for the electronic signature. • OE.DTBS_Intend (SCA sends data intended to be signed) ensures that the SCA provides only those DTBS to the TOE, which the signatory intends to sign. 1930 CGA SCA P.Sigy_SSCD (TOE as secure signature creation device) requires the TOE to meet Annex III of the Directive. The paragraph 1(a) of Annex III of the Directive is ensured by • OT.SCD_Unique (Uniqueness of the signature creation data) requiring that the SCD used for signature creation can practically occur only once. • The OT.SCD_Secrecy (Secrecy of the signature creation data), OT.Sig_Secure (Crypto- 1935 graphic security of the electronic signature) and OT.EMSEC_Design (Provide physical emanations security) and OT.Tamper_Resistance (Tamper resistance) address the secrecy of the SCD (cf. paragraph 1(a) of Annex III of the Directive). • OT.SCD_Secrecy (Secrecy of the signature creation data) and OT.Sig_Secure (Crypto- graphic security of the electronic signature) meet the requirement in paragraph 1(b) of 1940 Annex III of the Directive by the requirements to ensure that the SCD cannot be derived from SVD, the electronic signatures or any other data exported outside the TOE. 18 This security objective only applies in case a communication channel to the CGA (via trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. 19 This security objective only applies in case a communication channel to the CGA (via trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 52 5 Security Objectives • OT.Sigy_SigF (Signature creation function for the legitimate signatory only) meets the requirement in paragraph 1(c) of Annex III of the Directive by the requirements to ensure that the TOE provides the signature creation function for the legitimate signatory only 1945 and protects the SCD against the use of others. • OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) meets the requirements in paragraph 2 of Annex III of the Directive as the TOE shall not alter the DTBS/R. The usage of SCD under sole control of the signatory is ensured by • OT.Lifecycle_Security (Lifecycle security), 1950 • OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) and • OT.Sigy_SigF (Signature creation function for the legitimate signatory only). OE.Dev_Prov_Service (Authentic SSCD provided by SSCD Provisioning Service) ensures that the legitimate user obtains a TOE sample as an authentic, initialized and personalized TOE from an SSCD Provisioning Service through the TOE delivery procedure. 1955 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 feature (addressed by the security objectives 1960 • OT.TOE_SSCD_Auth (Authentication proof as SSCD) and • OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export)) to check whether the device presented is a SSCD linked to the applicant as required by • OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) 1965 and the received SVD is sent by this SSCD as required by • OE.CGA_TC_SVD_Imp (CGA trusted channel for SVD import). Thus the obligation of the SSCD provision service for the first SCD/SVD pair is complemented in an appropriate way by the CSP for the SCD/SVD pair generated outside the secure preparation environment. 1970 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 implemented by the combination of the security objectives for the TOE and its operational environment, which ensures the aspects of signatory’s sole control over and responsibility for the electronic 1975 signatures created with the TOE. • OE.Dev_Prov_Service (Authentic SSCD provided by SSCD Provisioning Service) ensures that the signatory uses an authentic TOE, initialized and personalized for the signatory. • OE.CGA_QCert (Generation of qualified certificates) ensures that the certificate allows to identify the signatory and thus to link the SVD to the signatory. 1980 • OE.SVD_Auth (Authenticity of the SVD) and • OE.CGA_QCert (Generation of qualified certificates) require the environment to ensure authenticity of the SVD as being exported by the TOE and used under sole control of the signatory. • OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) ensures that the SVD 1985 exported by the TOE corresponds to the SCD that is implemented in the TOE. • OT.SCD_Unique (Uniqueness of the signature creation data) provides that the signatory’s SCD can practically occur just once. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 53 5 Security Objectives • OE.Signatory (Security obligation of the signatory) ensures that the signatory checks that the SCD, stored in the SSCD received from an SSCD-provisioning service is in non- 1990 operational state (i.e. the SCD cannot be used before the signatory becomes into sole control over the SSCD). CGA The TOE security feature addressed by the security objectives • OT.TOE_SSCD_Auth and • OT.TOE_TC_SVD_Exp supported by 1995 • OE.Dev_Prov_Service enables the verification whether the device presented by the applicant is a SSCD as re- quired by OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) and the received SVD is sent by the device holding the corresponding SCD as required by OE.CGA_TC_SVD_Imp (CGA trusted channel for SVD import). 2000 • OT.Sigy_SigF (Signature creation function for the legitimate signatory only) provides that only the signatory may use the TOE for signature creation. As prerequisite OE.Signatory (Security obligation of the signatory) ensures that the signatory keeps their VAD confi- dential. The robust cryptographic techniques required by OT.Sig_Secure (Cryptographic security of 2005 the electronic signature) ensure that only this SCD may create a valid electronic signature that can be successfully verified with the corresponding SVD used for signature verification. • OT.Lifecycle_Security (Lifecycle security), • OT.SCD_Secrecy (Secrecy of the signature creation data), • OT.EMSEC_Design (Provide physical emanations security), 2010 • OT.Tamper_ID (Tamper detection) and • OT.Tamper_Resistance (Tamper resistance) protect the SCD against any compromise. The confidentiality of VAD is protected during the transmission between the HI device and TOE according to – OE.HID_TC_VAD_Exp (Trusted channel of HID for VAD export) and 2015 – OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import). – OE.DTBS_Intend (SCA sends data intended to be signed), – OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE), – OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS export) and – OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) ensure that the 2020 TOE generates electronic signatures only for a DTBS/R that the signatory has decided to sign as DTBS. – OE.DTBS_Intend (SCA sends data intended to be signed), – OE.DTBS_Protect (SCA protects the data intended to be signed) and – OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) ensure that the TOE creates 2025 electronic signatures only for those DTBS/R, which the signatory has decided to sign as DTBS. P.Manufact (Manufacturing of the travel document’s chip) is covered directly by OT.Identification (Identification of the TOE) since the objective mandates that the TOE implements identification mechanisms that support the identification of the TOE during 2030 manufacturing. PACE P.Pre-Operational (Pre-operational handling of the travel document) is enforced by the security objectives: • OT.Identification (Identification of the TOE) Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 54 5 Security Objectives • OT.AC_Pers (Access Control for Personalisation of logical MRTD) 2035 • OE.Personalisation (Personalisation of travel document) • and OE.Legislative_Compliance (Issuing of the travel document) in direct correspondence to the protection profile [BSI-CC-PP-0068-V2-2011-MA-01]. PACE P.Card_PKI (PKI for Passive Authentication (issuing branch)), P.Trustworthy_PKI (Trustworthi- ness of PKI), and are each directly enforced by a single security objective, namely OE.Passive_ 2040 Auth_Sign (Authentication of travel document by Signature), OE.Passive_Auth_Sign (Authen- tication of travel document by Signature), and in direct correspondence to the protection profile [BSI-CC-PP-0068-V2-2011-MA-01]. PACE The P.Terminal (Abilities and trustworthiness of terminals) is countered by the security objective OE.Exam_Travel_Document (Examination of the physical part of the travel docu- 2045 ment) additionally to the security objectives from PACE PP [BSI-CC-PP-0068-V2-2011-MA-01]. OE.Exam_Travel_Document (Examination of the physical part of the travel document) enforces the terminals to perform the terminal part of the PACE protocol. EAC The OSP P.Personalisation (Personalisation of the travel document by issuing State or Organisation only) addresses the 2050 (i) the enrolment of the logical travel document by the Personalization Agent as described in the security objective for the TOE environment OE.Personalisation (Personalisation of travel document), and (ii) the access control for the user data and TSF data as described by the security objective OT.AC_Pers (Access Control for Personalisation of logical MRTD). 2055 Note the manufacturer equips the TOE with the Personalization Agent Key(s) according to OT.Identification (Identification of the TOE). The security objective OT.AC_Pers (Access Control for Personalisation of logical MRTD) limits the management of TSF data and the management of TSF to the Personalization Agent. EAC The P.Sensitive_Data (Privacy of sensitive biometric reference data) is fulfilled and the threat 2060 T.Read_Sensitive_Data (Read the sensitive biometric reference data) is countered by the TOE-objective OT.Sens_Data_Conf (Confidentiality of sensitive biometric reference data) requiring that read access to EF.DG3 and EF.DG4 (containing the sensitive biometric reference data) is only granted to authorized inspection systems. Furthermore it is required that the transmission of these data ensures the data’s confidentiality. The authorization bases on 2065 Document Verifier certificates issued by the issuing State or Organization as required by OE.Authoriz_Sens_Data (Authorization for Use of Sensitive Biometric Reference Data) by creating appropriate Inspection System certificates for access to the sensitive biometric reference data as demanded by OE.Ext_Insp_Systems (Authorization of Extended Inspection Systems). 2070 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 (SCA sends data intended to be signed) which ensures that the SCA generates the DTBS/R of the data that have been presented to the signatory as DTBS 2075 and which the signatory intends to sign in a form which is appropriate for being signed by the TOE. A.CGA (Trustworthy certificate 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 2080 • OE.CGA_QCert (Generation of qualified certificates), which ensures the generation of qualified certificates, and by Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 55 5 Security Objectives • OE.SVD_Auth (Authenticity of the SVD), which ensures the protection of the integrity of the received SVD and the verification of the correspondence between the SVD and the SCD that is implemented by the SSCD of the signatory. 2085 A.Env_Admin (Environment for administrator) establishes a trustworthy environment for the Administrator for setting up the initialization and personalization of the TOE after the Ad- ministrator is successfully authenticated. This is addressed by OE.Env_Admin (Administrator works in trusted environment) which ensures that the TOE initialization, TOE personalization and (re)generation of RSA SCD/SVD pair is only started by the Administrator within a trusted 2090 environment and further eSign update (generation of EC SCD/SVD pair, export of SVD and optional creation/update of EFs / DFs) is performed by the Administrator through a trusted channel as a trusted environment. Notes 2095 1. “A.Env_Admin” and “OE.Env_Admin” are added to the contents of [BSI-CC-PP-0059- 2009-MA-02]. 2. After authentication and trusted channel establishment communication via trusted channel is considered to be a trusted environment. 3. RSA SCD/SVD pair generation is only allowed to be performed if the TOE is located in a 2100 trustworthy environment. For details refer to the guidance documentation. A.Env_Mass_Signature (Environment for a mass signature TOE) establishes a trustworthy environment for the signatory for generating mass signatures after the signatory is successfully authenticated. This is addressed by OE.Env_Mass_Signature (Mass signatures are generated in trusted environment only) which ensures that generation of mass signatures takes place 2105 only in a trusted environment. Note 1. “A.Env_Mass_Signature ” and “OE.Env_Mass_Signature ” are added to the contents of [BSI-CC-PP-0059-2009-MA-02]. 2110 The examination of the travel document addressed by the assumption A.Insp_Sys (Inspec- tion Systems for global interoperability) is covered by the security objectives for the TOE environment OE.Exam_Travel_Document (Examination of the physical part of the travel document) which requires the inspection system to examine physically the travel document, the Basic Inspection System to implement the Basic Access Control, and the Extended 2115 Inspection Systems to implement and to perform PACE Chip Authentication Mapping or the Chip Authentication Protocol Version 1 to verify the Authenticity of the presented travel document’s chip. The security objectives for the TOE environment OE.Prot_Logical_Travel_ Document (Protection of data from the logical travel document) require the Inspection System to protect the logical travel document data during the transmission and the internal 2120 handling. “Travel document Authentication Key”.20 The assumption A.Passive_Auth (PKI for Passive Authentication) is directly covered by the security objective for the TOE environment OE.Passive_Auth_Sign (Authentication of travel document by Signature) from PACE PP [BSI-CC-PP-0068-V2-2011-MA-01] covering the nec- essary procedures for the Country Signing CA Key Pair and the Document Signer Key Pairs. 2125 The implementation of the signature verification procedures is covered by OE.Exam_Travel_ Document (Examination of the physical part of the travel document). The assumption A.Auth_PKI (PKI for Inspection Systems) is covered by the security objective for the TOE environment OE.Authoriz_Sens_Data (Authorization for Use of Sensitive Biometric Reference Data) requires the CVCA to limit the read access to sensitive biometrics by issuing 2130 Document Verifier certificates for authorized receiving States or Organizations only. The 20 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 56 5 Security Objectives Document Verifier of the receiving State is required by OE.Ext_Insp_Systems (Authorization of Extended Inspection Systems) to authorize Extended Inspection Systems by creating Inspection System Certificates. Therefore, the receiving issuing State or Organization has to establish the necessary public key infrastructure. 2135 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 57 6 Extended Components Definition 6 Extended Components Definition This Security Target uses the components defined in • chapter 5 of [BSI-CC-PP-0068-V2-2011-MA-01] • chapter 5 of [BSI-CC-PP-0056-V2-2012-MA-02] for the ePass and eID applications and 2140 • chapter 8 of [BSI-CC-PP-0059-2009-MA-02] • chapter 8 of [BSI-CC-PP-0071-2012-MA-01] • chapter 8 of [BSI-CC-PP-0072-2012-MA-01] for eSign applications. No other components are used. 2145 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 58 7 Security Requirements (ASE_REQ) 7 Security Requirements (ASE_REQ) Common Criteria allows several operations to be performed on functional requirements; refinement, selection, assignment, and iteration. Each of these operations is used in this ST. This Security Target performs the missing operations and considers the Application Notes given in [BSI-CC-PP-0056-V2-2012-MA-02], [BSI-CC-PP-0068-V2-2011-MA-01], [BSI-CC-PP- 2150 0059-2009-MA-02], [BSI-CC-PP-0071-2012-MA-01] and [BSI-CC-PP-0072-2012-MA-01]. The following conventions have been applied to the set of operations that may be applied to functional requirements: • selections are indicated by bold text and by footnotes which lists the deleted text, • assignments are indicated by bold text and by footnotes which lists the deleted text, 2155 • iterations are indicated by appending a slash “/” with informative data following the component title (for example “/SHA-2”) and • refinements are indicated by bold text and by footnotes which identifies the refined text or by bold text and a leading [REFINEMENT] and in case of a longer section with a closing [END REFINEMENT]. 2160 If an operation of a security functional requirement has already been performed in the refer- enced PP(s) that is indicated by underlined text and by a footnote that states the operation. If a security functional requirement is added to contents of PP [BSI-CC-PP-0059-2009-MA-02], this is described by a note which also states whether the SFR is “iterated” or “not iterated” from a PP SFR. 2165 7.1 Elliptic curves used This TOE uses the following elliptic curves: 1. for 256 bits: a) P-256 ([NIST-FIPS-186-4], chapter D.1.2.3 “Curve P-256”, aka secp256r1 or prime256v1) b) brainpoolP256r1 ([RFC-5639-2010-03] chapter 3.4) 2170 2. for 384 bits: a. P-384 ([NIST-FIPS-186-4], chapter D.1.2.4 “Curve P-384”, aka secp384r1) b. brainpoolP384r1 ([RFC-5639-2010-03] chapter 3.6) 3. for 512 bits: brainpoolP512r1 ([RFC-5639-2010-03] chapter 3.7) 2175 4. for 521 bits: P-521 ([NIST-FIPS-186-4], chapter D.1.2.5 “Curve P-521”, aka secp521r1) Notes 1. EC curves above are taken from [BSI-TR-03110-3-V221] Table 4: Standardized Domain 2180 Parameters. 2. This TOE uses the EC crypto library v2.08.007 of the underlying chip SLC52GDA448*. 3. For “ECDH” see [Infineon-ST-SLC52-H13] section “7.1.2.5.6 Elliptic Curve Diffie-Hellman (ECDH) key agreement”. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 59 7 Security Requirements (ASE_REQ) 4. For the “digital signature generation” see [Infineon-ST-SLC52-H13], “8.5.4 Elliptic Curves 2185 Cryptographic Library for all versions”, section “Signature Generation and Verification”. 5. For the “cryptographic key generation algorithm” see [Infineon-ST-SLC52-H13], “7.1.2.5.5 Elliptic Curve (EC) key generation” 6. For the “digital signature verification” see [Infineon-ST-SLC52-H13], “8.5.4 Elliptic Curves Cryptographic Library for all versions”, section “ECDSA Signature Verification”. 2190 7.2 RSA key support The TOE supports the following RSA key sizes: • 2048, 3072, and 4096 bits Both the straight-forward and the CRT key representation are supported. The straight-forward key representation for private keys is limited to the 2048bit representation. 2195 Notes 1. This TOE uses the RSA crypto library v2.08.007 of the underlying chip SLC52GDA448*. 2. For “DH” the TOE uses the Modular Arithmetic Operations listed in [Infineon-ST-SLC52- H13], “8.5.3 RSA Cryptography”, section “Encryption, Decryption, Signature Generation 2200 and Verification”. 3. For the “digital signature generation” see [Infineon-ST-SLC52-H13], “8.5.3 RSA Cryptogra- phy”, section “Encryption, Decryption, Signature Generation and Verification”. 4. For the “digital signature verification” see [Infineon-ST-SLC52-H13], “8.5.3 RSA Cryptogra- phy”, section “Encryption, Decryption, Signature Generation and Verification”. 2205 7.3 Hash functions implemented This TOE provides the following hash algorithms 1. SHA-1 2. SHA-{256, 384, 512}. 2210 Notes 1. This TOE uses for SHA-{1, 256, 384, 512} the SHA crypto library v1.12.001 of the underlying chip SLC52GDA448*. 2. For the implemented standards, see [Infineon-Chip-HCL52], “Annex D Reference list of implemented standards”. 2215 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 60 7 Security Requirements (ASE_REQ) 7.4 Security attributes This ST defines the following security attributes for the PACE/EAC based access control: Table 7.1: Terminal Authentication Status1 Value Meaning none (any terminal) default role (i.e. without authorization after start-up) CVCA terminal is authenticated as CVCA after successful CA v.1 and TA v.1 DV (domestic) terminal is authenticated as domestic DV after successful CA v.1 and TA v.1 DV (foreign) terminal is authenticated as foreign DV after successful CA v.1 and TA v.1 IS terminal is authenticated as IS after successful CA v.1 and TA v.1 Table 7.2: Terminal Authorization Values Meaning none DG4 (Iris) Read access to DG4 (cf. [BSI-TR-03110-4-V221] Table 2) DG3 (Fingerprint) Read access to DG3 (cf. [BSI-TR-03110-4-V221] Table 2) Notes 1. Security attribute Terminal Authentication Status is spelled differently in PP [BSI-CC-PP- 2220 0056-V2-2012-MA-02], e.g. FDP_ACF.1/TRM spells it Terminal Authentication v.1. 2. Security attribute Terminal Authorization is spelled differently in PP [BSI-CC-PP-0056- V2-2012-MA-02], e.g. FDP_ACF.1/TRM spells it Authorization of the Terminal. 3. These diffent spellings are corrected by refinements to read always Terminal Authenti- cation Status or Terminal Authorization. 2225 4. A combination of Terminal Authorization attributes DG4 and DG3 is allowed and thus not not stated explicitly in Table 7.2. The security attributes and related status for the subjects and objects for the SSCD related access control policy are: Table 7.3: Security Attributes for SSCD related SFPs Subject or object the secu- rity attribute is associated with Security attribute type Value of the security at- tribute 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 se- curity attributes for SVD) (This ST does not define se- curity attributes for SVD) 1 REFINEMENT terminal authentication status Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 61 7 Security Requirements (ASE_REQ) 7.5 Keys and certificates 2230 Table 7.4 provide an overview of the keys and certificates used including further keys and certificates from [BSI-CC-PP-0068-V2-2011-MA-01]. Note 1. Where PP [BSI-CC-PP-0068-V2-2011-MA-01] is more specific than PP [BSI-CC-PP-0056- 2235 V2-2012-MA-02] name and data are taken from the former. Table 7.4: Keys and certificates Name Data TOE intrinsic secret cryptographic keys Permanently or temporarily stored secret crypto- graphic material by the TOE in order to enforce its security functionality. receiving PKI branch SK.CVCA The Country Verifying Certification Authority (CVCA) holds a private key (SK.CVCA) used for signing the DV Certificates. PK.CVCA The TOE stores the CVCA Public Key (PK.CVCA) as part of the TSF data to verify the DV Certificates. The PK.CVCA has the security attribute Current Date as the most recent valid effective date of the CVCA or of a domestic DV Certificate. C.CVCA The Country Verifying Certification Authority Cer- tificate may be a self-signed certificate or a link certificate (cf. [BSI-TR-03110-1-V220] and Glos- sary). It contains (i) the Country Verifying Certi- fication Authority Public Key (PK.CVCA) as au- thentication reference data, (ii) the coded access control rights of the Country Verifying Certifica- tion Authority, (iii) the Certificate Effective Date and the Certificate Expiration Date as security attributes. C.DV The Document Verifier Certificate C.DV is issued by the Country Verifying Certification Author- ity. It contains (i) the Document Verifier Public Key (PK.DV) as authentication reference data (ii) identification as domestic or foreign Document Verifier, the coded access control rights of the Document Verifier, the Certificate Effective Date and the Certificate Expiration Date as security attributes. C.IS The Inspection System Certificate (C.IS) is issued by the Document Verifier. It contains (i) as au- thentication reference data the Inspection Sys- tem Public Key (PK.IS), (ii) the coded access con- trol rights of the Extended Inspection System, the Certificate Effective Date and the Certificate Expiration Date as security attributes. Issuing PKI branch Chip Authentication key pair The Chip Authentication key pair (SK.ICC, PK.ICC) are used for Key Agreement Protocol: Diffie- Hellman (DH) according to RFC 2631 or Elliptic Curve Diffie-Hellman according to ISO 11770-3 [ISO-IEC-11770-3]. continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 62 7 Security Requirements (ASE_REQ) Table 7.4 – continued from previous page Name Data PK.ICC The Chip Authentication Public Key (PK.ICC) is stored in the EF.DG14 Chip Authentication Pub- lic Key of the TOE’s logical travel document and used by the inspection system for Chip Authenti- cation Version 1 of the travel document’s chip. It is part of the user data provided by the TOE for the IT environment. SK.ICC The Chip Authentication Private Key (SK.ICC) is used by the TOE to authenticate itself as authen- tic travel document’s chip. It is part of the TSF data. Active Authentica- tion key pair The Active Authentication Key Pair (KPr.AA, KPu.AA) is used for Active Authentication Proto- col according to [ICAO-9303-2015] part 11 chapter “6.1 Active Authentication)” using EC. KPu.AA The Active Authentication Public Key (KPu.AA) is stored in the EF.DG15 of the TOE’s logical travel document and used by the inspection system for Active Authentication of the travel document’s chip. It is part of the user data provided by the TOE for the IT environment. KPr.AA The Active Authentication Private Key (KPr.AA) is used by the TOE to authenticate itself as authen- tic travel document’s chip. It is part of the TSF data. CSCA Key Pair and Certificate CSCA of the travel document Issuer signs the Document Signer Public Key Certificate (C.DS) with the Country Signing Certification Author- ity Private Key (SK.CSCA) and the signature will be verified by receiving terminal with the Coun- try Signing Certification Authority Public Key (PK.CSCA). The CSCA also issues the self-signed CSCA Certificate (CCSCA) to be distributed by strictly secure diplomatic means, see. [ICAO- 9303-2015]. DS Key Pairs and Cer- tificates The Document Signer Certificate C.DS is issued by the Country Signing Certification Authority. It contains the Document Signer Public Key (PK.DS) as authentication reference data. The Document Signer acting under the policy of the CSCA signs the Document Security Object (SOD) of the travel document with the Document Signer Private Key (SK.DS) and the signature will be verified by a terminal as the Passive Authentication with the Document Signer Public Key (PK.DS). PACE Chip Authenti- cation Mapping Pub- lic Key Pair The PACE Chip Authentication Mapping Pub- lic Key Pair (SK.CAM, PK.CAM) are used for PACE Chip Authentication Mapping according to [ICAO-TR-110], [BSI-TR-03110-1-V220]. continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 63 7 Security Requirements (ASE_REQ) Table 7.4 – continued from previous page Name Data PACE Chip Authen- tication Mapping Public Key (PK.CAM) The PACE Chip Authentication Mapping Public Key (PK.CAM) is stored in the EF.CardSecurity of the TOE’s logical travel document and used by the inspection system for PACE Chip Authenti- cation Mapping of the travel document’s chip. It is part of the User Data provided by the TOE for the IT environment. PACE Chip Authenti- cation Mapping Pri- vate Key (SK.CAM) The PACE Chip Authentication Mapping Private Key (SK.CAM) is used by the TOE to authenticate itself as authentic travel document’s chip. It is part of the TSF data. Session keys CA-K.MAC, CA- K.ENC Secure messaging encryption key and MAC com- putation key agreed between the TOE and an Inspection System as result of the Chip Authen- tication Protocol Version 1. PACE-K.MAC, PACE- K.ENC Secure messaging AES keys for message authen- tication (CMAC-mode) and for message encryp- tion (CBC-mode) agreed between the TOE and a terminal as result of the PACE Protocol ([ICAO- TR-110]). Ephemeral keys ephem- SK.PICC.PACE, ephem- PK.PICC.PACE The ephemeral PACE Authentication Key Pair {ephem-SK.PICC.PACE, ephem-PK.PICC-PACE} is used for Key Agreement Protocols Elliptic Curve Diffie-Hellman (ECDH; ECKA key agreement al- gorithm) according to [BSI-TR-03111-V210-ECC] / [ICAO-TR-110] or DH according to [RSA-PKCS-3- V1.4]. Notes 1. The Country Verifying Certification Authority identifies a Document Verifier as “domestic” in the Document Verifier Certificate if it belongs to the same State as the Country 2240 Verifying Certification Authority. The Country Verifying Certification Authority identifies a Document Verifier as “foreign” in the Document Verifier Certificate if it does not belong to the same State as the Country Verifying Certification Authority. From travel document’s point of view the domestic Document Verifier belongs to the issuing State or Organization. 2245 2. With the optional Active Authentication a key pair is stored in the chip. 3. According to OE.AA_Key_Travel_Document the hash value of ACTIVE AUTHENTICATION PUBLIC KEY INFO (cf. [ICAO-9303-2015] part 11, section 6.1 is stored in the Document Security Object (SOD) for verifying the key using Passive Authentication. 4. The reference to the ISO 11770-3 which defines ECDH is taken over literally from the 2250 table in the protection profile [BSI-CC-PP-0056-V2-2012-MA-02]. All other parts of the ST reference different implementation standards. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 64 7 Security Requirements (ASE_REQ) 7.6 Security Functional Requirements for the TOE 7.6.1 Class FCS Cryptographic support The iterations of FCS_CKM.1/CA_EC Cryptographic key generation - EC Diffie-Hellman for 2255 Chip Authentication session keys and FCS_COP.1/EC (Cryptographic operation – EC) are caused by different cryptographic (key generation) algorithms to be implemented and keys to be generated by the TOE and shall meet their respective requirements as specified in [CC-Part2-V3.1]. 7.6.1.1 FCS_CKM.1/CA_EC Cryptographic key generation - EC Diffie-Hellman for Chip Au- 2260 thentication session keys EAC Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] 2265 FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/CA_EC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH2 and specified cryp- tographic key sizes 128, 192, 256 bits (for AES)3 that meet the following: (1) based on an ECDH protocol compliant to [BSI-TR-03111-V210-ECC] 2270 using curves (2) see section Elliptic curves used.4 Notes 1. FCS_CKM.1/CA_EC implicitly contains the requirements for the hashing functions used 2275 for key derivation by demanding compliance to [BSI-TR-03110-1-V220], section 3.1. 2. The TOE generates a shared secret value with the terminal during the Chip Authenti- cation Protocol Version 1, see [BSI-TR-03110-1-V220] chapter “3.4 Chip Authentication Version 1”. The protocol used by this TOE bases on the Diffie-Hellman-Protocol compliant to TR-03111 (i.e. an elliptic curve cryptography algorithm) (cf. [BSI-TR-03111-V210-ECC], for 2280 details). The shared secret value is used to derive the Chip Authentication Session Keys (CA-K.MAC, CA-K.Enc) used for encryption and MAC computation for secure messaging (defined in Key Derivation Function [BSI-TR-03110-1-V220]). 3. The TOE uses the hash functions SHA-1 and SHA-256 of the library SHA (HCL52 v1.12.001) provided by the underlying chip SLC52GDA448* for the cryptographic primitive to derive 2285 the keys for secure messaging from any shared secrets of the Authentication Mechanisms according to [BSI-TR-03110-3-V221] “A.2.3.2. AES”. 4. The TOE destroys any session keys in accordance with FCS_CKM.4 from [BSI-CC-PP- 0068-V2-2011-MA-01] after (i) detection of an error in a received command by verification of the MAC and 2290 (ii) after successful run of the Chip Authentication Protocol v.1. 2 [assignment: cryptographic key generation algorithm] 3 [assignment: cryptographic key sizes] 4 [selection: based on the Diffie-Hellman key derivation protocol compliant to [BSI-TR-03110-1-V220] and [RSA- PKCS-3-V1.4] , based on an ECDH protocol compliant to [BSI-TR-03111-V210-ECC] ] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 65 7 Security Requirements (ASE_REQ) (iii) The TOE destroys the PACE Session Keys after generation of the Chip Authentication Session Keys and changes the secure messaging to the Chip Authentication Session Keys. (iv) The TOE clears the memory area of any session keys before starting the communi- 2295 cation 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 fulfilled by FCS_CKM.1/CA_ EC. 5. See also FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the key sizes used. 6. See also section Hash functions implemented. 2300 7. 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_EC applies instead of FCS_CKM.1/CA_EC. 7.6.1.2 FCS_CKM.1/CA_RSA Cryptographic key generation - RSA DH for Chip Authentica- tion session keys 2305 EAC Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction 2310 FCS_CKM.1.1/CA_RSA The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm DH5 and specified cryptographic key sizes 128, 192, 256 bits (for AES)6 that meet the following: (1) based on the Diffie-Hellman key derivation protocol compliant to [RSA-PKCS-3-V1.4] and [BSI-TR-03110-1-V220].7 2315 Notes 1. FCS_CKM.1/CA_RSA is iterated from FCS_CKM.1/CA_EC. 2. For computing the shared secret the modular exponentation function provided by the RSA crypto library of SLC52GDA448* is used. 2320 3. FCS_CKM.1/CA_RSA implicitly contains the requirements for the hashing functions used for key derivation by demanding compliance to [BSI-TR-03110-1-V220], section 3.1. 4. The TOE generates a shared secret value with the terminal during the Chip Authenti- cation Protocol Version 1, see [BSI-TR-03110-1-V220] chapter “3.4 Chip Authentication Version 1”. The protocol used by this TOE bases on the Diffie-Hellman-Protocol com- 2325 pliant to [RSA-PKCS-3-V1.4] (i.e. modulo arithmetic based cryptographic algorithm, cf. [RSA-PKCS-3-V1.4]). The shared secret value is used to derive the Chip Authentication Session Keys (CA-K.MAC, CA-K.Enc) used for encryption and MAC computation for secure messaging (defined in Key Derivation Function [BSI-TR-03110-1-V220]). 5. The TOE uses the hash functions SHA-1 and SHA-256 of the library SHA (HCL52 v1.12.001) 2330 provided by the underlying chip SLC52GDA448* for the cryptographic primitive to derive the keys for secure messaging from any shared secrets of the Authentication Mechanisms according to [BSI-TR-03110-3-V221] chapter “A.2.3.2. AES”. 5 [assignment: cryptographic key generation algorithm] 6 [assignment: cryptographic key sizes] 7 [selection: based on the Diffie-Hellman key derivation protocol compliant to [BSI-TR-03110-1-V220] and [RSA- PKCS-3-V1.4] , based on an ECDH protocol compliant to [BSI-TR-03111-V210-ECC] ] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 66 7 Security Requirements (ASE_REQ) 6. The TOE destroys any session keys in accordance with FCS_CKM.4 from [BSI-CC-PP- 0068-V2-2011-MA-01] after 2335 (i) detection 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 destroys the PACE Session Keys after generation of the Chip Authentication Session Keys and changes the secure messaging to the Chip Authentication Session Keys. 2340 (iv) The TOE clears the memory area of any session keys before starting the communi- cation 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 fulfilled by FCS_CKM.1/CA_ RSA. 7. See also FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the key sizes used. 2345 8. See also section Hash functions implemented. 9. 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_RSA applies instead of FCS_CKM.1/CA_RSA. 7.6.1.3 FCS_CKM.1/DH_PACE_EC Cryptographic key generation - EC Diffie-Hellman for 2350 PACE session keys PACE Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] 2355 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: fulfilled by FCS_CKM.4 FCS_CKM.1.1/DH_PACE_EC The TSF shall generate cryptographic keys in accor- dance with a specified cryptographic key generation algorithm ECDH compli- 2360 ant to [BSI-TR-03111-V210-ECC]8 and specified cryptographic key sizes 128, 192, 256 bits (for AES)9 that meet the following: (1) [ICAO-TR-110] using curves (2) see section Elliptic curves used.10 2365 Notes 1. See also FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the key sizes used. 2. The TOE generates a shared secret value K with the terminal during the PACE protocol, see [ICAO-TR-110]. The shared secret value K is used for deriving the AES session keys for 2370 message encryption and message authentication (PACE-K.MAC, PACE-K.Enc) according 8 [selection: Diffie-Hellman-Protocol compliant to [RSA-PKCS-3-V1.4], ECDH compliant to [BSI-TR-03111-V210-ECC]] 9 [assignment: cryptographic key sizes] 10 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 67 7 Security Requirements (ASE_REQ) to [ICAO-TR-110] for the TSF required by FCS_COP.1/PACE_ENC (see FCS_COP.1/CA_ENC Note 5) and FCS_COP.1/PACE_MAC (see FCS_COP.1/CA_MAC Note 5). 3. FCS_CKM.1/DH_PACE_EC implicitly contains the requirements for the hashing functions used for key derivation by demanding compliance to [ICAO-TR-110]. 2375 4. The TOE destroys any session keys in accordance with FCS_CKM.4 from [BSI-CC-PP- 0068-V2-2011-MA-01] after (i) detection of an error in a received command by verification of the MAC and (ii) The TOE clears the memory area of any session keys before starting the communi- cation with the terminal in a new after-reset-session as required by FDP_RIP.1. 2380 5. See also section Hash functions implemented. 6. If a configuration of the TOE uses FCS_CKM.1/DH_PACE_RSA for PACE session key, it must not use this SFR additionally. 7.6.1.4 FCS_CKM.1/DH_PACE_RSA Cryptographic key generation - RSA Diffie-Hellman for PACE session keys 2385 PACE 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 2390 distribution, therefore FCS_CKM.2 makes no sense in this case. FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_CKM.1.1/DH_PACE_RSA The TSF shall generate cryptographic keys in ac- cordance with a specified cryptographic key generation algorithm Diffie- Hellman-Protocol compliant to [RSA-PKCS-3-V1.4]11 and specified crypto- 2395 graphic key sizes 128, 192, 256 bits (for AES)12 that meet the following: (1) [ICAO-TR-110] (section 3.4.1 Key Agreement Algorithms, table 1, Generic Mapping only) using bit lengths (2) 2048-bit MODP Group (p component) with 224-bit Prime Order Sub- 2400 group (q component) or (3) 2048-bit MODP Group (p component) with 256-bit Prime Order Sub- group (q component)13 Notes 2405 1. FCS_CKM.1/DH_PACE_RSA is iterated from FCS_CKM.1/DH_PACE_EC. 2. For computing the shared secret the modular exponentation function of the RSA crypto library provided by SLC52GDA448* is used. 3. See also FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the key sizes used. 11 [selection: Diffie-Hellman-Protocol compliant to [RSA-PKCS-3-V1.4], ECDH compliant to [BSI-TR-03111-V210-ECC]] 12 [assignment: cryptographic key sizes] 13 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 68 7 Security Requirements (ASE_REQ) 4. The TOE generates a shared secret value K with the terminal during the PACE protocol, 2410 see [ICAO-TR-110]. The shared secret value K is used for deriving the AES session keys for message encryption and message authentication (PACE-K.MAC, PACE-K.Enc) according to [ICAO-TR-110] for the TSF required by FCS_COP.1/PACE_ENC (see FCS_COP.1/CA_ENC Note 5) and FCS_COP.1/PACE_MAC (see FCS_COP.1/CA_MAC Note 5). 5. FCS_CKM.1/DH_PACE_RSA implicitly contains the requirements for the hashing functions 2415 used for key derivation by demanding compliance to [ICAO-TR-110]. 6. The TOE destroys any session keys in accordance with FCS_CKM.4 from [BSI-CC-PP- 0068-V2-2011-MA-01] after (i) detection of an error in a received command by verification of the MAC and (ii) The TOE clears the memory area of any session keys before starting the communi- 2420 cation with the terminal in a new after-reset-session as required by FDP_RIP.1. 7. See also section Hash functions implemented. 8. If a configuration of the TOE uses FCS_CKM.1/DH_PACE_EC for PACE session key, it must not use this SFR additionally. 7.6.1.5 FCS_CKM.1/EC (Cryptographic key generation – EC) 2425 SSCD Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction 2430 FCS_CKM.1.1/EC The TSF shall generate an SCD/SVD pair14 in accordance with a specified cryptographic key generation algorithm Elliptic Curve EC Key Generation15 and specified cryptographic key sizes 256, 384, 512, and 521 bits16 that meet the following: ECDSA Key Generation: 2435 (1) According to the appendix A4.3 in [ANSI-X9.62] the cofactor h is not supported. (2) According to section 6.4.2 in [ISO-IEC-14888-3] (3) According to Appendix A.16.9 in [IEEE-1363] using curves 2440 (4) see section Elliptic curves used.17 Notes 1. FCS_CKM.1/EC amounts to requirement “FCS_CKM.1” with the selection of ECC key generation. 2445 2. This TOE uses the crypto libraries RSA v2.08.007, EC v2.08.007, Toolbox v2.08.007, Base v2.08.007, SHA-2 v1.12.001 and Symmetric Crypto Library (SCL) v2.04.002 of the underlying chip SLC52GDA448*. 14 The refinement substitutes “cryptographic keys” by “SCD/SVD pairs” because it clearly addresses the SCD/SVD key generation. 15 [assignment: cryptographic key generation algorithm] 16 [assignment: cryptographic key sizes] 17 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 69 7 Security Requirements (ASE_REQ) 3. For the cryptographic key generation algorithm “Elliptic Curve EC Key Generation” see [Infineon-ST-SLC52-H13], 7.1.2.5.5 Elliptic Curve (EC) key generation. 2450 4. If a configuration of the TOE uses FCS_CKM.1/RSA, it must not use this SFR additionally. 7.6.1.6 FCS_CKM.1/RSA (Cryptographic key generation – RSA) SSCD Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or 2455 FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/RSA The TSF shall generate an SCD/SVD pair18 in accordance with a specified cryptographic key generation algorithm RSA key generation19 and specified cryptographic key sizes 2048, 3072, and 4096 bits20 that meet the 2460 following: (1) [RSA-PKCS1-v2.2], sections 3.1 and 3.2 for u=2, i.e., without any (ri, di, ti), i > 2.: • public key representation 3.1 supported for n < 24096 + 128 , • private key representation 3.2(1) supported for n < 22048 + 64 , 2465 • private key representation 3.2(2) supported for p × q < 24096 + 128 (2) and [IEEE-1363], section 8.1.3.1: • public key representation 8.1.3.1(1) supported for n < 22048 + 64 , • private key representation 8.1.3.1(2) supported for p × q < 24096 + 128 , • private key representation 8.1.3.1(3) supported for p × q < 22048 + 6421 2470 Notes 1. FCS_CKM.1/RSA is added to contents of PP [BSI-CC-PP-0059-2009-MA-02] (iterated). 2. This TOE uses the crypto libraries RSA v2.08.007, EC v2.08.007, Toolbox v2.08.007, Base v2.08.007, SHA-2 v1.12.001 and Symmetric Crypto Library (SCL) v2.04.002 of the 2475 underlying chip SLC52GDA448*. 3. RSA key generation is only allowed to be performed in a trustworthy environment. 4. If a configuration of the TOE uses FCS_CKM.1/EC, it must not use this SFR additionally. 18 The refinement substitutes “cryptographic keys” by “SCD/SVD pairs” because it clearly addresses the SCD/SVD key generation. 19 [assignment: cryptographic key generation algorithm] 20 [assignment: cryptographic key sizes] 21 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 70 7 Security Requirements (ASE_REQ) 7.6.1.7 FCS_CKM.4 Cryptographic key destruction Hierarchical to No other components. 2480 Dependencies [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a spec- 2485 ified cryptographic key destruction method overwriting with zeros22 that meets the following: none23 . Notes 1. The TOE shall destroy the PACE / CA session keys after detection of an error in a received 2490 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. 2. The cryptographic key SCD will be destroyed on demand of the signatory or by the signatory himself. The signatory may want to destruct the SCD stored in the SSCD e.g. 2495 after the qualified certificate for the corresponding SVD is not valid anymore. 3. The personalization key will be destroyed after the end of the personalization. 7.6.1.8 FCS_COP.1/EC (Cryptographic operation – EC) SSCD Hierarchical to No other components. Dependencies 2500 [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/EC The TSF shall perform digital signature creation24 in accordance 2505 with a specified cryptographic algorithm Elliptic Curve Digital Signature Al- gorithm (ECDSA)25 and cryptographic key sizes 256, 384, 512, and 521 bits26 that meet the following: Signature Generation: 1. According to section 7.3 in [ANSI-X9.62]. 2510 • Step d) and e) not supported. • The output of step e) has to be provided as input to our function by the caller. • Deviation of step c) and f): – The jumps to step a) were substituted by a return of the function 2515 with an error code, the jumps are emulated by another call to our function. 22 [assignment: cryptographic key destruction method] 23 [assignment: list of standards] 24 [assignment: list of cryptographic operations] 25 [assignment: cryptographic algorithm] 26 [assignment: cryptographic key sizes] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 71 7 Security Requirements (ASE_REQ) 2. According to section 6.4.3 in [ISO-IEC-14888-3]. • 6.4.3.3 not supported. • 6.4.3.5 not supported: 2520 – The hash-code H of the message has to be provided by the caller as input to our function. • 6.4.3.7 not supported. • 6.4.3.8 not supported. 3. According to section 7.2.7 in [IEEE-1363]: 2525 • Deviation of step (3) and (4): – The jump to step 1, were substituted by a return of the function with an error code, the jumps are emulated by another call to our function. using curves 2530 4. see section Elliptic curves used.27 Notes 1. FCS_COP.1/EC amounts to requirement “FCS_COP.1” with the selection of ECDSA. 2. This TOE uses the crypto libraries RSA v2.08.007, EC v2.08.007, Toolbox v2.08.007, 2535 Base v2.08.007, SHA-2 v1.12.001 and Symmetric Crypto Library (SCL) v2.04.002 of the underlying chip SLC52GDA448*. 3. For the Elliptic Curve Digital Signature Algorithm (ECDSA) see [Infineon-ST-SLC52-H13], “7.1.2.5.4 Elliptic Curve DSA (ECDSA) operation”, section “Signature Generation and Verifi- cation”. 2540 4. If a configuration of the TOE uses FCS_COP.1/RSA, it must not use this SFR additionally. 7.6.1.9 FCS_COP.1/RSA (Cryptographic operation – RSA) SSCD Hierarchical to No other components. Dependencies [FDP_ITC.1 Import of user data without security attributes, or 2545 FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/RSA The TSF shall perform digital signature creation28 in accordance with a specified cryptographic algorithm Rivest-Shamir-Adleman (RSA)29 and 2550 cryptographic key sizes 2048, 3072, and 4096 bits30 that meet the following: Signature Generation (with or without CRT): 1. According to section 5.2.1 RSASP1 in [RSA-PKCS1-v2.2], for u=2, i.e., with- out any (ri, di, ti), i > 2: • 5.2.1(1) not supported, 2555 • 5.2.1(2.a) supported for n < 22048 + 64 , 27 [assignment: list of standards] 28 [assignment: list of cryptographic operations] 29 [assignment: cryptographic algorithm] 30 [assignment: cryptographic key sizes] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 72 7 Security Requirements (ASE_REQ) • 5.2.1(2b) supported for p x q < 24096 + 128 , • 5.2.1(2b) (ii)&(v) not applicable due to u = 2 2. According to section 8.2.4 in [IEEE-1363]: • 8.2.1(I) supported for n < 22048 + 64 , 2560 • 8.2.1(II) supported for p x q < 24096 + 128 • 8.2.1(III) not supported.31 Notes 1. FCS_COP.1/RSA is added to contents of PP [BSI-CC-PP-0059-2009-MA-02] (iterated). 2565 2. This TOE uses the crypto libraries RSA v2.08.007, EC v2.08.007, Base v2.08.007, SHA- 2 v1.12.001 and Symmetric Crypto Library (SCL) v2.04.002 of the underlying chip SLC52GDA448*. 3. For the “Rivest-Shamir-Adleman (RSA)” see [Infineon-ST-SLC52-H13], “7.1.2.6.1 Rivest- Shamir-Adleman (RSA) operation”. 2570 4. The padding is done according to RSASSA-PSS and RSASSA-PKCS1-v1_5. 5. If a configuration of the TOE uses FCS_COP.1/EC, it must not use this SFR additionally. 7.6.1.10 FCS_COP.1/SHA (Cryptographic operation – Hash calculation) SSCD Hierarchical to No other components. Dependencies 2575 [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 fulfilled by Not fulfilled, but justified: 2580 A hash function does not use any cryptographic key; hence • neither a respective key import nor key generation can be expected here. • a respective key destruction cannot be expected here. FCS_COP.1.1/SHA The TSF shall perform hash-value calculation of user chosen data32 in accordance with a specified cryptographic algorithm SHA-1, SHA- 2585 256, SHA-384 and SHA-51233 and cryptographic key sizes none34 that meet the following: [NIST-FIPS-180-4] with chapters 6.1 “SHA-1”, 6.2 “SHA-256”, 6.4 “SHA-512” and 6.5 “SHA-384”.35 2590 Notes 1. FCS_COP.1/SHA is added to contents of PP [BSI-CC-PP-0059-2009-MA-02] (not iterated). 2. This TOE uses the SHA library (HCL52 v1.12.001) of the underlying chip SLC52GDA448*. 31 [assignment: list of standards] 32 [assignment: list of cryptographic operations] 33 [assignment: cryptographic algorithm] 34 [assignment: cryptographic key sizes] 35 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 73 7 Security Requirements (ASE_REQ) 3. The requirements for the hashing functions used for PACE are included in SFRs FCS_ CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA. 2595 4. FCS_COP.1/SHA is used for internally calculated hash values which are used afterward for the signature creation including last round hash values. 7.6.1.11 FCS_COP.1/AES_MAC (Cryptographic operation – MACing with AES) SSCD Hierarchical to No other components. Dependencies 2600 [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 fulfilled by FCS_CKM.4 is fulfilled. FCS_ITC.1/2 is not fulfilled, but justified: The key 2605 used here is managed in a similar way as other initialization data in the sense that it is imported during manufacturing (FMT_MTD.1/INI_ENA) and used only during personalisation and made unavailable afterwards ((FMT_MTD.1/INI_DIS). Therefore, no dedicated import policy is needed. FCS_COP.1.1/AES_MAC The TSF shall perform message authentication code in 2610 CMAC36 in accordance with a specified cryptographic algorithm Advanced Encryption Standard (AES) in CMAC mode37 and cryptographic key sizes 192 bit38 that meet the following: [NIST-FIPS-197] and [ISO-IEC-9797-1-2011]39 . Notes 2615 1. FCS_COP.1/AES_MAC is added to contents of [BSI-CC-PP-0059-2009-MA-02] (not iter- ated). 2. This SFR covers the cryptographic operation used during the Symmetric Authentication Mechanism with the Administrator Personalization Key. This key is imported by the administrator during the TOE initialization and is used to secure the TOE personalization. 2620 7.6.1.12 FCS_COP.1/CA_ENC (Cryptographic operation - Symmetric Encryption / Decryp- tion) EAC Hierarchical to No other components. Dependencies [FDP_ITC.1 Import of user data without security attributes, or 2625 FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction fulfilled by • FCS_CKM.1/DH_PACE_EC 2630 • FCS_CKM.1/DH_PACE_RSA • FCS_CKM.4.1 36 [assignment: list of cryptographic operations] 37 [assignment: cryptographic algorithm] 38 [assignment: cryptographic key sizes] 39 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 74 7 Security Requirements (ASE_REQ) FCS_COP.1.1/CA_ENC The TSF shall perform secure messaging - encryption and decryption40 in accordance with a specified cryptographic algorithm AES in CBC mode41 and cryptographic key sizes using AES with 128, 192, 256 bits42 2635 that meet the following: (1) (for CBC:) [NIST-800-38A-2001], chapter 6.2 THE CIPHER BLOCK CHAIN- ING MODE. (2) (for AES:) U.S. Department of Commerce, National Institute of Stan- dards and Technology, Information Technology Laboratory (ITL), Ad- 2640 vanced Encryption Standard (AES), FIPS PUB 197.43 Notes 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the underlying chip SLC52GDA448*. 2645 2. This TOE uses the AES provided by the underlying chip SLC52GDA448*. 3. For the “Advanced Encryption Standard (AES)” see [Infineon-ST-SLC52-H13], 7.1.2.2.2 AES Operation. 4. This SFR requires the TOE to implement the cryptographic primitives (AES) for secure messaging with encryption of the transmitted data. The keys are agreed between the 2650 TOE and the terminal as part of the Chip Authentication Protocol Version 1 according to the FCS_CKM.1/CA_EC (and FCS_CKM.1/CA_RSA). 7.6.1.13 FCS_COP.1/CA_MAC (Cryptographic operation - MAC) EAC Hierarchical to No other components. Dependencies 2655 [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 2660 authentication code44 in accordance with a specified cryptographic algorithm CMAC45 and cryptographic key sizes using AES with 128, 192, 256 bits46 that meet the following: (1) (for CMAC:) [ISO-IEC-9797-1-2011], algorithm 5 and padding method 2. (2) (for AES:) U.S. Department of Commerce, National Institute of Stan- 2665 dards and Technology, Information Technology Laboratory (ITL), Ad- vanced Encryption Standard (AES), [NIST-FIPS-197].47 Notes 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the underlying 2670 chip SLC52GDA448*. 40 [assignment: list of cryptographic operations] 41 [assignment: cryptographic algorithm] 42 [assignment: cryptographic key sizes] 43 [assignment: list of standards] 44 [assignment: list of cryptographic operations] 45 [assignment: cryptographic algorithm] 46 [assignment: cryptographic key sizes] 47 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 75 7 Security Requirements (ASE_REQ) 2. This TOE uses the AES provided by the underlying chip SLC52GDA448*. 3. For the “Advanced Encryption Standard (AES)” see [Infineon-ST-SLC52-H13], 7.1.2.2.2 AES Operation. 4. This SFR requires the TOE to implement the cryptographic primitive for secure messaging 2675 with encryption and message authentication code over the transmitted data. The key is agreed between the TSF by PACE Protocol according to the FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA. Furthermore the SFR is used for authentication attempts of a terminal as Personalization Agent by means of the authentication mechanism. 7.6.1.14 FCS_COP.1/PACE_ENC (Cryptographic operation - Encryption / Decryption AES ) 2680 PACE 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] 2685 FCS_CKM.4 Cryptographic key destruction fulfilled by • FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA • FCS_CKM.4 FCS_COP.1.1/PACE_ENC The TSF shall perform secure messaging - encryption and 2690 decryption48 in accordance with a specified cryptographic algorithm AES in CBC mode49 and cryptographic key sizes 128, 192, 256 (for AES)50 bit that meet the following: compliant to [ICAO-TR-110]51 . 2695 Notes 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the underlying chip SLC52GDA448*. 2. This SFR requires the TOE to implement the cryptographic primitive AES for secure messaging with encryption of transmitted data and encrypting the nonce in the first 2700 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_EC (PACE-K.Enc) and FCS_CKM.1/DH_PACE_RSA. 48 [assignment: list of cryptographic operations] 49 [assignment: cryptographic algorithm] 50 [assignment: cryptographic key sizes] 51 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 76 7 Security Requirements (ASE_REQ) 7.6.1.15 FCS_COP.1/PACE_MAC (Cryptographic operation - MAC) PACE Hierarchical to No other components. 2705 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 2710 fulfilled by • FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA • FCS_CKM.4 FCS_COP.1.1/PACE_MAC The TSF shall perform secure messaging - message authentication code52 in accordance with a specified cryptographic algorithm 2715 (AES) CMAC53 and cryptographic key sizes 128, 192, 256 (for AES)54 bit that meet the following: compliant to [ICAO-TR-110]55 . Notes 2720 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the underlying chip SLC52GDA448*. 2. 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 according 2725 to the FCS_CKM.1/DH_PACE_EC (PACE-K.MAC) and FCS_CKM.1/DH_PACE_RSA. 7.6.1.16 FCS_COP.1/SIG_VER_EC (Cryptographic operation - Signature verification by travel document with EC) EAC Hierarchical to No other components. Dependencies 2730 [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_EC The TSF shall perform digital signature verification56 in 2735 accordance with a specified cryptographic algorithm ECDSA57 and crypto- graphic key sizes 256, 384, 512, and 521 bits58 that meet the following: (1) According to section 7.4.1 in [ANSI-X9.62] Not implemented is step b) and c) thereof. The output of step c) has to be provided as input to our function by the caller. Deviation of step d): Beside noted calculation, 2740 our algorithm adds a random multiple of BasepointerOrder n to the calculated values u1 and u2. 52 [assignment: list of cryptographic operations] 53 [assignment: cryptographic algorithm] 54 [assignment: cryptographic key sizes] 55 [assignment: list of standards] 56 [assignment: list of cryptographic operations] 57 [assignment: cryptographic algorithm] 58 [assignment: cryptographic key sizes] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 77 7 Security Requirements (ASE_REQ) (2) According to sections 6.4.4 in [ISO-IEC-14888-3]. Not supported are sec- tions 6.4.4.2 and 6.4.4.3: The hash-code H of the message has to be pro- vided by the caller as input to the function. 2745 (3) According to section 7.2.8 ECVP-DSA in [IEEE-1363]. using curves (4) see section Elliptic curves used.59 Notes 2750 1. Due to the fact that there is a SFR added to this ST using RSA for signature verification the SFR “FCS_COP.1/SIG_VER” of [BSI-CC-PP-0056-V2-2012-MA-02] is renamed to “FCS_ COP.1/SIG_VER_EC” for mnemonic reason. 2. This TOE uses the ECDSA (Signature Verification) provided by the underlying chip SLC52GDA448*. 2755 3. The signature verification is used to verify the card verifiable certificates and the authen- tication attempt of the terminal creating a digital signature for the TOE challenge. 4. The TOE implements ECDSA (and RSA cf. FCS_COP.1/SIG_VER_RSA) for the Terminal Authentication Protocol v.1 (cf. [BSI-TR-03110-3-V221] A.6.4.Terminal Authentication with ECDSA). 2760 5. See also section Hash functions implemented. 6. If a configuration of the TOE uses FCS_COP.1/SIG_VER_RSA, it must not use this SFR additionally. 7.6.1.17 FCS_COP.1/SIG_VER_RSA (Cryptographic operation - Signature verification by travel document with RSA) 2765 EAC 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] 2770 FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/SIG_VER_RSA The TSF shall perform digital signature verification60 in accordance with a specified cryptographic algorithm RSA61 and cryptographic key sizes 2048 and 3072 bits62 (cf. [BSI-TR-03110-3-V221] section A.7.3.2.Public Key Format) that meet the following: 2775 (1) According to section 5.2.2 RSAVP1 in [RSA-PKCS1-v2.2] (2) Padding according to RSASSA-PSS or (3) Padding according to RSASSA-PKCS1-v1_5.63 Notes 2780 1. SFR FCS_COP.1/SIG_VER_RSA is iterated from PP SFR FCS_COP.1/SIG_VER_EC (“FCS_ COP.1/SIG_VER”). 59 [assignment: list of standards] 60 [assignment: list of cryptographic operations] 61 [assignment: cryptographic algorithm] 62 [assignment: cryptographic key sizes] 63 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 78 7 Security Requirements (ASE_REQ) 2. This TOE uses the RSA (Signature Verification) provided by the underlying chip SLC52GDA448*. 3. For the “digital signature verification” see [Infineon-ST-SLC52-H13], 7.1.2.5.1 Rivest-Shamir- 2785 Adleman (RSA) operation, section “Signature Verification:”. 4. The signature verification is used to verify the card verifiable certificates and the authen- tication attempt of the terminal creating a digital signature for the TOE challenge 5. See also section Hash functions implemented. 6. The bit lengths for TA are taken over from [BSI-TR-03110-3-V221] section A.7.3.2. Public 2790 Key Format. 7. The TOE implements RSA (and ECDSA cf. FCS_COP.1/SIG_VER_EC) for the Terminal Au- thentication Protocol v.1 (cf. [BSI-TR-03110-3-V221] section A.6.3.Terminal Authentication with RSA). 8. If a configuration of the TOE uses FCS_COP.1/SIG_VER_EC, it must not use this SFR 2795 additionally. 7.6.1.18 FCS_COP.1/AA_SGEN_EC (Cryptographic operation - Signature generation for AA with EC) EAC Hierarchical to No other components. Dependencies 2800 [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/AA_SGEN_EC The TSF shall perform digital signature generation64 2805 in accordance with a specified cryptographic algorithm ECDSA65 and crypto- graphic key sizes 256, 384, 512, and 521 bits66 that meet the following: Signature Generation: 1. According to section 7.3 in [ANSI-X9.62]. • Step d) and e) not supported. 2810 • The output of step e) has to be provided as input to our function by the caller. • Deviation of step c) and f): – The jumps to step a) were substituted by a return of the function with an error code, the jumps are emulated by another call to our 2815 function. 2. According to section 6.4.3 in [ISO-IEC-14888-3]. • 6.4.3.3 not supported. • 6.4.3.5 not supported: – The hash-code H of the message has to be provided by the caller 2820 as input to our function. • 6.4.3.7 not supported. 64 [assignment: list of cryptographic operations] 65 [assignment: cryptographic algorithm] 66 [assignment: cryptographic key sizes] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 79 7 Security Requirements (ASE_REQ) • 6.4.3.8 not supported. 3. According to section 7.2.7 in [IEEE-1363]: • Deviation of step (3) and (4): 2825 – The jump to step 1, were substituted by a return of the function with an error code, the jumps are emulated by another call to our function. using curves 4. see section Elliptic curves used.67 2830 Notes 1. SFR FCS_COP.1/AA_SGEN_EC is added to contents of PPs [BSI-CC-PP-0056-V2-2012-MA- 02] and [BSI-CC-PP-0068-V2-2011-MA-01]. 2. See also section Hash functions implemented. 2835 3. The signature generation is used to perform Active Authentication. 4. The TOE implements ECDSA for the Active Authentication Protocol (cf. [BSI-TR-03110-3- V221] section 1.2 Active Authentication). 7.6.1.19 FCS_RNG.1 (Random number generation) Hierarchical to No other components. 2840 Dependencies No dependencies. FCS_RNG.1.1 The TSF shall provide a hybrid deterministic68 random number gen- erator that implements: (DRG.4.1) The internal state of the RNG shall use PTRNG of class PTG.2 as random source. 2845 (DRG.4.2) The RNG provides forward secrecy. (DRG.4.3) The RNG provides backward secrecy even if the current internal state is known. (DRG.4.4) The RNG provides enhanced forward secrecy for every call. (DRG.4.5) The internal state of the RNG is seeded by a PTRNG of class PTG.2 2850 according to [BSI-AIS31-V3].69 FCS_RNG.1.2 The TSF shall provide random numbers that meet: (DRG.4.6) The RNG generates output for which 212 strings of bit length 128 are mutually different with probability 1-2-105 (acc. to [NIST-SP800-90A] C.3). (DRG.4.7) Statistical test suites cannot practically distinguish the random 2855 numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A as defined in [BSI-AIS2031-RNG-CLASSES-V2].70 Notes 67 [assignment: list of standards] 68 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] 69 [assignment: list of security capabilities] 70 [assignment: a defined quality metric] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 80 7 Security Requirements (ASE_REQ) 1. This SFR has been adapted from [BSI-CC-PP-0084-2014] (FCS_RNG.1) to meet [BSI- 2860 AIS2031-RNG-CLASSES-V2]. It correlates with the SFR ’FCS_RND.1’ from [BSI-CC-PP-0068- V2-2011-MA-01]. 2. For the “random numbers generation Class PTG.2 according to [BSI-AIS31-V3]” see [Infineon-ST-SLC52-H13] “7.1.2.1.1 True Random Number Generation, meeting AIS31 PTG.2”. 3. Entropy source uses PTG.2 of the hardware as noise source and Block_Cipher_df as 2865 specified in [NIST-SP800-90A] using the AES block cipher as a conditioning component to implement CTR_DRBG as specified in [NIST-SP800-90A]. 4. This SFR requires the TOE to generate random numbers (random nonce) used for the authentication protocol (PACE) as required by FIA_UAU.4/PACE (1). 5. This SFR requires the TOE to generate random numbers (random nonce) used also for 2870 Terminal Authentication Protocol v.1 as required by FIA_UAU.4/PACE (3). 7.6.2 Class FIA Identification and Authentication Table 7.5 provides an overview on the authentication mechanisms used Table 7.5: Overview on authentication SFR Name SFR for the TOE Authentication Mechanism for Per- sonalization Agents FIA_UAU.4/PACE Chip Authentication Protocol v.1 FIA_API.1/CA FIA_UAU.5/PACE FIA_UAU.6/EAC Active Authentication Protocol FIA_UAU.5/PACE FIA_API.1/AA Terminal Authentication Protocol v.1 FIA_UAU.5/PACE PACE protocol73 FIA_UAU.1/PACE FIA_UAU.5/PACE FIA_UAU.6/PACE74 FIA_AFL.1/PACE Passive Authentication FIA_UAU.5/PACE 2875 Note the Chip Authentication Protocol Version 1 as used by this TOE includes • the asymmetric key agreement to establish symmetric secure messaging keys between the TOE and the terminal based on the Chip Authentication Public Key and the Terminal Public Key used later in the Terminal Authentication Protocol Version 1, • the check whether the TOE is able to generate the correct message authentication code 2880 with the expected key for any message received by the terminal. The Chip Authentication Protocol v.1 may be used independent of the Terminal Authentication Protocol v.1. But if the Terminal Authentication Protocol v.1 is used the terminal shall use the same public key as presented during the Chip Authentication Protocol v.1. If PACE Chip Authentication Mapping is used,the secure messaging keys established by the 2885 PACE protocol are sustained. A subsequent Terminal Authentication Protocol v.1 uses the PACE-CAM public key verified during the PACE protocol. 73 Only listed for information purposes 74 not listed in PP [BSI-CC-PP-0056-V2-2012-MA-02] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 81 7 Security Requirements (ASE_REQ) 7.6.2.1 FIA_UID.1/PACE (Timing of identification) PACE EAC Hierarchical to No other components. Dependencies No dependencies. 2890 FIA_UID.1.1/PACE The TSF shall allow 1. to establish the communication channel 2. carrying out the PACE Protocol according to [ICAO-TR-110] 3. to read the Initialization Data if it is not disabled by TSF according to FMT_ MTD.1/INI_DIS 2895 4. to carry out the Chip Authentication Protocol v.1 according to [BSI-TR- 03110-1-V220] 5. to carry out the Terminal Authentication Protocol v.1 according to [BSI-TR- 03110-1-V220]75 6. to carry out the Active Authentication Protocol according to [ICAO-TR- 2900 110] 7. to carry out the PACE Chip Authentication Mapping protocol according to [ICAO-TR-110] 8. to run self tests according to FPT_TST.176 on behalf of the user to be performed before the user is identified. 2905 FIA_UID.1.2/PACE The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Notes 1. The SFR FIA_UID.1/PACE in the current ST covers the definition in PACE PP [BSI-CC-PP- 2910 0068-V2-2011-MA-01] and extends it by EAC aspect 4. This extension does not conflict with the strict conformance to PACE PP. 2. In the Phase 2 “Manufacturing of the TOE” the Manufacturer is the only user role known to the TOE which writes the Initialization Data and/or Pre-personalisation Data in the audit records of the IC. The travel document manufacturer may create the user role 2915 Personalisation Agent for transition from Phase 2 to Phase 3 “Personalisation of the travel document”. The users in role Personalisation Agent identify themselves by means of selecting the authentication key. After personalisation in the Phase 3 the PACE domain parameters, the Chip Authentication data and Terminal Authentication Reference Data are written into the TOE. The Inspection System is identified as default user after power 2920 up or reset of the TOE i.e. the TOE will run the PACE protocol, to gain access to the Chip Authentication Reference Data and to run the Chip Authentication Protocol Version 1. After successful authentication of the chip the terminal may identify itself as (i) Extended Inspection System by selection of the templates for the Terminal Authentication Protocol Version 1 or (ii) if necessary and available by authentication as Personalisation Agent 2925 (using the Personalisation Agent Key). 3. User identified after a successfully performed PACE protocol is a terminal. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted revealable; i.e. it is either the travel document holder itself or an authorised other person or device (Basic Inspection System with PACE). 2930 4. In the life-cycle phase “Manufacturing” the Manufacturer is the only user role known to the TOE. The Manufacturer writes the Initialisation Data and/or Pre-personalisation Data in the audit records of the IC.Please note that a Personalisation Agent acts on 75 [assignment: list of TSF-mediated actions] 76 [assignment: list of TSF-mediated actions] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 82 7 Security Requirements (ASE_REQ) behalf of the travel document Issuer under his and CSCA and DS policies. Hence, they define authentication procedure(s) for Personalisation Agents. The TOE must 2935 functionally support these authentication procedures being subject to evaluation within the assurance components ALC_DEL.1 and AGD_PRE.1. The TOE assumes the user role “Personalisation Agent”, when a terminal proves the respective Terminal Authorisation Level as defined by the related policy (policies). 5. See FIA_AFL.1/PACE how skimming is prevented by the TOE. 2940 6. The notes above stem from the protection profile which uses the generic terminology of [BSI-CC-PP-0084-2014]. For a mapping of the concrete TOE life-cycle to the generic model refer to section Life Cycle Phases Mapping. 7.6.2.2 FIA_UID.1 (Timing of identification) SSCD Hierarchical to No other components. 2945 Dependencies No dependencies. FIA_UID.1.1 The TSF shall allow: 1. self-test according to FPT_TST.1;77 2. carrying out the PACE protocol according to [ICAO-TR-110] 3. performing of the Symmetric Authentication Mechanism78 2950 on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Notes 2955 1. This SFR has been amended with item (2) from [BSI-CC-PP-0068-V2-2011-MA-01] and with (3) for authenticating the administrator before TOE personalization. 2. User identified after a successfully performed PACE protocol is a PACE authenticated PACE Terminal. Please note that CAN does not effectively represent a secret (but other PACE passwords do so), but is restricted-revealable; i.e. it is either the legitimate user 2960 itself or an authorized other person or device (PACE Terminal). 3. After successful PACE authentication using the PIN.ADMIN R.Admin or the IT entity (CGA or SSCD Issuing Application) on its behalf is identified. 7.6.2.3 FIA_UAU.1/PACE (Timing of authentication) PACE EAC Hierarchical to No other components. 2965 Dependencies FIA_UID.1 Timing of identification. FIA_UAU.1.1/PACE The TSF shall allow 1. to establish the communication channel, 2. carrying out the PACE Protocol according to [ICAO-TR-110]79 , 3. to read the Initialization Data if it is not disabled by TSF according to FMT_ 2970 MTD.1/INI_DIS, 77 [assignment: list of TSF mediated actions] 78 [assignment: list of additional TSF mediated actions] 79 travel document identifies itself within the PACE protocol by selection of the authentication key ephem-PK.PICC- PACE Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 83 7 Security Requirements (ASE_REQ) 4. to identify themselves by selection of the authentication key 5. to carry out the Chip Authentication Protocol Version 1 according to [BSI- TR-03110-1-V220] 6. to carry out the Terminal Authentication Protocol Version 1 according to 2975 [BSI-TR-03110-1-V220]80 7. to carry out the Active Authentication Protocol according to [ICAO-TR- 110] 8. to carry out the PACE Chip Authentication Mapping protocol according to [ICAO-TR-110] 2980 9. to run self tests according to FPT_TST.181 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/PACE The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 2985 Notes 1. The SFR FIA_UID.1/PACE in the current ST covers the definition in PACE PP [BSI-CC-PP- 0068-V2-2011-MA-01] and extends it by EAC aspect 5. This extension does not conflict with the strict conformance to PACE PP. 2. The user authenticated after a successfully performed PACE protocol is a terminal. Please 2990 note that neither CAN nor MRZ effectively represent secrets, but are restricted revealable; i.e. it is either the travel document holder itself or an authorized other person or device (BIS-PACE). If PACE was successfully performed, secure messaging is started using the derived session keys (PACE-K.MAC, PACE-K.Enc), cf. FTP_ITC.1/PACE. 3. See FIA_AFL.1/PACE how skimming is prevented by the TOE. 2995 7.6.2.4 FIA_UAU.1 (Timing of authentication) SSCD 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; 3000 2. identification of the user by means of TSF required by FIA_UID.1;82 3. establishing a trusted channel between the CGA and the TOE by means of TSF required by FTP_ITC.1/SVD, CGA 4. establishing a trusted channel between the HID and the TOE by means of TSF required by FTP_ITC.1/VAD, SCA 3005 5. carrying out the PACE protocol according to [ICAO-TR-110] 6. performing of the Symmetric Authentication Mechanism83 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 3010 80 [assignment: list of TSF-mediated actions] 81 [assignment: list of TSF-mediated actions] 82 [assignment: list of TSF mediated actions] 83 [assignment: list of additional TSF mediated actions] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 84 7 Security Requirements (ASE_REQ) Notes 1. This SFR has been amended with item (5) from [BSI-CC-PP-0068-V2-2011-MA-01] and with item (6) for authenticating the administrator before TOE personalization. 2. Item (3) of this SFR only applies for the Life Cycle Phase “Usage/Operational” as the TOE 3015 provides a communication channel to the CGA (via trusted channel) only in the Life Cycle Phase “Usage/Operational”. 3. The user authenticated after a successfully performed PACE protocol is a PACE authen- ticated PACE Terminal. Please note that CAN does not effectively represent a secret (but other PACE passwords do so), but are restricted-revealable; i.e. it is either the legitimate 3020 user itself or an authorized other person or device (PACE Terminal). 4. After successful PACE authentication using the PIN.ADMIN R.Admin or the IT entity (CGA or SSCD Issuing Application) on its behalf is authenticated. 7.6.2.5 FIA_UAU.4/PACE (Single-use authentication mechanisms - Single-use authentica- tion of the Terminal by the TOE) 3025 PACE EAC Hierarchical to No other components. Dependencies No dependencies FIA_UAU.4.1/PACE The TSF shall prevent reuse of authentication data related to 1. PACE Protocol according to [ICAO-TR-110] 2. Authentication Mechanism based on AES84 3030 3. Terminal Authentication Protocol v.1 according to [BSI-TR-03110-1-V220].85 Notes 1. The SFR FIA_UAU.4.1/PACE in the current ST covers the definition in PACE PP [BSI-CC-PP- 0068-V2-2011-MA-01] and extends it by the EAC aspect 3. This extension does not conflict 3035 with the strict conformance to PACE PP. The generation of random numbers (random nonce) used for the authentication protocol (PACE) and Terminal Authentication as required by FIA_UAU.4/PACE is required by FCS_RNG.1 from [BSI-CC-PP-0068-V2-2011- MA-01]. 2. The authentication mechanisms uses a challenge freshly and randomly generated by the 3040 TOE to prevent reuse of a response generated by a terminal in a successful authentication attempt. 3. Authentication data related to PACE Protocol according to [ICAO-TR-110] include au- thentication data related to PACE Chip Authentication Mapping. 84 [selection: Triple- DES, AES or other approved algorithms] 85 [assignment: identified authentication mechanism(s)] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 85 7 Security Requirements (ASE_REQ) 7.6.2.6 FIA_UAU.5/PACE (Multiple authentication mechanisms) 3045 PACE EAC Hierarchical to No other components. Dependencies No dependencies. FIA_UAU.5.1/PACE The TSF shall provide 1. PACE Protocol according to [ICAO-TR-110] 2. Passive Authentication according to [ICAO-9303-2015], part 11, section 5.1 3050 3. Secure messaging in MAC-ENC mode according to [ICAO-TR-110] 4. Symmetric Authentication Mechanism based on AES86 5. Terminal Authentication Protocol v.1 according to [BSI-TR-03110-1-V220]87 6. Active Authentication according to [ICAO-9303-2015], part 11 section 6.188 to support user authentication. 3055 FIA_UAU.5.2/PACE The TSF shall authenticate any user’s claimed identity accord- ing 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 3060 PACE protocol. 2. The TOE accepts the authentication attempt as Personalization Agent by the Authentication Mechanism with Personalization Agent Key(s)89 . 3. After run of the Chip Authentication Protocol Version 1 the TOE accepts only received commands with correct message authentication code sent 3065 by means of secure messaging with key agreed with the terminal by means of the Chip Authentication Mechanism v1. 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 3070 messaging established by the Chip Authentication Mechanism v.1.90 5. If PACE Chip Authentication Mapping has been performed instead of Chip Authentication Protocol Version 1 the TOE accepts the authenti- cation attempt by means of the Terminal Authentication Protocol v.1 only if the terminal uses the public key presented during the PACE Chip 3075 Authentication Mapping and the secure messaging established by the PACE Protocol.91 Notes 1. The SFR FIA_UAU.5.1/PACE in the current ST covers the definition in PACE PP [BSI-CC- 3080 PP-0068-V2-2011-MA-01] and extends it by EAC aspects 4), 5), and 6). The SFR FIA_ UAU.5.2/PACE in the current ST covers the definition in PACE PP [BSI-CC-PP-0068-V2- 2011-MA-01] and extends it by EAC aspects 2), 3), 4) and 5). These extensions do not conflict with the strict conformance to PACE PP. 86 [selection: Triple-DES, AES or other approved algorithms] 87 [assignment: list of multiple authentication mechanisms] 88 REFINEMENT 89 [selection: the Authentication Mechanism with Personalization Agent Key(s)] 90 [assignment: rules describing how the multiple authentication mechanisms provide authentication] 91 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 86 7 Security Requirements (ASE_REQ) 2. The Active Authentication has been added to the authentication mechanisms to cover 3085 it additionally in the evaluation. Adding new mechanisms does not impact the security claims of the Protection Profile. 7.6.2.7 FIA_UAU.6/EAC (Re-authenticating - Re-authenticating of Terminal by the TOE) EAC Hierarchical to No other components. Dependencies No dependencies. 3090 FIA_UAU.6.1/EAC The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authentication Protocol Version 1 shall be verified as being sent by the Inspection System.92 Note 3095 1. The Password Authenticated Connection Establishment and the Chip Authentication Protocol specified in [ICAO-9303-2015], part 11, section 8, include secure messaging for all commands exchanged after successful authentication of the Inspection System. The TOE checks by secure messaging in MAC_ENC mode each command based on a corre- sponding MAC algorithm whether it was sent by the successfully authenticated terminal 3100 (see FCS_COP.1/CA_MAC for further details). The TOE does not execute any command with incorrect message authentication code. Therefore the TOE re-authenticates the user for each received command and accepts only those commands received from the previously authenticated user. 7.6.2.8 FIA_UAU.6/PACE (Re-authenticating of Terminal by the TOE) 3105 PACE Hierarchical to No other components. Dependencies No dependencies. FIA_UAU.6.1/PACE The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the PACE protocol shall be verified as being sent by the PACE terminal.93 3110 Notes 1. This SFR has been adapted from [BSI-CC-PP-0068-V2-2011-MA-01]. 2. The PACE protocol specified in [ICAO-TR-110] starts secure messaging used for all com- mands exchanged after successful PACE authentication. The TOE checks each command 3115 by secure messaging in encrypt-then authenticate mode based on CMAC, whether it was sent by the successfully authenticated terminal (see FCS_COP.1/PACE_MAC for further details). The TOE does not execute any command with incorrect message authenti- cation code. Therefore, the TOE re-authenticates the terminal connected, if a secure messaging error occurred, and accepts only those commands received from the initially 3120 authenticated terminal. 3. The SFR FIA_UAU.6/PACE also includes PACE Chip Authentication Mapping. 92 [assignment: list of conditions under which re-authentication is required] 93 [assignment: list of conditions under which re-authentication is required] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 87 7 Security Requirements (ASE_REQ) 7.6.2.9 FIA_UAU.6/CA (Re-authenticating – Re-authenticating of Terminal by the TOE) CGA SCA Hierarchical to No other components. Dependencies No dependencies. 3125 FIA_UAU.6.1/CA The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authentication Protocol Version 1 shall be verified as being sent by the inspection system94 or the R.Admin or the IT entity (CGA or SSCD Issuing Application) on its behalf.95 3130 Notes 1. This SFR has been adapted from the SFR FIA_UAU.6/EAC of [BSI-CC-PP-0056-V2-2012- MA-02]. 2. The Password Authenticated Connection Establishment and the Chip Authentication 3135 Protocol specified in [ICAO-9303-2015] include secure messaging for all commands exchanged after successful authentication of R.Admin or the IT entity (CGA or SSCD Issuing Application) on its behalf. The TOE checks by secure messaging in MAC_ENC mode each command based on a corresponding MAC algorithm whether it was sent by the successfully authenticated terminal (see FCS_COP.1/CA_MAC for further details). 3140 The TOE does not execute any command with incorrect message authentication code. Therefore the TOE re-authenticates the user for each received command and accepts only those commands received from the previously authenticated user. 7.6.2.10 FIA_UAU.6/Signature_Creation (Re-authenticating for Signature Creation) Hierarchical to No other components. 3145 Dependencies No dependencies. FIA_UAU.6.1/Signature_Creation The TSF shall re-authenticate the user under the conditions 1. Single signature S.Sigy before every single DTBS/R signature. 2. Limited Mass signature S.Sigy before next signature after card reset 3150 or after Application QES was left or otherwise before (N+1)-th DTBS/R signature in a row when limit for consecutive signatures is N. 3. Unlimited Mass signature S.Sigy before next signature after card reset or after Application QES was left96 . 3155 Note 1. This SFR has been added to contents of PP [BSI-CC-PP-0059-2009-MA-02] (not iterated). 94 [assignment: list of conditions under which re-authentication is required] 95 REFINEMENT, see associated note 2 96 [assignment: list of conditions under which re-authentication is required] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 88 7 Security Requirements (ASE_REQ) 7.6.2.11 FIA_API.1/CA (Authentication Proof of Identity by Chip Authentication) EAC Hierarchical to No other components. Dependencies No dependencies. 3160 FIA_API.1.1/CA The TSF shall provide a Chip Authentication Protocol Version 1 according to [BSI-TR-03110-1-V220]97 to prove the identity of the TOE98 . Notes 1. Due to the fact that there is a SFR added to this ST using AA for Authentication Proof 3165 of Identity the SFR “FIA_API.1” of [BSI-CC-PP-0056-V2-2012-MA-02] is renamed to “FIA_ API.1/CA” for mnemonic reason. 2. This SFR requires the TOE to implement the Chip Authentication Mechanism v.1 specified in [BSI-TR-03110-1-V220]. The TOE and the terminal generate a shared secret using the Diffie-Hellman Protocol (DH or EC-DH) and two session keys for secure messaging in 3170 ENC_MAC mode according to [ICAO-9303-2015]. The terminal verifies by means of secure messaging whether the travel document’s chip was able or not to run his protocol properly using its Chip Authentication Private Key corresponding to the Chip Authentication Key (EF.DG14). 7.6.2.12 FIA_API.1/AA (Authentication Proof of Identity by Active Authentication) 3175 Hierarchical to No other components. Dependencies No dependencies. FIA_API.1.1/AA The TSF shall provide a Active Authentication Protocol according to [ICAO-9303-2015] part 11, section 6.199 to prove the identity of the TOE100 . 3180 Notes 1. SFR FIA_API.1/AA is iterated from PP SFR FIA_API.1/CA (“FIA_API.1”). 2. This SFR requires the TOE to implement the Active Authentication Mechanism specified in [ICAO-9303-2015], part 11, section 6.1. The TOE computes a signature over a nonce received from the terminal, sends the signature to the terminal and the terminal verifies 3185 the signature. 7.6.2.13 FIA_AFL.1/PACE (Authentication failure handling - PACE authentication using non-blocking authorization data) PACE Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE 3190 FIA_AFL.1.1/PACE The TSF shall detect when 1101 unsuccessful authentication at- tempt occurs related to authentication attempts using the PACE password as shared password.102 97 [assignment: authentication mechanism] 98 [assignment: authorized user or role] 99 [assignment: authentication mechanism] 100 [assignment: authorized user or role] 101 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assign- ment: range of acceptable values]] 102 [assignment: list of authentication events] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 89 7 Security Requirements (ASE_REQ) FIA_AFL.1.2/PACE When the defined number of unsuccessful authentication at- tempts has been met103 , the TSF shall delay the next authentication attempt 3195 at least 6 seconds.104 Notes 1. With a delay at least 6 seconds a brute force attack lasts in the average more than 30 days even if the password consist only of 6 digits (e.g. the CAN might be so long and 3200 consists of digits only). 2. The delay applies also when a new session is restarted. 3. The MRZ is longer than 6 signs and consists of alpha numerical characters. 7.6.2.14 FIA_AFL.1/RAD (Authentication failure handling – for Signatory PIN) SSCD Hierarchical to No other components. 3205 Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1/RAD The TSF shall detect when an administrator configurable posi- tive integer within 3 up to floor(MINLEN/2) (see note 3. below)105 unsuccess- ful authentication attempts occur related to consecutive failed authentication attempts106 . 3210 FIA_AFL.1.2/RAD When the defined number of unsuccessful authentication at- tempts has been met107 , the TSF shall block RAD108 [REFINEMENT] of the signatory PIN (PIN.QES). Notes 3215 1. FIA_AFL.1/RAD amounts to requirement “FIA_AFL.1”. 2. The minimal length of the signatory PIN has to be 6. 3. The Administrator configurable positive integer shall not exceed floor( MINLEN/2 ) where MINLEN denotes the minimal length of the signatory PIN (PIN.QES). 4. With “The TOE stores signatory reference authentication data to authenticate a user as 3220 its signatory”, see PP [BSI-CC-PP-0059-2009-MA-02], this requirement concerns the PIN of the Signatory (PIN.QES) only. 103 [selection: met ,surpassed] 104 [assignment: list of actions] 105 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assign- ment: range of acceptable values]] 106 [assignment: list of authentication events] 107 [selection: met ,surpassed] 108 [assignment: list of actions] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 90 7 Security Requirements (ASE_REQ) 7.6.2.15 FIA_AFL.1/Suspend_PIN (Authentication failure handling – Suspending PIN) Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication 3225 FIA_AFL.1.1/Suspend_PIN The TSF shall detect when 2109 unsuccessful authentica- tion attempts occur related to consecutive failed authentication attempts using the PACE password as the shared password for PACE110 . FIA_AFL.1.2/Suspend_PIN When the defined number of unsuccessful authentica- tion attempts has been met111 , the TSF shall suspend the reference value of 3230 the PACE password according to [BSI-TR-03110-2-V221].112 Note 1. FIA_AFL.1/Suspend_PIN has been adapted from [BSI-CC-PP-0086-2015], PIN has been changed to PACE password. 3235 7.6.2.16 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 1113 unsuccessful authentication attempts occur related to consecutive failed authentication attempts using 3240 the suspended114 PACE password as the shared password for PACE115 . FIA_AFL.1.2/Block_PIN When the defined number of unsuccessful authentication attempts has been met116 , the TSF shall block the reference value of the PACE password according to [BSI-TR-03110-2-V221]117 . 3245 Note 1. FIA_AFL.1/Block_PIN has been adapted from [BSI-CC-PP-0086-2015], PIN has been changed to PACE password. 109 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assign- ment: range of acceptable values]] 110 [assignment: list of authentication events] 111 [selection: met , surpassed] 112 [assignment: list of actions] 113 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assign- ment: range of acceptable values]] 114 as required by FIA_AFL.1/Suspend_PIN 115 [assignment: list of authentication events] 116 [selection: met , surpassed] 117 [assignment: list of actions] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 91 7 Security Requirements (ASE_REQ) 7.6.2.17 FIA_AFL.1/AuthAdmin (Authentication failure handling – of administrator for per- sonalization) 3250 Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1/AuthAdmin The TSF shall detect when 5118 unsuccessful authentica- tion attempts occur related to consecutive failed authentication attempts119 . FIA_AFL.1.2/AuthAdmin When the defined number of unsuccessful authentica- 3255 tion attempts has been met120 , the TSF shall delay the next authentication attempt at least 6 seconds121 . Notes 1. FIA_AFL.1/AuthAdmin is added to contents of [BSI-CC-PP-0059-2009-MA-02] (not iter- 3260 ated). 2. This SFR concerns the authentication of the administrator for personalization of the TOE using the Symmetric Authentication Mechanism with Administrator Personalization Key. 7.6.2.18 FIA_API.1 (Authentication proof of identity) 3265 CGA Hierarchical to No other components. Dependencies No dependencies. FIA_API.1.1 The TSF shall provide a Chip Authentication Protocol Version 1 ac- cording to [BSI-TR-03110-1-V220]122 to prove the identity of the SSCD123 . 3270 Notes 1. This SFR requires the TOE to implement the Chip Authentication Mechanism v.1 specified in [BSI-TR-03110-1-V220]. The TOE and the terminal generate a shared secret using the Diffie-Hellman Protocol (DH or EC-DH) and two session keys for secure messaging in ENC_MAC mode according to [ICAO-9303-2015]. 3275 2. The terminal verifies by means of secure messaging whether the travel document’s chip was able or not to run his protocol properly using its Chip Authentication Private Key corresponding to the Chip Authentication Key (EF.DG14). 118 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assign- ment: range of acceptable values]] 119 [assignment: list of authentication events] 120 [selection: met , surpassed] 121 [assignment: list of actions] 122 [assignment: authentication mechanism] 123 [assignment: authorized user or role] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 92 7 Security Requirements (ASE_REQ) 7.6.3 Class FDP User Data Protection The security attributes and related status for the subjects and objects are: 3280 Table 7.6: Subjects and security attributes for access control Subject or object 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 Note 1. This ST does not define security attributes for SVD. 3285 7.6.3.1 FDP_ACC.1/TRM (Subset access control) PACE EAC 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 SFP124 on terminals gaining access to the User Data and data stored in EF.SOD of the125 TOE126 . 3290 Notes 1. The SFR FDP_ACC.1.1/TRM in the current ST covers the definition in PACE PP [BSI-CC- PP-0068-V2-2011-MA-01] and extends it by data stored in EF.SOD of the logical travel document. This extension does not conflict with the strict conformance to PACE PP. 3295 2. This SFR has been adapted from [BSI-CC-PP-0068-V2-2011-MA-01]. The term travel document has been changed to TOE, because the access control policy also applies eSign applications. 7.6.3.2 FDP_ACF.1/TRM (Security attribute based access control) PACE EAC Hierarchical to No other components. 3300 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 SFP127 to objects based on the following: 3305 1. Subjects: a. Terminal, b. BIS-PACE c. Extended Inspection System 124 [assignment: access control SFP] 125 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 126 REFINEMENT, see note 2 below 127 [assignment: access control SFP] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 93 7 Security Requirements (ASE_REQ) 2. Objects: 3310 a. data in EF.DG1, EF.DG2 and EF.DG5 to EF.DG16, EF.SOD and EF.COM of the logical travel document, b. data in EF.DG3 of the logical travel document, c. data in EF.DG4 of the logical travel document, d. all TOE intrinsic secret cryptographic keys stored in the travel 3315 document128 e. data in EF.CardSecurity129 3. Security attributes: a. PACE Authentication130 b. Terminal Authentication Status131 3320 c. Terminal Authorization.132 FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: A BIS-PACE is allowed to read data objects from FDP_ACF.1.1/TRM according to [ICAO-TR-110] after a successful PACE authentication as required by FIA_ 3325 UAU.1/PACE.133 FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none.134 FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 3330 1. Any terminal being not authenticated as PACE authenticated BIS-PACE is not allowed to read, to write, to modify, to use any User Data stored on the travel document. 2. Terminals not using secure messaging are not allowed to read, to write, to modify, to use any data stored on the travel document. 3335 3. Any terminal being not successfully authenticated as Extended Inspection System with the Read access to DG 3 (Fingerprint) granted by the relative certificate holder authorization encoding is not allowed to read the data objects 2b) of FDP_ACF.1.1/TRM. 4. Any terminal being not successfully authenticated as Extended Inspection 3340 System with the Read access to DG 4 (Iris) granted by the relative certificate holder authorization encoding is not allowed to read the data objects 2c) of FDP_ACF.1.1/TRM. 5. Nobody is allowed to read the data objects 2d) of FDP_ACF.1.1/TRM. 6. Terminals authenticated as CVCA or as DV are not allowed to read data in 3345 the EF.DG3 and EF.DG4.135 Notes 128 e.g. Chip Authentication Version 1 and ephemeral keys 129 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 130 REFINEMENT access control to EF.CardSecurity is added to this SFR 131 REFINEMENT Terminal Authentication v.1, see also Table 7.1 and associated notes 132 REFINEMENT Authorization of the Terminal, , see also Table 7.2 and associated notes 133 [assignment: rules governing access among controlled subjects and controlled objects using controlled opera- tions on controlled objects] 134 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 135 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 94 7 Security Requirements (ASE_REQ) 1. The SFR FDP_ACF.1.1/TRM in the current ST covers the definition in PACE PP [BSI-CC- PP-0068-V2-2011-MA-01] and extends it by additional subjects and objects. The SFRs 3350 FDP_ACF.1.2/TRM and FDP_ACF.1.3/TRM in the current ST cover the definition in PACE PP [BSI-CC-PP-0068-V2-2011-MA-01]. The SFR FDP_ACF.1.4/TRM in the current ST covers the definition in PACE PP [BSI-CC-PP-0068-V2-2011-MA-01] and extends it by 3) to 6). These extensions do not conflict with the strict conformance to PACE PP. 2. The relative certificate holder authorization encoded in the CVC of the inspection system 3355 is defined in [BSI-TR-03110-1-V220]. The TOE verifies the certificate chain established by the Country Verifying Certification Authority, the Document Verifier Certificate and the Inspection System Certificate (cf. FMT_MTD.3). The Terminal Authorization is the intersection of the Certificate Holder Authorization in the certificates of the Country Verifying Certification Authority, the Document Verifier Certificate and the Inspection 3360 System Certificate in a valid certificate chain. 3. Please note that the Document Security Object (SOD) stored in EF.SOD (see [ICAO-9303- 2015]) does not belong to the user data, but to the TSF data. The Document Security Object can be read out by Inspection Systems using PACE, see [ICAO-TR-110]. 4. FDP_UCT.1/TRM and FDP_UIT.1/TRM require the protection of the User Data transmitted 3365 from the TOE to the terminal by secure messaging with encryption and message authen- tication codes after successful Chip Authentication Version 1 to the Inspection System. The Password Authenticated Connection Establishment, and the Chip Authentication Protocol v.1 establish different key sets to be used for secure messaging (each set of keys for the encryption and the message authentication key). 3370 5. Reading according to FDP_ACF.1.2/TRM includes for a TOE providing Active Authentica- tion the AA public key in EF.DG15. 6. EF.CardSecurity holds the public key needed for authenticating the SSCD during Chip Authentication Protocol Version 1. 7.6.3.3 FDP_RIP.1 (Subset residual information protection) 3375 PACE SSCD 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 from136 the following objects: 3380 1. Session Keys (immediately after closing related communication session), 2. the ephemeral private key ephem-SK:sub:PICC-PACE (by having generated a DH shared secret K)137 3. SCD138 3385 Notes 1. The SFR FDP_RIP.1.1 just merges the definitions in PP [BSI-CC-PP-0059-2009-MA-02] and [BSI-CC-PP-0068-V2-2011-MA-01] to fulfill both requirements and thereby keeping the strict conformance to the claimed PPs. 2. The TOE shall destroy any session keys in accordance with FCS_CKM.4 after 3390 (i) detection of an error in a received command by verification of the MAC and (ii) after successful run of the Chip Authentication Protocol v.1. 136 [selection: allocation of the resource to, deallocation of the resource from] 137 [assignment: list of objects] 138 [assignment: list of objects] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 95 7 Security Requirements (ASE_REQ) (iii) The TOE shall destroy the PACE Session Keys after generation of the Chip Authenti- cation Session Keys and changing the secure messaging to the Chip Authentication Session Keys. 3395 (iv) The TOE shall clear the memory area of any session keys before starting the com- munication 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 fulfilled by FCS_ CKM.1/CA. 3. The general formulation that all session keys shall be destroyed, compared to SFRs in the 3400 protection profiles which explicitly list session keys is intentional since the TOE supports different secure channel establishment protocols. The following data persistently stored by the TOE shall have the user data attribute “integrity checked persistent stored data”: 1. SCD; 3405 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”. 7.6.3.4 FDP_UCT.1/TRM (Basic data exchange confidentiality - MRTD) PACE Hierarchical to No other components. 3410 Dependencies [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] fulfilled by FTP_ITC.1/PACE [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] fulfilled by FDP_ACC.1/TRM 3415 FDP_UCT.1.1/TRM The TSF shall enforce the Access Control SFP139 to transmit and receive140 user data in a manner protected from unauthorized disclosure. 7.6.3.5 FDP_UIT.1/TRM (Data exchange integrity – Terminal) PACE Hierarchical to No other components. Dependencies 3420 [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] fulfilled by FDP_ACC.1/TRM 3425 FDP_UIT.1.1/TRM The TSF shall enforce the Access Control SFP141 to transmit and receive142 user data in a manner protected from modification, deletion, insertion and replay143 errors. FDP_UIT.1.2/TRM The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay144 has occurred. 3430 139 [assignment: access control SFP(s) and/or information flow control SFP(s)] 140 [selection: transmit, receive] 141 [assignment: access control SFP(s) and/or information flow control SFP(s)] 142 [selection: transmit, receive] 143 [selection: modification, deletion, insertion, replay] 144 [selection: modification, deletion, insertion, replay] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 96 7 Security Requirements (ASE_REQ) 7.6.3.6 FDP_ACC.1/SCD/SVD_Generation (Subset access control) SSCD Hierarchical to No other components. Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ SCD/SVD_Generation The TSF shall enforce the SCD/SVD_ Generation_SFP145 on: 3435 1. subjects: S.User, 2. objects: SCD, SVD, 3. operations: generation of SCD/SVD pair.146 7.6.3.7 FDP_ACF.1/SCD/SVD_Generation (Security attribute based access control) SSCD Hierarchical to No other components. 3440 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_SFP147 to objects based on the following: 3445 the user S.User is associated with the security attribute “SCD/SVD Management”.148 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: 3450 S.User with the security attribute “SCD/SVD Management” set to “authorized” is allowed to generate SCD/SVD pair.149 After issuing the TOE S.User is allowed to generate SCD/SVD pair only after successful Chip Authentication Protocol Version 1 following PACE authen- tication using the PIN.ADMIN as the shared password or after successful 3455 EAC with strong certificate following PACE authentication using any PACE password as the shared password.150 FDP_ACF.1.3/ SCD/SVD_Generation The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none151 FDP_ACF.1.4/ SCD/SVD_Generation The TSF shall explicitly deny access of subjects 3460 to objects based on the following additional rules: S.User with the security attribute “SCD/SVD Management” set to “not authorized” is not allowed to generate SCD/SVD pair.152 Notes 3465 145 [assignment: access control SFP] 146 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 147 [assignment: access control SFP] 148 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 149 [assignment: rules governing access among controlled subjects and controlled objects using controlled opera- tions on controlled objects] 150 REFINEMENT 151 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 152 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 97 7 Security Requirements (ASE_REQ) 1. The changes represent the need to secure communication between the SSCD Issuing Application and the TOE via trusted channel when generating SCD/SVD pair after issuing the TOE. 2. RSA key generation is only allowed to be performed in a trustworthy environment. 3. After the TOE is issued the TOE is in phase OPERATIONAL. 3470 7.6.3.8 FDP_ACC.1/SVD_Transfer (Subset access control) SSCD 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_SFP153 on: 1. subjects: S.User, 3475 2. objects: SVD, 3. operations: export.154 7.6.3.9 FDP_ACF.1/SVD_Transfer (Subset access control) SSCD Hierarchical to No other components. Dependencies 3480 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_SFP155 to ob- jects based on the following: 1. the S.User is associated with the security attribute Role; 3485 2. the SVD.156 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.Admin157 is allowed to export SVD.158 After issuing the TOE R.Admin is allowed to export SVD only after success- 3490 ful Chip Authentication Protocol Version 1 following PACE authentication using the PIN.ADMIN as the shared password or after successful EAC with strong certificate following PACE authentication using any PACE password as the shared password.159 FDP_ACF.1.3/ SVD_Transfer The TSF shall explicitly authorize access of subjects to 3495 objects based on the following additional rules: none160 . FDP_ACF.1.4/ SVD_Transfer The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none161 . 153 [assignment: access control SFP] 154 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 155 [assignment: access control SFP] 156 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 157 [selection: R.Admin, R.Sigy] 158 [assignment: rules governing access among controlled subjects and controlled objects using controlled opera- tions on controlled objects] 159 REFINEMENT 160 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 161 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 98 7 Security Requirements (ASE_REQ) Note 3500 1. The changes represent the need to secure communication between the CGA and the TOE via trusted channel when exporting the SVD in Life Cycle Phase “Usage/Operational”. 7.6.3.10 FDP_ACC.1/Signature_Creation (Subset access control) SSCD Hierarchical to No other components. Dependencies FDP_ACF.1 Security attribute based access control 3505 FDP_ACC.1.1/ Signature_Creation The TSF shall enforce the Signature_Creation_ SFP162 on: 1. subjects: S.User, 2. objects: DTBS/R, SCD, 3. operations: signature creation.163 3510 7.6.3.11 FDP_ACF.1/Signature_Creation (Security attribute based access control) SSCD Hierarchical to No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization 3515 FDP_ACF.1.1/ Signature_Creation The TSF shall enforce the Signature_Creation_ SFP164 to objects based on the following: 1. the user S.User is associated with the security attribute “Role”; and 2. the SCD with the security attribute “SCD Operational”165 FDP_ACF.1.2/ Signature_Creation The TSF shall enforce the following rules to de- 3520 termine 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”.166 R.Sigy is only allowed to create electronic signatures for DTBS/R with SCD 3525 only after successful PACE authentication using the PIN.CH or CAN as the shared password and successful authentication against RAD.167 FDP_ACF.1.3/ Signature_Creation The TSF shall explicitly authorize access of sub- jects to objects based on the following additional rules: none.168 FDP_ACF.1.4/ Signature_Creation The TSF shall explicitly deny access of subjects 3530 to objects based on the following additional rules: 162 [assignment: access control SFP] 163 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 164 [assignment: access control SFP] 165 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 166 [assignment: rules governing access among controlled subjects and controlled objects using controlled opera- tions on controlled objects] 167 REFINEMENT 168 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 99 7 Security Requirements (ASE_REQ) S.User is not allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “no”.169 Note 3535 1. The changes represent the need to secure communication between the SCA and the TOE via trusted channel for all communication interfaces for when creating electronic signatures for DTBS/R with SCD. 7.6.3.12 FDP_UIT.1/DTBS (Data exchange integrity – DTBS) SCA Hierarchical to No other components. 3540 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] 3545 FDP_UIT.1.1/DTBS The TSF shall enforce the Signature_Creation_SFP170 to receive171 user data in a manner protected from modification and insertion172 errors. FDP_UIT.1.2/DTBS The TSF shall be able to determine on receipt of user data, whether modification and insertion173 has occurred. 7.6.3.13 FDP_SDI.2/Persistent (Stored data integrity monitoring and action) 3550 SSCD 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 con- trolled by the TSF for integrity error174 on all objects, based on the following attributes: integrity checked stored data175 . 3555 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.176 169 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 170 [assignment: access control SFP(s) and/or information flow control SFP(s)] 171 [selection: transmit, receive] 172 [selection: modification, deletion, insertion, replay] 173 [selection: modification, deletion, insertion, replay] 174 [assignment: integrity errors] 175 [assignment: user data attributes] 176 [assignment: action to be taken] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 100 7 Security Requirements (ASE_REQ) 7.6.3.14 FDP_SDI.2/DTBS (Stored data integrity monitoring and action) SSCD Hierarchical to FDP_SDI.1 Stored data integrity monitoring. 3560 Dependencies No dependencies. FDP_SDI.2.1/DTBS The TSF shall monitor user data stored in containers controlled by the TSF for integrity error177 on all objects, based on the following attributes: integrity checked stored DTBS178 . FDP_SDI.2.2/DTBS Upon detection of a data integrity error, the TSF shall: 3565 1. prohibit the use of the altered data; 2. inform the S.Sigy about integrity error.179 Note 1. The integrity of TSF data like RAD shall be protected to ensure the effectiveness of the 3570 user authentication. This protection is a specific aspect of the security architecture (cf. ADV_ARC.1). 7.6.3.15 FDP_DAU.2/SVD (Data Authentication with Identity of Guarantor) CGA Hierarchical to FDP_DAU.1 Basic Data Authentication Dependencies FIA_UID.1 Timing of identification 3575 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 SVD180 . FDP_DAU.2.2/SVD The TSF shall provide CGA with the ability to verify evidence of the validity of the indicated information and the identity of the user that generated the evidence. 3580 Note 1. This SFR only applies for the Life Cycle Phase “Usage/Operational” as the TOE provides a communication channel to the CGA (via trusted channel) only in the Life Cycle Phase “Usage/Operational”. 3585 7.6.4 Class FTP Trusted Path/Channels 7.6.4.1 FTP_ITC.1/PACE (Inter-TSF trusted channel after PACE) PACE Hierarchical to No other components. Dependencies No dependencies. FTP_ITC.1.1/PACE The TSF shall provide a communication channel between itself 3590 and another trusted IT product (a PACE terminal) that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. The trusted channel shall be established by performing the PACE protocol according to [BSI-TR-03110-2-V221]181 . 3595 177 [assignment: integrity errors] 178 [assignment: user data attributes] 179 [assignment: action to be taken] 180 [assignment: list of objects or information types] 181 The refinements clarifiy the type of trusted IT product (a PACE terminal) and protocol used (PACE). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 101 7 Security Requirements (ASE_REQ) FTP_ITC.1.2/PACE The TSF shall permit another trusted IT product (a PACE terminal)182 to initiate communication via the trusted channel. FTP_ITC.1.3/PACE The TSF shall initiate enforce183 communication via the trusted channel for any data exchange between the TOE and the Terminal.184 3600 Notes 1. The trusted IT product is the terminal. In FTP_ITC.1.3/PACE, the word “initiate” is changed to “enforce”, as the TOE is a passive device that can not initiate the communication. All the communication are initiated by the Terminal, and the TOE enforce the trusted channel. 3605 2. The trusted channel is established after successful performing the PACE protocol (FIA_ UAU.1/PACE). If the PACE was successfully performed, secure messaging is immediately started using the derived session keys (PACE-K.MAC, PACE-K.Enc): This secure messaging enforces preventing tracing while Passive Authentication and the required properties of operational trusted channel; the cryptographic primitives 3610 being used for the secure messaging are as required by FCS_COP.1/PACE_ENC and FCS_ COP.1/PACE_MAC. The establishing phase of the PACE trusted channel does not enable tracing due to the requirements FIA_AFL.1/PACE. 3. Please note that the control on the user data stored in the TOE is addressed by FDP_ ACF.1/TRM 3615 4. If Chip Authentication is successfully performed, secure messaging is immediately started using the derived session keys (CA-K.MAC, CA-K.Enc): this secure messaging enforces preventing tracing while the required properties of operational trusted channel; the cryptographic primitives being used for the secure messaging are as required by FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC. 3620 5. If first PACE session keys are used for establishing the trusted channel and afterward a Chip Authentication is successfully performed, the sessions keys of the CA are used only for the trusted channel (the PACE session keys are not longer used). 7.6.4.2 FTP_ITC.1/SVD (Inter-TSF trusted channel) CGA Hierarchical to No other components. 3625 Dependencies No dependencies. FTP_ITC.1.1/SVD The TSF shall provide a communication channel between itself and another trusted IT product CGA185 that is logically distinct from other communication channels and provides ensured identification of its end points and protection of the channel data from modification or disclosure. 3630 FTP_ITC.1.2/SVD The TSF shall permit another trusted IT product186 to initiate com- munication via the trusted channel. FTP_ITC.1.3/SVD The TSF or the CGA shall initiate communication via the trusted channel for 1. data Authentication with Identity of Guarantor according to FIA_API.1 and 3635 FDP_DAU.2/SVD,187 182 [selection: the TSF, another trusted IT product] 183 The word “initiate” is changed to “enforce”, as the TOE is a passive device that can not initiate the communications. 184 [assignment: list of functions for which a trusted channel is required] 185 Refinement clarifies the type of terminal 186 [selection: the TSF, another trusted IT product] 187 [assignment: list of functions for which a trusted channel is required] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 102 7 Security Requirements (ASE_REQ) 2. none188 . Note 1. This SFR only applies for the Life Cycle Phase “Usage/Operational” as the TOE provides a 3640 communication channel to the CGA (via trusted channel) only in the Life Cycle Phase “Usage/Operational”. 7.6.4.3 FTP_ITC.1/VAD (Inter-TSF trusted channel – TC Human Interface Device) SCA Hierarchical to No other components. Dependencies No dependencies. 3645 FTP_ITC.1.1/VAD The TSF shall provide a communication channel between itself and another trusted IT product HID189 that is logically distinct from other communication channels and provides ensured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2/VAD The TSF shall permit the remote trusted IT product190 to initiate 3650 communication via the trusted channel. FTP_ITC.1.3/VAD The TSF or the HID shall initiate communication via the trusted channel for 1. User authentication according to FIA_UAU.1,191 2. none192 . 3655 Note 1. The PACE protocol used for authentication is a zero-knowledge protocol and thus protects the confidentiality of the VAD implicitly. 7.6.4.4 FTP_ITC.1/DTBS (Inter-TSF trusted channel – Signature creation Application) 3660 SCA Hierarchical to No other components. Dependencies No dependencies. FTP_ITC.1.1/DTBS The TSF shall provide a communication channel between itself and another trusted IT product SCA193 that is logically distinct from other communication channels and provides ensured identification of its end points 3665 and protection of the channel data from modification or disclosure. FTP_ITC.1.2/DTBS The TSF shall permit the remote trusted IT product194 to initiate communication via the trusted channel. FTP_ITC.1.3/DTBS The TSF or the SCA shall initiate communication via the trusted channel for 3670 1. signature creation,195 188 [assignment: list of other functions for which a trusted channel is required] 189 Refinement clarifies the type of terminal 190 [selection: the TSF, another trusted IT product] 191 [assignment: list of functions for which a trusted channel is required] 192 [assignment: list of other functions for which a trusted channel is required] 193 Refinement clarifies the type of terminal 194 [selection: the TSF, another trusted IT product] 195 [assignment: list of functions for which a trusted channel is required] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 103 7 Security Requirements (ASE_REQ) 2. none196 . 7.6.5 Class FMT Security Management Note 3675 1. The SFR FMT_SMR.1/PACE provides basic requirements to the management of the TSF data 7.6.5.1 FMT_SMR.1/PACE (Security roles) PACE EAC Hierarchical to No other components. Dependencies FIA_UID.1 Timing of identification. 3680 FMT_SMR.1.1/PACE The TSF shall maintain the roles 1. Manufacturer, 2. Personalization Agent, 3. Terminal, 4. PACE authenticated BIS-PACE, 3685 5. Country Verifying Certification Authority, 6. Document Verifier, 7. Domestic Extended Inspection System 8. Foreign Extended Inspection System.197 FMT_SMR.1.2/PACE The TSF shall be able to associate users with roles. 3690 Notes 1. The SFR FMT_SMR.1.1/PACE in the protection profile [BSI-CC-PP-0056-V2-2012-MA-02] covers the definition in PACE PP [BSI-CC-PP-0068-V2-2011-MA-01] and extends it by 5) to 8). This extension does not conflict with the strict conformance to PACE PP. 3695 2. The SFR FMT_LIM.1 and FMT_LIM.2 address the management of the TSF and TSF data to prevent misuse of test features of the TOE over the life-cycle phases. 7.6.5.2 FMT_SMR.1 (Security roles) SSCD Hierarchical to No other components. Dependencies FIA_UID.1 Timing of identification. 3700 FMT_SMR.1.1 The TSF shall maintain the roles R.Admin and R.Sigy198 [REFINE- MENT] and PACE Terminal. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 196 [assignment: list of other functions for which a trusted channel is required] 197 [assignment: the authorised identified roles] 198 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 104 7 Security Requirements (ASE_REQ) 7.6.5.3 FMT_LIM.1 (Limited capabilities) PACE EAC Hierarchical to No other components. 3705 Dependencies FMT_LIM.2 Limited availability. FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow, 3710 1. User Data to be manipulated and disclosed, 2. TSF data to be disclosed or manipulated, 3. software to be reconstructed, 4. substantial information about construction of TSF to be gathered which may enable other attacks and199 3715 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.200 7.6.5.4 FMT_LIM.2 (Limited availability) PACE EAC Hierarchical to No other components Dependencies FMT_LIM.1 Limited capabilities. FMT_LIM.2.1 The TSF shall be designed in a manner that limits their availability so 3720 that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow: 1. User Data to be manipulated and disclosed, 2. TSF data to be manipulated or disclosed 3725 3. software to be reconstructed, 4. substantial information about construction of TSF to be gathered which may enable other attacks201 and 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.202 3730 Notes 1. The formulation of “Deploying Test Features ...” in FMT_LIM.2.1 might be a little bit misleading since the addressed features are no longer available (e.g. by disabling or removing the respective functionality). Nevertheless the combination of FMT_LIM.1 and FMT_LIM.2 is introduced to provide an optional approach to enforce the same policy. 3735 2. Note that the term “software” in item 3 of FMT_LIM.1.1 and FMT_LIM.2.1 refers to both IC Dedicated and IC Embedded Software. Note 1. The following SFR are iterations of the component Management of TSF data (FMT_ 3740 MTD.1). 199 [assignment: Limited capability and availability policy] 200 [assignment: Limited capability and availability policy] 201 [assignment: Limited capability and availability policy] 202 [assignment: Limited capability and availability policy] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 105 7 Security Requirements (ASE_REQ) 7.6.5.5 FMT_MTD.1/INI_ENA (Management of TSF data - Writing Initialization and Pre- personalization Data) PACE Hierarchical to No other components. Dependencies 3745 FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/INI_ENA The TSF shall restrict the ability to write203 the Initialization Data and Pre-personalization Data204 to the Manufacturer205 . 7.6.5.6 FMT_MTD.1/INI_DIS (Management of TSF data - Reading and Using Initialization 3750 and Pre-personalization Data) PACE Hierarchical to No other components. Dependencies FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE 3755 FMT_MTD.1.1/INI_DIS The TSF shall restrict the ability to read out206 the Initialization Data and the Pre-personalization Data207 to the Personalization Agent208 . Notes 3760 1. The TOE restricts the ability to write the Initialization Data and the Pre-personalization Data by (i) allowing writing these data only once and (ii) blocking the role Manufacturer at the end of the manufacturing phase. The Manufacturer writes the Initialization Data (as required by FAU_SAS.1) including, 3765 but being not limited to a unique identification of the IC being used to trace the IC in the life cycle phases ‘manufacturing’ and ‘issuing’, but being not needed and may be misused in the ‘OPERATIONAL’. Therefore, read and use access to the Initialization Data and Pre-personalization Data is blocked by the Personalization Agent, before the card is handed out to the travel document holder. 3770 2. With “(i) allowing writing these data only once” the TOE allows to write the Initialization Data and Pre-personalization Data in more than one session but each data only once. 203 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 204 [assignment: list of TSF data] 205 [assignment: the authorised identified roles] 206 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 207 [assignment: list of TSF data] 208 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 106 7 Security Requirements (ASE_REQ) 7.6.5.7 FMT_MTD.1/PA (Management of TSF data - Personalization Agent) PACE Hierarchical to No other components. Dependencies 3775 FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/PA The TSF shall restrict the ability to write209 the Document Security Object (SOD)210 to the Personalization Agent211 . 3780 Note 1. By writing SOD into the TOE, the Personalization Agent confirms (on behalf of DS) the correctness and genuineness of all the personalization data related. This consists of user -and TSF- data. 7.6.5.8 FMT_MTD.1/CVCA_INI (Management of TSF data - Initialization of CVCA Certificate 3785 and Current Date) EAC Hierarchical to No other components. Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles 3790 FMT_MTD.1.1/CVCA_INI The TSF shall restrict the ability to write212 the 1. initial Country Verifying Certification Authority Public Key: PK.CVCA, 2. initial Country Verifying Certification Authority Certificate: C.CVCA, 3. initial Current Date, 4. none213 3795 to Personalization Agent214 . Note 1. The initial Country Verifying Certification Authority Public Keys (and their updates later on) are used to verify the Country Verifying Certification Authority Link-Certificates. 3800 The initial Country Verifying Certification Authority Certificate and the initial Current Date is needed for verification of the certificates and the calculation of the Terminal Authorization. 209 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 210 [assignment: list of TSF data] 211 [assignment: the authorised identified roles] 212 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 213 [assignment: list of TSF data] 214 [assignment: the authorized identified roles] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 107 7 Security Requirements (ASE_REQ) 7.6.5.9 FMT_MTD.1/CVCA_UPD (Management of TSF data - Country Verifying Certification Authority) 3805 EAC 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 update215 the 3810 1. Country Verifying Certification Authority Public Key: PK.CVCA, 2. Country Verifying Certification Authority Certificate216 : C.CVCA to Country Verifying Certification Authority.217 Note 3815 1. The Country Verifying Certification Authority updates its asymmetric key pair and dis- tributes the public key be means of the Country Verifying CA Link-Certificates (cf. [BSI- TR-03110-1-V220]). The TOE updates its internal trust-point if a valid Country Verifying CA Link-Certificates (cf. FMT_MTD.3) is provided by the terminal (cf. [BSI-TR-03110-1-V220]). 7.6.5.10 FMT_MTD.1/DATE (Management of TSF data - Current date) 3820 EAC 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 modify218 the Current date219 3825 to 1. Country Verifying Certification Authority, 2. Document Verifier, 3. Domestic Extended Inspection System.220 3830 Note 1. The authorized roles are identified in their certificate (cf. [BSI-TR-03110-1-V220]) and authorized by validation of the certificate chain (cf. FMT_MTD.3). The authorized role of the terminal is part of the Certificate Holder Authorization in the card verifiable certificate provided by the terminal for the identification and the Terminal Authentication v.1 (cf. 3835 to [BSI-TR-03110-1-V220]). 215 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 216 [assignment: list of TSF data] 217 [assignment: the authorised identified roles] 218 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 219 [assignment: list of TSF data] 220 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 108 7 Security Requirements (ASE_REQ) 7.6.5.11 FMT_MTD.1/CA_AA_PK (Management of TSF data - CA and AA Private Key) EAC Hierarchical to No other components. Dependencies FMT_SMF.1 Specification of management functions 3840 FMT_SMR.1 Security roles FMT_MTD.1.1/CA_AA_PK The TSF shall restrict the ability to load221 the Chip Au- thentication Private Key and Active Authentication Private Key222 to Person- alization Agent223 . 3845 Notes 1. Due to the fact that this SFR is refined with Active Authenticationthe SFR “FMT_ MTD.1/CAPK” of [BSI-CC-PP-0056-V2-2012-MA-02] is renamed to “FMT_MTD.1/CA_AA_ PK”. 2. The verb “load” means here that the Chip Authentication Private Key and the Active 3850 Authentication Private Key are generated securely outside the TOE and written into the TOE memory. 7.6.5.12 FMT_MTD.1/CAPK (Management of TSF data - Chip Authentication Private Key) Hierarchical to No other components. Dependencies 3855 FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/CAPK The TSF shall restrict the ability to load224 the Chip Authentication Private Key225 to R.Admin226 [REFINEMENT] before issuing the TOE. 3860 Notes 1. This SFR has been adapted from [BSI-CC-PP-0056-V2-2012-MA-02] . 2. [BSI-CC-PP-0056-V2-2012-MA-02] The verb “load” means here that the Chip Authen- tication Private Key is generated securely outside the TOE and written into the TOE 3865 memory. 3. The Chip Authentication Private Key mentioned here is used for performing Chip Au- thentication Protocol Version 1. 221 [selection: create, load] 222 REFINEMENT 223 [assignment: the authorized identified roles] 224 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 225 [assignment: list of TSF data] 226 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 109 7 Security Requirements (ASE_REQ) 7.6.5.13 FMT_MTD.1/KEY_READ (Management of TSF data - Key Read) PACE EAC Hierarchical to No other components. 3870 Dependencies FMT_SMF.1 Specification of management functions fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles fulfilled by FMT_SMR.1 FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read227 the 1. PACE passwords, 3875 2. Chip Authentication private key, 3. Personalization Agent Keys228 4. Electronic signature key 5. PACE Chip Authentication Mapping private key 6. Active Authentication Private Key229 3880 to none230 . Notes 1. The SFR FMT_MTD.1/KEY_READ in the current ST covers the definition in PACE PP [BSI- CC-PP-0068-V2-2011-MA-01] and extends it by additional TSF data. This extension does 3885 not conflict with the strict conformance to PACE PP. 2. This SFR makes explicit that the same security function also protects the electronic signature key, the chip authentication mapping key and the active authentication key. 7.6.5.14 FMT_MTD.1/RAD (Management of TSF data) SSCD Hierarchical to No other components. 3890 Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/RAD The TSF shall restrict the ability to create231 the RAD232 [RE- FINEMENT] of the Signatory once to R.Admin233 R.Sigy only after successful 3895 authentication with the transport PIN (PIN.T).234 Note 1. FMT_MTD.1/RAD captures the requirement “FMT_MTD.1/Admin” but clarifies that by using the transport PIN concept, the creation or the RAD can be bound to the signatory 3900 directly instead of using the administrator as an intermediary. 227 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 228 [assignment: list of TSF data] 229 [assignment: list of TSF data] 230 [assignment: the authorised identified roles] 231 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 232 [assignment: list of TSF data] 233 [assignment: the authorised identified roles] 234 REFINEMENT of “R.Admin” Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 110 7 Security Requirements (ASE_REQ) 7.6.5.15 FMT_MTD.1/Signatory (Management of TSF data) SSCD Hierarchical to No other components. Dependencies FMT_SMR.1 Security roles 3905 FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/Signatory The TSF shall restrict the ability to modify235 or unblock236 the RAD237 to R.Sigy238 . 7.6.5.16 FMT_MTD.3 (Secure TSF data) EAC Hierarchical to No other components. 3910 Dependencies FMT_MTD.1 Management of TSF data FMT_MTD.3.1 The TSF shall ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol v.1 and the Access Control.239 Refinement: The certificate chain is valid if and only if 3915 1. the digital signature of the Inspection System Certificate can be verified as correct with the public key of the Document Verifier Certificate and the expiration date of the Inspection System Certificate is not before the Current Date of the TOE, 2. the digital signature of the Document Verifier Certificate can be verified 3920 as correct with the public key in the Certificate of the Country Verifying Certification Authority and the expiration date of the Certificate of the Country Verifying Certification Authority is not before the Current Date of the TOE and the expiration date of the Document Verifier Certificate is not before the Current Date of the TOE, 3925 3. the digital signature of the Certificate of the Country Verifying Certification Authority can be verified as correct with the public key of the Country Verifying Certification Authority known to the TOE. The Inspection System Public Key contained in the Inspection System Certificate in a valid certificate chain is a secure value for the authentication 3930 reference data of the Extended Inspection System. The intersection of the Certificate Holder Authorizations contained in the certificates of a valid certificate chain is a secure value for Terminal Authorization of a successful authenticated Extended Inspection System. 3935 Note 1. The Terminal Authentication Version 1 is used for Extended Inspection System as required by FIA_UAU.4/PACE and FIA_UAU.5/PACE. The Terminal Authorization is used as TSF data for access control required by FDP_ACF.1/TRM. 235 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 236 [assignment: other operations] 237 [assignment: list of TSF data] 238 [assignment: the authorised identified roles] 239 [assignment: list of TSF data] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 111 7 Security Requirements (ASE_REQ) 7.6.5.17 FMT_SMF.1 (Specification of Management Functions) 3940 PACE SSCD Hierarchical to No other components. Dependencies No dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 1. Initialization, 3945 2. Pre-personalization, 3. Personalization, 4. Configuration 5. creation and modification of RAD; 6. enabling the signature creation function; 3950 7. modification of the security attribute SCD/SVD management, SCD operational; 8. change the default value of the security attribute SCD Identifier;240 9. none.241 3955 Notes 1. For “configuration” see chapter Life Cycle Phases Mapping section “Phase 3 “Personal- ization of the travel document” step (v). 2. Items 1. - 4. are defined in the [BSI-CC-PP-0068-V2-2011-MA-01] and items 5. to 8 are defined in [BSI-CC-PP-0059-2009-MA-02]. 3960 7.6.5.18 FMT_MOF.1 (Management of security functions behavior) SSCD Hierarchical to No other components. Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions 3965 FMT_MOF.1.1 The TSF shall restrict the ability to enable242 the functions signature creation function243 to R.Sigy244 . 240 [assignment: list of management functions to be provided by the TSF] 241 [assignment: list of other security management functions to be provided by the TSF] 242 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 243 [assignment: list of functions] 244 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 112 7 Security Requirements (ASE_REQ) 7.6.5.19 FMT_MSA.1/Admin (Management of security attributes) SSCD Hierarchical to No other components. Dependencies 3970 [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 The TSF shall enforce the SCD/SVD_Generation_SFP245 to re- 3975 strict the ability to modify246 and none247 the security attributes SCD/SVD management248 to R.Admin249 . 7.6.5.20 FMT_MSA.1/Signatory (Management of security attributes) SSCD Hierarchical to No other components. Dependencies 3980 [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 The TSF shall enforce the Signature_Creation_SFP250 to 3985 restrict the ability to modify251 the security attributes SCD operational252 to R.Sigy253 . 7.6.5.21 FMT_MSA.2 (Secure security attributes) SSCD Hierarchical to No other components. Dependencies 3990 [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 3995 SCD/SVD Management and SCD operational254 . Security attribute “SCD/SVD Management” can only have the values “au- thorized” or “not authorized”. Both values are secure, depending on the situation. Security attribute “SCD operational” can only have the values “no” or “yes”. 4000 Both values are secure, depending on the situation. 245 [assignment: access control SFP(s), information flow control SFP(s)] 246 [selection: change_default, query, modify, delete, [assignment: other operations]] 247 [assignment: other operations] 248 [assignment: list of security attributes] 249 [assignment: the authorised identified roles] 250 [assignment: access control SFP(s), information flow control SFP(s)] 251 [selection: change_default, query, modify, delete, [assignment: other operations]] 252 [assignment: list of security attributes] 253 [assignment: the authorised identified roles] 254 [selection: list of security attributes] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 113 7 Security Requirements (ASE_REQ) The security attribute values are not secure by themselves but in combina- tions. The secure values of the combinations are shown in the table Secure values of the combinations of security attributes. 4005 Therefore all combinations can be seen as secure.255 Table 7.7: Secure values of the combinations of security attributes SCD/SVD Management SCD operational Secure authorized yes YES authorized no YES not authorized yes YES not authorized no YES 7.6.5.22 FMT_MSA.3 (Static attribute initialization) SSCD Hierarchical to No other components. 4010 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_SFP256 to provide restrictive257 default values for 4015 security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the R.Admin258 to specify alternative initial values to override the default values when an object or information is created. 7.6.5.23 FMT_MSA.4 (Security attribute value inheritance) SSCD Hierarchical to No other components. 4020 Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.4.1 The TSF shall use the following rules to set the value of security attributes: 4025 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.259 4030 Note 1. Rule 2) is deleted, as the TOE does not support generating an SVD/SCD pair by the signatory alone. 255 REFINEMENT 256 [assignment: access control SFP, information flow control SFP] 257 [selection, choose one of: restrictive, permissive, [assignment: other property]] 258 [assignment: the authorised identified roles] 259 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 114 7 Security Requirements (ASE_REQ) 7.6.6 Class FAU Security Audit 4035 7.6.6.1 FAU_SAS.1 (Audit storage) PACE Hierarchical to No other components. Dependencies No dependencies. FAU_SAS.1.1 The TSF shall provide the Manufacturer260 with the capability to store the Initialization and Pre-Personalization Data261 in the audit records. 4040 Note 1. The Manufacturer role is the default user identity assumed by the TOE in the life cycle phase ‘manufacturing’. The IC manufacturer and the travel document manufacturer in the Manufacturer role write the Initialization and/or Pre-personalization Data as TSF-data 4045 into the TOE. The audit records are usually write-only-once data of the travel document (see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also be such audit records which cannot be read out, but directly used by the TOE. 7.6.7 Class FPT Protection of the Security Functions The TOE shall prevent inherent and forced illicit information leakage for User Data and TSF 4050 Data. The security functional requirement FPT_EMS.1 addresses the inherent leakage. The SFRs “Limited capabilities (FMT_LIM.1)”, “Limited availability (FMT_LIM.2)” together with the SAR “Security architecture description” (ADV_ARC.1) prevent bypassing, deactivation and manipulation of the security features or misuse of TOE functions. 7.6.7.1 FPT_EMS.1 (TOE Emanation) 4055 PACE EAC Hierarchical to No other components. Dependencies No Dependencies. FPT_EMS.1.1 The TOE shall not emit shape and amplitude of signals, time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines 4060 during internal operations or data transmissions262 in excess of unintelligible limits263 enabling access to 1. Chip Authentication Session Keys 2. PACE session Keys (PACE-K.MAC, PACE-K.Enc), 3. the ephemeral private key ephem-SK.PICC.PACE, 4065 4. none264 , 5. Personalization Agent Key(s), 6. Chip Authentication Private Key265 and 260 [assignment: authorised users] 261 [assignment: list of audit information] 262 [assignment: types of emissions] 263 [assignment: specified limits] 264 [assignment: list of types of TSF data] 265 [assignment: list of types of TSF data] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 115 7 Security Requirements (ASE_REQ) 7. Active Authentication Private Key and 8. PACE Chip Authentication Mapping private key266 . 4070 FPT_EMS.1.2 The TSF shall ensure any users267 are unable to use the following interface smart card circuit contacts268 to gain access to 1. Chip Authentication Session Keys 2. PACE Session Keys (PACE-K.MAC, PACE-K.Enc), 3. the ephemeral private key ephem-SK.PICC.PACE, 4075 4. none269 , 5. Personalization Agent Key(s) and 6. Chip Authentication Private Key270 and 7. Active Authentication Private Key and 8. PACE Chip Authentication Mapping private key271 . 4080 Notes 1. This SFR has been adapted from [BSI-CC-PP-0056-V2-2012-MA-02]. Active Authentication is taken into account in aspect 7, while PACE Chip Authentication Mapping has been added as aspect 8. 4085 These extensions do not conflict with the strict conformance to [BSI-CC-PP-0068-V2- 2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]. 2. The TOE prevents attacks against the listed secret data where the attack is based on external observable physical phenomena of the TOE. Such attacks may be observable at the interfaces of the TOE or may be originated from internal operation of the TOE or 4090 may be caused by an attacker that varies the physical environment under which the TOE operates. The set of measurable physical phenomena is influenced by the technology employed to implement the smart card. The travel document’s chip can provide a smart card contactless interface and contact-based interface according to ISO/IEC 7816-2 [ISO-IEC- 4095 7816-part-2] as well (in case the package only provides a contactless interface the attacker might gain access to the contacts anyway). Examples of measurable phenomena include, but are not limited to variations in the power consumption, the timing of signals and the electromagnetic radiation due to internal operations or data transmissions. 7.6.7.2 FPT_EMS.1/SSCD (TOE Emanation of SCD and RAD) 4100 SSCD Hierarchical to No other components. Dependencies No dependencies. FPT_EMS.1.1/SSCD The TOE shall not emit shape and amplitude of signals, time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines 4105 during internal operations or data transmissions272 266 [assignment: list of types of user data] 267 [assignment: type of users] 268 [assignment: type of connection] 269 [assignment: list of types of TSF data] 270 [assignment: list of types of TSF data] 271 [assignment: list of types of user data] 272 [assignment: types of emissions] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 116 7 Security Requirements (ASE_REQ) in excess of unintelligible limits273 enabling access to RAD274 and SCD275 . FPT_EMS.1.2/SSCD The TSF shall ensure any users276 are unable to use the fol- lowing interface smart card circuit contacts277 to gain access to RAD278 and SCD279 . 4110 7.6.7.3 FPT_FLS.1 (Failure with preservation of secure state) PACE SSCD Hierarchical to No other components. Dependencies No dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: 4115 1. Exposure to operating conditions causing a TOE malfunction, 2. Failure detected by TSF according to FPT_TST.1,280 3. Failures during cryptographic operations 4. Memory failures during TOE execution 5. Out of range failures of temperature, clock and voltage sensors 4120 6. Failures during random number generation.281 7.6.7.4 FPT_TST.1 (TSF testing) PACE SSCD 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 and at the 4125 conditions 1. start-up 2. Reading Initialization and Pre-personalization Data according to FMT_ MTD.1/INI_DIS 3. Reading data of LDS groups and EF.SOD 4130 4. Reading CA keys (secret key only internally) 5. Cryptographic key generation according to FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA 6. Reading certificates internally before Terminal Authentication Proto- 4135 col v.1 according to FCS_COP.1/SIG_VER_EC or FCS_COP.1/SIG_VER_RSA 7. Generating random numbers according to FCS_RNG.1 8. Generation of the SCD/SVD key pair according to “FCS_CKM.1/EC” or “FCS_CKM.1/RSA” 9. Signature-creation according to “FCS_COP.1/EC” or “FCS_COP.1/RSA” 4140 273 [assignment: specified limits] 274 [assignment: list of types of TSF data] 275 [assignment: list of types of user data] 276 [assignment: type of users] 277 [assignment: type of connection] 278 [assignment: list of types of TSF data] 279 [assignment: list of types of user data] 280 [assignment: list of types of failures in the TSF] 281 [assignment: list of other types of failures in the TSF] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 117 7 Security Requirements (ASE_REQ) 10. VAD verification 11. RAD modification282 to demonstrate the correct operation of the TSF283 . FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of the TSF data284 . 4145 FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of stored TSF executable code TSF285 . Note 1. This SFR covers both definitions from [BSI-CC-PP-0059-2009-MA-02] and [BSI-CC-PP- 4150 0068-V2-2011-MA-01] which differ only in the selection made in FPT_TST.1.3 by each PP; here the selection of TSF as a whole made by [BSI-CC-PP-0059-2009-MA-02] is the stronger one. 7.6.7.5 FPT_PHP.1 (Passive detection of physical attack) SSCD Hierarchical to No other components. 4155 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. 4160 7.6.7.6 FPT_PHP.3 Resistance to physical attack PACE SSCD Hierarchical to No other components. Dependencies No dependencies. FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing286 to the TSF287 by responding automatically such that the SFRs are always enforced. 4165 Note 1. The TOE implements appropriate measures to continuously counter physical manipula- tion and physical probing. Due to the nature of these attacks (especially manipulation) the TOE can by no means detect attacks on all of its elements. Therefore, permanent 4170 protection against these attacks is required ensuring that the TSP could not be violated at any time. Hence, ‘automatic response’ means here (i) assuming that there might be an attack at any time and (ii) countermeasures are provided at any time. 282 [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the conditions [assignment: conditions under which self test should occur]] 283 [selection: [assignment: parts of TSF], the TSF] 284 [selection: [assignment: parts of TSF], TSF data] 285 [selection: [assignment: parts of TSF], TSF] 286 [assignment: physical tampering scenarios] 287 [assignment: list of TSF devices/elements] Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 118 7 Security Requirements (ASE_REQ) 7.7 Security Assurance Requirements for the TOE 4175 The assurance requirements for the evaluation of the TOE and its development and operating environment are those taken from the • Evaluation Assurance Level 4 (EAL4) and augmented by taking the following components: • ALC_DVS.2, 4180 • ATE_DPT.2 and • AVA_VAN.5. Table 7.8: Security assurance requirements: EAL4 aug- mented with ALC_DVS.2, ATE-DPT.2 and AVA_VAN.5 Assurance Class Assurance components ADV: Development ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification ADV_IMP.1 Implementation representation of the TSF ADV_TDS.3 Basic 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 procedures and automation ALC_CMS.4 Problem tracking CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.2 Sufficiency of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.1 Well-defined development tools ASE: Security Target evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE: Tests ATE_COV.2 Analysis of coverage ATE_DPT.2 Testing: security enforcing modules ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample AVA: Vulnerability assessment AVA_VAN.5 Advanced methodical vulnerability analysis 4185 Note 1. The TOE shall protect the assets against high attack potential. This includes interme- diate storage in the chip as well as secure channel communications established using the Chip Authentication Protocol v.1 (OE.Prot_Logical_Travel_Document). If the TOE is operated in non-certified mode using the BAC-established communication channel, the 4190 confidentiality of the standard data shall be protected against attackers with at least Enhanced-Basic attack potential (AVA_VAN.3). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 119 7 Security Requirements (ASE_REQ) 7.8 Security Requirements Rationale 7.8.1 Security Functional Requirements Coverage The following table provides an overview for security functional requirements coverage. 4195 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 120 7 Security Requirements (ASE_REQ) Fig. 7.1: Functional Requirement to TOE security objective mapping Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 121 7 Security Requirements (ASE_REQ) 7.8.2 TOE Security Requirements Sufficiency OT.Identification (Identification of the TOE) addresses the storage of Initialization and Pre-Personalization Data in its non-volatile memory, whereby they also include the IC Identification Data uniquely identifying the TOE’s chip. This will be ensured by TSF according to FAU_SAS.1. The SFR FMT_MTD.1/INI_ENA allows 4200 only the Manufacturer to write Initialization and Pre-personalization Data (including the Personalization Agent key). The SFR FMT_MTD.1/INI_DIS requires the Personalization Agent to disable access to Initialization and Pre-personalization Data in the life cycle phase ‘operational use’. The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support the functions and roles related. OT.AC_Pers (Access Control for Personalisation of logical MRTD) 4205 addresses the access control of the writing the logical travel document. The justification for the SFRs FAU_SAS.1, FMT_MTD.1/INI_ENA and FMT_MTD.1/INI_DIS arises from the justification for OT.Identification above with respect to the Pre-personalization Data. The write access to the logical travel document data are defined by the SFR FIA_UID.1/PACE, FIA_UAU.1/PACE, FDP_ACC.1/TRM and FDP_ACF.1/TRM in the same way: only the successfully authenticated 4210 Personalization Agent is allowed to write the data of the groups EF.DG1 to EF.DG16 of the logical travel document only once. FMT_MTD.1/PA covers the related property of OT.AC_Pers (writing S.OD and, in generally, personalization data). The SFR FMT_SMR.1/PACE lists the roles (including Personalization Agent) and the SFR FMT_SMF.1 lists the TSF management functions (including Personalization). The SFRs FMT_MTD.1/KEY_READ and FPT_EMS.1 restrict 4215 the access to the Personalization Agent Keys and the Chip Authentication Private Key. The authentication of the terminal as Personalization Agent shall be performed by TSF according to SFR FIA_UAU.4/PACE and FIA_UAU.5/PACE. If the Personalization Terminal want to authenticate itself to the TOE by means of the Terminal Authentication Protocol v.1 (after Chip Authentication v.1) with the Personalization Agent 4220 Keys the TOE will use TSF according to the FCS_RNG.1 (for the generation of the challenge), FCS_CKM.1/CA_EC or FCS_CKM.1/CA_RSA288 (for the derivation of the new session keys after Chip Authentication v.1), and FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC (for the ENC_MAC_ Mode secure messaging), FCS_COP.1/SIG_VER_EC or FCS_COP.1/SIG_VER_RSA289 (as part of the Terminal Authentication Protocol v.1) and FIA_UAU.6/EAC (for the re-authentication). 4225 If the Personalization Terminal wants to authenticate itself to the TOE by means of the Authentication Mechanism with Personalization Agent Key the TOE will use TSF according to the FCS_RNG.1 (for the generation of the challenge) and FCS_COP.1/CA_ENC (to verify the authentication attempt). The session keys are destroyed according to FCS_CKM.4 after use. OT.Data_Integrity (Integrity of Data) 4230 requires the TOE to protect the integrity of the logical travel document stored on the travel document’s chip against physical manipulation and unauthorized writing. Physical manipu- lation is addressed by FPT_PHP.3. Logical manipulation of stored user data is addressed by (FDP_ACC.1/TRM, FDP_ACF.1/TRM): Only the Personalization Agent is allowed to write the data in EF.DG1 to EF.DG16 of the logical 4235 travel document (FDP_ACF.1.2/TRM, rule 1) and terminals are not allowed to modify any of the data in EF.DG1 to EF.DG16 of the logical travel document (cf. FDP_ACF.1.4/TRM). FMT_ MTD.1/PA requires that SOD containing signature over the User Data stored on the TOE and used for the Passive Authentication is allowed to be written by the Personalization Agent only and, hence, is to be considered as trustworthy. The Personalization Agent must identify and 4240 authenticate themselves according to FIA_UID.1/PACE and FIA_UAU.1/PACE before accessing these data. FIA_UAU.4/PACE, FIA_UAU.5/PACE and FCS_CKM.4 represent some required 288 REFINEMENT FCS_CKM.1/CA_RSA is added to this ST 289 REFINEMENT FCS_COP.1/SIG_VER_RSA is added to this ST Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 122 7 Security Requirements (ASE_REQ) specific properties of the protocols used. The SFR FMT_SMR.1/PACE lists the roles and the SFR ||PP0068 FMT_SMF.1|| lists the TSF management functions. Unauthorized modifying of the exchanged data is addressed, in the first line, by FTP_ITC.1/PACE 4245 using FCS_COP.1/PACE_MAC. For PACE secured data exchange, a prerequisite for establishing this trusted channel is a successful PACE Authentication (FIA_UID.1/PACE, FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA290 and possessing the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp. FIA_UAU.6/EAC. The trusted channel is established using PACE, Chip Authentication v.1, and Terminal Authentication v.1. FDP_RIP.1 4250 requires erasing the values of session keys (here: for K.MAC). The TOE supports the inspection system detect any modification of the transmitted logical travel document data after Chip Authentication v.1. The SFR FIA_UAU.6/EAC and FDP_ UIT.1/TRM requires the integrity protection of the transmitted data after Chip Authentication v.1 by means of secure messaging implemented by the cryptographic functions according to 4255 FCS_CKM.1/CA_EC or FCS_CKM.1/CA_RSA291 (for the generation of shared secret and for the derivation of the new session keys), and FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the ENC_MAC_Mode secure messaging. The session keys are destroyed according to FCS_CKM.4 after use. The SFR FMT_MTD.1/CA_AA_PK and FMT_MTD.1/KEY_READ requires that the Chip Authenti- 4260 cation Key cannot be written unauthorized or read afterward. The SFR FCS_RNG.1 represents a general support for cryptographic operations needed. The SFR FCS_RNG.1 represents a general support for cryptographic operations needed.292 OT.Data_Authenticity (Authenticity of Data) aims ensuring authenticity of the User- and TSF data (after the PACE Authentication) by 4265 enabling its verification at the terminal-side and by an active verification by the TOE itself. This objective is mainly achieved by FTP_ITC.1/PACE using FCS_COP.1/PACE_MAC. A pre- requisite for establishing this trusted channel is a successful PACE or Chip and Terminal Authentication v.1 (FIA_UID.1/PACE, FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE_EC and FCS_ CKM.1/DH_PACE_RSA293 resp. FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA294 and possessing 4270 the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp. FIA_UAU.6/EAC. FDP_RIP.1 requires erasing the values of session keys (here: for KMAC). FIA_UAU.4/PACE, FIA_UAU.5/PACE and FCS_CKM.4 represent some required specific proper- ties of the protocols used. The SFR FMT_MTD.1/KEY_READ restricts the access to the PACE passwords and the Chip Authentication Private Key. 4275 FMT_MTD.1/PA requires that S.OD containing signature over the User Data stored on the TOE and used for the Passive Authentication is allowed to be written by the Personalization Agent only and, hence, is to be considered as trustworthy. The SFR FCS_RNG.1 represents a general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support the functions and roles related. 4280 OT.Data_Confidentiality (Confidentiality of Data) aims that the TOE always ensures confidentiality of the User- and TSF-data stored and, after the PACE Authentication resp. Chip Authentication, of these data exchanged. This objective for the data stored is mainly achieved by (FDP_ACC.1/TRM, FDP_ACF.1/TRM). FIA_ UAU.4/PACE, FIA_UAU.5/PACE and FCS_CKM.4 represent some required specific properties of 4285 the protocols used. 290 REFINEMENT 291 REFINEMENT FCS_CKM.1/CA_RSA is added to this ST 292 REFINEMENT 293 REFINEMENT 294 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 123 7 Security Requirements (ASE_REQ) This objective for the data exchanged is mainly achieved by FDP_UCT.1/TRM, FDP_UIT.1/TRM and FTP_ITC.1/PACE using FCS_COP.1/PACE_ENC resp. FCS_COP.1/CA_ENC. A prerequisite for establishing this trusted channel is a successful PACE or Chip and Terminal Authentication v.1 (FIA_UID.1/PACE, FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_ 4290 PACE_RSA295 resp. FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA296 and possessing the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp. FIA_UAU.6/EAC. FDP_RIP.1 requires erasing the values of session keys (here: for K.enc). The SFR FMT_MTD.1/KEY_READ restricts the access to the PACE passwords and the Chip Authentication Private Key. FMT_MTD.1/PA requires that SOD containing signature over the User Data stored on the TOE and used for the Passive 4295 Authentication is allowed to be written by the Personalization Agent only and, hence, is to be considered trustworthy. The SFR FCS_RNG.1 represents the general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support the functions and roles related. OT.Sens_Data_Conf (Confidentiality of sensitive biometric reference data) 4300 is enforced by the Access Control SFP defined in FDP_ACC.1/TRM and FDP_ACF.1/TRM allowing the data of EF.DG3 and EF.DG4 only to be read by successfully authenticated Extended Inspection System being authorized by a valid certificate according FCS_COP.1/SIG_VER_EC or FCS_COP.1/SIG_VER_RSA297 . The SFRs FIA_UID.1/PACE and FIA_UAU.1/PACE require the identification and authentication 4305 of the inspection systems. The SFR FIA_UAU.5/PACE requires the successful Chip Authenti- cation (CA) v.1 or PACE Chip Authentication Mapping before any authentication attempt as Extended Inspection System. During the protected communication following the CA v.1 the reuse of authentication data is prevented by FIA_UAU.4/PACE. The SFR FIA_UAU.6/EAC and FDP_UCT.1/TRM requires the confidentiality protection of the transmitted data after Chip 4310 Authentication v.1 by means of secure messaging implemented by the cryptographic func- tions according to FCS_RNG.1 (for the generation of the terminal authentication challenge), FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA298 (for the generation of shared secret and for the derivation of the new session keys), and FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the ENC_MAC_Mode secure messaging. The session keys are destroyed according to FCS_CKM.4 4315 after use. The SFR FMT_MTD.1/CA_AA_PK and FMT_MTD.1/KEY_READ requires that the Chip Authentication Key cannot be written unauthorized or read afterward. To allow a verification of the certificate chain as in FMT_MTD.3 the CVCA’s public key and certificate as well as the current date are written or update by authorized identified role as of FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. 4320 OT.Chip_Auth_Proof (Proof of the travel document’s chip authenticity) is ensured by the Chip Authentication Protocol v.1 provided by FIA_API.1/CA proving the identity of the TOE. The Chip Authentication Protocol v.1 defined by FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA299 is performed using a TOE internally stored confidential private key as required by FMT_MTD.1/CA_AA_PK and FMT_MTD.1/KEY_READ. The Chip Authentication 4325 Protocol v.1 [BSI-TR-03110-1-V220] requires additional TSF according to FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA300 (for the derivation of the session keys), FCS_COP.1/CA_ENC and FCS_ COP.1/CA_MAC (for the ENC_MAC_Mode secure messaging). The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support the functions and roles related. 295 REFINEMENT 296 REFINEMENT 297 REFINEMENT FCS_COP.1/SIG_VER_RSA is added to this ST 298 REFINEMENT 299 REFINEMENT 300 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 124 7 Security Requirements (ASE_REQ) The SFR FMT_MTD.1/CA_AA_PK requires that the Chip Authentication Key used for Chip 4330 Authentication Protocol v.1 cannot be imported unauthorized.301 OT.AA_Proof (Proof of the travel document’s chip authenticity) is ensured by the Active Authentication Protocol provided by FIA_API.1/AA proving the identity of the TOE. The Active Authentication Protocol is performed using a TOE in- ternally stored confidential private key as required by FMT_MTD.1/CA_AA_PK and FMT_ 4335 MTD.1/KEY_READ. The Active Authentication Protocol [ICAO-9303-2015] requires addi- tional TSF according to FCS_COP.1/AA_SGEN_EC (for the generation ot the digital sig- natures). The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support the functions and roles related. The SFR FMT_MTD.1/CA_AA_PK requires that the Active Authentication Key used for Ac- 4340 tive Authentication Protocol cannot be imported unauthorized. OT.Prot_Abuse-Func (Protection against Abuse of Functionality) is ensured by the SFR FMT_LIM.1 and FMT_LIM.2 which prevent misuse of test functionality of the TOE or other features which may not be used after TOE Delivery. OT.Prot_Inf_Leak (Protection against Information Leakage) 4345 requires the TOE to protect confidential TSF data stored and/or processed in the travel document’s chip against disclosure • by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines which is addressed by the SFR FPT_EMS.1, 4350 • by forcing a malfunction of the TOE which is addressed by the SFR FPT_FLS.1 and FPT_ TST.1, and/or • by a physical manipulation of the TOE which is addressed by the SFR FPT_PHP.3. OT.Tracing (Tracing travel document) aims that the TOE prevents gathering TOE tracing data by means of unambiguous identifying 4355 the travel document remotely through establishing or listening to a communication via the contactless interface of the TOE without a priori knowledge of the correct values of shared passwords (CAN, MRZ). This objective is achieved as follows: (i) while establishing PACE communication with CAN or MRZ (non-blocking authorization data) - by FIA_AFL.1/PACE; 4360 (ii) for listening to PACE communication (is of importance for the current ST, since S.OD is card-individual) - FTP_ITC.1/PACE. OT.Prot_Phys-Tamper (Protection against Physical Tampering) is covered by the SFR FPT_PHP.3. OT.Prot_Malfunction (Protection against Malfunctions) 4365 is covered by 301 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 125 7 Security Requirements (ASE_REQ) (i) the SFR FPT_TST.1 which requires self tests to demonstrate the correct operation and tests of authorized users to verify the integrity of TSF data and TSF code, and (ii) the SFR FPT_FLS.1 which requires a secure state in case of detected failure or operating conditions possibly causing a malfunction. 4370 OT.Lifecycle_Security (Lifecycle security) is provided by the SFRs • FCS_CKM.1/EC (for EC SCD/SVD generation), • FCS_CKM.1/RSA (for RSA SCD/SVD generation), • FCS_COP.1/EC (for SCD usage using EC), • FCS_COP.1/RSA (for SCD usage using RSA) and 4375 • 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. 4380 The SVD transfer for certificate generation is controlled by TSF according to • FDP_ACC.1/SVD_Transfer and • FDP_ACF.1/SVD_Transfer. The SCD usage is ensured by access control • FDP_ACC.1/Signature_Creation, 4385 • FDP_ACF.1/Signature_Creation, which is based on the security attribute secure TSF management according to • FMT_MOF.1, • FMT_MSA.1/Admin, • FMT_MSA.1/Signatory, 4390 • FMT_MSA.2, • FMT_MSA.3, • FMT_MSA.4, • FMT_MTD.1/RAD, • FMT_MTD.1/Signatory, 4395 • FMT_SMF.1 and • FMT_SMR.1. The test functions • FPT_TST.1 provides failure detection throughout the life cycle. 4400 (Life cycle security) in the Phase “Usage/Preparation” is provided by the SFRs • FCS_COP.1/AES_MAC, • FIA_UID.1, • FIA_UAU.1, Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 126 7 Security Requirements (ASE_REQ) • FIA_AFL.1/AuthAdmin provides protection against brute force attacks against authenti- 4405 cation. (Life cycle security) in the Phase “Usage/Operational” is provided by the SFRs which essen- tially reflect the fact that the eSign application uses the PACE and Chip Authentication as elementary mechanisms to control the access to the application. The general access control to EF.CardSecurity (references to FDP_ACx.1/TRM) arises from the fact that this EF contains 4410 the public key needed to authenticate the SSCD. • FCS_CKM.1/DH_PACE_EC, • FCS_CKM.1/DH_PACE_RSA, • FCS_CKM.1/CA_EC, • FCS_CKM.1/CA_RSA, 4415 • FCS_CKM.4 (for session key destruction), • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_COP.1/CA_ENC, • FCS_COP.1/CA_MAC, 4420 • FCS_RNG.1, • FDP_ACC.1/TRM, • FDP_ACF.1/TRM, • FIA_UID.1, • FIA_UAU.1, 4425 • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, • FIA_UAU.6/PACE, • FIA_UAU.6/CA, • FIA_API.1, 4430 • FMT_MTD.1/KEY_READ, • FMT_MTD.1/CAPK. SCD destruction (FCS_CKM.4) can be performed on request of the signatory by the adminis- trator or by the signatory itself by irreversibly blocking the PIN and the (optional) PUK. OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) addresses that generation of a 4435 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 authorized functions. The SFR 4440 • FDP_ACC.1/SCD/SVD_Generation and • FDP_ACF.1/SCD/SVD_Generation provide access control for the SCD/SVD generation. The security attributes of the authenticated user are provided by • FMT_MSA.1/Admin, 4445 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 127 7 Security Requirements (ASE_REQ) • 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. 4450 OT.SCD_Unique (Uniqueness of the signature creation data) implements the requirement of practically unique SCD as laid down in Annex III of the Directive, paragraph 1(a), which is provided by the cryptographic algorithms specified by • FCS_CKM.1/EC and • FCS_CKM.1/RSA. 4455 OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) addresses that the SVD corresponds to the SCD implemented by the TOE. This is provided by the algorithms specified by • FCS_CKM.1/EC and • FCS_CKM.1/RSA 4460 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 4465 • 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 the signature creation data) is provided by the security functions specified by the following SFRs. 4470 • FCS_CKM.1/EC and • FCS_CKM.1/RSA ensure the use of secure cryptographic algorithms for SCD/SVD generation. Cryptographic quality of SCD/SVD pair shall prevent disclosure of SCD by cryptographic attacks using the publicly known SVD. 4475 The security functions specified by • 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 information. 4480 The security functions specified by • FDP_SDI.2/Persistent ensure that no critical data is modified which could alter the efficiency of the security functions or leak information of the SCD. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 128 7 Security Requirements (ASE_REQ) • FPT_TST.1 4485 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 error conditions are countered by FPT_FLS.1 is fault injection for differential fault analysis (DFA). 4490 • 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 crypto- graphic algorithms specified by 4495 • FCS_COP.1/EC, • FCS_COP.1/RSA and • FCS_COP.1/SHA which ensures the cryptographic robustness of the signature algorithms, • FDP_SDI.2/Persistent 4500 corresponds to the integrity of the SCD implemented by the TOE and • FPT_TST.1 ensures self-tests ensuring correct signature creation. FCS_COP.1/SHA is used before FCS_COP.1/EC and FCS_COP.1/RSA if DTBS or an interme- diate hash value with the remainder of DTBS (last round hash value) is sent to the TOE 4505 for signature creation. 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 4510 ensure that no signature creation function can be invoked before the signatory is identified and authenticated. The security functions specified by • FMT_MTD.1/RAD and • FMT_MTD.1/Signatory 4515 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/PACE provides protection against brute force attacks against authentication. 4520 • FIA_AFL.1/Suspend_PIN provides protection against denial-of-service attacks. • FIA_AFL.1/Block_PIN provides protection against brute force attacks against authentica- tion. The security functions specified by Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 129 7 Security Requirements (ASE_REQ) • FDP_SDI.2/DTBS 4525 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). The security functions specified by 4530 • FDP_ACC.1/Signature_Creation and • FDP_ACF.1/Signature_Creation provide access control based on the security attributes managed according to the SFRs • FMT_MTD.1/Signatory, • FMT_MSA.2, 4535 • FMT_MSA.3 and • FMT_MSA.4. The SFRs • FMT_SMF.1 and • FMT_SMR.1 4540 list these management functions and the roles. These ensure that the signature process is restricted to the signatory. • FMT_MOF.1 restricts the ability to enable the signature creation function to the signatory. • FMT_MSA.1/Signatory 4545 restricts the ability to modify the security attributes SCD operational to the signatory. In the Phase “Usage/Operational” Signature creation function for the legitimate signatory only is additionally provided by the SFRs, which essentially reflects that the PACE protocol is used to protect the signature creation function. • FCS_CKM.1/DH_PACE_RSA, 4550 • FCS_CKM.1/DH_PACE_EC, • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_RNG.1, • FDP_UCT.1/TRM, 4555 • FDP_UIT.1/TRM, • FIA_UID.1, • FIA_UAU.1, • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, 4560 • FIA_UAU.6/PACE and • FIA_UAU.6/Signature_Creation 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 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 130 7 Security Requirements (ASE_REQ) • FDP_SDI.2/DTBS 4565 require that the DTBS/R has not been altered by the TOE. OT.EMSEC_Design (Provide physical emanations security) covers that no intelligible informa- tion is emanated. This is provided by • FPT_EMS.1/SSCD and • FPT_EMS.1. 4570 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_PHP.3 4575 to resist physical attacks. CGA OT.TOE_SSCD_Auth (Authentication proof as SSCD) requires the TOE to provide security mechanisms to identify and to authenticate themselves as SSCD302 , which is directly provided by • FIA_API.1. 4580 The SFR • FIA_UAU.1 allows (additionally to PP SSCD KG) establishment of the trusted channel before (human) user is authenticated. Furthermore 4585 • FMT_MTD.1/CAPK provides the Chip Authentication private key. CGA OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export) requires the TOE to provide a trusted channel to the CGA to protect the integrity of the SVD exported to the CGA303 , which is directly provided by 4590 • the SVD transfer for certificate generation controlled by TSF according to – FDP_ACC.1/SVD_Transfer and – FDP_ACF.1/SVD_Transfer. • The SFR – FDP_DAU.2/SVD 4595 requires the TOE to provide CGA with the ability to verify evidence of the validity of the SVD and the identity of the user that generated the evidence. 302 This security objective only applies in case a communication channel to the CGA (via trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. 303 The TOE provides a communication channel to the CGA (via trusted channel) only in the Life Cycle Phase “Usage/Operational”. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 131 7 Security Requirements (ASE_REQ) • The SFR – FTP_ITC.1/SVD requires the TOE to provide a trusted channel to the CGA. 4600 The functionality for integrity and confidentiality is provided by the following SFRs, which reflects that the PACE and CA protocols are used to establish the trusted channel to the CGA. • FCS_CKM.1/DH_PACE_RSA, • FCS_CKM.1/DH_PACE_EC, • FCS_CKM.1/CA_RSA, 4605 • FCS_CKM.1/CA_EC, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, • FCS_COP.1/CA_ENC, 4610 • FCS_COP.1/CA_MAC, • FCS_RNG.1, • FDP_ACC.1/TRM, • FDP_ACF.1/TRM, • FDP_UCT.1/TRM, 4615 • FDP_UIT.1/TRM, • FIA_UID.1, • FIA_UAU.1, • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, 4620 • FIA_UAU.6/PACE, • FIA_UAU.6/CA, • FMT_MTD.1/KEY_READ and • FMT_MTD.1/CAPK. FDP_RIP.1 requires erasing the values of session keys 4625 SCA OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) is provided by • 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 the following SFRs which essentially reflects that the PACE protocol is used to protect the VAD 4630 • FCS_CKM.1/DH_PACE_RSA, • FCS_CKM.1/DH_PACE_EC, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/PACE_ENC, • FCS_COP.1/PACE_MAC, 4635 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 132 7 Security Requirements (ASE_REQ) • FCS_RNG.1, • FDP_UCT.1/TRM, • FDP_UIT.1/TRM, • FIA_UAU.1, • FIA_UAU.4/PACE, 4640 • FIA_UAU.5/PACE, • FIA_UAU.6/PACE and • FMT_MTD.1/KEY_READ. FDP_RIP.1 requires erasing the values of session keys SCA OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) is provided by 4645 • 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 the following SFRs which 4650 essentially reflects that the DTBS is protected using the PACE protocol. • FCS_CKM.1/DH_PACE_RSA, • FCS_CKM.1/DH_PACE_EC, • FCS_CKM.4 (for session key destruction), • FCS_COP.1/PACE_ENC, 4655 • FCS_COP.1/PACE_MAC, • FCS_RNG.1, • FDP_UCT.1/TRM, • FDP_UIT.1/TRM, • FIA_UID.1, 4660 • FIA_UAU.1, • FIA_UAU.4/PACE, • FIA_UAU.5/PACE, • FIA_UAU.6/PACE and • FMT_MTD.1/KEY_READ. 4665 FDP_RIP.1 requires erasing the values of session keys Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 133 7 Security Requirements (ASE_REQ) 7.9 Satisfaction of Dependencies of Security Requirements The dependency analysis for the security functional requirements shows that the basis for mutual support and internal consistency between all defined functional requirements is satisfied. All dependencies between the chosen functional components are analyzed, and 4670 non-dissolved dependencies are appropriately explained. Please note that • the dependency analysis for SFRs taken over from [BSI-CC-PP-0068-V2-2011-MA-01] has directly been made within the description of each SFR in chapter Security Functional Requirements for the TOE and 4675 • these SFRs are not listed in the following table. Table 7.9 shows the dependencies between the SFR of the TOE. Table 7.9: Dependencies between the SFR for the TOE Functional requirements Dependencies Satisfied by FCS_CKM.1/CA_EC [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_RSA [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/EC [FCS_CKM.2 or FCS_ COP.1], FCS_CKM.4 FCS_COP.1/EC, FCS_ CKM.4 FCS_CKM.1/RSA [FCS_CKM.2 or FCS_ COP.1], FCS_CKM.4 FCS_COP.1/RSA, FCS_ CKM.4 FCS_CKM.1/DH_PACE_EC [FCS_CKM.2 or FCS_ COP.1], FCS_CKM.4 FCS_COP.1/PACE_ENC, FCS_COP.1/PACE_MAC, FCS_CKM.4 FCS_CKM.1/DH_PACE_RSA [FCS_CKM.2 or FCS_ COP.1], FCS_CKM.4 FCS_COP.1/PACE_ENC, FCS_COP.1/PACE_MAC, FCS_CKM.4 FCS_CKM.4 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1/DH_PACE_ EC, FCS_CKM.1/CA_EC, FCS_CKM.1/DH_PACE_ RSA, FCS_CKM.1/CA_RSA FCS_COP.1/CA_ENC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 FCS_CKM.1/CA_EC, FCS_ CKM.1/CA_RSA, 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_EC, FCS_ CKM.1/CA_RSA, FCS_ CKM.4 FCS_COP.1/SIG_VER_EC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 see Justification 2 below, FCS_CKM.4 FCS_COP.1/SIG_VER_RSA [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 see Justification 2 below, FCS_CKM.4 FCS_COP.1/AA_SGEN_EC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 see Justification 5 below, FCS_CKM.4 FCS_COP.1/EC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 FCS_CKM.1/EC, FCS_ CKM.4 continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 134 7 Security Requirements (ASE_REQ) Table 7.9 – continued from previous page Functional requirements Dependencies Satisfied by FCS_COP.1/RSA [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 FCS_CKM.1/RSA, FCS_ CKM.4 FCS_COP.1/SHA [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 see Justification 3 below FCS_COP.1/PACE_ENC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 FCS_CKM.1/DH_PACE_ EC, FCS_CKM.1/DH_ PACE_RSA, 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_ EC, FCS_CKM.1/DH_ PACE_RSA, FCS_CKM.4 FCS_COP.1/AES_MAC [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_ CKM.4 see Justification 4 below, FCS_CKM.4 FCS_RNG.1 No dependencies n.a. FIA_UID.1304 No dependencies n.a. FIA_UAU.1305 FIA_UID.1 FIA_UID.1 FIA_UAU.6/PACE No dependencies n.a. FIA_UAU.6/CA No dependencies n.a. FIA_AFL.1/RAD FIA_UAU.1 FIA_UAU.1 FIA_AFL.1/PACE FIA_UAU.1 FIA_UAU.1/PACE FIA_AFL.1/Suspend_PIN FIA_UAU.1 FIA_UAU.1 FIA_AFL.1/Block_PIN FIA_UAU.1 FIA_UAU.1 FIA_AFL.1/AuthAdmin FIA_UAU.1 FIA_UAU.1 FIA_API.1 No dependencies n.a. FIA_UID.1/PACE No dependencies n.a. FIA_UAU.1/PACE FIA_UID.1 FIA_UID.1/PACE FIA_UAU.4/PACE No dependencies n.a. FIA_UAU.5/PACE No dependencies n.a. FIA_UAU.6/EAC No dependencies n.a. FIA_API.1/CA No dependencies n.a. FIA_API.1/AA 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, see Jus- tification 1 below FDP_ACC.1/SCD/SVD_Generation FDP_ACF.1 FDP_ACF.1/SCD/SVD_ Generation FDP_ACF.1/SCD/SVD_Generation FDP_ACF.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_ACF.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_ACF.1, FMT_MSA.3 FDP_ACC.1/Signature_ Creation, FMT_MSA.3 FDP_UCT.1/TRM [FTP_ITC.1 or FTP_TRP.1], [FDP_ACC.1 or FDP_IFC.1] FTP_ITC.1/SVD, FTP_ ITC.1/VAD, FTP_ ITC.1/DTBS, FDP_ ACC.1/TRM continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 135 7 Security Requirements (ASE_REQ) Table 7.9 – continued from previous page Functional requirements Dependencies Satisfied by FDP_UIT.1/TRM [FTP_ITC.1 or FTP_TRP.1], [FDP_ACC.1 or FDP_IFC.1] FTP_ITC.1/SVD, FTP_ ITC.1/VAD, FTP_ ITC.1/DTBS, FDP_ ACC.1/TRM FDP_UIT.1/DTBS [FTP_ITC.1 or FTP_TRP.1], [FDP_ACC.1 or FDP_IFC.1] FTP_ITC.1/DTBS, FDP_ ACC.1/Signature_ Creation 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 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_SMR.1, FMT_MSA.1 FDP_ACC.1/SCD/SVD_ Generation, FDP_ ACC.1/Signature_ Creation, FMT_SMR.1, FMT_MSA.1/Admin, FMT_ MSA.1/Signatory FMT_MSA.3 FMT_SMR.1, FMT_MSA.1 FMT_SMR.1, FMT_ MSA.1/Admin, FMT_ MSA.1/Signatory FMT_MSA.4 [FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1/SCD/SVD_ Generation, FDP_ ACC.1/Signature_ Creation FMT_MTD.1/RAD FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_SMR.1 FMT_MTD.1/Signatory FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_SMR.1 FMT_MTD.1/KEY_READ FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE FMT_MTD.1/CAPK FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE FMT_SMR.1/PACE FIA_UID.1 FIA_UID.1/PACE FMT_LIM.1 FMT_LIM.2 FMT_LIM.2 FMT_LIM.2 FMT_LIM.1 FMT_LIM.1 FMT_MTD.1/CVCA_INI FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE FMT_MTD.1/CVCA_UPD FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE FMT_MTD.1/DATE FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE FMT_MTD.1/CA_AA_PK FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE FMT_MTD.1/PA FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 136 7 Security Requirements (ASE_REQ) Table 7.9 – continued from previous page Functional requirements Dependencies Satisfied by FMT_MTD.3 FMT_MTD.1 FMT_MTD.1/CVCA_INI and FMT_MTD.1/CVCA_ UPD FPT_EMS.1 No dependencies n.a. FPT_EMS.1/SSCD 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. Justification for non-satisfied dependencies between the SFR for TOE: 1. The access control TSF according to FDP_ACF.1/TRM uses security attributes which are 4680 defined during the personalization and are fixed over the whole life time of the TOE. No management of these security attribute (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary here. 2. (i) Dependency FCS_CKM.1 is not useful since all keys for Terminal Authentication are generated outside of the TOE, see A.Auth_PKI (PKI for Inspection Systems). 4685 (ii) Dependencies “FDP_ITC.1 Import of user data without security attributes” and “FDP_ITC.2 Import of user data with security attributes” are not necessary be- cause all keys are written using FMT_MTD.1/CVCA_INI (Management of TSF data - Initialization of CVCA Certificate and Current Date) regardless whether the keys are EC or RSA keys.306 4690 3. Justification of “FCS_COP.1/SHA” can be found in FCS_COP.1/SHA (Cryptographic opera- tion – Hash calculation). 4. Justification of “FCS_COP.1/AES_MAC” can be found in FCS_COP.1/AES_MAC (Crypto- graphic operation – MACing with AES) 5. The Chip Authentication and Active Authentication Keys are permanently stored during 4695 personalisation in accordance to FMT_MTD.1/CA_AA_PK. Therefore, no key generation or import policy is needed. 7.10 Rationale for Chosen Security Assurance Requirements Table 7.10: Satisfaction of dependencies of security assur- ance requirements Assurance requirements Dependencies Satisfied by EAL4 package (dependencies of EAL4 package are not repro- duced here) By construction, all de- pendencies are satisfied in a CC EAL package ALC_DVS.2 No dependencies continues on next page 304 This SFR is amended with an item from [BSI-CC-PP-0068-V2-2011-MA-01]. 305 This SFR is amended with items from PP SSCD KG TCCGA, PP SSCD KG TCSCA and [BSI-CC-PP-0068-V2-2011- MA-01]. 306 REFINEMENT Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 137 7 Security Requirements (ASE_REQ) Table 7.10 – continued from previous page Assurance requirements Dependencies Satisfied by AVA_VAN.5 ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1 ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1 (all are in- cluded in EAL4 package) ATE_DPT.2 ADV_ARC.1, ADV_TDS.3, ATE_FUN.1 All of these are met or ex- ceeded in the EAL4 assur- ance package. The assurance level for PP SSCD KG, PP SSCD KG TCCGA and PP SSCD KG TCSCA is EAL4 augmented. EAL4 allows a developer to attain a reasonably high assurance level without the 4700 need for highly specialized processes and practices. It is considered to be the highest level that could be applied to an existing product line without undue expense and complexity. As such, EAL4 is appropriate for commercial products that can be applied to moderate to high security functions. The TOE described in this ST is just such a product. Augmentation results from the selection of: 4705 • ALC_DVS.2 which provides a higher assurance of the security of the travel document’s development and manufacturing especially for the secure handling of the travel docu- ment’s material. • ATE_DPT.2 which provides a higher assurance than the pre-defined EAL4 package due to requiring the functional testing of SFR-enforcing modules. 4710 • AVA_VAN.5 which provides a higher assurance of the security by vulnerability analysis to assess the resistance to penetration attacks performed by an attacker possessing a high attack potential. The TOE is intended to function as • an ePassport (with user data stored in an ICAO-compliant ePass application) or 4715 • a SSCD (with user data stored in an eSign application) or • an eID (with user data stored in an ICAO compliant ePass, an eSign and optionally other eID applications). 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 administrators. As a result, it 4720 is imperative that misleading, unreasonable and conflicting guidance 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. The requirements of the claimed protection profiles are met or exceeded and the dependen- 4725 cies are fulfilled as shown in Table 7.10. 7.11 Security Requirements - Mutual Support and Internal Consistency The following part of the security requirements rationale shows that the set of security requirements for the TOE consisting of the security functional requirements (SFRs) and the 4730 security assurance requirements (SARs) together form a mutually supportive and internally consistent whole. The analysis of the TOE’s security requirements with regard to their mutual support and internal consistency demonstrates: Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 138 7 Security Requirements (ASE_REQ) The dependency analysis in section Satisfaction of Dependencies of Security Requirements 4735 for the security functional requirements shows that the basis for mutual support and internal consistency between all defined functional requirements is satisfied. All dependencies between the chosen functional components are analyzed, and non-satisfied dependencies are appropriately explained. All subjects and objects addressed by more than one SFR in section Security Functional 4740 Requirements for the TOE are also treated in a consistent way: the SFRs impacting them do not require any contradictory property and behaviour of these ‘shared’ items. The assurance class EAL4 is an established set of mutually supportive and internally consistent assurance requirements. The dependency analysis for the sensitive assurance components in section Rationale for Chosen Security Assurance Requirements shows that the assurance 4745 requirements are mutually supportive and internally consistent as all (sensitive) dependencies are satisfied and no inconsistency appears. Inconsistency between functional and assurance requirements could only arise if there are functional-assurance dependencies which are not met, a possibility which has been shown not to arise in sections Satisfaction of Dependencies of Security Requirements and Rationale 4750 for Chosen Security Assurance Requirements. Furthermore, as also discussed in section Rationale for Chosen Security Assurance Requirements, the chosen assurance components are adequate for the functionality of the TOE. So the assurance requirements and security functional requirements support each other and there are no inconsistencies between the goals of these two groups of security requirements. 4755 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 139 8 TOE Summary Specification (ASE_TSS) 8 TOE Summary Specification (ASE_TSS) 8.1 TOE Security Services 8.1.1 User Identification and Authentication (ePass) This Security Service is responsible for maintaining of the following roles 1. Manufacturer, 4760 2. Personalization Agent, 3. Terminal, 4. PACE authenticated BIS-PACE, 5. Country Verifying Certification Authority, 6. Document Verifier, 4765 7. Domestic Extended Inspection System 8. Foreign Extended Inspection System according to FMT_SMR.1/PACE. The TOE allows • identification of the user according to FIA_UID.1/PACE before the authentication takes 4770 place according to FIA_UAU.1/PACE • the execution of following TSF-mediated actions before the user is identified and associ- ated with one of maintained roles 1. to establish the communication channel 2. carrying out the PACE Protocol according to 4775 3. to read the Initialization Data if it is not disabled by TSF 4. to carry out the Chip Authentication Protocol v.1 5. to carry out the Terminal Authentication Protocol v.1 6. to carry out the Active Authentication Protocol 7. to run self tests 4780 • the execution of following TSF-mediated actions before the user is authenticated 1. to establish the communication channel 2. carrying out the PACE Protocol 3. to read the Initialization Data if it is not disabled by TSF 4. to identify themselves by selection of the authentication key 4785 5. to carry out the Chip Authentication Protocol Version 1 6. to carry out the Terminal Authentication Protocol Version 1 7. to carry out the Active Authentication Protocol 8. to run self tests. 4790 Note Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 140 8 TOE Summary Specification (ASE_TSS) 1. If a user acts as (Travel Document) Manufacturer or Personalization Agent, the user acts as Administrator according to [Eviden-V60-ADM]. 8.1.1.1 Travel document manufacturer Identification and Authentication After the card leaves the Infineon site the IC Identification Data (a unique IC identifier) written 4795 by the IC Manufacturer according to • FMT_SMF.1 (1) allows tracing of the travel document. The travel document manufacturer needs a procedure provided by the developer of the TOE to start his tasks (the card is secured as modeled by FMT_MTD.1/INI_ENA) according to 4800 • FMT_SMF.1 (1) + (2) which includes import the Initialization Data and Pre-personalization Data in the audit records (FAU_SAS.1) which contains at least the Personalization Agent Key(s) used for the symmetric authentication mechanism (c.f. FCS_COP.1/AES_MAC). The travel document manufacturer creates also 4805 • file system including MF and ICAO.DF and • the ePassport application. Writing the Initialization Data and Pre-personalization Data are managed by FMT_MTD.1/INI_ ENA. With FMT_SMR.1/PACE (1) the TOE maintains the role of the Manufacturer. 4810 Reading of the PACE passwords is not allowed according to FMT_MTD.1/KEY_READ. 8.1.1.2 Personalization Agent Identification and Authentication With FMT_SMR.1/PACE (2) the TOE maintains the role of the Personalization Agent. The Personalization Agent is identified and authenticated according to • FIA_UAU.1/PACE (4) 4815 and the authentication data is not reused according to • FIA_UAU.4/PACE (2) using the Symmetric Authentication Mechanism provided by • FIA_UAU.5.1/PACE (4) and the authentication attempt is accepted according to 4820 • FIA_UAU.5.2/PACE rule (2). The usage of the • Personalization Agent Key(s) emit no information about IC power consumption in excess of unintelligible limits and any user is unable to gain access by the card interfaces to this keys according to FPT_EMS.1 (5). 4825 The Personalization Agent performs MRTD Configuration for files (e.g. LDS data groups and EF.SOD) and for objects (e.g. for keys). The tasks of the Personalization Agent are specified by FMT_SMF.1 (3) + (4). The Personalization Agent is allowed to read out • the Initialization Data and the Pre-personalization Data according to FMT_MTD.1/INI_DIS 4830 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 141 8 TOE Summary Specification (ASE_TSS) and he is allowed to read the Initialization Data before he is identificated and authenticated according to • FIA_UID.1/PACE (3) • FIA_UAU.1/PACE (3). Personalization Agent is identified using FIA_UAU.1/PACE (4) by selecting his key. 4835 If the Personalization Agent is identificated and authenticated successfully, he is allowed to perform following tasks: 1. Writing (i) initial Country Verifying Certification Authority Public Key: PK.CVCA, (ii) initial Country Verifying Certification Authority Certificate: C.CVCA, 4840 (iii) initial Current Date, according to FMT_MTD.1/CVCA_INI (iv) the Document Security Object (SOD) according to FMT_MTD.1/PA. 2. Loading 4845 (v) Chip Authentication Private Key and Active Authentication Private Key according to FMT_MTD.1/CA_AA_PK. No one is able to read the Chip Authentication Private Key or Active Authentication Private Key after loading it according to FMT_MTD.1/KEY_READ. 3. Loading 4850 (vi) Chip Authentication Private Key according to FMT_MTD.1/CA_AA_PK (vii) Active Authentication Private Key according to FMT_MTD.1/CA_AA_PK. No one is able to read the Chip Authentication Private Key or Active Authentication 4855 Private Key after loading it according to FMT_MTD.1/KEY_READ. With FPT_TST.1 the TOE checks previously the correct functioning of the cryptographic routines. Before issuing the TOE to the travel document holder the Personalization Agent • has to block the read and use access to the Initialization Data. 4860 This is done to prevent misuse, see [BSI-CC-PP-0068-V2-2011-MA-01] application note 49. Additionally the Personalization Agent shall invalidate his key(s). 8.1.1.3 PACE Terminal Identification and Authentication With FMT_SMR.1/PACE (3) + (4) the TOE maintains the role of a Terminal and PACE authenti- cated BIS-PACE. 4865 A user in the role terminal is • a PACE Terminal after the PACE or “PACE with CAM” protocol is successfully performed using secure messaging in MAC-ENC mode according • FIA_UAU.5.1/PACE (3). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 142 8 TOE Summary Specification (ASE_TSS) After the PACE protocol is successfully performed the TOE accepts only commands sent by 4870 means of secure messaging according to • FIA_UAU.5.2/PACE (1). With FIA_UAU.4/PACE (1) the TOE prevents reuse of authentication data and with FIA_ UAU.6/PACE the TOE re-authenticate the PACE Terminal by verifying each commands sent. A user in the role terminal is allowed to carry out the PACE protocol according to 4875 • FIA_UID.1.1/PACE (2) • FIA_UAU.1.1/PACE (2) before the user is identification or authenticated. After performing PACE protocol the terminal shall perform (depending on it’s ability) • the Advanced Inspection Procedure with PACE 4880 • the Active Authentication Protocol. 8.1.1.4 Establishing the trusted channel With FTP_ITC.1/PACE the TOE • provides a communication channel between itself and another trusted IT product • permits another trusted IT product to initiate communication via the trusted channel 4885 • enforces communication via the trusted channel for any data exchange between the TOE and the Terminal which is supported in case of a PACE protocol by • FCS_CKM.1/DH_PACE_EC or FCS_CKM.1/DH_PACE_RSA for PACE session key derivation (with MRZ or CAN as password) 4890 and FIA_UAU.5.1/PACE (3) for secure messaging using 1. FCS_COP.1/PACE_ENC for confidentiality (by encrypting the data) 2. FCS_COP.1/PACE_MAC for integrity (by MACing the commands). or in case of a Chip Authentication protocol v.1 by 4895 • FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA for Chip Authentication session key derivation (using the Chip Authentication Public Key) and FIA_UAU.5.1/PACE (3) for secure messaging using 1. FCS_COP.1/CA_ENC for confidentiality (by encrypting the data) 4900 2. FCS_COP.1/CA_MAC for integrity (by MACing the commands). and (when transmitting and receiving user data) • FDP_UCT.1/TRM by protecting from unauthorized disclosure • FDP_UIT.1/TRM by protecting from modification, deletion, insertion and replay errors and by determining on receipt of user data, whether modification, deletion, insertion 4905 and replay has occurred. After the trusted channel is established the TOE does not execute any command with incorrect message authentication code according to • FIA_UAU.6/EAC in case of a Chip Authentication protocol v.1 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 143 8 TOE Summary Specification (ASE_TSS) • FIA_UAU.6/PACE in case of a PACE protocol. 4910 The usage of session keys • {CA-K.MAC, CA-K.Enc} (generated during Chip Authentication) • {PACE-K.MAC, PACE-K.Enc} (generated during PACE) and • ephemeral domain parameters {ephem-SK.PICC.PACE, ephem-PK.PICC.PACE} (used for 4915 starting of ECDH for PACE) emit no information about IC power consumption in excess of unintelligible limits and any user is unable to gain access by the card interfaces to these keys according to FPT_EMS.1 (1) + (2) + (3). After the trusted channel is terminated the session keys and the ephemeral private key 4920 ephem-SK.PICC.PACE are invalidated according to • FCS_CKM.4 • FDP_RIP.1. and • the security attribute PACE Authentication (see FDP_ACF.1.1/TRM) is unset 4925 • the security attribute Terminal Authentication Status is set to “none”. 8.1.2 User Identification and Authentication (eSign) This security function is responsible for the identification and authentication of the user roles (FMT_SMR.1) • Administrator 4930 • Signatory • PACE Terminal by the methods: • PACE authentication method1 according to [BSI-TR-03110-1-V220] and [BSI-TR-03110-2- V221] (FIA_UID.1.1(2), FIA_UAU.1.1(5) and FIA_UAU.5/PACE) 4935 – It uses a. PIN.CH, b. optionally PUK.CH, c. PIN.T, d. PIN.ADMIN or 4940 e. CAN as passwords. – In the first step of the method a random nonce (FCS_RNG.1) encrypted with the password using the cryptographic algorithm AES is transmitted from the TOE to a terminal (FIA_UAU.4/PACE). – The method is configured to set the card to a suspended state before the password 4945 is finally blocked (only PIN.CH, PUK.CH, PIN.T and PIN.ADMIN) (FIA_AFL.1/Suspend_ PIN and FIA_AFL.1/Block_PIN) or to delay the processing of the authentication command after a failed authentication (CAN) (FIA_AFL.1/PACE). 1 The PACE authentication method is only applicable in cases where the communication between the TOE and another entity via trusted channel is mandatory. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 144 8 TOE Summary Specification (ASE_TSS) – The cryptographic method for confidentiality is AES/CBC (supplied by FCS_ COP.1/PACE_ENC). 4950 – The cryptographic method for authenticity is CMAC (supplied by FCS_COP.1/PACE_ MAC). – On error (wrong MAC, wrong challenge) the user role is not identified/authenticated. – A usage counter of 15-60 prevents the unlimited usage of PUK.CH. – On success the session keys are created and stored for Secure Messaging (FCS_ 4955 CKM.1/DH_PACE). – Keys and data in transient memory are overwritten after usage (FCS_CKM.4). • Secure Messaging (FIA_UAU.1.1(3), FIA_UAU.1.1(4) and FIA_UAU.5/PACE) – The cryptographic method for confidentiality is AES/CBC (supplied by FCS_ COP.1/PACE_ENC, FCS_COP.1/CA_ENC). 4960 – The cryptographic method for authenticity is CMAC (supplied by FCS_COP.1/PACE_ MAC, FCS_COP.1/CA_MAC). – In a Secure Messaging protected command the method for confidentiality and the method for authenticity must be present. – A derived session key is used. 4965 – Any command protected correctly with the session keys is considered to be sent by the successfully authenticated user (FIA_UAU.6/PACE, FIA_UAU.6/CA). – On any command that is not protected correctly with the session keys these are overwritten and a new PACE authentication is required. – Keys and data in transient memory are overwritten after usage (FCS_CKM.4). 4970 • PIN authentication mechanism using – the PIN for qualified signature (PIN.QES) as PIN * PIN.QES is a password with a minimum length of 6 digits for authentica- tion data that is blocked after an administrator configurable positive integer within 3 up to floor(MINLEN/2) consecutive failed authentication attempts 4975 (FIA_AFL.1/RAD) * The transmission of the PIN.QES must be protected by Secure Messaging with PACE for all communication interfaces. • Symmetric Authentication Mechanism (FIA_UID.1.1(3), FIA_UAU.1.1(6), FIA_ UAU.4.1/PACE(2), FIA_UAU.5.1/PACE(4) and FIA_UAU.5.2/PACE(2)) 4980 – The cryptographic method for authenticity is CMAC (supplied by FCS_COP.1/AES_ MAC). – The method is configured to delay the processing of the authentication command after consecutive failed authentication attempts (FIA_AFL.1/AuthAdmin). • Chip Authentication Protocol Version 12 according to [BSI-TR-03110-1-V220] (FIA_ 4985 UAU.5/PACE) – The cryptographic method for confidentiality is AES/CBC (supplied by FCS_ COP.1/CA_ENC). – The cryptographic method for authenticity is CMAC (supplied by FCS_COP.1/CA_ MAC). 4990 – On error the user role is not identified/authenticated. 2 The Chip Authentication Protocol Version 1 is only applicable in cases where the communication between the TOE and another entity via trusted channel is mandatory. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 145 8 TOE Summary Specification (ASE_TSS) – On success the session keys are created and stored for Secure Messaging (FCS_ CKM.1/CA). – Keys and data in transient memory are overwritten after usage (FCS_CKM.4). • Passive Authentication3 for the verification of the authenticity of EF.CardSecurity (FIA_ 4995 UAU.5/PACE) – EF.CardSecurity is signed by the SSCD-provisioning service provider allowing a PACE terminal to verify the authenticity of the TOE. – It contains the Chip Authentication Public Key which is used for identifying the SSCD. 5000 The access control methods allow the execution of certain security relevant actions (e.g. self-tests) without successful user identification (FIA_UID.1) and authentication (FIA_UAU.1). 8.1.2.1 Administrator Identification and Authentication Depending on the life cycle phase the administrator can gain access to the TOE in two different ways: 5005 For the Life Cycle Phase “Personalization”: The administrator is implicitly identified at the beginning of the Phase “Person- alization” represented by the TOE life cycle phase MANUFACTURING. Before the administrator is able to start the TOE initialization, the command sequence received by the TOE software developer has to be performed, since the initial StartKey is not 5010 known to the administrator. The command sequence changes the secret StartKey (initial StartKey) to a default value (“default” in the sense of “the same value for each SSCD-provisioning service provider”) which is known to the administrator. It is mandatory that the administrator change this default value to a value only known to him. 5015 With this administrator-known (but otherwise secret) value for the StartKey, the TOE’s life cycle can be switched from the MANUFACTURING to the ADMINISTRA- TION phase in order to carry out the TOE initialization and TOE personalization which comprises all the tasks performed by an SSCD-provisioning service provider during preparation of the TOE (see section Life Cycle Phases Mapping Phase 5020 “Personalization”). In order to separate the TOE initialization from the TOE personalization a re- authentication of the administrator is necessary. The TOE is switched from phase ADMINISTRATION to phase OPERATIONAL (permanently) after TOE initialization. The TOE personalization is secured by using the Symmetric Authentication Mecha- 5025 nism with the Administrator Personalization Key which is used to re-authenticate the administrator in order to allow the TOE to be switched back to phase ADMIN- ISTRATION before the personalization tasks can be performed. This TOE behavior is modeled by the SFRs FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS and FMT_MTD.1/PA. 5030 Notes 1. After the TOE has been (permanently) switched to phase OPERATIONAL it is only possible to switch it temporarily to phase ADMINISTRATION. In this sense ADMINISTRATION can be seen rather as a state than as a life cycle phase of 5035 the TOE. After a reset the TOE is always in phase OPERATIONAL. 2. The TOE initialization and TOE personalization may only take place in a trusted environment. (A.Env_Admin) 3 Passive Authentication is only applicable in cases where the communication between the TOE and another entity via trusted channel is mandatory. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 146 8 TOE Summary Specification (ASE_TSS) For the Life Cycle Phase “Operational Use”: The administrator is identified and authenticated by using the PACE authentication 5040 method using the PIN.ADMIN as the shared password in the Phase “Operational Use” represented by the TOE life cycle phase OPERATIONAL. Note 1. By successfully authenticating himself using the PACE authentication method 5045 with PIN.ADMIN as the shared password the administrator sets the security attribute “SCD/SVD management” to “authorized” (FMT_SMF.1 and FMT_MSA.2). Before performing any management operations including the generation of the certificate thus including the SVD export from the TOE, the CGA or SSCD Issuing Application establishes the identity of the TOE as SSCD by 5050 • reading and verifying EF.CardSecurity using Passive Authentication (FIA_ UAU.5/PACE) • using the Public Key from EF.CardSecurity together with Chip Authentication Protocol Version 1 to authenticate the SSCD (FIA_API.1). SCD/SVD generation, SVD export from the TOE in this phase require an interac- 5055 tion with the SSCD-provisioning service provider or certification service provider (CSP) acting as administrator through a trusted channel established by the Chip Authentication Protocol Version 1 (FTP_ITC.1/SVD). (A.Env_Admin and A.CGA). Additionally management operations, e.g. store certificate info to the SSCD in this phase also require an interaction with the SSCD-provisioning service provider acting 5060 as administrator through a trusted channel established by the Chip Authentication Protocol Version 1. 8.1.2.2 Signatory Identification and Authentication Within the Phase “Operational Use” represented by the TOE life cycle phase OPERATIONAL the signatory is identified and authenticated either 5065 • by using the transport PIN (PIN.T) as the shared password with the PACE authentication method on first usage upon receiving the TOE from the SSCD-provisioning service provider in order to disable the transport protection and activate (FMT_SMF.1) – the PIN for qualified signature (PIN.QES), – optionally the personal unblocking key (PUK.CH), if present and not already 5070 activated.4 Notes 1. The transport PIN (PIN.T) cannot be modified and can be used only once. 2. The ability to activate the PIN of the Signatory (PIN.QES) is restricted to the 5075 signatory only after disabling the transport protection (FMT_MTD.1/RAD). 3. If the transport PIN is not entered successfully or the transport PIN is blocked, the Signatory cannot be identified or authenticated. 4. If the transport PIN is entered successfully, it is not possible to enter a transport PIN again. 5080 4 If provision comprises a PUK letter, PUK.CH is already activated. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 147 8 TOE Summary Specification (ASE_TSS) 5. If the PIN of the Signatory (PIN.QES) is not set, it is not possible to enter the PIN of the Signatory (PIN.QES) successfully and it is not possible to block the PIN of the Signatory (PIN.QES) with unsuccessful consecutive authentication attempts. • by using the optional personal unblocking key (PUK.CH) as the shared password with 5085 the PACE authentication method in order to establish a trusted channel between the HID and the TOE for the management environment (FTP_ITC.1/VAD) allowing – to unblock the PIN for qualified signature (PIN.QES) while ensuring the confidentiality and integrity of the VAD (FMT_MTD.1/Signatory). – to unblock the transport PIN (PIN.T5 ) and the card holder PIN (PIN.CH) while 5090 ensuring the confidentiality and integrity of the VAD. – the modification of the personal unblocking key (PUK.CH) and the card holder PIN (PIN.CH) while ensuring the confidentiality and integrity of the VAD. 5095 Note 1. PUK.CH must be used as shared password for the PACE authentication method. • by verifying the PIN for qualified signature (PIN.QES) with the PIN authentication mech- anism in order to 5100 – create qualified electronic signatures, – modify the PIN for qualified signature (PIN.QES) itself (FMT_SMF.1 and FMT_ MTD.1/Signatory), Note 5105 1. By successfully authenticating himself using PIN verification with the PIN for qualified signature (PIN.QES) the signatory sets the security attribute “SCD operational” to “yes” (FMT_SMF.1 and FMT_MSA.2). The TOE ensures re-authentication of the signatory for signature creation (FIA_ UAU.6/Signature_Creation) 5110 a) after each signature if the personalization allows only a single signature, b) after card reset or after Application QES was left or before the (N+1)-th signature in a row when limit for consecutive signatures is N if the personalization allows a limited number of mass signatures in a row, 5115 c) after card reset or after Application QES was left if the personalization allows an unlimited number of mass signatures in a row. 5 While PIN.T can only be used successfully once, it is still subject to the PIN suspend and block mechanism. Hence, to avoid denial-of-service attacks on PIN.T, it may be unblocked using PUK.CH. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 148 8 TOE Summary Specification (ASE_TSS) 8.1.2.3 PACE Terminal Identification and Authentication Within the Phase “Operational Use” represented by the TOE life cycle phase OPERATIONAL the PACE Terminal is identified and authenticated by using the PACE authentication method 5120 using any of the available shared passwords (PIN.T, PIN.CH, optional PUK.CH, PIN.ADMIN and CAN) in order to establish a trusted channel between the HID and the TOE for both the signing and management environments or between the CGA or an issuer SSCD management application and the TOE for the management environment. An identified and authenticated PACE Terminal is allowed to access EF.CardSecurity and 5125 exchange data with the TOE. Depending on the shared password used with the PACE authentication method an additional user may be identified and authenticated and additional operations are allowed: • by using the PACE authentication method using the transport PIN (PIN.T) as the shared password on first usage upon receiving the TOE from the SSCD-provisioning service 5130 provider in order to additionally identify and authenticate the Signatory and establish a trusted channel between the HID and the TOE for disabling the transport protection and activating the RAD (FTP_ITC.1/VAD and FMT_SMF.1). • by using the PACE authentication method using the card holder PIN (PIN.CH) as the shared password in order to establish a trusted channel between the HID and the TOE 5135 for both the signing and management environments (FTP_ITC.1/VAD and FTP_ITC.1/DTBS) allowing – the verification of the PIN for qualified signature (PIN.QES) while ensuring the confidentiality and integrity of the VAD, – the creation of qualified electronic signatures6 while ensuring the integrity of the 5140 DTBS respective DTBS/R (A.SCA), – the modification of the PIN for qualified signature (PIN.QES)7 and the card holder PIN (PIN.CH) itself while ensuring the confidentiality and integrity of the VAD (FMT_ SMF.1). 5145 Notes 1. Using PIN.CH as shared password used with the PACE authentication method only identifies and authenticates the PACE Terminal. 2. For the TOE PIN.CH is only used as shared password for the PACE authentication method. 5150 • by using the PACE authentication method using the optional personal unblocking key (PUK.CH) as the shared password in order to additionally identify and authenticate the Signatory and establish a trusted channel between the HID and the TOE for the management environment (FTP_ITC.1/VAD) allowing – to unblock the PIN for qualified signature (PIN.QES) while ensuring the confidential- 5155 ity and integrity of the VAD (FMT_MTD.1/Signatory), – to unblock the transport PIN (PIN.T) and the card holder PIN (PIN.CH) while ensuring the confidentiality and integrity of the VAD, – the modification of the personal unblocking key (PUK.CH) and the card holder PIN (PIN.CH) while ensuring the confidentiality and integrity of the VAD. 5160 • by using the PACE authentication method using the administrator PIN (PIN.ADMIN) as the shared password in order to additionally identify and authenticate the Administrator and establish a trusted channel between the CGA or an issuer SSCD management 6 Additionally requires verification of PIN.QES 7 Additionally requires verification of PIN.QES Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 149 8 TOE Summary Specification (ASE_TSS) application and the TOE for management environment (FTP_ITC.1/SVD, FTP_ITC.1/VAD and FTP_ITC.1/DTBS) allowing the execution of Chip Authentication Protocol Version 1. 5165 • by using the PACE authentication method using any PACE password as the shared password in order to additionally identify and authenticate the Administrator and establish a trusted channel between the CGA or an issuer SSCD management application and the TOE for management environment (FTP_ITC.1/SVD, FTP_ITC.1/VAD and FTP_ ITC.1/DTBS) allowing the execution of EAC with strong certificate. 5170 • by using the PACE authentication method using the CAN as the shared password in order to establish a trusted channel between the HID and the TOE for both the signing and management environments (FTP_ITC.1/VAD and FTP_ITC.1/DTBS) allowing – the verification of the PIN for qualified signature (PIN.QES) while ensuring the confidentiality and integrity of the VAD, 5175 – the creation of qualified electronic signatures8 while ensuring the integrity of the DTBS respective DTBS/R (A.SCA), – the modification of the PIN for qualified signature (PIN.QES)9 while ensuring the confidentiality and integrity of the VAD (FMT_SMF.1), – the execution of EAC with strong certificate and the unblocking and modi- 5180 fication of the card holder PIN (PIN.CH). – to authenticate against PIN.CH, PUK.CH, PIN.T or PIN.ADMIN for the very last retry after setting the relevant password into a suspended state as protection against denial-of-service attacks. 5185 Note 1. The CAN is a non-blocking password with a minimum length of 6 digits that does not effectively represent a secret, but is restricted-revealable. 8.1.2.4 EIS-AIP-PACE Identification and Authentication An Extended Inspection System (EIS) using successfully the Advanced Inspection Procedure 5190 with PACE is a EIS-AIP-PACE using a PACE Terminal. 8.1.3 Advanced Inspection Procedure with PACE An Inspection System is an Extended Inspection System after performing the all parts of the Advanced Inspection Procedure (AIP) successfully in this order: 1. The Inspection System uses an identified and authenticated PACE Terminal, see PACE 5195 Terminal Identification and Authentication, 2. the chip is authenticated successfully to the inspection system, see Chip Authentication Protocol v.1 3. the genuineness of the TOE is verified, see Passive Authentication 4. the terminal used by inspection system is authenticated successfully to the TOE, see 5200 Terminal Authentication Protocol v.1 If Advanced Inspection Procedure is performed successfully, the TOE sets the security at- tributes below (see FDP_ACF.1.1/TRM (3)): • PACE Authentication 8 Additionally requires verification of PIN.QES 9 Additionally requires verification of PIN.QES Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 150 8 TOE Summary Specification (ASE_TSS) • the security attribute Terminal Authentication Status accordingly to the roles defined in 5205 the certificate used for authentication. • the security attribute Terminal Authorization to the intersection of the Certificate Holder Authorizations defined by the Inspection System Certificate, the Document Verifier Certificate and Country Verifying Certification Authority which shall be all valid for the Current Date. 5210 8.1.4 Protocols The TOE support the following protocols. 8.1.4.1 PACE or “PACE with CAM” protocol The TOE accepts authentication using the PACE protocol according to • FIA_UAU.5.1/PACE (1) 5215 using • FCS_CKM.1/DH_PACE_EC or FCS_CKM.1/DH_PACE_RSA for PACE session keys which are also used for establishing the trusted channel, see Establishing the trusted channel. If the terminal uses a wrong password (not derived from MRZ or CAN), the TOE delays the next attempt to establish the PACE protocol at least 5 seconds according to 5220 • FIA_AFL.1/PACE. This prevents skimming of the passwords because the passwords are non-blocking authoriza- tion data. If the PACE protocol is performed successfully, the TOE sets the security attribute PACE Authentication (FDP_ACF.1.1/TRM (3.a)). 5225 Observe, that the TOE also support the chip-authentication mapping for PACE which com- bines PACE and the chip authentication protocol into a shorter command exchange between the terminal and the TOE. 8.1.4.2 Chip Authentication Protocol v.1 The terminal proves the identity of the TOE using Chip Authentication Protocol v.1 according 5230 to [BSI-TR-03110-1-V220] section “3.4 Chip Authentication Version 1” using • FIA_API.1/CA and • FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA for Chip Authentication session keys which are also used for establishing the trusted channel, see Establishing the trusted channel. After the Chip Authentication Protocol v.1 is successfully performed the TOE accepts only 5235 commands sent by means of secure messaging according to • FIA_UAU.5.2/PACE (3). With FMT_MTD.1/KEY_READ no user is able to read the Chip Authentication Private Key. After Chip Authentication Protocol v.1 the terminal has to validate the Chip Authentication Public Key by 5240 • performing Passive Authentication to verify the genuineness of the TOE. The usage of the • Chip Authentication Private Key Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 151 8 TOE Summary Specification (ASE_TSS) emit no information about IC power consumption in excess of unintelligible limits and any user is unable to gain access by the card interfaces to this keys according to FPT_EMS.1 (6). 5245 See Personalization Agent Identification and Authentication for the task loading the CA key pair. 8.1.4.3 Active Authentication Protocol The terminal proves the identity of the TOE using Active Authentication Protocol according to [ICAO-9303-2015] part 11, section 6.1, using 5250 • FIA_API.1/AA for providing the protocol and • FCS_COP.1/AA_SGEN_EC for signing the terminal’s nonce. With FMT_MTD.1/KEY_READ no user is able to read the Active Authentication Private Key. 5255 The TOE accepts Active Authentication according to • FIA_UAU.5.1/PACE (6). After Active Authentication Protocol the terminal has to validate the Active Authentication Public Key by • performing Passive Authentication to verify the genuineness of the TOE. 5260 The usage of the • Active Authentication Private Key emit no information about IC power consumption in excess of unintelligible limits and any user is unable to gain access by the card interfaces to this keys according to FPT_EMS.1 (7). See Personalization Agent Identification and Authentication for the task loading the AA key 5265 pair. 8.1.4.4 Terminal Authentication Protocol v.1 A terminal authenticates itself to the TOE using the Terminal Authentication Protocol v.1 according to [BSI-TR-03110-1-V220] section “3.5 Terminal Authentication Version 1” using • FIA_UAU.5.1/PACE (5) 5270 and • FCS_COP.1/SIG_VER_EC or FCS_COP.1/SIG_VER_RSA for verifying the certificate chain which is managed by • FMT_MTD.3 (the certificate chain to the trust anchor must be valid). With FIA_UAU.5.2/PACE (4) the TOE accepts only authentication attempts using the Chip Au- 5275 thentication Public Key presented during the Chip Authentication Protocol v.1 and the secure messaging established by the Chip Authentication Mechanism v.1, see Chip Authentication Protocol v.1 and Establishing the trusted channel. With FIA_UAU.4/PACE (3) the TOE prevents reuse of authentication data. The random nonce is generated using FCS_RNG.1. 5280 With FPT_TST.1 reading of a certificate and the generation of a random nonce is checked previously. If Terminal Authentication Protocol v.1 is performed successfully, the TOE Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 152 8 TOE Summary Specification (ASE_TSS) 1. sets the security attribute Terminal Authentication Status (see FDP_ACF.1.1/TRM) accord- ingly to the roles defined in the certificate used for authentication. It is possible that the 5285 security attribute contains more than one value, e.g. CVCA and IS. 2. sets the security attribute Terminal Authorization to the intersection of the Certificate Holder Authorizations defined by the Inspection System Certificate, the Document Verifier Certificate and Country Verifying Certification Authority which shall be all valid for the Current Date. 5290 3. updates the Current Date and trust anchor if necessary, see :Write access to data of the ePass application at phase Operational Use Note 1. Terminal Authentication v.1 can only be performed if Chip Authentication v.1 has been 5295 successfully executed. 8.1.4.5 Passive Authentication The terminal verifies the genuineness of the TOE (MRTD) according to [BSI-TR-03110-1-V220] section “1.1 Passive Authentication” by • verifying the signature of the SOD 5300 • reading the hash value of the Chip Authentication public key or the hash value of the Active Authentication public key stored on the chip (LDS data fields) • comparing the hash values with the hash values computed by the terminal / inspection system over the public keys received from the chip during the respective protocol. If the hash values are equal and signature is verified, the Passive Authentication is performed 5305 successfully. The TOE accepts Passive Authentication according to • FIA_UAU.5.1/PACE (2). For accessing the SOD and the LDS data fields see Read access to the data of the ePass application at phase Operational Use. 5310 Note 1. Performing Passive Authentication by verifying the signature of SOD and comparing the stored values with hash value computed by the terminal / inspection system cannot be enforced by the TOE. 5315 8.1.5 Access Control (General and ePass) This security enforces the Access Control SFP on general and ePass application related data. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 153 8 TOE Summary Specification (ASE_TSS) 8.1.5.1 Read access to the data of the ePass application at phase Operational Use Access to the Logical Travel Document (LTD) and SOD (EF.SOD) is allowed according to • FDP_ACC.1/TRM 5320 • FDP_ACF.1/TRM after Establishing the trusted channel according to FDP_ACF.1.4/TRM (2): 1. If security attribute PACE Authentication (FDP_ACF.1.1/TRM (3.a)) is set (i.e. the PACE or “PACE with CAM” protocol is performed successfully) then 5325 • the inspection system is allowed to read data objects ((FDP_ACF.1.2/TRM): DG1, DG2, DG14, DG15, DG16 and the Security Object SOD. 2. If security attribute Terminal Authentication Status (FDP_ACF.1.1/TRM (3.b)) has the value “IS” (i.e. the Advanced Inspection Procedure with PACE is performed successfully), the inspection system is a Extended Inspection System and allowed to read data objects: 5330 • DG1, DG2, DG14, DG15, DG16 and the Security Object SOD • DG3 if security attribute Terminal Authorization equals DG3 • DG4 if security attribute Terminal Authorization equals DG4 • DG3 and DG4 if security attribute Terminal Authorization equals DG3 / DG4. 5335 Notes 1. If the security attribute Terminal Authorization is set to one of the values “DG3” or “DG4” of “DG3 / DG4” and the terminal is not successfully authenticated as Extended Inspection System, the TOE denies access to data objects 2b) of FDP_ACF.1.1/TRM or data objects 2c) of FDP_ACF.1.1/TRM. 5340 2. If security attribute Terminal Authentication Status is set to one of the values “CVCA” or “DV (domestic)” or “DV (foreign)”, the TOE denies any inspection system the access to EF.DG3 or EF.DG4 (FDP_ACF.1.4/TRM (6)). 8.1.5.2 Write access to data of the ePass application at phase Operational Use With FMT_SMR.1/PACE (5), (6) + (7) the TOE maintains the roles of Country Verifying Certification 5345 Authority, Document Verifier and Domestic Extended Inspection System. The write access to the TOE phase Operational Use depends on role encoded in certificates. 1. A terminal in the role Country Verifying Certification Authority (security attribute terminal authentication status has the value CVCA) is allowed to update (the trust anchor) • Country Verifying Certification Authority Public Key, 5350 • Country Verifying Certification Authority Certificate according to FMT_MTD.1/CVCA_UPD if the Country Verifying CA Link-Certificates are valid (FMT_MTD.3) after • Terminal Authentication Protocol v.1 is successfully performed. 2. A terminal in the role 5355 • Country Verifying Certification Authority (security attribute terminal authentication status has the value CVCA) or Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 154 8 TOE Summary Specification (ASE_TSS) • Document Verifier (security attribute terminal authentication status has the value DV (domestic) or DV (foreign)) 5360 or • Domestic Extended Inspection System10 (security attribute terminal authentication status has the value IS) is allowed to modify • the Current Date 5365 according to FMT_MTD.1/DATE if the Country Verifying CA Link-Certificates are valid (FMT_ MTD.3) after • Terminal Authentication Protocol v.1 is successfully performed and • if the Current Date is before the effective date of the respective certificate. 5370 The Current Date is set to the maximum of the effective dates of valid CVCA, DV and domestic Inspection System certificates used during performing Terminal Authentication Protocol v.1. If operations (1) and (2) have to be performed both after Terminal Authentication Protocol v.1, they are implemented as an atomic operation, see [BSI-TR-03110-3-V221] section “2.5.1 General Procedure”. 5375 Please note that a prerequisite for performing successfully TA is a successfully performed Chip Authentication Protocol v.1. 8.1.5.3 General access to data This aspect of the security function controls • access to EF.CardSecurity of the TOE and 5380 • data exchange with the TOE. The TOE allows the access to EF.CardSecurity and data exchange with the TOE if and only if (FDP_ACC.1/TRM, FDP_ACF.1/TRM, FDP_UCT.1/TRM and FDP_UIT.1/TRM): 1. the access request is sent by an authorized PACE Terminal, see also section PACE Terminal Identification and Authentication 5385 2. the access request is sent in a manner protected from unauthorized disclosure, modifi- cation, deletion, insertion and replay errors. 8.1.6 Access Control (eSign) This security function regulates all access by external entities to operations of the TOE which are only executed after the TSF allowed access. The identification, authentication and associ- 5390 ation of users to roles is realized by section User Identification and Authentication (eSign). This security functions also • restricts the ability to read any keys or passwords (FMT_MTD.1/KEY_READ) • denies any access not explicitly allowed 10 From travel document’s point of view an Extended Inspection System is a domestic one if the Extended Inspection System is authorized by the issuing State or Organization. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 155 8 TOE Summary Specification (ASE_TSS) 8.1.6.1 Access Control provided by the Signature_Creation_SFP 5395 This aspect of the security function is responsible for the realization of the signature creation security function policy (Signature_Creation_SFP) and controls access to the signature creation functionality of the TOE. The Signature_Creation_SFP is based on the security attribute “SCD operational” which is managed by 5400 • FMT_MSA.1/Signatory • FMT_MSA.2 • FMT_MSA.3 The TOE allows the creation of electronic signatures for DTBS/R with SCD if and only if (FDP_ ACC.1/Signature_Creation, FDP_ACF.1/Signature_Creation, FDP_UIT.1/DTBS, FMT_MOF.1 and 5405 FMT_MSA.1/Signatory and FMT_MSA.2): 1. the transport protection is disabled 2. PACE authentication using PIN.CH or CAN as the shared password has been successfully performed 3. the security attribute “SCD/SVD Management” is set to “not authorized” or “authorized” 5410 4. the security attribute “SCD operational” is set to “yes” 5. the signature request is sent by an authorized signatory, see also section Signatory Identification and Authentication 6. the signature request is sent in a manner protected from modification and insertion errors 5415 8.1.6.2 Access Control provided by the SCD/SVD_Generation_SFP This aspect of the security function is responsible for the realization of the SCD/SVD pair generation security function policy (SCD/SVD_Generation_SFP) and controls access to the SCD/SVD pair generation functionality of the TOE. The SCD/SVD_Generation_SFP is based on the security attribute “SCD/SVD Management” 5420 which is managed by • FMT_MSA.1/Admin • FMT_MSA.2 • FMT_MSA.3 Depending on the life cycle phase the TOE allows the generation of SCD/SVD pair either by 5425 the administrator alone or by the administrator together with the signatory: For the Life Cycle Phase “Composite Product Integration and Initialization” or “Personal- ization”: During the preparation of the TOE (see section Life Cycle Phases Mapping Phase “Initialization” and “Personalization”) the TOE allows the (optional) generation of SCD/SVD pair if and only if 5430 (FDP_ACC.1/SCD/SVD_Generation, FDP_ACF.1/SCD/SVD_Generation, FMT_MSA.1/Admin, FMT_ MSA.2 and FMT_MSA.4): 1. the security attribute “SCD/SVD Management” is set to “authorized” 2. the security attribute “SCD operational” is set to “no” 3. the generation request is sent by an authorized administrator, see also Administrator 5435 Identification and Authentication Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 156 8 TOE Summary Specification (ASE_TSS) The (re-)generation of the SCD/SVD key pair is also possible in the Phase “Operational use” as detailed in the following section. For the Life Cycle Phase “Operational use”: During the operation of the TOE (see section Life Cycle Phases Mapping Phase “Operational 5440 Use”) the TOE allows the (re-)generation of SCD/SVD pair if and only if (FDP_ACC.1/SCD/SVD_ Generation, FDP_ACF.1/SCD/SVD_Generation, FMT_MSA.1/Admin and FMT_MSA.2): 1. PACE authentication using PIN.ADMIN as the shared password has been successfully performed 2. Chip Authentication Protocol Version 1 has been successfully performed 5445 3. the security attribute “SCD/SVD Management” is set to “authorized” 4. the generation request is sent by an authorized administrator, see also section Adminis- trator Identification and Authentication or 1. PACE authentication using any PACE password as the shared password has been suc- 5450 cessfully performed 2. EAC with strong certificate has been successfully performed 3. the security attribute “SCD/SVD Management” is set to “authorized” 4. the generation request is sent by an authorized administrator, see also section Adminis- trator Identification and Authentication 5455 Notes 1. Strong Certificate contains Certificate Holder Authorization Template (effective autho- rization) with right “Install Qualified Certificate” set - see [BSI-TR-03110-4-V221] , chapter 2.2.3.2 Table 4 “Authorization of Authentication Terminals”. 5460 2. RSA SCD/SVD pair generation is only allowed to be performed in a trustworthy environ- ment. For details refer to the guidance documentation. 8.1.6.3 Access Control provided by the SVD_Transfer_SFP This aspect of the security function is responsible for the realization of the SVD transfer security function policy (SVD_Transfer_SFP) and controls access to the SVD export functionality of the 5465 TOE. The TOE allows the export of the SVD if and only if (FDP_ACC.1/SVD_Transfer and FDP_ ACF.1/SVD_Transfer): 1. PACE authentication using PIN.ADMIN as the shared password has been successfully performed 5470 2. Chip Authentication Protocol Version 1 has been successfully performed 3. the export request is sent by an authorized administrator, see also section Administrator Identification and Authentication 4. the exported SVD is sent in a manner to provide the CGA with the ability to verify evidence of the validity of the SVD (FDP_DAU.2/SVD). 5475 Note 1. Chip Authentication Protocol Version 1 shall be used in order to provide the CGA with the ability to verify the identity of the SSCD. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 157 8 TOE Summary Specification (ASE_TSS) or 5480 1. PACE authentication using any PACE password as the shared password has been suc- cessfully performed 2. EAC with strong certificate has been successfully performed 3. the export request is sent by an authorized administrator, see also section Administrator Identification and Authentication 5485 4. the exported SVD is sent in a manner to provide the CGA with the ability to verify evidence of the validity of the SVD (FDP_DAU.2/SVD). Note 1. Strong Certificate contains Certificate Holder Authorization Template (effective autho- 5490 rization) with right “Install Qualified Certificate” set - see [BSI-TR-03110-4-V221] , chapter 2.2.3.2 Table 4 “Authorization of Authentication Terminals”. 8.1.7 Key management This security function is responsible for the management of • the SCD/SVD pair which is used by the signatory to create electronic signatures. This 5495 includes the correct generation and the termination of the SCD/SVD pair. • the Chip Authentication Private Key which is used during Chip Authentication Protocol Version 1 in order to prove the identity of the SSCD. The TOE supports onboard generation of a) EC signature key pairs for keys as detailed in Elliptic curves used (FCS_CKM.1/EC) and 5500 b) RSA signature key pairs for key as detailed in RSA key support (FCS_CKM.1/RSA). The generation is done with secure values for SCD/SVD parameters so that the key pairs fulfill the corresponding requirements of the standards: • EC key pairs [ANSI-X9.62], [ISO-IEC-14888-3] and [IEEE-1363] (FCS_CKM.1/EC) • RSA key pairs [RSA-PKCS1-v2.2] and [IEEE-1363] (FCS_CKM.1/RSA). 5505 The TOE uses the hybrid deterministic random number generator specified by FCS_RNG.1 for the generation of the SCD/SVD pair. The generation is furthermore protected against electromagnetic emanation, power analysis, timing and other side channel attacks, see also section Protection below. In the case that a signature key pair is terminated on request of the signatory, the signature 5510 key pair will be deleted by the TOE (FCS_CKM.4). The signatory is also able to terminate the signature key pair by blocking the signature key. The SCD is identified by security attribute “SCD identifier”. The security attribute “SCD identifier” may have arbitrary values. The Administrator can set/change security attribute “SCD identifier” to a desired value (FMT_SMF.1). The Administrator is thus able to override the default values 5515 when an object or information (here: SCD) is created (FMT_MSA.3). Only during the preparation of the TOE (see section Life Cycle Phases Mapping Phase “Personalization”) the TOE allows to load the Chip Authentication Private Key if and only if the import request is sent by an authorized administrator, see also section Administrator Identification and Authentication (FMT_MTD.1/CAPK). 5520 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 158 8 TOE Summary Specification (ASE_TSS) 8.1.8 Signature Creation This security function is responsible for signature creation using the SCD of the signatory. Before a signature is created by the TOE, the signatory has to be authenticated successfully, see also section Signatory Identification and Authentication. Depending on its configuration the TOE allows to create single or mass signatures11 . 5525 Note 1. Mass signatures are allowed only in a trusted environment (A.Env_Mass_Signature). 8.1.8.1 Signature Creation with EC This aspect of the security function creates EC signatures (FCS_COP.1/EC) for hash values using 5530 the SCD of the signatory. The signatures created meet the following standards: • section 7.3 in [ANSI-X9.62], • section 6.4.3 in [ISO-IEC-14888-3] and • section 7.2.7 in [IEEE-1363] The security function supports EC key lengths of 256, 384, 512, and 521 bits bits using 5535 curves as detailed in section Elliptic curves used. 8.1.8.2 Signature Creation with RSA This aspect of the security function creates RSA signatures (FCS_COP.1/RSA) for hash values with PKCS1 or PSS padding using the SCD of the signatory. The signatures created meet the following standards: 5540 • section 5.2.1 RSASP1 in [RSA-PKCS1-v2.2] and • section 8.2.4 in [IEEE-1363] The padding is done according to RSASSA-PSS and RSASSA-PKCS1-v1_5. The security function supports RSA key lengths of the supported key detailed in section RSA key support (FCS_COP.1/RSA). 5545 8.1.8.3 TOE IT environment generated hash values The hash value used for the signature creation is calculated over the DTBS in the TOE IT environment and sent to the TOE under the control of the Signature_Creation_SFP, see section Access Control provided by the Signature_Creation_SFP. 11 Mass signature generation is used to create either a limited or unlimited number of electronic signatures in a row for an automated process. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 159 8 TOE Summary Specification (ASE_TSS) 8.1.8.4 TOE generated hash values 5550 In case that DTBS instead of a hash value (DTBS/R) is sent to the TOE under the control of the Signature_Creation_SFP, see section Access Control provided by the Signature_Creation_ SFP, the TOE directly generates a hash value (FCS_COP.1/SHA) over the sent DTBS first which is used afterward for the signature creation. 8.1.8.4.1 Hash last round 5555 In case that the hash value (DTBS/R) is only partly computed in the IT environment an intermediate hash value with the remainder of DTBS is sent to the TOE under the control of the Signature_Creation_SFP, see section Access Control provided by the Signature_Creation_SFP. The TOE first computes the ‘last round(s)’ over the remainder of DTBS and the intermediate hash value (FCS_COP.1/SHA). The final hash value is used afterward for the signature creation. 5560 1. Last round hash values may be used if a signature for large data shall be generated as the IT environment is able to hash much faster than the card. 8.1.9 Test features According to FMT_LIM.1 and FMT_LIM.2 the TOE is designed in a manner that limits the • capabilities of TSF 5565 • availability of TSF to enforce the following policy Deploying Test Features after TOE Delivery does not allow, 1. User Data to be manipulated and disclosed, 2. TSF data to be disclosed or manipulated, 5570 3. software to be reconstructed, 4. substantial information about construction of TSF to be gathered which may enable other attacks and 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. The Test Features are disabled before the card leaves IC Manufacturer’s site. 5575 8.1.10 Protection This Security Service is responsible for the protection of the TSF, TSF data and user data. The TOE runs a suite of tests to demonstrate the correct operation of the security assumptions provided by the IC platform that underlies the TSF. The following tests are performed during initial start-up (FPT_TST.1): 5580 • The SLC52GDA448* provides a high security initialization software concept. The self test software (STS) is activated by the chip after a cold or warm reset (ISO-reset with I/O=1). It contains diagnostic routines for the chip, see [Infineon-Chip-HW-Ref-16bit-V01], 6.2.4 Power-up and references to High-security boot-up software (BOS). • After erasure of RAM the state of the User EEPROM is tested and, if not yet initialized, 5585 this will be done. • The User EEPROM heap is checked for consistency. If it is not valid, the TOE will preserve a secure state (life cycle DEATH). • The backup buffer is checked and its data is restored to User EEPROM, if they were saved because of a command interruption. 5590 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 160 8 TOE Summary Specification (ASE_TSS) • The integrity of stored TSF executable code is verified. If this check fails, the TOE will preserve a secure state (life cycle DEATH). • The integrity of stored data (objects and files) is verified before their use. • The hardware sensors, the symmetric coprocessor and the random number generator are tested. If one of the tests fails, the chip platform will perform a security reset. 5595 The TOE will furthermore run tests during 1. start-up 2. Reading Initialization and Pre-personalization Data according to “FMT_MTD.1/INI_DIS” 3. Reading data of LDS groups and EF.SOD 4. Reading CA keys (secret key is used only internally by the TOE) 5600 5. Cryptographic key generation according to “FCS_CKM.1/DH_PACE_EC”, “FCS_CKM.1/DH_ PACE_RSA”, “FCS_CKM.1/CA_EC” and “FCS_CKM.1/CA_RSA” 6. Reading certificates internally before Terminal Authentication Protocol v.1 according to “FCS_COP.1/SIG_VER_EC” or “FCS_COP.1/SIG_VER_RSA” 7. Generating random numbers according to “FCS_RNG.1” 5605 8. the generation of the SCD/SVD pair 9. and during signature creation according to FPT_TST.1. The correct operation of generation of the key pairs is demonstrated by performing the following checks: 5610 • Before a random number is used for the generation of a key pair the correct functioning of the random number generator is checked by enforcing all self-test and re-seeding requirements in accordance to FCS_RNG.1. Furthermore the TOE checks • all command parameters for consistency 5615 • access rights. If a critical failure occurs during these tests, the TOE will preserve a secure state according to FPT_FLS.1. This comprises the following types of failures: • Failure of sensors • Failure of Active Shield 5620 • Failure of cryptographic operation, e.g. during key creation • Memory failures during TOE execution • Out of range failures of temperature, clock and voltage sensors • Failures during random number generation The TOE is furthermore able to detect physical manipulation and physical probing (FPT_PHP.1 5625 and FPT_PHP.3). This comprises tampering attempts before start-up and during operation. If the underlying IC hardware is attacked by physical or mechanical means, the TOE will respond automatically in form of a continuously generated reset and the TOE functionality will be blocked. The TOE protects itself against interference and logical tampering by the following measures: 5630 Each application removes its own data from the used memory area at the latest after execution of a command. • Clearance of sensitive data, as soon as possible (when they are dispensable) according to FCS_CKM.4 and FDP_RIP.1 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 161 8 TOE Summary Specification (ASE_TSS) • No parallel but only serial execution of commands 5635 • Encapsulation of context data (security relevant status variables, etc.) • Use of the chips MMU (Memory Management Unit) • Separation of User ROM and Test ROM, where the chip’s self test software is located, and to which entries are not possible (apart from cold or warm reset) • Removal of channel data, when the channel is closed 5640 The TOE protects itself against bypass by not allowing any function in the TSF to proceed if a prior security enforcement function was not executed successfully. The TOE always checks that the appropriate user is successfully authenticated (cf. User Identification and Authentication (ePass) and User Identification and Authentication (eSign)) for a certain action. 5645 With FPT_EMS.1 and FPT_EMS.1/SSCD the TOE ensures any users are unable to use the following interface smart card circuit contacts to gain access to • Chip Authentication Session Keys • PACE Session Keys (PACE-K.MAC, PACE-K.Enc), • the ephemeral private key ephem-SK.PICC.PACE, 5650 • Personalization Agent Key(s) and • Chip Authentication Private Key and • Active Authentication Private Key • Signature Creation Keys • the RAD 5655 The TOE provides contact-based and contactless interfaces and is able to connect itself (i) with terminals which provide a contactless interface (ii) with terminals which provide a contact-based interface. In the case that the TOE is connected using it’s contactless interface the TOE accepts attempts to establish a connection using it’s contact-based interface by 5660 (i) resetting first it’s contactless interface (ii) restarting using it’s contact-based interface only. If the TOE is connected using it’s contact-based interface, the TOE does not accept any attempt to establish a connection using it’s contactless interface. The following data persistently stored by TOE has the user data attribute “integrity checked 5665 persistent stored data” (FDP_RIP.1): • SCD • SVD Also the DTBS/R temporarily stored by the TOE has the user data attribute “integrity checked stored data” (FDP_RIP.1). 5670 If the integrity of SCD, SVD or DTBS/R is violated, the TOE will prohibit the usage of the altered data and inform the signatory about the integrity error by means of an error code (FDP_ SDI.2/Persistent and FDP_SDI.2/DTBS). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 162 8 TOE Summary Specification (ASE_TSS) 8.2 Compatibility between the Composite ST and the Platform-ST 5675 IP_SFR Irrelevant Platform SFR RP_SFR-SERV Relevant Platform-SFRs being used by the Composite-ST to implement a security service with associated TSFI. RP_SFR-MECH Relevant Platform SFRs being used by the Composite-ST because of its secu- rity properties providing protection against attack to the TOE as a whole 5680 IrOE Objectives for the environment not being relevant for the Composite-ST CfPOE Objectives for the environment being fulfilled by the Composite-ST automatically, i.e. they can be assigned to TOE security objectives. SgOE Remaining security objectives for the environment of the Platform-ST not belonging to the group IrOE nor CfPOE and thus need to be addressed in the Composite-ST 5685 The sections • Assurance requirements of the composite evaluation • Security objectives for the environment of the platform • Usage of platform TSF by TOE TSF show the compatibility of this Composite ST and the Platform-ST as required by [BSI-AIS36-V5]. 5690 The Platform-ST is the security target of all controllers SLC52GDA448* used by this TOE as platform. 8.2.1 Assurance requirements of the composite evaluation The Platform-ST requires • Common Criteria version CC:2022 with 5695 • EAL5 and EAL6 augmented. The Composite-ST requires: • Common Criteria version 3.1, cf. [CC-Part1-V3.1], [CC-Part2-V3.1], and [CC-Part3-V3.1] and • EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. Therefore the Composite-SAR is a subset of the Platform-SAR. 5700 8.2.2 Security objectives for the environment of the platform The Platform-ST defined the following objectives for the environment: • OE.Process-Sec-IC is directly supported by the P.Manufact and the implementing ob- jective OT.Identification which provides means to identify the TOE. Thus, the objective falls in both classes CfPOE and SgOE because it is partially fulfilled by the TOE but also 5705 remains partially significant of the composite ST objectives for the environment. • OE.Lim_Block_Loader, OE.TOE_Auth, and OE.Loader_Usage are not relevant because they are concerned with the authentication of the TOE and the usage of the flash loader in early production phases at the IC manufacturer. Therefore, they are irrelevant objectives fir the environment (IrOE) 5710 • OE.Resp-Appl concerns the treatment of the user data by the Composite-TOE and is enforced intrinsically by the security architecture of the Composite-TOE. Thus, this objective belongs to the automatically fulfilled objectives (CfPOE). Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 163 8 TOE Summary Specification (ASE_TSS) Overall, the objectives for the environment of the platform are fully captured by the Composite- ST. 5715 Thus, the objectives of the Platform-TOE and the Composite-TOE are not contradictory. 8.2.3 Usage of platform TSF by TOE TSF The relevant SFRs (RP_SFR-SERV, RP_SFR-MECH) of the platform being used by the Composite ST are listed in the following table. Table 8.1: Relevant Platform SFRs used as services RP_SFR-SERV Meaning Used by TOE SFR FRU_FLT.2 Limited Fault Tolerance FPT_TST.1 FPT_FLS.1 Failure with Preservation of Secure State FPT_FLS.1 FPT_PHP.3 Resistance to Physical At- tack FPT_PHP.3, FPT_PHP.1 FDP_ITT.1 Basic Internal Transfer Protection FPT_EMS.1, FPT_EMS.1/SSCD FDP_IFC.1 Subset Information Flow Control FPT_EMS.1, FPT_EMS.1/SSCD FPT_ITT.1 Basic Internal TSF Data Transfer Protection FPT_EMS.1, FPT_EMS.1/SSCD FCS_RNG.1/TRNG Quality Metric for Ran- dom Numbers FCS_RNG.1 FPT_TST.2 Subset TOE Security Test- ing FPT_TST.1, FPT_PHP.3 (active shield and sensors) FCS_CKM.1/EC-1 Cryptographic Key Gener- ation (EC) FCS_CKM.1/EC (FCS_CKM.1/RSA-1) Cryptographic Key Gener- ation (RSA) The RSA key generation is functionally dependent on the underlying crypto library. FCS_CKM.1/RSA-1 not in scope of the plat- form TSF. FCS_CKM.1/RSA FCS_COP.1/ECDH-1 Cryptographic Support (ECDH) FCS_CKM.1/CA_EC, FCS_CKM.1/DH_PACE_EC FCS_COP.1/ECDSA-1 Cryptographic Support (ECDSA) FCS_COP.1/SIG_VER_EC, FCS_COP.1/AA_SGEN_EC, FCS_COP.1/EC FCS_COP.1/RSA-1 Cryptographic Support (RSA) FCS_COP.1/SIG_VER_RSA, FCS_CKM.1/DH_PACE_RSA, FCS_CKM.1/CA_RSA, FCS_COP.1/RSA FCS_COP.1/AES- SCL- 1 FCS_CKM.6/AES- SCL-1 Cryptographic Support (AES) FCS_COP.1/CA_ENC (AES), FCS_COP.1/PACE_ENC (AES), FCS_COP.1/CMAC- SCL-1 FCS_CKM.6/CMAC- SCL-1 FCS_COP.1/CA_MAC (AES), FCS_COP.1/PACE_MAC (AES), FCS_COP.1/AES_MAC FCS_COP.1/AES FCS_RNG.1 continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 164 8 TOE Summary Specification (ASE_TSS) Table 8.1 – continued from previous page RP_SFR-SERV Meaning Used by TOE SFR (FCS_COP.1/HCL) The SHA implementa- tion is functionally de- pendent on the under- lying crypto library but addressed in the scope of this evaluation as re- flected by the addition of FCS_COP.1/SHA in this ST FCS_CKM.1/CA_EC, FCS_CKM.1/DH_PACE_EC, FCS_CKM.1/DH_PACE_RSA, FCS_CKM.1/CA_RSA FAU_SAS.1 Audit Storage FAU_SAS.1 FMT_LIM.1 Limited Capabilities FMT_LIM.1 FMT_LIM.2 Limited Availability FMT_LIM.2 Table 8.2: Relevant Platform SFRs used as mechanisms RP_SFR-MECH Meaning Used by TOE SFR FDP_ACC.1 Subset Access Control used as supporting mechanism FDP_ACF.1 Security Attribute Based Access Control used as supporting mechanism FDP_SDC.1 Stored date confidential- ity used as supporting mechanism FDP_SDI.2 Stored data integrity monitoring and action used as supporting mechanism FDP_UCT.1 Basic data exchange con- fidentiality used as supporting mechanism FDP_UIT.1 Data exchange integrity used as supporting mechanism FDP_LIM.1/Loader Limited Capabilities Loader used as supporting mechanism FDP_LIM.2/Loader Limited Availability Loader used as supporting mechanism Any platform SFR neither listed in Table 8.1 nor Table 8.2 is not being used by the Composite 5720 ST and thus an irrelevant SFRs (IP_SFR). 8.2.4 Conclusion Overall there is no conflict between security requirements of this Composite-ST and the Platform-ST. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 165 A Overview of Cryptographic Algorithms A Overview of Cryptographic Algorithms 5725 This TOE is a composite product and uses for cryptographic mechanism listed only mechanism provided by the underlying chip SLC52GDA448*. The “Standard of Implementation” is a citation of the ST of the underlying chip SLC52GDA448* only, cf. [Infineon-ST-SLC52-H13]. The following cryptographic algorithms are used by the TOE to enforce its security policy: Table A.1: Used Algorithms # Purpose Cryptographic Mechanism Standard of Imple- menta- tion Key size in bits Standard of Appli- cation Comments and ST Reference 1 Authenticity RSA-signature generation (RSA PKCS1_ v1_5, RSA PSS), using SHA-256, SHA-384 or SHA-512 [RSA- PKCS1- v2.2], [IEEE- 1363] 2048, 3072 and 4096 bits N/A Digital sig- nature cre- ation FCS_ COP.1/RSA (see note 2) 2 Authenticity ECDSA- signature generation, using SHA-256, SHA-384 or SHA-512 (de- pending on curve) [ANSI- X9.62], [ISO-IEC- 14888-3], [IEEE- 1363], [NIST- FIPS-186- 4], [RFC- 5639- 2010-03] corresp. to the used elliptic curves: NIST P- 256, NIST P-384, NIST P-521, BP P256r1, BP P384r1, BP P512r1 N/A Digital sig- nature cre- ation FCS_ COP.1/EC (see note 2) 3 Authenticity, Authentica- tion Terminal Authentica- tion Version 1, ECDSA- signature verification using SHA-256, SHA-384 or SHA-512 [ANSI- X9.62] sec- tion 7.4.1, [ISO-IEC- 14888-3] section 6.4.4, and [IEEE- 1363] section 7.2.8 (Refer to Cryp- tographic Primitives for the def- inition of the hash- functions) corresp. to the used elliptic curves: NIST P- 256, NIST P-384, NIST P-521, BP P256r1, BP P384r1, BP P512r1 [ICAO- 9303- 2015], [BSI-TR- 03110-3- V221] FCS_ COP.1/SIG_ VER_EC (see notes 1 and 9) continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 166 A Overview of Cryptographic Algorithms Table A.1 – continued from previous page # Purpose Cryptographic Mechanism Standard of Imple- menta- tion Key size in bits Standard of Appli- cation Comments and ST Reference 4 Authenticity, Authentica- tion Terminal Au- thentication Version 1, RSA-signature verification using SHA-256, SHA-384 or SHA-512 [RSA- PKCS1- v2.2], sec- tion 5.2.2 RSAVP1, padding accord- ing to RSASSA- PSS or RSASSA- PKCS1-v1_ 5 (Refer to Cryp- tographic Primitives for the def- inition of the hash- functions) 2048 and 3072 bits [ICAO- 9303- 2015], [BSI-TR- 03110-3- V221] FCS_ COP.1/SIG_ VER_RSA (see notes 1 and 10) 5 Authentication PACEv2 (Generic Mapping, Integrated Mapping (with ECDH), Chip Authentication Mapping1 ), PACE [BSI-TR- 03110- 1-V220] (PACE v2) 128 (nonce), 160 (MRZ), PINs: 48..128 (PIN.CH, CAN), 64..128 (PUK.CH), 40 (PIN.T), 192..256 (PIN.ADMIN) [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ CKM.1/DH_ PACE_ RSA, FCS_ CKM.1/DH_ PACE_EC (see notes 3 and 11) 6 Authentication Symmetric Au- thentication, AES in CMAC mode [NIST- FIPS-197] (AES), [ISO- IEC-9797- 1-2011] algorithm 5 and padding method 2 (CMAC) 192 [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ COP.1/AES_ MAC (see note 4) continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 167 A Overview of Cryptographic Algorithms Table A.1 – continued from previous page # Purpose Cryptographic Mechanism Standard of Imple- menta- tion Key size in bits Standard of Appli- cation Comments and ST Reference 7 Authentication Active Au- thentication, ECDSA signa- ture generation using SHA-256, SHA-384 or SHA-512 According to [ANSI- X9.62] section 7.3 and ac- cording to [ISO-IEC- 14888-3], section 6.4.3, and [IEEE- 1363], sec- tion 7.2.7. (Refer to Crypto- graphic Primitives for the def- inition of the hash- functions) corresp. to the used elliptic curves: NIST P- 256, NIST P-384, NIST P-521, BP P256r1, BP P384r1, BP P512r1 [ICAO- 9303- 2015] FCS_ COP.1/AA_ SGEN_EC (see notes 2 and 9) 8 Key Genera- tion EC signature key pair gener- ation ECDSA Key Gen- eration [ANSI- X9.62], appendix A4.3, [ISO- IEC-14888- 3], section 6.4.2 and [IEEE- 1363], appendix A.16.9 corresp. to the used elliptic curves: NIST P- 256, NIST P-384, NIST P-521, BP P256r1, BP P384r1, BP P512r1 N/A FCS_ CKM.1/EC (see note 3) 9 Key Genera- tion RSA signature key pair gener- ation Proprietary. Generated keys meet [RSA- PKCS1- v2.2], sections 3.1 and 3.2 and [IEEE- 1363], section 8.1.3.1 2048, 3072 and 4096 bits N/A FCS_ CKM.1/RSA (see note 3) 10 Key Agree- ment PACE Key derivation ECDH using SHA-1 and SHA-256 [ICAO- TR-110], [BSI-TR- 03111- V210-ECC] 128 (AES), 192 (AES), 256 (AES) [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ CKM.1/DH_ PACE_EC continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 168 A Overview of Cryptographic Algorithms Table A.1 – continued from previous page # Purpose Cryptographic Mechanism Standard of Imple- menta- tion Key size in bits Standard of Appli- cation Comments and ST Reference 11 Key Agree- ment PACE Key derivation DH using SHA-1 and SHA-256 [RSA- PKCS-3- V1.4] (Refer to Cryp- tographic Primitives for the def- inition of the hash- functions) 128 (AES), 192 (AES), 256 (AES) [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ CKM.1/DH_ PACE_RSA 12 Key Agree- ment, Au- thentication Chip Authenti- cation Version 1, ECDH Key agreement and key derivation using SHA-1 and SHA-256 [ICAO- TR-110] [BSI-TR- 03111- V210-ECC] (Refer to Crypto- graphic Primitives for the def- inition of the hash- functions) 128 (AES), 192 (AES), 256 (AES), 256 (EC), 384 (EC), 512 (EC), 521 (EC) [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ CKM.1/CA_ EC 13 Key Agree- ment, Au- thentication Chip Authenti- cation Version 1, DH Key agree- ment and key derivation us- ing SHA-1 and SHA-256 [RSA- PKCS-3- V1.4] (Refer to Cryp- tographic Primitives for the def- inition of the hash- functions) 128 (AES), 192 (AES), 256 (AES), 2048 (RSA) [BSI-TR- 03110-1- V220] FCS_ CKM.1/CA_ RSA (see note 8) 14 Confidentiality Secure Messag- ing, AES in CBC mode [NIST- FIPS-197] (AES), [NIST-800- 38A-2001], section 6.2 (CBC) 128, 192, 256 [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ COP.1/PACE_ ENC, FCS_ COP.1/CA_ ENC (see note 4) 15 Integrity Secure Mes- saging, AES in CMAC mode [NIST- FIPS-197] (AES), [ISO- IEC-9797- 1-2011] algorithm 5 and padding method 2 (CMAC) 128, 192, 256 [ICAO- TR-110], [BSI-TR- 03110-1- V220] FCS_ COP.1/PACE_ MAC, FCS_ COP.1/CA_ MAC (see note 4) continues on next page Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 169 A Overview of Cryptographic Algorithms Table A.1 – continued from previous page # Purpose Cryptographic Mechanism Standard of Imple- menta- tion Key size in bits Standard of Appli- cation Comments and ST Reference 16 Trusted Chan- nel Secure Mes- saging in ENC MAC mode established during PACE [BSI-TR- 03110-1- V220] see lines “PACE Key Derivation DH” and “PACE Key Derivation ECDH” of this table [ICAO- TR-110], [BSI-TR- 03110-1- V220] FTP_ ITC.1/SVD, FTP_ ITC.1/VAD, FTP_ ITC.1/DTBS, FTP_ ITC.1/PACE 17 Trusted Chan- nel Secure Mes- saging in ENC MAC mode established during CA after PACE [BSI-TR- 03110-1- V220] see lines “CA DH Key agree- ment and key deriva- tion” and “CA ECDH Key agree- ment and key deriva- tion” of this table [ICAO- TR-110], [ICAO- 9303- 2015], [BSI-TR- 03110-1- V220] FTP_ ITC.1/SVD, FTP_ ITC.1/PACE 18 Cryptographic Primitive DRG.4 random number gener- ator [NIST- SP800- 90A] CTR_ DRBG, using AES as block cipher, random source of class PTG.2 according to [BSI- AIS31-V3] ./. N/A FCS_RNG.1 (see note 5) 19 Cryptographic Primitive SHA-1, SHA- 256, SHA-384, SHA-512 [NIST- FIPS-180- 4] ./. [BSI-TR- 03110-1- V220] Signature verification, signature generation, key deriva- tion (see notes 6 and 7) 5730 Notes 1. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the standard of implementation of “digital signature verification” using RSA or EC see [Infineon-ST-SLC52-H13]. 5735 2. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA 1 Integrated Mapping is a licensed technology protected by IDEMIA under the patents FR2946818 and FR2946819 and their foreign extensions. Chip Authentication Mapping is a licensed technology protected by the BSI under the patent DE 10 2011 013 562.8 and foreign extensions. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 170 A Overview of Cryptographic Algorithms (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the standard of implementation of “digital signature generation” using RSA or EC see [Infineon-ST-SLC52-H13]. 3. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA 5740 (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the “cryptographic key generation algorithm” for EC and ECDH see [Infineon-ST-SLC52-H13]. RSA signature key pair generation functionally implemented based on the crypto library of the underlying chip. 4. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA 5745 (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the standard of implementation of “Advanced Encryption Standard (AES)” see [Infineon-ST-SLC52-H13]. 5. This TOE uses the random numbers generation provided by the underlying chip SLC52GDA448* as random source for the hybrid deterministic random number genera- 5750 tor. For the standard of implementation of “random numbers generation Class DRG.4 according to [BSI-AIS2031-RNG-CLASSES-V2]” see [Infineon-ST-SLC52-H13]. 6. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the standard of implementation of hash algorithms SHA-{256, 384, 5755 512} see [Infineon-Chip-HCL52]. 7. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the standard of implementation of hash algorithms SHA-1 see [Infineon-Chip-HCL52]. 5760 8. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For computing the shared secret via the modular exponentia- tion function (CryptoRsaSignExpMask()) of the RSA crypto library is used. Function CryptoRsaSignExpMask() of RSA crypto library is used also for signing. 5765 9. EC curves for TA and AA are taken from [BSI-TR-03110-3-V221] Table 4: Standardized Domain Parameters. 10. The RSA bit lengths for TA are taken over from [BSI-TR-03110-3-V221] section A.7.3.2. Public Key Format. 11. Regarding the supported lengths for PIN.CH (6..16 Byte), PUK.CH (8..16 Byte), PIN.T (5 5770 Byte), CAN (6..16 Byte) and PIN_ADMIN (24..32 Byte) refer to the guidance documentation. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 171 Bibliography Bibliography [CC-Part1-V3.1] CCMB-2017-04-001, Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model, Common Criteria Maintenance Board, Version 3.1, Revision 5, 2017-04. 5775 [CC-Part2-V3.1] CCMB-2017-04-002, Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components, Common Criteria Maintenance Board, Version 3.1, Revision 5, 2017-04. [CC-Part3-V3.1] CCMB-2017-04-003, Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Components, Common Criteria Maintenance 5780 Board, Version 3.1, Revision 5, 2017-04. [CEM-V3.1] CCMB-2017-04-004, Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 5, 2017-04. [CC-CompositeEval-Smart-Cards] Composite product evaluation for Smart Cards and similar devices, September 2007, Version 1.0 Revision 1, CCDB-2007-09-001. 5785 [BSI-AIS2031-RNG-CLASSES-V2] AIS 20 / AIS 31, A proposal for: Functionality classes for ran- dom number generators, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.0, 2011-09-18. [BSI-AIS36-V5] AIS 36, Anwendungshinweise und Interpretationen zum Schema, AIS36: Kom- positionsevaluierung, Bundesamt für Sicherheit in der Informationstechnik (BSI), 5790 Version 5, 2017-03-15. [BSI-AIS31-V3] AIS 31, Anwendungshinweise und Interpretationen zum Schema, AIS31: Funk- tionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlen- generatoren, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 3, 2013-05-15. 5795 [BSI-CC-PP-0055-110] Common Criteria Protection Profile Machine Readable Travel Docu- ment with “ICAO Application” Basic Access Control, BSI-CC-PP-0055 Version 1.10, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2009-03-25. [BSI-CC-PP-0059-2009-MA-02] Protection profiles for Secure signature creation device - Part 2: Device with key generation, Information Society Standardization System 5800 CEN/ISSS, EN 419211-2:2013, 2013-07-17. [BSI-CC-PP-0071-2012-MA-01] Protection profiles for Secure signature creation device - Part 4: Extension for device with key generation and trusted communication with certificate generation application, Information Society Standardization System CEN/ISSS, EN 419211-4:2013, 2013-11-27 5805 [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 sig- nature creation application, Information Society Standardization System CEN/ISSS, EN 419211-5:2013, 2013-12-04. [BSI-CC-PP-0056-V2-2012-MA-02] Assurance Continuity Maintenance Report BSI-CC-PP- 5810 0056-V2-2012-MA-02 for Common Criteria Protection Profile Machine Readable Travel Document with “ICAO Application” Extended Access Control with PACE (EAC PP) Version 1.3.2, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2012-12-05. [BSI-CC-PP-0068-V2-2011-MA-01] Machine Readable Travel Document using Standard In- 5815 spection Procedure with PACE(PACE PP), BSI-CC-PP-0068-V2-2011-MA-01, Version 1.0.1, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2014-07-22. [BSI-CC-PP-0084-2014] Security IC Platform Protection Profile with Augmentation Packages, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 1.0, 2014-01-13. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 172 Bibliography [BSI-CC-PP-0086-2015] Common Criteria Protection Profile / Electronic document imple- 5820 menting Extended Access Control Version 2 defined in BSI TR-03110 [EAC2-PP], Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 1.01, 2015-05-20. [BSI-TR-03110-1-V220] Technical Guideline TR-03110-1, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token - Part 1 - eMRTDs with BAC/PACEv2 and EACv1, Bundesamt für Sicherheit in der Informationstechnik (BSI), 5825 Version 2.20, 2015-02-26. [BSI-TR-03110-2-V221] Technical Guideline TR-03110, Advanced Security Mechanisms for Ma- chine Readable Travel Documents and eIDAS Token ü Part 2 - Protocols for elec- tronic IDentification, Authentication and trust Services (eIDAS), Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.21, 2016-12-21. 5830 [BSI-TR-03110-3-V221] BSI, Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token - Part 3 - Common Specifications, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.21, 2016-12-21. [BSI-TR-03110-4-V221] BSI, Technical Guideline TR-03110, Advanced Security Mechanisms for 5835 Machine Readable Travel Documents and eIDAS Token - Part 4: Applications and Document Profiles, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.21, 2016-12-21 [BSI-TR-03111-V210-ECC] TR-03111, Technical Guideline TR-03111: Elliptic Curve Cryptography, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.10, 2018-06-01. 5840 [BSI-TR-03116-2] TR-03116-2, Technische Richtlinie BSI TR-03116 - Kryptographische Verfahren für Projekte der Bundesregierung - Teil 2: Hoheitliche Dokumente, Bundesamt für Sicherheit in der Informationstechnik (BSI), Stand 2021, 2021-02-23. [EU-Reg-910-2014] eIDAS Regulation (Regulation (EU) No 910/2014), REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 5845 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Official Journal of the European Communities, L257:73 - 114, 2014-08-28. [ICAO-9303-2015] ICAO Doc 9303, Machine Readable Travel Documents - Machine Readable Passports, (this includes the latest supplemental for ICAO Doc 9303 which also 5850 should be considered), International Civil Aviation Organization (ICAO), Seventh Edition, 2015. [ICAO-TR-110] ICAO SAC v1.1, Machine Readable Travel Documents, TECHNICAL REPORT, Sup- plemental Access Control for Machine Readable Travel Documents, International Civil Aviation Organization (ICAO), Version 1.1, 2014-04-15. 5855 [NIST-FIPS-180-4] FIPS PUB 180-4, Secure Hash Standard (SHS), Information Technology Lab- oratory, National Institute of Standards and Technology (NIST), August 2015. [NIST-FIPS-186-4] FIPS PUB 186-4, DIGITAL SIGNATURE STANDARD (DSS), Information Tech- nology Laboratory, National Institute of Standards and Technology (NIST), 2013-07. [NIST-FIPS-197] FIPS PUB 197, ADVANCED ENCRYPTION STANDARD (AES), Information Tech- 5860 nology Laboratory, National Institute of Standards and Technology (NIST), 2001-11-26 [ISO-IEC-7816-part-2] ISO/IEC 7816: Identification cards - Integrated circuit(s) cards with con- tacts - Part 2: Dimensions and location of contacts, Version Second Edition, ISO/IEC, 2008. [ISO-IEC-7816-part-4] ISO/IEC 7816-4:2013, Identification cards – Integrated circuit cards – Part 5865 4: Organization, security and commands for interchange, ISO/IEC, 2013-04. [ISO-IEC-14443-2018] ISO/IEC 14443 Identification cards – Contactless integrated circuit cards - Contactless proximity objects, ISO/IEC, 2018. Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 173 Bibliography [ISO-IEC-9797-1-2011] ISO/IEC 9797-1:2011, Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher, 5870 ISO/IEC, 2011-03. [RFC-5639-2010-03] RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, 2010-03. [NIST-800-38A-2001] NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, National Institute of Standards and 5875 Technology (NIST), 2001 Edition, 2001-12. [NIST-SP800-67] NIST Special Publication 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, National Institute of Standards and Technology (NIST), Revision 2, 2012-01. [NIST-SP800-90A] NIST Special Publication 800-90A, Recommendation Random Number 5880 Generation Using Deterministic Random Bit Generators, National Institute of Stan- dards and Technology (NIST), Revision 1, 2015-06. [RSA-PKCS1-v2.2] PKCS #1 v2.2: RSA Cryptography Standard, Version 2.2, 2012-10-27. [RSA-PKCS-3-V1.4] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories Technical Note, Version 1.4, Revised, 1993-11-01. 5885 [Infineon-ST-SLC52-H13] Public Security Target BSI-DSZ-CC-1110-V8-2025, IFX_CCI_000003h, IFX_CCI_000005h, IFX_CCI_000008h IFX_CCI_00000Ch, IFX_CCI_000013h, IFX_ CCI_000014h, IFX_CCI_000015h, IFX_CCI_00001Ch, IFX_CCI_00001Dh, IFX_CCI_ 000021h, IFX_CCI_000022h H13, Infineon Technologies AG, Revision 6.2, 2025-06- 26. 5890 [Infineon-Chip-HW-Ref-16bit-V01] 16-bit Security Controller Family - V01, Hardware Reference Manual (HRM), Revision 7.0, 2019-06-11 [Infineon-Chip-HCL52] HCL52-CPU-C65 Hash Crypto Library for CPU SHA, 16-bit Security Controller, User interface manual, v1.12.001, 2020-01-14. [ANSI-X9.62] American National Standard X9.62-2005, Public Key Cryptography for the Fi- 5895 nancial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), ANSI, 2005-11-16. [ANSI-X9.63] American National Standard X9.63-2001, Public Key Cryptography for the Fi- nancial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, ANSI, 2001-11-20. 5900 [ISO-IEC-14888-3] ISO/IEC 14888_3:2006 - Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms, ISO/IEC, 2006-11. [ISO-IEC-11770-3] ISO/IEC 11770-3:2015, Information technology – Security techniques - Key management – Part 3: Mechanisms using asymmetric techniques, ISO/IEC, 2015-08. 5905 [IEEE-1363] IEEE 1363A-2004, IEEE Standard Specifications for Public-Key Cryptography, IEEE Standards Board, 2004-07-22. [ECCG-ACM-V2.0] European Cybersecurity Certification Group, Sub-group on Cryptography - Agreed Cryptographic Mechanisms, Version 2.0, 2025-04. [DIR-1999-93-EC] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE 5910 COUNCIL of 13 December 1999 on a Community framework for electronic signatures. Official Journal of the European Communities, L13:12 - 20, 2000-01-19. [Eviden-V60-ADM] Administrator Guidance ‘CardOS V6.0 ID R1.2’ and ‘CardOS V6.0 ID R1.2 (BAC)’, Eviden Germany GmbH [Eviden-V60-USR] User Guidance ‘CardOS V6.0 ID R1.2’ and ‘CardOS V6.0 ID R1.2 (BAC)’, Eviden 5915 Germany GmbH Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 174 Index Index A Accessibility to the TOE functions and data only for authorised subjects, 17 5920 Administrator, 20 Advanced Inspection Procedure, 3 AIP, 3 Attacker, 19 Authenticity of the travel 5925 document’s chip, 17 B BAC, 2 Basic Inspection System with PACE, 18 5930 BIS-BAC, 2 BIS-PACE, 18 C CAN, 2 CfPOE, 163 5935 Common Criteria, 3 Country Signing Certification Authority, 19 Country Verifying Certification Authority, 19 5940 CSCA, 19 CVCA, 19 D Document Signer, 18 Document Verifier, 20 5945 DS, 19 DTBS, 2 DTBS, DTBS/R, 17 DV, 20 E 5950 EAC, 2 EIS, 20 Evaluation Assurance Level, 3 Extended Inspection System, 20 G 5955 Genuineness of the TOE, 17 I Inspection system, 20 IrOE, 163 IS, 20 5960 L Logical travel document sensitive User Data, 17 M Manufacturer, 19 5965 MRTD, 2 MRZ, 2 P PACE, 2 Personalisation Agent, 19 5970 PIN, 2 PP0056 FCS_CKM.1; CA_EC, 65 FCS_CKM.1; CA_RSA, 66 FCS_CKM.4; CA Session Keys, 71 5975 FCS_COP.1; AA_SGEN_EC, 79 FCS_COP.1; CA_ENC, 74 FCS_COP.1; CA_MAC, 75 FCS_COP.1; SIG_VER_EC, 77 FCS_COP.1; SIG_VER_RSA, 78 5980 FDP_ACC.1; TRM, 93 FDP_ACF.1; TRM, 93 PP0059 FCS_CKM.1; SCD/SVD EC KeyPair, 69 FCS_CKM.1; SCD/SVD RSA KeyPair, 5985 70 FCS_CKM.4; SCD, 71 FCS_COP.1; AES_MAC, 74 FCS_COP.1; EC digital signature creation, 71 5990 FCS_COP.1; RSA digital signature creation, 72 FCS_COP.1; SHA, 73 FDP_RIP.1, 95 PP0068 5995 FAU_SAS.1, 115 FCS_CKM.1; DH_PACE_EC, 67 FCS_CKM.1; DH_PACE_RSA, 68 FCS_CKM.4; PACE Session Keys, 71 FCS_COP.1; PACE_ENC, 76 6000 FCS_COP.1; PACE_MAC, 77 FDP_ACC.1; TRM, 93 FDP_ACF.1; TRM, 93 FDP_RIP.1, 95 FDP_UCT.1; TRM, 96 6005 FDP_UIT.1; TRM, 96 Protection Profile, 3 PTRNG, 2 Q QES, 2 6010 R RAD, 2 Reference Authentication Data, 3 S SCD, 17 6015 Security Target, 3 SgOE, 163 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 175 Index Signatory, 20 Signature Creation Data, 3 Signature Verification Data, 3 6020 SIP, 3 Standard Inspection Procedure, 3 SVD, 2, 17 T Target of Evaluation, 3 6025 Terminal, 18 TOE, 2 TOE internal non-secret cryptographic material, 18 TOE internal secret cryptographic 6030 keys, 18 TOE Security Functions, 3 travel document communication establishment authorisation data, 18 6035 travel document holder, 18 travel document presenter, 18 travel document tracing data, 17 traveller, 18 U 6040 User, 20 user data stored on the TOE, 17 user data transferred between the TOE and the terminal connected, 17 6045 V VAD, 2 Verification Authentication Data, 3 Security Target ’CardOS V6.0 ID R1.2’ Copyright © Eviden Germany GmbH. All rights reserved. PUBLIC 176