All Information and Intellectual property rights reserved at ©IDEMIA 2023 IDmove v5 on SCR404U in BAC configuration with AA and/or CA in option Public Security Target ISSUE: 6.0 2/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 DOCUMENT REVISION HISTORY Issue Date Author Purpose 1 25/10/2023 IDEMIA Creation of the document 2 30/10/2023 IDEMIA Update with PACE-CAM product identification 3 08/11/2023 IDEMIA Issue 4 13/11/2023 IDEMIA Issue for publication 5 20/11/2023 IDEMIA Issue with AGD_PRE Ed4. 6 21/11/2023 IDEMIA Issue with AGD_PRE Ed5. 3/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 TABLE OF CONTENTS 1 GENERAL........................................................................................................................................................ 10 1.1 INTRODUCTION........................................................................................................................................... 10 1.2 PRODUCT OVERVIEW.................................................................................................................................. 10 2 ST INTRODUCTION ........................................................................................................................................ 11 2.1 ST REFERENCE AND TOE REFERENCE........................................................................................................ 11 2.1.1 ST reference.........................................................................................................................................................11 2.1.2 TOE reference......................................................................................................................................................11 2.1.3 IC identification ...................................................................................................................................................11 2.1.4 TOE Delivered Parts............................................................................................................................................12 2.2 TOE OVERVIEW ......................................................................................................................................... 13 2.2.1 Usage and major security features of the TOE ....................................................................................................13 2.2.2 TOE type..............................................................................................................................................................15 2.2.3 TOE life cycle......................................................................................................................................................16 2.2.3.1 Life cycle overview....................................................................................................................... 16 2.2.3.2 Life cycle phases ......................................................................................................................... 18 2.2.4 Required non-TOE hardware/Software/firmware................................................................................................20 2.3 TOE DESCRIPTION..................................................................................................................................... 21 2.3.1 TOE Architecture.................................................................................................................................................21 2.3.2 Integrated Circuit .................................................................................................................................................22 2.3.3 Low layer.............................................................................................................................................................22 2.3.3.1 IDEMIA Basic Input/Output System (BIOS) ................................................................................ 22 2.3.3.2 IDEMIA Cryptographic library (Crypto)....................................................................................... 22 2.3.4 Platform layer ......................................................................................................................................................22 2.3.4.1 Services ....................................................................................................................................... 22 2.3.5 Authentication Protocols......................................................................................................................................23 2.3.5.1 Terminal Authentication (TA)....................................................................................................... 23 2.3.5.2 Chip Authentication (CA)............................................................................................................. 23 2.3.5.3 Password Authenticated Connection Establishment (PACE v2) ................................................ 23 2.3.5.4 Basic Access Control (BAC)........................................................................................................ 23 2.3.5.5 Active Authentication (AA)........................................................................................................... 24 2.3.6 Application layer..................................................................................................................................................24 2.3.6.1 Start-Up and Applications Manager (Boot)................................................................................. 24 2.3.6.2 Application Creation Engine (ACRE)........................................................................................... 24 2.3.6.3 Resident Application (RA) ........................................................................................................... 24 2.3.6.4 Machine Readable Travel Document (MRTD) ............................................................................ 24 3 CONFORMANCE CLAIMS.............................................................................................................................. 25 3.1 COMMON CRITERIA CONFORMANCE ............................................................................................................ 25 3.2 PROTECTION PROFILE CONFORMANCE ........................................................................................................ 26 3.2.1 Overview..............................................................................................................................................................26 3.2.2 Assumptions.........................................................................................................................................................26 3.2.3 Threats .................................................................................................................................................................27 3.2.4 Organizational Security Policies..........................................................................................................................27 4/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 3.2.5 Security Objectives..............................................................................................................................................28 4 SECURITY PROBLEM DEFINITION............................................................................................................... 29 4.1 ASSETS ..................................................................................................................................................... 29 4.1.1 Logical MRTD data.............................................................................................................................................29 4.1.1.1 Personal Data .............................................................................................................................. 29 4.1.1.2 Biometric Data ............................................................................................................................. 29 4.1.1.3 EF.COM....................................................................................................................................... 29 4.1.1.4 EF.SOD........................................................................................................................................ 29 4.1.1.5 Chip Authentication Public Key (CA_PK) .................................................................................... 29 4.1.1.6 Chip Authentication Private Key (CA_SK)................................................................................... 30 4.1.1.7 Active Authentication Public Key (AA_PK) .................................................................................. 30 4.1.1.8 Active Authentication Private Key (AA_SK)................................................................................. 30 4.1.1.9 CPLC ........................................................................................................................................... 30 4.1.1.10 TOE_ID .................................................................................................................................... 30 4.1.1.11 Pre-personalization Agent keys (Pre-perso_K) ....................................................................... 30 4.1.1.12 Personalization Agent keys (Perso_K) .................................................................................... 30 4.1.1.13 BAC keys (BAC_K).................................................................................................................. 30 4.1.1.14 Secure Messaging session keys (Session_K)......................................................................... 30 4.1.1.15 TOE Life Cycle State (LCS)..................................................................................................... 30 4.1.1.16 Configuration Data................................................................................................................... 30 4.1.2 Assets related to Update Mechanism ...................................................................................................................30 4.1.2.1 Secret Cryptographic Update Keys ............................................................................................. 30 4.1.2.2 Meta-Data .................................................................................................................................... 31 4.1.2.3 Update Data................................................................................................................................. 31 4.1.2.4 Update Log Data.......................................................................................................................... 31 4.1.2.5 Update Package .......................................................................................................................... 31 4.1.2.6 Update Package Verification Status ............................................................................................ 31 4.1.2.7 Version Information...................................................................................................................... 31 4.1.2.8 Load Secure Key (LSK) and Diversified LSK (DIV_LSK, DIV2_LSK) ......................................... 31 4.1.3 Authenticity of the MRTD’s chip ........................................................................................................................32 4.2 SUBJECTS ................................................................................................................................................. 33 4.2.1 Overview..............................................................................................................................................................33 4.2.2 IC manufacturer ...................................................................................................................................................33 4.2.3 MRTD packaging responsible .............................................................................................................................33 4.2.4 Embedded software loading responsible..............................................................................................................33 4.2.5 Pre-personalization Agent....................................................................................................................................33 4.2.6 Personalization Agent..........................................................................................................................................33 4.2.7 Terminal...............................................................................................................................................................34 4.2.8 Inspection system (IS)..........................................................................................................................................34 4.2.9 MRTD Holder......................................................................................................................................................34 4.2.10 Traveler ...........................................................................................................................................................34 4.2.11 Attacker ...........................................................................................................................................................34 5/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.3 ASSUMPTIONS ........................................................................................................................................... 35 4.3.1 A.MRTD_Manufact “MRTD manufacturing on steps 4 to 6” ..........................................................................35 4.3.2 A.MRTD_Delivery “MRTD delivery during steps 4 to 6” ................................................................................35 4.3.3 A.Pers_Agent “Personalization of the MRTD’s chip”.......................................................................................35 4.3.4 A.Insp_Sys “Inspection Systems for global interoperability” ............................................................................35 4.3.5 A.BAC-Keys “Cryptographic quality of Basic Access Control Keys” ...............................................................35 4.3.6 A.Insp_Sys_Chip_Auth “Inspection Systems for global interoperability on chip authenticity” ......................35 4.3.7 A.Signature_PKI “PKI for Passive Authentication”.........................................................................................36 4.4 THREATS ................................................................................................................................................... 37 4.4.1 T.Chip_ID “Identification of MRTD’s chip” .....................................................................................................37 4.4.2 T.Skimming “Skimming the logical MRTD” .....................................................................................................37 4.4.3 T.Eavesdropping “Eavesdropping to the communication between TOE and inspection system”.....................37 4.4.4 T.Forgery “Forgery of data on MRTD’s chip”..................................................................................................37 4.4.5 T.Abuse-Func “Abuse of Functionality”............................................................................................................38 4.4.6 T.Information_Leakage “Information Leakage from MRTD’s chip”...............................................................38 4.4.7 T.Phys-Tamper “Physical Tampering”.............................................................................................................38 4.4.8 T.Malfunction “Malfunction due to Environmental Stress”..............................................................................39 4.4.9 T.Configuration “Tampering attempt of the TOE during preparation”............................................................39 4.4.10 T.Counterfeit “MRTD’s chip”.......................................................................................................................39 4.4.11 T.FaTSF “Faulty TSF” .................................................................................................................................39 4.4.12 T.UaU “Unauthorized Update”....................................................................................................................40 4.5 ORGANISATIONAL SECURITY POLICIES ........................................................................................................ 41 4.5.1 P.Manufact “Manufacturing of the MRTD’s chip”............................................................................................41 4.5.2 P.Personalization “Personalization of the MRTD by issuing State or Organization only”...............................41 4.5.3 P.Personal_Data “Personal data protection policy” .........................................................................................41 4.5.4 OSP from PP Module for Update mechanism.................................................................................................41 4.5.4.1 P.Code_Confidentiality ................................................................................................................. 41 4.5.4.2 P.Secure_Environment................................................................................................................. 41 4.5.4.3 P.Eligible_Terminals_Only............................................................................................................ 41 5 SECURITY OBJECTIVES ............................................................................................................................... 42 5.1 SECURITY OBJECTIVES FOR THE TOE ......................................................................................................... 42 5.1.1 OT.AC_Pers “Access Control for Personalization of logical MRTD” ..............................................................42 5.1.2 OT.Data_Int “Integrity of personal data” .........................................................................................................42 5.1.3 OT.Data_Conf “Confidentiality of personal data”............................................................................................42 5.1.4 OT.Identification “Identification and Authentication of the TOE” ...................................................................42 5.1.5 OT.Prot_Abuse-Func “Protection against Abuse of Functionality”.................................................................42 5.1.6 OT.Prot_Inf_Leak “Protection against Information Leakage” ........................................................................43 5.1.7 OT.Prot_Phys-Tamper “Protection against Physical Tampering”..................................................................43 5.1.8 OT.Prot_Malfunction “Protection against Malfunctions” ...............................................................................43 5.1.9 OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” ...........................................................................43 5.1.10 OT.Configuration “Protection of the TOE preparation”..............................................................................43 5.1.11 OT.TOE_Identification “Secure identification of the TOE” ........................................................................43 6/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.1.12 OT.Update_Mechanism “TOE Update Mechanism”.................................................................................44 5.1.13 OT.Enc_Sign_Update “Encrypted-then-signed Update Packages”..........................................................44 5.1.14 OT.Update_Terminal_Auth “Updates only by authenticated Update Terminals” .................................44 5.1.15 OT.Attack_Detection “Detection of Attacks on the TOE using the Update Mechanism” ......................44 5.1.16 OT.Key_Secrecy “Key Secrecy of Cryptographic Update Keys” .............................................................44 5.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT...................................................................... 45 5.2.1 Issuing State or Organization...............................................................................................................................45 5.2.1.1 OE.MRTD_Manufact “Protection of the MRTD Manufacturing” ................................................. 45 5.2.1.2 OE.MRTD_Delivery “Protection of the MRTD delivery” ............................................................. 45 5.2.1.3 OE.Personalization “Personalization of logical MRTD” ............................................................. 45 5.2.1.4 OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature”........................................ 45 5.2.1.5 OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys” ....................................... 46 5.2.1.6 OE.Auth_MRTD “MRTD Authentication Key”............................................................................. 46 5.2.2 Receiving State or Organization ..........................................................................................................................46 5.2.2.1 OE.Exam_MRTD “Examination of the MRTD passport book” .................................................... 46 5.2.2.2 OE.Exam_Chip_Auth “Examination of the chip authenticity” .................................................... 46 5.2.2.3 OE.Passive_Auth_Verif “Verification by Passive Authentication” ............................................. 46 5.2.2.4 OE.Prot_Logical_MRTD “Protection of data from the logical MRTD”........................................ 46 5.2.3 OEs from PP Module for Update mechanism......................................................................................................46 5.2.3.1 OE.Secure_Environment........................................................................................................... 46 5.2.3.2 OE.Eligible_Terminals_Only..................................................................................................... 47 5.2.4 Security Objectives for the Development and Production Environment .............................................................47 5.2.4.1 OE.Code_Confidentiality........................................................................................................... 47 5.3 SECURITY OBJECTIVES RATIONALE.............................................................................................................. 49 5.3.1 Introduction..........................................................................................................................................................49 5.3.2 Rationales for Assumptions .................................................................................................................................50 5.3.2.1 A.MRTD_Manufact ...................................................................................................................... 50 5.3.2.2 A.MRTD_Delivery ........................................................................................................................ 50 5.3.2.3 A.Pers_Agent............................................................................................................................... 50 5.3.2.4 A.Insp_Sys................................................................................................................................... 50 5.3.2.5 A.Insp_Sys_Chip_Auth................................................................................................................ 50 5.3.2.6 A.BAC-Keys................................................................................................................................. 50 5.3.2.7 A.Signature_PKI .......................................................................................................................... 50 5.3.3 Rationales for Threats..........................................................................................................................................51 5.3.3.1 T.Chip_ID..................................................................................................................................... 51 5.3.3.2 T.Skimming and T.Eavesdropping............................................................................................... 51 5.3.3.3 T.Forgery ..................................................................................................................................... 51 5.3.3.4 T.Abuse-Func .............................................................................................................................. 51 5.3.3.5 T.Information_Leakage, T.Phys-Tamper and T.Malfunction ....................................................... 51 5.3.3.6 T.Configuration ............................................................................................................................ 51 5.3.3.7 T.Counterfeit ................................................................................................................................ 52 5.3.3.8 T.FaTSF....................................................................................................................................... 52 7/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.3.3.9 T.UaU........................................................................................................................................... 52 5.3.4 Rationales for Organisational Security Policies...................................................................................................53 5.3.4.1 P.Manufact................................................................................................................................... 53 5.3.4.2 P.Personalization......................................................................................................................... 53 5.3.4.3 P.Personal_Data.......................................................................................................................... 53 5.3.4.4 The organizational security policies for Update Mechanism ....................................................... 53 6 EXTENDED COMPONENTS DEFINITION ..................................................................................................... 54 6.1 EXTENDED COMPONENTS DEFINITION .......................................................................................................... 54 6.1.1 Definition of the Family FAU_SAS ....................................................................................................................54 6.1.2 Definition of the Family FCS_RND ....................................................................................................................55 6.1.3 Definition of the Family FMT_LIM ....................................................................................................................56 6.1.4 Definition of the Family FPT_EMS.....................................................................................................................57 6.1.5 Definition of the Family FIA_API.......................................................................................................................58 7 SECURITY REQUIREMENTS ......................................................................................................................... 59 7.1 SECURITY FUNCTIONAL REQUIREMENTS ...................................................................................................... 59 7.1.1 Class FAU “Security Audit”................................................................................................................................62 7.1.1.1 FAU_SAS.1 “Audit Storage” ........................................................................................................ 62 7.1.2 Class FCS “Cryptographic Support” ..................................................................................................................62 7.1.2.1 FCS_CKM.1 “Cryptographic key generation” .............................................................................. 62 7.1.2.2 FCS_CKM.4 “Cryptographic key destruction” ............................................................................. 63 7.1.2.3 FCS_COP.1 “Cryptographic operation”....................................................................................... 64 7.1.2.4 FCS_RND.1 “Quality metric for random numbers”...................................................................... 66 7.1.3 Class FIA “Identification and Authentication” ...................................................................................................67 7.1.3.1 FIA_UID.1 “Timing of identification”............................................................................................. 67 7.1.3.2 FIA_UAU.1 “Timing of authentication”......................................................................................... 67 7.1.3.3 FIA_UAU.4 “Single-use authentication mechanisms” ................................................................. 68 7.1.3.4 FIA_UAU.5 “Multiple authentication mechanisms”...................................................................... 69 7.1.3.5 FIA_UAU.6 “Re-authenticating”................................................................................................... 70 7.1.3.6 FIA_AFL.1 “Authentication failure handling”................................................................................ 70 7.1.3.7 FIA_API.1 “Authentication Proof of Identity”................................................................................ 71 7.1.4 Class FDP “User Data Protection”.....................................................................................................................71 7.1.4.1 FDP_ACC.1 “Subset access control” .......................................................................................... 71 7.1.4.2 FDP_ACF.1 “Basic Security attribute based access control” ...................................................... 72 7.1.4.3 FDP_UCT.1 “Basic data exchange confidentiality” ..................................................................... 75 7.1.4.4 FDP_UIT.1 “Data exchange integrity” ......................................................................................... 76 7.1.4.5 FDP_ITC.1 “Import of user data without security attributes” ....................................................... 77 7.1.4.6 FDP_RIP.1 “Subset residual information protection”................................................................... 77 7.1.4.7 FDP_IFC.1/UPD “Subset information flow control....................................................................... 77 7.1.4.8 FDP_IFF.1/UPD “Simple security attributes”............................................................................... 78 7.1.5 Class FMT “Security Management” ...................................................................................................................79 7.1.5.1 FMT_MOF “Management of functions in TSF”............................................................................ 79 7.1.5.2 FMT_SMF.1 “Specification of Management Functions” .............................................................. 80 8/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.5.3 FMT_SMR.1 “Security roles” ....................................................................................................... 80 7.1.5.4 FMT_LIM.1 “Limited capabilities”................................................................................................. 80 7.1.5.5 FMT_LIM.2 “Limited availability”.................................................................................................. 81 7.1.5.6 FMT_MTD.1 “Management of TSF data” .................................................................................... 81 7.1.6 Class FPT “Protection of the Security Functions”..............................................................................................82 7.1.6.1 FPT_EMS.1 “TOE Emanation” .................................................................................................... 82 7.1.6.2 FPT_FLS.1 “Failure with preservation of secure state”............................................................... 83 7.1.6.3 FPT_TST.1 “TSF testing” ............................................................................................................ 83 7.1.6.4 FPT_PHP.3 “Resistance to physical attack”................................................................................ 84 7.1.7 Class FTP “Trusted path/channels” .....................................................................................................................85 7.1.7.1 FTP_ITC.1 “Inter-TSF trusted channel”....................................................................................... 85 7.2 SECURITY ASSURANCE REQUIREMENTS....................................................................................................... 86 7.2.1 EAL rationale.......................................................................................................................................................86 7.2.2 EAL augmentation rationale................................................................................................................................86 7.2.2.1 ALC_DVS.2 "Sufficiency of security measures".......................................................................... 86 7.2.2.2 ADV_FSP.5 “Complete semi-formal functional specification with additional error information”.. 86 7.2.2.3 ADV_INT.2 “Well-structured internals” ........................................................................................ 86 7.2.2.4 ADV_TDS.5 “Semiformal modular design”.................................................................................. 86 7.2.2.5 ALC_CMS.5 “Development tools CM coverage” ......................................................................... 86 7.2.2.6 ALC_TAT.2 “Compliance with implementation standards”.......................................................... 87 7.2.2.7 ATE_DPT.3 “Testing: modular design”........................................................................................ 87 7.2.3 Dependencies.......................................................................................................................................................87 7.3 SECURITY REQUIREMENTS RATIONALE......................................................................................................... 89 7.3.1 Security Functional Requirements Rationale.......................................................................................................89 7.3.1.1 Overview...................................................................................................................................... 89 7.3.1.2 OT.AC_Pers................................................................................................................................. 91 7.3.1.3 OT.Data_Int ................................................................................................................................. 93 7.3.1.4 OT.Data_Conf.............................................................................................................................. 94 7.3.1.5 OT.Identification........................................................................................................................... 95 7.3.1.6 OT.Prot_Abuse-Func................................................................................................................... 95 7.3.1.7 OT.Prot_Inf_Leak ........................................................................................................................ 95 7.3.1.8 OT.Prot_Phys-Tamper................................................................................................................. 95 7.3.1.9 OT.Prot_Malfunction.................................................................................................................... 95 7.3.1.10 OT.Chip_Auth_Proof ............................................................................................................... 95 7.3.1.11 OT.Configuration...................................................................................................................... 96 7.3.1.12 OT.TOE_Identification ............................................................................................................. 97 7.3.1.13 OT.Update_Mechanism........................................................................................................... 97 7.3.1.14 OT.Enc_Sign_Update.............................................................................................................. 97 7.3.1.15 OT.Update_Terminal_Auth...................................................................................................... 98 7.3.1.16 OT.Attack_Detection................................................................................................................ 98 7.3.1.17 OT.Key_Secrecy...................................................................................................................... 98 7.3.2 Dependency Rationale .........................................................................................................................................99 9/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.3.2.1 Overview...................................................................................................................................... 99 7.3.2.2 Rationale for the exclusion of dependencies............................................................................. 102 8 TOE SUMMARY SPECIFICATION................................................................................................................ 103 8.1 TOE SUMMARY SPECIFICATION ................................................................................................................. 103 8.1.1 Overview............................................................................................................................................................103 8.1.2 Access Control in Reading.................................................................................................................................103 8.1.3 Access Control in Writing .................................................................................................................................104 8.1.4 Active Authentication........................................................................................................................................104 8.1.5 Basic Access Control .........................................................................................................................................104 8.1.6 Chip Authentication...........................................................................................................................................104 8.1.7 MRTD Personalization ......................................................................................................................................104 8.1.8 Physical Protection ............................................................................................................................................105 8.1.9 MRTD Pre-personalization................................................................................................................................105 8.1.10 Safe State Management .................................................................................................................................105 8.1.11 Secure Messaging..........................................................................................................................................105 8.1.12 Self Tests .......................................................................................................................................................105 8.1.13 Update Mechanism........................................................................................................................................105 8.2 SFR AND TSF ......................................................................................................................................... 107 9 GLOSSARY AND ACRONYMS .................................................................................................................... 110 9.1 GLOSSARY............................................................................................................................................... 110 9.2 ACRONYMS.............................................................................................................................................. 114 10 LITERATURE ............................................................................................................................................. 115 10/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 1 GENERAL 1.1 Introduction This security target describes the security needs induced by the “IDmove v5 on SCR404U” in BAC configuration with AA and/or CA in option product. The objectives of this Security Target are to: • describe the Target of Evaluation (TOE), its life cycle and to position it in the smart card life cycle, • describe the security environment of the TOE including the assets to be protected and the threats to be countered by the TOE and by the operational environment during the platform active phases, • describe the security objectives of the TOE and its supported environment in terms of integrity and confidentiality of sensitive information. It includes protection of the TOE (and its documentation) during the product active phases, • specify the security requirements including the TOE functional requirements, the TOE assurance requirements and the security requirements for the environment, • describe the summary of the TOE specification including a description of the security functions and assurance measures that meet the TOE security requirements, • present evidence that this ST is a complete and cohesive set of requirements that the TOE provides on an effective set of IT security countermeasures within the security environment, and that the TOE summary specification addresses the requirements. 1.2 Productoverview IDmove v5 is a multi-configuration MRTD product. It provides four configurations, which are: • IDmove v5 on SCR404U in BAC configuration with AA and/or CA in option, • IDmove v5 on SCR404U in EAC configuration with AA in option, • IDmove v5 on SCR404U in EAC with PACE configuration with AA in option, • IDmove v5 on SCR404U in PACE configuration with AA and/or CA in option. IDmove v5 on SCR404U Operating System is embedded in the component identified in [IC_ST] manufactured by IDEMIA. Mutatis mutandis, the product may also be used as an ISO driving license, compliant to ISO/IEC 18013 or ISO/IEC TR 19446 supporting BAP-1 (the same protocol as BAC but used in the context of driving license), AA and CA, as both applications (MRTD and IDL) share the same protocols and data structure organization. Therefore, in the rest of the document, the word “MRTD” MAY be understood either as a MRTD in the sense of ICAO, or a driving license compliant to ISO/IEC 18013 or ISO/IEC TR 19446 depending on the targeted usage envisioned by the issuer. 11/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2 ST INTRODUCTION 2.1 ST reference andTOE reference 2.1.1 ST reference Title IDmove v5 on SCR404U in BAC configuration with AA and/or CA in option – Public Security Target Version 6.0 Authors IDEMIA Publication date 21/11/2023 CC version 3.1 revision 5 EAL EAL4 augmented with: • ADV_IMP.2, • ADV_FSP.5, • ADV_INT.3, • ADV_TDS.5, • ALC_CMC.5, • ALC_TAT.3, • ALC_FLR.3, • ALC_DVS.2, • ATE_COV.3, • ATE_FUN.2 • ATE_DPT.3. PP See [PP_BAC] Table 1 - ST reference 2.1.2 TOE reference Developer name IDEMIA Product name IDmove v5 on SCR404U M02 TOE name IDmove v5 on SCR404U in BAC configuration with AA and/or CA in option TOE identification Integrated Circuit See Table 3 - IC identification Embedded Software Operating System Commercial Version SAAAAR: 098912 Operating System Unique Identifier: B7BC0108 with PACE-CAM or E48C0108 without PACE-CAM User Guidance documentation Preparative Documentation: FQR 110 A110 Ed5 and FQR 110 A17E Ed1 Operational Documentation: FQR 110 A111 Ed3 Table 2 - TOE reference 2.1.3 IC identification IC certificates See [IC_CERT] IC public Security Target See [IC_ST] Table 3 - IC identification 12/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.1.4 TOE Delivered Parts Part of the TOE Format Delivery Method Comment Integrated Circuit See [IC_ST] Embedded Software Specific file containing APDUs allowing the embedded software loading. Encrypted file in email The file contains all commands to be used to load the embedded software. These commands are already formatted to ensure the integrity and the confidentiality of the embedded software. Optional Updated Code Specific file containing APDUs allowing the additional code loading Encrypted file in email If necessary optional Updated package can be delivered. The file contains all updated packages for the Embedded software. The embedded software Update mechanism ensures the integrity and the confidentiality of the additional code. The updated code need to be Common Criteria certified. Final TOE ID1 cards, wafers, modules, inlays, ecovers, eDatapage or passeports Secure transport Customer can ask for rising of the security of the delivery method. User Guidance Documentation Personalized pdf Encrypted file in email - Table 4- TOE delivery parts 13/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.2 TOE overview 2.2.1 Usage and major security features of the TOE A State or Organization issues MRTDs to be used by the holder for international travel. The traveler presents a MRTD to the inspection system to prove his or her identity. The MRTD in context of this Security Target contains (i) visual (eye readable) biographical data and portrait of the holder, (ii) a separate data summary (MRZ data) for visual and machine reading using OCR methods in the Machine readable zone (MRZ) and (iii) data elements on the MRTD’s chip according to LDS for contactless machine reading. The authentication of the traveler is based on (i) the possession of a valid MRTD personalized for a holder with the claimed identity as given on the biographical data page and (ii) optional biometrics using the reference data stored in the MRTD. The issuing State or Organization ensures the authenticity of the data of genuine MRTD’s. The receiving State trusts a genuine MRTD of an issuing State or Organization. The MRTD is viewed as unit of (a) the physical MRTD as travel document in form of paper, plastic and chip. It presents visual readable data including (but not limited to) personal data of the MRTD holder (1) the biographical data on the biographical data page of the passport book, (2) the printed data in the Machine-Readable Zone (MRZ) and (3) the printed portrait. (b) the logical MRTD as data of the MRTD holder stored according to the Logical Data Structure [ICAO_9303] as specified by ICAO on the contactless integrated circuit. It presents contactless readable data including (but not limited to) personal data of the MRTD holder (1) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1), (2) the digitized portraits (EF.DG2), (3) the optional biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both (4) the other data according to LDS (EF.DG5 to EF.DG16) and (5) the Document security object. The issuing State or Organization implements security features of the MRTD to maintain the authenticity and integrity of the MRTD and their data. The MRTD as the passport book and the MRTD’s chip is uniquely identified by the Document Number. The physical MRTD is protected by physical security measures (e.g. watermark on paper, security printing), logical (e.g. authentication keys of the MRTD’s chip) and organizational security measures (e.g. control of materials, personalization procedures) [ICAO_9303]. These security measures include the binding of the MRTD’s chip to the passport book. The logical MRTD is protected in authenticity and integrity by a digital signature created by the document signer acting for the issuing State or Organization and the security features of the MRTD’s chip. The ICAO defines the baseline security methods Passive Authentication and the optional advanced security methods Basic Access Control to the logical MRTD, Active Authentication of the MRTD’s chip, Extended Access Control to and the Data Encryption of additional sensitive biometrics as optional security measure in the ‘ICAO Doc 9303’ [ICAO_9303]. The Passive Authentication Mechanism and the Data Encryption are performed completely and independently on the TOE by the TOE environment. The Basic Access Control is a security feature which is mandatory supported by the TOE. The inspection system (i) reads optically the MRTD, (ii) authenticates itself as inspection system by means of Document Basic Access Keys. After successful authentication of the inspection system the MRTD’s chip provides read access to the logical MRTD by means of private communication (secure messaging) with this inspection system [ICAO_9303]. 14/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 As defined in [ICAO_9303] in part 11 §6.1, Active Authentication authenticates the contactless IC by signing a challenge sent by the IFD (inspection system) with a private key known only to the IC. For this purpose the contactless IC contains its own Active Authentication Key pair (KPrAA and KPuAA). A hash representation of Data Group 15 (Public Key (KPuAA) info) is stored in the Document Security Object (SOD) and therefore authenticated by the issuer’s digital signature. The corresponding Private Key (KPrAA) is stored in the contactless IC’s secure memory. By authenticating the visual MRZ (through the hashed MRZ in the Document Security Object (SOD)) in combination with the challenge response, using the eMRTD’s Active Authentication Key Pair (KPrAA and KPuAA), the inspection system verifies that the Document Security Object (SOD) has been read from the genuine contactless IC, stored in the genuine eMRTD. The Chip Authentication defined in [ICAO_9303] and [TR_03110] is a security feature which is optionally supported by the TOE. The Chip Authentication prevents data traces described in [ICAO_9303]. The Chip Authentication is provided by the following steps: (i) the inspection system communicates by means of secure messaging established by Basic Access Control, (ii) the inspection system reads and verifies by means of the Passive Authentication the authenticity of the MRTD’s Chip Authentication Public Key using the Document Security Object, (iii) the inspection system generates an ephemeral key pair, (iv) the TOE and the inspection system agree on two session keys for secure messaging in ENC_MAC mode according to the Diffie-Hellman Primitive and (v) the inspection system verifies by means of received message authentication codes whether the MRTD’s chip was able or not to run this protocol properly (i.e. the TOE proves to be in possession of the Chip Authentication Private Key corresponding to the Chip Authentication Public Key used for derivation of the session keys). The Chip Authentication requires collaboration of the TOE and the TOE environment. This TOE addresses the Chip Authentication as an alternative to the Active Authentication stated in [ICAO_9303]. Mutatis mutandis, the TOE may also be used as an ISO driving license, compliant to ISO/IEC 18013 or ISO/IEC TR 19446 supporting BAP-1 (the same protocol as BAC but used in the context of driving license), AA and CA, as both applications (MRTD and IDL) share the same protocols and data structure organization. Therefore, in the rest of the document, the word “MRTD” MAY be understood either as a MRTD in the sense of ICAO, or a driving license compliant to ISO/IEC 18013 or ISO/IEC TR 19446 depending on the targeted usage envisioned by the issuer. The table below indicates how terms and concept present in the current document shall be read when considering the TOE to be an ISO driving license: MRTD ISO driving licence MRTD IDL ICAO ISO/IEC ICAO 9303 ISO/IEC 18013 or ISO/IEC TR 19446 BAC BAP-1 DG3 DG7 DG4 DG8 DG15 DG13 MRZ MRZ or SAI (Scanning area identifier) Traveler Holder Finally, the TOE can be updated in post-emission. The mechanism allows to protect the integrity and confidentiality of product data loaded and data already in the product as established in the PP module [PP_0090]. The mechanism is called Update Mechanism in this document. 15/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.2.2 TOE type The TOE is the contactless and/or contact integrated circuit chip of machine readable travel documents (MRTD’s chip) programmed according to the Logical Data Structure (LDS) and providing the Basic Access Control, the Active Authentication and the Chip Authentication according to [ICAO_9303]. The TOE comprises at least: • the circuitry of the MRTD’s chip (the integrated circuit, IC), • the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated Support Software, • the IC Embedded Software (operating system), • the MRTD application, • the associated guidance documentation. Note: The antenna and the form factor are not part of the TOE as they do not have any impact on the security. 16/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.2.3 TOE life cycle 2.2.3.1 Life cycle overview The following table presents the TOE subjects and the corresponding responsible: Subject Responsible IC developer IDEMIA TOE developer IDEMIA Manufacturer IC manufacturer IDEMIA or identified actors in [IC_ST] MRTD packaging responsible IDEMIA or another agent Embedded software loading responsible IDEMIA or identified actors in [IC_ST] Pre-personalization Agent IDEMIA or another agent Personalization Agent IDEMIA or another agent Table 5 - Subjects identification on the life cycle Several life cycles are available, depending when the Flash Code is loaded and who loads the Flash Code. The following tables present the subjects following TOE life cycle steps in accordance with the standard smart card life cycle [PP_IC], and describe for each of them, (1) the TOE delivery point and (2) the assurance coverage: Scheme 1, MRTD chip Embedded Software loaded by the IC Manufacturer in step 3: Phase Step Subject Emb. Sw. loading Covered by Sites 1 - Development 1 IC developer  IC certification IC certification 2 TOE developer  ALC R&D sites Pessac and Courbevoie 2 - Manufacturing 3 IC manufacturer  IC certification IC manufacturer site Embedded software loading responsible ✓ TOE delivery point 4 MRTD packaging responsible  Packaging centre 5 Pre-personalization agent  AGD_PRE 3 - Personalization 6 Personalization agent  AGD_PRE 4 - Operational Use 7 End user  AGD_OPE Table 6 - Subjects identification following life cycle steps – Scheme 1 For the scheme 1, the OS loading is done at IC manufacturer site (audited). Once OS loaded, the TOE is auto- protected. Thus, the delivery to other entities (IDEMIA or any other not audited site) is a standard delivery. 17/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Scheme 2, MRTD chip Embedded Software loaded by the Flash Loader with the optional Package 1 (See [IC_ST]) in step 4 before TOE delivery point: Phase Step Subject Emb. Sw. loading Covered by Sites 1 - Development 1 IC developer  IC certification IC developer site 2 TOE developer  ALC R&D sites Pessac and Courbevoie 2 - Manufacturing 3 IC manufacturer  IC certification IC manufacturer site 4 MRTD packaging responsible  Packaging centre Embedded software loading responsible ✓ ALC Embedded software loading centre IDEMIA audited sites TOE delivery point 5 Pre-personalization agent  AGD_PRE 3 - Personalization 6 Personalization agent  AGD_PRE 4 - Operational Use 7 End user  AGD_OPE Table 7 - Subjects identification following life cycle steps – Scheme 2 For the scheme 2, the IC is delivered to IDEMIA after IC manufacturing (audited). Then the OS loading is done at one audited IDEMIA site. Once OS loaded, the TOE is auto-protected. The next delivery to any entity is done following ALC_DEL. 18/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.2.3.2 Life cycle phases The following text was extracted from [PP_BAC]. Due to the previous specified life cycles and to the technology of the IC, some interpretations have to be done by the reader of this ST. The table below indicates how terms shall be read: Term in [PP_BAC] Meaning in this ST Software developer TOE developer non-volatile non-programmable memory(ies) Part of the Flash memory where the Flash Loader and the OS are loaded. This memory is programmable by the IC manufacturer or using the Flash Loader. Once the Flash Loader is blocked, this memory is Read Only Memory ROM non-volatile programmable memory(ies) Part of the Flash memory where initialization data and user data are written. FLASH MEMORY The TOE life cycle is described in terms of the four life cycle phases and subdivided into 7 steps (with respect to the [PP_IC]). 2.2.3.2.1 Phase 1 “Development” (Step1) The TOE is developed in phase 1. The IC developer develops the integrated circuit, the IC Dedicated Software and the guidance documentation associated with these TOE components. (Step2) 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 MRTD application and the guidance documentation associated with these TOE components. The manufacturing documentation of the IC including the IC Dedicated Software and the Embedded Software in the Flash memory is securely delivered to the IC manufacturer. The IC Embedded Software in the non-volatile programmable memories, the MRTD application and the guidance documentation is securely delivered to the MRTD manufacturer. Note: If scheme 1 is applied, the Embedded Software in the Flash memory securely delivered to the IC manufacturer. For details, please refer to ALC and in particular to [ALC_STM]. If scheme 2 is applied, the Embedded Software in the Flash memory securely delivered to the MRTD manufacturer. For details, please refer to ALC and in particular to [ALC_SCT]. 2.2.3.2.2 Phase 2 “Manufacturing” (Step3) In a first step the TOE integrated circuit is produced containing the MRTD’s IC Dedicated Software and the parts of the MRTD’s chip Embedded Software in the Flash memory. The IC manufacturer writes the IC Identification Data onto the IC to control the IC as MRTD material during the IC manufacturing and the delivery process to the MRTD manufacturer. The IC is securely delivered from the IC manufacture to the MRTD manufacturer. If necessary the IC manufacturer adds the parts of the IC Embedded Software in the non-volatile programmable memories (for instance Flash memory). The manufacturer can use the update mechanism to add a Update Package. Note: If scheme 2 is applied, the TOE integrated circuit is produced containing IC dedicated software. The IC manufacturer writes the IC Identification Data onto the chip to control the IC as MRTD material during the IC manufacturing and the delivery process to the MRTD manufacturer. The IC is securely delivered from the IC manufacture to the MRTD manufacturer. (Step4) The MRTD manufacturer combines the IC with hardware for the contactless interface in the passport book. Note: If scheme 2 is applied, the MRTD manufacturer (i) loads the MRTD’s chip Dedicated Software and the parts of the MRTD’s chip Embedded Software in the non-volatile non-programmable memories (ii) adds the parts of the IC Embedded Software in the non-volatile programmable memories. 19/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 (Step5) The MRTD manufacturer (i) creates the MRTD application and (ii) equips MRTD’s chips with pre- personalization Data. Application Note: Creation of the application implies the creation of MF and ICAO.DF. Note: If one (or several) Update Package(s) is (are) associated to the MRTD’s chip Embedded Software, it (they) shall be loaded prior to any operation in (Step5). The pre-personalized MRTD together with the IC Identifier is securely delivered from the MRTD manufacturer to the Personalization Agent. The MRTD manufacturer also provides the relevant parts of the guidance documentation to the Personalization Agent. Also this step authorizes to update the OS. 2.2.3.2.3 Phase 3 “Personalization of the MRTD” (Step6) The personalization of the MRTD includes (i) the survey of the MRTD holder’s biographical data, (ii) the enrolment of the MRTD holder biometric reference data (i.e. the digitized portraits and the optional biometric reference data), (iii) the printing of the visual readable data onto the physical MRTD, (iv) the writing of the TOE User Data and TSF Data into the logical MRTD and (v) configuration of the TSF if necessary. The step (iv) is performed by the Personalization Agent and includes but is not limited to the creation of (i) the digital MRZ data (EF.DG1), (ii) the digitized portrait (EF.DG2), and (iii) the Document security object and file for the TOE configuration such as (but not limited to) the keys, CA keys and TA trust point. The signing of the Document security object by the Document Signer [ICAO_9303] finalizes the personalization of the genuine MRTD for the MRTD holder. The personalized MRTD (together with appropriate guidance for TOE use if necessary) is handed over to the MRTD holder for operational use. Application note: The TSF data comprise (but are not limited to) the Personalization Agent Authentication Key(s) and the Basic Authentication Control Key. Application note: This security target 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]. This approach allows but does not enforce the separation of these roles. The selection of the authentication keys should consider the organization, the productivity and the security of the personalization process. Asymmetric authentication keys provide comfortable security for distributed personalization but their use may be more time consuming than authentication using symmetric cryptographic primitives. Authentication using symmetric cryptographic primitives allows fast authentication protocols appropriate for centralized personalization schemes but relies on stronger security protection in the personalization environment. Also this step authorizes to update the OS. 2.2.3.2.4 Phase 4 “Operational Use” (Step7) The TOE is used as MRTD chip by the traveler and the inspection systems in the “Operational Use” phase. The user data can be read according to the security policy of the issuing State or Organization and can be used according to the security policy of the issuing State but they can never be modified. Application note: The authorized Personalization Agents might be allowed to add (not to modify) data in the other data groups of the MRTD application (e.g. person(s) to notify EF.DG16) in the Phase 4 “Operational Use”. This will imply an update of the Document Security Object including the re-signing by the Document Signer. Application note: The intention of this security target is to consider at least the Phase 1 and parts of Phase 2 (i.e. Step1 to Step3) as part of the evaluation and therefore to define the TOE delivery according to CC after this Phase 2 or later. Since specific production steps of Phase 2 are of minor security relevance (e. g. booklet manufacturing and antenna integration) these are not part of the CC evaluation under ALC. Nevertheless, the decision about this has to be taken by the certification body resp. the national body of the issuing State or Organization. In this case the national body of the issuing State or Organization is responsible for these specific production steps. 20/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Note that the personalization process and its environment may depend on specific security needs of an issuing State or Organization. All production, generation and installation procedures after TOE delivery up to the “Operational Use” (phase 4) have to be considered in the product evaluation process under AGD assurance class. Therefore, the Security Target has to outline the split up of P.Manufact, P.Personalization and the related security objectives into aspects relevant before vs. after TOE delivery. Also this step authorizes to update the OS. 2.2.4 Required non-TOE hardware/Software/firmware There is no explicit non-TOE hardware, software or firmware required by the TOE to perform its claimed security features. The TOE is defined to comprise the chip and the complete operating system and application. Note, the inlay holding the chip as well as the antenna and the booklet (holding the printed MRZ) are needed to represent a complete MRTD, nevertheless these parts are not inevitable for the secure operation of the TOE. Note: in particular the TOE may be used in contact mode, without any inlay or antenna. 21/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.3 TOE description 2.3.1 TOE Architecture The TOE is composed of an IC and some software components as presented in Figure 1. Each part of the TOE is presented in the following chapters. Figure 1 - TOE architecture Application layer Platform layer Integrated Circuit Low layer IDEMIA BIOS IDEMIA Cryptographic Library Services Toolbox FSM ACE CKM AKM Authentication Protocols TA CA PACE v2 Start-Up and Applications Manager Block 1: MRTD/IDL MRTD/IDL BAC Resident Application Application Creation Engine BAC MRTD/IDL EAC MRTD/IDL PACE MRTD/IDL EAC w. PACE AA OCL 22/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.3.2 Integrated Circuit The TOE is embedded on SCR404U components (cf § 2.1.3). IC is part of the TOE and also part of the TSF. More information on the chips with physical and logical protections is given in the related Security Target [IC_ST]. It is a hardware device composed of a processing unit, memories, security components and I/O interfaces. It has to implement security features able to ensure: • The confidentiality and the integrity of information processed and flowing through the device, • The resistance of the security IC to externals attacks such as physical tampering, environmental stress or any other attacks that could compromise the sensitive assets stored or flowing through it. 2.3.3 Low layer 2.3.3.1 IDEMIA Basic Input/Output System (BIOS) The BIOS module provides access management (read/write) functionalities to upper-layer application. It also provides exception and communication functionalities. The BIOS module is part of the TOE and is also part of the TSF. 2.3.3.2 IDEMIA Cryptographic library (Crypto) The Cryptography module provides secure cryptographic functionalities to upper-layer applications. . Ciphering operations are implemented to resist environmental stress and glitches and include measures for preventing information leakage through covert channels. The Crypto module is part of the TOE and is also part of the TSF. 2.3.4 Platform layer 2.3.4.1 Services 2.3.4.1.1 File System Management (FSM) The FSM module manages files and data objects according to ISO 7816-4 and 7816-9. It also manages the Digitally Blurred Image process. This specific feature is covered by a patent owned by IDEMIA. Sensitive data have to be protected in integrity from modifications: keys, updated code and sensitive MRTD data. The FSM module is part of the TOE and is also part of the TSF. 2.3.4.1.2 Os Communication Layer (OCL) Os Communication Layer (OCL) is the first subsystem that takes in charge the communication layer (ISO7816 and ISO14443) and it’s the first entry point to make the link between external to internal. It manages the protocol, the ATR sending, the Secure Messaging and brings some specific functionalities The Secure Messaging OCL provides functionalities to encrypt/decrypt data for secure communication in Manufacturing, Personalization and Operational Use phases (steps 5, 6 and 7). A Secure Messaging session begins after a successful authentication (GP authentication for Pre-personalization and Personalization phases or CA for Operational Use phase). The OCL module is part of the TOE and is also part of the TSF. 2.3.4.1.3 Cryptography Key Management (CKM) The CKM module is responsible for asymmetric cryptography key management and asymmetric cryptography operations. 23/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 The CKM module is part of the TOE and is also part of the TSF. 2.3.4.1.4 Authentication and Key Management (AKM) This module supplies: • Symmetric Key management (read, write, access control), • Services to manage Global Platform authentication and secure messaging. The AKM module is part of the TOE and is also part of the TSF. 2.3.4.1.5 Access Condition Engine (ACE) The ACE module is in charge of the verification of the Access Conditions of an object (files and keys) when an application tries to access this object. The ACE module is part of the TOE and is also part of the TSF. 2.3.4.1.6 Toolbox (TBX) The Toolbox module provides different kind of services to other modules. • Services to manage APDU, • Services to handle BER-TLV constructed data object, • Services to process specific cryptographic operations, • Services to handle Object Identifier, • Services to manage MRZ (personalization and misuse management), • Services to handle data in a secure way. The TBX module is part of the TOE but and is also part of the TSF 2.3.5 Authentication Protocols 2.3.5.1 Terminal Authentication (TA) The TA module processes the Terminal Authentication (v1 and v2) mechanism. Terminal Authentication v1 is part of the EACv1 procedure defined in [TR_03110]. The TA module is part of the TOE but is NOT part of the TSF. 2.3.5.2 Chip Authentication (CA) The CA module processes the Chip Authentication (v1 and v2) mechanism. Chip Authentication v1 is part of the EACv1 procedure defined in [ICAO_9303]. The CA module is part of the TOE and also part of the TSF. 2.3.5.3 Password Authenticated Connection Establishment (PACE v2) The PACE module provides functionalities to process the PACE v2 mechanism as defined in [ICAO_9303]. The PACE v2 module is part of the TOE but is NOT part of the TSF. 2.3.5.4 Basic Access Control (BAC) The BAC module provides functionalities to process the BAC mechanism as defined in [ICAO_9303]. The BAC module is part of the TOE and is also part of the TSF. 24/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 2.3.5.5 Active Authentication (AA) The AA module provides functionalities to process the AA mechanism as defined in [ICAO_9303]. The AA module is part of the TOE and is also part of the TSF. 2.3.6 Application layer 2.3.6.1 Start-Up and Applications Manager (Boot) The Boot module is responsible to manage the start-up of the applications (MRTD, RA and ACRE). The Boot module is part of the TOE and is also part of the TSF 2.3.6.2 Application Creation Engine (ACRE) The Application Creation Engine is a complete set of commands used to (pre-)personalize the card and its application(s). It includes: • Creation of application, • Import and Generation of the Active Authentication key (ECC and RSA keys), • Import and Generation of multiple Chip Authentication keys under the ADF (supporting ECC and RSA Keys), • Storage of CVCA Keys under each ADF. The ACRE module is part of the TOE and is also part of the TSF. 2.3.6.3 Resident Application (RA) The Resident Application is a complete set of commands, which allows the management of the card in the Operational Use phase (data management and authentication process under MF). The RA is also in charge of Update mechanism. The Additional Code Loading, i.e the Update mechanism process is as follow: 1. Additional Code’s Secure Messaging keys (authenticity and confidentiality) calculation, 2. Additional Code loading, 3. Additional Code activation. The RA module is part of the TOE and is also part of the TSF. 2.3.6.4 Machine Readable Travel Document (MRTD) The MRTD is a complete set of commands, which allows the management of MRTD data in the Operational Use phase (data management and authentication process under MRTD ADF). The MRTD module is part of the TOE and is also part of the TSF. 25/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 3 Conformance claims 3.1 CommonCriteriaconformance This Security Target (ST) claims conformance to the Common Criteria (CC) version 3.1 revision 5. The conformance to the CC is claimed as follows Part 2 extended and Part 3 Conformant: CC Conformance Claim Part 1 Strict conformance Part 2 Conformance with extensions: • FAU_SAS.1 “Audit storage”, • FCS_RND.1 “Quality metric for random numbers”, • FMT_LIM.1 “Limited capabilities”, • FMT_LIM.2 “Limited availability”, • FPT_EMS.1 “TOE Emanation”, • FIA_API.12 “Authentication Proof of Identity”, Part 3 Conformance with package EAL4 augmented3 with: • ADV_IMP.2 “Complete mapping of the implementation representation of the TSF”, • ADV_FSP.5 “Complete semi-formal functional specification with additional error information” • ADV_INT.3 “Minimally complex internals”, • ADV_TDS.5 “Complete semiformal modular design”, • ALC_CMC.5 “Advanced support”, • ALC_TAT.3 “Compliance with implementation standards – all parts”, • ALC_FLR.3 “Flaw remediation”, • ALC_DVS.2 “Sufficiency of security measures”, • ATE_COV.3 “Rigorous analysis of coverage”, • ATE_DPT.3 “Testing: modular design” • ATE_FUN.2 “Ordered Functional testing”. Table 8 – Common Criteria conformance claim Remark For interoperability reasons it is assumed the receiving state cares for sufficient measures against eavesdropping within the operating environment of the inspection systems. Otherwise the TOE may protect the confidentiality of some less sensitive assets (e.g. the personal data of the TOE holder which are also printed on the physical TOE) for some specific attacks only against enhanced basic attack potential (AVA_VAN.3). FPT_EMSEC.1 from [PP_BAC] has been renamed to FPT_EMS.1, in order to keep the SFR formatting. 2 FIA_API.1 has been added to this security target for the needs of the Chip Authentication Protocol and the Active Authentication Protocol. 3 This EAL and its augmentations correspond to an EAL5 + ALC_DVS.2 where AVA_VAN level is downgraded to AVA_VAN.3 following constraint of MRZ entropy described in [ICAO_9303]. 26/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 3.2 ProtectionProfile conformance 3.2.1 Overview This ST claims strict conformance to the following Protection Profile (PP): Title Protection Profile – Machine Readable Travel Document with ICAO Application and Basic Access Control (MRTD-PP) CC Version 3.1 (Revision 2) Assurance Level The minimum assurance level for this PP is EAL4 augmented Version Number 1.10 Registration BSI-CC-PP-0055 Table 9 – Protection Profile conformance This ST also addresses the Manufacturing and Personalization phases at TOE level (cf. § 2.2.3), as well as the Chip Authentication (CA) and Active Authentication (AA) protocols available in operational use phase. The additions do not contradict any of the threats, assumptions, organizational policies, objectives or SFRs stated in the [PP_BAC] that covers the advanced security methods BAC in operational use phase. The following parts list assumptions, threats, OSP, OT and OE for this TOE (i.e. from [PP_BAC] and additional). This ST is also based on the following PP Configuration: Title Machine Readable Electronic Documents - Optionales Nachladen (Optional Post-Emission Updates) [MR.ED-ON-PP] CC Version 3.1 (Revision 4) Assurance Level The minimum assurance level for this PP is EAL4 augmented Version Number Version 0.9.2, August 18th, 2016 Registration BSI-CC-PP-0090-2016 Table 10 – Protection Profile Configuration conformance The strict conformance can’t be announced here because the [PP_0087] is not used, but the PP module for OS post emission update [PP_0090] is completely used. For code loading, this ST is also based on the support of [JIL_SRCL] document. 3.2.2 Assumptions The following Assumptions are assumed for this TOE: • A.MRTD_Manufact “MRTD manufacturing on steps 4 to 6” defined in [PP_BAC], • A.MRTD_Delivery “MRTD delivery during steps 4 to 6” defined in [PP_BAC], • A.Pers_Agent “Personalization of the MRTD’s chip” defined in [PP_BAC], • A.Insp_Sys “Inspection Systems for global interoperability” defined in [PP_BAC], • A.BAC-Keys “Cryptographic quality of Basic Access Control Keys” defined in [PP_BAC], • A.Insp_Sys_Chip_Auth “Inspection Systems for global interoperability on chip authenticity” defined in this ST, • A.Signature_PKI “PKI for Passive Authentication” defined in [PP_EAC]. A.Insp_Sys_Chip_Auth and A.Signature_PKI are additional for the Chip Authentication protocol and Active Authentication protocol which are not in the original scope of the [PP_BAC]. These assumptions are only linked to threats for the Chip Authentication protocol and Active Authentication protocol so these objectives neither mitigate a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the [PP_BAC], nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the [PP_BAC]. 27/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 3.2.3 Threats The following threats are averted by this TOE: • T.Chip_ID “Identification of MRTD’s chip” defined in [PP_BAC], • T.Skimming “Skimming the logical MRTD” defined in [PP_BAC], • T.Eavesdropping “Eavesdropping to the communication between TOE and inspection system” defined in [PP_BAC], • T.Forgery “Forgery of data on MRTD’s chip” defined in [PP_BAC], • T.Abuse-Func “Abuse of Functionality” defined in [PP_BAC], • T.Information_Leakage “Information Leakage from MRTD’s chip” defined in [PP_BAC], • T.Phys-Tamper “Physical Tampering” defined in [PP_BAC], • T.Malfunction “Malfunction due to Environmental Stress” defined in [PP_BAC], • T.Configuration “Tampering attempt of the TOE during preparation” defined in this ST, • T.Counterfeit “MRTD’s chip” defined in [PP_EAC], Threats for Update mechanism: • T.FaTSF “Faulty TSF”, defined in [PP_0090], • T.UaU “Unauthorized Update”, defined in [PP_0090]. 3.2.4 Organizational Security Policies This TOE complies with the following OSP: • P.Manufact “Manufacturing of the MRTD’s chip” defined in [PP_BAC], • P.Personalization “Personalization of the MRTD by issuing State or Organization only” defined in [PP_BAC], • P.Personal_Data “Personal data protection policy” defined in [PP_BAC]. OSP for Update mechanism: • P.Code_Confidentiality, defined in [PP_0090], • P.Secure_Environment, defined in [PP_0090], • P.Eligible_Terminals_Only, defined in [PP_0090]. 28/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 3.2.5 Security Objectives The Security Objectives for this TOE are the following: • OT.AC_Pers “Access Control for Personalization of logical MRTD” defined in [PP_BAC], • OT.Data_Int “Integrity of personal data” defined in [PP_BAC], • OT.Data_Conf “Confidentiality of personal data” defined in [PP_BAC], • OT.Identification “Identification and Authentication of the TOE” defined in [PP_BAC], • OT.Prot_Abuse-Func “Protection against Abuse of Functionality” defined in [PP_BAC], • OT.Prot_Inf_Leak “Protection against Information Leakage” defined in [PP_BAC], • OT.Prot_Phys-Tamper “Protection against Physical Tampering” defined in [PP_BAC], • OT.Prot_Malfunction “Protection against Malfunctions” defined in [PP_BAC], • OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” defined in this ST, • OT.Configuration “Protection of the TOE preparation” defined in this ST, • OT.TOE_Identification “Secure identification of the TOE” defined in [JIL_SRCL]. OT for update mechanism: • OT.Update_Mechanism “TOE Update Mechanism” defined in [PP_0090], • OT.Enc_Sign_Update “Encrypted-then-signed Update Packages” defined in [PP_0090], • OT.Update_Terminal_Auth “Updates only by authenticated Update Terminals” defined in [PP_0090], • OT.Attack_Detection “Detection of Attacks on the TOE using the Update Mechanism” defined in [PP_0090], • OT.Key_Secrecy “Key Secrecy of Cryptographic Update Keys” defined in [PP_0090]. The Security Objectives for the environment of this TOE are the following: • OE.MRTD_Manufact “Protection of the MRTD Manufacturing” defined in [PP_BAC], • OE.MRTD_Delivery “Protection of the MRTD delivery” defined in [PP_BAC], • OE.Personalization “Personalization of logical MRTD” defined in [PP_BAC], • OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature” defined in [PP_BAC], • OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys” defined in [PP_BAC], • OE.Exam_MRTD “Examination of the MRTD passport book” defined in [PP_BAC], • OE.Passive_Auth_Verif “Verification by Passive Authentication” defined in [PP_BAC], • OE.Prot_Logical_MRTD “Protection of data from the logical MRTD” defined in [PP_BAC], • OE.Auth_MRTD “MRTD Authentication Key” defined in this ST, • OE.Exam_Chip_Auth “Examination of the chip authenticity” defined in this ST. OE for Update mechanism • OE.Secure_Environment defined in [PP_0090], • OE.Eligible_Terminals_Only defined in [PP_0090], • OE.Code_Confidentiality defined in [PP_0090]. OE.Auth_MRTD and OE.Exam_Chip_Auth are additional objectives for the operational environment for the Chip Authentication protocol and Active Authentication protocol which are not in the original scope of the [PP_BAC]. These objectives are only linked to threats for the Chip Authentication protocol and Active Authentication protocol so these objectives neither mitigate a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the [PP_BAC], nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the [PP_BAC]. 29/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4 Security problem definition 4.1 Assets 4.1.1 Logical MRTD data The following table presents the assets of the TOE and their corresponding phase(s) according to §2.2.3 TOE life cycle: Asset Step 5 Step 6 Step 7 Personal Data  ✓ ✓ Biometric Data  ✓ ✓ EF.COM  ✓ ✓ EF.SOD  ✓ ✓ CA_PK  ✓ ✓ CA_SK  ✓ ✓ AA_PK  ✓ ✓ AA_SK  ✓ ✓ CPLC ✓ ✓ ✓ TOE_ID ✓ ✓ ✓ Pre-Perso_K ✓   Perso_K  ✓  BAC_K  ✓ ✓ Session_K ✓ ✓ ✓ LCS ✓ ✓ ✓ Configuration data ✓ ✓ ✓ Update Package ✓ ✓ ✓ LSK ✓ ✓ ✓ DIV_LSK and DIV2_LSK ✓ ✓ ✓ Table 11 – Assets of the TOE and their corresponding phase(s) 4.1.1.1 Personal Data The Personal Data are the logical MRTD standard User Data of the MRTD holder (EF.DG1, EF.DG2, EF.DG5 to EF.DG13, EF.DG16). 4.1.1.2 Biometric Data The Biometric Data are the sensitive biometric reference data (EF.DG3, EF.DG4). 4.1.1.3 EF.COM The EF.COM is an elementary file containing the list of the existing elementary files (EF) with the user data. 4.1.1.4 EF.SOD The elementary file Document Security Object is used by the inspection system for Passive Authentication of the logical MRTD. 4.1.1.5 Chip Authentication Public Key (CA_PK) The Chip Authentication Public Key (contained in EF.DG14) is used by the inspection system for the Chip Authentication. 30/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.1.1.6 Chip Authentication Private Key (CA_SK) The Chip Authentication Private Key is used by the application to process Chip Authentication. 4.1.1.7 Active Authentication Public Key (AA_PK) The Active Authentication Public Key (contained in EF.DG15) is used by the inspection system for the Active Authentication. 4.1.1.8 Active Authentication Private Key (AA_SK) The Active Authentication Private Key is used by the application to process Active Authentication. 4.1.1.9 CPLC The CPLC Data are the Card Production Life Cycle data. They are considered as user data as they enable to track the holder. These data are filled during steps 4, 5 and 6 by subjects. 4.1.1.10 TOE_ID These data allow the identification of the TOE. These data are part of the IC Embedded Software in the non-volatile non-programmable memory. If Update Package is loaded, then the TOE_ID contains Update Package Identification Data. 4.1.1.11 Pre-personalization Agent keys (Pre-perso_K) This key set used for mutual authentication between the Pre-personalization agent and the chip, and secure communication establishment. 4.1.1.12 Personalization Agent keys (Perso_K) This key set used for mutual authentication between the Personalization agent and the chip, and secure communication establishment. 4.1.1.13 BAC keys (BAC_K) This key set used for secure communication establishment between the Terminal and the chip. 4.1.1.14 Secure Messaging session keys (Session_K) Session keys are used to secure communication in confidentiality and authenticity. 4.1.1.15 TOE Life Cycle State (LCS) This is the Life Cycle State of the TOE. 4.1.1.16 Configuration Data These specific data set the configuration of the TOE in terms of security features and security functions. These configuration data can be set in Manufacturing and Personalization phases (Steps 5 and 6) after authentication of the relevant agent with the relevant key set. 4.1.2 Assets related to Update Mechanism 4.1.2.1 Secret Cryptographic Update Keys All cryptographic key material related to the update mechanism; i.e. cryptographic material that is used to establish a secure communication channel with the update terminal, to authenticate an update terminal, to 31/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 decrypt and verify the authenticity of an update package, and for other update-related cryptographic operations. Note that this term deliberately includes public (in the cryptographic sense) signing keys installed on the TOE for verifying the authenticity of update packages, as well as ephemeral keys. Application Note: the keys are LSK and derived ones: see 4.1.2.8. 4.1.2.2 Meta-Data Data that contains information about the update, e.g. version information, checksums, information w.r.t. applicability to specific product versions and platforms, etc. Application Note: Note that, depending on the deployment scenario, some meta-data are security relevant and must be encrypted. Consider for example an identifier, that uniquely identifies a product version. If the update fixes a security flaw, an attacker that obtains the identifier can directly find out whether some product is vulnerable. The precise definition of meta-data and which data are encrypted shall be given by the ST-Writer. 4.1.2.3 Update Data Unencrypted data that is used to update the TOE software. Note that we use the term update data to denote the unencrypted data. Encrypted update data, appended with optional additional unencrypted meta-data (i.e. version number, TOE product identifier), and signed, is called an update package. 4.1.2.4 Update Log Data Log records that store information about previously applied updates and failed update attempts. 4.1.2.5 Update Package Encrypted update data, appended with optional unencrypted meta-data, and signed. Application Note: This is the Updated Code to be loaded on the Initial TOE during life cycle by an update Agent or Manufacturer. The result of this operation is the Final TOE. 4.1.2.6 Update Package Verification Status Security attribute indicating whether the supplied update was successfully verified (and where hence its authenticity and integrity can be assumed) or not, and whether an attempt to verify was made or not. Allowed values are NOT VERIFIED, SUCCESSFULLY VERIFIED and VERIFICATION FAILED. 4.1.2.7 Version Information Version information that uniquely identify the version of the TOE software currently installed on the TOE. 4.1.2.8 Load Secure Key (LSK) and Diversified LSK (DIV_LSK, DIV2_LSK) This Load Secure Key (LSK) is the secret key used to calculate the Diversified LSK (DIV_LSK and DIV2_LSK). The Diversified LSK is a session key used to verify the Update Package confidentiality (DIV_LSK) and integrity (DIV2_LSK). 32/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.1.3 Authenticity of the MRTD’s chip The authenticity of the MRTD’s chip personalized by the issuing State or Organization for the MRTD holder is used by the traveler to prove his possession of a genuine MRTD. 33/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.2 Subjects 4.2.1 Overview The following table presents the subjects of the TOE and their corresponding phase(s) according to §2.2.3 TOE life cycle: Subject Descr. Step 3 Step 4 Step 5 Step 6 Step 7 IC manufacturer (Manufacturer role) § 4.2.2 ✓     MRTD packaging responsible (Manufacturer role) § 4.2.3  ✓    Embedded software loading responsible (Manufacturer role) § 4.2.4 ✓ ✓    Pre-personalization Agent (Manufacturer role) § 4.2.5   ✓   Personalization Agent § 4.2.6    ✓  Terminal § 4.2.7   ✓ ✓ ✓ Inspection System § 4.2.8     ✓ MRTD Holder § 4.2.9     ✓ Traveler § 4.2.10     ✓ Attacker § 4.2.11 ✓ ✓ ✓ ✓ ✓ Table 12 – Subjects of the TOE and their corresponding phase(s) 4.2.2 IC manufacturer This additional subject is a refinement of the role Manufacturer as described in [PP_BAC]. It is the manufacturer of the IC. If scheme 1 is applied (cf. § 2.2.3), this subject is responsible for the embedded software downloading in the IC. This subject does not use Flash loader, even if it is embedded in the IC. 4.2.3 MRTD packaging responsible This additional subject is a refinement of the role Manufacturer as described in [PP_BAC]. This subject is responsible for the combination of the IC with hardware for the contactless and/or contact interface. 4.2.4 Embedded software loading responsible This additional subject is a refinement of the role Manufacturer as described in [PP_BAC]. This subject is responsible for the embedded software loading when scheme 1 or scheme 2 is applied (cf. § 2.2.3). This subject uses the Flash loader embedded in the IC. 4.2.5 Pre-personalization Agent This additional subject is a refinement of the role Manufacturer as described in [PP_BAC]. This subject is responsible for the preparation of the card, i.e. creation of the MF and MRTD ADF. He also sets Personalization Agent keys, Configuration data. 4.2.6 Personalization Agent The agent is acting on behalf of the issuing State or Organization to personalize the MRTD for the holder by some or all of the following activities (i) establishing the identity the holder for the biographic data in the MRTD, (ii) enrolling the biometric reference data of the MRTD holder i.e. the portrait, the encoded finger image(s) and/or the encoded iris image(s) (iii) writing these data on the physical and logical MRTD for the holder as defined for global, international and national interoperability, (iv) writing the initial TSF data and (iv) signing the Document Security Object defined in [ICAO_9303]. 34/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.2.7 Terminal A terminal is any technical system communicating with the TOE through the contactless interface. Note: as the TOE may also be used in contact mode, the terminal may also communicate using the contact interface. 4.2.8 Inspection system (IS) A technical system used by the border control officer of the receiving State (i) examining an MRTD presented by the traveler and verifying its authenticity and (ii) verifying the traveler as MRTD holder. The Basic Inspection System (BIS) (i) contains a terminal for the contactless communication with the MRTD’s chip, (ii) implements the terminals part of the Basic Access Control Mechanism and (iii) gets the authorization to read the logical MRTD under the Basic Access Control by optical reading the MRTD or other parts of the passport book providing this information. The General Inspection System (GIS) is a Basic Inspection System which implements additionally the Chip Authentication Mechanism. The Extended Inspection System (EIS) in addition to the General Inspection System (i) implements the Terminal Authentication Protocol and (ii) is authorized by the issuing State or Organization through the Document Verifier of the receiving State to read the sensitive biometric reference data. The security attributes of the EIS are defined of the Inspection System Certificates. 4.2.9 MRTD Holder The rightful holder of the MRTD for whom the issuing State or Organization personalized the MRTD. 4.2.10 Traveler Person presenting the MRTD to the inspection system and claiming the identity of the MRTD holder. 4.2.11 Attacker A threat agent trying (i) to identify and to trace the movement of the MRTD’s chip remotely (i.e. without knowing or optically reading the printed MRZ data), (ii) to read or to manipulate the logical MRTD without authorization, or (iii) to forge a genuine MRTD. Application note: An impostor is attacking the inspection system as TOE IT environment independent on using a genuine, counterfeit or forged MRTD. Therefore the impostor may use results of successful attacks against the TOE but the attack itself is not relevant for the TOE. 35/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.3 Assumptions 4.3.1 A.MRTD_Manufact “MRTD manufacturing on steps 4 to 6” It is assumed that appropriate functionality testing of the MRTD is used. It is assumed that security procedures are used during all manufacturing and test operations to maintain confidentiality and integrity of the MRTD and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorized use). 4.3.2 A.MRTD_Delivery “MRTD delivery during steps 4 to 6” Procedures shall guarantee the control of the TOE delivery and storage process and conformance to its objectives: • Procedures shall ensure protection of TOE material/information under delivery and storage. • Procedures shall ensure that corrective actions are taken in case of improper operation in the delivery process and storage. • Procedures shall ensure that people dealing with the procedure for delivery have got the required skill. 4.3.3 A.Pers_Agent “Personalization of the MRTD’s chip” The Personalization Agent ensures the correctness of (i) the logical MRTD with respect to the MRTD holder, (ii) the Document Basic Access Keys, (iii) the Chip Authentication Public Key (EF.DG14) if stored on the MRTD’s chip, and (iv) the Document Signer Public Key Certificate (if stored on the MRTD’s chip). The Personalization Agent signs the Document Security Object. The Personalization Agent bears the Personalization Agent Authentication to authenticate himself to the TOE by symmetric cryptographic mechanisms. 4.3.4 A.Insp_Sys “Inspection Systems for global interoperability” The Inspection System is used by the border control officer of the receiving State (i) examining an MRTD presented by the traveler and verifying its authenticity and (ii) verifying the traveler as MRTD holder. The Basic Inspection System for global interoperability (i) includes the Country Signing Public Key and the Document Signer Public Key of each issuing State or Organization, and (ii) implements the terminal part of the Basic Access Control [ICAO_9303]. The Basic Inspection System reads the logical MRTD under Basic Access Control and performs the Passive Authentication to verify the logical MRTD. 4.3.5 A.BAC-Keys “Cryptographic quality of Basic Access Control Keys” The Document Basic Access Control Keys being generated and imported by the issuing State or Organization have to provide sufficient cryptographic strength. As a consequence of the [ICAO_9303], the Document Basic Access Control Keys are derived from a defined subset of the individual printed MRZ data. It has to be ensured that these data provide sufficient entropy to withstand any attack based on the decision that the inspection system has to derive Document Access Keys from the printed MRZ data with enhanced basic attack potential. 4.3.6 A.Insp_Sys_Chip_Auth “Inspection Systems for global interoperability on chip authenticity” The Inspection System implements at least one of the following protocols to authenticate the MRTD’s chip: Chip Authentication and Active Authentication. The Inspection System verifies the authenticity of the MRTD’s chip during inspection and establishes secure messaging with keys established by the Chip Authentication Mechanism, or uses the signature returned by the TOE during Active Authentication as proof of authenticity. 36/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.3.7 A.Signature_PKI “PKI for Passive Authentication” The issuing and receiving States or Organizations establish a public key infrastructure for passive authentication i.e. digital signature creation and verification for the logical MRTD. The issuing State or Organization 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, (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 MRTDs. The CA creates the Document Signer Certificates for the Document Signer Public Keys that are distributed to the receiving States and Organizations. 37/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.4 Threats 4.4.1 T.Chip_ID “Identification of MRTD’s chip” Adverse action: An attacker trying to trace the movement of the MRTD by identifying remotely the MRTD’s chip by establishing or listening to communications through the contactless communication interface. Threat agent: having enhanced basic attack potential, not knowing the optically readable MRZ data printed on the MRTD data page in advance Asset: Anonymity of user 4.4.2 T.Skimming “Skimming the logical MRTD” Adverse action: An attacker imitates an inspection system trying to establish a communication to read the logical MRTD or parts of it via the contactless communication channel of the TOE. Threat agent: having enhanced basic attack potential, not knowing the optically readable MRZ data printed on the MRTD data page in advance. Asset: confidentiality of logical MRTD data. 4.4.3 T.Eavesdropping “Eavesdropping to the communication between TOE and inspection system” Adverse action: An attacker is listening to an existing communication between the MRTD’s chip and an inspection system to gain the logical MRTD or parts of it. The inspection system uses the MRZ data printed on the MRTD data page but the attacker does not know these data in advance. Threat agent: having enhanced basic attack potential, not knowing the optically readable MRZ data printed on the MRTD data page in advance. Asset: confidentiality of logical MRTD data. 4.4.4 T.Forgery “Forgery of data on MRTD’s chip” Adverse action: An attacker alters fraudulently the complete stored logical MRTD or any part of it including its security related data in order to deceive on an inspection system by means of the changed MRTD holder’s identity or biometric reference data. This threat comprises several attack scenarios of MRTD forgery. The attacker may alter the biographical data on the biographical data page of the passport book, in the printed MRZ and in the digital MRZ to claim another identity of the traveler. The attacker may alter the printed portrait and the digitized portrait to overcome the visual inspection of the inspection officer and the automated biometric authentication mechanism by face recognition. The attacker may alter the biometric reference data to defeat automated biometric authentication mechanism of the inspection system. The attacker may combine data groups of different logical MRTDs to create a new forged MRTD, e.g. the attacker writes the digitized portrait and optional biometric reference finger data read from the logical MRTD of a traveler into another MRTD’s chip leaving their digital MRZ unchanged to claim the identity of the holder this MRTD. The attacker may also copy the complete unchanged logical MRTD to another contactless chip. Threat agent: having enhanced basic attack potential, being in possession of one or more legitimate MRTDs. Asset: authenticity of logical MRTD data. 38/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.4.5 T.Abuse-Func “Abuse of Functionality” Adverse action: An attacker may use functions of the TOE which shall not be used in the phase “Operational Use” in order (i) to manipulate User Data, (ii) to manipulate (explore, bypass, deactivate or change) security features or functions of the TOE or (iii) to disclose or to manipulate TSF Data. This threat addresses the misuse of the functions for the initialization and the personalization in the operational state after delivery to MRTD holder. Threat agent: having enhanced basic attack potential, being in possession of a legitimate MRTD. Asset: confidentiality and authenticity of logical MRTD and TSF data, correctness of TSF. 4.4.6 T.Information_Leakage “Information Leakage from MRTD’s chip” Adverse action: An attacker may exploit information which is leaked from the TOE during its usage in order to disclose confidential TSF data. The information leakage may be inherent in the normal operation or caused by the attacker. Leakage may occur through emanations, variations in power consumption, I/O characteristics, clock frequency, or by changes in processing time requirements. This leakage may be interpreted as a covert channel transmission but is more closely related to measurement of operating parameters, which may be derived either from measurements of the contactless interface (emanation) or direct measurements (by contact to the chip still available even for a contactless chip) and can then be related to the specific operation being performed. Examples are the Differential Electromagnetic Analysis (DEMA) and the Differential Power Analysis (DPA). Moreover the attacker may try actively to enforce information leakage by fault injection (e.g. Differential Fault Analysis). Threat agent: having enhanced basic attack potential, being in possession of a legitimate MRTD. Asset: confidentiality of logical MRTD and TSF data. 4.4.7 T.Phys-Tamper “Physical Tampering” Adverse action: An attacker may perform physical probing of the MRTD’s chip in order (i) to disclose TSF Data or (ii) to disclose/reconstruct the MRTD’s chip Embedded Software. An attacker may physically modify the MRTD’s chip in order to (i) modify security features or functions of the MRTD’s chip, (ii) modify security functions of the MRTD’s chip Embedded Software, (iii) modify User Data or (iv) to modify TSF data. The physical tampering may be focused directly on the disclosure or manipulation of TOE User Data (e.g. the biometric reference data for the inspection system) or TSF Data (e.g. authentication key of the MRTD’s chip) or indirectly by preparation of the TOE to following attack methods by modification of security features (e.g. to enable information leakage through power analysis). Physical tampering requires direct interaction with the MRTD’s chip internals. Techniques commonly employed in IC failure analysis and IC reverse engineering efforts may be used. Before that, the hardware security mechanisms and layout characteristics need to be identified. Determination of software design including treatment of User Data and 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. Threat agent: having enhanced basic attack potential, being in possession of a legitimate MRTD. Asset: confidentiality and authenticity of logical MRTD and TSF data, correctness of TSF. 39/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.4.8 T.Malfunction “Malfunction due to Environmental Stress” Adverse action: An attacker may cause a malfunction of TSF or of the MRTD’s chip Embedded Software by applying environmental stress in order to (i) deactivate or modify security features or functions of the TOE or (ii) circumvent, deactivate or modify security functions of the MRTD’s chip Embedded Software. This may be achieved e.g. by operating the MRTD’s chip outside the normal operating conditions, exploiting errors in the MRTD’s chip Embedded Software or misusing administration function. To exploit these vulnerabilities an attacker needs information about the functional operation. Threat agent: having enhanced basic attack potential, being in possession of a legitimate MRTD. Asset: confidentiality and authenticity of logical MRTD and TSF data, correctness of TSF. 4.4.9 T.Configuration “Tampering attempt of the TOE during preparation” Adverse action: An attacker may access to the TOE at Manufacturing and Personalization phases (steps 5 and 6) to try to (i) deactivate or modify security features or functions of the TOE or (ii) circumvent, deactivate or modify security functions of the MRTD’s chip Embedded Software. Threat agent: having high attack potential, being in possession of one or more MRTD in Pre-personalization or Personalization phases. Asset: authenticity of logical MRTD data 4.4.10 T.Counterfeit “MRTD’s chip” Adverse action: An attacker with high attack potential produces an unauthorized copy or reproduction of a genuine MRTD’s chip to be used as part of a counterfeit MRTD. This violates the authenticity of the MRTD’s chip used for authentication of a traveler by possession of a MRTD. The attacker may generate a new data set or extract completely or partially the data from a genuine MRTD’s chip and copy them on another appropriate chip to imitate this genuine MRTD’s chip. Threat agent: having high attack potential, being in possession of one or more legitimate MRTDs Asset: authenticity of logical MRTD data Threats for Update mechanism 4.4.11 T.FaTSF “Faulty TSF” Adverse action: An attacker gains read or write access to user data or TSF data, or manipulates or mitigates the TSF, for example due to: • software issues that were not detected, not exploitable, or deemed unable to being exploitable at the time of certification, but due to unforeseen advances in technology became a security risk during operational use of the TOE, or • cryptographic mechanisms that were deemed secure at the time of certification, but due to unforeseen advances in the field of cryptography became a security risk during operational use of the TOE. Threat agent: Having high attack potential, being in possession of one or more legitimate electronic documents Asset: all data stored on the TOE (esp. the integrity, authenticity and – if applicable – secrecy of the data) 40/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.4.12 T.UaU “Unauthorized Update” Adverse action: An attacker gains read or write access to user data or TSF data, or manipulates or mitigates the TSF by misuse of the update functionality. This threat contains two main aspects: • the unauthorized installation, which may lead to the use of untimely, outdated or revoked updates. • the installation of updates that are not authorized and authentic. Threat agent: Having high attack potential, being in possession of one or more legitimate electronic documents. Asset: all data stored on the TOE (esp. the integrity, authenticity and – if applicable – secrecy of the data) 41/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 4.5 Organisational SecurityPolicies 4.5.1 P.Manufact “Manufacturing of the MRTD’s chip” The Initialization Data are written by the IC Manufacturer to identify the IC uniquely. The MRTD Manufacturer writes the Pre-personalization Data which contains at least the Personalization Agent Key. 4.5.2 P.Personalization “Personalization of the MRTD by issuing State or Organization only” The issuing State or Organization guarantees the correctness of the biographical data, the printed portrait and the digitized portrait, the biometric reference data and other data of the logical MRTD with respect to the MRTD holder. The personalization of the MRTD for the holder is performed by an agent authorized by the issuing State or Organization only. 4.5.3 P.Personal_Data “Personal data protection policy” The biographical data and their summary printed in the MRZ and stored on the MRTD’s chip (EF.DG1), the printed portrait and the digitized portrait (EF.DG2), the biometric reference data of finger(s) (EF.DG3), the biometric reference data of iris image(s) (EF.DG4)4 and data according to LDS (EF.DG5 to EF.DG13, EF.DG16) stored on the MRTD’s chip are personal data of the MRTD holder. These data groups are intended to be used only with agreement of the MRTD holder by inspection systems to which the MRTD is presented. The MRTD’s chip shall provide the possibility for the Basic Access Control to allow read access to these data only for terminals successfully authenticated based on knowledge of the Document Basic Access Keys as defined in [ICAO_9303]. 4.5.4 OSP from PP Module for Update mechanism 4.5.4.1 P.Code_Confidentiality Update code packages that are created by the TOE software developer or document manufacturer are kept confidential, are encrypted after development at the site of the electronic document manufacturer, and are delivered to the TOE in encrypted form. 4.5.4.2 P.Secure_Environment Update terminals are placed in a secure environment that prevents unauthorized physical access, and are operated by authorized staff only. Authorized staff oversees the complete update procedure. 4.5.4.3 P.Eligible_Terminals_Only Update terminals (i.e. terminals with appropriate certificates that are able to install updates) are handed only to those entities where P.Secure_Environment is enforced. In case of a security incident, these update terminals are functionally disabled (through organizational and/or cryptographic means by e.g. withdrawing certificates). 4 Note that EF.DG3 and EF.DG4 are only readable after successful EAC authentication, not covered by this ST. 42/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5 Security objectives This chapter describes the security objectives for the TOE (OT) and the security objectives for the TOE environment (OE). The security objectives for the TOE environment are separated into security objectives for the development and production environment and security objectives for the operational environment. 5.1 Security objectives for the TOE This section describes the security objectives for the TOE addressing the aspects of identified threats to be countered by the TOE and organizational security policies to be met by the TOE. 5.1.1 OT.AC_Pers “Access Control for Personalization of logical MRTD” The TOE must ensure that the logical MRTD data in EF.DG1 to EF.DG16, the Document security object according to LDS [ICAO_9303] and the TSF data can be written by authorized Personalization Agents only. The logical MRTD data in EF.DG1 to EF.DG16 and the TSF data may be written only during and cannot be changed after its personalization. The Document security object can be updated by authorized Personalization Agents if data in the data groups EF.DG 3 to EF.DG16 are added. 5.1.2 OT.Data_Int “Integrity of personal data” The TOE must ensure the integrity of the logical MRTD stored on the MRTD’s chip against physical manipulation and unauthorized writing. The TOE must ensure that the inspection system is able to detect any modification of the transmitted logical MRTD data. 5.1.3 OT.Data_Conf “Confidentiality of personal data” The TOE must ensure the confidentiality of the logical MRTD data groups EF.DG1 to EF.DG16. Read access to EF.DG1 to EF.DG16 is granted to terminals successfully authenticated as Personalization Agent. Read access to EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 is granted to terminals successfully authenticated as Basic Inspection System. The Basic Inspection System shall authenticate itself by means of the Basic Access Control based on knowledge of the Document Basic Access Key. The TOE must ensure the confidentiality of the logical MRTD data during their transmission to the Basic Inspection System. 5.1.4 OT.Identification “Identification and Authentication of the TOE” The TOE must provide means to store IC Identification and Pre-Personalization Data in its non-volatile memory. The IC Identification Data must provide a unique identification of the IC during Phase 2 “Manufacturing” and Phase 3 “Personalization of the MRTD”. The storage of the Pre-Personalization data includes writing of the Personalization Agent Key(s). In Phase 4 “Operational Use” the TOE shall identify itself only to a successful authenticated Basic Inspection System or Personalization Agent. 5.1.5 OT.Prot_Abuse-Func “Protection against Abuse of Functionality” After delivery of the TOE to the MRTD Holder, the TOE must prevent the abuse of test and support functions that may be maliciously used to (i) disclose critical User Data, (ii) manipulate critical User Data of the IC Embedded Software, (iii) manipulate Soft-coded IC Embedded Software or (iv) bypass, deactivate, change or explore security features or functions of the TOE. Details of the relevant attack scenarios depend, for instance, on the capabilities of the Test Features provided by the IC Dedicated Test Software which are not specified here. 43/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.1.6 OT.Prot_Inf_Leak “Protection against Information Leakage” The TOE must provide protection against disclosure of confidential TSF data stored and/or processed in the MRTD’s chip • 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 and • by forcing a malfunction of the TOE and/or • by a physical manipulation of the TOE 5.1.7 OT.Prot_Phys-Tamper “Protection against Physical Tampering” The TOE must provide protection of the confidentiality and integrity of the User Data, the TSF Data, and the MRTD’s chip Embedded Software. This includes protection against attacks with enhanced-basic attack potential by means of • measuring through galvanic contacts which is direct physical probing on the chips 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 charges (using tools used in solid-state physics research and IC failure analysis) • manipulation of the hardware and its security features, 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 functions. 5.1.8 OT.Prot_Malfunction “Protection against Malfunctions” The TOE must ensure its correct operation. The TOE must prevent its operation outside the normal operating conditions where reliability and secure operation has not been proven or tested. This is to prevent errors. The environmental conditions may include external energy (esp. electromagnetic) fields, voltage (on any contacts), clock frequency, or temperature. 5.1.9 OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” The TOE must support the Inspection Systems to verify the identity and authenticity of the MRTD’s chip as issued by the identified issuing State or Organization by means of the Chip Authentication as defined in [ICAO_9303], or Active Authentication as defined in in combination with the Document Security Object (SOD) verification to verify the SOD belongs to the data page, the chip is genuine and chip and data page belong to each other as defined in [ICAO_9303].The authenticity proof provided by MRTD’s chip shall be protected against attacks with high attack potential. 5.1.10 OT.Configuration “Protection of the TOE preparation” During Pre-personalization and Personalization phases, the TOE must control the access to its sensitive information and its functions and must provide the means to secure exchanges using cryptographic functions. It must also ensure secure erasing of useless keys. 5.1.11 OT.TOE_Identification “Secure identification of the TOE” The Identification Data identifies the Initial TOE and Update Package. The TOE provides means to store Identification Data in its non-volatile memory and guarantees the integrity of these data. After Atomic Activation of the Update Package, the Identification Data of the Final TOE allows identifications of Initial TOE and Update Package. The user must be able to uniquely identify Initial TOE and Update Package(s) which are embedded in the Final TOE. 44/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Security Objectives from PP Module for Update mechanism 5.1.12 OT.Update_Mechanism “TOE Update Mechanism” The TSF provides a mechanism to install code-signed updates of the TOE software by authorized staff during operational use. 5.1.13 OT.Enc_Sign_Update “Encrypted-then-signed Update Packages” The TOE only installs update packages that are encrypted, integrity-protected and signed by the authority in charge of delivering and installing updates. 5.1.14 OT.Update_Terminal_Auth “Updates only by authenticated Update Terminals” The TOE allows only authenticated update terminals to upload an update package to the TOE and to initiate the update procedure. The TOE uses a dedicated cryptographic method to authenticate an update terminal. 5.1.15 OT.Attack_Detection “Detection of Attacks on the TOE using the Update Mechanism” The TOE has logging capabilities that track installed updates and failed update attempts. It also limits the amount of faulty (signature verification or decryption fails) update attempts. It allows dedicated terminals to read out the update logs. 5.1.16 OT.Key_Secrecy “Key Secrecy of Cryptographic Update Keys” The TOE keeps the cryptographic update keys secret, and is designed such that emissions from the TOE do not allow to read out or gain full or partial information about the keys. 45/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.2 Security objectives for the operational environment 5.2.1 Issuing State or Organization The issuing State or Organization will implement the following security objectives of the TOE environment. 5.2.1.1 OE.MRTD_Manufact “Protection of the MRTD Manufacturing” Appropriate functionality testing of the TOE shall be used in step 4 to 6. During all manufacturing and test operations, security procedures shall be used through phases 4, 5 and 6 to maintain confidentiality and integrity of the TOE and its manufacturing and test data. 5.2.1.2 OE.MRTD_Delivery “Protection of the MRTD delivery” Procedures shall ensure protection of TOE material/information under delivery including the following objectives: • non-disclosure of any security relevant information, • identification of the element under delivery, • meet confidentiality rules (confidentiality level, transmittal form, reception acknowledgment), • physical protection to prevent external damage, • secure storage and handling procedures (including rejected TOE’s), • traceability of TOE during delivery including the following parameters: - origin and shipment details, - reception, reception acknowledgement, - location material/information. Procedures shall ensure that corrective actions are taken in case of improper operation in the delivery process (including if applicable any non-conformance to the confidentiality convention) and highlight all non-conformance to this process. Procedures shall ensure that people (shipping department, carrier, reception department) dealing with the procedure for delivery have got the required skill, training and knowledge to meet the procedure requirements and be able to act fully in accordance with the above expectations. 5.2.1.3 OE.Personalization “Personalization of logical MRTD” The issuing State or Organization must ensure that the Personalization Agents acting on behalf of the issuing State or Organization (i) establish the correct identity of the holder and create biographical data for the MRTD, (ii) enroll the biometric reference data of the MRTD holder i.e. the portrait, the encoded finger image(s) and/or the encoded iris image(s) and (iii) personalize the MRTD for the holder together with the defined physical and logical security measures to protect the confidentiality and integrity of these data. 5.2.1.4 OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature” The issuing State or Organization must (i) generate a cryptographic secure Country Signing CA Key Pair, (ii) ensure the secrecy of the Country Signing CA Private Key and sign Document Signer Certificates in a secure operational environment, and (iii) distribute the Certificate of the Country Signing CA Public Key to receiving States and Organizations maintaining its authenticity and integrity. The issuing State or Organization must (i) generate a cryptographic secure Document Signer Key Pair and ensure the secrecy of the Document Signer Private Keys, (ii) sign Document Security Objects of genuine MRTD in a secure operational environment only and (iii) distribute the Certificate of the Document Signer Public Key to receiving States and Organizations. The digital signature in the Document Security Object relates all data in the data in EF.DG1 to EF.DG16 if stored in the LDS according to [ICAO_9303]. 46/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.2.1.5 OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys” The Document Basic Access Control Keys being generated and imported by the issuing State or Organization have to provide sufficient cryptographic strength. As a consequence of the [ICAO_9303] the Document Basic Access Control Keys are derived from a defined subset of the individual printed MRZ data. It has to be ensured that these data provide sufficient entropy to withstand any attack based on the decision that the inspection system has to derive Document Basic Access Keys from the printed MRZ data with enhanced basic attack potential. 5.2.1.6 OE.Auth_MRTD “MRTD Authentication Key” The issuing State or Organization has to establish the necessary public key infrastructure in order to (i) generate the MRTD’s Authentication Key Pair(s), (ii) ensure the secrecy of the MRTD’s Authentication Private Key(s), (iii) sign and store the Authentication Public Key(s) in the Authentication Public Key data (i.e in EF.DG14 for Chip Authentication Public Key and in EF.DG15 for Active Authentication Public Key) and (iv) support inspection systems of receiving States or organizations to verify the authenticity of the MRTD’s chip used for genuine MRTD by certification of the Authentication Public Key by means of the Document Security Object. 5.2.2 Receiving State or Organization The receiving State or Organization will implement the following security objectives of the TOE environment. 5.2.2.1 OE.Exam_MRTD “Examination of the MRTD passport book” The inspection system of the receiving State or Organization must examine the MRTD presented by the traveler to verify its authenticity by means of the physical security measures and to detect any manipulation of the physical MRTD. The Basic Inspection System for global interoperability (i) includes the Country Signing Public Key and the Document Signer Public Key of each issuing State or Organization, and (ii) implements the terminal part of the Basic Access Control [ICAO_9303]. 5.2.2.2 OE.Exam_Chip_Auth “Examination of the chip authenticity” Additionally to the OE.Exam_MRTD, inspection system performs the Chip Authentication Protocol or the Active Authentication Protocol to verify the Authenticity of the presented MRTD’s chip. 5.2.2.3 OE.Passive_Auth_Verif “Verification by Passive Authentication” The border control officer of the receiving State uses the inspection system to verify the traveler as MRTD holder. The inspection systems must have successfully verified the signature of Document Security Objects and the integrity data elements of the logical MRTD before they are used. The receiving States and Organizations must manage the Country Signing Public Key and the Document Signer Public Key maintaining their authenticity and availability in all inspection systems. 5.2.2.4 OE.Prot_Logical_MRTD “Protection of data from the logical MRTD” The inspection system of the receiving State or Organization ensures the confidentiality and integrity of the data read from the logical MRTD. The receiving State examining the logical MRTD being under Basic Access Control will use inspection systems which implement the terminal part of the Basic Access Control and use the secure messaging with fresh generated keys for the protection of the transmitted data (i.e. Basic Inspection Systems). 5.2.3 OEs from PP Module for Update mechanism 5.2.3.1 OE.Secure_Environment The operational environment must ensure that update terminals are placed in a secure environment that prevents unauthorized physical access, and are operated by authorized staff only. The operational environment must also 47/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 ensure through e.g. organizational policies and procedures, that authorized staff oversees the complete update procedure. 5.2.3.2 OE.Eligible_Terminals_Only The operational environment must also ensure by e.g. organizational procedures, supported by cryptographic means, that only those entities that have policies in place that guarantee OE.Secure_Environment, are supplied with update terminals. Moreover the operational environment guarantees that update terminals can be functionally deactivated if these policies are no longer in place or not enforced at the entities. This can be implemented for example by the issuance of certificates for update terminals together with a public key infrastructure. 5.2.4 Security Objectives for the Development and Production Environment 5.2.4.1 OE.Code_Confidentiality The operational environment must ensure that the TOE software developer or document manufacturer keeps update code packages confidential, encrypts them after development at the site of the developer/manufacturer, and delivers them to the TOE in encrypted form. 48/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 49/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.3 Security objectives rationale 5.3.1 Introduction Assumption Related Security Objective(s) Rationale A.MRTD_Manufact OE.MRTD_Manufact § 5.3.2.1 A.MRTD_Delivery OE.MRTD_Delivery § 5.3.2.2 A.Pers_Agent OE.Personalization § 5.3.2.3 A.Insp_Sys OE.Exam_MRTD OE.Prot_Logical_MRTD § 5.3.2.4 A.Insp_Sys_Chip_Auth OE.Exam_Chip_Auth § 5.3.2.5 A.BAC-Keys OE.BAC-Keys § 5.3.2.6 A.Signature_PKI OE.Pass_Auth_Sign § 5.3.2.7 Table 13 - Assumptions of the TOE and Security Objectives Threat Related Security Objective(s) Rationale T.Chip_ID OT.Identification OE.BAC-Keys § 5.3.3.1 T.Skimming OT.Data_Conf OE.BAC-Keys § 5.3.3.2 T.Eavesdropping T.Forgery OT.AC_Pers OT.Data_Int OT.Prot_Phys-Tamper OE.Exam_MRTD OE.Pass_Auth_Sign OE.Passive_Auth_Verif § 5.3.3.3 T.Abuse-Func OT.Prot_Abuse-Func OE. Personalization § 5.3.3.4 T.Information_Leakage OT.Prot_Inf_Leak § 5.3.3.5 T.Phys-Tamper OT.Prot_Phys-Tamper T.Malfunction OT.Prot_Malfunction T.Configuration OT.Configuration OT.TOE_Identification § 5.3.3.6 T.Counterfeit OT.Chip_Auth_Proof OE.Exam_Chip_Auth OE.Auth_MRTD § 5.3.3.7 T.FaTSF OT.Update_Mechanism OT.Attack_Detection OT.Key_Secrecy § 5.3.3.8 T.UaU OT.Enc_Sign_Update OT.Update_Terminal_Auth § 5.3.3.9 Table 14 - Threats of the TOE and Security Objectives OSP Related Security Objective(s) Rationale P.Manufact OT.Identification § 5.3.4.1 P.Personalization OE.Personalization OT.AC_Pers OT.Identification § 5.3.4.2 P.Personal_Data OT.Data_Int OT.Data_Conf § 5.3.4.3 P.Code_Confidentiality OE.Code_Confidentiality § 5.3.4.4 P.Secure_Environment OE.Secure_Environment P.Eligible_Terminals_Only OE.Eligible_Terminals_Only Table 15 - OSP of the TOE and Security Objectives 50/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.3.2 Rationales for Assumptions 5.3.2.1 A.MRTD_Manufact The assumption A.MRTD_Manufact “MRTD manufacturing on steps 4 to 6” is covered by the security objective for the TOE environment OE.MRTD_Manufact “Protection of the MRTD Manufacturing” that requires to use security procedures during all manufacturing steps. 5.3.2.2 A.MRTD_Delivery The assumption A.MRTD_Delivery “MRTD delivery during steps 4 to 6” is covered by the security objective for the TOE environment OE.MRTD_Delivery “Protection of the MRTD delivery” that requires to use security procedures during delivery steps of the MRTD. 5.3.2.3 A.Pers_Agent The assumption A.Pers_Agent “Personalization of the MRTD’s chip” is covered by the security objective for the TOE environment OE.Personalization “Personalization of logical MRTD” including the enrolment, the protection with digital signature and the storage of the MRTD holder personal data. 5.3.2.4 A.Insp_Sys The examination of the MRTD passport book addressed by the assumption A.Insp_Sys “Inspection Systems for global interoperability” is covered by the security objectives for the TOE environment OE.Exam_MRTD “Examination of the MRTD passport book”. The security objectives for the TOE environment OE.Prot_Logical_MRTD “Protection of data from the logical MRTD will require the Basic Inspection System to implement the Basic Access Control and to protect the logical MRTD data during the transmission and the internal handling. 5.3.2.5 A.Insp_Sys_Chip_Auth The examination of the MRTD passport book addressed by the assumption A.Insp_Sys_Chip_Auth “Inspection Systems for global interoperability on chip authenticity” is covered by the security objectives for the TOE environment OE.Exam_Chip_Auth. 5.3.2.6 A.BAC-Keys The assumption is directly covered by the security objective for the TOE environment OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys” ensuring the sufficient key quality to be provided by the issuing State or Organization. 5.3.2.7 A.Signature_PKI The assumption is directly covered by the security objective for the TOE environment OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature” covering the necessary procedures for the Country Signing CA Key Pair and the Document Signer Key Pairs. 51/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.3.3 Rationales for Threats 5.3.3.1 T.Chip_ID The threat T.Chip_ID “Identification of MRTD’s chip” addresses the trace of the MRTD movement by identifying remotely the MRTD’s chip through the contactless communication interface. This threat is countered as described by the security objective OT.Identification “Identification and Authentication of the TOE” by Basic Access Control using sufficiently strong derived keys as required by the security objective for the environment OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys”. 5.3.3.2 T.Skimming and T.Eavesdropping The threat T.Skimming “Skimming the logical MRTD” and T.Eavesdropping “Eavesdropping to the communication between TOE and inspection system” address the reading of the logical MRTD trough the contactless interface or listening the communication between the MRTD’s chip and a terminal. This threat is countered by the security objective OT.Data_Conf “Confidentiality of personal data” through Basic Access Control using sufficiently strong derived keys as required by the security objective for the environment OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys”. 5.3.3.3 T.Forgery The threat T.Forgery “Forgery of data on MRTD’s chip” addresses the fraudulent alteration of the complete stored logical MRTD or any part of it. The security objective OT.AC_Pers “Access Control for Personalization of logical MRTD” requires the TOE to limit the write access for the logical MRTD to the trustworthy Personalization Agent (cf. OE.Personalization). The TOE will protect the integrity of the stored logical MRTD according the security objective OT.Data_Int “Integrity of personal data” and OT.Prot_Phys-Tamper “Protection against Physical Tampering”. The examination of the presented MRTD passport book according to OE.Exam_MRTD “Examination of the MRTD passport book” shall ensure that passport book does not contain a sensitive contactless chip which may present the complete unchanged logical MRTD. The TOE environment will detect partly forged logical MRTD data by means of digital signature which will be created according to OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature” and verified by the inspection system according to OE.Passive_Auth_Verif “Verification by Passive Authentication”. 5.3.3.4 T.Abuse-Func The threat T.Abuse-Func “Abuse of Functionality” addresses attacks using the MRTD’s chip as production material for the MRTD and misuse of the functions for personalization in the operational state after delivery to MRTD holder to disclose or to manipulate the logical MRTD. This threat is countered by OT.Prot_Abuse-Func “Protection against Abuse of Functionality”. Additionally this objective is supported by the security objective for the TOE environment: OE.Personalization “Personalization of logical MRTD” ensuring that the TOE security functions for the initialization and the personalization are disabled and the security functions for the operational state after delivery to MRTD holder are enabled according to the intended use of the TOE. 5.3.3.5 T.Information_Leakage, T.Phys-Tamper and T.Malfunction The threats T.Information_Leakage “Information Leakage from MRTD’s chip”, T.Phys-Tamper “Physical Tampering” and T.Malfunction “Malfunction due to Environmental Stress” are typical for integrated circuits like smart cards under direct attack with high attack potential. The protection of the TOE against these threats is addressed by the directly related security objectives OT.Prot_Inf_Leak “Protection against Information Leakage”, OT.Prot_Phys-Tamper “Protection against Physical Tampering” and OT.Prot_Malfunction “Protection against Malfunctions”. 5.3.3.6 T.Configuration The threat T.Configuration “Tampering attempt of the TOE during preparation” addresses attacks in Pre- personalization and Personalization phases. The attacker trying to access to unauthorized TOE functions, trying to access or to modify sensitive information exchanged between the TOE and the Personalization system. Protection 52/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 of the TOE during these two phases is directly addressed by OT.Configuration “Protection of the TOE preparation”. OT.TOE_Identification also covers this threat allowing to identify uniquely the Final TOE. 5.3.3.7 T.Counterfeit The threat T.Counterfeit “MRTD’s chip” addresses the attack of unauthorized copy or reproduction of the genuine MRTD chip. This attack is thwarted by chip an identification and authenticity proof required by OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” using a authentication key pair to be generated by the issuing State or Organization. The Public Chip Authentication Key has to be written into EF.DG14 and signed by means of Documents Security Objects as demanded by OE.Auth_MRTD “MRTD Authentication Key”. According to OE.Exam_Chip_Auth the inspection system has to perform the Chip Authentication Protocol to verify the authenticity of the MRTD’s chip. This threat is also covered by OE.Auth_MRTD “MRTD Authentication Key” using a authentication key pair to be generated by the issuing State or Organization. The Public Active Authentication Key has to be written into EF.DG15 and signed by means of Documents Security Objects as demanded by OE.Auth_MRTD “MRTD Authentication Key”. According to OE.Exam_Chip_Auth the inspection system has to perform the Active Authentication Protocol to verify the authenticity of the MRTD’s chip. Threats for Update mechanism 5.3.3.8 T.FaTSF The threat T.FaTSF addresses attacks on the TOE and TSF by an attacker exploiting flaws of the TOE software implementation that manifest themselves after the TOE enters the phase operational usage. This threat is countered by the TOE offering a secure update mechanism; in particular: • The security objective OT.Update_Mechanism “TOE Update Mechanism” counters this threat by ensuring that the TOE has the ability to update the TOE software in a secure manner. • The security objective OT.Attack_Detection “Detection of Attacks on the TOE using the Update Mechanism”ensures that the TOE is able to detect multiple failed update attempts and can take action upon that detection. • The security objective OT.Key_Secrecy “Key Secrecy of Cryptographic Update Keys” makes sure that the required cryptographic key material for the update mechanism cannot be accessed or reconstructed by a malicious attacker. 5.3.3.9 T.UaU The threat T.UaU addresses attacks on the TOE and TSF by an attacker installing unauthorized and potential harmful updates: • The security objective OT.Enc_Sign_Update “Encrypted-then-signed Update Packages” ensures that only signed and encrypted updates are installed by the TOE, and that during the transmission to the TOE, a protocol based on encrypt-then-MAC is used. • The security objective OT.Update_Terminal_Auth “Updates only by authenticated Update Terminals” ensures that only authenticated update terminals are able to read version information, upload update packages on the TOE, and initiate the update procedure. • OT.TOE_Identification “Secure identification of the TOE” also covers this threat allowing to identify uniquely the Final TOE. 53/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5.3.4 Rationales for Organisational Security Policies 5.3.4.1 P.Manufact The OSP P.Manufact “Manufacturing of the MRTD’s chip” requires a unique identification of the IC by means of the Initialization Data and the writing of the Pre-personalization Data as being fulfilled by OT.Identification “Identification and Authentication of the TOE”. 5.3.4.2 P.Personalization The OSP P.Personalization “Personalization of the MRTD by issuing State or Organization only” addresses the (i) the enrolment of the logical MRTD by the Personalization Agent as described in the security objective for the TOE environment OE.Personalization “Personalization of logical MRTD”, and (ii) the access control for the user data and TSF data as described by the security objective OT.AC_Pers “Access Control for Personalization of logical MRTD”. Note the manufacturer equips the TOE with the Personalization Agent Key(s) according to OT.Identification “Identification and Authentication of the TOE”. The security objective OT.AC_Pers “Access Control for Personalization of logical MRTD” limits the management of TSF data and management of TSF to the Personalization Agent. 5.3.4.3 P.Personal_Data The OSP P.Personal_Data “Personal data protection policy” requires the TOE (i) to support the protection of the confidentiality of the logical MRTD by means of the Basic Access Control and (ii) enforce the access control for reading as decided by the issuing State or Organization. This policy is implemented by the security objectives OT.Data_Int “Integrity of personal data” describing the unconditional protection of the integrity of the stored data and during transmission. The security objective OT.Data_Conf “Confidentiality of personal data” describes the protection of the confidentiality. 5.3.4.4 The organizational security policies for Update Mechanism P.Code_Confidentiality, P.Secure_Environment, and P.Eligible_Terminals_Only, address the confidentiality of the code, the way the update procedure must be carried out, and precise control over which terminals are allowed to carry out the update procedure. Each of these policies are enforced through security objectives for the environment of the TOE, namely OE.Code_Confidentiality, OE.Secure_Environment, and OE.Eligible_Terminals_Only. 54/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 6 Extended components definition 6.1 Extendedcomponentsdefinition 6.1.1 Definition of the Family FAU_SAS To define the security functional requirements of the TOE a sensitive family (FAU_SAS) of the Class FAU (Security Audit) is defined here. This family describes the functional requirements for the storage of audit data. It has a more general approach than FAU_GEN, because it does not necessarily require the data to be generated by the TOE itself and because it does not give specific details of the content of the audit records. The family “Audit data storage (FAU_SAS)” is specified as follows. FAU_SAS “Audit data storage” Family behavior This family defines functional requirements for the storage of audit data. Component leveling FAU_SAS.1 Requires the TOE to the possibility to store audit data Management: FAU_SAS.1 There are no management activities foreseen. Audit: FAU_SAS.1 There are no actions defined to be auditable. FAU_SAS.1 “Audit storage” Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide [assignment: authorized users] with the capability to store [assignment: list of audit information] in the audit records. 55/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 6.1.2 Definition of the Family FCS_RND To define the IT security functional requirements of the TOE a sensitive family (FCS_RND) of the Class FCS (cryptographic support) is defined here. This family describes the functional requirements for random number generation used for cryptographic purposes. The component FCS_RND is not limited to generation of cryptographic keys unlike the component FCS_CKM.1. The similar component FIA_SOS.2 is intended for non-cryptographic use. The family “Generation of random numbers (FCS_RND)” is specified as follows. FCS_RND “Generation of random numbers” Family behavior This family defines quality requirements for the generation of random numbers which are intended to be used for cryptographic purposes. Component leveling: FCS_RND.1 Generation of random numbers requires that random numbers meet a defined quality metric. Management: FCS_RND.1 There are no management activities foreseen. Audit: FCS_RND.1 There are no actions defined to be auditable. FCS_RND.1 “Quality metric for random numbers” Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet [assignment: a defined quality metric]. 56/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 6.1.3 Definition of the Family FMT_LIM The family FMT_LIM describes the functional requirements for the Test Features of the TOE. The new functional requirements were defined in the class FMT because this class addresses the management of functions of the TSF. The examples of the technical mechanism used in the TOE show that no other class is appropriate to address the specific issues of preventing the abuse of functions by limiting the capabilities of the functions and by limiting their availability. The family “Limited capabilities and availability (FMT_LIM)” is specified as follows. FMT_LIM “Limited capabilities and availability” Family behavior This family defines requirements that limit the capabilities and availability of functions in a combined manner. Note that FDP_ACF restricts the access to functions whereas the Limited capability of this family requires the functions themselves to be designed in a specific manner. Component leveling: FMT_LIM.1 Limited capabilities requires that the TSF is built to provide only the capabilities (perform action, gather information) necessary for its genuine purpose. FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions (refer to Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by removing or by disabling functions in a specific phase of the TOE’s life-cycle). Management: FMT_LIM.1, FMT_LIM.2 There are no management activities foreseen. Audit: FMT_LIM.1, FMT_LIM.2 There are no actions defined to be auditable. To define the IT security functional requirements of the TOE a sensitive family (FMT_LIM) of the Class FMT (Security Management) is defined here. This family describes the functional requirements for the Test Features of the TOE. The new functional requirements were defined in the class FMT because this class addresses the management of functions of the TSF. The examples of the technical mechanism used in the TOE show that no other class is appropriate to address the specific issues of preventing the abuse of functions by limiting the capabilities of the functions and by limiting their availability. FMT_LIM.1 “Limited capabilities” Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability. FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced [assignment: Limited capability and availability policy]. The TOE Functional Requirement “Limited availability (FMT_LIM.2)” is specified as follows. 57/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 FMT_LIM.2 “Limited availability” 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 policy is enforced [assignment: Limited capability and availability policy]. 6.1.4 Definition of the Family FPT_EMS The sensitive family FPT_EMS (TOE Emanation) of the Class FPT (Protection of the TSF) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against the TOE and other secret data where the attack is based on external observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This family describes the functional requirements for the limitation of intelligible emanations which are not directly addressed by any other component of [CC_2]. The family “TOE Emanation (FPT_EMS)” is specified as follows. Family behavior This family defines requirements to mitigate intelligible emanations. Component levelling: FPT_EMS.1 TOE emanation has two constituents: FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF data or user data. FPT_EMS.1.2 Interface Emanation requires to not emit interface emanation enabling access to TSF data or user data. Management: FPT_EMS.1 There are no management activities foreseen. Audit: FPT_EMS.1 There are no actions defined to be auditable. FPT_EMS.1 “TOE Emanation” Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. FPT_EMS.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to assignment: list of types of TSF data] and [assignment: list of types of user data]. 58/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 6.1.5 Definition of the Family FIA_API To describe the IT security functional requirements of the TOE a sensitive family (FIA_API) of the Class FIA (Identification and authentication) is defined here. This family describes the functional requirements for the proof of the claimed identity for the authentication verification by an external entity where the other families of the class FIA address the verification of the identity of an external entity. FIA_API “Authentication Proof of Identity” Family behavior This family defines functions provided by the TOE to prove their identity and to be verified by an external entity in the TOE IT environment. Component leveling: FIA_API.1 Authentication Proof of Identity. Management: FIA_API.1 The following actions could be considered for the management functions in FMT: Management of authentication information used to prove the claimed identity. Audit: There are no actions defined to be auditable. FIA_API.1 “Authentication Proof of Identity” Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to prove the identity of the [assignment: authorized user or role]. 59/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7 Security requirements 7.1 Security functional requirements This section on security functional requirements for the TOE is divided into sub-section following the main security functionality. This following table provides MRTD SFRs. The SFRs for Update Mechanism are in the next table. SFR in ST SFR in [PP_BAC] Descr. Step Before 5 5 6 7 Class FAU “Security Audit” FAU_SAS.1.1 FAU_SAS.1.1 7.1.1.1 ✓    Class FCS “Cryptographic Support” FCS_CKM.1.1/BAC FCS_CKM.1.1 7.1.2.1    ✓ FCS_CKM.1.1/MSK_DIV Additional SFR  ✓   FCS_CKM.1.1/GP  ✓ ✓  FCS_CKM.1.1/LSK_DIV Additional SFR  ✓   FCS_CKM.1.1/CA Additional SFR    ✓ FCS_CKM.1.1/KEY_GEN Additional SFR  ✓ ✓  FCS_CKM.4.1 FCS_CKM.4.1 7.1.2.2  ✓ ✓ ✓ FCS_COP.1.1/BAC_SHA FCS_COP.1.1/SHA 7.1.2.3    ✓ FCS_COP.1.1/BAC_ENC FCS_COP.1.1/ENC    ✓ FCS_COP.1.1/AUTH FCS_COP.1.1/AUTH   ✓  FCS_COP.1.1/BAC_MAC FCS_COP.1.1/MAC    ✓ FCS_COP.1.1/MSK_SHA Additional SFR  ✓   FCS_COP.1.1/GP_ENC  ✓ ✓  FCS_COP.1.1/GP_AUTH  ✓   FCS_COP.1.1/GP_MAC  ✓ ✓  FCS_COP.1.1/GP_SDT_DEC  ✓ ✓  FCS_COP.1.1/CA_SHA Additional SFR    ✓ FCS_COP.1.1/CA_ENC    ✓ FCS_COP.1.1/CA_MAC    ✓ FCS_COP.1.1/SIG_GEN Additional SFR    ✓ FCS_RND.1.1 FCS_RND.1.1 7.1.2.4  ✓ ✓ ✓ Class FIA “Identification and Authentication” FIA_UID.1.1 FIA_UID.1.1 7.1.3.1  ✓ ✓ ✓ FIA_UID.1.2 FIA_UID.1.2  ✓ ✓ ✓ FIA_UAU.1.1 FIA_UAU.1.1 7.1.3.2  ✓ ✓ ✓ FIA_UAU.1.2 FIA_UAU.1.2  ✓ ✓ ✓ FIA_UAU.4.1 FIA_UAU.4.1 7.1.3.3  ✓ ✓ ✓ FIA_UAU.5.1/BAC FIA_UAU.5.1 7.1.3.4   ✓ ✓ FIA_UAU.5.2/BAC FIA_UAU.5.2   ✓ ✓ FIA_UAU.5.1/MP Additional SFR  ✓   FIA_UAU.5.2/MP  ✓   FIA_UAU.5.1/CA Additional SFR   ✓ ✓ FIA_UAU.5.2/CA   ✓ ✓ FIA_UAU.6.1/BAC FIA_UAU.6.1 7.1.3.5    ✓ FIA_UAU.6.1/MP Additional SFR  ✓ ✓  FIA_UAU.6.1/CA Additional SFR    ✓ FIA_AFL.1.1/BAC FIA_AFL.1.1 7.1.3.6    ✓ FIA_AFL.1.2/BAC FIA_AFL.1.2    ✓ FIA_AFL.1.1/MP Additional SFR  ✓ ✓  FIA_AFL.1.2/MP Additional SFR  ✓ ✓  FIA_API.1.1/CA Additional SFR 7.1.3.7    ✓ FIA_API.1.1/AA Additional SFR    ✓ 60/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SFR in ST SFR in [PP_BAC] Descr. Step Before 5 5 6 7 Class FDP “User Data Protection” FDP_ACC.1.1/BAC FDP_ACC.1.1 7.1.4.1   ✓ ✓ FDP_ACC.1.1/MP Additional SFR  ✓ ✓  FDP_ACC.1.1/ID Additional SFR  ✓ ✓ ✓ FDP_ACF.1.1/BAC FDP_ACF.1.1 7.1.4.2   ✓ ✓ FDP_ACF.1.2/BAC FDP_ACF.1.2   ✓ ✓ FDP_ACF.1.3/BAC FDP_ACF.1.3   ✓ ✓ FDP_ACF.1.4/BAC FDP_ACF.1.4   ✓ ✓ FDP_ACF.1.1/MP Additional SFR  ✓ ✓  FDP_ACF.1.2/MP  ✓ ✓  FDP_ACF.1.3/MP  ✓ ✓  FDP_ACF.1.4/MP  ✓ ✓  FDP_ACF.1.1/ID Additional SFR  ✓ ✓ ✓ FDP_ACF.1.2/ID  ✓ ✓ ✓ FDP_ACF.1.3/ID  ✓ ✓ ✓ FDP_ACF.1.4/ID  ✓ ✓ ✓ FDP_UCT.1.1/BAC FDP_UCT.1.1 7.1.4.3    ✓ FDP_UCT.1.1/MP Additional SFR  ✓ ✓  FDP_UCT.1.1/CA Additional SFR    ✓ FDP_UIT.1.1/BAC FDP_UIT.1.1 7.1.4.4    ✓ FDP_UIT.1.2/BAC FDP_UIT.1.2    ✓ FDP_UIT.1.1/MP Additional SFR  ✓ ✓  FDP_UIT.1.2/MP  ✓ ✓  FDP_UIT.1.1/CA Additional SFR    ✓ FDP_UIT.1.2/CA    ✓ FDP_ITC.1.1/MP Additional SFR 7.1.4.5  ✓ ✓  FDP_ITC.1.2/MP  ✓ ✓  FDP_ITC.1.3/MP  ✓ ✓  Class FMT “Security Management” FMT_MOF.1.1/PROT Additional SFR 7.1.5.1  ✓ ✓  FMT_MOF.1.1/GP  ✓ ✓  FMT_SMF.1.1 FMT_SMF.1.1 7.1.5.2 ✓ ✓ ✓  FMT_SMR.1.1 FMT_SMR.1.1 7.1.5.3  ✓ ✓ ✓ FMT_SMR.1.2 FMT_SMR.1.2  ✓ ✓ ✓ FMT_LIM.1.1 FMT_LIM.1.1 7.1.5.4  ✓ ✓ ✓ FMT_LIM.2.1 FMT_LIM.2.1 7.1.5.5  ✓ ✓ ✓ FMT_MTD.1.1/INI_ENA FMT_MTD.1.1/INI_ENA 7.1.5.6  ✓ ✓ ✓ FMT_MTD.1.1/INI_DIS FMT_MTD.1.1/INI_DIS  ✓ ✓ ✓ FMT_MTD.1.1/KEY_WRITE FMT_MTD.1.1/KEY_WRITE  ✓ ✓ ✓ FMT_MTD.1.1/KEY_READ FMT_MTD.1.1/KEY_READ  ✓ ✓ ✓ FMT_MTD.1.1/MP_KEY_WRITE Additional SFR ✓ ✓ ✓ ✓ FMT_MTD.1.1/MP_KEY_READ ✓ ✓ ✓ ✓ FMT_MTD.1.1/CAPK Additional SFR  ✓ ✓ ✓ FMT_MTD.1.1/CAPK_READ  ✓ ✓ ✓ FMT_MTD.1.1/AA_KEY_WRITE Additional SFR  ✓ ✓ ✓ FMT_MTD.1.1/AA_KEY_READ  ✓ ✓ ✓ FMT_MTD.1.1/LCS_PREP Additional SFR  ✓ ✓ ✓ FMT_MTD.1.1/LCS_PERS  ✓ ✓ ✓ FMT_MTD.1.1/LSK_READ Additional SFR ✓ ✓ ✓ ✓ FMT_MTD.1.1/AA_KEY_GEN Additional SFR  ✓ ✓ ✓ FMT_MTD.1.1/CA_KEY_GEN Additional SFR  ✓ ✓ ✓ Class FPT “Protection of the Security Functions” FPT_EMS.1.1 FPT_EMSEC.1.1 7.1.6.1  ✓ ✓ ✓ FPT_EMS.1.2 FPT_EMSEC.1.2  ✓ ✓ ✓ FPT_FLS.1.1 FPT_FLS.1.1 7.1.6.2  ✓ ✓ ✓ 61/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SFR in ST SFR in [PP_BAC] Descr. Step Before 5 5 6 7 FPT_TST.1.1 FPT_TST.1.1 7.1.6.3  ✓ ✓ ✓ FPT_TST.1.2 FPT_TST.1.2  ✓ ✓ ✓ FPT_TST.1.3 FPT_TST.1.3  ✓ ✓ ✓ FPT_PHP.3.1 FPT_PHP.3.1 7.1.6.4  ✓ ✓ ✓ Class FTP “Trusted path/channels” FTP_ITC.1.1/MP Additional SFR 7.1.7.1  ✓ ✓  FTP_ITC.1.2/MP  ✓ ✓  FTP_ITC.1.3/MP  ✓ ✓  Table 16 – SFR of the TOE The TOE SFR include also the PP module Update Mechanism Post-issuance SFRs mentioned with “/UPD”: These SFRs are available Steps 5 to 7 of life cycle: SFR in ST and in [PP_0090] Descr. Step 3 4 Sch. 1 4 Sch. 2 5 6 7 Class FAU “Security Audit” FAU_SAS.1/UPD 7.1.1.1 ✓  ✓ ✓ ✓ ✓ Class FCS “Cryptographic Support” FCS_CKM.1/UPD_ITC 7.1.2.1 ✓  ✓ ✓ ✓ ✓ FCS_CKM.1/UPD_DEC ✓  ✓ ✓ ✓ ✓ FCS_CKM.1/UPD_INT ✓  ✓ ✓ ✓ ✓ FCS_CKM.4/UPD 7.1.2.2 ✓  ✓ ✓ ✓ ✓ FCS_COP.1/UPD_ITC 7.1.2.3 ✓  ✓ ✓ ✓ ✓ FCS_COP.1/UPD_DEC ✓  ✓ ✓ ✓ ✓ FCS_COP.1/UPD_SIG ✓  ✓ ✓ ✓ ✓ FCS_COP.1/UPD_INT ✓  ✓ ✓ ✓ ✓ Class FIA “Identification and Authentication” FIA_AFL.1/UPD 7.1.3.6 ✓  ✓ ✓ ✓ ✓ FIA_UID.1/UPD 7.1.3.1 ✓  ✓ ✓ ✓ ✓ FIA_UAU.1/UPD 7.1.3.2 ✓  ✓ ✓ ✓ ✓ Class FDP “User Data Protection” FDP_ACC.1/UPD 7.1.4.1 ✓  ✓ ✓ ✓ ✓ FDP_ACF.1/UPD 7.1.4.2 ✓  ✓ ✓ ✓ ✓ FDP_IFC.1/UPD 7.1.4.7 ✓  ✓ ✓ ✓ ✓ FDP_IFF.1/UPD 7.1.4.8 ✓  ✓ ✓ ✓ ✓ FDP_RIP.1/UPD 7.1.4.6 ✓  ✓ ✓ ✓ ✓ Class FMT “Security Management” FMT_SMF.1/UPD 7.1.5.2 ✓  ✓ ✓ ✓ ✓ FMT_MTD.1/UPD_SK_PICC 7.1.5.6 ✓  ✓ ✓ ✓ ✓ FMT_MTD.1/UPD_KEY_READ ✓  ✓ ✓ ✓ ✓ FMT_SMR.1/UPD 7.1.5.3 ✓  ✓ ✓ ✓ ✓ Class FPT “Protection of the Security Functions” FPT_EMS.1 /UPD 7.1.6.1 ✓  ✓ ✓ ✓ ✓ FPT_FLS.1/UPD 7.1.6.2 ✓  ✓ ✓ ✓ ✓ FPT_TST.1/UPD 7.1.6.3 ✓  ✓ ✓ ✓ ✓ FTP_ITC.1/UPD 7.1.7.1 ✓  ✓ ✓ ✓ ✓ Table 17– SFR of the TOE for Update Mechanism 62/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.1 Class FAU “Security Audit” 7.1.1.1 FAU_SAS.1 “Audit Storage” Hierarchical to: No other components. Dependencies: No dependencies FAU_SAS.1.1 The TSF shall provide the Manufacturer with the capability to store the IC Identification Data in the audit records. FAU_SAS.1.1/UPD The TSF shall provide the TOE update functionality with the capability to store update log information and version history, namely the following data objects: Update Package identification and associated hash in the audit records. 7.1.2 Class FCS “Cryptographic Support” 7.1.2.1 FCS_CKM.1 “Cryptographic key generation” Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/ BAC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm Document Basic Access Key Derivation Algorithm and specified cryptographic key sizes 112 bit that meet the following: [ICAO_9303], normative appendix 5. FCS_CKM.1.1/ MSK_DIV The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm MSK derivation from initial MSK, using SHA-256 and specified cryptographic key sizes 256 bit that meet the following: none. Application note: In Step 5, (Master) MSK is diversified during the first command, and then replaced by the derived MSK generated by FCS_CKM.1/MSK_DIV. The secure erasing of the keys is ensured by FCS_CKM.4. FCS_CKM.1.1/ GP The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [Algorithm] and specified cryptographic key sizes [key size(s)] that meet the following: [standard]. Algorithm key size(s) standard Triple-DES in CBC mode 112 bit [GPC_SPE_034]; appendix E.4.1. AES in CBC mode 128, 192 and 256 bit [GPC_SPE_034]; appendix E.4.1. FCS_CKM.1.1/ LSK_DIV The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm LSK derivation from Initial LSK and Derivation Data, using AES 128 ECB and specified cryptographic key sizes 128 bit that meet the following: None. FCS_CKM.1.1/ CA The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [Algorithm] and specified cryptographic key sizes [key size(s)] that meet the following:[standard]. 63/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Algorithm key size(s) standard ECDH compliant to [ISO_15946] 192 to 521 bit [TR_03110] based on the key Diffie- Hellman key derivation protocol compliant to PKCS#3 1024 to 2048 in steps of 256 bits [TR_03110] FCS_CKM.1.1/ KEY_GEN The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [Algorithm] and specified cryptographic key sizes [key size(s)] that meet the following:[standard]. Algorithm key size(s) standard RSA key generation 1024 to 3072 in steps of 256 bits [ICAO_9303] Key pair over Elliptic curve 192 to 521 bit with prime field p [ICAO_9303] FCS_CKM.1.1/ UPD_ITC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [Algorithm] and specified cryptographic key sizes [Key size(s)] that meet the following: [Standard]. Algorithm Key size(s) Standard Triple-DES in CBC mode 112 bit [GPC_SPE_034]; appendix E.4.1 AES in CBC mode 128, 192, 256 bit FCS_CKM.1.1/ UPD_DEC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm LSK derivation from Initial LSK and Derivation Data, using AES 128 ECB and specified cryptographic key sizes 128 bit that meet the following: None. FCS_CKM.1.1/ UPD_INT The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm second LSK derivation from Initial LSK and Derivation Data, using AES 128 ECB and specified cryptographic key sizes 128 bit that meet the following:None. 7.1.2.2 FCS_CKM.4 “Cryptographic key destruction” Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method zeroisation that meets the following: none. Application note: This SFR addresses the destruction of the MSK, ISK, Personalization Key Set and SM sessions keys. FCS_CKM.4.1/UPD The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method zeroisation that meets the following: none. Application note: This SFR addresses the destruction of the diversified LSK keys used for update mechanism sessions. 64/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.2.3 FCS_COP.1 “Cryptographic operation” Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ BAC_SHA The TSF shall perform hashing in accordance with a specified cryptographic algorithm SHA-1 and cryptographic key sizes none that meets the following [FIPS_180_2]. FCS_COP.1.1/ BAC_ENC The TSF shall perform secure messaging (BAC) – encryption and decryption in accordance with a specified cryptographic algorithm Triple-DES in CBC mode and cryptographic key sizes 112 bit that meets the following [FIPS_46_3] and [ICAO_9303]; normative appendix 5, A5.3 [ICAO_9303]. FCS_COP.1.1/ AUTH The TSF shall perform symmetric authentication – encryption and decryption in accordance with a specified cryptographic algorithm Triple-DES and cryptographic key sizes 112 bit that meets the following [FIPS_46_3]. FCS_COP.1.1/ BAC_MAC The TSF shall perform secure messaging – message authentication code in accordance with a specified cryptographic algorithm Retail MAC and cryptographic key sizes 112 bit that meets the following [ISO_9797_1] (MAC algorithm 3, block cipher DES, Sequence Message Counter, padding mode 2). FCS_COP.1.1/ MSK_SHA The TSF shall perform hashing for MSK diversification in accordance with a specified cryptographic algorithm SHA-256 and cryptographic key sizes none that meets the following [FIPS_180_2]. FCS_COP.1.1/ GP_ENC The TSF shall perform secure messaging (GP) – encryption and decryption in accordance with a specified cryptographic algorithm Triple-DES in CBC mode and cryptographic key sizes [key size(s)] that meets the following [standard]. Algorithm key size(s) standard Triple-DES in CBC mode 112 bit [FIPS_46_3] AES in CBC mode 128, 192 and 256 bit [FIPS_197] FCS_COP.1.1/ GP_AUTH The TSF shall perform symmetric authentication – encryption and decryption in accordance with a specified cryptographic algorithm [algorithm] and cryptographic key sizes [key size(s)] that meets the following [standard]. Algorithm key size(s) standard Triple-DES 112 bit [FIPS_46_3] AES 128, 192 and 256 bit [FIPS_197] FCS_COP.1.1/ GP_MAC The TSF shall perform secure messaging – message authentication code in accordance with a specified cryptographic algorithm [algorithm] and cryptographic key sizes [key size(s)] that meets the following [standard]. Algorithm key size(s) standard MAC Algorithm 1 with Padding M2 112 bit [ISO_9797_1] AES CMAC 128, 192 and 256 bit [NIST_800_38B] 65/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 FCS_COP.1.1/ GP_SDT_DEC The TSF shall perform sensitive data decryption in accordance with a specified cryptographic algorithm [algorithm]and cryptographic key sizes [key size(s)] that meets the following [standard]. Algorithm key size(s) standard Triple-DES in CBC mode 112 bit [FIPS_46_3] AES in CBC mode 128, 192 and 256 bit [FIPS_197] FCS_COP.1.1/ CA_SHA The TSF shall perform hashing in accordance with a specified cryptographic algorithm SHA-1 and SHA-256 and cryptographic key sizes none that meets the following [FIPS_180_2]. FCS_COP.1.1/ CA_ENC The TSF shall perform secure messaging – encryption and decryption in accordance with a specified cryptographic algorithm [algorithm] and cryptographic key sizes [key size(s)] that meets the following [standard]. Algorithm key size(s) standard Triple-DES in CBC mode 112 bit [FIPS_46_3] AES in CBC mode 128, 192 and 256 bit [FIPS_197] FCS_COP.1.1/ CA_MAC The TSF shall perform secure messaging – message authentication code in accordance with a specified cryptographic algorithm [algorithm] and cryptographic key sizes [key size(s)] that meets the following [standard]. Algorithm key size(s) standard Retail MAC 112 bit [ISO_9797_1] AES CMAC 128, 192 and 256 bit [NIST_800_38B] FCS_COP.1.1/ SIG_GEN The TSF shall perform Digital Signature Creation in accordance with a specified cryptographic algorithm [Algorithm] and cryptographic key sizes [key size(s)] that meet the following [standard]. Algorithm key size(s) standard RSA signature CRT with SHA-1, SHA-224,SHA-256, SHA-384 and SHA-512 1024 to 4096 in steps of 256 bits [ISO_9796_2] ECDSA with SHA-1, SHA- 224,SHA-256, SHA-384 and SHA- 512 192 to 521 bit [TR_03111] FCS_COP.1.1/ UPD_ITC Cryptographic Operation – Inter Trusted Channel The TSF shall perform secure messaging – message authentication code in accordance with a specified cryptographic algorithm [Algorithm] and cryptographic key sizes [Key size(s)] that meets the following [Standard]. Algorithm Key size(s) Standard AES CMAC 128 bit [NIST_800_38B] FCS_COP.1.1/UPD_D EC Cryptographic Operation – Decryption of Update Packages The TSF shall perform decryption of update package in accordance with a specified cryptographic algorithm AES in CBC mode and cryptographic key sizes 128 bit that meets the following [FIPS_197] 66/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 FCS_COP.1.1/UPD_S IG Cryptographic Operation – Signature Verification of Update Packages The TSF shall perform digital signature verification in accordance with a specified cryptographic algorithm checksum verification and cryptographic key sizes 256 bit that meet the following none. Application Note: 3 checksums SHA-256 provided by FCS_COP.1.1/UPD_INT are verified. FCS_COP.1.1/ UPD_INT Cryptographic Operation – Integrity Verification of Update Package The TSF shall perform integrity verification of update packages in accordance with a specified cryptographic algorithm SHA-256 and cryptographic key sizes none that meets the following [FIPS_186_5]. 7.1.2.4 FCS_RND.1 “Quality metric for random numbers” Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet: 1. The requirement for random number generation following [SP800-90A] standard and [ANSSI-PG-083] recommendations.. 67/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.3 Class FIA “Identification and Authentication” 7.1.3.1 FIA_UID.1 “Timing of identification” Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1 The TSF shall allow 1. to read the Initialization Data in Phase 2 “Manufacturing”, 2. to read the random identifier in Phase 3 “Personalization of the MRTD”, 3. to read the random identifier in Phase 4 “Operational Use” 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. FIA_UID.1.1/UPD The TSF shall allow 1. to establish a communication channel, 2. to authenticate an update terminal by GP authentication on behalf of the user to be performed before the user is identified. FIA_UID.1.2/UPD The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 7.1.3.2 FIA_UAU.1 “Timing of authentication” Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.1.1 The TSF shall allow 1. to read the Initialization Data in Phase 2 “Manufacturing”, 2. to read the random identifier in Phase 3 “Personalization of the MRTD”, 3. to read the random identifier in Phase 4 “Operational Use” 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. FIA_UAU.1.1/UPD The TSF shall allow 1. to establish a communication channel, 2. to authenticate an update terminal by GP authenticate. 3. to read the Initialization Data if it is not disable by TSF according to FMT_MTD.1/UPD_SK_PICC, on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/UPD The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 68/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.3.3 FIA_UAU.4 “Single-use authentication mechanisms” Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to 1. Basic Access Control Authentication Mechanism, 2. Authentication Mechanisms based on: • Triple-DES, • AES Application Note: The Authentication Mechanisms based on Triple-DES or AES is the authentication process performed in phases 5 and 6. 69/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.3.4 FIA_UAU.5 “Multiple authentication mechanisms” Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/ BAC The TSF shall provide 1. Basic Access Control Authentication Mechanism, 2. Authentication Mechanism based on: • Triple-DES, • AES To support user authentication. FIA_UAU.5.2/ BAC The TSF shall authenticate any user’s claimed identity according to the following rules: 1. The TOE accepts the authentication attempt as Personalization Agent by one of the following mechanism(s) the Symmetric Authentication Mechanism with the Personalization Agent Key, 2. The TOE accepts the authentication attempt as Basic Inspection System only by means of the Basic Access Control Authentication Mechanism with the Document Basic Access Keys. FIA_UAU.5.1/ MP The TSF shall provide 1. Authentication Mechanism based on: • Triple-DES, • AES To support user authentication. FIA_UAU.5.2/ MP The TSF shall authenticate any user’s claimed identity according to the following rules: 1. The TOE accepts the authentication attempt as Manufacturer by the Symmetric Authentication Mechanism with Pre-personalization Agent Key. FIA_UAU.5.1/ CA The TSF shall provide 1. Secure messaging in MAC-ENC mode, To support user authentication. FIA_UAU.5.2/ CA The TSF shall authenticate any user’s claimed identity according to the following rules: 1. After run of the Chip Authentication Protocol the TOE accepts only received commands with correct message authentication code sent by means of secure messaging with key agreed with the terminal by means of the Chip Authentication Mechanism 70/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.3.5 FIA_UAU.6 “Re-authenticating” Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/ BAC The TSF shall re-authenticate the user under the conditions each command sent to the TOE during a BAC mechanism based communication after successful authentication of the terminal with Basic Access Control Authentication Mechanism. FIA_UAU.6.1/ MP The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful authentication of the terminal with the Symmetric Authentication Mechanism shall be verified as being sent by the authenticated terminal. Application note This requirement applies to the authentication protocol used by (1) the Manufacturer and (2) the Personalization Agent FIA_UAU.6.1/ CA The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authentication Protocol shall be verified as being sent by the inspection system. 7.1.3.6 FIA_AFL.1 “Authentication failure handling” Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication. FIA_AFL.1.1/ BAC The TSF shall detect when an administrator configurable positive integer within range of acceptable values 0 to 255 consecutive unsuccessful authentication attempts occur related to BAC authentication protocol. FIA_AFL.1.2/ BAC When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall wait for an increasing time between receiving of the terminal challenge and sending of the TSF response during the BAC authentication attempts. FIA_AFL.1.1/ MP The TSF shall detect when 3 unsuccessful authentication attempts occur related to authentication of the Manufacturer and the Personalization Agent. FIA_AFL.1.2/ MP When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall wait for an increasing time between receiving of the terminal challenge and sending of the TSF response during the Authentication Mechanisms (based on Triple-DES or AES) attempts. FIA_AFL.1.1/ UPD The TSF shall detect when 3 unsuccessful update attempts occurs related to authentication of the Manufacturer and the Update Agent. FIA_AFL.1.2/ UPD When the defined number of unsuccessful authentication attempts has been met, the TSF shall wait for an increasing time between receiving of the terminal challenge and sending of the TSF response during the Update authentication attempts. 71/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.3.7 FIA_API.1 “Authentication Proof of Identity” Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/ CA The TSF shall provide a Chip Authentication protocol according to [ICAO_9303] to prove the identity of the TOE. FIA_API.1.1/ AA The TSF shall provide an Active Authentication protocol according to [ICAO_9303] to prove the identity of the TOE. 7.1.4 Class FDP “User Data Protection” 7.1.4.1 FDP_ACC.1 “Subset access control” Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/ BAC The TSF shall enforce the Basic Access Control SFP on terminals gaining write, read and modification access to data in the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD. FDP_ACC.1.1/ MP The TSF shall enforce the GP Access Control SFP on terminals gaining write, read and modification access to the CPLC, the Pre-Perso_K, the Perso_K, the LCS, the Configuration Data, the Update Package, the Active Authentication Keys (AA_PK and AA_SK) and the Chip Authentication Keys (CA_PK and CA_SK). FDP_ACC.1.1/ ID The TSF shall enforce the ID Access Control SFP on terminals gaining write, read and modification access to the CPLC and the TOE_ID. FDP_ACC.1/UPD Subset Access Control – Terminal Access The TSF shall enforce the Update Access Control SFP on 1) Subjects: a)terminal, b)update terminal. 2 )Objects: a)version information identifying the TOE software b)update package c)update log information 3 )Operations: a)reading out version information, b)reading out log data, c)uploading an update package on the TOE, or d)initiating an update procedure and none5 . 5 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 72/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.4.2 FDP_ACF.1 “Basic Security attribute based access control” Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/ BAC The TSF shall enforce the Basic Access Control SFP to objects based on the following: 1. Subjects: a. Personalization Agent, b. Basic Inspection System, c. Terminal, 2. Objects: a. data EF.DG1 to EF.DG16 of the logical MRTD, b. data in EF.COM, c. data in EF.SOD, 3. Security attributes a. authentication status of terminals. FDP_ACF.1.2/ BAC The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 1. the successfully authenticated Personalization Agent is allowed to write and read the data of the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD, 2. the successfully authenticated Basic Inspection System is allowed to read the data in EF.COM, EF.SOD, EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 of the logical MRTD. FDP_ACF.1.3/ BAC The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/ BAC The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. Any terminal is not allowed to modify any of the EF.DG1 to EF.DG16 of the logical MRTD, 2. Any terminal is not allowed to read any of the EF.DG1 to EF.DG16 of the logical MRTD, 3. The Basic Inspection System is not allowed to read the data in EF.DG3 and EF.DG4. FDP_ACF.1.1/ MP The TSF shall enforce the GP Access Control SFP to objects based on the following 1. Subjects: a. Manufacturer, b. Personalization Agent, 2. Objects: a. the Pre-Perso_K, b. the Perso_K, c. the LCS, d the Configuration Data, e the Update Package f. the Active Authentication Private Key g. the Active Authentication Public Key 73/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 h. the Chip Authentication Private Key i. the Chip Authentication Public Key 3. Security attributes a. authentication status of the Manufacturer, b. authentication status of the Personalization Agent. FDP_ACF.1.2/ MP The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 1. the Manufacturer is allowed to write the Pre-Perso_K, the Perso_K, the LCS and the Configuration Data, 2. the Manufacturer is allowed to read the Configuration Data and the LCS, 3. the Personalization Agent is allowed to write the Perso_K, the LCS and the Configuration Data, 4. the Personalization Agent is allowed to read the Configuration Data and the LCS, 5. the Manufacturer is allowed to load and activate the Update Package, 6. the Personalization Agent is allowed to import the Active Authentication Private Key, 7. the Personalization Agent is allowed to generate the Active Authentication Private Key and the Active Authentication Public Key 8. the Personalization Agent is allowed to import the Chip Authentication Private Key, 9. the Personalization Agent is allowed to generate the Chip Authentication Private Key and the Chip Authentication Public Key. FDP_ACF.1.3/ MP The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/ MP The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. FDP_ACF.1.1/ ID The TSF shall enforce the ID Access Control SFP to objects based on the following 1. Subjects: a. Manufacturer, b. Personalization Agent, c. Basic Inspection System, d. Terminal, 2. Objects: a. the TOE_ID, b. the CPLC, 3. Security attributes a. authentication status of the Manufacturer, b. authentication status of the Personalization Agent, c. authentication status of the Basic Inspection System. FDP_ACF.1.2/ ID The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 1. the Manufacturer is allowed to write and read the CPLC, 2. the Personalization Agent is allowed to write and read the CPLC, 3. the Basic Inspection System is allowed to read the CPLC, 74/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 FDP_ACF.1.3/ ID The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none FDP_ACF.1.4/ ID The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. Any Terminal is not allowed to read the CPLC and the TOE_ID, 2. Any Terminal is not allowed to modify the CPLC, FDP_ACF.1.1/UPD Security Attribute based Access Control – Terminal Access The TSF shall enforce the Update Access Control SFP to objects based on the following: 1. Subjects: a)terminal, b)update terminal 2. Objects: a)version information identifying the TOE software b)update package c)update log information 3. Security attributes: a)access rights 4. none. FDP_ACF.1.2/UPD The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: The authentication level of a terminal must be determined by GP authenticate as required by FIA_UAU.1/UPD. Depending on the authentication level, an authenticated update terminal is allowed one or more of the following: –read one or more data objects from FDP_ACF.1/UPD –upload an update package to the TOE and initiate the update procedure. The precise definition of access rights and how the authentication level is calculated from an authenticated terminal is defined in AGD_PRE. FDP_ACF.1.3/UPD The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/UPD The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. 75/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.4.3 FDP_UCT.1 “Basic data exchange confidentiality” Hierarchical to: No other components. Dependencies: [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] FDP_UCT.1.1/ BAC The TSF shall enforce the Basic Access Control SFP to transmit and receive user data in a manner protected from unauthorised disclosure. FDP_UCT.1.1/ MP The TSF shall enforce the GP Access Control SFP to transmit and receive user data in a manner protected from unauthorised disclosure. Application Note: Additional SFR FDP_UCT.1/MP enforces confidentiality of data import and export in steps 5 and 6. FDP_UCT.1.1/ CA The TSF shall enforce the CA Access Control SFP to be able to transmit and receive user data in a manner protected from unauthorized disclosure after Chip Authentication. 76/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.4.4 FDP_UIT.1 “Data exchange integrity” Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_UIT.1.1/ BAC The TSF shall enforce the Basic Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay errors. FDP_UIT.1.2/ BAC The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred. FDP_UIT.1.1/ MP The TSF shall enforce the GP Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay errors. FDP_UIT.1.2/ MP The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred. Application Note: Additional SFR FDP_UIT.1/MP enforces integrity of data import and export in steps 5 and 6. FDP_UIT.1.1/ CA The TSF shall enforce the CA Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay errors after Chip Authentication protocol FDP_UIT.1.2/ CA The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred after Chip Authentication protocol. 77/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.4.5 FDP_ITC.1 “Import of user data without security attributes” Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.3 Static attribute initialisation FDP_ITC.1.1/ MP The TSF shall enforce the GP Access Control SFP when importing user data, controlled under the SFP, from outside the TOE. FDP_ITC.1.2/ MP The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3/ MP The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: sensitive data (Pre-Perso_K, Perso_K, BAC_K, CA_SK and AA_SK) shall be encrypted. Application Note: Additional SFR FDP_ITC.1/MP enforces confidentiality of sensitive data import in steps 5 and 6. 7.1.4.6 FDP_RIP.1 “Subset residual information protection” Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1/UPD The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects: 1) session keys (immediately after closing related communication session), 2) all ephemeral keys DIV_LSK and DIV2_LSK related to the update mechanism. 3) Update package, decrypted update data and meta-data uploaded to the TOE or generated during the update procedure. 4) none. 7.1.4.7 FDP_IFC.1/UPD “Subset information flow control Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFF.1 Simple security attributes, fulfilled by FDP_IFF.1/UPD] FDP_IFC.1.1/UPD The TSF shall enforce the Update Flow Control SFP on the following: 1. Subjects: a) terminal, b) update terminal. 2. information: a) update package b) update data c) meta-data, such as version information 78/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 3. operations: a) performing an update. 7.1.4.8 FDP_IFF.1/UPD “Simple security attributes”. Hierarchical to: No other components. Dependencies: FDP_IFC.1 Subset information flow control: fulfilled by FDP_IFC.1/UPD FDP_IFF.1.1/UPD The TSF shall enforce the Update Control SFP based on the following types of subject and information security attributes: 1. Subjects: a) terminal, b) update terminal. 2. information: a) update package b) update data c) meta-data, such as version information 3. security attributes: a) update package verification status with the values: NOT VERIFIED (default status), SUCCESSFULLY VERIFIED, and VERIFICATION FAILED. FDP_IFF.1.2/UPD The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: 1. The terminal has established a secure channel with the TOE. 2. The TOE shall only accept update packages sent via a secure channel established with an authenticated update terminal. FDP_IFF.1.3/UPD The TSF shall enforce the following rules in their specific order: 1) The integrity (using the keyed or unkeyed hash function cf. FCS_COP.1/UPD_INT) and authenticity (using the digital signature, cf. FCS_COP.1/UPD_SIG) of the first part of the update package is verified. If the integrity and authenticity are not both validated, abort with VERIFICATION FAILED, and erase all data transferred so far, cf. FDP_RIP.1. 2) The first part of the update package is only decrypted, cf. FCS_COP.1/UPD_DEC, if the integrity and authenticity of the that part has been verified in rule 1. If the decryption fails, abort with VERIFICATION FAILED, and erase all data transferred so far, cf. FDP_RIP.1. 3) If all parts of the update package have been decrypted, continue with rule 4. Otherwise, apply rules 1. and 2. on the remaining parts (replace 'first part' with 'current part' above) until either all parts have been decrypted, or the procedure has been aborted with VERIFICATION FAILED. 4) If additional meta-data is stored in the update package Signature of the update package is not verified as correct according to SHA-256 signature the security attribute is set to VERIFICATION FAILED and the update package including all associated data are destroyed, cf. FDP_RIP.1. Correctness w.r.t. the referenced technical specification must not contradict any of the given rules here. 79/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 5) Next, the TSF shall verify that: a) the version number of the update package must be greater than the version of the installed corresponding software package; b) the update data are suitable to the specific TOE configuration/platform by checking relevant meta-data ( i.e. TOE product identifier, version number etc.). If all conditions in step 5 are verified, the verification status is set to SUCCESSFULLY VERIFIED. Otherwise abort with VERIFICATION FAILED, and erase all data transferred so far, cf. FDP_RIP.1. Only if the verification status is SUCCESSFULLY VERIFIED, the TOE shall install the update data. FDP_IFF.1.4/UPD The TSF shall explicitly authorize an information flow based on the following rules: none FDP_IFF.1.5/UPD The TSF shall explicitly deny an information flow based on the following rules: none. 7.1.5 Class FMT “Security Management” 7.1.5.1 FMT_MOF “Management of functions in TSF” Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MOF.1.1/ PROT The TSF shall restrict the ability to enable the functions - Active Authentication, - Chip Authentication v1, - Chip Authentication v1 through MSE: Set KAT to the Manufacturer. FMT_MOF.1.1/ GP The TSF shall restrict the ability to enable the functions - transmission of user data in a manner protected from unauthorised disclosure, - reception of user data in a manner protected from unauthorised disclosure, - transmission of user data in a manner protected from modification, deletion, insertion and replay errors, - reception of user data in a manner protected from modification, deletion, insertion and replay errors, to the Manufacturer and the Personalization Agent. 80/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.5.2 FMT_SMF.1 “Specification of Management Functions” Hierarchical to: No other components. Dependencies: No Dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 1. Initialization 2. Pre-personalization 3. Personalization FMT_SMF.1.1/UPD The TSF shall provide the TOE update functionality with the capability to store update log information and version history, namely the following data objects: Update Package identification and associated hashin the audit records. 7.1.5.3 FMT_SMR.1 “Security roles” Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification. FMT_SMR.1.1 The TSF shall maintain the roles: 1. Manufacturer 2. Personalization Agent 3. Basic Inspection System FMT_SMR.1.2 The TSF shall be able to associate users with roles. FMT_SMR.1.1/UPD The TSF shall maintain the roles: 1. Terminal, 2. Update terminal, 3. Update key installation agent FMT_SMR.1.2/UPD The TSF shall be able to associate users with roles. Note This SFR also applies to the refinement of the role Manufacturer. 7.1.5.4 FMT_LIM.1 “Limited capabilities” Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability. FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow 1. User Data to be disclosed or manipulated, 2. TSF data to be disclosed or manipulated, 3. software to be reconstructed and, 4. substantial information about construction of TSF to be gathered which may enable other attacks. 81/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.5.5 FMT_LIM.2 “Limited availability” 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 policy is enforced: Deploying Test Features after TOE Delivery does not allow 1. User Data to be disclosed or manipulated, 2. TSF data to be disclosed or manipulated, 3. software to be reconstructed and, 4. substantial information about construction of TSF to be gathered which may enable other attacks. 7.1.5.6 FMT_MTD.1 “Management of TSF data” Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/ INI_ENA The TSF shall restrict the ability to write the Initialization Data and Pre- personalization Data to the Manufacturer. FMT_MTD.1.1/ INI_DIS The TSF shall restrict the ability to disable read access for users to the Initialization Data to the Personalization Agent. FMT_MTD.1.1/ KEY_WRITE The TSF shall restrict the ability to write the Document Basic Access Keys to the Personalization Agent. FMT_MTD.1.1/ KEY_READ The TSF shall restrict the ability to read the Document Basic Access Keys and Personalization Agent Keys to none. FMT_MTD.1.1/ MP_KEY_WRITE The TSF shall restrict the ability to write the Pre-personalization Agent Keys and the Personalization Agent Keys to the Manufacturer. FMT_MTD.1.1/ MP_KEY_READ The TSF shall restrict the ability to read the Pre-personalization Agent Keys and the Personalization Agent Keys to none. FMT_MTD.1.1/ CAPK The TSF shall restrict the ability to write the Chip Authentication Keys to the Personalization Agent. FMT_MTD.1.1/ CAPK_READ The TSF shall restrict the ability to read the Chip Authentication Private Key to none. FMT_MTD.1.1/ AA_KEY_WRITE The TSF shall restrict the ability to write the Active Authentication Keys to the Personalization Agent. FMT_MTD.1.1/ AA_KEY_READ The TSF shall restrict the ability to read the Active Authentication Private Keys to none. FMT_MTD.1.1/ LCS_PREP The TSF shall restrict the ability to switch the LCS from phase 5 to phase 6 to the Manufacturer. FMT_MTD.1.1/ LCS_PERS The TSF shall restrict the ability to switch the LCS from phase 6 to phase 7 to the Personalization Agent. 82/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 FMT_MTD.1.1/ LSK_READ The TSF shall restrict the ability to read the Load Secure Key to none. FMT_MTD.1.1/ AA_KEY_GEN The TSF shall restrict the ability to generate the Active Authentication Keys (AA_PK and AA_SK) to the Personalization Agent. FMT_MTD.1.1/ CA_KEY_GEN The TSF shall restrict the ability to generate the Chip Authentication Keys (CA_PK and CA_SK) to the Personalization Agent. FMT_MTD.1.1/ CA_KEY_GEN The TSF shall restrict the ability to generate the Chip Authentication Keys (CA_PK and CA_SK) to the Personalization Agent. FMT_MTD.1.1/UPD_SK_PICC The TSF shall restrict the ability to create, load the LSK to the update key installation agent FMT_MTD.1.1/UPD_KEY_READ The TSF shall restrict the ability to read the 1)LSK 2)DIV_LSK and DIV2_LSK to none. 7.1.6 Class FPT “Protection of the Security Functions” 7.1.6.1 FPT_EMS.1 “TOE Emanation” Hierarchical to: No other components. Dependencies: No Dependencies. FPT_EMS.1.1 The TOE shall not emit power variations, timing variations during command execution in excess of non useful information enabling access to Personalization Agent Keys and : - Personal Data including Biometric Data, - EF.COM, - EF.SOD, - Chip Authentication Private Key, - Chip Authentication Public Key, - Active Authentication Private Key, - Active Authentication Public Key, - CPLC, - TOE_ID, - Pre-personalization Agent Keys, - BAC Keys, - Secure Messaging Session Keys, - TOE Life Cycle State, - Configuration Data. FPT_EMS.1.2 The TSF shall ensure any unauthorized users are unable to use the following interface smart card circuit contacts to gain access to Personalization Agent Keys and: - Personal Data including Biometric Data, - EF.COM, - EF.SOD, - Chip Authentication Private Key, - Chip Authentication Public Key, - Active Authentication Private Key, - Active Authentication Public Key, 83/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 - CPLC, - TOE_ID, - Pre-personalization Agent Keys, - BAC Keys, - Secure Messaging Session Keys, - TOE Life Cycle State, - Configuration Data, FPT_EMS.1.1/UPD The TOE shall not emit power variations, timing variations during command execution in excess of non useful information enabling access to 1. Update Package ID, 2. The LSK, derived LSK, derived MSK, 3. Secure Messaging Session Keys, 4. Update Package signature Keys. FPT_EMS.1.2/UPD The TSF shall ensure any users are unable to use the following interface electronic document ’s contactless/contact-based interface and circuit contacts to gain access to 1. Update Package ID, 2. The LSK, DIV_LSK, DIV2_LSK, derived MSK 3. Secure Messaging Session Keys, and Update Package signature Keys. 7.1.6.2 FPT_FLS.1 “Failure with preservation of secure state” Hierarchical to: No other components. Dependencies: No Dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: 1. Exposure to out-of-range operating conditions where therefore a malfunction could occur, 2. failure detected by TSF according to FPT_TST.1. FPT_FLS.1.1/UPD The TSF shall preserve a secure state when the following types of failures occur: 1. Failure during a transmission of the update package data file 2. Failure detected by TSF according to FPT_TST.1 3. Failure detected after a failed update 7.1.6.3 FPT_TST.1 “TSF testing” Hierarchical to: No other components. Dependencies: No Dependencies. FPT_TST.1.1 The TSF shall run a suite of self tests at the conditions - At reset, - Before any cryptographic operation, - When accessing a DG or any EF, - Prior to any use of TSF data, - Before execution of any command, 84/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 - When performing a BAC authentication, - When performing the Chip Authentication, - When performing the Active Authentication. To demonstrate the correct operation of the TSF. FPT_TST.1.1/UPD The TSF shall run a suite of self tests at the conditions 1. during initial start-up, 2. after a software update To demonstrate the correct operation of the TSF. FPT_TST.1.2/UPD The TSF shall provide authorised users with the capability to verify the integrity of TSF data. FPT_TST.1.3/UPD The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code. 7.1.6.4 FPT_PHP.3 “Resistance to physical attack” Hierarchical to: No other components. Dependencies: No Dependencies. FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing to the TSF by responding automatically such that the SFRs are always enforced. 85/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.1.7 Class FTP “Trusted path/channels” 7.1.7.1 FTP_ITC.1 “Inter-TSF trusted channel” Hierarchical to: No other components. Dependencies: No Dependencies. FTP_ITC.1.1/ MP The TSF shall provide a communication channel between 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/ MP The TSF shall permit another trusted IT product to initiate communication via the trusted channel. FTP_ITC.1.3/ MP The TSF shall initiate communication via the trusted channel for loading sensitive data (Pre-Perso_K, Perso_K, BAC_K, CA_SK and AA_SK) shall be encrypted. FTP_ITC.1.1/UPD The TSF shall provide a communication channel between itself and an update terminal that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2/UPD The TSF shall permit an update terminal to initiate communication via the trusted channel. FTP_ITC.1.3/UPD The TSF shall enforce communication via the trusted channel for any data exchange between the TOE and the Terminal. 86/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.2 Security assurance requirements The assurance components for the evaluation of the TOE and its development and operating environment are those taken from the Evaluation Assurance Level 4 (EAL4) and augmented by taking the following component: ADV_IMP.2, ADV_INT.3 , ADV_TDS.5, ALC_CMC.5, ALC_TAT.3, ATE_COV.3, ATE_FUN.2, ALC_FLR.3, . 7.2.1 EAL rationale The EAL4 was chosen to permit a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. EAL4 is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur sensitive security specific engineering costs. 7.2.2 EAL augmentation rationale 7.2.2.1 ALC_DVS.2 "Sufficiency of security measures" The selection of the component ALC_DVS.2 provides a higher assurance of the security of the MRTD’s development and manufacturing especially for the secure handling of the MRTD’s material. The component ALC_DVS.2 augmented to EAL4 has no dependencies to other security requirements 7.2.2.2 ADV_FSP.5 “Complete semi-formal functional specification with additional error information” The TOE actually target an EAL4 + with AVA_VAN.5 and is only limited to EAL4+ due to the restriction of [PP_BAC] on AVA_VAN level. Other MRTDs TOE are targeting the same physical scope are not affected by this limitation and provide the full EAL5+ set of SARs. This EAL5+ is required to reach a higher level of assurance due to sensitivity of ID documents. 7.2.2.3 ADV_INT.2 “Well-structured internals” The TOE actually target an EAL5 + with AVA_VAN.5 and is only limited to EAL4+ due to the restriction of [PP_BAC] on AVA_VAN level. Other MRTDs TOE are targeting the same physical scope are not affected by this limitation and provide the full EAL5+ set of SARs. This EAL5+ is required to reach a higher level of assurance due to sensitivity of ID documents. 7.2.2.4 ADV_TDS.5 “Semiformal modular design” The TOE actually target an EAL5 + with AVA_VAN.5 and is only limited to EAL4+ due to the restriction of [PP_BAC] on AVA_VAN level. Other MRTDs TOE are targeting the same physical scope are not affected by this limitation and provide the full EAL5+ set of SARs. This EAL5+ is required to reach a higher level of assurance due to sensitivity of ID documents. 7.2.2.5 ALC_CMS.5 “Development tools CM coverage” The TOE actually target an EAL5 + with AVA_VAN.5 and is only limited to EAL4+ due to the restriction of [PP_BAC] on AVA_VAN level. Other MRTDs TOE are targeting the same physical scope are not affected by this limitation and provide the full EAL5+ set of SARs. This EAL5+ is required to reach a higher level of assurance due to sensitivity of ID documents. 87/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.2.2.6 ALC_TAT.2 “Compliance with implementation standards” The TOE actually target an EAL5 + with AVA_VAN.5 and is only limited to EAL4+ due to the restriction of [PP_BAC] on AVA_VAN level. Other MRTDs TOE are targeting the same physical scope are not affected by this limitation and provide the full EAL5+ set of SARs. This EAL5+ is required to reach a higher level of assurance due to sensitivity of ID documents. 7.2.2.7 ATE_DPT.3 “Testing: modular design” The TOE actually target an EAL5 with AVA_VAN.5 and is only limited to EAL4+ due to the restriction of [PP_BAC] on AVA_VAN level. Other MRTDs TOE are targeting the same physical scope are not affected by this limitation and provide the full EAL5+ set of SARs. This EAL5+ is required to reach a higher level of assurance due to sensitivity of ID documents. 7.2.3 Dependencies SAR Dependencies Support of the Dependencies ADV_ARC.1 ADV_FSP.1 ADV_TDS.1 ADV_FSP.5 ADV_TDS.5 ADV_FSP.5 ADV_TDS.1 ADV_IMP.1 ADV_TDS.5 ADV_IMP.2 ADV_IMP.2 ADV_TDS.3 ALC_TAT.1 ALC_CMC.5 ADV_TDS.5 ALC_TAT.3 ALC_CMC.5 ADV_INT.3 ADV_IMP.1 ADV_TDS.3 ALC_TAT.1 ADV_IMP.2 ADV_TDS.5 ALC_TAT.3 ADV_TDS.5 ADV_FSP.5 ADV_FSP.5 AGD_OPE.1 ADV_FSP.1 ADV_FSP.5 AGD_PRE.1 No dependencies n.a. ALC_CMC.5 ALC_CMS.1 ALC_DVS.2 ALC_LCD.1 ALC_CMS.5 ALC_DVS.2 ALC_LCD.1 ALC_CMS.5 No dependencies n.a. ALC_DEL.1 No dependencies n.a. ALC_DVS.2 No dependencies n.a. ALC_LCD.1 No dependencies n.a. ALC_TAT.3 ADV_IMP.1 ADV_IMP.2 ASE_CCL.1 ASE_INT.1 ASE_ECD.1 ASE_REQ.1 ASE_INT.3 ASE_ECD.1 ASE_REQ.2 ASE_ECD.1 No dependencies n.a. ASE_INT.1 No dependencies n.a. ASE_OBJ.2 ASE_SPD.1 ASE_SPD.1 ASE_REQ.2 ASE_OBJ.2 ASE_ECD.1 ASE_OBJ.2 ASE_ECD.1 ASE_SPD.1 No dependencies n.a. ASE_TSS.1 ASE_INT.1 ASE_REQ.1 ADV_FSP.1 ASE_INT.3 ASE_REQ.2 ADV_FSP.5 ATE_COV.3 ADV_FSP.2 ATE_FUN.2 ADV_FSP.5 ATE_FUN.2 ATE_DPT.3 ADV_ARC.1 ADV_TDS.4 ATE_FUN.1 ADV_ARC.1 ADV_TDS.5 ATE_FUN.2 ATE_FUN.2 ATE_COV.1 ATE_COV.3 88/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SAR Dependencies Support of the Dependencies ATE_IND.2 ADV_FSP.2 AGD_OPE.1 AGD_PRE.1 ATE_COV.1 ATE_FUN.1 ADV_FSP.5 AGD_OPE.1 AGD_PRE.1 ATE_COV.3 ATE_FUN.2 AVA_VAN.3 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.5 ADV_TDS.5 ADV_IMP.2 AGD_OPE.1 AGD_PRE.1 ATE_DPT.3 ALC_FLR.3 No dependencies n.a. Table 18 - SARs dependencies 89/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.3 Security requirements rationale 7.3.1 Security Functional Requirements Rationale 7.3.1.1 Overview The following table provides an overview for security functional requirements coverage. The rational for Update mechanism is in Table 20, for other SFRs is in following table: SO SFR OT.AC_Pers OT.Data_Int OT.Data_Conf OT.Identification OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction OT.Prot_Abuse-Func OT.Chip_Auth_Proof OT.Configuration OT.TOE_Identification FAU_SAS.1 X X FCS_CKM.1/BAC X X FCS_CKM.1/MSK_DIV X X FCS_CKM.1/GP X X X X FCS_CKM.1.1/LSK_DIV X FCS_CKM.1/CA X X X FCS_CKM.1/KEY_GEN X FCS_CKM.4 X X X X FCS_COP.1/BAC_SHA X X FCS_COP.1/BAC_ENC X X FCS_COP.1/AUTH X X FCS_COP.1/BAC_MAC X X FCS_COP.1/MSK_SHA X X X X FCS_COP.1/GP_ENC X X X X FCS_COP.1/GP_AUTH X X FCS_COP.1/GP_MAC X X X X FCS_COP.1/GP_SDT_DEC X X FCS_COP.1/CA_SHA X X X FCS_COP.1/CA_ENC X X X FCS_COP.1/CA_MAC X X X FCS_COP.1/SIG_GEN X FCS_RND.1 X X X X X FIA_UID.1 X X FIA_UAU.1 X X FIA_UAU.4 X X X X X FIA_UAU.5/BAC X X X FIA_UAU.5/MP X X FIA_UAU.5/CA X FIA_UAU.6/BAC X X FIA_UAU.6/MP X X X X X FIA_UAU.6/CA X X FIA_AFL.1/BAC X X FIA_AFL.1/MP X X X FIA_API.1/CA X FIA_API.1/AA X 90/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SO SFR OT.AC_Pers OT.Data_Int OT.Data_Conf OT.Identification OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction OT.Prot_Abuse-Func OT.Chip_Auth_Proof OT.Configuration OT.TOE_Identification FDP_ACC.1/BAC X X X FDP_ACC.1/MP X FDP_ACC.1/ID X X X X FDP_ACF.1/BAC X X X FDP_ACF.1/MP X FDP_ACF.1/ID X X X X FDP_UCT.1/BAC X X FDP_UCT.1/MP X X X X FDP_UCT.1/CA X X FDP_UIT.1/BAC X X FDP_UIT.1/MP X X X X FDP_UIT.1/CA X X FDP_ITC.1/MP X X FMT_MOF.1/PROT X X FMT_MOF.1/GP X X X FMT_SMF.1 X X X X FMT_SMR.1 X X X X FMT_LIM.1 X FMT_LIM.2 X FMT_MTD.1/INI_ENA X FMT_MTD.1/INI_DIS X FMT_MTD.1/KEY_WRITE X X X FMT_MTD.1/KEY_READ X X X FMT_MTD.1/MP_KEY_WRITE X X X FMT_MTD.1/MP_KEY_READ X X X FMT_MTD.1/CAPK X X X X FMT_MTD.1/CAPK_READ X X X X FMT_MTD.1/AA_KEY_WRITE X X FMT_MTD.1/AA_KEY_READ X X FMT_MTD.1/LCS_PREP X X FMT_MTD.1/LCS_PERS X FMT_MTD.1/LSK_READ FMT_MTD.1/AA_KEY_GEN X FMT_MTD.1/CA_KEY_GEN X FPT_EMS.1 X X X FPT_FLS.1 X X X X FPT_TST.1 X X FPT_PHP.3 X X X X FTP_ITC.1/MP X X X Table 19 - SFRs and Security Objectives 91/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SO SFR OT.Update_Mechanism OT.Enc_Sign_Update OT.Update_Terminal_Auth OT.Attack_Detection OT.Key_Secrecy Class FCS FCS_COP.1/UPD_ITC X X FCS_CKM.1/UPD_ITC X X FCS_COP.1/UPD_DEC X X FCS_CKM.1/UPD_DEC X X FCS_COP.1/UPD_INT X X FCS_CKM.1/UPD_INT X X FCS_COP.1/UPD_SIG X X FCS_CKM.4/UPD X X Class FIA FIA_AFL.1/UPD X X FIA_UID.1/UPD X X FIA_UAU.1/UPD X X Class FDP FDP_ACC.1/UPD X X FDP_ACF.1/UPD X X FDP_IFC.1/UPD X X FDP_IFF.1/UPD X X FDP_RIP.1/UPD X Class FAU FAU_SAS.1/UPD X X Class FMT FMT_SMF.1/UPD X FMT_MTD.1/UPD_SK_PICC X X X FMT_MTD.1/UPD_KEY_READ X X X FMT_SMR.1/UPD X X X Class FPT FPT_EMS.1/UPD X FPT_FLS.1/UPD X FPT_TST.1/UPD X Class FTP FTP_ITC.1/UPD X X Table 20- SFRs and Security Objectives for Update mechanism. 7.3.1.2 OT.AC_Pers The security objective OT.AC_Pers “Access Control for Personalization of logical MRTD” addresses the access control of the writing the logical MRTD. The write access to the logical MRTD data are defined by the SFR FDP_ACC.1/BAC and FDP_ACF.1/BAC as follows: only the successfully authenticated Personalization Agent is allowed to write the data of the groups EF.DG1 to EF.DG16 of the logical MRTD. 92/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 The Manufacturer Secret Key (MSK) loaded by IC Manufacturer is diversified at first command according to SFR FCS_CKM.1/MSK_DIV and FCS_CKM.1/MSK_SHA. This secures the transport of the chip between IC manufacturing centre and MRTD manufacturing centre. The following paragraph is extracted from [PP_BAC] and has been refined according to the technical characteristics of this TOE. The refinement is right after. The authentication of the terminal as Personalization Agent shall be performed by TSF according to SFR FIA_UAU.4 and FIA_UAU.5. The Personalization Agent can be authenticated either by using the BAC mechanism (FCS_CKM.1, FCS_COP.1/SHA, FCS_RND.1 (for key generation), and FCS_COP.1/ENC as well as FCS_COP.1/MAC) with the personalization key or for reasons of interoperability with the [PP_EAC] by using the symmetric authentication mechanism (FCS_COP.1/ AUTH)6. In case of using the BAC mechanism the SFR FIA_UAU.6 describes the re-authentication and FDP_UCT.1 and FDP_UIT.1 the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1, FCS_COP.1/SHA, FCS_RND.1 (for key generation), and FCS_COP.1/ENC as well as FCS_COP.1/MAC and and FCS_COP.1/CA_MAC for the ENC_MAC_Mode.6. Note: As BAC mechanism is not supported for the authentication of the terminal as Personalization Agent, the following two paragraphs have been added to demonstrate that symmetric authentication used in Personalization phase fulfills the OT.AC_Pers. The authentication of the terminal as Personalization Agent is performed by TSF according to SFR FIA_UAU.4 and FIA_UAU.5/BAC. The Personalization Agent can be authenticated by using the symmetric authentication mechanism (FCS_COP.1/AUTH) with the personalization key. FIA_UAU.6/MP describes the re-authentication. In case of failed authentication attempts FIA_AFL.1/MP enforces additional waiting time prolonging the necessary amount of time for facilitating a brute force attack. As the symmetric authentication is used in Personalization phase, the SFR FIA_UAU.6/MP describes the re- authentication and FDP_UCT.1/MP and FDP_UIT.1/MP the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1/GP, FCS_RND.1 (for key generation), and FCS_COP.1/GP_ENC as well as FCS_COP.1/GP_MAC for the ENC_MAC_Mode. The SFR FCS_CKM.4 enforces the destruction of Secure Messaging session keys. The SFR FMT_SMR.1 lists the roles (including Personalization Agent) and the SFR FMT_SMF.1 lists the TSF management functions (including Personalization) setting the Document Basic Access Keys according to the SFR FMT_MTD.1/KEY_WRITE as authentication reference data. The SFR FMT_MTD.1/KEY_READ prevents read access to the secret key of the Personalization Agent Keys and ensure together with the SFR FCS_CKM.4, FPT_EMS.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these keys. The following parts are added to integrate the personalization of the different keys in the OT.AC_Pers. Only the Personalization Agent is allowed to set the Document Basic Access Keys according to the SFR FMT_MTD.1/KEY_WRITE. The SFR FMT_MTD.1/KEY_READ prevents read access to the Document Basic Access Keys and ensure together with the SFR FCS_CKM.4, FPT_EMS.1 and FPT_PHP.3 the confidentially of these keys. Only the Personalization Agent is allowed to set the Chip Authentication Private Key according to the SFR FMT_MTD.1/CAPK. The SFR FMT_MTD.1/CAPK_READ prevents read access to the Chip Authentication Private Key and ensure together with the SFR FTP_ITC.1/MP, FCS_CKM.4, FPT_EMS.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these keys. Only the Personalization Agent is allowed to set the Active Authentication Private Key according to the SFR FMT_MTD.1/AA_KEY_WRITE. The SFR FMT_MTD.1/AA_KEY_READ prevents read access to the Active Authentication Private Key and ensure together with the SFR FTP_ITC.1/MP, FCS_CKM.4, FPT_EMS.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these keys. 6 As the BAC mechanism is not used during Personalization phase of the TOE, this part is not relevant for this TOE. 93/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Only the Personalization Agent is allowed to generate Chip Authentication Key pair and Active Authentication Key pair according to respectively FMT_MTD.1/CA_KEY_GEN and FMT_MTD.1/AA_KEY_GEN. The generation of these key pairs is ensured by FCS_CKM.1/KEY_GEN. SFR FDP_ACF.1/ID and FDP_ACC.1/ID define rules to access TOE_ID and CPLC which allow the TOE identification. The Personalization Agent is the only subject allowed to ends Personalization of logical MRTD, setting the TOE Life Cycle State in Operational Use state according to FMT_MTD.1.1/LCS_PERS, only if FMT_MTD.1.1/LCS_PREP has been realized. Since then it is no more possible to return in Personalization state. 7.3.1.3 OT.Data_Int The security objective OT.Data_Int “Integrity of personal data” requires the TOE to protect the integrity of the logical MRTD stored on the MRTD’s chip against physical manipulation and unauthorized writing. The TOE supports FCS_COP.1/MSK_SHA for integrity check of master key. The write access to the logical MRTD data is defined by the SFR FDP_ACC.1/BAC and FDP_ACF.1/BAC in the same way: only the Personalization Agent is allowed to write the data of the groups EF.DG1 to EF.DG16 of the logical MRTD (FDP_ACF.1.2/BAC, rule 1) and terminals are not allowed to modify any of the data groups EF.DG1 to EF.DG16 of the logical MRTD (cf. FDP_ACF.1.4/BAC). The SFR FMT_SMR.1 lists the roles (including Personalization Agent) and the SFR FMT_SMF.1 lists the TSF management functions (including Personalization). The authentication of the terminal as Personalization Agent shall be performed by TSF according to SFR FIA_UAU.4, FIA_UAU.5/BAC and FIA_UAU.6/BAC using FCS_COP.1/AUTH. The security objective OT.Data_Int “Integrity of personal data” requires the TOE to ensure that the inspection system is able to detect any modification of the transmitted logical MRTD data by means of the BAC mechanism. The SFR FIA_UAU.6/BAC, FDP_UCT.1/BAC and FDP_UIT.1/BAC requires the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1/BAC, FCS_COP.1/BAC_SHA, FCS_RND.1 (for key generation), and FCS_COP.1/BAC_ENC and FCS_COP.1/BAC_MAC for the ENC_MAC_Mode. The SFR FMT_MTD.1/KEY_WRITE requires the Personalization Agent to establish the Document Basic Access Keys in a way that they cannot be read by anyone in accordance to FMT_MTD.1/KEY_READ. The following part is added to integrate the Manufacturing and Personalization phases in the OT_Data_Int. Manufacturer and Personalization Agent are also able to detect any modification of the transmitted logical MRTD data by means of the Symmetric Authentication mechanism. The SFR FIA_UAU.6/MP, FDP_UCT.1/MP and FDP_UIT.1/MP requires the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1/GP, FCS_RND.1 (for key generation), and FCS_COP.1/GP_ENC and FCS_COP.1/GP_MAC for the ENC_MAC_Mode. The SFR FMT_MTD.1/MP_KEY_WRITE requires the Manufacturer to establish the Symmetric Authentication Private Key in a way that it cannot be read by anyone in accordance to FMT_MTD.1/MP_KEY_READ. FCS_CKM.4 enforces the destruction of Secure Messaging session keys. The Manufacturer and the Personalization Agent can select the protection mode of user data following FMT_MOF.1/GP The following part is added to integrate the Chip Authentication mechanism in the coverage of the OT.Data_Int. The inspection system is also able to detect any modification of the transmitted logical MRTD data by means of the Chip Authentication mechanism. The SFR FIA_UAU.6/CA, FDP_UCT.1/CA and FDP_UIT.1/CA requires the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1/CA FCS_COP.1/CA_SHA, FCS_RND.1 (for key generation), and FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the ENC_MAC_Mode. The SFR FMT_MTD.1/CAPK requires the Personalization Agent to establish the Chip Authentication Private Key in a way that it cannot be read by anyone in accordance to FMT_MTD.1/CAPK_READ. FCS_CKM.4 enforces the destruction of Secure Messaging session keys. 94/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.3.1.4 OT.Data_Conf The security objective OT.Data_Conf “Confidentiality of personal data” requires the TOE to ensure the confidentiality of the logical MRTD data groups EF.DG1 to EF.DG16. The SFR FIA_UID.1 and FIA_UAU.1 allow only those actions before identification respective authentication which do not violate OT.Data_Conf. In case of failed authentication attempts FIA_AFL.1/BAC enforces additional waiting time prolonging the necessary amount of time for facilitating a brute force attack. The read access to the logical MRTD data is defined by the FDP_ACC.1/BAC and FDP_ACF.1.2/BAC: the successful authenticated Personalization Agent is allowed to read the data of the logical MRTD (EF.DG1 to EF.DG16). The successful authenticated Basic Inspection System is allowed to read the data of the logical MRTD (EF.DG1, EF.DG2 and EF.DG5 to EF.DG16). The SFR FMT_SMR.1 lists the roles (including Personalization Agent and Basic Inspection System) and the SFR FMT_SMF.1 lists the TSF management functions (including Personalization for the key management for the Document Basic Access Keys). The SFR FIA_UAU.4 prevents reuse of authentication data to strengthen the authentication of the user. The SFR FIA_UAU.5/BAC enforces the TOE to accept the authentication attempt as Basic Inspection System only by means of the Basic Access Control Authentication Mechanism with the Document Basic Access Keys. Moreover, the SFR FIA_UAU.6/BAC requests secure messaging after successful authentication of the terminal with Basic Access Control Authentication Mechanism which includes the protection of the transmitted data in ENC_MAC_Mode by means of the cryptographic functions according to FCS_COP.1/BAC_ENC and FCS_COP.1/BAC_MAC (cf. the SFR FDP_UCT.1/BAC and FDP_UIT.1/BAC). (for key generation), and FCS_COP.1/BAC_ENC and FCS_COP.1/BAC_MAC for the ENC_MAC_Mode. The SFR FCS_CKM.1/BAC, FCS_CKM.4, FCS_COP.1/BAC_SHA and FCS_RND.1 establish the key management for the secure messaging keys. The SFR FMT_MTD.1/KEY_WRITE addresses the key management and FMT_MTD.1/KEY_READ prevents reading of the Document Basic Access Keys. The TOE supports FCS_COP.1/MSK_SHA for integrity check of master key. The following part is added to integrate the Manufacturing and Personalization phases in the OT.Data_Conf. Manufacturer and Personalization Agent are also able to detect any modification of the transmitted logical MRTD data by means of the Symmetric Authentication mechanism. The SFR FIA_UAU.6/MP, FDP_UCT.1/MP and FDP_UIT.1/MP requires the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1/GP, FCS_RND.1 (for key generation), and FCS_COP.1/GP_ENC and FCS_COP.1/GP_MAC for the ENC_MAC_Mode. The SFR FMT_MTD.1/MP_KEY_WRITE requires the Manufacturer to establish the Symmetric Authentication Private Key in a way that it cannot be read by anyone in accordance to FMT_MTD.1/MP_KEY_READ. FCS_CKM.4 enforces the destruction of Secure Messaging session keys. The Manufacturer and the Personalization Agent can select the protection mode of user data following FMT_MOF.1/GP The following parts are added to integrate the Chip Authentication mechanism and the Symmetric Authentication mechanism used in Personalization phase in the coverage of the OT.Data_Conf. The SFR FIA_UAU.5/CA enforces the TOE to accept only received commands with correct message authentication code sent by means of secure messaging with key agreed with the terminal by means of the Chip Authentication Mechanism. Moreover, the SFR FIA_UAU.6/CA requests secure messaging after successful authentication of the chip which includes the protection of the transmitted data in ENC_MAC_Mode by means of the cryptographic functions according to FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC (cf. the SFR FDP_UCT.1/CA and FDP_UIT.1/CA). (for key generation), and FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC for the ENC_MAC_Mode. The SFR FCS_CKM.1/CA, FCS_CKM.4, FCS_COP.1/CA_SHA and FCS_RND.1 establish the key management for the secure messaging keys. The SFR FMT_MTD.1/CAPK addresses the key management and FMT_MTD.1/CAPK_READ prevents reading of the Chip Authentication Private Key. During Personalization of logical MRTD, the Document Basic Access Keys, Chip Authentication Private Key and Active Authentication Private Key are transmitted ciphered and the TSF deciphers these keys according to SFR FDP_ITC.1/MP and FCS_COP.1/GP_SDT_DEC (FCS_CKM.4 for decryption session key destruction). 95/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.3.1.5 OT.Identification The security objective OT.Identification “Identification and Authentication of the TOE” address the storage of the IC Identification Data uniquely identifying the MRTD’s chip in its non-volatile memory. This will be ensured by TSF according to SFR FAU_SAS.1. Furthermore, the TOE shall identify itself only to a successful authenticated Basic Inspection System in Phase 4 “Operational Use”. The SFR FMT_MTD.1/INI_ENA allows only the Manufacturer to write Initialization Data and Pre- personalization Data (including the Personalization Agent key). The SFR FMT_MTD.1/INI_DIS allows the Personalization Agent to disable Initialization Data if their usage in the phase 4 “Operational Use” violates the security objective OT.Identification. The SFR FIA_UID.1 and FIA_UAU.1 do not allow reading of any data uniquely identifying the MRTD’s chip before successful authentication of the Basic Inspection Terminal and will stop communication after unsuccessful authentication attempt. In case of failed authentication attempts FIA_AFL.1/BAC enforces additional waiting time prolonging the necessary amount of time for facilitating a brute force attack. SFR FDP_ACF.1/ID and FDP_ACC.1/ID define rules to read and write TOE_ID and CPLC which allow the TOE identification. 7.3.1.6 OT.Prot_Abuse-Func The security objective 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. 7.3.1.7 OT.Prot_Inf_Leak The security objective OT.Prot_Inf_Leak “Protection against Information Leakage” requires the TOE to protect confidential TSF data stored and/or processed in the MRTD’s chip against disclosure • by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines, which is addressed by the SFR FPT_EMS.1, • 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. 7.3.1.8 OT.Prot_Phys-Tamper The security objective OT.Prot_Phys-Tamper “Protection against Physical Tampering” is covered by the SFR FPT_PHP.3. 7.3.1.9 OT.Prot_Malfunction The security objective 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 conditions possibly causing a malfunction. 7.3.1.10 OT.Chip_Auth_Proof The security objective OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” is ensured by the Chip Authentication Protocol activated by FMT_MOF.1/PROT and provided by FIA_API.1/CA proving the genuineness of the TOE. The Chip Authentication Protocol defined by FCS_CKM.1/CA is performed using a TOE internally stored confidential private key. Confidentiality of this key is ensured by FMT_MTD.1/CAPK and FMT_MTD.1/CAPK_READ. The Chip Authentication Protocol [TR_03110] requires additional TSF according to FCS_COP.1/CA_SHA (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). 96/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 This security objective OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” is also ensured by the Active Authentication Protocol activated by FMT_MOF.1/PROT and provided by FIA_API/AA proving the identity and authenticity of the TOE. The Active Authentication relies on FCS_COP.1/SIG_GEN and FCS_RND.1. It is performed using a TOE internally stored confidential private key. Confidentiality of this key is ensured by FMT_MTD.1/AA_KEY_WRITE and FMT_MTD.1/AA_KEY_READ. 7.3.1.11 OT.Configuration The security objective OT.Configuration “Protection of the TOE preparation” addresses management of the Data Configuration, the Pre-personalization Agent keys, the Personalization Agent keys, the CPLC Data and the Life Cycle State of the TOE. The Manufacturer Secret Key (MSK) loaded by Embedded software loading responsible (scheme 2) or IC manufacturer (scheme 1) is diversified at first command according to SFR FCS_CKM.1/MSK_DIV and FCS_CKM.1/MSK_SHA. This secures the transport of the chip between IC manufacturing centre and MRTD manufacturing centre. The authentication of the terminal as Manufacturer is performed by TSF according to SFR FIA_UAU.4 and FIA_UAU.5/MP. The Manufacturer can be authenticated by using the symmetric authentication mechanism (FCS_COP.1/GP_AUTH) with the Pre-personalization key. FIA_UAU.6/MP describes the re-authentication. In case of failed authentication attempts FIA_AFL.1/MP enforces additional waiting time prolonging the necessary amount of time for facilitating a brute force attack. The SFR FTP_ITC.1/MP allows the Manufacturer to communicate with the OS. In step 5, the Manufacturer is allowed to set the Pre-personalization Agent keys according to the SFR FMT_MTD.1/MP_KEY_WRITE, FDP_ITC.1/MP and FCS_COP.1/GP_SDT_DEC. The SFR FMT_MTD.1/MP_KEY_READ prevents read access to the Pre-personalization keys and ensure together with the SFR FPT_EMS.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these keys. This operation destroys the MSK (FCS_CKM.4). The write access to these data is defined by the SFR FDP_ACC.1/MP and FDP_ACF.1/MP as follows: only the successfully authenticated Pre-personalization Agent and Personalization Agent are allowed to write these data. In step 5, the authentication of the terminal as Manufacturer shall be performed by TSF according to SFR FIA_UAU.4 and FIA_UAU.5/MP. The Manufacturer shall be authenticated by using the symmetric authentication mechanism (FCS_COP.1/GP_AUTH). In case of failed authentication attempts FIA_AFL.1/MP enforces additional waiting time prolonging the necessary amount of time for facilitating a brute force attack The SFR FIA_UAU.6/MP describes the re-authentication and FDP_UCT.1/MP and FDP_UIT.1/MP the protection of the transmitted data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1/GP, FCS_RND.1 (for key generation), and FCS_COP.1/GP_ENC as well as FCS_COP.1/GP_MAC for the ENC_MAC_Mode. The SFR FCS_CKM.4 enforces the destruction of Secure Messaging session keys. The Manufacturer can enable Chip Authentication and Active Authentication functionalities following FMT_MOF.1.1/PROT. The Manufacturer and the Personalization Agent can select the protection mode of user data following FMT_MOF.1.1/GP. The SFR FMT_SMR.1 lists the roles and the SFR FMT_SMF.1 lists the TSF management functions setting the Pre-personalization Agent Keys according to the SFR FMT_MTD.1/MP_KEY_WRITE as authentication reference data. The SFR FMT_MTD.1/MP_KEY_READ prevents read access to the secret key of the Personalization Agent Keys and ensure together with the SFR FCS_CKM.4, FPT_EMS.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these keys. SFR FDP_ACF.1/ID and FDP_ACC.1/ID define rules to access TOE_ID and CPLC which allow the TOE identification. 97/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 The Manufacturer is the only subject allowed to ends Pre-personalization of logical MRTD, setting the TOE Life Cycle State in Personalization state according to FMT_MTD.1.1/LCS_PREP. Since then it is no more possible to return in manufacturing state and the role Manufacturer is no longer available as FCS_CKM.4 destroys Manufacturer keys. 7.3.1.12 OT.TOE_Identification The security objective OT.TOE_Identification “Secure identification of the TOE” address the storage of the IC Identification Data uniquely identifying the MRTD’s chip in its non-volatile memory. This will be ensured by TSF according to SFR FAU_SAS.1. SFR FDP_ACF.1/ID and FDP_ACC.1/ID define rules to read and write TOE_ID and CPLC which allow the TOE identification. The authentication of the terminal as Manufacturer is performed by TSF according to SFR FIA_UAU.4 and FIA_UAU.5/MP. The Manufacturer can be authenticated by using the symmetric authentication mechanism (FCS_COP.1/GP_AUTH) with the Pre-personalization key. FIA_UAU.6/MP describes the re-authentication. In case of failed authentication attempts FIA_AFL.1/MP enforces additional waiting time prolonging the necessary amount of time for facilitating a brute force attack. The SFR FTP_ITC.1/MP allows the Manufacturer to communicate with the OS. 7.3.1.13 OT.Update_Mechanism The update mechanism is dedicated to part or all OS update and is enforced by the SFRs FCS_COP.1/UPD_ITC, FCS_CKM.1/UPD_ITC, FCS_COP.1/UPD_DEC, FCS_CKM.1/UPD_DEC, FCS_COP.1/UPD_INT, FCS_CKM.1/UPD_INT, FCS_COP.1/UPD_SIG, FCS_CKM.4/UPD which are concerned with cryptographic operations and key generation. A secure messaging is used for Update Package transport (SCP03 by default). The SFRs are used to decipher the new Update Package and to check the associated signature. FIA_AFL.1/UPD, FIA_UID.1/UPD, FIA_UAU.1/UPD are concerned with identification and authentication towards the TOE, they requires the protection of the received data by means of secure messaging implemented. The access control policy is supported by FDP_ACC.1/UPD, FDP_ACF.1/UPD, FDP_IFC.1/UPD, FDP_IFF.1/UPD and FDP_RIP.1/UPD. FAU_SAS.1/UPD addresses the storage of update Data in its non-volatile memory, whereby they also include the Update Package Identification Data uniquely identifying the TOE’s Update Package. FMT_SMF.1/UPD are concerned with management functions and data. The Manufacturer is the only one who can load and activate the MSK according to SFRs, the LSK managed by the installation Update Package agent can’t be read as required by FMT_MTD.1/UPD_SK_PICC and FMT_MTD.1/UPD_KEY_READ. FMT_SMR.1/UPD’. Unauthorised modifying of the exchanged data is addressed, in the first line, by FTP_ITC.1/UPD. The Update Package installation agent is able to detect any modification of the transmitted code data by means of the Symmetric Authentication mechanism. The SFR FCS_COP.1/UPD_ITC requires the protection of the received data by means of secure messaging implemented by the cryptographic functions according to FCS_CKM.1.1/UPD_DEC, FCS_CKM.1.1/UPD_INT, and FCS_COP.1/UPD_DEC for the ENC_MAC_Mode. The LSK used as a seed for DIV_LSK and DIV2_LSK and DIV2_LSK cannot be read by anyone in accordance to FMT_MTD.1/UPD_KEY_READ. FCS_CKM.4 enforces the destruction of Secure Messaging session keys. FCS_CKM.4 also enforces the destruction of the LSK once the TOE is in Step 6. 7.3.1.14 OT.Enc_Sign_Update The SFRs FCS_COP.1/UPD_ITC, FCS_CKM.1/UPD_ITC, FCS_COP.1/UPD_DEC, FCS_CKM.1/UPD_DEC, FCS_COP.1/UPD_INT, FCS_CKM.1/UPD_INT, FCS_COP.1/UPD_SIG, FCS_CKM.4/UPD are concerned with cryptographic operations and key generation for checking installs update packages that are encrypted, integrity- protected and signed by the authority in charge of delivering and installing updates. The Update Package installation in non-volatile memory is enforced by FMT_MTD.1/UPD_SK_PICC and FMT_MTD.1/UPD_KEY_READ, FMT_SMR.1/UPD 98/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.3.1.15 OT.Update_Terminal_Auth FIA_AFL.1/UPD, FIA_UID.1/UPD, FIA_UAU.1/UPD are concerned with identification and authentication towards the TOE according GP authentication. The access control policy is supported by FDP_ACC.1/UPD, FDP_ACF.1/UPD, FDP_IFC.1/UPD, FDP_IFF.1/UPD. FMT_MTD.1/UPD_SK_PICC, FMT_MTD.1/UPD_KEY_READ, FTP_ITC.1/UPD and FMT_SMR.1/UPD are concerned with management functions and data. FMT_SMF.1/UPD supports OT.Update_Terminal_Auth, 7.3.1.16 OT.Attack_Detection FAU_SAS.1/UPD addresses the storage of Initialisation update and Pre-Personalisation Data in its non-volatile memory, whereby they also include the Update Package Identification Data uniquely identifying the TOE’s Update Package. A bad log can confirm an attack detection. The security objective requires the TOE to protect confidential TSF data stored and/or processed in the travel document’s chip against disclosure by forcing a malfunction of the TOE which is addressed by the SFR FPT_FLS.1/UPD and FPT_TST.1/UPD. 7.3.1.17 OT.Key_Secrecy FMT_MTD.1/UPD_SK_PICC, FMT_SMR.1/UPD and FMT_MTD.1/UPD_KEY_READ addresses the access control of the writing the logical travel document and respect key secrecy. The security objective requires the TOE to protect confidential TSF data stored and/or processed in the travel document’s chip against disclosure - by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines which is addressed by the SFR FPT_EMS.1/UPD. 99/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 7.3.2 Dependency Rationale 7.3.2.1 Overview The Table 21 shows the dependencies between the SFR of the TOE. SFR Dependencies Support of the Dependencies FAU_SAS.1 No dependencies n.a. FAU_SAS.1/UPD No dependencies n.a. FCS_CKM.1/BAC [FCS_CKM.2 or FCS_COP.1], FCS_CKM.4 FCS_COP.1/BAC_ENC and FCS_COP.1/BAC_MAC FCS_CKM.4 FCS_CKM.1/MSK_DIV FCS_COP.1/GP_ENC and FCS_COP.1/GP_MAC FCS_CKM.4 FCS_CKM.1/GP FCS_COP.1/GP_ENC and FCS_COP.1/GP_MAC FCS_CKM.4 FCS_CKM.1/CA FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC FCS_CKM.4 FCS_CKM.1/KEY_GEN FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC and FCS_COP.1/SIG_GEN FCS_CKM.4 FCS_CKM.1/UPD_DEC FCS_COP.1/UPD_DEC FCS_CKM.4/UPD FCS_CKM.1/UPD_INT FCS_COP.1/UPD_INT FCS_COP.1/UPD_SIG FCS_CKM.4/UPD FCS_CKM.1/UPD_ITC FCS_COP.1/UPD_ITC FCS_CKM.4/UPD FCS_CKM.4 FDP_ITC.1, or FDP_ITC.2, or FCS_CKM.1] FCS_CKM.1/BAC and FCS_CKM.1/MSK_DIV and FCS_CKM.1/GP and FCS_CKM.1/CA FCS_CKM.4/UPD FCS_CKM.1/UPD_DEC FCS_CKM.1/UPD_INT FCS_CKM.1/UPD_ITC FCS_COP.1/BAC_SHA [FDP_ITC.1, or FDP_ITC.2, or FCS_CKM.1], FCS_CKM.4 See § 7.3.2.2.1 FCS_CKM.4 FCS_COP.1/BAC_ENC FCS_CKM.1/BAC FCS_CKM.4 FCS_COP.1/AUTH FCS_CKM.1/BAC FCS_CKM.4 FCS_COP.1/BAC_MAC FCS_CKM.1/BAC FCS_CKM.4 100/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SFR Dependencies Support of the Dependencies FCS_COP.1/MSK_SHA See § 7.3.2.2.1 FCS_CKM.4 FCS_COP.1/GP_ENC FCS_CKM.1/GP FCS_CKM.4 FCS_COP.1/GP_AUTH FCS_CKM.1/GP FCS_CKM.4 FCS_COP.1/GP_MAC FCS_CKM.1/GP FCS_CKM.4 FCS_COP.1/GP_SDT_DEC FCS_CKM.1/GP FCS_CKM.4 FCS_COP.1/CA_SHA See § 7.3.2.2.1 FCS_CKM.4 FCS_COP.1/CA_ENC FDP_ITC.1/MP FCS_CKM.1/KEY_GEN FCS_CKM.4 FCS_COP.1/CA_MAC FDP_ITC.1/MP FCS_CKM.1/KEY_GEN FCS_CKM.4 FCS_COP.1/SIG_GEN FDP_ITC.1/MP FCS_CKM.1/KEY_GEN FCS_CKM.4 FCS_COP.1/UPD_ITC FCS_CKM.1/UPD_ITC FCS_CKM.4/UPD FCS_COP.1/UPD_DEC FCS_CKM.1/UPD_DEC FCS_CKM.4/UPD FCS_COP.1/UPD_SIG FCS_CKM.1/UPD_INT FCS_CKM.4/UPD FCS_COP.1/UPD_INT FCS_CKM.1/UPD_INT FCS_CKM.4/UPD FCS_RND.1 No dependencies n.a. FIA_UID.1 No dependencies n.a. FIA_UID.1/UPD No dependencies n.a. FIA_UAU.1/UPD FIA_UID.1 FIA_UID.1/UPD FIA_UAU.1 FIA_UID.1 FIA_UID.1 FIA_UAU.4 No dependencies n.a. FIA_UAU.5/BAC No dependencies n.a. FIA_UAU.5/MP FIA_UAU.5/CA FIA_UAU.6/BAC No dependencies n.a. FIA_UAU.6/MP FIA_UAU.6/CA FIA_AFL.1/BAC FIA_UAU.1 FIA_UAU.1 FIA_AFL.1/MP FIA_AFL.1/UPD FIA_UAU.1/UPD FIA_API.1/CA No dependencies n.a. FIA_API.1/AA No dependencies n.a. FDP_ACC.1/BAC FDP_ACF.1 FDP_ACF.1/BAC FDP_ACC.1/MP FDP_ACF.1/MP 101/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SFR Dependencies Support of the Dependencies FDP_ACC.1/ID FDP_ACF.1/ID FDP_ACC.1/UPD FDP_ACF.1 FDP_ACF.1/UPD FDP_ACF.1/BAC FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/BAC See § 7.3.2.2.2 FDP_ACF.1/MP FDP_ACC.1/MP See § 7.3.2.2.3 FDP_ACF.1/ID FDP_ACC.1/ID See § 7.3.2.2.3 FDP_ACF.1/UPD FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/UPD See § 7.3.2.2.2 FDP_IFC.1/UPD FDP_ACC.1, FDP_IFF.1 FDP_ACC.1/UPD, FDP_IFF.1/UPD FDP_IFF.1/UPD FDP_IFC.1 FDP_IFC.1/UPD FDP_RIP.1/UPD No dependencies n.a. FDP_UCT.1/BAC [FTP_ITC.1, or FTP_TRP.1], [FDP_IFC.1, or FDP_ACC.1] See § 7.3.2.2.4 FDP_ACC.1/BAC FDP_UCT.1/MP FTP_ITC.1/MP FDP_ACC.1/MP FDP_UIT.1/BAC [FTP_ITC.1, or FTP_TRP.1], [FDP_IFC.1, or FDP_ACC.1] See § 7.3.2.2.4 FDP_ACC.1/BAC FDP_UIT.1/MP FTP_ITC.1/MP FDP_ACC.1/MP FDP_UIT.1/CA See § 7.3.2.2.4 FDP_ACC.1/BAC FDP_ITC.1/MP [FDP_ACC.1, or FDP_IFC.1] FMT_MSA.3 FDP_ACC.1/MP See § 7.3.2.2.5 FMT_MOF.1/PROT FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 FMT_MOF.1/GP FMT_SMF.1 No dependencies n.a. FMT_SMF.1/UPD No dependencies n.a. FMT_SMR.1 FIA_UID.1 FIA_UID.1 FMT_SMR.1/UPD FIA_UID.1 FIA_UID.1/UPD FMT_LIM.1 FMT_LIM.2 FMT_LIM.2 FMT_LIM.2 FMT_LIM.1 FMT_LIM.1 FMT_MTD.1/INI_ENA FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_SMR.1 FMT_MTD.1/INI_DIS FMT_MTD.1/KEY_WRITE FMT_MTD.1/KEY_READ FMT_MTD.1/MP_KEY_WRITE FMT_MTD.1/MP_KEY_READ FMT_MTD.1/CAPK FMT_MTD.1/CAPK_READ FMT_MTD.1/AA_KEY_WRITE FMT_MTD.1/AA_KEY_READ FMT_MTD.1/LCS_PREP FMT_MTD.1/LCS_PERS 102/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 SFR Dependencies Support of the Dependencies FMT_MTD.1/LSK_READ FMT_MTD.1/AA_KEY_GEN FMT_MTD.1/CA_KEY_GEN FMT_MTD.1/UPD_SK_PICC FMT_MTD.1/UPD_KEY_READ FPT_EMS.1 No dependencies n.a. FPT_EMS.1/UPD No dependencies n.a. FPT_FLS.1 No dependencies n.a. FPT_FLS.1/UPD No dependencies n.a. FPT_TST.1 No dependencies n.a. FPT_TST.1/UPD No dependencies n.a. FPT_PHP.3 No dependencies n.a. FTP_ITC.1/MP No dependencies n.a. FTP_ITC.1/UPD No dependencies n.a. Table 21 - Dependencies between the SFR for the TOE 7.3.2.2 Rationale for the exclusion of dependencies 7.3.2.2.1 FCS_COP.1/BAC_SHA, FCS_COP.1/MSK_SHA, FCS_COP.1/CA_SHA The hash algorithm required by FCS_COP.1/BAC_SHA, FCS_COP.1/MP_SHA and FCS_COP.1/CA_SHA_SM_TDES does not need any key material. Therefore neither a key generation (FCS_CKM.1) nor an import (FDP_ITC.1/2) is necessary. 7.3.2.2.2 FDP_ACF.1/BAC and FDP_ACF.1/UPD The access control TSF according to FDP_ACF.1/BAC and FDP_ACF.1/UPD 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. 7.3.2.2.3 FDP_ACF.1/MP and FDP_ACF.1/ID The access control TSF according to FDP_ACF.1/MP and FDP_ACF.1/ID uses security attributes which are fixed during the development of the OS 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 7.3.2.2.4 FDP_UCT.1/BAC and FDP_UIT.1/BAC The SFR FDP_UCT.1/BAC and FDP_UIT.1/BAC require the use secure messaging between the MRTD and the BIS. There is no need for SFR FTP_ITC.1, e.g. to require this communication channel to be logically distinct from other communication channels since there is only one channel. Since the TOE does not provide a direct human interface a trusted path as required by FTP_TRP.1 is not applicable here. 7.3.2.2.5 FDP_ITC.1/MP The SFR FDP_ITC.1/MP requires the verification of security attributes when Manufacturer and Personalization Agent imports user data. There is no need for FMT_MSA.3, e.g. to initialize these security attributes, as they are fixed during the development of the OS. 103/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 8 TOE summary specification 8.1 TOE summary specification 8.1.1 Overview The TOE provides the following Security Functions (TSF): TSF Acronym Descr. Step 5 6 7 Access Control in Reading F.ACR § 8.1.2 ✓ ✓ ✓ Access Control in Writing F.ACW § 8.1.3 ✓ ✓ ✓ Active Authentication F.AA § 8.1.4 ✓  ✓ Basic Access Control F.BAC § 8.1.5   ✓ Chip Authentication F.CA § 8.1.6 ✓  ✓ MRTD Personalization F.PERS § 8.1.7  ✓  Physical Protection F.PHY § 8.1.8 ✓ ✓ ✓ MRTD Pre-personalization F.PREP § 8.1.9 ✓   Safe State Management F.SS § 8.1.10 ✓ ✓ ✓ Secure Messaging F.SM § 8.1.11 ✓ ✓ ✓ Self Tests F.STST § 8.1.12 ✓ ✓ ✓ Update Mechanism7 F.UPD § 8.1.13 ✓ ✓ ✓ Table 22 - TSF of the TOE 8.1.2 Access Control in Reading This function controls access to read functions and enforces the security policy for data retrieval. Prior to any data retrieval, it authenticates the actor trying to access the data, and checks the access conditions are fulfilled as well as the life cycle state. It ensures that at any time, the following keys are never readable: - MSK, - Pre-personalization Agent keys, - Personalization Agent keys, - BAC keys, - AA private key, - CA private key, - LSK. It controls access to the CPLC data as follow: - It ensures the CPLC data can be read during the personalization phase, - It ensures it cannot be readable without authentication at the end of the personalization step. It controls access to the TOE_ID as follow: - It ensures the TOE_ID data can be read during the manufacturing and personalization phases, - It ensures it cannot be readable without authentication in operational use phase. Regarding the file structure: In the Operational Use phase: - The terminal can read user data, the Document Security Object, EF.COM only after BAC authentication and through a valid secure channel. 7 The Update mechanism is also available on step before 5, to the manufacturer. 104/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 In the Manufacturing and Personalization phases: - The Manufacturer and the Personalization Agent can read all the data stored in the TOE after it is authenticated by the TOE (using its authentication keys). It ensures as well that no other part of the memory can be accessed at anytime 8.1.3 Access Control in Writing This function controls access to write functions (in FLASH MEMORY) and enforces the security policy for data writing. Prior to any data update, it authenticates the actor, and checks the access conditions are fulfilled as well as the life cycle state. It also ensures the CPLC data cannot be written anymore once the TOE is in Operational Use phase. Regarding the file structure: In the Operational Use phase: It is not possible to create any files (system or data files). Furthermore, it is not possible to update any files (system or data files), except for CVCA which can be updated if the “Secure Messaging” access condition is verified. In the Manufacturing and Personalization phases: The Manufacturing and Personalization Agent can create and write through a valid secure channel all the data files it needs after it is authenticated by the TOE (using its authentication keys). 8.1.4 Active Authentication This TSF provides the Active Authentication as described in [ICAO_9303]. It also provides management of this function in phase 5. 8.1.5 Basic Access Control This TSF provides the Basic Access Control, authentication and session keys generation to be used by F.SM, as described in [ICAO_9303]. 8.1.6 Chip Authentication This TSF provides the Chip Authentication, authentication and session keys generation to be used by F.SM, as described in [TR_03110]. It also provides management of this function in phase 5. 8.1.7 MRTD Personalization This security functionality ensures that the TOE, when delivered to the Personalization Agent, provides and requires authentication for data exchange. This authentication is based on a Triple DES authentication mechanism. This function allows to: • Manage symmetric authentication using Personalization Agent keys, • Compute session keys to be used by F.SM, • Load user data, • Create (Import or Generate on card) Chip Authentication key pair, • Create (Import or Generate on card)Active Authentication key pair, • Set Personalization Agent CPLC Data, • Set TOE life cycle in Operational Use phase. 105/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 8.1.8 Physical Protection This Security Function protects the TOE against physical attacks, so that the integrity and confidentiality of the TOE is ensured, including keys, user data, CPLC data, configuration data and TOE life cycle. It detects physical tampering, responds automatically, and also controls the emanations sent out by the TOE. 8.1.9 MRTD Pre-personalization This security functionality ensures that the TOE, when delivered to the Manufacturer, provides and requires an authentication mechanism for data exchange. This authentication is based on Triple DES symmetric authentication mechanism. This function allows to: • Diversify the MSK, • Manage symmetric authentication using Pre-personalization Agent keys, • Compute session keys to be used by F.SM, • Load data, • Create the MRTD application, • Load Personalization Agent keys, • Load the Pre-personalization Agent CPLC Data, • Set TOE life cycle in Personalization phase. This security function ensures the destruction of the MSK, once ISK is loaded. This security function ensures the destruction of the ISK, once Personalization Agent keys are loaded. 8.1.10 Safe State Management This security functionality ensures that the TOE gets back to a secure state when: • an integrity error is detected by F.STST described in § 8.1.12, • a tearing occurs (during a copy of data in FLASH MEMORY). This security functionality ensures that if such a case occurs, the TOE is either switched in the state "kill card" or becomes mute. 8.1.11 Secure Messaging This security functionality ensures the confidentiality, authenticity and integrity of the communication between the TOE and the interface device. In the operational phase, after a successful Authentication Procedure (i.e. BAC or CA), a secure channel is established. This security functionality also provides a Secure Messaging (SCP03-SCP02) for the Pre-personalization and Personalization phases. The protocols can be configured to protect the exchanges integrity and/or confidentiality. If an error occurs in the secure messaging layer, the session keys are destroyed. 8.1.12 Self Tests The TOE performs self-tests to verify the integrity of the TSF data: • At Reset, • Before using the TSF data, • Before using Chip Authentication Private Key and Active Authentication Private Key. 8.1.13 Update Mechanism This function is in charge of loading Updated Package. The update of the Initial TOE checks an evidence of authenticity and integrity of the loaded additional Code. The mechanism enforces that only the allowed version of the Update Package can be loaded on the Initial TOE. 106/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 The mechanism forbids the loading of an additional Code not intended to be assembled with the Initial TOE. Activation of the Update Package and update of the Identification Data shall be performed at the same time in an Atomic way. During the Load Phase of Update Package, the TOE shall remain secure. The secure messaging protects in confidentiality and integrity the exchange with the Update terminal. A GP secure authentication is used and the TOE is in charge to decipher the Update Package, to check the associated signature and to install the new functionalities. The Update Package contains its identification elements that are used, during audit, to uniquely identify loaded code. F.STST, F.SM, F.PERS, F.ACR, F.ACW, F.PHY and F_SM protect and support Update Mechanism. 107/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 8.2 SFRandTSF TSF SFR F.ACR F.ACW F.AA F.BAC F.CA F.PERS F.PHY F.PREP F.SS F.SM F.STST F.UPD FAU_SAS.1       ✓  ✓   FCS_CKM.1/BAC    ✓       ✓ FCS_CKM.1/MSK_DIV        ✓   ✓ FCS_CKM.1/GP      ✓  ✓   ✓ FCS_CKM.1/LSK_DIV        ✓   ✓ FCS_CKM.1/CA     ✓      ✓ FCS_CKM.1/KEY_GEN      ✓  ✓   ✓ FCS_CKM.4      ✓  ✓  ✓  FCS_COP.1/BAC_SHA    ✓        FCS_COP.1/BAC_ENC          ✓ ✓ FCS_COP.1/AUTH      ✓     ✓ FCS_COP.1/BAC_MAC          ✓ ✓ FCS_COP.1/MSK_SHA        ✓    FCS_COP.1/GP_ENC          ✓ ✓ FCS_COP.1/GP_AUTH        ✓   ✓ FCS_COP.1/GP_MAC          ✓ ✓ FCS_COP.1/GP_SDT_DEC      ✓  ✓   ✓ FCS_COP.1/CA_SHA     ✓       FCS_COP.1/CA_ENC          ✓ ✓ FCS_COP.1/CA_MAC          ✓ ✓ FCS_COP.1/SIG_GEN   ✓        ✓ FCS_RND.1   ✓ ✓  ✓  ✓    FIA_UID.1 ✓ ✓          FIA_UAU.1 ✓ ✓          FIA_UAU.4    ✓  ✓  ✓   ✓ FIA_UAU.5/BAC    ✓  ✓     ✓ FIA_UAU.5/MP        ✓   ✓ FIA_UAU.5/CA          ✓ ✓ FIA_UAU.6/BAC          ✓ ✓ FIA_UAU.6/MP          ✓ ✓ FIA_UAU.6/CA          ✓ ✓ FIA_AFL.1/BAC    ✓       ✓ FIA_AFL.1/MP      ✓  ✓   ✓ FIA_API.1/CA     ✓       FIA_API.1/AA   ✓         FDP_ACC.1/BAC ✓ ✓  ✓  ✓      FDP_ACC.1/MP ✓ ✓      ✓    FDP_ACC.1/ID ✓ ✓  ✓  ✓  ✓    FDP_ACF.1/BAC ✓ ✓  ✓  ✓      FDP_ACF.1/MP ✓ ✓      ✓    FDP_ACF.1/ID ✓ ✓  ✓  ✓  ✓    FDP_UCT.1/BAC          ✓ ✓ FDP_UCT.1/MP          ✓ ✓ FDP_UCT.1/CA          ✓ ✓ FDP_UIT.1/BAC          ✓ ✓ FDP_UIT.1/MP          ✓ ✓ FDP_UIT.1/CA          ✓ ✓ 108/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 TSF SFR F.ACR F.ACW F.AA F.BAC F.CA F.PERS F.PHY F.PREP F.SS F.SM F.STST F.UPD FDP_ITC.1/MP      ✓  ✓   ✓ FMT_MOF.1/PROT   ✓  ✓   ✓     FMT_MOF.1/GP      ✓  ✓     FMT_SMF.1   ✓  ✓ ✓  ✓     FMT_SMR.1    ✓  ✓  ✓     FMT_LIM.1       ✓  ✓    FMT_LIM.2       ✓  ✓    FMT_MTD.1/INI_ENA ✓ ✓      ✓     FMT_MTD.1/INI_DIS ✓     ✓       FMT_MTD.1/KEY_WRITE ✓ ✓    ✓       FMT_MTD.1/KEY_READ ✓            FMT_MTD.1/MP_KEY_WRITE ✓ ✓      ✓     FMT_MTD.1/MP_KEY_READ ✓            FMT_MTD.1/CAPK ✓ ✓    ✓       FMT_MTD.1/CAPK_READ ✓            FMT_MTD.1/AA_KEY_WRITE ✓ ✓    ✓       FMT_MTD.1/AA_KEY_READ ✓            FMT_MTD.1/LCS_PREP ✓ ✓      ✓     FMT_MTD.1/LCS_PERS ✓ ✓    ✓       FMT_MTD.1/LSK_READ ✓            FMT_MTD.1/AA_KEY_GEN      ✓  ✓     FMT_MTD.1/CA_KEY_GEN      ✓  ✓     FPT_EMS.1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓  ✓ ✓  FPT_FLS.1       ✓  ✓    FPT_TST.1           ✓  FPT_PHP.3       ✓  ✓    FTP_ITC.1/MP      ✓  ✓   ✓  FAU_SAS.1/UPD       ✓  ✓   ✓ FCS_CKM.1/UPD_ITC      ✓  ✓  ✓ ✓ ✓ FCS_CKM.1/UPD_DEC      ✓  ✓  ✓ ✓ ✓ FCS_CKM.1/UPD_INT      ✓  ✓  ✓ ✓ ✓ FCS_CKM.4/UPD      ✓  ✓  ✓  ✓ FCS_COP.1/UPD_ITC            ✓ FCS_COP.1/UPD_DEC            ✓ FCS_COP.1/UPD_SIG            ✓ FCS_COP.1/UPD_INT            ✓ FIA_AFL.1/UPD            ✓ FIA_UID.1/UPD            ✓ FIA_UAU.1/UPD            ✓ FDP_ACC.1/UPD            ✓ FDP_ACF.1/UPD            ✓ FDP_IFC.1/UPD            ✓ FDP_IFF.1/UPD            ✓ FDP_RIP.1/UPD            ✓ FMT_SMF.1/UPD            ✓ FMT_MTD.1/UPD_SK_PICC            ✓ FMT_MTD.1/UPD_KEY_READ            ✓ FMT_SMR.1/UPD            ✓ FPT_EMS.1 /UPD            ✓ FPT_FLS.1/UPD            ✓ FPT_TST.1/UPD            ✓ 109/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 TSF SFR F.ACR F.ACW F.AA F.BAC F.CA F.PERS F.PHY F.PREP F.SS F.SM F.STST F.UPD FTP_ITC.1/UPD            ✓ Table 23- SFR and TSF 110/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 9 GLOSSARY AND ACRONYMS 9.1 Glossary Term Definition Active Authentication Security mechanism defined in [ICAO_9303] option by which means the MRTD’s chip proves and the inspection system verifies the identity and authenticity of the MRTD’s chip as part of a genuine MRTD issued by a known State or Organization. Audit records Write-only-once non-volatile memory area of the MRTDs chip to store the Initialization Data and Pre-personalization Data. Authenticity Ability to confirm the MRTD and its data elements on the MRTD’s chip were created by the issuing State or Organization. Basic Access Control (BAC) Security mechanism defined in [ICAO_9303] by which means the MRTD’s chip proves and the inspection system protects their communication by means of secure messaging with Document Basic Access Keys (see there). Basic Inspection System (BIS) An inspection system which implements the terminals part of the Basic Access Control Mechanism and authenticates itself to the MRTD’s chip using the Document Basic Access Keys derived from the printed MRZ data for reading the logical MRTD. Biographical data (biodata) The personalized details of the MRTD holder of the document appearing as text in the visual and machine readable zones on the biographical data page of a passport book or on a travel card or visa. [ICAO_9303] Biometric reference data Data stored for biometric authentication of the MRTD holder in the MRTD’s chip as (i) digital portrait and (ii) optional biometric reference data. Counterfeit An unauthorized copy or reproduction of a genuine security document made by whatever means. [ICAO_9303] Country Signing CA Certificate (Ccsca) Self-signed certificate of the Country Signing CA Public Key (KPuCSCA) issued by CSCA stored in the inspection system. Document Basic Access Keys Pair of symmetric (two-key) Triple-DES keys used for secure messaging with encryption (key KENC) and message authentication (key KMAC) of data transmitted between the MRTD’s chip and the inspection system [ICAO_9303]. It is drawn from the printed MRZ of the passport book to authenticate an entity able to read the printed MRZ of the passport book. Document Security Object (SOD) A RFC3369 CMS Signed Data Structure, signed by the Document Signer (DS). Carries the hash values of the LDS Data Groups. It is stored in the MRTD’s chip. It may carry the Document Signer Certificate (CDS). [ICAO_9303] Eavesdropper A threat agent with Enhanced-Basic attack potential reading the communication between the MRTD’s chip and the inspection system to gain the data on the MRTD’s chip. Enrolment The process of collecting biometric samples from a person and the subsequent preparation and storage of biometric reference templates representing that person’s identity. [ICAO_9303] Extended Access Control (EAC) Security mechanism identified in [ICAO_9303] by which means the MRTD’s chip (i) verifies the authentication of the inspection systems authorized to read the optional biometric reference data, (ii) controls the access to the optional biometric reference data and (iii) protects the confidentiality and integrity of the optional biometric reference data during their transmission to the inspection system by secure messaging. The Personalization Agent may use the same mechanism to authenticate themselves with Personalization Agent Private Key and to get write and read access to the logical MRTD and TSF data. Extended Inspection System (EIS) A role of a terminal as part of an inspection system which is in addition to Basic Inspection System authorized by the issuing State or Organization to read the optional biometric reference data and supports the terminals part of the Extended Access Control Authentication Mechanism. Forgery Fraudulent alteration of any part of the genuine document, e.g. changes to the biographical data or the portrait. [ICAO_9303] 111/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Term Definition Global Interoperability The capability of inspection systems (either manual or automated) in different States throughout the world to exchange data, to process data received from systems in other States, and to utilize that data in inspection operations in their respective States. Global interoperability is a major objective of the standardized specifications for placement of both eye-readable and machine readable data in all MRTDs. [ICAO_9303] IC Dedicated Support Software That part of the IC Dedicated Software (refer to above) which provides functions after TOE Delivery. The usage of parts of the IC Dedicated Software might be restricted to certain phases. IC Dedicated Test Software That part of the IC Dedicated Software (refer to above) which is used to test the TOE before TOE Delivery but which does not provide any functionality thereafter. IC Identification Data The IC manufacturer writes a unique IC identifier to the chip to control the IC as MRTD material during the IC manufacturing and the delivery process to the MRTD manufacturer (i.e MRTD packaging responsible). Impostor A person who applies for and obtains a document by assuming a false name and identity, or a person who alters his or her physical appearance to represent himself or herself as another person for the purpose of using that person’s document. [ICAO_9303] Improperly document person A person who travels, or attempts to travel with: (a) an expired travel document or an invalid visa; (b) a counterfeit, forged or altered travel document or visa; (c) someone else’s travel document or visa; or (d) no travel document or visa, if required. [ICAO_9303] Initialisation Process of writing Initialisation Data (see below) to the TOE (cf. 2.2.3.2.2). Initialization Data Any data defined by the TOE Manufacturer and injected into the non-volatile memory by the Integrated Circuits manufacturer (Phase 2). These data are for instance used for traceability and for IC identification as MRTD’s material (IC identification data). Inspection The act of a State examining an MRTD presented to it by a traveler (the MRTD holder) and verifying its authenticity. [ICAO_9303] Inspection System (IS) A technical system used by the border control officer of the receiving State (i) examining an MRTD presented by the traveler and verifying its authenticity and (ii) verifying the traveler as MRTD holder. Integrated Circuit (IC) Electronic component(s) designed to perform processing and/or memory functions. The MRTD’s chip is a integrated circuit. Integrity Ability to confirm the MRTD and its data elements on the MRTD’s chip have not been altered from that created by the issuing State or Organization Issuing Organization Organization authorized to issue an official travel document (e.g. the United Nations Organization, issuer of the Laissez-passer). [ICAO_9303] Issuing State The Country issuing the MRTD. [ICAO_9303] Logical Data Structure (LDS) The collection of groupings of Data Elements stored in the optional capacity expansion technology [ICAO_9303]. The capacity expansion technology used is the MRTD’s chip. Logical MRTD Data of the MRTD holder stored according to the Logical Data Structure [ICAO_9303] as specified by ICAO on the contactless integrated circuit. It presents contactless readable data including (but not limited to) (1) personal data of the MRTD holder, (2) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1), (3) the digitized portraits (EF.DG2), (4) the biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both and (5) the other data according to LDS (EF.DG5 to EF.DG16). (6) EF.COM and EF.SOD Logical travel document Data stored according to the Logical Data Structure as specified by ICAO in the contactless integrated circuit including (but not limited to) (1) data contained in the machine-readable zone (mandatory), (2) digitized photographic image (mandatory) and (3) fingerprint image(s) and/or iris image(s) (optional). 112/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Term Definition Machine Readable Travel Document (MRTD) Official document issued by a State or Organization which is used by the holder for international travel (e.g. passport, visa, official document of identity) and which contains mandatory visual (eye readable) data and a separate mandatory data summary, intended for global use, reflecting essential data elements capable of being machine read. [ICAO_9303] Machine Readable Visa (MRV) A visa or, where appropriate, an entry clearance (hereinafter collectively referred to as visas) conforming to the specifications contained herein, formulated to improve facilitation and enhance security for the visa holder. Contains mandatory visual (eye readable) data and a separate mandatory data summary capable of being machine read. The MRV is normally a label which is attached to a visa page in a passport. [ICAO_9303] Machine Readable Zone (MRZ) Fixed dimensional area located on the front of the MRTD or MRP Data Page or, in the case of the TD1, the back of the MRTD, containing mandatory and optional data for machine reading using OCR methods. [ICAO_9303] Machine-verifiable biometrics feature A unique physical personal identification feature (e.g. an iris pattern, fingerprint or facial characteristics) stored on a travel document in a form that can be read and verified by machine. [ICAO_9303] MRTD application Non-executable data defining the functionality of the operating system on the IC as the MRTD’s chip. It includes - the file structure implementing the LDS [ICAO_9303], - the definition of the User Data, but does not include the User Data itself (i.e. content of EF.DG1 to EF.DG14, EF.DG 16, EF.COM and EF.SOD) and - the TSF Data including the definition the authentication data but except the authentication data itself. MRTD Basic Access Control Mutual authentication protocol followed by secure messaging between the inspection system and the MRTD’s chip based on MRZ information as key seed and access condition to data stored on MRTD’s chip according to LDS. MRTD holder The rightful holder of the MRTD for whom the issuing State or Organization personalized the MRTD. MRTD’s Chip A contactless integrated circuit chip complying with ISO/IEC 14443 and programmed according to the Logical Data Structure as specified by ICAOT, [ICAO], p. 14. MRTD’s chip Embedded Software Software embedded in a MRTD’s chip and not being developed by the IC Designer. The MRTD’s chip Embedded Software is designed in Phase 1 and embedded into the MRTD’s chip in Phase 2 of the TOE life-cycle. Optional biometric reference data Data stored for biometric authentication of the MRTD holder in the MRTD’s chip as (i) encoded finger image(s) (EF.DG3) or (ii) encoded iris image(s) (EF.DG4) or (iii) both. Note that the European commission decided to use only finger print and not to use iris images as optional biometric reference data. Passive authentication (i) verification of the digital signature of the Document Security Object and (ii) comparing the hash values of the read LDS data fields with the hash values contained in the Document Security Object. Personalization The process by which the portrait, signature and biographical data are applied to the document. This may also include the optional biometric data collected during the “Enrolment” (cf. 2.2.3.2.3, Step 6). Personalization Agent The agent acting on the behalf of the issuing State or Organization to personalize the MRTD for the holder by (i) establishing the identity the holder for the biographic data in the MRTD, (ii) enrolling the biometric reference data of the MRTD holder i.e. the portrait, the encoded finger image(s) or (ii) the encoded iris image(s) and (iii) writing these data on the physical and logical MRTD for the holder. Personalization Agent Authentication Information TSF data used for authentication proof and verification of the Personalization Agent. Personalization Agent Key Symmetric cryptographic authentication key used (i) by the Personalization Agent to prove their identity and get access to the logical MRTD and (ii) by the MRTD’s chip to verify the authentication attempt of a terminal as Personalization Agent according to the SFR FIA_UAU.4/BAC, FIA_UAU.5/BAC and FIA_UAU.6/BAC. 113/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 Term Definition Physical travel document Travel document in form of paper, plastic and chip using secure printing to present data including (but not limited to) (1) biographical data, (2) data of the machine-readable zone, (3) photographic image and (4) other data. Pre-Personalisation Process of writing Pre-Personalisation Data (see below) to the TOE including the creation of the MRTD Application ((cf. 2.2.3.2.3, Step 5) Pre-personalization Data Any data that is injected into the non-volatile memory of the TOE by the MRTD Manufacturer (i.e IC manufacturer) (Phase 2) for traceability of non-personalized MRTD’s and/or to secure shipment within or between life cycle phases 2 and 3. It contains (but is not limited to) the Active Authentication Key Pair and the Personalization Agent Key Pair. Pre-personalized MRTD’s chip MRTD’s chip equipped with an unique identifier and an unique asymmetric Active Authentication Key Pair of the chip. Primary Inspection System (PIS) An inspection system that contains a terminal for the contactless communication with the MRTD’s chip and does not implement the terminals part of the Basic Access Control Mechanism. random identifier Random identifier used to establish a communication to the TOE in Phase 3 and 4 preventing the unique identification of the MRTD and thus participates in the prevention of traceability. Receiving State The Country to which the Traveler is applying for entry. [ICAO_9303] reference data Data enrolled for a known identity and used by the verifier to check the verification data provided by an entity to prove this identity in an authentication attempt. secondary image A repeat image of the holder’s portrait reproduced elsewhere in the document by whatever means. [ICAO_9303] Secure messaging in encrypted mode Secure messaging using encryption and message authentication code according to ISO/IEC 7816-4 Skimming Imitation of the inspection system to read the logical MRTD or parts of it via the contactless communication channel of the TOE without knowledge of the printed MRZ data. Travel document A passport or other official document of identity issued by a State or Organization, which may be used by the rightful holder for international travel. [ICAO_9303] Traveler Person presenting the MRTD to the inspection system and claiming the identity of the MRTD holder. TSF data Data created by and for the TOE, that might affect the operation of the TOE ([CC_1]). Unpersonalized MRTD The MRTD that contains the MRTD Chip holding only Initialization Data and Pre- personalization Data as delivered to the Personalisation Agent from the Manufacturer. User data Data created by and for the user, that does not affect the operation of the TSF ([CC_1]). Verification The process of comparing a submitted biometric sample against the biometric reference template of a single enrolee whose identity is being claimed, to determine whether it matches the enrolee’s template. Verification data Data provided by an entity in an authentication attempt to prove their identity to the verifier. The verifier checks whether the verification data match the reference data known for the claimed identity. 114/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 9.2 Acronyms Acronym Term BIS Basic Inspection System CC Common Criteria EF Elementary File GIS General Inspection System ICCSN Integrated Circuit Card Serial Number ISK Issuer Secret Key MF Master File MSK Manufacturer Secret Key n.a. Not applicable OSP Organizational Security Policy PT Personalization Terminal SAR Security Assurance Requirements SFR Security Functional Requirement TOE Target Of Evaluation TSF TOE Security Functions 115/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 10 LITERATURE Common Criteria [CC_1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017 [CC_2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017 [CC_3] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017 [CC_EM] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017 Protection Profiles [PP_0002] PP conformant to Smartcard IC Platform Protection Profile, Version 1.0, July 2001; registered and certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference BSI-PP-0002-2001 Smartcard Integrated Circuit Platform Augmentations, Version 1.00, March 8th, 2002 [PP_IC] Security IC Platform Protection Profile with Augmented Packages, Version 1.0; registered and certified by BSI (Bundesamt für Sicherheit in der Informationstechnik) under the reference BSI- PP-0084-2014 [PP_BAC] Machine readable travel documents with “ICAO Application”, Basic Access control – BSI-PP- 0055 v1.10 25th march 2009 [PP_EAC] Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Extended Access Control, BSI-PP-0056, Version 1.10, 25th March 2009 [PP_0090] Machine Readable Electronic Documents - Optionales Nachladen (Optional Post-Emission Updates) [MR.ED-ON-PP], BSI-CC-PP-0090-2016, Version 0.9.2, August 18th, 2016. [PP_0087] Common Criteria Protection ProfileMachine-Readable Electronic Documents based on BSI TR- 03110 for Official Use [MR.ED-PP], Version 2.0.3, July 18th, 2016, BSI-CC-PP-0087-V2-2016- MA-01 ANSSI [JIL_SRCL] Joint Interpretation Library – Security requirements for post-delivery code loading – Version 1.0, February 2016 [ANSSI-PG- 083] Guide des mécanismes cryptographiques : Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques. ANSSI, Version 2.04, 2020-01-01 IC [IC_CERT] ANSSI-CC-2023_37 116/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 [IC_ST]8 Public Security Target SCR404U version B Reference SEC222 ICAO [ICAO_9303] ICAO Doc 9303, Machine Readable Travel Documents, Eighth Edition, 2021 – Part 11: Security Mechanisms for MRTDs [ICAO_9303_10] ICAO Doc 9303, Machine Readable Travel Documents, Eighth Edition, 2021 – Part 10: Part 10: Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC) [ICAO_9303_12] ICAO Doc 9303, Machine Readable Travel Documents, Eighth Edition, 2021 – Part 12: Part 12: Public Key Infrastructure for MRTDs [ICAO] INTERNATIONAL CIVIL AVIATION ORGANIZATION FACILITATION (FAL) DIVISION, twelfth session (Cairo, Egypt, 22 March – 1 April 2004) ISO [ISO_9797_1] ISO/IEC 9797-1 Information technology – Security techniques – Message Authentication codes (MACs) – part 1: Mechanisms using a block cipher, Second edition 2011-03-01 [ISO_15946] Information technology -- Security techniques -- Cryptographic techniques based on elliptic curves [ISO_9796_2] ISO/IEC 9796-2:2010 Information technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Integer factorization based mechanisms [ISO_18013] ISO/IEC 18013-2:2020 Personal identification — ISO-compliant driving licence — Part 2: Machine-readable technologies, Part 3: Access control, authentication and integrity validation — Amendment 1: PACE protocol, Part 4: Test methods IDEMIA [ALC_SCT] ID division: sensitive code transfer, I/R&D/2/SQA 515 [ALC_STM] Secure transfer of masks, I CRD13 2 CRD 507 Other [TR_03110] Technical Guideline Advanced Security Mechanisms for Machine Readable Travel Documents – Part 1: eMRTDs with BAC/PACEv2 and EACv1, and Part 3: Common Specification TR-03110, Version 2.2, Bundesamt für Sicherheit in der Informationstechnik (BSI) [TR_03111] BSI: Technical Guideline TR-03111: Elliptic Curve Cryptography, Version 2.0, 2012 [FIPS_180_2] FIPS 180-2, Federal Information Processing Standards Publication (FIPS PUB) 180-2, Secure Hash Standard, August 2002 [FIPS_46_3] FIPS 46-3, Federal Information Processing Standards Publication (FIPS PUB) 46-3, Data Encryption Standard (DES), 1999 October 25 [FIPS_186_5] FIPS 186-5, Federal Information Processing Standards Publication (FIPS PUB) 186-5, Digital Signature Standard (DSS), Feb. 2023 8 The version of this document can be found in [IC_CERT]. 117/117 IDEMIA Certification Secure Elements 21/11/2023| FQR 110 A0BF All Information and Intellectual property rights reserved at ©IDEMIA 2023 [FIPS_197] FIPS 197, Federal Information Processing Standards Publication (FIPS PUB 197), Advanced Encryption Standard (AES) [NIST_800_38B] NIST Special Publication 800-38B: 2005, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, May 2005 [GPC_SPE_034] GlobalPlatform – Card Specification – Version 2.2.1 – Public Release, January 2011 [IEEE] IEEE Std 1363a-2004 Standard Specification of Public-Key Cryptography [ANSIX9.31] "Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (DSA)" - ANSI X9.31-1998, American Bankers Association [SP800-90A] NIST SP 800-90 – Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)