Security Target ’CardOS V6.0 ID R1.0’ Rev. 1.91R, Edition 10/2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Usage and major security features of the TOE . . . . . . . . . . . . . . . . 6 2.3.2 TOE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.3 File System of the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.4 Non-TOE hardware/software/firmware . . . . . . . . . . . . . . . . . . . . 8 2.3.5 Conformance to eIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 TOE Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Life Cycle Phases Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.2 TOE Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.1 TOE Physical Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.2 TOE Logical Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.2.3 TOE Delivery Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Conformance Claim 15 3.1 CC Conformance Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 PP Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Package Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4 Conformance Claim Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 Security Problem Definition 18 4.1 Assets and External Entities . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.1 T.Skimming (Skimming travel document / Capturing Card-Terminal Communication) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.2 T.Eavesdropping (Eavesdropping on the communication between the TOE and the PACE terminal) . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3 T.Tracing (Tracing travel document) . . . . . . . . . . . . . . . . . . . . . 23 4.2.4 T.Forgery (Forgery of Data) . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.5 T.Abuse-Func (Abuse of Functionality) . . . . . . . . . . . . . . . . . . . . 23 4.2.6 T.Information_Leakage (Information Leakage from travel document) . . 24 4.2.7 T.Phys-Tamper (Physical Tampering) . . . . . . . . . . . . . . . . . . . . . 24 4.2.8 T.Malfunction (Malfunction due to Environmental Stress) . . . . . . . . . . 25 4.2.9 T.Read_Sensitive_Data (Read the sensitive biometric reference data) . . 25 4.2.10 T.Counterfeit (Counterfeit of travel document chip data) . . . . . . . . . . 26 4.2.11 T.SCD_Divulg (Storing, copying and releasing of the signature creation data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.12 T.SCD_Derive (Derive the signature creation data) . . . . . . . . . . . . . 26 4.2.13 T.Hack_Phys (Physical attacks through the TOE interfaces) . . . . . . . . 26 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC i Contents 4.2.14 T.SVD_Forgery (Forgery of the signature verification data) . . . . . . . . 26 4.2.15 T.SigF_Misuse (Misuse of the signature creation function of the TOE) . . 27 4.2.16 T.DTBS_Forgery (Forgery of the DTBS/R) . . . . . . . . . . . . . . . . . . 27 4.2.17 T.Sig_Forgery (Forgery of the electronic signature) . . . . . . . . . . . . . 27 4.3 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.1 P.Manufact (Manufacturing of the travel document’s chip) . . . . . . . . . 27 4.3.2 P.Pre-Operational (Pre-operational handling of the travel document) . . . 28 4.3.3 P.Card_PKI (PKI for Passive Authentication (issuing branch)) . . . . . . . 28 4.3.4 P.Trustworthy_PKI (Trustworthiness of PKI) . . . . . . . . . . . . . . . . . 29 4.3.5 P.Terminal (Abilities and trustworthiness of terminals) . . . . . . . . . . . 29 4.3.6 P.Sensitive_Data (Privacy of sensitive biometric reference data) . . . . . 29 4.3.7 P.Personalisation (Personalisation of the travel document by issuing State or Organisation only) . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.8 P.CSP_QCert (Qualified certificate) . . . . . . . . . . . . . . . . . . . . . . 30 4.3.9 P.QSign (Qualified electronic signatures) . . . . . . . . . . . . . . . . . . . 30 4.3.10 P.Sigy_SSCD (TOE as secure signature creation device) . . . . . . . . . . 30 4.3.11 P.Sig_Non-Repud (Non-repudiation of signatures) . . . . . . . . . . . . . . 30 4.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4.1 A.Passive_Auth (PKI for Passive Authentication) . . . . . . . . . . . . . . . 31 4.4.2 A.Insp_Sys (Inspection Systems for global interoperability) . . . . . . . . 31 4.4.3 A.Auth_PKI (PKI for Inspection Systems) . . . . . . . . . . . . . . . . . . . 31 4.4.4 A.CGA (Trustworthy certificate generation application) . . . . . . . . . . . 32 4.4.5 A.SCA (Trustworthy signature creation application) . . . . . . . . . . . . . 32 4.4.6 A.Env_Admin (Environment for administrator) . . . . . . . . . . . . . . . . 32 4.4.7 A.Env_Mass_Signature (Environment for a mass signature TOE) . . . . . 32 5 Security Objectives 33 5.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1 OT.Data_Integrity (Integrity of Data) . . . . . . . . . . . . . . . . . . . . . 33 5.1.2 OT.Data_Authenticity (Authenticity of Data) . . . . . . . . . . . . . . . . . 33 5.1.3 OT.Data_Confidentiality (Confidentiality of Data) . . . . . . . . . . . . . . 34 5.1.4 OT.Tracing (Tracing travel document) . . . . . . . . . . . . . . . . . . . . . 34 5.1.5 OT.Prot_Abuse-Func (Protection against Abuse of Functionality) . . . . . 34 5.1.6 OT.Prot_Inf_Leak (Protection against Information Leakage) . . . . . . . . 34 5.1.7 OT.Prot_Phys-Tamper (Protection against Physical Tampering) . . . . . . 35 5.1.8 OT.Prot_Malfunction (Protection against Malfunctions) . . . . . . . . . . . 35 5.1.9 OT.Identification (Identification of the TOE) . . . . . . . . . . . . . . . . . 35 5.1.10 OT.AC_Pers (Access Control for Personalisation of logical MRTD) . . . . . 36 5.1.11 OT.Sens_Data_Conf (Confidentiality of sensitive biometric reference data) 36 5.1.12 OT.Chip_Auth_Proof (Proof of the travel document’s chip authenticity) . . 36 5.1.13 OT.AA_Proof (Proof of the travel document’s chip authenticity) . . . . . . 37 5.1.14 OT.Lifecycle_Security (Lifecycle security) . . . . . . . . . . . . . . . . . . . 37 5.1.15 OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) . . . . . . . . 37 5.1.16 OT.SCD_Unique (Uniqueness of the signature creation data) . . . . . . . 37 5.1.17 OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) . . . . . 38 5.1.18 OT.SCD_Secrecy (Secrecy of the signature creation data) . . . . . . . . . 38 5.1.19 OT.Sig_Secure (Cryptographic security of the electronic signature) . . . . 38 5.1.20 OT.Sigy_SigF (Signature creation function for the legitimate signa- tory only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1.21 OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) . . . . . . . . 38 5.1.22 OT.EMSEC_Design (Provide physical emanations security) . . . . . . . . . 38 5.1.23 OT.Tamper_ID (Tamper detection) . . . . . . . . . . . . . . . . . . . . . . 39 5.1.24 OT.Tamper_Resistance (Tamper resistance) . . . . . . . . . . . . . . . . . 39 5.1.25 OT.TOE_SSCD_Auth (Authentication proof as SSCD) . . . . . . . . . . . . 39 5.1.26 OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export) . . . . . . . 39 5.1.27 OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) . . . . . 39 5.1.28 OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS import) . . . . 40 5.2 Security Objectives for the Operational Environment . . . . . . . . . . . . 40 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC ii Contents 5.2.1 OE.Legislative_Compliance (Issuing of the travel document) . . . . . . . . 40 5.2.2 OE.Passive_Auth_Sign (Authentication of travel document by Signature) 40 5.2.3 OE.Personalisation (Personalisation of travel document) . . . . . . . . . . 41 5.2.4 OE.Terminal (Terminal operating) . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.5 OE.Travel_Document_Holder (Travel document holder Obligations) . . . 42 5.2.6 OE.Auth_Key_Travel_Document (Travel document Authentication Key) . 42 5.2.7 OE.AA_Key_Travel_Document (Travel document Authentication Key) . . 42 5.2.8 OE.Authoriz_Sens_Data (Authorization for Use of Sensitive Biomet- ric Reference Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.9 OE.Exam_Travel_Document (Examination of the physical part of the travel document) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.10 OE.Prot_Logical_Travel_Document (Protection of data from the logical travel document) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.11 OE.Ext_Insp_Systems (Authorization of Extended Inspection Systems) . 44 5.2.12 OE.SVD_Auth (Authenticity of the SVD) . . . . . . . . . . . . . . . . . . . 44 5.2.13 OE.CGA_QCert (Generation of qualified certificates) . . . . . . . . . . . . 44 5.2.14 OE.SSCD_Prov_Service (Authentic SSCD provided by SSCD- provisioning service) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.15 OE.HID_VAD (Protection of the VAD) . . . . . . . . . . . . . . . . . . . . . 44 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) . . . . . . . . . 45 5.2.18 OE.DTBS_Protect (SCA protects the data intended to be signed) . . . . . 45 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) . . . . . . . . . . . . . 46 5.2.21 OE.Dev_Prov_Service (Authentic SSCD provided by SSCD Provi- sioning Service) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 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) . . . . . . . 47 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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3 Security Objective Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.1 Security Objectives Backtracking . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.2 Security Objectives Sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . 49 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 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC iii Contents 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 7.6.1.12 FCS_COP.1/CA_ENC (Cryptographic operation - Symmetric Encryp- tion / Decryption) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.6.1.13 FCS_COP.1/CA_MAC (Cryptographic operation - MAC) . . . . . . . . . . . 76 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 ver- ification by travel document with EC) . . . . . . . . . . . . . . . . . . . . . 78 7.6.1.17 FCS_COP.1/SIG_VER_RSA (Cryptographic operation - Signature verification by travel document with RSA) . . . . . . . . . . . . . . . . . . 79 7.6.1.18 FCS_COP.1/AA_SGEN_EC (Cryptographic operation - Signature generation for AA with EC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.6.1.19 FCS_COP.1/AA_SGEN_RSA (Cryptographic operation - Signature generation for AA with RSA) . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.6.1.20 FCS_RNG.1 (Random number generation) . . . . . . . . . . . . . . . . . . 82 7.6.2 Class FIA Identification and Authentication . . . . . . . . . . . . . . . . . . 83 7.6.2.1 FIA_UID.1/PACE (Timing of identification) . . . . . . . . . . . . . . . . . . 83 7.6.2.2 FIA_UID.1 (Timing of identification) . . . . . . . . . . . . . . . . . . . . . . 85 7.6.2.3 FIA_UAU.1/PACE (Timing of authentication) . . . . . . . . . . . . . . . . . 85 7.6.2.4 FIA_UAU.1 (Timing of authentication) . . . . . . . . . . . . . . . . . . . . . 86 7.6.2.5 FIA_UAU.4/PACE (Single-use authentication mechanisms - Single- use authentication of the Terminal by the TOE) . . . . . . . . . . . . . . . 87 7.6.2.6 FIA_UAU.5/PACE (Multiple authentication mechanisms) . . . . . . . . . . 87 7.6.2.7 FIA_UAU.6/EAC (Re-authenticating - Re-authenticating of Terminal by the TOE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.6.2.8 FIA_UAU.6/PACE (Re-authenticating of Terminal by the TOE) . . . . . . . 89 7.6.2.9 FIA_UAU.6/CA (Re-authenticating – Re-authenticating of Terminal by the TOE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.6.2.10 FIA_UAU.6/Signature_Creation (Re-authenticating for Signature Creation) 90 7.6.2.11 FIA_API.1/CA (Authentication Proof of Identity by Chip Authentication) . 91 7.6.2.12 FIA_API.1/AA (Authentication Proof of Identity by Active Authentication) 91 7.6.2.13 FIA_AFL.1/PACE (Authentication failure handling - PACE authentica- tion using non-blocking authorization data) . . . . . . . . . . . . . . . . . 92 7.6.2.14 FIA_AFL.1/RAD (Authentication failure handling – for Signatory PIN) . . . 92 7.6.2.15 FIA_AFL.1/Suspend_PIN (Authentication failure handling – Sus- pending PIN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.6.2.16 FIA_AFL.1/Block_PIN (Authentication failure handling – Blocking PIN) . . 93 7.6.2.17 FIA_AFL.1/AuthAdmin (Authentication failure handling – of admin- istrator for personalization) . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.6.2.18 FIA_API.1 (Authentication proof of identity) . . . . . . . . . . . . . . . . . 94 7.6.3 Class FDP User Data Protection . . . . . . . . . . . . . . . . . . . . . . . . 95 7.6.3.1 FDP_ACC.1/TRM (Subset access control) . . . . . . . . . . . . . . . . . . . 95 7.6.3.2 FDP_ACF.1/TRM (Security attribute based access control) . . . . . . . . . 95 7.6.3.3 FDP_RIP.1 (Subset residual information protection) . . . . . . . . . . . . . 97 7.6.3.4 FDP_UCT.1/TRM (Basic data exchange confidentiality - MRTD) . . . . . . 98 7.6.3.5 FDP_UIT.1/TRM (Data exchange integrity – Terminal) . . . . . . . . . . . 98 7.6.3.6 FDP_ACC.1/SCD/SVD_Generation (Subset access control) . . . . . . . . . 99 7.6.3.7 FDP_ACF.1/SCD/SVD_Generation (Security attribute based access control) 99 7.6.3.8 FDP_ACC.1/SVD_Transfer (Subset access control) . . . . . . . . . . . . . 100 7.6.3.9 FDP_ACF.1/SVD_Transfer (Subset access control) . . . . . . . . . . . . . . 100 7.6.3.10 FDP_ACC.1/Signature_Creation (Subset access control) . . . . . . . . . . 101 7.6.3.11 FDP_ACF.1/Signature_Creation (Security attribute based access control) 101 7.6.3.12 FDP_UIT.1/DTBS (Data exchange integrity – DTBS) . . . . . . . . . . . . 102 7.6.3.13 FDP_SDI.2/Persistent (Stored data integrity monitoring and action) . . . 102 7.6.3.14 FDP_SDI.2/DTBS (Stored data integrity monitoring and action) . . . . . . 103 7.6.3.15 FDP_DAU.2/SVD (Data Authentication with Identity of Guarantor) . . . . 103 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC iv Contents 7.6.4 Class FTP Trusted Path/Channels . . . . . . . . . . . . . . . . . . . . . . . 103 7.6.4.1 FTP_ITC.1/PACE (Inter-TSF trusted channel after PACE) . . . . . . . . . . 103 7.6.4.2 FTP_ITC.1/SVD (Inter-TSF trusted channel) . . . . . . . . . . . . . . . . . 104 7.6.4.3 FTP_ITC.1/VAD (Inter-TSF trusted channel – TC Human Interface Device) 105 7.6.4.4 FTP_ITC.1/DTBS (Inter-TSF trusted channel – Signature creation Application) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6.5 Class FMT Security Management . . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.5.1 FMT_SMR.1/PACE (Security roles) . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.5.2 FMT_SMR.1 (Security roles) . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.5.3 FMT_LIM.1 (Limited capabilities) . . . . . . . . . . . . . . . . . . . . . . . . 107 7.6.5.4 FMT_LIM.2 (Limited availability) . . . . . . . . . . . . . . . . . . . . . . . . 107 7.6.5.5 FMT_MTD.1/INI_ENA (Management of TSF data - Writing Initializa- tion and Pre-personalization Data) . . . . . . . . . . . . . . . . . . . . . . . 108 7.6.5.6 FMT_MTD.1/INI_DIS (Management of TSF data - Reading and Using Initialization and Pre-personalization Data) . . . . . . . . . . . . . . . . . . 108 7.6.5.7 FMT_MTD.1/PA (Management of TSF data - Personalization Agent) . . . . 109 7.6.5.8 FMT_MTD.1/CVCA_INI (Management of TSF data - Initialization of CVCA Certificate and Current Date) . . . . . . . . . . . . . . . . . . . . . . 109 7.6.5.9 FMT_MTD.1/CVCA_UPD (Management of TSF data - Country Verify- ing Certification Authority) . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.6.5.10 FMT_MTD.1/DATE (Management of TSF data - Current date) . . . . . . . 110 7.6.5.11 FMT_MTD.1/CA_AA_PK (Management of TSF data - CA and AA Private Key) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.6.5.12 FMT_MTD.1/CAPK (Management of TSF data - Chip Authentication Private Key) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.6.5.13 FMT_MTD.1/KEY_READ (Management of TSF data - Key Read) . . . . . . 112 7.6.5.14 FMT_MTD.1/RAD (Management of TSF data) . . . . . . . . . . . . . . . . . 112 7.6.5.15 FMT_MTD.1/Signatory (Management of TSF data) . . . . . . . . . . . . . . 113 7.6.5.16 FMT_MTD.3 (Secure TSF data) . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.6.5.17 FMT_SMF.1 (Specification of Management Functions) . . . . . . . . . . . . 114 7.6.5.18 FMT_MOF.1 (Management of security functions behavior) . . . . . . . . . 114 7.6.5.19 FMT_MSA.1/Admin (Management of security attributes) . . . . . . . . . . 115 7.6.5.20 FMT_MSA.1/Signatory (Management of security attributes) . . . . . . . . 115 7.6.5.21 FMT_MSA.2 (Secure security attributes) . . . . . . . . . . . . . . . . . . . 115 7.6.5.22 FMT_MSA.3 (Static attribute initialization) . . . . . . . . . . . . . . . . . . 116 7.6.5.23 FMT_MSA.4 (Security attribute value inheritance) . . . . . . . . . . . . . . 116 7.6.6 Class FAU Security Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.6.6.1 FAU_SAS.1 (Audit storage) . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.6.7 Class FPT Protection of the Security Functions . . . . . . . . . . . . . . . . 117 7.6.7.1 FPT_EMS.1 (TOE Emanation) . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.6.7.2 FPT_EMS.1/SSCD (TOE Emanation of SCD and RAD) . . . . . . . . . . . . 119 7.6.7.3 FPT_FLS.1 (Failure with preservation of secure state) . . . . . . . . . . . . 119 7.6.7.4 FPT_TST.1 (TSF testing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.6.7.5 FPT_PHP.1 (Passive detection of physical attack) . . . . . . . . . . . . . . 120 7.6.7.6 FPT_PHP.3 Resistance to physical attack . . . . . . . . . . . . . . . . . . . 121 7.7 Security Assurance Requirements for the TOE . . . . . . . . . . . . . . . . 121 7.8 Security Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . 122 7.8.1 Security Functional Requirements Coverage . . . . . . . . . . . . . . . . . 122 7.8.2 TOE Security Requirements Sufficiency . . . . . . . . . . . . . . . . . . . . 124 7.9 Satisfaction of Dependencies of Security Requirements . . . . . . . . . . . 136 7.10 Rationale for Chosen Security Assurance Requirements . . . . . . . . . . 140 7.11 Security Requirements - Mutual Support and Internal Consistency . . . . 141 8 TOE Summary Specification (ASE_TSS) 142 8.1 TOE Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 8.1.1 User Identification and Authentication (ePass) . . . . . . . . . . . . . . . . 142 8.1.1.1 Travel document manufacturer Identification and Authentication . . . . . 143 8.1.1.2 Personalization Agent Identification and Authentication . . . . . . . . . . . 143 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC v Contents 8.1.1.3 PACE Terminal Identification and Authentication . . . . . . . . . . . . . . . 145 8.1.1.4 Establishing the trusted channel . . . . . . . . . . . . . . . . . . . . . . . . 145 8.1.2 User Identification and Authentication (eSign) . . . . . . . . . . . . . . . . 146 8.1.2.1 Administrator Identification and Authentication . . . . . . . . . . . . . . . 148 8.1.2.2 Signatory Identification and Authentication . . . . . . . . . . . . . . . . . . 149 8.1.2.3 PACE Terminal Identification and Authentication . . . . . . . . . . . . . . . 151 8.1.2.4 EIS-AIP-PACE Identification and Authentication . . . . . . . . . . . . . . . 152 8.1.3 Advanced Inspection Procedure with PACE . . . . . . . . . . . . . . . . . . 153 8.1.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 8.1.4.1 PACE or “PACE with CAM” protocol . . . . . . . . . . . . . . . . . . . . . . 153 8.1.4.2 Chip Authentication Protocol v.1 . . . . . . . . . . . . . . . . . . . . . . . . 154 8.1.4.3 Active Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 154 8.1.4.4 Terminal Authentication Protocol v.1 . . . . . . . . . . . . . . . . . . . . . 155 8.1.4.5 Passive Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.1.5 Access Control (General and ePass) . . . . . . . . . . . . . . . . . . . . . . 156 8.1.5.1 Read access to the data of the ePass application at phase Opera- tional Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 8.1.5.2 Write access to data of the ePass application at phase Operational Use . 157 8.1.5.3 General access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 8.1.6 AccessControl (eSign) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 8.1.6.1 Access Control provided by the Signature_Creation_SFP . . . . . . . . . . 158 8.1.6.2 Access Control provided by the SCD/SVD_Generation_SFP . . . . . . . . . 159 8.1.6.3 Access Control provided by the SVD_Transfer_SFP . . . . . . . . . . . . . 160 8.1.7 Key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.1.8 Signature Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.1.8.1 Signature Creation with EC . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.1.8.2 Signature Creation with RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.1.8.3 TOE IT environment generated hash values . . . . . . . . . . . . . . . . . 162 8.1.8.4 TOE generated hash values . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.1.8.4.1 Hash last round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.1.9 Test features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.1.10 Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 8.2 Compatibility between the Composite ST and the Platform-ST . . . . . . . 165 8.2.1 Assurance requirements of the composite evaluation . . . . . . . . . . . . 166 8.2.2 Security objectives for the environment of the platform . . . . . . . . . . 166 8.2.3 Usage of platform TSF by TOE TSF . . . . . . . . . . . . . . . . . . . . . . 166 8.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 A Overview of Cryptographic Algorithms 169 Bibliography 176 Index 180 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC vi Contents © Atos Information Technology GmbH 2021. 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. Atos Information Technology GmbH Otto-Hahn-Ring 6 D-81739 Munich Germany Disclaimer of Liability We have checked the contents of this manual for agreement 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 nec- essary corrections included in subsequent editions. Suggestions for improvement are welcome. Subject to change without notice. ©Atos Information Technology GmbH 2021. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 1 Chapter 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 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 2 Chapter 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 as 40 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 45 to 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 60 the 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.0’ Copyright © Atos Information Technology 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 . . . . . . . . . . . . . . . . . . . . . . . . 83 85 7.6 Subjects and security attributes for access control . . . . . . . . . . . . . 95 7.7 Secure values of the combinations of security attributes . . . . . . . . . . 116 7.8 Security assurance requirements: EAL4 augmented with ALC_ DVS.2, ATE-DPT.2 and AVA_VAN.5 . . . . . . . . . . . . . . . . . . . . . . 122 7.9 Dependencies between the SFR for the TOE . . . . . . . . . . . . . . . . . 136 90 7.10 Satisfaction of dependencies of security assurance requirements . . . . . 140 8.1 Relevant Platform SFRs used as services . . . . . . . . . . . . . . . . . . . 166 8.2 Relevant Platform SFRs used as mechanisms . . . . . . . . . . . . . . . . 167 A.1 Used Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 1.5 List of Figures 95 5.1 Security Objective Rationale overview . . . . . . . . . . . . . . . . . . . . 48 7.1 Functional Requirement to TOE security objective mapping . . . . . . . . 123 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 4 Chapter 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.0’ 110 TOE ‘CardOS V6.0 ID R1.0’ Sponsor Atos Information Technology GmbH Editor(s) Atos Information Technology GmbH CC Version 3.1 (Revision 5) Assurance Level EAL4 augmented with ALC_DVS.2, ATE_DPT.2, and AVA_ 115 VAN.5. Status Release Version 1.91R Date 2021-10-21 Certification ID BSI-DSZ-CC-1162 120 Keywords ICAO, PACE, EAC, Extended Access Control, ID-Card, Machine Read- able Travel Document, CardOS 2.2 TOE Reference This Security Target refers to the Product ‘CardOS V6.0 ID R1.0’ (TOE) of Atos Information Technology GmbH for CC evaluation. 125 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 5 Chapter 2. ST Introduction (ASE_INT) 2.3 TOE Overview The Target of Evaluation (TOE) ‘’CardOS V6.0 ID R1.0’’ 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. 130 Here, an application is a collection of data (data groups) and their access conditions. We 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: ˆ EAC1-protected data: Sensitive user data protected by EAC1 (cf. [BSI-TR-03110-1- V220]), 135 ˆ all other (common) user data. Other user data are protected by Password Authenticated Connection Establishment (PACE, cf. also [BSI-TR-03110-2-V221]). Note that EAC1 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 140 configuration performing BAC instead of PACE is acting outside of the security policy defined by this ST. 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. 145 Applications considered in [BSI-TR-03110-1-V220] and [BSI-TR-03110-2-V221] are ˆ an electronic passport (ePass1 ) application, ˆ an electronic identity (eID) application, and ˆ a signature (eSign) application. Atos Information Technology GmbH implemented all these applications in the TOE. Only 150 ePass and eSign application are subject of CC Evaluation. 2.3.1 Usage and major security features of the TOE 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 155 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 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 160 connected terminal is provided, ˆ inconspicuous tracing of the card is averted, ˆ 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 165 Summary Specification (ASE_TSS). 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 6 Chapter 2. ST Introduction (ASE_INT) 2.3.2 TOE Type 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 170 ePassport application provides an ICAO-compliant ([ICAO-9303-2015]) ePass Application. 2.3.3 File System of the TOE The TOE is configured with one of the dedicated file systems during Initialization. Depend- ing 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, 175 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 application is available. The available major Configurations of the file system related to this ST are described in detail in other documents [Atos-V60-ADM]. They do not differ in security-relevant ways. 180 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 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 185 description of the object system, are: ˆ ePassport: User data are stored in an ICAO-compliant ([ICAO-9303-2015]) ePass Application 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 190 Application. ˆ eID: User data are contained in an ICAO-compliant ([ICAO-9303-2015]) ePass Applica- tion, 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 195 this evaluation aim also at enabling the use of the product as a residence permit using the ePass application. 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 200 application 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 the signature creation functionality of the eSign application is blocked until the legitimate signatory has set the reference authentication data (RAD). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 7 Chapter 2. ST Introduction (ASE_INT) 2.3.4 Non-TOE hardware/software/firmware 205 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 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: 210 ˆ 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 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 215 [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, 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. 220 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). 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 225 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 Certi- fication Authority (CVCA) Link Certificates, Document Verifiers Certificates and Terminal Certificates – must be available in the card verifiable format defined in [BSI-TR-03110-3- 230 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 the TOE. 235 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 BAC (cf. Application note 5 of [BSI-CC-PP-0068-V2-2011-MA-01]). 240 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 perform its claimed security features. 245 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 8 Chapter 2. ST Introduction (ASE_INT) 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 signature device according to eIDAS must be certified using the Common Criteria, claiming 250 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. 2.4 TOE Description 255 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- lishment (PACE) with CAN and MRZ or alternatively Basic Access Control (BAC) as well as 260 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. The ePass Application can be accessed both through the contact-based and the contactless 265 interface of the TOE according to [BSI-CC-PP-0056-V2-2012-MA-02]. For the eSign Appli- cation 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. For the ePass Application, the card holder can control the access to his user data by conscious presenting his document to authorities2 (CAN or MRZ authentication as specified 270 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 . Using a secret PIN represents a manifestation of declaration of intent bound to this secret 275 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. The cryptographic algorithms used by the TOE are configurable. Personalization must 280 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 applications are chosen in accordance to international recommendations [SOG-IS-Crypto- Catalog-V1.2] . 285 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. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 9 Chapter 2. ST Introduction (ASE_INT) For further details of the supported crypto protocol configurations and parameters refer to 290 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 295 target only contains security claims for the inspection procedures involving PACE. The configuration depends on the Initialization of the TOE. A more detailed description is given in the Administrator Guidance [Atos-V60-ADM]. The TOE comprises of ˆ the circuitry of the chip including all IC Dedicated Software being active in the Opera- 300 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 instal- 305 lation 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. 310 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 315 defined 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 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 ([Atos-V60-ADM]) provides further requirements for the 320 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 325 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 330 module, 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- 335 1110-V3-2020) 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. 340 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 10 Chapter 2. ST Introduction (ASE_INT) 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 345 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. 350 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, 355 ˆ 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 360 guidance 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 365 the Initializer. 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 370 manufacturer. Additionally, the IC manufacturer adds the IC embedded software in the non-volatile programmable memory using the certified loading mechanisms of the IC. The IC is securely delivered from the IC manufacturer to the composite product manufac- turer. The IC may be delivered as a wafer, module or a packaged component. 375 Life cycle phase C “Composite Product Integration and Initialization” Step 4 (optional): The composite product manufacturer ˆ produces modules, or packaged components, combined with hardware for the contact- based or contactless interfaces (e.g. inlays) Step 5: The initializer 380 ˆ equips the card’s chip with pre-personalization data, and ˆ creates the application(s). 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 385 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]). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 11 Chapter 2. ST Introduction (ASE_INT) 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. 390 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 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. 395 Life cycle phase D “Personalization” Step 6: The Personalization of the card includes for the ePass application: 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, 400 3) printing the visual readable data onto the physical part of the card, and 4) configuration of the TSF, if necessary. 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 405 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 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. 410 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 Authentication Key(s), the Terminal Authentication trust anchor, the effective date and the Chip 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]). 415 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 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]) 420 From a hardware point of view, this cycle phase is already an operational use of the com- posite product and not a personalization of the hardware. The hardware’s “Personalization” (cf. [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 425 from the personalization of the TOE as Qualified Signature Creation Device, e.g. the generation of a signature key. 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” 430 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 security policy of the issuer. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 12 Chapter 2. ST Introduction (ASE_INT) 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 435 note 4 of [BSI-CC-PP-0068-V2-2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]). 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 440 Phase 2: IC Development Phase 3: IC Manufacturing Phase 4: IC Packaging Phase 5: Composite Product Integration Phase 6: Personalization 445 Phase 7: Operational Use 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. 450 The TOE can be delivered in various form factors. Thus, IC packaging i.e. phase 4 of [BSI-CC-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]. 455 Observe, that the TOE has reached its secure state already at the delivery point which is 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 and security mechanisms provided by the TOE developer. In particular, observe that both 460 the Initialization and the Personalization must be conducted in a trusted environment (c.f. 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. 465 The last life cycle phase E corresponds to the first step of Phase 7 of [BSI-CC-PP-0084-2014]. 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, 470 volatile and non-volatile memory, and associated software, packaged and embedded in a carrier. The 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 connec- tion to systems separate from the chip through TOE’s interfaces in accordance with ISO 475 standards. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 13 Chapter 2. ST Introduction (ASE_INT) The physical constituent of the TOE is IC with the operating system loaded using the certified 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 480 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 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 485 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, 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 490 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 systems are described in more detail in the guidance [Atos-V60-ADM], [Atos-V60-USR]. 2.4.2.3 TOE Delivery Format In summary the delivery of the TOE consists of: 495 ˆ the integrated circuit (IC) with the operation system pre-loaded ˆ the administrator and user guidance documentation [Atos-V60-ADM], [Atos-V60-USR] ˆ personalization information package, required for the secure personalization of the TOE. Further details about the secure personalization are provided in the guidance documentation. 500 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 14 Chapter 3. Conformance Claim 3 Conformance Claim 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, Revi- 505 sion 5, April 2017, [CC-Part1-V3.1] Part 2: Security functional components; CCMB-2017-04-002, Version 3.1, Revi- sion 5, April 2017, [CC-Part2-V3.1] Part 3: Security assurance components; CCMB-2017-04-003, Version 3.1, Revi- sion 5, April 2017, [CC-Part3-V3.1] 510 as follows: 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. 515 3.2 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- MA-02] 520 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]. However, since [BSI-CC-PP-0056-V2-2012-MA-02] already claims strict conformance to 525 [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. This ST claims also strict conformance to 530 ˆ 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] ˆ Common Criteria Protection Profiles for Secure Signature Creation Device – Part 4: Extension for device with key generation and trusted communication with certificate generation application, EN 419211-4:2013, [BSI-CC-PP-0071-2012-MA-01] 535 ˆ 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 protection profiles covers the part of the security policy for the eSign application of the TOE, 540 and hence are applicable, if the eSign application is operational. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 15 Chapter 3. Conformance Claim 3.3 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 software are evaluated at level EAL 6+. 545 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.4 Conformance Claim Rationale The TOE type is a chip consistent with the TOE type of the claimed PPs [BSI-CC-PP-0056- V2-2012-MA-02] and [BSI-CC-PP-0059-2009-MA-02], [BSI-CC-PP-0071-2012-MA-01], and 550 [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 combination of hardware and software configured to securely create, use and manage 555 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 introduction of the PACE-Chip Authentication Mapping but this is just a combination of 560 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 elements of the security problem definitions, security objectives and the security functional requirements but all of these do not change the original definitions. 565 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 of TOE functions in the Initialization and Personalization as well as using the TOE 570 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: ˆ OT.AA_Proof models the additional objective of the TOE to provide the Active 575 Authentication feature. There are no corresponding additions to the SPD because Active Authentication is just another mean (in addition to the Chip Authentication modelled in the PP) to counter the threat T.Counterfeit. Therefore, this extension does not contradict the protection profiles this ST claims conformance to. 5. The security objectives for the operational environment in this ST include all security 580 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 protection profiles. 585 ˆ 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 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 16 Chapter 3. Conformance Claim not used. This extension obviously does not contradict to the objectives definitions in the PPs. 590 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- 0059-2009-MA-02]. 595 ˆ 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 protected user data. These access control SFPs and security roles are unified to FDP_ACF.1/TRM and FMT_SMR.1 ˆ The SFRs FIA_API.1/AA, FMT_MTD.1/CA_AA_PK, FCS_COP.1/AA_SGEN_EC, and 600 FCS_COP.1/AA_SGEN_RSA are added to model the additional Active Authentication feature for the ePass application. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 17 Chapter 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 PACE EAC context 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 625 covers ‘User Data on the 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 (be- PACE EAC ing not authentication data) being transferred in the context of the ePassport ap- plication of the travel document as defined in [ICAO-TR-110] between the TOE and 630 an authenticated terminal acting as Basic Inspection System with PACE (in the sense of [ICAO-TR-110]). User data can be received and sent (exchange <=> {receive, send}). travel document tracing data Technical information about the current and previous PACE EAC locations of the travel document gathered unnoticeable by the travel document holder 635 recognising the TOE not knowing any PACE password. TOE tracing data can be provided / gathered. Logical travel document sensitive User Data Sensitive biometric reference data EAC (EF.DG3, EF.DG4) Due to interoperability reasons the ICAO standard [ICAO-TR-110] requires that Basic 640 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 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 645 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 EAC chip 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 650 The confidentiality, integrity and signatory’s sole control over the use of the SCD shall be maintained. 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 655 Their integrity and the unforgeability of the link to the signatory provided by the electronic signature shall be maintained. 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. 660 Secondary Assets Accessibility to the TOE functions and data only for authorised subjects Property PACE of the TOE to restrict access to TSF and TSF-data stored in the TOE to authorised subjects only. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 18 Chapter 4. Security Problem Definition Genuineness of the TOE Property of the TOE to be authentic in order to provide claimed PACE 665 security functionality in a proper way. This asset also covers ‘Authenticity of the MRTD’s chip’ in [BSI-CC-PP-0055-110]. TOE internal secret cryptographic keys Permanently or temporarily stored secret cryp- PACE tographic material used by the TOE in order to enforce its security functionality. TOE internal non-secret cryptographic material Permanently or temporarily stored PACE 670 non-secret cryptographic (public) keys and other non-secret material (Document Security Object SOD containing digital signature) used by the TOE in order to enforce its security functionality. travel document communication establishment authorisation data Restricted- PACE revealable1 authorisation information for a human user being used for verification 675 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- 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 680 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 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 685 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 are not to be send to the TOE (cf. Application note 8 of [BSI-CC-PP-0068-V2-2011-MA-01]). 690 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]. Please note that a travel document holder can also be an attacker (s. below). 695 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]. Please note that a travel document presenter can also be an attacker (s. below). 700 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-0055-110]. 705 Basic Inspection System with PACE BIS-PACE A technical system being used by an inspecting authority5 and verifying the PACE EAC travel 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 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 19 Chapter 4. Security Problem Definition data (DG2) of the travel document holder). BIS-PACE implements the terminal’s part 710 of the PACE protocol and authenticates itself to the travel document using a shared password (PACE password) and supports Passive Authentication. Document Signer DS An organisation enforcing the policy of the CSCA and signing the Document Security PACE EAC Object stored on the travel document for passive authentication. A Document Signer 715 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 confirming correctness of user and TSF data stored in the travel document. The CSCA 720 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 PACE EAC 725 to 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, 730 (iii) writing a subset of these data on the physical travel document (optical personali- sation) 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, 735 (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]. 740 Manufacturer Generic term for the IC Manufacturer producing integrated circuit and PACE EAC the travel document Manufacturer completing the IC to the travel document. The Manufacturer 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 docu- ment Manufacturer using this role Manufacturer. This entity is commensurate with 745 ‘Manufacturer’ in [BSI-CC-PP-0055-110]. Attacker A threat agent (a person or a process acting on his behalf) trying to undermine PACE the 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 750 role recognised by 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), 755 (iii) to forge a genuine travel document, or (iv) to trace a travel document. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 20 Chapter 4. Security Problem Definition 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. 760 Country Verifying Certification Authority 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 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 765 within this PKI. The updates of the public key of the CVCA are distributed in the form of 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 770 by the Extended Inspection Systems. The Document Verifier manages the authorization 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 775 IS A technical system used by the border control officer of the receiving State EAC (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 780 EIS The Extended Inspection System (EIS) performs the Advanced Inspection Procedure EAC 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 785 BAC by optical reading the travel document providing this information. (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. 790 Security attributes of the EIS are defined by means of the Inspection System Cer- tificates. 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 795 R.Sigy. Administrator User who is in charge to perform the TOE initialisation, TOE personalisation SSCD CGA SCA or other TOE administrative functions. The subject S.Admin is acting in the role R.Admin for this user after successful authentication as administrator. 800 Signatory User who hold the TOE and use it on their own behalf or on behalf of the SSCD CGA SCA natural or legal person or entity they represent. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 21 Chapter 4. Security Problem Definition The subject S.Sigy is acting in the role R.Sigy for this user after successful authentica- tion as signatory. 4.2 Threats 805 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 method of TOE’s use in the operational environment. 4.2.1 T.Skimming (Skimming travel document / Capturing Card- Terminal Communication) 810 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 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. 815 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 820 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 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]). 825 4.2.2 T.Eavesdropping (Eavesdropping on the communication be- tween the TOE and the PACE terminal) 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. 830 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 Notes 835 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]). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 22 Chapter 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 840 movement of the travel document) unambiguously identifying it remotely by establishing or listening to a communication 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. 845 Asset privacy of the travel document holder 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]). 850 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 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 855 stored on the travel document or/and exchanged between the TOE and the terminal connected in order to outsmart (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 860 biographic or biometric data). The attacker does it in such a way that the terminal connected perceives these modified data as authentic one. Threat agent having high attack potential Asset integrity of the travel document 4.2.5 T.Abuse-Func (Abuse of Functionality) 865 PACE EAC Adverse action An attacker may use functions of the TOE which shall not be used in TOE operational phase in order (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 func- 870 tionality of the TOE. This threat addresses the misuse of the functions for the initialisation and 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 875 legitimate travel documents Asset integrity and authenticity of the travel document, availability of the func- 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 23 Chapter 4. Security Problem Definition Notes 880 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. application note 16 of [BSI-CC-PP-0068-V2-2011-MA-01]). 4.2.6 T.Information_Leakage (Information Leakage from travel document) 885 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 connected. The information leakage may be inherent in the normal operation or caused by the attacker. 890 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) PACE EAC Adverse action An attacker may perform physical probing of the travel docu- ment in order 895 (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 (i) its security functionality (hardware and software part, as well), (#) the User Data or the TSF-data stored on the travel document. 900 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- tionality of the travel document, confidentiality of User Data and TSF-data of the travel document 905 Notes 1. Physical tampering may be focused directly on the disclosure or manipulation of the 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 910 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 failure analysis and IC reverse engineering efforts may be used. Before that, hardware security mechanisms and layout characteristics need to be identified. Determination of 915 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 [BSI-CC-PP-0068-V2-2011-MA-01]). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 24 Chapter 4. Security Problem Definition 4.2.8 T.Malfunction (Malfunction due to Environmental Stress) 920 PACE EAC Adverse action An attacker may cause a malfunction the travel document’s hardware and Embedded Software by applying environmental stress in order to (i) deactivate or modify security features or functionality of the TOE’ hard- ware or to 925 (ii) circumvent, deactivate or modify security functions of the TOE’s Embed- ded Software. This may be achieved e.g. by operating the travel document outside the normal operating conditions, exploiting errors in the travel document’s Em- bedded Software or misusing administrative functions. To exploit these 930 vulnerabilities an attacker needs information about the functional operation. Threat agent having high attack potential, being in possession of one or more legitimate travel documents, having information about the functional opera- tion Asset integrity and authenticity of the travel document, availability of the func- 935 tionality of the travel document, confidentiality of User Data and TSF-data of the travel document Notes 1. A malfunction of the TOE may also be caused using a direct interaction with elements 940 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 refer- ence data) 945 EAC Adverse action An attacker tries to gain the sensitive biometric reference data 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 950 differs from those in the asset under the attack (sensitive biometric reference data vs. 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 955 the portrait are visually readable on the physical part of the travel document 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 960 reference) Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 25 Chapter 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 965 document’s chip used for authentication of a traveller by possession of a travel 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 970 legitimate travel documents Asset authenticity of user data stored on the TOE 4.2.11 T.SCD_Divulg (Storing, copying and releasing of the signa- ture creation data) SSCD CGA SCA Adverse action An attacker stores or copies the SCD outside the TOE. An at- 975 tacker can obtain the SCD during generation, storage and use for signature creation 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 980 or any other data exported outside the TOE, which is a threat against the secrecy 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 vulnera- bilities, resulting in arbitrary security compromises. This threat is directed 985 against SCD, SVD and DTBS. Notes 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- 990 trator Personalization Key and Chip Authentication session keys (CA-K MAC, CA-KEnc). 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 26 Chapter 4. Security Problem Definition 4.2.15 T.SigF_Misuse (Misuse of the signature creation function of 995 the TOE) SSCD CGA SCA Adverse action An attacker misuses the signature creation function of the TOE to create SDO for data the signatory has not decided to sign. The TOE is subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by 1000 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 used by the TOE for signing does not match the DTBS the signatory intended to sign. 1005 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 elec- tronic signature that has been created by the TOE, and the violation of the integrity of the signed data object is not detectable by the signatory or by third parties. The signature created by the TOE is subject to deliberate at- 1010 tacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. 4.3 Organizational Security Policies 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 organi- 1015 zation 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) 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 1020 the Personalisation Agent Key. Notes 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]. 1025 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 27 Chapter 4. Security Problem Definition 4.3.2 P.Pre-Operational (Pre-operational handling of the travel doc- ument) PACE EAC 1) The travel document Issuer issues the travel document and approves it using the terminals complying with all applicable laws and regulations. 2) The travel document Issuer guarantees correctness of the user data (amongst other 1030 of those, concerning the travel document holder) and of the TSF-data permanently stored in the TOE7 . 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, i.e. before they are in the operational phase, cf. sec. 1.2.3 in [BSI-CC-PP- 1035 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. 1040 4.3.3 P.Card_PKI (PKI for Passive Authentication (issuing branch)) Note 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 implemented 1045 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 doc- ument. For this aim, he runs a Country Signing Certification Authority (CSCA). The 1050 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]. The CSCA shall create the Document Signer Certificates for the 1055 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, 1060 (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. 7 cf. Table 1 and Table 2 in [BSI-CC-PP-0068-V2-2011-MA-01] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 28 Chapter 4. Security Problem Definition 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 1065 (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 1070 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). 1075 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]). 1080 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. 1085 Notes 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 1090 private personal data of the travel document holder. The sensitive biometric reference data can be 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 1095 Verifier Certificate. The travel document’s chip shall protect the confidentiality and integrity of the sensitive private personal data even during transmission to the Extended Inspection System after Chip Authentication Version 1 or PACE Chip Authentication Mapping, respectively9 . 8 This order is commensurate with [ICAO-TR-110]. 9 since Chip Authentication functionally is part of PACE Chip Authentication Mapping Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 29 Chapter 4. Security Problem Definition 4.3.7 P.Personalisation (Personalisation of the travel document by 1100 issuing State or Organisation only) EAC The issuing State or Organisation guarantees the correctness of the biographical data, the 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 1105 by the issuing State or Organisation only. 4.3.8 P.CSP_QCert (Qualified certificate) 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 1110 implemented in the TOE under sole control of the signatory. The CSP ensures that the use of the TOE as SSCD is evident with signatures through the certificate or other publicly available information. 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 1115 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 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 1120 subsequent change of the data is detectable. 4.3.10 P.Sigy_SSCD (TOE as secure signature creation device) 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. 1125 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 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 1130 The assumptions describe the security aspects of the environment in which the TOE will be used or is intended to be used. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 30 Chapter 4. Security Problem Definition 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 1135 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 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, 1140 (ii) hands over the Document Signer Public Key to the CA for certification, (iii) keeps the Document Signer Private Key secret and (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 1145 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 user data according to [ICAO-9303-2015]. 4.4.2 A.Insp_Sys (Inspection Systems for global interoperability) EAC The Extended Inspection System (EIS) for global interoperability 1150 (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]. 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 1155 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 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 1160 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 assumptions for the Inspection Systems for handling the the EAC functionality of the TOE. 1165 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 pairs and certificates for their public keys encoding the access control 1170 rights. The Country Verifying Certification Authorities of the issuing States or Organisations are signing the certificates 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 their travel document’s chip. 1175 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 31 Chapter 4. Security Problem Definition 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 it covers the pre-requisite for performing the Terminal Authentication 1180 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) 1185 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. 4.4.6 A.Env_Admin (Environment for administrator) TOE initialization, TOE personalization by the Administrator only takes place within a trusted environment. 1190 eSign update (generation of 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 1195 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. 3. For eSign update the administrator resides in a trusted environment. 1200 4. After authentication and trusted channel establishment communication via trusted channel is considered to be a trusted environment. 4.4.7 A.Env_Mass_Signature (Environment for a mass signature TOE) Mass signature generation only takes place within a trusted environment. 1205 Notes 1. “A.Env_Mass_Signature” is added to the security problem definitions of the claimed protection profiles. 2. Trusted Environment means for mass signature generation a physically trusted envi- 1210 ronment. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 32 Chapter 5. Security Objectives 5 Security Objectives This chapter describes the security objectives for the TOE and for the TOE environment. The security objectives for the TOE environment are separated into security objectives for the development, and production environment and security objectives for the operational 1215 environment. 5.1 Security Objectives for the TOE The following TOE security objectives address the protection provided by the TOE indepen- dent of the TOE environment. 5.1.1 OT.Data_Integrity (Integrity of Data) 1220 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 modifying). The TOE must ensure integrity 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. 1225 Notes 1. OT.Data_Integrity holds also for Extended Inspection System which has used an authenticated BIS-PACE for authentication. 5.1.2 OT.Data_Authenticity (Authenticity of Data) 1230 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 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 1235 receiving by the terminal) and by an active verification by the TOE itself (at receiving by the TOE)4 . Notes 1. REFINEMENT OT.Data_Authenticity holds also for Extended Inspection System which 1240 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 33 Chapter 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 confidentiality of the User Data and the TSF-data during their exchange between the TOE 1245 and the terminal connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. Note 1. REFINEMENT OT.Data_Confidentiality holds also for Extended Inspection System which 1250 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 contactless/contact interface of the TOE without knowledge of the correct values of shared 1255 passwords (PACE passwords) in advance. 5.1.5 OT.Prot_Abuse-Func (Protection against Abuse of Functional- ity) 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 (i) to manipulate or to disclose the User Data stored in the 1260 TOE, (#) to manipulate or to disclose the TSF-data stored in the TOE, (#) to manipulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. 5.1.6 OT.Prot_Inf_Leak (Protection against Information Leakage) 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 1265 ˆ 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, ˆ by forcing a malfunction of the TOE and/or ˆ by a physical manipulation of the TOE. 1270 Note 1. This objective pertains to measurements with subsequent complex signal process- ing 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]). 1275 5 where appropriate, see [BSI-CC-PP-0068-V2-2011-MA-01], Table 2 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 34 Chapter 5. Security Objectives 5.1.7 OT.Prot_Phys-Tamper (Protection against Physical Tamper- ing) 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 ˆ measuring through galvanic contacts representing a direct physical probing on the 1280 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), 1285 ˆ 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) 1290 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. 1295 The following two TOE security objectives (OT.Identification and OT.AC_Pers) ad- dress the aspects of identified threats to be countered involving TOE’s environ- ment. 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 1300 non-volatile memory. The Initialisation Data must provide a unique identification of the IC during 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 1305 1. The OT.AC_Pers implies that the data of the LDS groups written during personalization 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]). 6 amongst other, IC Identification data Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 35 Chapter 5. Security Objectives 5.1.10 OT.AC_Pers (Access Control for Personalisation of logical 1310 MRTD) PACE EAC The TOE must ensure that the logical travel document data in EF.DG1 to EF.DG16, the Document Security Object according to LDS [ICAO-9303-2015] and the TSF data can be written by 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 1315 after personalisation of the document. 5.1.11 OT.Sens_Data_Conf (Confidentiality of sensitive biometric reference data) 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 1320 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 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 1325 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 au- thenticity) EAC The TOE must support the Inspection Systems to verify the identity and authenticity of the 1330 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 authenticity proof provided by travel document’s chip shall be protected against attacks with high attack potential. 1335 Note The OT.Chip_Auth_Proof implies the travel document’s chip to have (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 1340 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 Key that matches the Chip Authentication Private Key of the travel document’s chip. 1345 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 Signer. 1350 ˆ 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 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 36 Chapter 5. Security Objectives (ii) the hash value of EF.CardSecurity in the Document Security Object signed by the 1355 Document Signer. 5.1.13 OT.AA_Proof (Proof of the travel document’s chip authentic- ity) 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 1360 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. 1365 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 1370 SVD has 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. 1375 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) 1380 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. 7 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 37 Chapter 5. Security Objectives 5.1.17 OT.SCD_SVD_Corresp (Correspondence between SVD and 1385 SCD) 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. 5.1.18 OT.SCD_Secrecy (Secrecy of the signature creation data) 1390 SSCD CGA SCA The secrecy of the SCD (used for signature creation) shall be reasonably assured against attacks with a high attack potential. Note 1. The TOE shall keep the confidentiality of the SCD at all times, in particular during 1395 SCD/SVD generation, signature creation operation, storage and secure destruction. 5.1.19 OT.Sig_Secure (Cryptographic security of the electronic sig- nature) 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 1400 digital 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 signatory only) SSCD CGA SCA The TOE shall provide the digital signature creation function for the legitimate signatory 1405 only 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 1410 the 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. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 38 Chapter 5. Security Objectives 5.1.23 OT.Tamper_ID (Tamper detection) 1415 SSCD CGA SCA The TOE shall provide system features that detect physical tampering of its components, and uses those features to limit security breaches. 5.1.24 OT.Tamper_Resistance (Tamper resistance) SSCD CGA SCA The TOE shall prevent or resist physical tampering with specified system devices and components. 1420 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 1425 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 1430 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 1435 Life Cycle Phase “Usage/Operational”. 5.1.27 OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD im- port) 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. 1440 Notes 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- 1445 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 (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 1450 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. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 39 Chapter 5. Security Objectives 5.1.28 OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS im- port) 1455 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. Notes 1460 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] 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 1465 according 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 necessary functionality by the SCA. 1470 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: 5.2.1 OE.Legislative_Compliance (Issuing of the travel document) 1475 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 (issuing) branch 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 1480 for Passive Authentication (issuing branch)) above) 5.2.2 OE.Passive_Auth_Sign (Authentication of travel document by Signature) 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 1485 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 (iii) publish the Certificate of the CSCA Public Key (CCSCA ). 1490 Hereby authenticity and integrity of these certificates are being maintained. A Document Signer acting in accordance with the CSCA policy must (i) generate a cryptographically secure Document Signing Key Pair, Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 40 Chapter 5. Security Objectives (ii) ensure the secrecy of the Document Signer Private Key, (iii) hand over the Document Signer Public Key to the CSCA for certification, 1495 (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 Security Object contains only the hash values of genuine user data according to [6]. The 1500 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 (i) establish the correct identity of the travel document holder and create the biographical 1505 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 as defined in [ICAO-9303-2015]8 , 1510 (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 5.2.4 OE.Terminal (Terminal operating) 1515 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- 110], of the Passive Authentication [ICAO-TR-110] (by verification of the signature of 1520 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. 4) The related terminals securely store the Country Signing Public Key and the Document 1525 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 of respective data handled by them (e.g. confidentiality of the PACE passwords, 1530 integrity of PKI certificates, etc.), where it is necessary for a secure operation of the TOE according to the current PP. Note 8 see also [ICAO-9303-2015], part 10 9 This order is commensurate with [ICAO-TR-110]. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 41 Chapter 5. Security Objectives 1. OE.Terminal completely covers and extends “OE.Exam_MRTD”, “OE.Passive_Auth_ 1535 Verif” and “OE.Prot_Logical_MRTD” from BAC PP [BSI-CC-PP-0055-110]. (cf. applica- tion 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 Obliga- tions) 1540 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 1545 TOE environment. 5.2.6 OE.Auth_Key_Travel_Document (Travel document Authenti- cation Key) EAC The issuing State or Organisation has to establish the necessary public key infrastructure in order to 1550 (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 authen- ticity of the travel document’s chip used for genuine travel document by certification 1555 of the Chip Authentication Public Key by means of the Document Security Object. 5.2.7 OE.AA_Key_Travel_Document (Travel document Authentica- tion Key) The issuing State or Organization has to establish the necessary public key infrastructure in order to 1560 (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 authen- ticity 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 1565 10 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 42 Chapter 5. Security Objectives 5.2.8 OE.Authoriz_Sens_Data (Authorization for Use of Sensitive Biometric 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 1570 of 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. 1575 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 document 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. 1580 The 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]. 1585 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 1590 from [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 1595 perform AA) 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 logical 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 1600 prevent 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 43 Chapter 5. Security Objectives 5.2.11 OE.Ext_Insp_Systems (Authorization of Extended Inspec- tion Systems) EAC The Document Verifier of receiving States or Organisations authorizes Extended Inspection 1605 Systems by creation of Inspection System Certificates for access to sensitive biometric reference 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 1610 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) 1615 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. 1620 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 1625 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. 1630 In particular, if the TOE requires a trusted channel for import of the VAD, the HID shall support usage of this trusted channel. 5.2.16 OE.HID_TC_VAD_Exp (Trusted channel of HID for VAD ex- port) SCA The HID provides the human interface for user authentication. The HID will ensure confiden- 1635 tiality and integrity of the VAD as needed by the authentication method employed including export to the TOE by means of a trusted channel. Notes Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 44 Chapter 5. Security Objectives 1. This security objective for the TOE is partly covering OE.HID_VAD (Protection of the 1640 VAD) from the core [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 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 1645 at the other end of the trusted channel according to OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD 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. 1650 5.2.17 OE.DTBS_Intend (SCA sends data intended to be signed) SSCD CGA SCA The signatory shall use a trustworthy SCA that: ˆ 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 1655 by the TOE; ˆ attaches the signature produced by the TOE to the data or provides it separately. Note 1. The SCA should be able to support advanced electronic signatures. Currently, there 1660 are three formats defined by ETSI recognized as meeting the requirements needed by advanced electronic signatures: CadES, XadES and PadES. These three formats mandate to include the hash of the signer’s public key certificate in the data to be signed. In order to support for the mobility of the signer, it is recommended to store the certificate info on the SSCD for use by SCA and identification of the corresponding 1665 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) 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 1670 of the DTBS/R, the SCA shall support usage of this trusted channel. 5.2.19 OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS ex- port) SCA The SCA provides a trusted channel to the TOE for the protection of the integrity of the DTBS to ensure that the DTBS/R cannot be altered undetected in transit between the SCA 1675 and the TOE. Notes 1. This security objective for the TOE is partly covering OE.DTBS_Protect (SCA protects the data intended to be signed) from the core [BSI-CC-PP-0059-2009-MA-02]. While 1680 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] requires the SCA and the TOE to implement a trusted channel for the protection of the DTBS: the SCA Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 45 Chapter 5. Security Objectives exports the DTBS and establishes one end of the trusted channel according to OE.SCA_ TC_DTBS_Exp, the TOE imports DTBS at the other end of the trusted channel according 1685 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. 5.2.20 OE.Signatory (Security obligation of the signatory) 1690 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 1. The signatory may reveal, if necessary, his or her verification values of the PACE 1695 password to an authorized person or device (PACE Terminal) who are trustworthy. 5.2.21 OE.Dev_Prov_Service (Authentic SSCD provided by SSCD Provisioning Service) CGA The SSCD Provisioning Service handles authentic devices that implement the TOE, prepares the TOE for proof as SSCD to external entities, personalizes the TOE for the legitimate user 1700 as signatory, links the identity of the TOE as SSCD with the identity of the legitimate user, and delivers the TOE to the signatory. NOTE This objective replaces OE.SSCD_Prov_Service (Authentic SSCD provided by SSCD- 1705 provisioning service) from the core PP, which is possible as it does not imply any additional requirements for the operational environment when compared to OE.SSCD_Prov_Service (OE.Dev_Prov_Service is a subset of OE.SSCD_Prov_Service). 2. The preparation of the TOE for proof as SSCD to external entities only applies in case a communication channel to the CGA (via trusted channel) in the Life Cycle Phase 1710 “Usage/Operational” is needed. 5.2.22 OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) CGA The CSP shall check by means of the CGA whether the device presented for application of a (qualified) certificate holds unique identification as SSCD, successfully proved this identity 1715 as SSCD to the CGA, and whether this identity is linked to the legitimate holder of the device as applicant for the certificate. Note 1. This security objective only applies in case a communication channel to the CGA (via 1720 trusted channel) in the Life Cycle Phase “Usage/Operational” is needed. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 46 Chapter 5. Security Objectives 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. The developer prepares the TOE by pre-initialization for the delivery to the customer (i.e. the 1725 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_ Prov_Service (Authentic SSCD provided by SSCD-provisioning service) except the additional 1730 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 OT.TOE_SSCD_Auth (Authentication proof as SSCD) and OT.TOE_TC_SVD_ 1735 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 security functionality of the TOE. Nevertheless the 1740 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] . 1745 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 Cycle Phase “Usage/Operational”. 1750 5.2.24 OE.Env_Admin (Administrator works in trusted environ- ment) The administrative functions of “Administrator” users are performed within a trusted envi- ronment. 1755 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. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 47 Chapter 5. Security Objectives 5.2.25 OE.Env_Mass_Signature (Mass signatures are generated in- 1760 trusted environment only) Mass signature generation only takes place within a trusted environment. Note 1. “OE.Env_Mass_Signature” is added to the contents of the claimed protection profiles. 1765 5.3 Security Objective Rationale 5.3.1 Security Objectives Backtracking Fig. 5.1 shows that ˆ all threats and OSPs are addressed by the security objectives and ˆ that all assumptions are addressed by the security objectives for the TOE environment. 1770 Fig. 5.1: Security Objective Rationale overview Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 48 Chapter 5. Security Objectives 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 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 1775 ˆ 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 known data produced by the TOE, which are the SVD and the signatures created with the SCD. 1780 ˆ OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) counters this threat by implementing cryptographically secure generation of the SCD/SVD pair. ˆ OT.Sig_Secure (Cryptographic security of the electronic signature) ensures crypto- graphically secure electronic signatures. SSCD T.Hack_Phys (Physical attacks through the TOE interfaces) deals with physical attacks 1785 exploiting physical vulnerabilities of the TOE. ˆ OT.SCD_Secrecy (Secrecy of the signature creation data) preserves the secrecy of the SCD. ˆ OT.EMSEC_Design (Provide physical emanations security) counters physical attacks through the TOE interfaces and observation of TOE emanations. 1790 ˆ OT.Tamper_ID (Tamper detection) and ˆ OT.Tamper_Resistance (Tamper resistance) counter the threat T.Hack_Phys by detect- ing and by resisting tampering attacks. 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 1795 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 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 1800 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. Additionally T.SVD_Forgery is addressed by ˆ OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export), which ensures that the 1805 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 verifica- tion of SVD authenticity by the CGA. SSCD T.SigF_Misuse (Misuse of the signature creation function of the TOE) addresses the threat 1810 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). 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 49 Chapter 5. Security Objectives ˆ OT.Lifecycle_Security (Lifecycle security) requires the TOE to detect flaws during the initialization, personalization and operational usage including secure destruction of the 1815 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 the DTBS/R only for data the signatory intends to sign. 1820 ˆ 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 is in non-operational state, i.e. the SCD cannot be used before the signatory 1825 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 – OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS export) counters the 1830 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 and the integrity of the VAD as needed by the authentication method employed. The 1835 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). – OE.DTBS_Protect (SCA protects the data intended to be signed) counters manip- 1840 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. SSCD T.DTBS_Forgery (Forgery of the DTBS/R) addresses the threat arising from modifications of 1845 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 ˆ OE.DTBS_Intend (SCA sends data intended to be signed), which ensures that the 1850 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 the DTBS/R inside the TOE. 1855 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 1860 in transit between the SCA and the TOE. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 50 Chapter 5. Security Objectives 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 1865 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 1870 of 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. 1875 ˆ 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 1880 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 1885 ˆ 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 ter- 1890 minal), 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- 1895 0068-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 1900 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 1905 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 1910 (Proof of the travel document’s chip authenticity) using an authentication key pair to be Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 51 Chapter 5. Security Objectives 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 1915 (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 1920 refined 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 1925 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 1930 the authenticity of the travel document’s chip. 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 1935 advanced signatures. The ˆ OE.CGA_QCert (Generation of qualified certificates) addresses the requirement of qualified (or advanced) electronic signatures as being based on qualified (or non- qualified) certificates. According to 1940 ˆ 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 1945 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 1950 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. 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 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 52 Chapter 5. Security Objectives ˆ OT.Sigy_SigF (Signature creation function for the legitimate signatory only) ensures 1955 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 1960 SCD through robust encryption techniques. ˆ OE.CGA_QCert (Generation of qualified certificates) addresses the requirement of qualified 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 1965 only those DTBS to the TOE, which the signatory intends to sign. 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. 1970 ˆ The OT.SCD_Secrecy (Secrecy of the signature creation data), OT.Sig_Secure (Crypto- 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- 1975 graphic security of the electronic signature) meet the requirement in paragraph 1(b) of 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. ˆ OT.Sigy_SigF (Signature creation function for the legitimate signatory only) meets 1980 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 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. 1985 The usage of SCD under sole control of the signatory is ensured by ˆ OT.Lifecycle_Security (Lifecycle security), ˆ 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 1990 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. 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 1995 Device holder and legitimate user of the TOE. The CSP will use the TOE security feature (addressed by the security objectives ˆ 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 2000 as required by ˆ OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 53 Chapter 5. Security Objectives 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 2005 in an appropriate way by the CSP for the SCD/SVD pair generated outside the secure preparation environment. P.Sig_Non-Repud (Non-repudiation of signatures) deals with the repudiation of signed data by the signatory, although the electronic signature is successfully verified with the SVD contained in their certificate valid at the time of signature creation. This policy is 2010 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 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. 2015 ˆ 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. ˆ 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 2020 the signatory. ˆ OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) ensures that the SVD 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 signa- tory’s SCD can practically occur just once. 2025 ˆ 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-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 2030 ˆ OT.TOE_SSCD_Auth and ˆ OT.TOE_TC_SVD_Exp supported by ˆ OE.Dev_Prov_Service enables the verification whether the device presented by the applicant is a SSCD as required by OE.CGA_SSCD_Auth (Pre-initialization of the TOE for SSCD authentication) 2035 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). ˆ 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 2040 their VAD confidential. The robust cryptographic techniques required by OT.Sig_Secure (Cryptographic security of 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), 2045 ˆ OT.SCD_Secrecy (Secrecy of the signature creation data), ˆ OT.EMSEC_Design (Provide physical emanations security), ˆ OT.Tamper_ID (Tamper detection) and Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 54 Chapter 5. Security Objectives ˆ OT.Tamper_Resistance (Tamper resistance) protect the SCD against any compromise. The confidentiality of VAD is protected during the transmission between the HI device 2050 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). – OE.DTBS_Intend (SCA sends data intended to be signed), – OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE), 2055 – 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 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), 2060 – 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 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 2065 OT.Identification (Identification of the TOE) since the objective mandates that the TOE implements identification mechanisms that support the identification of the TOE during manufacturing. PACE P.Pre-Operational (Pre-operational handling of the travel document) is enforced by the security objectives: 2070 ˆ OT.Identification (Identification of the TOE) ˆ OT.AC_Pers (Access Control for Personalisation of logical MRTD) ˆ 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]. 2075 PACE P.Card_PKI (PKI for Passive Authentication (issuing branch)), P.Trustworthy_PKI (Trust- worthiness of PKI), and are each directly enforced by a single security objective, namely OE.Passive_Auth_Sign (Authentication of travel document by Signature), OE.Passive_Auth_ Sign (Authentication of travel document by Signature), and in direct correspondence to the protection profile [BSI-CC-PP-0068-V2-2011-MA-01]. 2080 PACE The P.Terminal (Abilities and trustworthiness of terminals) is countered by the security objec- tive OE.Exam_Travel_Document (Examination of the physical part of the travel document) 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. 2085 EAC The OSP P.Personalisation (Personalisation of the travel document by issuing State or Organisation only) addresses the (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 2090 (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). 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 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 55 Chapter 5. Security Objectives Control for Personalisation of logical MRTD) limits the management of TSF data and the 2095 management of TSF to the Personalization Agent. EAC The P.Sensitive_Data (Privacy of sensitive biometric reference data) is fulfilled and the threat 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 2100 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 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 2105 biometric reference data as demanded by OE.Ext_Insp_Systems (Authorization of Extended Inspection Systems). 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 2110 ˆ 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 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 2115 authenticity of the signatory’s name and the SVD in the qualified certificate by the advanced signature of the CSP by means of the CGA. This is addressed by ˆ OE.CGA_QCert (Generation of qualified certificates), which ensures the generation of qualified certificates, and by ˆ OE.SVD_Auth (Authenticity of the SVD), which ensures the protection of the integrity 2120 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. 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 Administrator is successfully authenticated. This is addressed by OE.Env_Admin 2125 (Administrator works in trusted environment) which ensures that the TOE initialization, TOE personalization is only started by the Administrator within a trusted environment and eSign update (generation of 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. 2130 Notes 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. 2135 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 suc- cessfully 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 only in a trusted environment. 2140 Note Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 56 Chapter 5. Security Objectives 1. “A.Env_Mass_Signature ” and “OE.Env_Mass_Signature ” are added to the contents of [BSI-CC-PP-0059-2009-MA-02]. The examination of the travel document addressed by the assumption A.Insp_Sys (Inspec- 2145 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 Inspection Systems to implement and to perform PACE Chip Authentication Mapping or the 2150 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 handling. “Travel document Authentication Key”.20 2155 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 necessary procedures for the Country Signing CA Key Pair and the Document Signer Key Pairs. The implementation of the signature verification procedures is covered by OE.Exam_ 2160 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 objec- tive 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 Document Verifier certificates for authorized receiving States or Organizations 2165 only. The Document Verifier of the receiving State is required by OE.Ext_Insp_Systems (Authorization of Extended Inspection Systems) to authorize Extended Inspection Sys- tems by creating Inspection System Certificates. Therefore, the receiving issuing State or Organization has to establish the necessary public key infrastructure. 20 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 57 Chapter 6. Extended Components Definition 6 Extended Components Definition 2170 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 ˆ chapter 8 of [BSI-CC-PP-0059-2009-MA-02] 2175 ˆ 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. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 58 Chapter 7. Security Requirements (ASE_REQ) 7 Security Requirements (ASE_REQ) 2180 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- 2185 PP-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, 2190 ˆ assignments are indicated by bold text and by footnotes which lists the deleted text, ˆ 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 2195 a closing [END REFINEMENT]. If an operation of a security functional requirement has already been performed in the referenced 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- 2200 02], this is described by a note which also states whether the SFR is “iterated” or “not iterated” from a PP SFR. 7.1 Elliptic curves used This TOE uses the following elliptic curves: 1. for 256 bits: 2205 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) 2. for 384 bits: a. P-384 ([NIST-FIPS-186-4], chapter D.1.2.4 “Curve P-384”, aka secp384r1) 2210 b. brainpoolP384r1 ([RFC-5639-2010-03] chapter 3.6) 3. for 512 bits: brainpoolP512r1 ([RFC-5639-2010-03] chapter 3.7) 4. for 521 bits: P-521 ([NIST-FIPS-186-4], chapter D.1.2.5 “Curve P-521”, aka secp521r1) 2215 Notes 1. EC curves above are taken from [BSI-TR-03110-3-V221] Table 4: Standardized Domain Parameters. 2. This TOE uses the EC crypto library v2.08.007 of the underlying chip SLC52GDA448*. 2220 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 59 Chapter 7. Security Requirements (ASE_REQ) 3. For “ECDH” see [Infineon-ST-SLC52-H13] section “7.1.4.5.5 Elliptic Curve Diffie- Hellman (ECDH) key agreement”. 4. For the “digital signature generation” see [Infineon-ST-SLC52-H13], “8.5.4 Elliptic Curves Cryptographic Library”, section “Signature Generation and Verification”. 5. For the “cryptographic key generation algorithm” see [Infineon-ST-SLC52-H13], 2225 “7.1.4.5.4 Elliptic Curve (EC) key generation” 6. For the “digital signature verification” see [Infineon-ST-SLC52-H13], “8.5.4 Elliptic Curves Cryptographic Library”, section “ECDSA Signature Verification”. 7.2 RSA key support The TOE supports the following RSA key sizes: 2230 ˆ 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. Notes 2235 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 Cryptographic Library”, section “Encryption, Decryption, Signature Generation and Verification”. 3. For the “digital signature generation” see [Infineon-ST-SLC52-H13], “8.5.3 RSA Cryp- 2240 tographic Library”, section “Encryption, Decryption, Signature Generation and Verifica- tion”. 4. For the “cryptographic key generation algorithm” see [Infineon-ST-SLC52-H13], “7.1.4.5.2 Rivest-Shamir-Adleman (RSA) key generation” 5. For the “digital signature verification” see [Infineon-ST-SLC52-H13], “8.5.3 RSA Cryp- 2245 tographic Library”, section “Encryption, Decryption, Signature Generation and Verifica- tion”. 7.3 Hash functions implemented This TOE provides the following hash algorithms 1. SHA-1 2250 2. SHA-{256, 384, 512}. Notes 1. This TOE uses for SHA-{1, 256, 384, 512} the SHA crypto library v1.12.001 of the underlying chip SLC52GDA448*. 2255 2. For the implemented standards, see [Infineon-Chip-HCL52], “Annex D Reference list of implemented standards”. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 60 Chapter 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) 2260 Notes 1. Security attribute Terminal Authentication Status is spelled differently in PP [BSI- CC-PP-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- 2265 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. 4. A combination of Terminal Authorization attributes DG4 and DG3 is allowed and thus not not stated explicitly in Table 7.2. 2270 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 se- curity attribute is associ- ated 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 61 Chapter 7. Security Requirements (ASE_REQ) 7.5 Keys and certificates 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]. 2275 Note: 1. Where PP [BSI-CC-PP-0068-V2-2011-MA-01] is more specific than PP [BSI-CC-PP- 0056-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 Certifi- cates. 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 Certificate may be a self-signed certificate or a link certificate (cf. [BSI-TR-03110-1-V220] and Glossary). It contains (i) the Country Verify- ing Certification Authority Public Key (PK.CVCA) as authentication reference data, (ii) the coded access control rights of the Country Verifying Certification Authority, (iii) the Certificate Effec- tive Date and the Certificate Expiration Date as security attributes. C.DV The Document Verifier Certificate C.DV is issued by the Country Verifying Certification Authority. 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 is- sued by the Document Verifier. It contains (i) as authentication reference data the Inspection System Public Key (PK.IS), (ii) the coded ac- cess control 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 62 Chapter 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 Authen- tication 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 au- thentic 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) are used for Active Authentication Pro- tocol according to [ICAO-9303-2015] part 11 chapter “6.1 Active Authentication)” using EC or RSA. 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 au- thentic 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 Authority 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 Certificates The Document Signer Certificate C.DS is is- sued by the Country Signing Certification Au- thority. 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 Au- thentication with the Document Signer Public Key (PK.DS). PACE Chip Authenti- cation Mapping Pub- lic Key Pair The PACE Chip Authentication Mapping Public 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 63 Chapter 7. Security Requirements (ASE_REQ) Table 7.4 – continued from previous page Name Data PACE Chip Authenti- cation Mapping Pub- lic 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 Authen- tication 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 au- thentication (CMAC-mode) and for message en- cryption (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 agree- ment algorithm) according to [BSI-TR-03111- V210-ECC] / [ICAO-TR-110] or DH according to [RSA-PKCS-3-V1.4]. 2280 Notes 1. The Country Verifying Certification Authority identifies a Document Verifier as “domes- tic” in the Document Verifier Certificate if it belongs to the same State as the Country Verifying Certification Authority. The Country Verifying Certification Authority identifies a Document Verifier as “foreign” in the Document Verifier Certificate if it does not 2285 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. 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 2290 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 table in the protection profile [BSI-CC-PP-0056-V2-2012-MA-02]. All other parts of the ST reference different implementation standards. 2295 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 64 Chapter 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 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 2300 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 Authentication session keys EAC Hierarchical to No other components. 2305 Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/CA_EC The TSF shall generate cryptographic keys in accordance 2310 with a specified cryptographic key generation algorithm ECDH2 and specified cryptographic 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] using curves 2315 (2) see section Elliptic curves used.4 Notes 1. FCS_CKM.1/CA_EC implicitly contains the requirements for the hashing functions used for key derivation by demanding compliance to [BSI-TR-03110-1-V220], section 3.1. 2320 2. The TOE generates a shared secret value with the terminal during the Chip Authentica- tion 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 details). The shared secret value is used to derive the Chip 2325 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 2330 primitive to derive 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 2335 (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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 65 Chapter 7. Security Requirements (ASE_REQ) (iii) The TOE destroys the PACE Session Keys after generation of a 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 com- 2340 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_ EC. 5. See also FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the key sizes used. 2345 6. See also section Hash functions implemented. 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 Au- 2350 thentication session keys EAC Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] 2355 FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/CA_RSA The TSF shall generate cryptographic keys in accor- dance with a specified cryptographic key generation algorithm DH5 and specified cryptographic key sizes 128, 192, 256 bits (for AES)6 that meet the following: 2360 (1) based on the Diffie-Hellman key derivation protocol compliant to [RSA-PKCS-3-V1.4] and [BSI-TR-03110-1-V220].7 Notes 1. FCS_CKM.1/CA_RSA is iterated from FCS_CKM.1/CA_EC. 2365 2. For computing the shared secret the modular exponentation function provided by the RSA crypto library of SLC52GDA448* is used. 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. 2370 4. The TOE generates a shared secret value with the terminal during the Chip Authentica- tion 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 compli- ant 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 2375 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 [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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 66 Chapter 7. Security Requirements (ASE_REQ) 5. 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 the keys for secure messaging from any shared secrets of the 2380 Authentication Mechanisms according to [BSI-TR-03110-3-V221] chapter “A.2.3.2. AES”. 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 2385 (ii) after successful run of the Chip Authentication Protocol v.1. (iii) The TOE destroys the PACE Session Keys after generation of a 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 com- 2390 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_ RSA. 7. See also FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the key sizes used. 2395 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- 2400 Hellman for PACE session keys PACE Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] 2405 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 ac- cordance with a specified cryptographic key generation algorithm ECDH 2410 compliant 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 2415 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 67 Chapter 7. Security Requirements (ASE_REQ) 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 2420 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). 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]. 2425 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 com- munication with the terminal in a new after-reset-session as required by FDP_ 2430 RIP.1. 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- 2435 Hellman for PACE session keys PACE Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] 2440 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_RSA The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm Diffie- 2445 Hellman-Protocol compliant to [RSA-PKCS-3-V1.4]11 and specified cryp- tographic 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) using bit lengths (2) 2048-bit MODP Group (p component) with 224-bit Prime Order 2450 Subgroup (q component) or (3) 2048-bit MODP Group (p component) with 256-bit Prime Order Subgroup (q component)13 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 68 Chapter 7. Security Requirements (ASE_REQ) Notes 2455 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. 4. The TOE generates a shared secret value K with the terminal during the PACE protocol, 2460 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 func- 2465 tions 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 com- 2470 munication 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. 2475 7.6.1.5 FCS_CKM.1/EC (Cryptographic key generation – EC) SSCD Hierarchical to No other components. Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] 2480 FCS_CKM.4 Cryptographic key destruction 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: 2485 ECDSA Key Generation: (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] 2490 using curves (4) see section Elliptic curves used.17 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 69 Chapter 7. Security Requirements (ASE_REQ) Notes 1. FCS_CKM.1/EC amounts to requirement “FCS_CKM.1” with the selection of ECC key 2495 generation. 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*. 3. For the cryptographic key generation algorithm “Elliptic Curve EC Key Generation” see 2500 [Infineon-ST-SLC52-H13], 7.1.4.5.4 Elliptic Curve (EC) key generation. 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 2505 [FCS_CKM.2 Cryptographic key distribution or 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 genera- 2510 tion19 and specified cryptographic key sizes 2048, 3072, and 4096 bits20 that meet the 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 , 2515 ˆ private key representation 3.2(1) supported for n < 22048 + 64 , ˆ 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 < 2520 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 2525 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 2530 the underlying chip SLC52GDA448*. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 70 Chapter 7. Security Requirements (ASE_REQ) 3. For the cryptographic key generation algorithm “RSA Key Generation” see [Infineon- ST-SLC52-H13] 7.1.4.5 Rivest-Shamir-Adleman (RSA) key generation. 4. The standard PKCS #1 version 2.2 [RSA-PKCS1-v2.2] supersedes the standard PKCS #1 version 2.1, which is referenced in the [Infineon-ST-SLC52-H13]. However, version 2535 2.2 only includes compatible techniques; both versions are equivalent in this context. 5. If a configuration of the TOE uses FCS_CKM.1/EC, it must not use this SFR additionally. 7.6.1.7 FCS_CKM.4 Cryptographic key destruction Hierarchical to No other components. Dependencies 2540 [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method overwriting with zeros22 2545 that meets the following: none23 . Notes 1. The TOE shall destroy the PACE / CA session keys after detection of an error in a received command by verification of the MAC. The TOE shall clear the memory area 2550 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. The signatory may want to destruct the SCD stored in the SSCD e.g. after the qualified certificate for the corresponding SVD is not valid anymore. 2555 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 [FDP_ITC.1 Import of user data without security attributes, or 2560 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 accor- dance with a specified cryptographic algorithm Elliptic Curve Digital Sig- 2565 nature Algorithm (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]. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 71 Chapter 7. Security Requirements (ASE_REQ) ˆ Step d) and e) not supported. 2570 ˆ The output of step e) has to be provided as input to our func- tion 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 an- 2575 other call to our 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 2580 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]: ˆ Deviation of step (3) and (4): 2585 – The jump to step 1, were substituted by a return of the func- tion with an error code, the jumps are emulated by another call to our function. using curves 4. see section Elliptic curves used.27 2590 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, Base v2.08.007, SHA-2 v1.12.001 and Symmetric Crypto Library (SCL) v2.04.002 of 2595 the underlying chip SLC52GDA448*. 3. For the Elliptic Curve Digital Signature Algorithm (ECDSA) see [Infineon-ST-SLC52- H13], “7.1.4.6.4 Elliptic Curve DSA (ECDSA) operation”, section “Signature Generation and Verification”. 4. If a configuration of the TOE uses FCS_COP.1/RSA, it must not use this SFR additionally. 2600 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 FDP_ITC.2 Import of user data with security attributes, or 2605 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 accor- dance with a specified cryptographic algorithm Rivest-Shamir-Adleman 27 [assignment: list of standards] 28 [assignment: list of cryptographic operations] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 72 Chapter 7. Security Requirements (ASE_REQ) (RSA)29 and cryptographic key sizes 2048, 3072, and 4096 bits30 that 2610 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., without any (ri, di, ti), i > 2: ˆ 5.2.1(1) not supported, 2615 ˆ 5.2.1(2.a) supported for n < 22048 + 64 , ˆ 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 , 2620 ˆ 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). 2625 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.4.6.1 Rivest-Shamir-Adleman (RSA) operation”. 2630 4. The standard PKCS #1 version 2.2 [RSA-PKCS1-v2.2] supersedes the standard PKCS #1 version 2.1, which is referenced in the [Infineon-ST-SLC52-H13]. However, version 2.2 only includes compatible techniques; both versions are equivalent in this context. 5. The padding is done according to RSASSA-PSS and RSASSA-PKCS1-v1_5. 6. If a configuration of the TOE uses FCS_COP.1/EC, it must not use this SFR additionally. 2635 7.6.1.10 FCS_COP.1/SHA (Cryptographic operation – Hash calculation) SSCD 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 2640 FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction fulfilled by Not fulfilled, but justified: A hash function does not use any cryptographic key; hence ˆ neither a respective key import nor key generation can be expected here. 2645 ˆ a respective key destruction cannot be expected here. 29 [assignment: cryptographic algorithm] 30 [assignment: cryptographic key sizes] 31 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 73 Chapter 7. Security Requirements (ASE_REQ) 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-256, SHA-384 and SHA-51233 and cryptographic key sizes none34 that meet the following: 2650 [NIST-FIPS-180-4] with chapters 6.1 “SHA-1”, 6.2 “SHA-256”, 6.4 “SHA-512” and 6.5 “SHA-384”.35 Notes 1. FCS_COP.1/SHA is added to contents of PP [BSI-CC-PP-0059-2009-MA-02] (not iter- 2655 ated). 2. This TOE uses the SHA library (HCL52 v1.12.001) of the underlying chip SLC52GDA448*. 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. 2660 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 2665 [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: 2670 The key 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 2675 code in CMAC36 in accordance with a specified cryptographic algorithm Ad- vanced 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 . 2680 Notes 1. FCS_COP.1/AES_MAC is added to contents of [BSI-CC-PP-0059-2009-MA-02] (not iterated). 2. This SFR covers the cryptographic operation used during the Symmetric Authentication Mechanism with the Administrator Personalization Key. This key is imported by the 2685 administrator during the TOE initialization and is used to secure the TOE personalization. 32 [assignment: list of cryptographic operations] 33 [assignment: cryptographic algorithm] 34 [assignment: cryptographic key sizes] 35 [assignment: list of standards] 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 74 Chapter 7. Security Requirements (ASE_REQ) 7.6.1.12 FCS_COP.1/CA_ENC (Cryptographic operation - Symmetric Encryption / Decryption) EAC Hierarchical to No other components. Dependencies 2690 [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 2695 ˆ FCS_CKM.1/DH_PACE_EC ˆ FCS_CKM.1/DH_PACE_RSA ˆ FCS_CKM.4.1 FCS_COP.1.1/CA_ENC The TSF shall perform secure messaging - encryption and decryption40 in accordance with a specified cryptographic algorithm AES 2700 in CBC mode41 and cryptographic key sizes using AES with 128, 192, 256 bits42 that meet the following: (1) (for CBC:) [NIST-800-38A-2001], chapter 6.2 THE CIPHER BLOCK CHAINING MODE. (2) (for AES:) U.S. Department of Commerce, National Institute of 2705 Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197.43 Notes 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the 2710 underlying chip SLC52GDA448*. 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.4.2.2 AES Operation. 4. This SFR requires the TOE to implement the cryptographic primitives (AES) for secure 2715 messaging with encryption of the transmitted data. The keys are agreed between the TOE and the terminal as part of the Chip Authentication Protocol Version 1 according to the FCS_CKM.1/CA_EC (and FCS_CKM.1/CA_RSA). 40 [assignment: list of cryptographic operations] 41 [assignment: cryptographic algorithm] 42 [assignment: cryptographic key sizes] 43 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 75 Chapter 7. Security Requirements (ASE_REQ) 7.6.1.13 FCS_COP.1/CA_MAC (Cryptographic operation - MAC) EAC Hierarchical to No other components. 2720 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 2725 FCS_COP.1.1/CA_MAC The TSF shall perform secure messaging - message 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 2730 method 2. (2) (for AES:) U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), [NIST-FIPS-197].47 2735 Notes 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the underlying chip SLC52GDA448*. 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.4.2.2 2740 AES Operation. 4. This SFR requires the TOE to implement the cryptographic primitive for secure mes- saging 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 authentica- 2745 tion 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 / Decryp- tion AES ) PACE Hierarchical to No other components. 2750 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 2755 fulfilled by ˆ FCS_CKM.1/DH_PACE_EC and FCS_CKM.1/DH_PACE_RSA ˆ FCS_CKM.4 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 76 Chapter 7. Security Requirements (ASE_REQ) FCS_COP.1.1/PACE_ENC The TSF shall perform secure messaging - encryption and decryption48 in accordance with a specified cryptographic algorithm AES 2760 in CBC mode49 and cryptographic key sizes 128, 192, 256 (for AES)50 bit that meet the following: compliant to [ICAO-TR-110]51 . Note 2765 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 step of PACE. The related session keys are agreed between the TOE and the terminal 2770 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. 7.6.1.15 FCS_COP.1/PACE_MAC (Cryptographic operation - MAC) PACE Hierarchical to No other components. Dependencies 2775 [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 2780 ˆ 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 (AES) CMAC53 and cryptographic key sizes 128, 192, 256 (for AES)54 bit 2785 that meet the following: compliant to [ICAO-TR-110]55 . Notes 1. This TOE uses the Symmetric Crypto Library (SCL52 v2.04.002) provided by the 2790 underlying chip SLC52GDA448*. 2. This SFR requires the TOE to implement the cryptographic primitive for secure mes- saging with message authentication code over transmitted data. The related session keys are agreed between the TOE and the terminal as part of either the PACE protocol according to the FCS_CKM.1/DH_PACE_EC (PACE-K.MAC) and FCS_CKM.1/DH_PACE_ 2795 RSA. 48 [assignment: list of cryptographic operations] 49 [assignment: cryptographic algorithm] 50 [assignment: cryptographic key sizes] 51 [assignment: list of standards] 52 [assignment: list of cryptographic operations] 53 [assignment: cryptographic algorithm] 54 [assignment: cryptographic key sizes] 55 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 77 Chapter 7. Security Requirements (ASE_REQ) 7.6.1.16 FCS_COP.1/SIG_VER_EC (Cryptographic operation - Signature verifica- tion by travel document 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/SIG_VER_EC The TSF shall perform digital signature 2805 verification56 in accordance with a specified cryptographic algorithm ECDSA57 and cryptographic 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 2810 as input to our function by the caller. Deviation of step d): Be- side noted calculation, our algorithm adds a random multiple of BasepointerOrder n to the calculated values u1 and u2. (2) According to sections 6.4.4 in [ISO-IEC-14888-3]. Not supported are sections 6.4.4.2 and 6.4.4.3: The hash-code H of the message 2815 has to be provided by the caller as input to the function. (3) According to section 7.2.8 ECVP-DSA in [IEEE-1363]. using curves (4) see section Elliptic curves used.59 2820 Notes 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 2825 SLC52GDA448*. 3. The signature verification is used to verify the card verifiable certificates and the authentication 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 2830 with ECDSA). 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. 56 [assignment: list of cryptographic operations] 57 [assignment: cryptographic algorithm] 58 [assignment: cryptographic key sizes] 59 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 78 Chapter 7. Security Requirements (ASE_REQ) 7.6.1.17 FCS_COP.1/SIG_VER_RSA (Cryptographic operation - Signature verifi- 2835 cation by travel document with RSA) 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 2840 FCS_CKM.1 Cryptographic key generation] 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- 2845 V221] section A.7.3.2.Public Key Format) that meet the following: (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 2850 Notes 1. SFR FCS_COP.1/SIG_VER_RSA is iterated from PP SFR FCS_COP.1/SIG_VER_EC (“FCS_ COP.1/SIG_VER”). 2. This TOE uses the RSA (Signature Verification) provided by the underlying chip SLC52GDA448*. 2855 3. For the “digital signature verification” see [Infineon-ST-SLC52-H13], 7.1.4.6.1 Rivest- Shamir-Adleman (RSA) operation, section “Signature Verification:”. 4. The signature verification is used to verify the card verifiable certificates and the authentication attempt of the terminal creating a digital signature for the TOE challenge 5. See also section Hash functions implemented. 2860 6. The bit lengths for TA are taken over from [BSI-TR-03110-3-V221] section A.7.3.2. Public Key Format. 7. The TOE implements RSA (and ECDSA cf. FCS_COP.1/SIG_VER_EC) for the Termi- nal Authentication Protocol v.1 (cf. [BSI-TR-03110-3-V221] section A.6.3.Terminal Authentication with RSA). 2865 8. If a configuration of the TOE uses FCS_COP.1/SIG_VER_EC, it must not use this SFR additionally. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 79 Chapter 7. Security Requirements (ASE_REQ) 7.6.1.18 FCS_COP.1/AA_SGEN_EC (Cryptographic operation - Signature genera- tion for AA with EC) EAC Hierarchical to No other components. 2870 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 2875 FCS_COP.1.1/AA_SGEN_EC The TSF shall perform digital signature gener- ation64 in accordance with a specified cryptographic algorithm ECDSA65 and cryptographic key sizes 256, 384, 512, and 521 bits66 that meet the following: Signature Generation: 2880 1. According to section 7.3 in [ANSI-X9.62]. ˆ Step d) and e) not supported. ˆ The output of step e) has to be provided as input to our func- tion by the caller. ˆ Deviation of step c) and f): 2885 – The jumps to step a) were substituted by a return of the function with an error code, the jumps are emulated by an- other call to our function. 2. According to section 6.4.3 in [ISO-IEC-14888-3]. ˆ 6.4.3.3 not supported. 2890 ˆ 6.4.3.5 not supported: – 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. 2895 3. According to section 7.2.7 in [IEEE-1363]: ˆ Deviation of step (3) and (4): – The jump to step 1, were substituted by a return of the func- tion with an error code, the jumps are emulated by another call to our function. 2900 using curves 4. see section Elliptic curves used.67 Notes 1. SFR FCS_COP.1/AA_SGEN_EC is added to contents of PPs [BSI-CC-PP-0056-V2-2012- 2905 MA-02] and [BSI-CC-PP-0068-V2-2011-MA-01]. 2. See also section Hash functions implemented. 64 [assignment: list of cryptographic operations] 65 [assignment: cryptographic algorithm] 66 [assignment: cryptographic key sizes] 67 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 80 Chapter 7. Security Requirements (ASE_REQ) 3. The signature generation is used to perform Active Authentication. 4. The TOE implements ECDSA and RSA (cf. FCS_COP.1/AA_SGEN_RSA) for the Active Authentication Protocol (cf. [BSI-TR-03110-3-V221] section 1.2 Active Authentication). 2910 5. If a configuration of the TOE uses FCS_COP.1/AA_SGEN_RSA, it must not use this SFR additionally. 7.6.1.19 FCS_COP.1/AA_SGEN_RSA (Cryptographic operation - Signature gener- ation for AA with RSA) EAC Hierarchical to No other components. 2915 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 2920 FCS_COP.1.1/AA_SGEN_RSA The TSF shall perform digital signature gen- eration68 in accordance with a specified cryptographic algorithm RSA69 and cryptographic key sizes 2048, 3072, and 4096 bits70 that meet the following: (1) Signature Generation (with or without CRT): According to section 2925 5.2.1 RSASP1 in [RSA-PKCS1-v2.2] for u = 2, i.e., without any (r_ i, d_i, t_i), i >2, therefore without 5.2.1.2.b (ii)&(v), without 5.2.1.1. 5.2.1.2.a. (2) Padding according ISO/IEC 9796-2 Digital Signature scheme 1 according to [ICAO-9303-2015] part 11, section “6.1 Active Au- 2930 thentication”.71 Notes 1. SFR FCS_COP.1/AA_SGEN_RSA is iterated from SFR FCS_COP.1/AA_SGEN_EC. 2. This TOE uses the RSA (Signature Generation) provided by the underlying chip 2935 SLC52GDA448*. 3. For the “digital signature generation” see [Infineon-ST-SLC52-H13], 7.1.4.6.1 Rivest- Shamir-Adleman (RSA) operation, section “Signature Generation (with or without CRT):”. 4. See also section Hash functions implemented. 2940 5. The signature generation is used to perform Active Authentication. 6. The TOE implements RSA and ECDSA (cf. FCS_COP.1/AA_SGEN_EC) for the Active Authentication Protocol (cf. [BSI-TR-03110-3-V221] section 1.2 Active Authentication). 7. If a configuration of the TOE uses FCS_COP.1/AA_SGEN_EC, it must not use this SFR additionally. 2945 68 [assignment: list of cryptographic operations] 69 [assignment: cryptographic algorithm] 70 [assignment: cryptographic key sizes] 71 [assignment: list of standards] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 81 Chapter 7. Security Requirements (ASE_REQ) 7.6.1.20 FCS_RNG.1 (Random number generation) Hierarchical to No other components. Dependencies No dependencies. FCS_RNG.1.1 The TSF shall provide a hybrid deterministic72 random number generator that implements: 2950 (DRG.4.1) The internal state of the RNG shall use PTRNG of class PTG.2 as random source. (DRG.4.2) The RNG provides forward secrecy. (DRG.4.3) The RNG provides backward secrecy even if the current internal state is known. 2955 (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 according to [BSI-AIS31-V3].73 FCS_RNG.1.2 The TSF shall provide random numbers that meet: 2960 (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 numbers from output sequences of an ideal RNG. The ran- 2965 dom numbers must pass test procedure A as defined in [BSI-AIS2031- RNG-CLASSES-V2].74 Notes 1. This SFR has been adapted from [BSI-CC-PP-0084-2014] (FCS_RNG.1) to meet [BSI- 2970 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.1.1.1 True Random Number Generation”. 3. Entropy source uses PTG.2 of the hardware as noise source and Block_Cipher_df as 2975 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 2980 Terminal Authentication Protocol v.1 as required by FIA_UAU.4/PACE (3). 72 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] 73 [assignment: list of security capabilities] 74 [assignment: a defined quality metric] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 82 Chapter 7. Security Requirements (ASE_REQ) 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 protocol77 FIA_UAU.1/PACE FIA_UAU.5/PACE FIA_ UAU.6/PACE78 FIA_AFL.1/PACE Passive Authentication FIA_UAU.5/PACE 2985 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 2990 code 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 2995 PACE protocol are sustained. A subsequent Terminal Authentication Protocol v.1 uses the PACE-CAM public key verified during the PACE protocol. 7.6.2.1 FIA_UID.1/PACE (Timing of identification) PACE EAC Hierarchical to No other components. Dependencies No dependencies. 3000 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 3005 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]79 6. to carry out the Active Authentication Protocol according to [ICAO- 3010 TR-110] 7. to carry out the PACE Chip Authentication Mapping protocol ac- cording to [ICAO-TR-110] 77 Only listed for information purposes 78 not listed in PP [BSI-CC-PP-0056-V2-2012-MA-02] 79 [assignment: list of TSF-mediated actions] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 83 Chapter 7. Security Requirements (ASE_REQ) 8. to run self tests according to FPT_TST.180 on behalf of the user to be performed before the user is identified. 3015 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- 3020 PP-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 3025 role 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 3030 user after power 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 3035 Personalisation Agent (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). 3040 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 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 3045 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. 3050 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. 80 [assignment: list of TSF-mediated actions] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 84 Chapter 7. Security Requirements (ASE_REQ) 7.6.2.2 FIA_UID.1 (Timing of identification) SSCD Hierarchical to No other components. 3055 Dependencies No dependencies. FIA_UID.1.1 The TSF shall allow: 1. self-test according to FPT_TST.1;81 2. carrying out the PACE protocol according to [ICAO-TR-110] 3. performing of the Symmetric Authentication Mechanism82 3060 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 3065 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 3070 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. 3075 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]83 , 3. to read the Initialization Data if it is not disabled by TSF according to 3080 FMT_MTD.1/INI_DIS, 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 3085 [BSI-TR-03110-1-V220]84 7. to carry out the Active Authentication Protocol according to [ICAO- TR-110] 8. to carry out the PACE Chip Authentication Mapping protocol ac- cording to [ICAO-TR-110] 3090 81 [assignment: list of TSF mediated actions] 82 [assignment: list of additional TSF mediated actions] 83 travel document identifies itself within the PACE protocol by selection of the authentication key ephem- PK.PICC-PACE 84 [assignment: list of TSF-mediated actions] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 85 Chapter 7. Security Requirements (ASE_REQ) 9. to run self tests according to FPT_TST.185 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 authen- ticated before allowing any other TSF-mediated actions on behalf of that user. 3095 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. 3100 2. The user authenticated 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 authorized other person or device (BIS-PACE). If PACE was successfully performed, secure messag- ing is started using the derived session keys (PACE-K.MAC, PACE-K.Enc), cf. FTP_ 3105 ITC.1/PACE. 3. See FIA_AFL.1/PACE how skimming is prevented by the TOE. 7.6.2.4 FIA_UAU.1 (Timing of authentication) SSCD Hierarchical to No other components. Dependencies FIA_UID.1 Timing of identification. 3110 FIA_UAU.1.1 The TSF shall allow: 1. self-test according to FPT_TST.1; 2. identification of the user by means of TSF required by FIA_ UID.1;86 3. establishing a trusted channel between the CGA and the TOE by 3115 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 5. carrying out the PACE protocol according to [ICAO-TR-110] 6. performing of the Symmetric Authentication Mechanism87 3120 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. Notes 3125 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 provides a communication channel to the CGA (via trusted channel) only in the Life Cycle Phase “Usage/Operational”. 3130 85 [assignment: list of TSF-mediated actions] 86 [assignment: list of TSF mediated actions] 87 [assignment: list of additional TSF mediated actions] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 86 Chapter 7. Security Requirements (ASE_REQ) 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 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 3135 (CGA or SSCD Issuing Application) on its behalf is authenticated. 7.6.2.5 FIA_UAU.4/PACE (Single-use authentication mechanisms - Single-use au- thentication of the Terminal by the TOE) PACE EAC Hierarchical to No other components. Dependencies No dependencies 3140 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 AES88 3. Terminal Authentication Protocol v.1 according to [BSI-TR-03110-1- 3145 V220].89 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 3150 does not conflict 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 3155 by the 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 authentication data related to PACE Chip Authentication Mapping. 7.6.2.6 FIA_UAU.5/PACE (Multiple authentication mechanisms) 3160 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 3165 5.1 3. Secure messaging in MAC-ENC mode according to [ICAO-TR-110] 4. Symmetric Authentication Mechanism based on AES90 88 [selection: Triple- DES, AES or other approved algorithms] 89 [assignment: identified authentication mechanism(s)] 90 [selection: Triple-DES, AES or other approved algorithms] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 87 Chapter 7. Security Requirements (ASE_REQ) 5. Terminal Authentication Protocol v.1 according to [BSI-TR-03110-1- V220]91 3170 6. Active Authentication according to [ICAO-9303-2015], part 11 sec- tion 6.192 to support user authentication. FIA_UAU.5.2/PACE The TSF shall authenticate any user’s claimed identity according to the following rules: 3175 1. Having successfully run the PACE protocol the TOE accepts only received commands with correct message authentication code sent by means of secure messaging with the key agreed with the terminal by means of the PACE protocol. 2. The TOE accepts the authentication attempt as Personalization Agent 3180 by the Authentication Mechanism with Personalization Agent Key(s)93 . 3. After run of the Chip Authentication Protocol Version 1 the TOE accepts only received commands with correct message authentication code sent by means of secure messaging with key agreed with the terminal by 3185 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 messaging established by the Chip Authentication Mechanism v.1.94 3190 5. If PACE Chip Authentication Mapping has been performed instead of Chip Authentication Protocol Version 1 the TOE accepts the au- thentication attempt by means of the Terminal Authentication Protocol v.1 only if the terminal uses the public key presented during the PACE Chip Authentication Mapping and the secure 3195 messaging established by the PACE Protocol.95 Notes 1. The SFR FIA_UAU.5.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 aspects 4), 5), and 6). The SFR FIA_ 3200 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. 2. The Active Authentication has been added to the authentication mechanisms to cover it additionally in the evaluation. Adding new mechanisms does not impact the security 3205 claims of the Protection Profile. 91 [assignment: list of multiple authentication mechanisms] 92 REFINEMENT 93 [selection: the Authentication Mechanism with Personalization Agent Key(s)] 94 [assignment: rules describing how the multiple authentication mechanisms provide authentication] 95 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 88 Chapter 7. Security Requirements (ASE_REQ) 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. 3210 FIA_UAU.6.1/EAC The TSF shall re-authenticate the user under the condi- tions 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.96 3215 Note 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 3220 corresponding MAC algorithm whether it was sent by the successfully authenticated terminal (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. 3225 7.6.2.8 FIA_UAU.6/PACE (Re-authenticating of Terminal by the TOE) 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 3230 be verified as being sent by the PACE terminal.97 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 3235 commands exchanged after successful PACE authentication. The TOE checks each command 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 authentication code. Therefore, the TOE re-authenticates the terminal 3240 connected, if a secure messaging error occurred, and accepts only those commands received from the initially authenticated terminal. 3. The SFR FIA_UAU.6/PACE also includes PACE Chip Authentication Mapping. 96 [assignment: list of conditions under which re-authentication is required] 97 [assignment: list of conditions under which re-authentication is required] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 89 Chapter 7. Security Requirements (ASE_REQ) 7.6.2.9 FIA_UAU.6/CA (Re-authenticating – Re-authenticating of Terminal by the TOE) 3245 CGA SCA Hierarchical to No other components. Dependencies No dependencies. FIA_UAU.6.1/CA The TSF shall re-authenticate the user under the condi- tions each command sent to the TOE after successful run of the Chip Authentication Protocol Version 1 shall be verified as being sent by the 3250 inspection system98 or the R.Admin or the IT entity (CGA or SSCD Is- suing Application) on its behalf.99 Notes 1. This SFR has been adapted from the SFR FIA_UAU.6/EAC of [BSI-CC-PP-0056-V2- 3255 2012-MA-02]. 2. The Password Authenticated Connection Establishment and the Chip Authentication 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 3260 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). 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. 3265 7.6.2.10 FIA_UAU.6/Signature_Creation (Re-authenticating for Signature Cre- ation) Hierarchical to No other components. Dependencies No dependencies. FIA_UAU.6.1/Signature_Creation The TSF shall re-authenticate the user un- 3270 der 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 or after Application QES was left or otherwise before (N+1)- th DTBS/R signature in a row when limit for consecutive signa- 3275 tures is N. 3. Unlimited Mass signature S.Sigy before next signature after card reset or after Application QES was left100 . Note 3280 1. This SFR has been added to contents of PP [BSI-CC-PP-0059-2009-MA-02] (not iterated). 98 [assignment: list of conditions under which re-authentication is required] 99 REFINEMENT, see associated note 2 100 [assignment: list of conditions under which re-authentication is required] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 90 Chapter 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. 3285 FIA_API.1.1/CA The TSF shall provide a Chip Authentication Protocol Version 1 according to [BSI-TR-03110-1-V220]101 to prove the identity of the TOE102 . Note 1. Due to the fact that there is a SFR added to this ST using AA for Authentication Proof 3290 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 3295 messaging in 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 Authentica- 3300 tion) 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.1103 to prove the 3305 identity of the TOE104 . Note 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 3310 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 the signature. 101 [assignment: authentication mechanism] 102 [assignment: authorized user or role] 103 [assignment: authentication mechanism] 104 [assignment: authorized user or role] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 91 Chapter 7. Security Requirements (ASE_REQ) 7.6.2.13 FIA_AFL.1/PACE (Authentication failure handling - PACE authentication using non-blocking authorization data) 3315 PACE Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE FIA_AFL.1.1/PACE The TSF shall detect when 1105 unsuccessful authentication attempt occurs related to authentication attempts using the PACE password as shared password.106 3320 FIA_AFL.1.2/PACE When the defined number of unsuccessful authentication attempts has been met107 , the TSF shall delay the next authentication attempt at least 6 seconds.108 Notes 3325 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 consists of digits only). The delay applies also when a new session is restarted. The MRZ is longer than 6 signs and consists of alpha numerical characters. 3330 7.6.2.14 FIA_AFL.1/RAD (Authentication failure handling – for Signatory PIN) SSCD Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1/RAD The TSF shall detect when an administrator configurable positive integer within 3 up to floor(MINLEN/2) (see note 3. be- 3335 low)109 unsuccessful authentication attempts occur related to consecutive failed authentication attempts110 . FIA_AFL.1.2/RAD When the defined number of unsuccessful authentication attempts has been met111 , the TSF shall block RAD112 [REFINEMENT] of the signatory PIN (PIN.QES). 3340 Notes 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 ) 3345 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 its signatory”, see PP [BSI-CC-PP-0059-2009-MA-02], this requirement concerns the PIN of the Signatory (PIN.QES) only. 105 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 106 [assignment: list of authentication events] 107 [selection: met ,surpassed] 108 [assignment: list of actions] 109 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 110 [assignment: list of authentication events] 111 [selection: met ,surpassed] 112 [assignment: list of actions] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 92 Chapter 7. Security Requirements (ASE_REQ) 7.6.2.15 FIA_AFL.1/Suspend_PIN (Authentication failure handling – Suspending 3350 PIN) Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1/Suspend_PIN The TSF shall detect when 2113 unsuccessful au- thentication attempts occur related to consecutive failed authentica- 3355 tion attempts using the PACE password as the shared password for PACE114 . FIA_AFL.1.2/Suspend_PIN When the defined number of unsuccessful authen- tication attempts has been met115 , the TSF shall suspend the reference value of the PACE password according to [BSI-TR-03110-2-V221].116 3360 Note 1. FIA_AFL.1/Suspend_PIN has been adapted from [BSI-CC-PP-0086-2015], PIN has been changed to PACE password. 7.6.2.16 FIA_AFL.1/Block_PIN (Authentication failure handling – Blocking PIN) 3365 Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1/Block_PIN The TSF shall detect when 1117 unsuccessful authen- tication attempts occur related to consecutive failed authentication at- tempts using the suspended118 PACE password as the shared pass- 3370 word for PACE119 . FIA_AFL.1.2/Block_PIN When the defined number of unsuccessful authenti- cation attempts has been met120 , the TSF shall block the reference value of the PACE password according to [BSI-TR-03110-2-V221]121 . 3375 Note 1. FIA_AFL.1/Block_PIN has been adapted from [BSI-CC-PP-0086-2015], PIN has been changed to PACE password. 113 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 114 [assignment: list of authentication events] 115 [selection: met , surpassed] 116 [assignment: list of actions] 117 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 118 as required by FIA_AFL.1/Suspend_PIN 119 [assignment: list of authentication events] 120 [selection: met , surpassed] 121 [assignment: list of actions] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 93 Chapter 7. Security Requirements (ASE_REQ) 7.6.2.17 FIA_AFL.1/AuthAdmin (Authentication failure handling – of administra- tor for personalization) 3380 Hierarchical to No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1/AuthAdmin The TSF shall detect when 5122 unsuccessful authen- tication attempts occur related to consecutive failed authentication at- tempts123 . 3385 FIA_AFL.1.2/AuthAdmin When the defined number of unsuccessful authenti- cation attempts has been met124 , the TSF shall delay the next authenti- cation attempt at least 6 seconds125 . Notes 3390 1. FIA_AFL.1/AuthAdmin is added to contents of [BSI-CC-PP-0059-2009-MA-02] (not iterated). 2. This SFR concerns the authentication of the administrator for personalization of the TOE using the Symmetric Authentication Mechanism with Administrator Personalization Key. 3395 7.6.2.18 FIA_API.1 (Authentication proof of identity) CGA Hierarchical to No other components. Dependencies No dependencies. FIA_API.1.1 The TSF shall provide a Chip Authentication Protocol Version 1 according to [BSI-TR-03110-1-V220]126 to prove the identity of the 3400 SSCD127 . Note 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 3405 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]. 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). 3410 122 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 123 [assignment: list of authentication events] 124 [selection: met , surpassed] 125 [assignment: list of actions] 126 [assignment: authentication mechanism] 127 [assignment: authorized user or role] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 94 Chapter 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: 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 3415 Note: This ST does not define security attributes for SVD. 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 SFP128 on 3420 terminals gaining access to the User Data and data stored in EF.SOD of the129 TOE130 . Note 1. The SFR FDP_ACC.1.1/TRM in the current ST covers the definition in PACE PP [BSI-CC- 3425 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. 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. 3430 7.6.3.2 FDP_ACF.1/TRM (Security attribute based access control) PACE EAC Hierarchical to No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization 3435 FDP_ACF.1.1/TRM The TSF shall enforce the Access Control SFP131 to objects based on the following: 1. Subjects: a. Terminal, b. BIS-PACE 3440 c. Extended Inspection System 128 [assignment: access control SFP] 129 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 130 REFINEMENT, see note 2 below 131 [assignment: access control SFP] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 95 Chapter 7. Security Requirements (ASE_REQ) 2. Objects: 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, 3445 c. data in EF.DG4 of the logical travel document, d. all TOE intrinsic secret cryptographic keys stored in the travel document132 e. data in EF.CardSecurity133 3. Security attributes: 3450 a. PACE Authentication134 b. Terminal Authentication Status135 c. Terminal Authorization.136 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: 3455 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_ UAU.1/PACE.137 FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to ob- jects based on the following additional rules: none.138 3460 FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. Any terminal being not authenticated as PACE authenticated BIS-PACE is not allowed to read, to write, to modify, to use any User Data stored on the travel document. 3465 2. Terminals not using secure messaging are not allowed to read, to write, to modify, to use any data stored on the travel document. 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 3470 read the data objects 2b) of FDP_ACF.1.1/TRM. 4. Any terminal being not successfully authenticated as Extended Inspection 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. 3475 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 the EF.DG3 and EF.DG4.139 Notes 3480 132 e.g. Chip Authentication Version 1 and ephemeral keys 133 [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] 134 REFINEMENT access control to EF.CardSecurity is added to this SFR 135 REFINEMENT Terminal Authentication v.1, see also Table 7.1 and associated notes 136 REFINEMENT Authorization of the Terminal, , see also Table 7.2 and associated notes 137 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 138 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 139 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 96 Chapter 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 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 3485 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 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 3490 intersection of the Certificate Holder Authorization in the certificates of the Country Verifying Certification Authority, the Document Verifier Certificate and the Inspection 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 3495 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 transmit- ted from the TOE to the terminal by secure messaging with encryption and message authentication codes after successful Chip Authentication Version 1 to the Inspection System. The Password Authenticated Connection Establishment, and the Chip Authen- 3500 tication 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). 5. Reading according to FDP_ACF.1.2/TRM includes for a TOE providing Active Authenti- cation the AA public key in EF.DG15. 6. EF.CardSecurity holds the public key needed for authenticating the SSCD during Chip 3505 Authentication Protocol Version 1. 7.6.3.3 FDP_RIP.1 (Subset residual information protection) 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 3510 resource is made unavailable upon the de-allocation of the resource from140 the following objects: 1. Session Keys (immediately after closing related communication session), 2. the ephemeral private key ephem-SK:sub:`PICC-PACE (by having gen- erated a DH shared secret K)`141 3515 3. SCD142 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 3520 keeping the strict conformance to the claimed PPs. 2. The TOE shall destroy any session keys in accordance with FCS_CKM.4 after (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. 140 [selection: allocation of the resource to, deallocation of the resource from] 141 [assignment: list of objects] 142 [assignment: list of objects] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 97 Chapter 7. Security Requirements (ASE_REQ) (iii) The TOE shall destroy the PACE Session Keys after generation of a Chip Authenti- 3525 cation Session Keys and changing the secure messaging to the Chip Authentication Session Keys. (iv) 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. Concerning the Chip Authentication keys FCS_CKM.4 is also fulfilled by 3530 FCS_CKM.1/CA. The following data persistently stored by the TOE shall have the user data attribute “integrity checked persistent stored data”: 1. SCD; 2. SVD (if persistently stored by the TOE). 3535 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. Dependencies 3540 [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 FDP_UCT.1.1/TRM The TSF shall enforce the Access Control SFP143 to be able 3545 to transmit and receive144 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 3550 [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 3555 FDP_UIT.1.1/TRM The TSF shall enforce the Access Control SFP145 to be able to transmit and receive146 user data in a manner protected from modification, deletion, insertion and replay147 errors. FDP_UIT.1.2/TRM The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay148 has occurred. 3560 143 [assignment: access control SFP(s) and/or information flow control SFP(s)] 144 [selection: transmit, receive] 145 [assignment: access control SFP(s) and/or information flow control SFP(s)] 146 [selection: transmit, receive] 147 [selection: modification, deletion, insertion, replay] 148 [selection: modification, deletion, insertion, replay] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 98 Chapter 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_SFP149 on: 3565 1. subjects: S.User, 2. objects: SCD, SVD, 3. operations: generation of SCD/SVD pair.150 7.6.3.7 FDP_ACF.1/SCD/SVD_Generation (Security attribute based access con- trol) 3570 SSCD Hierarchical to No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ SCD/SVD_Generation The TSF shall enforce the SCD/SVD_ 3575 Generation_SFP151 to objects based on the following: the user S.User is associated with the security attribute “SCD/SVD Management”.152 FDP_ACF.1.2/ SCD/SVD_Generation The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled 3580 objects is allowed: S.User with the security attribute “SCD/SVD Management” set to “authorized” is allowed to generate SCD/SVD pair.153 After issuing the TOE S.User is allowed to generate SCD/SVD pair only after successful Chip Authentication Protocol Version 1 follow- 3585 ing PACE authentication using the PIN.ADMIN as the shared pass- word or after successful EAC with strong certificate following PACE authentication using any PACE password as the shared password.154 FDP_ACF.1.3/ SCD/SVD_Generation The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none155 3590 FDP_ACF.1.4/ SCD/SVD_Generation The TSF shall explicitly deny access of subjects to objects based on the following additional rules: S.User with the security attribute “SCD/SVD Management” set to “not authorized” is not allowed to generate SCD/SVD pair.156 3595 Notes 149 [assignment: access control SFP] 150 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 151 [assignment: access control SFP] 152 [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] 153 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 154 REFINEMENT 155 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 156 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 99 Chapter 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. After the TOE is issued the TOE is in phase OPERATIONAL. 3600 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_SFP157 on: 3605 1. subjects: S.User, 2. objects: SVD, 3. operations: export.158 7.6.3.9 FDP_ACF.1/SVD_Transfer (Subset access control) SSCD Hierarchical to No other components. 3610 Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ SVD_Transfer The TSF shall enforce the SVD_Transfer_SFP159 to objects based on the following: 3615 1. the S.User is associated with the security attribute Role; 2. the SVD.160 FDP_ACF.1.2/ SVD_Transfer The TSF shall enforce the following rules to de- termine if an operation among controlled subjects and controlled objects is allowed: 3620 R.Admin161 is allowed to export SVD.162 After issuing the TOE R.Admin is allowed to export SVD only after successful 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 3625 using any PACE password as the shared password.163 FDP_ACF.1.3/ SVD_Transfer The TSF shall explicitly authorize access of sub- jects to objects based on the following additional rules: none164 . FDP_ACF.1.4/ SVD_Transfer The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none165 . 3630 157 [assignment: access control SFP] 158 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 159 [assignment: access control SFP] 160 [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] 161 [selection: R.Admin, R.Sigy] 162 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 163 REFINEMENT 164 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 165 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 100 Chapter 7. Security Requirements (ASE_REQ) Note 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) 3635 SSCD Hierarchical to No other components. Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ Signature_Creation The TSF shall enforce the Signature_ Creation_SFP166 on: 1. subjects: S.User, 3640 2. objects: DTBS/R, SCD, 3. operations: signature creation.167 7.6.3.11 FDP_ACF.1/Signature_Creation (Security attribute based access con- trol) SSCD Hierarchical to No other components. 3645 Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ Signature_Creation The TSF shall enforce the Signature_ Creation_SFP168 to objects based on the following: 3650 1. the user S.User is associated with the security attribute “Role”; and 2. the SCD with the security attribute “SCD Operational”169 FDP_ACF.1.2/ Signature_Creation The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 3655 R.Sigy is allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “yes”.170 R.Sigy is only allowed to create electronic signatures for DTBS/R with SCD only after successful PACE authentication using the PIN.CH or CAN as the shared password and successful authentication 3660 against RAD.171 FDP_ACF.1.3/ Signature_Creation The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none.172 166 [assignment: access control SFP] 167 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 168 [assignment: access control SFP] 169 [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] 170 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 171 REFINEMENT 172 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 101 Chapter 7. Security Requirements (ASE_REQ) FDP_ACF.1.4/ Signature_Creation The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 3665 S.User is not allowed to create electronic signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “no”.173 Note 1. The changes represent the need to secure communication between the SCA and the 3670 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. Dependencies 3675 [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_UIT.1.1/DTBS The TSF shall enforce the Signature_Creation_SFP174 to 3680 receive175 user data in a manner protected from modification and insertion176 errors. FDP_UIT.1.2/DTBS The TSF shall be able to determine on receipt of user data, whether modification and insertion177 has occurred. 7.6.3.13 FDP_SDI.2/Persistent (Stored data integrity monitoring and action) 3685 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 controlled by the TSF for integrity error178 on all objects, based on the following attributes: integrity checked stored data179 . 3690 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.180 173 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 174 [assignment: access control SFP(s) and/or information flow control SFP(s)] 175 [selection: transmit, receive] 176 [selection: modification, deletion, insertion, replay] 177 [selection: modification, deletion, insertion, replay] 178 [assignment: integrity errors] 179 [assignment: user data attributes] 180 [assignment: action to be taken] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 102 Chapter 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. 3695 Dependencies No dependencies. FDP_SDI.2.1/DTBS The TSF shall monitor user data stored in containers con- trolled by the TSF for integrity error181 on all objects, based on the following attributes: integrity checked stored DTBS182 . FDP_SDI.2.2/DTBS Upon detection of a data integrity error, the TSF shall: 3700 1. prohibit the use of the altered data; 2. inform the S.Sigy about integrity error.183 Note 1. The integrity of TSF data like RAD shall be protected to ensure the effectiveness of the 3705 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 3710 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 SVD184 . 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. 3715 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”. 3720 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 3725 itself and another trusted IT product 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. FTP_ITC.1.2/PACE The TSF shall permit another trusted IT product to initiate communication via the trusted channel. 3730 181 [assignment: integrity errors] 182 [assignment: user data attributes] 183 [assignment: action to be taken] 184 [assignment: list of objects or information types] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 103 Chapter 7. Security Requirements (ASE_REQ) FTP_ITC.1.3/PACE The TSF shall initiate enforce185 communication via the trusted channel for any data exchange between the TOE and the Terminal.186 Notes 1. The trusted IT product is the terminal. In FTP_ITC.1.3/PACE, the word “initiate” 3735 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. 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 3740 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 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 3745 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 4. If Chip Authentication is successfully performed, secure messaging is immediately started using the derived session keys (CA-K.MAC, CA-K.Enc): 3750 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. 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 3755 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. Dependencies No dependencies. FTP_ITC.1.1/SVD The TSF shall provide a communication channel between 3760 itself and another trusted IT product CGA 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/SVD The TSF shall permit another trusted IT product187 to initiate communication via the trusted channel. 3765 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 FDP_DAU.2/SVD,188 2. none189 . 3770 185 The word “initiate” is changed to “enforce”, as the TOE is a passive device that can not initiate the communi- cations. 186 [assignment: list of functions for which a trusted channel is required] 187 [selection: the TSF, another trusted IT product ] 188 [assignment: list of functions for which a trusted channel is required] 189 [assignment: list of other functions for which a trusted channel is required] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 104 Chapter 7. Security Requirements (ASE_REQ) 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”. 3775 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. FTP_ITC.1.1/VAD The TSF shall provide a communication channel between itself and another trusted IT product HID that is logically distinct from other 3780 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 communication via the trusted channel. FTP_ITC.1.3/VAD The TSF or the HID shall initiate communication via the 3785 trusted channel for 1. User authentication according to FIA_UAU.1,191 2. none192 . Note 3790 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 Appli- cation) SCA Hierarchical to No other components. 3795 Dependencies No dependencies. FTP_ITC.1.1/DTBS The TSF shall provide a communication channel between itself and another trusted IT product SCA 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. 3800 FTP_ITC.1.2/DTBS The TSF shall permit :ppassigned:` the remote trusted IT product`193 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 1. signature creation,194 3805 2. none195 . 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 [selection: the TSF, another trusted IT product ] 194 [assignment: list of functions for which a trusted channel is required] 195 [assignment: list of other functions for which a trusted channel is required] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 105 Chapter 7. Security Requirements (ASE_REQ) 7.6.5 Class FMT Security Management Note 1. The SFR FMT_SMR.1/PACE provides basic requirements to the management of the TSF 3810 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. FMT_SMR.1.1/PACE The TSF shall maintain the roles 3815 1. Manufacturer, 2. Personalization Agent, 3. Terminal, 4. PACE authenticated BIS-PACE, 5. Country Verifying Certification Authority, 3820 6. Document Verifier, 7. Domestic Extended Inspection System 8. Foreign Extended Inspection System.196 FMT_SMR.1.2/PACE The TSF shall be able to associate users with roles. 3825 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. 2. The SFR FMT_LIM.1 and FMT_LIM.2 address the management of the TSF and TSF data 3830 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. FMT_SMR.1.1 The TSF shall maintain the roles R.Admin and R.Sigy197 [RE- 3835 FINEMENT] and PACE Terminal. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 196 [assignment: the authorised identified roles] 197 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 106 Chapter 7. Security Requirements (ASE_REQ) 7.6.5.3 FMT_LIM.1 (Limited capabilities) PACE EAC Hierarchical to No other components. Dependencies FMT_LIM.2 Limited availability. 3840 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, 1. User Data to be manipulated and disclosed, 3845 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 and198 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.199 3850 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 that in conjunction with “Limited capabilities (FMT_LIM.1)” the following 3855 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 3. software to be reconstructed, 3860 4. substantial information about construction of TSF to be gathered which may enable other attacks200 and 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.201 Notes: 1. The formulation of “Deploying Test Features . . . ” in FMT_LIM.2.1 might be a little bit 3865 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. 2. Note that the term “software” in item 3 of FMT_LIM.1.1 and FMT_LIM.2.1 refers to 3870 both IC Dedicated and IC Embedded Software. Note 1. The following SFR are iterations of the component Management of TSF data (FMT_ MTD.1). 3875 198 [assignment: the authorised identified roles] 199 [assignment: Limited capability and availability policy] 200 [assignment: Limited capability and availability policy] 201 [assignment: Limited capability and availability policy] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 107 Chapter 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 FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 3880 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/INI_ENA The TSF shall restrict the ability to write202 the Initialization Data and Pre-personalization Data203 to the Manufacturer204 . 7.6.5.6 FMT_MTD.1/INI_DIS (Management of TSF data - Reading and Using Ini- tialization and Pre-personalization Data) 3885 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 FMT_MTD.1.1/INI_DIS The TSF shall restrict the ability to read out205 the 3890 Initialization Data and the Pre-personalization Data206 to the Personalization Agent207 . Notes 1. The TOE restricts the ability to write the Initialization Data and the Pre-personalization 3895 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, but being not limited to a unique identification of the IC being used to trace the IC in 3900 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. 2. With “(i) allowing writing these data only once” the TOE allows to write the Initialization 3905 Data and Pre-personalization Data in more than one session but each data only once. 202 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 203 [assignment: list of TSF data] 204 [assignment: the authorised identified roles] 205 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 206 [assignment: list of TSF data] 207 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 108 Chapter 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 FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 3910 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/PA The TSF shall restrict the ability to write208 the Document Security Object (SOD)209 to the Personalization Agent210 . Note 3915 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 and Current Date) 3920 EAC Hierarchical to No other components. Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/CVCA_INI The TSF shall restrict the ability to write211 the 3925 1. initial Country Verifying Certification Authority Public Key: PK.CVCA, 2. initial Country Verifying Certification Authority Certificate: C.CVCA, 3. initial Current Date, 4. none212 to Personalization Agent213 . 3930 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. The initial Country Verifying Certification Authority Certificate and the initial Current 3935 Date is needed for verification of the certificates and the calculation of the Terminal Authorization. 208 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 209 [assignment: list of TSF data] 210 [assignment: the authorised identified roles] 211 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 212 [assignment: list of TSF data] 213 [assignment: the authorized identified roles] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 109 Chapter 7. Security Requirements (ASE_REQ) 7.6.5.9 FMT_MTD.1/CVCA_UPD (Management of TSF data - Country Verifying Cer- tification Authority) EAC Hierarchical to No other components. 3940 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 update214 the 1. Country Verifying Certification Authority Public Key: PK.CVCA, 3945 2. Country Verifying Certification Authority Certificate215 : C.CVCA to Country Verifying Certification Authority.216 Note 1. The Country Verifying Certification Authority updates its asymmetric key pair and 3950 distributes 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) 3955 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 modify217 the Current 3960 date218 to 1. Country Verifying Certification Authority, 2. Document Verifier, 3. Domestic Extended Inspection System.219 3965 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 cer- tificate provided by the terminal for the identification and the Terminal Authentication 3970 v.1 (cf. to [BSI-TR-03110-1-V220]). 214 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 215 [assignment: list of TSF data] 216 [assignment: the authorised identified roles] 217 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 218 [assignment: list of TSF data] 219 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 110 Chapter 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 3975 FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/CA_AA_PK The TSF shall restrict the ability to load220 the Chip Authentication Private Key and Active Authentication Private Key221 to Personalization Agent222 . 3980 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”. 3985 2. The verb “load” means here that the Chip Authentication Private Key and the Active 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 Pri- vate Key) 3990 Hierarchical to No other components. Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/CAPK The TSF shall restrict the ability to load223 the Chip 3995 Authentication Private Key224 to R.Admin225 [REFINEMENT] before is- suing the TOE. Notes 1. This SFR has been adapted from [BSI-CC-PP-0056-V2-2012-MA-02] . 4000 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 memory. 3. The Chip Authentication Private Key mentioned here is used for performing Chip Authentication Protocol Version 1. 4005 220 [selection: create, load] 221 REFINEMENT 222 [assignment: the authorized identified roles] 223 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 224 [assignment: list of TSF data] 225 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 111 Chapter 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. Dependencies FMT_SMF.1 Specification of management functions fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles fulfilled by FMT_SMR.1 4010 FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read226 the 1. PACE passwords, 2. Chip Authentication private key, 3. Personalization Agent Keys227 4. Electronic signature key 4015 5. PACE Chip Authentication Mapping private key 6. Active Authentication Private Key228 to none229 . Notes 4020 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 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. 4025 7.6.5.14 FMT_MTD.1/RAD (Management of TSF data) SSCD Hierarchical to No other components. Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions 4030 FMT_MTD.1.1/RAD The TSF shall restrict the ability to create230 the RAD231 [REFINEMENT] of the Signatory once to R.Admin232 R.Sigy only after successful authentication with the transport PIN (PIN.T).233 Note 4035 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 directly instead of using the administrator as an intermediary. 226 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 227 [assignment: list of TSF data] 228 [assignment: list of TSF data] 229 [assignment: the authorised identified roles] 230 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 231 [assignment: list of TSF data] 232 [assignment: the authorised identified roles] 233 REFINEMENT of “R.Admin” Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 112 Chapter 7. Security Requirements (ASE_REQ) 7.6.5.15 FMT_MTD.1/Signatory (Management of TSF data) SSCD Hierarchical to No other components. 4040 Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/Signatory The TSF shall restrict the ability to modify234 or un- block235 the RAD236 to R.Sigy237 . 4045 7.6.5.16 FMT_MTD.3 (Secure TSF data) EAC Hierarchical to No other components. 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 4050 and the Access Control.238 Refinement: The certificate chain is valid if and only if 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 4055 Current Date of the TOE, 2. the digital signature of the Document Verifier Certificate can be verified 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 4060 of the TOE and the expiration date of the Document Verifier Certificate is not before the Current Date of the TOE, 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. 4065 The Inspection System Public Key contained in the Inspection System Certificate in a valid certificate chain is a secure value for the authentication 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 4070 Authorization of a successful authenticated Extended Inspection System. 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 4075 as TSF data for access control required by FDP_ACF.1/TRM. 234 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 235 [assignment: other operations] 236 [assignment: list of TSF data] 237 [assignment: the authorised identified roles] 238 [assignment: list of TSF data] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 113 Chapter 7. Security Requirements (ASE_REQ) 7.6.5.17 FMT_SMF.1 (Specification of Management Functions) PACE SSCD Hierarchical to No other components. Dependencies No dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following management 4080 functions: 1. Initialization, 2. Pre-personalization, 3. Personalization, 4. Configuration 4085 5. creation and modification of RAD; 6. enabling the signature creation function; 7. modification of the security attribute SCD/SVD management, SCD operational; 8. change the default value of the security attribute SCD Identifier;239 4090 9. none.240 Note 1. For “configuration” see chapter Life Cycle Phases Mapping section “Phase 3 “Personal- ization of the travel document” step (v). 4095 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]. 7.6.5.18 FMT_MOF.1 (Management of security functions behavior) SSCD Hierarchical to No other components. Dependencies 4100 FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MOF.1.1 The TSF shall restrict the ability to enable241 the functions signature creation function242 to R.Sigy243 . 239 [assignment: list of management functions to be provided by the TSF] 240 [assignment: list of other security management functions to be provided by the TSF] 241 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 242 [assignment: list of functions] 243 [assignment: the authorised identified roles] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 114 Chapter 7. Security Requirements (ASE_REQ) 7.6.5.19 FMT_MSA.1/Admin (Management of security attributes) 4105 SSCD Hierarchical to No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles 4110 FMT_SMF.1 Specification of Management Functions FMT_MSA.1.1/Admin The TSF shall enforce the SCD/SVD_Generation_SFP244 to restrict the ability to modify245 and none246 the security attributes SCD/SVD management247 to R.Admin248 . 7.6.5.20 FMT_MSA.1/Signatory (Management of security attributes) 4115 SSCD Hierarchical to No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles 4120 FMT_SMF.1 Specification of Management Functions FMT_MSA.1.1/Signatory The TSF shall enforce the Signature_Creation_SFP to restrict the ability to modify the security attributes SCD operational to R.Sigy. 7.6.5.21 FMT_MSA.2 (Secure security attributes) SSCD Hierarchical to No other components. 4125 Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles 4130 FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for SCD/SVD Management and SCD operational249 . Security attribute “SCD/SVD Management” can only have the values “authorized” or “not authorized”. Both values are secure, depending on the situation. 4135 Security attribute “SCD operational” can only have the values “no” or “yes”. Both values are secure, depending on the situation. The security attribute values are not secure by themselves but in combinations. The secure values of the combinations are shown in the table Secure 4140 values of the combinations of security attributes. 244 [assignment: access control SFP(s), information flow control SFP(s)] 245 [selection: change_default, query, modify, delete, [assignment: other operations]] 246 [assignment: other operations] 247 [assignment: list of security attributes] 248 [assignment: the authorised identified roles] 249 [selection: list of security attributes] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 115 Chapter 7. Security Requirements (ASE_REQ) Therefore all combinations can be seen as secure.250 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) 4145 SSCD Hierarchical to No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1 The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_ 4150 Transfer_SFP and Signature_Creation_SFP251 to provide restrictive252 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the R.Admin253 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) 4155 SSCD Hierarchical to No other components. 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 4160 attributes: 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 4165 “SCD operational of the SCD” shall be set to “yes” as a single operation.254 Note 1. Rule 2) is deleted, as the TOE does not support generating an SVD/SCD pair by the 4170 signatory alone. 250 REFINEMENT 251 [assignment: access control SFP, information flow control SFP] 252 [selection, choose one of: restrictive, permissive, [assignment: other property]] 253 [assignment: the authorised identified roles] 254 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 116 Chapter 7. Security Requirements (ASE_REQ) 7.6.6 Class FAU Security Audit 7.6.6.1 FAU_SAS.1 (Audit storage) PACE Hierarchical to No other components. Dependencies No dependencies. 4175 FAU_SAS.1.1 The TSF shall provide the Manufacturer255 with the capability to store the Initialization and Pre-Personalization Data256 in the audit records. Note 1. The Manufacturer role is the default user identity assumed by the TOE in the life cycle 4180 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 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 4185 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 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 4190 with the SAR “Security architecture description” (ADV_ARC.1) prevent bypassing, deactiva- tion and manipulation of the security features or misuse of TOE functions. 7.6.7.1 FPT_EMS.1 (TOE Emanation) PACE EAC Hierarchical to No other components. Dependencies No Dependencies. 4195 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 consump- tion, clock, or I/O lines during internal operations or data transmis- sions257 4200 in excess of unintelligible limits258 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, 4. none259 , 4205 5. Personalization Agent Key(s), 6. Chip Authentication Private Key260 and 255 [assignment: authorised users] 256 [assignment: list of audit information] 257 [assignment: types of emissions] 258 [assignment: specified limits] 259 [assignment: list of types of TSF data] 260 [assignment: list of types of TSF data] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 117 Chapter 7. Security Requirements (ASE_REQ) 7. Active Authentication Private Key and 8. PACE Chip Authentication Mapping private key261 . FPT_EMS.1.2 The TSF shall ensure any users262 are unable to use the following 4210 interface smart card circuit contacts263 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, 4. none264 , 4215 5. Personalization Agent Key(s) and 6. Chip Authentication Private Key265 and 7. Active Authentication Private Key and 8. PACE Chip Authentication Mapping private key266 . 4220 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. These extensions do not conflict with the strict conformance to [BSI-CC-PP-0068-V2- 4225 2011-MA-01] and [BSI-CC-PP-0056-V2-2012-MA-02]. 2. The TOE preventd 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 may be caused by an attacker that varies the physical environment under which the 4230 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-7816-part-2] as well (in case the package only provides a contactless interface 4235 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. 261 [assignment: list of types of user data] 262 [assignment: type of users] 263 [assignment: type of connection] 264 [assignment: list of types of TSF data] 265 [assignment: list of types of TSF data] 266 [assignment: list of types of user data] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 118 Chapter 7. Security Requirements (ASE_REQ) 7.6.7.2 FPT_EMS.1/SSCD (TOE Emanation of SCD and RAD) 4240 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 consump- 4245 tion, clock, or I/O lines during internal operations or data transmis- sions267 in excess of unintelligible limits268 enabling access to RAD269 and SCD270 . FPT_EMS.1.2/SSCD The TSF shall ensure any users271 are unable to use the following interface smart card circuit contacts272 to gain access to RAD273 4250 and SCD274 . 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 4255 failures occur: 1. Exposure to operating conditions causing a TOE malfunction, 2. Failure detected by TSF according to FPT_TST.1,275 3. Failures during cryptographic operations 4. Memory failures during TOE execution 4260 5. Out of range failures of temperature, clock and voltage sensors 6. Failures during random number generation.276 7.6.7.4 FPT_TST.1 (TSF testing) PACE SSCD Hierarchical to No other components. Dependencies No dependencies. 4265 FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up and at the conditions 1. start-up 2. Reading Initialization and Pre-personalization Data according to FMT_MTD.1/INI_DIS 4270 3. Reading data of LDS groups and EF.SOD 4. Reading CA keys (secret key only internally) 267 [assignment: types of emissions] 268 [assignment: specified limits] 269 [assignment: list of types of TSF data] 270 [assignment: list of types of user data] 271 [assignment: type of users] 272 [assignment: type of connection] 273 [assignment: list of types of TSF data] 274 [assignment: list of types of user data] 275 [assignment: list of types of failures in the TSF] 276 [assignment: list of other types of failures in the TSF] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 119 Chapter 7. Security Requirements (ASE_REQ) 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 4275 6. Reading certificates internally before Terminal Authentica- tion 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 8. Generation of the SCD/SVD key pair according to “FCS_ 4280 CKM.1/EC” or “FCS_CKM.1/RSA” 9. Signature-creation according to “FCS_COP.1/EC” or “FCS_ COP.1/RSA” 10. VAD verification 11. RAD modification277 4285 to demonstrate the correct operation of the TSF278 . FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of the TSF data279 . FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of stored TSF executable code TSF280 . 4290 Note 1. This SFR covers both definitions from [BSI-CC-PP-0059-2009-MA-02] and [BSI-CC-PP- 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 4295 the stronger one. 7.6.7.5 FPT_PHP.1 (Passive detection of physical attack) SSCD Hierarchical to No other components. Dependencies No dependencies. FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tamper- 4300 ing 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. 277 [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]] 278 [selection: [assignment: parts of TSF], the TSF] 279 [selection: [assignment: parts of TSF], TSF data] 280 [selection: [assignment: parts of TSF], TSF] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 120 Chapter 7. Security Requirements (ASE_REQ) 7.6.7.6 FPT_PHP.3 Resistance to physical attack PACE SSCD Hierarchical to No other components. 4305 Dependencies No dependencies. FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing281 to the TSF282 by responding automatically such that the SFRs are always enforced. 4310 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 protection against these attacks is required ensuring that the TSP could not be violated 4315 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. 7.7 Security Assurance Requirements for the TOE The assurance requirements for the evaluation of the TOE and its development and operating 4320 environment are those taken from the ˆ Evaluation Assurance Level 4 (EAL4) and augmented by taking the following components: ˆ ALC_DVS.2, ˆ ATE_DPT.2 and 4325 ˆ AVA_VAN.5. 281 [assignment: physical tampering scenarios] 282 [assignment: list of TSF devices/elements] Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 121 Chapter 7. Security Requirements (ASE_REQ) 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 Note 4330 1. The TOE shall protect the assets against high attack potential. This includes intermedi- ate 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 confidentiality of the standard data shall be protected against attackers with at 4335 least Enhanced-Basic attack potential (AVA_VAN.3). 7.8 Security Requirements Rationale 7.8.1 Security Functional Requirements Coverage The following table provides an overview for security functional requirements coverage. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 122 Chapter 7. Security Requirements (ASE_REQ) Fig. 7.1: Functional Requirement to TOE security objective mapping Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 123 Chapter 7. Security Requirements (ASE_REQ) 7.8.2 TOE Security Requirements Sufficiency 4340 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 only the Manufacturer to write Initialization and Pre-personalization Data (including 4345 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) 4350 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 4355 authenticated 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_ 4360 READ and FPT_EMS.1 restrict 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 4365 Terminal Authentication Protocol v.1 (after Chip Authentication v.1) with the Personalization Agent 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_RSA283 (for the derivation of the new ses- sion 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_ 4370 VER_RSA284 (as part of the Terminal Authentication Protocol v.1) and FIA_UAU.6/EAC (for the re-authentication). 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 4375 authentication attempt). The session keys are destroyed according to FCS_CKM.4 after use. OT.Data_Integrity (Integrity of Data) 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 manipulation is addressed by FPT_PHP.3. Logical manipulation of stored user data is 4380 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 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 4385 TOE and used for the Passive Authentication is allowed to be written by the Personalization 283 REFINEMENT FCS_CKM.1/CA_RSA is added to this ST 284 REFINEMENT FCS_COP.1/SIG_VER_RSA is added to this ST Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 124 Chapter 7. Security Requirements (ASE_REQ) Agent only and, hence, is to be considered as trustworthy. The Personalization Agent must identify and 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 specific properties of the protocols used. The SFR FMT_SMR.1/PACE lists the 4390 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 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_RSA285 and 4395 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 requires erasing the values of session keys (here: for K.MAC). The TOE supports the inspection system detect any modification of the transmitted logical 4400 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 FCS_CKM.1/CA_EC or FCS_CKM.1/CA_RSA286 (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_ 4405 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 Au- thentication Key cannot be written unauthorized or read afterward. The SFR FCS_RNG.1 represents a general support for cryptographic operations needed. 4410 The SFR FCS_RNG.1 represents a general support for cryptographic operations needed.287 OT.Data_Authenticity (Authenticity of Data) aims ensuring authenticity of the User- and TSF data (after the PACE Authentication) by enabling its verification at the terminal-side and by an active verification by the TOE itself. 4415 This objective is mainly achieved by FTP_ITC.1/PACE using FCS_COP.1/PACE_MAC. 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_PACE_RSA288 resp. FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA289 and possessing the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp. FIA_ 4420 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 prop- erties of the protocols used. The SFR FMT_MTD.1/KEY_READ restricts the access to the PACE passwords and the Chip Authentication Private Key. 4425 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. 4430 285 REFINEMENT 286 REFINEMENT FCS_CKM.1/CA_RSA is added to this ST 287 REFINEMENT 288 REFINEMENT 289 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 125 Chapter 7. Security Requirements (ASE_REQ) 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 prop- 4435 erties of the protocols used. 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 Termi- nal Authentication v.1 (FIA_UID.1/PACE, FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE_ 4440 EC and FCS_CKM.1/DH_PACE_RSA290 resp. FCS_CKM.1/CA_EC and FCS_CKM.1/CA_ RSA291 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 4445 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 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) 4450 is enforced by the Access Control SFP defined in FDP_ACC.1/TRM and FDP_ACF.1/TRM allow- ing 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_RSA292 . The SFRs FIA_UID.1/PACE and FIA_UAU.1/PACE require the identification and authenti- 4455 cation of the inspection systems. The SFR FIA_UAU.5/PACE requires the successful Chip Authentication (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 4460 data after Chip Authentication v.1 by means of secure messaging implemented by the cryptographic functions according to FCS_RNG.1 (for the generation of the terminal authen- tication challenge), FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA293 (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 4465 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 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 4470 of FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. 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_RSA294 is performed using a TOE internally stored confidential private key 4475 290 REFINEMENT 291 REFINEMENT 292 REFINEMENT FCS_COP.1/SIG_VER_RSA is added to this ST 293 REFINEMENT 294 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 126 Chapter 7. Security Requirements (ASE_REQ) as required by FMT_MTD.1/CA_AA_PK and FMT_MTD.1/KEY_READ. The Chip Authentication Protocol v.1 [BSI-TR-03110-1-V220] requires additional TSF according to FCS_CKM.1/CA_ EC and FCS_CKM.1/CA_RSA295 (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. 4480 The SFR FMT_MTD.1/CA_AA_PK requires that the Chip Authentication Key used for Chip Authentication Protocol v.1 cannot be imported unauthorized.296 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 4485 TOE internally stored confidential private key as required by FMT_MTD.1/CA_AA_ PK and FMT_MTD.1/KEY_READ. The Active Authentication Protocol [ICAO-9303-2015] requires additional TSF according to FCS_COP.1/AA_SGEN_EC and FCS_COP.1/AA_ SGEN_RSA (for the generation ot the digital signatures). The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support the functions and roles related. 4490 The SFR FMT_MTD.1/CA_AA_PK requires that the Active Authentication Key used for Active 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. 4495 OT.Prot_Inf_Leak (Protection against Information Leakage) 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, 4500 clock, or I/O lines which is addressed by the SFR FPT_EMS.1, ˆ 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) 4505 aims that the TOE prevents gathering TOE tracing data by means of unambiguous identifying 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 4510 data) - by FIA_AFL.1/PACE; (ii) for listening to PACE communication (is of importance for the current ST, since S.OD is card-individual) - FTP_ITC.1/PACE. 295 REFINEMENT 296 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 127 Chapter 7. Security Requirements (ASE_REQ) OT.Prot_Phys-Tamper (Protection against Physical Tampering) is covered by the SFR FPT_PHP.3. 4515 OT.Prot_Malfunction (Protection against Malfunctions) is covered by (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 4520 conditions possibly causing a malfunction. 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), 4525 ˆ FCS_COP.1/RSA (for SCD usage using RSA) and ˆ FCS_CKM.4 (for SCD destruction) ensuring cryptographically secure life cycle of the SCD. The SCD/SVD generation is controlled by TSF according to ˆ FDP_ACC.1/SCD/SVD_Generation and 4530 ˆ FDP_ACF.1/SCD/SVD_Generation. 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 4535 ˆ FDP_ACC.1/Signature_Creation, ˆ FDP_ACF.1/Signature_Creation, which is based on the security attribute secure TSF management according to ˆ FMT_MOF.1, ˆ FMT_MSA.1/Admin, 4540 ˆ FMT_MSA.1/Signatory, ˆ FMT_MSA.2, ˆ FMT_MSA.3, ˆ FMT_MSA.4, ˆ FMT_MTD.1/RAD, 4545 ˆ FMT_MTD.1/Signatory, ˆ FMT_SMF.1 and ˆ FMT_SMR.1. The test functions Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 128 Chapter 7. Security Requirements (ASE_REQ) ˆ FPT_TST.1 4550 provides failure detection throughout the life cycle. (Life cycle security) in the Phase “Usage/Preparation” is provided by the SFRs ˆ FCS_COP.1/AES_MAC, ˆ FIA_UID.1, ˆ FIA_UAU.1, 4555 ˆ FIA_AFL.1/AuthAdmin provides protection against brute force attacks against authenti- cation. (Life cycle security) in the Phase “Usage/Operational” is provided by the SFRs which essentially 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 4560 control to EF.CardSecurity (references to FDP_ACx.1/TRM) arises from the fact that this EF contains 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, 4565 ˆ FCS_CKM.1/CA_RSA, ˆ FCS_CKM.4 (for session key destruction), ˆ FCS_COP.1/PACE_ENC, ˆ FCS_COP.1/PACE_MAC, ˆ FCS_COP.1/CA_ENC, 4570 ˆ FCS_COP.1/CA_MAC, ˆ FCS_RNG.1, ˆ FDP_ACC.1/TRM, ˆ FDP_ACF.1/TRM, ˆ FIA_UID.1, 4575 ˆ FIA_UAU.1, ˆ FIA_UAU.4/PACE, ˆ FIA_UAU.5/PACE, ˆ FIA_UAU.6/PACE, ˆ FIA_UAU.6/CA, 4580 ˆ FIA_API.1, ˆ FMT_MTD.1/KEY_READ, ˆ FMT_MTD.1/CAPK. OT.SCD/SVD_Auth_Gen (Authorised SCD/SVD generation) addresses that generation of a SCD/SVD pair requires proper user authentication. The TSF specified by 4585 ˆ FIA_UID.1 and ˆ FIA_UAU.1 provide user identification and user authentication prior to enabling access to authorized functions. The SFR Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 129 Chapter 7. Security Requirements (ASE_REQ) ˆ FDP_ACC.1/SCD/SVD_Generation and 4590 ˆ FDP_ACF.1/SCD/SVD_Generation provide access control for the SCD/SVD generation. The security attributes of the authenti- cated user are provided by ˆ FMT_MSA.1/Admin, ˆ FMT_MSA.2 and 4595 ˆ FMT_MSA.3 for static attribute initialization. The SFR ˆ FMT_MSA.4 defines rules for inheritance of the security attribute “SCD operational” of the SCD. OT.SCD_Unique (Uniqueness of the signature creation data) implements the requirement 4600 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. OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) addresses that the SVD 4605 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 to generate corresponding SVD/SCD pairs. The security functions specified by 4610 ˆ FDP_SDI.2/Persistent ensure that the keys are not modified, so to retain the correspondence. Moreover, the SCD Identifier allows the environment to identify the SCD and to link it with the appropriate SVD. The management functions identified by ˆ FMT_SMF.1 and by 4615 ˆ 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. ˆ FCS_CKM.1/EC and 4620 ˆ 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. The security functions specified by 4625 ˆ FDP_RIP.1 and ˆ FCS_CKM.4 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 130 Chapter 7. Security Requirements (ASE_REQ) 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. The security functions specified by 4630 ˆ 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. ˆ FPT_TST.1 tests the working conditions of the TOE and 4635 ˆ 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). ˆ FPT_EMS.1/SSCD and 4640 ˆ 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 cryptographic algorithms specified by ˆ FCS_COP.1/EC, 4645 ˆ FCS_COP.1/RSA and ˆ FCS_COP.1/SHA which ensures the cryptographic robustness of the signature algorithms, ˆ FDP_SDI.2/Persistent corresponds to the integrity of the SCD implemented by the TOE and 4650 ˆ 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 intermediate hash value with the remainder of DTBS (last round hash value) is sent to the TOE for signature creation. 4655 OT.Sigy_SigF (Signature creation function for the legitimate signatory only) is provided by an SFR for identification, authentication and access control. ˆ FIA_UAU.1 and ˆ FIA_UID.1 ensure that no signature creation function can be invoked before the signatory is identified 4660 and authenticated. The security functions specified by ˆ FMT_MTD.1/RAD and ˆ FMT_MTD.1/Signatory manage the authentication function. 4665 ˆ FIA_AFL.1/RAD Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 131 Chapter 7. Security Requirements (ASE_REQ) 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. ˆ FIA_AFL.1/Suspend_PIN provides protection against denial-of-service attacks. 4670 ˆ FIA_AFL.1/Block_PIN provides protection against brute force attacks against authenti- cation. The security functions specified by ˆ FDP_SDI.2/DTBS ensures the integrity of stored DTBS and 4675 ˆ 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 ˆ FDP_ACC.1/Signature_Creation and 4680 ˆ 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, ˆ FMT_MSA.3 and 4685 ˆ FMT_MSA.4. The SFRs ˆ FMT_SMF.1 and ˆ FMT_SMR.1 list these management functions and the roles. These ensure that the signature process is 4690 restricted to the signatory. ˆ FMT_MOF.1 restricts the ability to enable the signature creation function to the signatory. ˆ FMT_MSA.1/Signatory restricts the ability to modify the security attributes SCD operational to the signatory. 4695 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, ˆ FCS_CKM.1/DH_PACE_EC, 4700 ˆ FCS_COP.1/PACE_ENC, ˆ FCS_COP.1/PACE_MAC, ˆ FCS_RNG.1, ˆ FDP_UCT.1/TRM, ˆ FDP_UIT.1/TRM, 4705 ˆ FIA_UID.1, ˆ FIA_UAU.1, Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 132 Chapter 7. Security Requirements (ASE_REQ) ˆ FIA_UAU.4/PACE, ˆ FIA_UAU.5/PACE, ˆ FIA_UAU.6/PACE and 4710 ˆ 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 ˆ FDP_SDI.2/DTBS require that the DTBS/R has not been altered by the TOE. 4715 OT.EMSEC_Design (Provide physical emanations security) covers that no intelligible infor- mation is emanated. This is provided by ˆ FPT_EMS.1/SSCD and ˆ FPT_EMS.1. OT.Tamper_ID (Tamper detection) is provided by 4720 ˆ FPT_PHP.1 by the means of passive detection of physical attacks. OT.Tamper_Resistance (Tamper resistance) is provided by ˆ FPT_PHP.3 to resist physical attacks. 4725 CGA OT.TOE_SSCD_Auth (Authentication proof as SSCD) requires the TOE to provide security mechanisms to identify and to authenticate themselves as SSCD297 , which is directly provided by ˆ FIA_API.1. The SFR 4730 ˆ FIA_UAU.1 allows (additionally to PP SSCD KG) establishment of the trusted channel before (human) user is authenticated. Furthermore ˆ FMT_MTD.1/CAPK 4735 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 CGA298 , which is directly provided by 297 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. 298 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 133 Chapter 7. Security Requirements (ASE_REQ) ˆ the SVD transfer for certificate generation controlled by TSF according to 4740 – FDP_ACC.1/SVD_Transfer and – FDP_ACF.1/SVD_Transfer. ˆ The SFR – FDP_DAU.2/SVD requires the TOE to provide CGA with the ability to verify evidence of the validity of 4745 the SVD and the identity of the user that generated the evidence. ˆ The SFR – FTP_ITC.1/SVD requires the TOE to provide a trusted channel to the CGA. The functionality for integrity and confidentiality is provided by the following SFRs, which 4750 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, 4755 ˆ 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, 4760 ˆ FCS_COP.1/CA_MAC, ˆ FCS_RNG.1, ˆ FDP_ACC.1/TRM, ˆ FDP_ACF.1/TRM, ˆ FDP_UCT.1/TRM, 4765 ˆ FDP_UIT.1/TRM, ˆ FIA_UID.1, ˆ FIA_UAU.1, ˆ FIA_UAU.4/PACE, ˆ FIA_UAU.5/PACE, 4770 ˆ 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 4775 SCA OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) is provided by ˆ FTP_ITC.1/VAD Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 134 Chapter 7. Security Requirements (ASE_REQ) 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 4780 ˆ 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, 4785 ˆ FCS_RNG.1, ˆ FDP_UCT.1/TRM, ˆ FDP_UIT.1/TRM, ˆ FIA_UAU.1, ˆ FIA_UAU.4/PACE, 4790 ˆ 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 4795 ˆ 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 4800 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, 4805 ˆ FCS_COP.1/PACE_MAC, ˆ FCS_RNG.1, ˆ FDP_UCT.1/TRM, ˆ FDP_UIT.1/TRM, ˆ FIA_UID.1, 4810 ˆ FIA_UAU.1, ˆ FIA_UAU.4/PACE, ˆ FIA_UAU.5/PACE, ˆ FIA_UAU.6/PACE and ˆ FMT_MTD.1/KEY_READ. 4815 FDP_RIP.1 requires erasing the values of session keys Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 135 Chapter 7. Security Requirements (ASE_REQ) 7.9 Satisfaction of Dependencies of Security Require- ments The dependency analysis for the security functional requirements shows that the basis for mutual support and internal consistency between all defined functional requirements is 4820 satisfied. All dependencies between the chosen functional components are analyzed, and 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 4825 Requirements for the TOE and ˆ 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_RSA [FDP_ITC.1 or FDP_ ITC.2 or FCS_CKM.1], FCS_CKM.4 see Justification 5 below, FCS_CKM.4 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 136 Chapter 7. Security Requirements (ASE_REQ) Table 7.9 – continued from previous page Functional requirements Dependencies Satisfied by 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 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.1299 No dependencies n.a. FIA_UAU.1300 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 Justification 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 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 137 Chapter 7. Security Requirements (ASE_REQ) Table 7.9 – continued from previous page Functional requirements Dependencies Satisfied by 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 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 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 138 Chapter 7. Security Requirements (ASE_REQ) Table 7.9 – continued from previous page Functional requirements Dependencies Satisfied by FMT_MTD.1/PA FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_ SMR.1/PACE 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: 4830 1. The access control TSF according to FDP_ACF.1/TRM uses security attributes which are 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 Authenti- 4835 cation are generated outside of the TOE, see A.Auth_PKI (PKI for Inspection Systems). (ii) Dependencies “FDP_ITC.1 Import of user data without security at- tributes” and “FDP_ITC.2 Import of user data with security attributes” are not necessary because all keys are written using FMT_MTD.1/CVCA_INI 4840 (Management of TSF data - Initialization of CVCA Certificate and Current Date) regardless whether the keys are EC or RSA keys.301 3. Justification of “FCS_COP.1/SHA” can be found in FCS_COP.1/SHA (Cryptographic operation – Hash calculation). 4. Justification of “FCS_COP.1/AES_MAC” can be found in FCS_COP.1/AES_MAC (Crypto- 4845 graphic operation – MACing with AES) 5. The Chip Authentication and Active Authentication Keys are permanently stored during personalisation in accordance to FMT_MTD.1/CA_AA_PK. Therefore, no key generation or import policy is needed. 299 This SFR is amended with an item from [BSI-CC-PP-0068-V2-2011-MA-01]. 300 This SFR is amended with items from PP SSCD KG TCCGA, PP SSCD KG TCSCA and [BSI-CC-PP-0068-V2- 2011-MA-01]. 301 REFINEMENT Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 139 Chapter 7. Security Requirements (ASE_REQ) 7.10 Rationale for Chosen Security Assurance Require- 4850 ments 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 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 exceeded in the EAL4 as- surance 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 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. 4855 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: ˆ ALC_DVS.2 which provides a higher assurance of the security of the travel docu- ment’s development and manufacturing especially for the secure handling of the travel 4860 document’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. ˆ 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 4865 high attack potential. The TOE is intended to function as ˆ an ePassport (with user data stored in an ICAO-compliant ePass application) or ˆ 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 4870 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 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 4875 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- cies are fulfilled as shown in Table 7.10. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 140 Chapter 7. Security Requirements (ASE_REQ) 7.11 Security Requirements - Mutual Support and Inter- 4880 nal 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 security assurance requirements (SARs) together form a mutually supportive and internally consistent whole. 4885 The analysis of the TOE’s security requirements with regard to their mutual support and internal consistency demonstrates: The dependency analysis in section Satisfaction of Dependencies of Security Requirements for the security functional requirements shows that the basis for mutual support and internal consistency between all defined functional requirements is satisfied. All dependencies 4890 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 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. 4895 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 requirements are mutually supportive and internally consistent as all (sensitive) dependencies are satisfied and no inconsistency appears. 4900 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 for Chosen Security Assurance Requirements. Furthermore, as also discussed in section Rationale for Chosen Security Assurance Requirements, the chosen assurance components 4905 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. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 141 Chapter 8. TOE Summary Specification (ASE_TSS) 8 TOE Summary Specification (ASE_TSS) 8.1 TOE Security Services 4910 8.1.1 User Identification and Authentication (ePass) This Security Service is responsible for maintaining of the following roles 1. Manufacturer, 2. Personalization Agent, 3. Terminal, 4915 4. PACE authenticated BIS-PACE, 5. Country Verifying Certification Authority, 6. Document Verifier, 7. Domestic Extended Inspection System 8. Foreign Extended Inspection System 4920 according to FMT_SMR.1/PACE. The TOE allows ˆ identification of the user according to FIA_UID.1/PACE before the authentication takes place according to FIA_UAU.1/PACE ˆ the execution of following TSF-mediated actions before the user is identified and 4925 associated with one of maintained roles 1. to establish the communication channel 2. carrying out the PACE Protocol according to 3. to read the Initialization Data if it is not disabled by TSF 4. to carry out the Chip Authentication Protocol v.1 4930 5. to carry out the Terminal Authentication Protocol v.1 6. to carry out the Active Authentication Protocol 7. to run self tests ˆ the execution of following TSF-mediated actions before the user is authenticated 1. to establish the communication channel 4935 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 5. to carry out the Chip Authentication Protocol Version 1 6. to carry out the Terminal Authentication Protocol Version 1 4940 7. to carry out the Active Authentication Protocol 8. to run self tests. Note Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 142 Chapter 8. TOE Summary Specification (ASE_TSS) 1. If a user acts as (Travel Document) Manufacturer or Personalization Agent, the user 4945 acts as Administrator according to [Atos-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 by the IC Manufacturer according to ˆ FMT_SMF.1 (1) 4950 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 ˆ FMT_SMF.1 (1) + (2) which includes import the Initialization Data and Pre-personalization Data in the audit 4955 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 ˆ file system including MF and ICAO.DF and ˆ the ePassport application. 4960 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. Reading of the PACE passwords is not allowed according to FMT_MTD.1/KEY_READ. 8.1.1.2 Personalization Agent Identification and Authentication 4965 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) and the authentication data is not reused according to ˆ FIA_UAU.4/PACE (2) 4970 using the Symmetric Authentication Mechanism provided by ˆ FIA_UAU.5.1/PACE (4) and the authentication attempt is accepted according to ˆ FIA_UAU.5.2/PACE rule (2). The usage of the 4975 ˆ 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). The Personalization Agent performs MRTD Configuration for files (e.g. LDS data groups and EF.SOD) and for objects (e.g. for keys). 4980 The tasks of the Personalization Agent are specified by FMT_SMF.1 (3) + (4). The Personalization Agent is allowed to read out Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 143 Chapter 8. TOE Summary Specification (ASE_TSS) ˆ the Initialization Data and the Pre-personalization Data according to FMT_MTD.1/INI_ DIS and he is allowed to read the Initialization Data before he is identificated and authenticated 4985 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. If the Personalization Agent is identificated and authenticated successfully, he is allowed to 4990 perform following tasks: 1. Writing (i) initial Country Verifying Certification Authority Public Key: PK.CVCA, (ii) initial Country Verifying Certification Authority Certificate: C.CVCA, (iii) initial Current Date, 4995 according to FMT_MTD.1/CVCA_INI (iv) the Document Security Object (SOD) according to FMT_MTD.1/PA. 2. Loading (v) Chip Authentication Private Key and Active Authentication Private Key 5000 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 (vi) Chip Authentication Private Key 5005 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 Private Key after loading it according to FMT_MTD.1/KEY_READ. 5010 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. This is done to prevent misuse, see [BSI-CC-PP-0068-V2-2011-MA-01] application note 49. 5015 Additionally the Personalization Agent shall invalidate his key(s). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 144 Chapter 8. TOE Summary Specification (ASE_TSS) 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 authenticated BIS-PACE. A user in the role terminal is 5020 ˆ 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). After the PACE protocol is successfully performed the TOE accepts only commands sent by means of secure messaging according to 5025 ˆ 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 ˆ FIA_UID.1.1/PACE (2) 5030 ˆ 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 ˆ the Active Authentication Protocol. 5035 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 ˆ enforces communication via the trusted channel for any data exchange between the 5040 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 deriva- tion (with MRZ or CAN as password) and 5045 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 ˆ FCS_CKM.1/CA_EC and FCS_CKM.1/CA_RSA for Chip Authentication session key deriva- 5050 tion (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) 2. FCS_COP.1/CA_MAC for integrity (by MACing the commands). 5055 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 145 Chapter 8. TOE Summary Specification (ASE_TSS) 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 and replay has occurred. 5060 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 ˆ FIA_UAU.6/PACE in case of a PACE protocol. The usage of session keys 5065 ˆ {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 starting of ECDH for PACE) 5070 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 ephem-SK.PICC.PACE are invalidated according to 5075 ˆ FCS_CKM.4 ˆ FDP_RIP.1. and ˆ the security attribute PACE Authentication (see FDP_ACF.1.1/TRM) is unset ˆ the security attribute Terminal Authentication Status is set to “none”. 5080 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 ˆ Signatory 5085 ˆ 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) – It uses 5090 a. PIN.CH, b. optionally PUK.CH, c. PIN.T, d. PIN.ADMIN or 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 146 Chapter 8. TOE Summary Specification (ASE_TSS) e. CAN as passwords. 5095 – 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 is finally blocked (only PIN.CH, PUK.CH, PIN.T and PIN.ADMIN) (FIA_ 5100 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). – The cryptographic method for confidentiality is AES/CBC (supplied by FCS_ COP.1/PACE_ENC). – The cryptographic method for authenticity is CMAC (supplied by FCS_COP.1/PACE_ 5105 MAC). – On error (wrong MAC, wrong challenge) the user role is not identi- fied/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_ 5110 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). 5115 – 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. 5120 – 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). 5125 ˆ 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 authentication data that is blocked after an administrator configurable positive integer within 3 up to floor(MINLEN/2) consecutive failed authentication attempts 5130 (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)) 5135 – 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). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 147 Chapter 8. TOE Summary Specification (ASE_TSS) ˆ Chip Authentication Protocol Version 12 according to [BSI-TR-03110-1-V220] (FIA_ 5140 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). 5145 – On error the user role is not identified/authenticated. – 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_ 5150 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. 5155 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 5160 different ways: 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 5165 received by the TOE software developer has to be performed, since the initial StartKey is not 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 5170 a value only known to him. 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 5175 during preparation of the TOE (see section Life Cycle Phases Mapping Phase “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. 5180 The TOE personalization is secured by using the Symmetric Authentication Mecha- 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. 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. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 148 Chapter 8. TOE Summary Specification (ASE_TSS) This TOE behavior is modeled by the SFRs FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_ 5185 DIS and FMT_MTD.1/PA. 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 5190 sense ADMINISTRATION can be seen rather as a state than as a life cycle phase of 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) For the Life Cycle Phase “Operational Use”: 5195 The administrator is identified and authenticated by using the PACE authenti- cation method using the PIN.ADMIN as the shared password in the Phase “Operational Use” represented by the TOE life cycle phase OPERATIONAL. Note 5200 1. By successfully authenticating himself using the PACE authentication method 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 5205 certificate thus including the SVD export from the TOE, the CGA or SSCD Issuing Application establishes the identity of the TOE as SSCD by ˆ reading and verifying EF.CardSecurity using Passive Authentication (FIA_ UAU.5/PACE) ˆ using the Public Key from EF.CardSecurity together with Chip Authentication 5210 Protocol Version 1 to authenticate the SSCD (FIA_API.1). SCD/SVD generation, SVD export from the TOE in this phase require an interaction 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 5215 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 as administrator through a trusted channel established by the Chip Authentication Protocol Version 1. 5220 8.1.2.2 Signatory Identification and Authentication Within the Phase “Operational Use” represented by the TOE life cycle phase OPERA- TIONAL the signatory is identified and authenticated either ˆ by using the transport PIN (PIN.T) as the shared password with the PACE authen- tication method on first usage upon receiving the TOE from the SSCD-provisioning 5225 service provider in order to disable the transport protection and activate (FMT_SMF.1) – the PIN for qualified signature (PIN.QES), Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 149 Chapter 8. TOE Summary Specification (ASE_TSS) – optionally the personal unblocking key (PUK.CH), if present and not already activated.4 5230 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 signatory only after disabling the transport protection (FMT_ MTD.1/RAD). 5235 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. 5. If the PIN of the Signatory (PIN.QES) is not set, it is not possible to enter 5240 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 the PACE authentication method in order to establish a trusted channel between 5245 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 ensuring the confidentiality and integrity of the VAD. 5250 – 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. Note 5255 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 mechanism in order to – create qualified electronic signatures, 5260 – modify the PIN for qualified signature (PIN.QES) itself (FMT_SMF.1 and FMT_MTD.1/Signatory), Note 1. By successfully authenticating himself using PIN verification with the PIN 5265 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) 4 If provision comprises a PUK letter, PUK.CH is already activated. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 150 Chapter 8. TOE Summary Specification (ASE_TSS) a) after each signature 5270 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, c) after card reset or after Application QES was left 5275 if the personalization allows an unlimited number of mass signatures in a row. 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 using any of the available shared passwords (PIN.T, PIN.CH, optional PUK.CH, PIN.ADMIN 5280 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 exchange data with the TOE. 5285 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 provider in order to additionally identify and authenticate the Signatory and 5290 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 for both the signing and management environments (FTP_ITC.1/VAD and FTP_ 5295 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 DTBS respective DTBS/R (A.SCA), 5300 – 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). Notes 5305 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. ˆ by using the PACE authentication method using the optional personal unblocking key 5310 (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 6 Additionally requires verification of PIN.QES 7 Additionally requires verification of PIN.QES Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 151 Chapter 8. TOE Summary Specification (ASE_TSS) – to unblock the PIN for qualified signature (PIN.QES) while ensuring the confiden- tiality and integrity of the VAD (FMT_MTD.1/Signatory), 5315 – 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. ˆ by using the PACE authentication method using the administrator PIN (PIN.ADMIN) 5320 as the shared password in order to additionally identify and authenticate the Ad- ministrator 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 Chip Authentication Protocol Version 1. 5325 ˆ by using the PACE authentication method using any PACE password as the shared password in order to additionally identify and authenticate the Administrator and es- tablish 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. 5330 ˆ 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, 5335 – 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 ensur- ing the confidentiality and integrity of the VAD (FMT_SMF.1), – the execution of EAC with strong certificate and the unblocking and 5340 modification 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. 5345 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 5350 with PACE is a EIS-AIP-PACE using a PACE Terminal. 8 Additionally requires verification of PIN.QES 9 Additionally requires verification of PIN.QES Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 152 Chapter 8. TOE Summary Specification (ASE_TSS) 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 5355 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 5360 Terminal Authentication Protocol v.1 If Advanced Inspection Procedure is performed successfully, the TOE sets the security attributes below (see FDP_ACF.1.1/TRM (3)): ˆ PACE Authentication ˆ the security attribute Terminal Authentication Status accordingly to the roles defined 5365 in 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. 5370 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) 5375 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 5380 next attempt to establish the PACE protocol at least 5 seconds according to ˆ FIA_AFL.1/PACE. This prevents skimming of the passwords because the passwords are non-blocking autho- rization data. If the PACE protocol is performed successfully, the TOE sets the security attribute PACE 5385 Authentication (FDP_ACF.1.1/TRM (3.a)). Observe, that the TOE also support the chip-authentication mapping for PACE which combines PACE and the chip authentication protocol into a shorter command exchange between the terminal and the TOE. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 153 Chapter 8. TOE Summary Specification (ASE_TSS) 8.1.4.2 Chip Authentication Protocol v.1 5390 The terminal proves the identify of the TOE using Chip Authentication Protocol v.1 according 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 5395 channel. After the Chip Authentication Protocol v.1 is successfully performed the TOE accepts only 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. 5400 After Chip Authentication Protocol v.1 the terminal has to validate the Chip Authentication Public Key by ˆ performing Passive Authentication to verify the genuineness of the TOE. The usage of the ˆ Chip Authentication Private Key 5405 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). See Personalization Agent Identification and Authentication for the task loading the CA key pair. 8.1.4.3 Active Authentication Protocol 5410 The terminal proves the identify of the TOE using Active Authentication Protocol according to [ICAO-9303-2015] part 11, section 6.1, using ˆ FIA_API.1/AA for providing the protocol and ˆ FCS_COP.1/AA_SGEN_RSA 5415 ˆ 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. The TOE accepts Active Authentication according to ˆ FIA_UAU.5.1/PACE (6). 5420 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. The usage of the ˆ Active Authentication Private Key 5425 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 pair. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 154 Chapter 8. TOE Summary Specification (ASE_TSS) 8.1.4.4 Terminal Authentication Protocol v.1 5430 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) and ˆ FCS_COP.1/SIG_VER_EC or FCS_COP.1/SIG_VER_RSA 5435 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- 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 5440 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. With FPT_TST.1 reading of a certificate and the generation of a random nonce is checked previously. 5445 If Terminal Authentication Protocol v.1 is performed successfully, the TOE 1. sets the security attribute Terminal Authentication Status (see FDP_ACF.1.1/TRM) accordingly to the roles defined in the certificate used for authentication. It is possible that the 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 5450 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. 3. updates the Current Date and trust anchor if necessary, see :Write access to data of the ePass application at phase Operational Use 5455 Note 1. Terminal Authentication v.1 can only be performed if Chip Authentication v.1 has been successfully executed. 8.1.4.5 Passive Authentication 5460 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 ˆ 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) 5465 ˆ 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 successfully. The TOE accepts Passive Authentication according to 5470 ˆ FIA_UAU.5.1/PACE (2). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 155 Chapter 8. TOE Summary Specification (ASE_TSS) For accessing the SOD and the LDS data fields see Read access to the data of the ePass application at phase Operational Use. Note 5475 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. 8.1.5 Access Control (General and ePass) This security enforces the Access Control SFP on general and ePass application related data. 5480 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 ˆ FDP_ACF.1/TRM after Establishing the trusted channel according to FDP_ACF.1.4/TRM (2): 5485 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 ˆ the inspection system is allowed to read data objects ((FDP_ACF.1.2/TRM): DG1, DG2, DG14, DG15, DG16 and the Security Object SOD. 5490 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: ˆ DG1, DG2, DG14, DG15, DG16 and the Security Object SOD ˆ DG3 if security attribute Terminal Authorization equals DG3 5495 ˆ DG4 if security attribute Terminal Authorization equals DG4 ˆ DG3 and DG4 if security attribute Terminal Authorization equals DG3 / DG4. Notes 1. If the security attribute Terminal Authorization is set to one of the values “DG3” or 5500 “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. 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 5505 to EF.DG3 or EF.DG4 (FDP_ACF.1.4/TRM (6)). Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 156 Chapter 8. TOE Summary Specification (ASE_TSS) 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 Authority, Document Verifier and Domestic Extended Inspection System. The write access to the TOE phase Operational Use depends on role encoded in certificates. 5510 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, ˆ Country Verifying Certification Authority Certificate according to FMT_MTD.1/CVCA_UPD if the Country Verifying CA Link-Certificates are valid 5515 (FMT_MTD.3) after ˆ Terminal Authentication Protocol v.1 is successfully performed. 2. A terminal in the role ˆ Country Verifying Certification Authority (security attribute terminal authentication status has the value CVCA) 5520 or ˆ Document Verifier (security attribute terminal authentication status has the value DV (domestic) or DV (foreign)) or ˆ Domestic Extended Inspection System10 (security attribute terminal authentication 5525 status has the value IS) is allowed to modify ˆ the Current Date according to FMT_MTD.1/DATE if the Country Verifying CA Link-Certificates are valid (FMT_ MTD.3) after 5530 ˆ Terminal Authentication Protocol v.1 is successfully performed and ˆ if the Current Date is before the effective date of the respective certificate. 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 5535 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”. Please note that a prerequisite for performing successfully TA is a successfully performed 5540 Chip Authentication Protocol v.1. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 157 Chapter 8. TOE Summary Specification (ASE_TSS) 8.1.5.3 General access to data This aspect of the security function controls ˆ access to EF.CardSecurity of the TOE and ˆ data exchange with the TOE. 5545 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 2. the access request is sent in a manner protected from unauthorized disclosure, modifi- 5550 cation, deletion, insertion and replay errors. 8.1.6 AccessControl (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 association of users to roles is realized by section User Identification and Authentication 5555 (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 8.1.6.1 Access Control provided by the Signature_Creation_SFP 5560 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 5565 ˆ 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_ 5570 MOF.1 and 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” 5575 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 5580 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 158 Chapter 8. TOE Summary Specification (ASE_TSS) 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” 5585 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 5590 the administrator alone or by the administrator together with the signatory: For the Life Cycle Phase “Composite Product Integration and Initialization” or “Personalization”: During the preparation of the TOE (see section Life Cycle Phases Mapping Phase “Initial- ization” and “Personalization”) the TOE allows the (optional) generation of SCD/SVD pair 5595 if and only if (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 5600 Identification and Authentication 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 “Oper- 5605 ational 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 5610 2. Chip Authentication Protocol Version 1 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 Admin- istrator Identification and Authentication or 5615 1. PACE authentication using any PACE password as the shared password has been successfully 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 Admin- 5620 istrator Identification and Authentication Note Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 159 Chapter 8. TOE Summary Specification (ASE_TSS) 1. Strong Certificate contains Certificate Holder Authorization Template (effective autho- rization) with right “Install Qualified Certificate” set - see [BSI-TR-03110-4-V221] , 5625 chapter 2.2.3.2 Table 4 “Authorization of Authentication Terminals”. 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 secu- rity function policy (SVD_Transfer_SFP) and controls access to the SVD export functionality of the TOE. 5630 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 2. Chip Authentication Protocol Version 1 has been successfully performed 5635 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). 5640 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. or 1. PACE authentication using any PACE password as the shared password has been 5645 successfully 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 4. the exported SVD is sent in a manner to provide the CGA with the ability to verify 5650 evidence of the validity of the SVD (FDP_DAU.2/SVD). Note 1. Strong Certificate contains Certificate Holder Authorization Template (effective autho- rization) with right “Install Qualified Certificate” set - see [BSI-TR-03110-4-V221] , 5655 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 includes the correct generation and the termination of the SCD/SVD pair. 5660 ˆ 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 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 160 Chapter 8. TOE Summary Specification (ASE_TSS) b) RSA signature key pairs for key as detailed in RSA key support (FCS_CKM.1/RSA). 5665 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). The TOE uses the hybrid deterministic random number generator specified by FCS_RNG.1 5670 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 key pair will be deleted by the TOE (FCS_CKM.4). 5675 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 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 5680 “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). 8.1.8 Signature Creation This security function is responsible for signature creation using the SCD of the signatory. 5685 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 . Note 5690 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 the SCD of the signatory. The signatures created meet the following standards: ˆ section 7.3 in [ANSI-X9.62], 5695 ˆ 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 curves as detailed in section Elliptic curves used. 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 161 Chapter 8. TOE Summary Specification (ASE_TSS) 8.1.8.2 Signature Creation with RSA 5700 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: ˆ section 5.2.1 RSASP1 in [RSA-PKCS1-v2.2] and ˆ section 8.2.4 in [IEEE-1363] 5705 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). 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 5710 environment and sent to the TOE under the control of the Signature_Creation_SFP, see section Access Control provided by the Signature_Creation_SFP. 8.1.8.4 TOE generated hash values 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_ 5715 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 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 5720 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. 1. Last round hash values may be used if a signature for large data shall be generated as 5725 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 ˆ availability of TSF 5730 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, 3. software to be reconstructed, 5735 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. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 162 Chapter 8. TOE Summary Specification (ASE_TSS) The Test Features are disabled before the card leaves IC Manufacturer’s site. 8.1.10 Protection 5740 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): ˆ The SLC52GDA448* provides a high security initialization software concept. The self 5745 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, 5750 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. 5755 ˆ 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. 5760 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) 5765 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” 5770 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: 5775 ˆ 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 5780 ˆ access rights. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 163 Chapter 8. TOE Summary Specification (ASE_TSS) 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 5785 ˆ 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_ 5790 PHP.1 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: 5795 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 ˆ No parallel but only serial execution of commands 5800 ˆ 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 5805 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. 5810 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, 5815 ˆ Personalization Agent Key(s) and ˆ Chip Authentication Private Key and ˆ Active Authentication Private Key ˆ Signature Creation Keys ˆ the RAD 5820 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 5825 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 164 Chapter 8. TOE Summary Specification (ASE_TSS) (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 5830 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). 5835 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). 8.2 Compatibility between the Composite ST and the Platform-ST 5840 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 security properties providing protection against attack to the TOE as a whole 5845 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 5850 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- 5855 V5]. The Platform-ST is the security target of all controllers SLC52GDA448* used by this TOE as platform. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 165 Chapter 8. TOE Summary Specification (ASE_TSS) 8.2.1 Assurance requirements of the composite evaluation The Platform-ST requires 5860 ˆ Common Criteria version v3.1 part 1, part 2 and part 3 and ˆ EAL6 augmented with the component ALC_FLR.1. The Composite-ST requires: ˆ Common Criteria version 3.1, cf. [CC-Part1-V3.1], [CC-Part2-V3.1], and [CC-Part3- V3.1] and 5865 ˆ EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. Therefore the Composite-SAR is a subset of the Platform-SAR. 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- 5870 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 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 5875 in early production phases at the IC manufacturer. Therefore, they are irrelevant objectives fir the environment (IrOE) ˆ 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). 5880 Overall, the objectives for the environment of the platform are fully captured by the Composite-ST. 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 5885 Composite ST are listed in the following table. Table 8.1: Relevant Platform SFRs used as services RP_SFR-SERV RP_SFR-MECH 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 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 166 Chapter 8. TOE Summary Specification (ASE_TSS) Table 8.1 – continued from previous page RP_SFR-SERV RP_SFR-MECH Meaning Used by TOE SFR FCS_RNG.1/TRNG Quality Metric for Ran- dom Numbers FCS_RNG.1 FPT_TST.2 Subset TOE Security Testing FPT_TST.1, FPT_PHP.3 (active shield and sensors) FCS_CKM.1/EC-1 Cryptographic Key Gen- eration (EC) FCS_CKM.1/EC FCS_CKM.1/RSA-1 Cryptographic Key Gen- eration (RSA) 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/AA_SGEN_RSA, FCS_COP.1/RSA FCS_COP.1/AES- SCL-1 FCS_CKM.4/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.4/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 (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 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 167 Chapter 8. TOE Summary Specification (ASE_TSS) Table 8.2 – continued from previous page RP_SFR-MECH Meaning Used by TOE SFR 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 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 5890 the Platform-ST. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 168 Appendix A. Overview of Cryptographic Algorithms A Overview of Cryptographic Algorithms This TOE is a composite product and uses for cryptographic mechanism listed only mecha- nism 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- 5895 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 ellip- tic 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] section 7.4.1, [ISO-IEC- 14888-3] section 6.4.4, and [IEEE- 1363] section 7.2.8 (Re- fer to Crypto- graphic Primitives for the def- inition of the hash- functions) corresp. to the used ellip- tic 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 169 Appendix 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], section 5.2.2 RSAVP1, padding accord- ing to RSASSA- PSS or RSASSA- PKCS1- v1_5 (Refer to Crypto- graphic 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 Mapping1 , Chip Authentica- tion Mapping), 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 Authentication, 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.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 170 Appendix 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], section 7.2.7. (Refer to Crypto- graphic Primitives for the def- inition of the hash- functions) corresp. to the used ellip- tic 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 Authentication Active Authen- tication, RSA signature gen- eration using SHA-256 According to sec- tion 5.2.1 RSASP1 in [RSA- PKCS1- v2.2] for u = 2; padding according to ISO/IEC 9796-2 (Refer to Crypto- graphic Primitives for the def- inition of the hash- functions) 2048, 3072 and 4096 bits [ICAO- 9303- 2015] FCS_ COP.1/AA_ SGEN_RSA (see note 2 and 10) continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 171 Appendix 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 9 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 ellip- tic 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) 10 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) 11 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 12 Key Agree- ment PACE Key derivation DH using SHA-1 and SHA-256 [RSA- PKCS- 3-V1.4] (Refer to Crypto- graphic 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 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 172 Appendix 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 13 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 14 Key Agree- ment, Au- thentication Chip Authenti- cation Version 1, DH Key agreement and key derivation using SHA-1 and SHA-256 [RSA- PKCS- 3-V1.4] (Refer to Crypto- graphic 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) 15 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) 16 Integrity Secure Messag- ing, 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) 17 Trusted Channel 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 continues on next page Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 173 Appendix 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 18 Trusted Channel 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 19 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) 20 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) Notes 1. This TOE uses the Infineon libraries RSA, ECC and Toolbox (ACL52 v2.08.007), SHA 5900 (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the under- lying chip SLC52GDA448*. For the standard of implementation of “digital signature verification” using RSA or EC see [Infineon-ST-SLC52-H13]. 2. 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 under- 5905 lying 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 (HCL52 v1.12.001) and Symmetric Crypto Library (SCL52 v2.04.002) of the underlying chip SLC52GDA448*. For the “cryptographic key generation algorithm” for RSA, EC 5910 and ECDH see [Infineon-ST-SLC52-H13]. 1 Integrated Mapping is a licensed technology protected by IDEMIA under the patents FR2946818 and FR2946819 and their foreign extensions. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 174 Appendix A. Overview of Cryptographic Algorithms 4. 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 “Advanced Encryption Standard (AES)” see [Infineon-ST-SLC52-H13]. 5915 5. This TOE uses the random numbers generation provided by the underlying chip SLC52GDA448* as random source for the hybrid deterministic random number gener- ator. 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 5920 (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, 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 5925 chip SLC52GDA448*. For the standard of implementation of hash algorithms SHA-1 see [Infineon-Chip-HCL52]. 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 exponenti- 5930 ation function (CryptoRsaSignExpMask()) of the RSA crypto library is used. Function CryptoRsaSignExpMask() of RSA crypto library is used also for signing. 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 and AA are taken over from [BSI-TR-03110-3-V221] section 5935 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 Byte), CAN (6..16 Byte) and PIN_ADMIN (24..32 Byte) refer to the guidance documentation. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 175 Bibliography Bibliography 5940 [CC-Part1-V3.1] CCMB-2017-04-001, Common Criteria for Information Technology Se- curity Evaluation, Part 1: Introduction and General Model, Common Criteria Maintenance Board, Version 3.1, Revision 5, 2017-04. [CC-Part2-V3.1] CCMB-2017-04-002, Common Criteria for Information Technology Se- curity Evaluation, Part 2: Security Functional Components, Common Criteria 5945 Maintenance Board, Version 3.1, Revision 5, 2017-04. [CC-Part3-V3.1] CCMB-2017-04-003, Common Criteria for Information Technology Se- curity Evaluation, Part 3: Security Assurance Components, Common Criteria Maintenance Board, Version 3.1, Revision 5, 2017-04. [CEM-V3.1] CCMB-2017-04-004, Common Methodology for Information Technology Secu- 5950 rity Evaluation, Evaluation Methodology, Version 3.1, Revision 5, 2017-04. [CC-CompositeEval-Smart-Cards] Composite product evaluation for Smart Cards and simi- lar devices, September 2007, Version 1.0 Revision 1, CCDB-2007-09-001. [BSI-AIS2031-RNG-CLASSES-V2] AIS 20 / AIS 31, A proposal for: Functionality classes for random number generators, Bundesamt für Sicherheit in der Informationstechnik 5955 (BSI), Version 2.0, 2011-09-18. [BSI-AIS36-V5] AIS 36, Anwendungshinweise und Interpretationen zum Schema, AIS36: Kompositionsevaluierung, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 5, 2017-03-15. [BSI-AIS31-V3] AIS 31, Anwendungshinweise und Interpretationen zum Schema, AIS31: 5960 Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufall- szahlengeneratoren, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 3, 2013-05-15. [BSI-CC-PP-0055-110] Common Criteria Protection Profile Machine Readable Travel Doc- ument with “ICAO Application” Basic Access Control, BSI-CC-PP-0055 Version 5965 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 CEN/ISSS, EN 419211-2:2013, 2013-07-17. [BSI-CC-PP-0071-2012-MA-01] Protection profiles for Secure signature creation device - 5970 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 [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 5975 with signature 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- 0056-V2-2012-MA-02 for Common Criteria Protection Profile Machine Readable Travel Document with “ICAO Application” Extended Access Control with PACE 5980 (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 Inspection 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- 5985 07-22. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 176 Bibliography [BSI-CC-PP-0084-2014] Security IC Platform Protection Profile with Augmentation Pack- ages, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 1.0, 2014-01-13. [BSI-CC-PP-0086-2015] Common Criteria Protection Profile / Electronic document imple- 5990 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 5995 BAC/PACEv2 and EACv1, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.20, 2015-02-26. [BSI-TR-03110-2-V221] Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token ü Part 2 - Protocols for electronic IDentification, Authentication and trust Services (eIDAS), Bundesamt 6000 für Sicherheit in der Informationstechnik (BSI), Version 2.21, 2016-12-21. [BSI-TR-03110-3-V221] BSI, Technical Guideline TR-03110, Advanced Security Mecha- nisms 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. 6005 [BSI-TR-03110-4-V221] BSI, Technical Guideline TR-03110, Advanced Security Mecha- nisms for Machine Readable Travel Documents and eIDAS Token - Part 4: Applications and Document Profiles, Bundesamt für Sicherheit in der Informa- tionstechnik (BSI), Version 2.21, 21. December 2016 [BSI-TR-03111-V210-ECC] TR-03111, Technical Guideline TR-03111: Elliptic Curve Cryp- 6010 tography, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.10, 2018-06-01. [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- 6015 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 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Official Journal of the 6020 European Communities, L257:73 - 114, 2014-08-28. [ICAO-9303-2015] ICAO Doc 9303, Machine Readable Travel Documents - Machine Read- able Passports, (this includes the latest supplemental for ICAO Doc 9303 which also should be considered), International Civil Aviation Organization (ICAO), Seventh Edition, 2015. 6025 [ICAO-TR-110] ICAO SAC v1.1, Machine Readable Travel Documents, TECHNICAL RE- PORT, Supplemental Access Control for Machine Readable Travel Documents, International Civil Aviation Organization (ICAO), Version 1.1, 2014-04-15. [NIST-FIPS-180-4] FIPS PUB 180-4, Secure Hash Standard (SHS), Information Technology Laboratory, National Institute of Standards and Technology (NIST), August 2015. 6030 [NIST-FIPS-186-4] FIPS PUB 186-4, DIGITAL SIGNATURE STANDARD (DSS), Information Technology Laboratory, National Institute of Standards and Technology (NIST), 2013-07. [NIST-FIPS-197] FIPS PUB 197, ADVANCED ENCRYPTION STANDARD (AES), Information Technology Laboratory, National Institute of Standards and Technology (NIST), 6035 2001-11-26 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 177 Bibliography [ISO-IEC-7816-part-2] ISO/IEC 7816: Identification cards - Integrated circuit(s) cards with contacts - 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 6040 cards – Part 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. [ISO-IEC-9797-1-2011] ISO/IEC 9797-1:2011, Information technology – Security tech- 6045 niques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher, 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 6050 Modes of Operation: Methods and Techniques, National Institute of Standards and 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. 6055 [NIST-SP800-90A] NIST Special Publication 800-90A, Recommendation Random Number Generation Using Deterministic Random Bit Generators, National Institute of Standards 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 Laborato- 6060 ries Technical Note, Version 1.4, Revised, 1993-11-01. [Infineon-ST-SLC52-H13] Security Target 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 with Options, Common Criteria EAL6 augmented / EAL6+, Infineon, 6065 Version 1.9, 2021-05-18. [Infineon-Chip-HW-Ref-16bit-V01] 16-bit Security Controller Family - V01, Hardware Ref- erence 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. 6070 [ANSI-X9.62] American National Standard X9.62-2005, Public Key Cryptography for the Fi- 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 Financial Services Industry: Key Agreement and Key Transport Using Elliptic 6075 Curve Cryptography, ANSI, 2001-11-20. [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 - 6080 Key management – Part 3: Mechanisms using asymmetric techniques, ISO/IEC, 2015-08. [IEEE-1363] IEEE 1363A-2004, IEEE Standard Specifications for Public-Key Cryptography, IEEE Standards Board, 2004-07-22. Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 178 Bibliography [SOG-IS-Crypto-Catalog-V1.2] SOG-IS Crypto Evaluation Scheme - Agreed Cryptographic 6085 Mechanisms, Version 1.2, 2020-01. [DIR-1999-93-EC] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999 on a Community framework for electronic signatures. Official Journal of the European Communities, L13:12 - 20, 2000-01- 19. 6090 [Atos-V60-ADM] Administrator Guidance ‘CardOS V6.0 ID R1.0’ and ‘CardOS V6.0 ID R1.0 (BAC)’, Atos Information Technology GmbH [Atos-V60-USR] User Guidance ‘CardOS V6.0 ID R1.0’ and ‘CardOS V6.0 ID R1.0 (BAC)’, Atos Information Technology GmbH Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 179 Index Index A 6095 Accessibility to the TOE functions and data only for authorised subjects, 18 Administrator, 21 Advanced Inspection Procedure, 3 6100 AIP, 3 Attacker, 20 Authenticity of the travel document’s chip, 18 B 6105 BAC, 2 Basic Inspection System with PACE, 19 BIS-BAC, 2 BIS-PACE, 19 C 6110 CAN, 2 CfPOE, 165 Common Criteria, 3 Country Signing Certification Authority, 20 6115 Country Verifying Certification Authority, 21 CSCA, 20 CVCA, 21 D 6120 Document Signer, 20 Document Verifier, 21 DS, 20 DTBS, 2 DTBS, DTBS/R, 18 6125 DV, 21 E EAC, 2 EIS, 21 Evaluation Assurance Level, 3 6130 Extended Inspection System, 21 G Genuineness of the TOE, 19 I Inspection system, 21 6135 IrOE, 165 IS, 21 L Logical travel document sensitive User Data, 18 6140 M Manufacturer, 20 MRTD, 2 MRZ, 2 P 6145 PACE, 2 Personalisation Agent, 20 PIN, 2 PP0056 FCS_CKM.1; CA_EC, 65 6150 FCS_CKM.1; CA_RSA, 66 FCS_CKM.4; CA Session Keys, 71 FCS_COP.1; AA_SGEN_EC, 80 FCS_COP.1; AA_SGEN_RSA, 81 FCS_COP.1; CA_ENC, 75 6155 FCS_COP.1; CA_MAC, 76 FCS_COP.1; SIG_VER_EC, 78 FCS_COP.1; SIG_VER_RSA, 79 FDP_ACC.1; TRM, 95 FDP_ACF.1; TRM, 95 6160 PP0059 FCS_CKM.1; SCD/SVD EC KeyPair, 69 FCS_CKM.1; SCD/SVD RSA KeyPair, 70 FCS_CKM.4; SCD, 71 FCS_COP.1; AES_MAC, 74 6165 FCS_COP.1; EC digital signature creation, 71 FCS_COP.1; RSA digital signature creation, 72 FCS_COP.1; SHA, 73 6170 FDP_RIP.1, 97 PP0068 FAU_SAS.1, 117 FCS_CKM.1; DH_PACE_EC, 67 FCS_CKM.1; DH_PACE_RSA, 68 6175 FCS_CKM.4; PACE Session Keys, 71 FCS_COP.1; PACE_ENC, 76 FCS_COP.1; PACE_MAC, 77 FDP_ACC.1; TRM, 95 FDP_ACF.1; TRM, 95 6180 FDP_RIP.1, 97 FDP_UCT.1; TRM, 98 FDP_UIT.1; TRM, 98 Protection Profile, 3 PTRNG, 2 6185 Q QES, 2 R RAD, 2 Reference Authentication Data, 3 6190 S SCD, 18 Security Target, 3 SgOE, 165 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 180 Index Signatory, 21 6195 Signature Creation Data, 3 Signature Verification Data, 3 SIP, 3 Standard Inspection Procedure, 3 SVD, 2, 18 6200 T Target of Evaluation, 3 Terminal, 19 TOE, 2 TOE internal non-secret cryptographic 6205 material, 19 TOE internal secret cryptographic keys, 19 TOE Security Functions, 3 travel document communication 6210 establishment authorisation data, 19 travel document holder, 19 travel document presenter, 19 travel document tracing data, 18 6215 traveller, 19 U User, 21 user data stored on the TOE, 18 user data transferred between the TOE 6220 and the terminal connected, 18 V VAD, 2 Verification Authentication Data, 3 Security Target ’CardOS V6.0 ID R1.0’ Copyright © Atos Information Technology GmbH. All rights reserved. PUBLIC 181