Security Target COMMON CRITERIA DOCUMENTS | Version 1.0 Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600 Certification-ID: BSI-DSZ-CC-1074-V3    Public Version MaskTech International GmbH | Nordostpark 45 | Nuernberg | www.masktech.com | +49 (0)911 95 51 49-0 Security Target Contents 1 ST Introduction (ASE_INT.1) 5 1.1 ST Reference and TOE Reference . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 TOE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1 TOE Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.2 TOE description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.3 TOE Usage and Main Security Functions . . . . . . . . . . . . . . . . 7 1.2.4 TOE Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Conformance Claims (ASE_CCL.1) 11 2.1 CC Conformance Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 PP Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Package Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Conformance Rationales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 PP Additions and Adaptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Security Problem Definition (ASE_SPD.1) 14 3.1 Users and Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4 Security Objectives (ASE_OBJ.2) 21 4.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Security Objectives for the Operational Environment . . . . . . . . . . . . . 23 4.3 Security Objectives Rationales . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.1 Correspondence between Security Problem Definition and Security Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.2 Security Objectives Rationale . . . . . . . . . . . . . . . . . . . . . . 25 5 Extended Components Definition (ASE_ECD.1) 27 Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 1 Security Target 6 Security Requirements (ASE_REQ.2) 28 6.1 Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1.1 FCS_CKM.1b Cryptographic key generation (BAC) . . . . . . . . . . 30 6.1.2 FCS_ CKM.1p Cryptographic key generation (PACE, session keys) . . 30 6.1.3 FCS_CKM.1e Cryptographic key generation (PACE, ephemeral key pairs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.4 FCS_CKM.6 Timing and event of cryptographic key destruction . . . 31 6.1.5 FCS_COP.1a Cryptographic operation (Active Authentication, signa- ture generation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1.6 FCS_COP.1h Cryptographic operation (Active Authentication, hash functions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1.7 FCS_COP.1hb Cryptographic operation (BAC, hash functions) . . . . 33 6.1.8 FCS_COP.1mb Cryptographic operation (BAC, mutual authentication) 33 6.1.9 FCS_COP.1sb Cryptographic operation (BAC, Secure Messaging) . . 34 6.1.10 FCS_COP.1n Cryptographic operation (Nonce encryption) . . . . . . 35 6.1.11 FCS_COP.1e Cryptographic operation (Key agreement) . . . . . . . 35 6.1.12 FCS_COP.1hp Cryptographic operation (PACE, hash functions) . . . 35 6.1.13 FCS_COP.1mp Cryptographic operation (PACE, mutual authentication) 36 6.1.14 FCS_COP.1sp Cryptographic operation (PACE, Secure Messaging) . 36 6.1.15 FCS_RNG.1 Random number generation . . . . . . . . . . . . . . . 37 6.1.16 FDP_ACC.1a Subset access control (Issuance procedure) . . . . . . 39 6.1.17 FDP_ACC.1b Subset access control (BAC) . . . . . . . . . . . . . . . 39 6.1.18 FDP_ACC.1p Subset access control (PACE) . . . . . . . . . . . . . . 39 6.1.19 FDP_ACF.1a Security attribute-based access control (Issuance pro- cedure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.20 FDP_ACF.1b Security attribute based access control (BAC) . . . . . 40 6.1.21 FDP_ACF.1p Security attribute-based access control (PACE) . . . . . 41 6.1.22 FDP_ITC.1 Import of user data without security attributes . . . . . 41 6.1.23 FDP_UCT.1b Basic data exchange confidentiality (BAC) . . . . . . . 42 6.1.24 FDP_UCT.1p Basic data exchange confidentiality (PACE) . . . . . . 42 6.1.25 FDP_UIT.1b Data exchange integrity (BAC) . . . . . . . . . . . . . . 42 6.1.26 FDP_UIT.1p Data exchange integrity (PACE) . . . . . . . . . . . . . 43 6.1.27 FIA_AFL.1a Authentication failure handling (Active Authentication Information Access Key) . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.1.28 FIA_AFL.1d Authentication failure handling (Transport key) . . . . . 43 6.1.29 FIA_AFL.1r Authentication failure handling (Readout key) . . . . . . 44 6.1.30 FIA_UAU.1 Timing of authentication . . . . . . . . . . . . . . . . . 44 6.1.31 FIA_UAU.4 Single-use authentication mechanisms . . . . . . . . . 45 Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 2 Security Target 6.1.32 FIA_UAU.5 Multiple authentication mechanisms . . . . . . . . . . . 45 6.1.33 FIA_UID.1 Timing of identification . . . . . . . . . . . . . . . . . . 45 6.1.34 FMT_MOF.1 Management of security functions behavior . . . . . . 46 6.1.35 FMT_MTD.1 Management of TSF data . . . . . . . . . . . . . . . . . 46 6.1.36 FMT_SMF.1 Specification of management functions . . . . . . . . . 47 6.1.37 FMT_SMR.1 Security roles . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.38 FPT_EMS.1 TOE Emanation . . . . . . . . . . . . . . . . . . . . . . 47 6.1.39 FPT_PHP.3 Resistance to physical attack . . . . . . . . . . . . . . . 48 6.1.40 FTP_ITC.1 Inter-TSF trusted channel . . . . . . . . . . . . . . . . . 48 6.2 Security Assurance Requirements . . . . . . . . . . . . . . . . . . . . . . . . 48 6.3 Security Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . . 49 6.3.1 Security Functional Requirements Rationale . . . . . . . . . . . . . . 49 6.3.1.1 Tracing between Security Objectives and Security Func- tional Requirements . . . . . . . . . . . . . . . . . . . . . 50 6.3.1.2 Justification for the tracing . . . . . . . . . . . . . . . . . . 51 6.3.1.3 Dependencies for Security Functional Requirements . . . . 53 6.3.2 Security Assurance Requirements Rationale . . . . . . . . . . . . . . 57 7 TOE Summary Specification (ASE_TSS.1) 58 7.1 TOE Security Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.1.1 TOE Security Functions from Hardware and Cryptographic Library . . 58 7.1.1.1 F.IC_CL: Security Functions of the Hardware and Crypto- graphic Library . . . . . . . . . . . . . . . . . . . . . . . . 58 7.1.2 TOE Security Functions from Basic Software – Operating System . . . 58 7.1.2.1 F.Access_Control . . . . . . . . . . . . . . . . . . . . . . . 58 7.1.2.2 F.Identification_Authentication . . . . . . . . . . . . . . . 59 7.1.2.3 F.Management . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1.2.4 F.Crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1.2.5 F.Verification . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.2 Assurance Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.3 TOE Summary Specification Rationale . . . . . . . . . . . . . . . . . . . . . 62 7.4 Statement of Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4.1 Compatibility: TOE Security Environment . . . . . . . . . . . . . . . 66 7.4.1.1 Security Objectives . . . . . . . . . . . . . . . . . . . . . . 66 7.4.1.2 Security Requirements . . . . . . . . . . . . . . . . . . . . 68 7.4.1.3 Assurance Requirements . . . . . . . . . . . . . . . . . . . 72 7.4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 3 Security Target 8 Glossary 73 8.1 CC Related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.2 ePassport Related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9 Bibliography 75 10 Revision History 78 11 Contact 79 A Overview Cryptographic Algorithms 80 Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 4 Security Target 1 ST Introduction (ASE_INT.1) 1.1 ST Reference and TOE Reference Title Security Target – Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600 Version 1.0, 2025-11-24 Editors MASKTECH INTERNATIONAL GMBH Sponsor NTT Data Corporation Developer MASKTECH INTERNATIONAL GMBH Registration BSI-DSZ-CC-1074-V3 CC Version CC:2022 (Revision 1) Compliant to Protection Profile for ePassport IC with SAC (BAC+PACE) and Active Au- thentication (JISEC C0500) Assurance Level EAL4 augmented by ALC_DVS.2 and ALC_FLR.3 TOE name Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600 TOE hardware STMicroelectronics, ST31N600, smartcard IC including cryptographic library Neslib 6.7.4 TOE version MTCOS Pro 2.6 Keywords Smart card, IC card, ePassport, Basic Access Control (BAC), Supplemen- tal Access Control (SAC), PACE, Active Authentication N The notation “Xaica-α ” may be substituted by the notation “Xaica-Alpha” to prevent potential coding errors as they may occur if displayed on e.g. a web site. Both notations are equivalent. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 5 Security Target 1.2 TOE Overview 1.2.1 TOE Types The TOE is an ePassport IC (including necessary software). This ePassport IC is composed of IC chip hardware with the contactless communication interface, and basic software (operating system)andePassportapplicationprogramthatareinstalledinthesaidhardware(hereinafter, the term an “IC chip” shall mean an “ePassport IC”). An external antenna is connected to the IC chip for contactless communication purpose, and the IC chip is embedded in the plastic sheet together with the antenna to constitute a portion of a passport booklet. 1.2.2 TOE description The TOE addressed by this Security Target is an ePassport IC including the necessary software. It comprises of: • the integrated circuit (IC) ST31N600 by STMicroelectronics, • the cryptographic library Neslib 6.7.4 by STMicroelectronics, • the basic software (operating system, OS) MTCOS Pro 2.6 implemented on the IC, • the ePassport application software, • the configuration script and • the associated guidance documentation [AGD]. The IC hardware ST31N600 including the cryptographic library Neslib 6.7.4 provides basic functionality, among others the contactless communication interface, and low-level security features (e.g. random number generator, 3DES-, AES and EC-support). Both are certified compliant to the Protection Profile [CC_PP-0084]: • ANSSI-CC-2022/21-R02 according to CC EAL6 augmented by ALC_FLR.2 and ASE_TSS.2 and • ANSSI-CC-2022/42-R02 according to CC EAL5 augmented by ALC_DVS.2, AVA_VAN.5 and ALC_FLR.2 The IC hardware can be configured for an antenna capacitance of either 20 pF or 68 pF. The TOE is only using 68 pF. MTCOS Pro is a fully interoperable multi-application smart card operating system compli- ant to [ISO_7816]. It provides the high-level cryptography and the basic functionality for the secure usage of the product. The ePassport application uses the basic functionality of the OS to provide the specific ePassport functionality. It is developed according to the Logical Data Structure (LDS) compli- ant to [ICAO_9303]. The ePassport is viewed as unit of the physical part of the ePassport in form of the IC sheet/booklet and chip. It presents visual readable data including (but not limited to) personal data of the Passport Holder 1. the biographical data on the biographical data page of the travel document sur- face, Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 6 Security Target 2. the printed data in the Machine Readable Zone (MRZ) and 3. the printed portrait. the logical ePassport asdataofthePassportHolderstoredaccordingtotheLogicalData Structure as defined in [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 Passport Holder 1. the digital Machine Readable Zone Data (digital MRZ data, EF.DG1), 2. the digitized portraits (EF.DG2), 3. the other data according to LDS (EF.DG13 to EF.DG15) and 4. the Document Security Object (SOD). 1.2.3 TOE Usage and Main Security Functions A passport is an identification document issued by each country’s government or equivalent public organization, which certifies, for the purpose of international travel, the identity of its holder, generally in a booklet form (passport booklet). The International Civil Aviation Organization (ICAO) of the United Nations has provided the passport booklet guidelines. As for conventional passports, all information necessary as the identification was printed on a paper booklet, and thereby this could cause these passports to be forged for illicit purposes. In order to prevent such forgery, an IC chip containing personal information with digital signature has been incorporated in a passport booklet. Since valid digital signature can be granted only by the official passport issuing authorities, a high level of forgery prevention can be achieved. However, digital signature is not enough to counter forgery of copying personal information with authorized signature to store such information on a different IC chip. This type of forgery attack can be countered by adding the Active Authentication function to the IC chip and verifying the authenticity of the IC chip with the use of the said function. The TOE is embedded in a plastic sheet and then interfiled in a passport booklet. At immigration, the immigration official inspects the passport booklet using a passport inspec- tion terminal (hereinafter a “terminal”). Aside from the information printed on the passport booklet in ordinary characters, the same information is encoded, printed on the machine readable zone (MRZ) of the passport booklet, and read by the optical character reader of the terminal. The information is digitized1 and is stored in the IC chip, i.e., the TOE. These digitalized data are read by the terminal through the contactless communication interface of the TOE. The digitalized data include facial images. The antenna used for the TOE to perform contactless communication with the terminal is connected to the TOE in the plastic sheet. The TOE operates using wireless signal power supplied from the terminal and is configured for an antenna capacitance of 68 pF. 1 Digital signature is added to individual digital data by the passport issuing authorities in order to prevent the forgery of digital data. The verification process of the digital signature has been standardized as the Passive Authentication by ICAO. PKI that provides interoperability for all member states of ICAO is implemented from the grant of digital signature through the verification thereof with the terminal for the purpose of supporting Passive Authentication. Since the Passive Authentication is performed through verification of digital signature (including background PKI) without involvement of the security functions of the TOE, it is not included in the security requirements for the TOE. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 7 Security Target ThemainsecurityfunctionsoftheTOEaretoprotectdatastoredintheTOEfromillicitread- ing or writing. The operation of the security functions applied to contactless communication with the terminal shall comply with the BAC, PACE, and Active Authentication specifications defined by Part 11 of Doc [ICAO_9303]. Attacks on protected data in the TOE include those through the contactless communica- tion interface of the TOE and those attempting to disclose internal confidential information (Active Authentication Private Key) through physical attacks on the TOE. The TOE provides the main security functions, including: • BAC function (mutual authentication and Secure Messaging); • PACE function (mutual authentication and Secure Messaging); • Active Authentication support function (prevention of copying the IC chip); • Disabling function of BAC function (prohibition of operating BAC after issuing a pass- port); • Write protection function (protection on writing data after issuing a passport); • Protection function in transport (protection against attacks during transport before issuing the TOE); and • Tamper resistance (protection against confidential information leak due to physical attacks). 1.2.4 TOE Life Cycle The TOE life cycle is described below to clarify the security requirements for the TOE. The TOE life cycle of general IC chips is often described in terms of seven phases in the life cycle. As for the ePassport IC, however, the life cycle is divided into four phases instead of seven. Phase 1 (Development): Development of IC chip hardware, basic software (operating system), and application software Phase 2 (Manufacturing): Manufacturing of the IC chip (with software installed) and embedding it together with antenna in the plastic sheet Phase 3 (Personalization): Production of a passport booklet and writing of personal data Phase 4 (Operational Use): Use of the TOE by the Passport Holder in operational environ- ment Phase 1 Phase 1 is a development phase: STMicroelectronics develops the IC chip hardware, the IC Dedicated Software and the associated guidance documentation. MASKTECH INTERNATIONAL GMBH develops the basic software (operating system) using the IC guidance documentation, the ePassport application software and the associated guidance documentation. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 8 Security Target In phase 1, threats in the operational environment are not considered, but proper develop- ment security shall be maintained to protect the confidentiality and integrity of development data. Security related to the TOE in the development phase is evaluated as the development security in assurance requirements. The TOE security functions are still not validly operational in the development phase. All sites maintain a secure development environment. The basic software and the application software is securely delivered from MASKTECH INTERNATIONAL GMBH to STMicroelectronics. Phase 2 Phase 2 is a manufacturing phase. STMicroelectronics ThehardwarefortheICchipismanufactured, andoperatingsystem and application software for passport are installed in this hardware. A file object neces- sary for an ePassport is created in the TOE and an IC chip identification serial number is written into the file object. The functional tests of the internal circuit of the IC chip are conducted before the IC chip is sealed (i.e. the Flash Loader is deactivated). After that, only the contactless communication interface becomes available as an external interface. The manufactured IC is securely delivered from STMicroelectronics to the IC Sheet Manufacturer. IC Sheet Manufacturer The manufactured IC chip is embedded in the plastic sheet together with the contactless communication antenna. The IC Sheet Manufacturer changes the transport key and writes the readout key and Active Authentication In- formation Access Key in agreement with the Booklet Manufacturer. Furthermore, he configures the PACE-key, writes the serial number of the sheet into DG13 and writes temporary user data for functional testing. In the following, this process is denoted personalization (pre-issuance). In this phase, threats from the operational environment are not considered, but proper development security shall be maintained to protect the confidentiality and integrity of the components of the IC chip. The TOE is issued to the passport issuing authorities2 . Phase 3 The TOE in phase 3 is put under the control of the passport issuing authorities. Although no explicit attack against the TOE is assumed under the control of the passport issu- ing authorities, the TOE is required to have security functionality that allows only authorized individuals to process the TOE, as the organizational security policy. Booklet Manufacturer The TOE is interfiled in the ePassport booklet and information necessary for ePassport is written therein. This information includes the personal information of the passport holder (e.g. name, information on birth and so on) and 2 In Japan, the Ministry of Foreign Affairs of Japan and the passport manufacturer and regional passport offices under its direction fall under the authorities. The passport manufacturer interfiles a TOE embedded plastic sheet in a passport booklet and configures necessary data other than personal information (e.g. date of birth, facial image data, and data for security related to the said data). Regional passport offices configure passport data related to personal information. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 9 Security Target cryptographic key used by the security functions. In addition, the BAC functions im- plemented in the TOE can be disabled in this phase. In the following, this process is denoted personalization (post-issuance). After the completion of personalization of all information, the ePassport is issued to the holder thereof. Phase 4 Phase 4 is a phase subsequent to the handover of the passport booklet to the end user, i.e., the holder thereof. The passport booklet is carried along with the holder thereof and used as a means to certify the identity of the holder in various situations, including immigration procedures. Inphase4,noinformationstoredintheTOEisalteredordeleted. TheTOEsecurityfunction protects the information necessary for immigration procedures against illicit reading, unless the information is read by an Authorized Terminal. The private key for Active Authentication is only used for the internal processing of the TOE and will never be readout to anywhere other than the TOE. The TOE security functions protect the information assets in the TOE against external unauthorized access. Note 1: All steps performed by STMicroelectronics in life cycle phases 1 and 2 including the delivery from STMicroelectronics to the IC Sheet Manufacturer are covered by ANSSI-CC- 2022/21-R02. The development of the software and associated documentation performed by MASKTECH INTERNATIONAL GMBH in life cycle phase 1 is examined under the ALC assurance of this certification, while the activites of the IC Sheet Manufacturer in life cycle phase 2 and of the Booklet Manufacturer in life cycle phase 3 are examined under the AGD assurance. Delivery Naming Conventions In this ST the terms delivery and delivered are used to describe the transport of hardware, software or guidance documentation within the life cycle phases 1 and 2: • software (basic software, application software and transport key) from MASKTECH IN- TERNATIONAL GMBH to the IC manufacturer STMicroelectronics • IC including all software from the STMicroelectronics to the IC Sheet Manufacturer • configuration script and transport key from MASKTECH INTERNATIONAL GMBH to the IC Sheet Manufacturer • guidance documentation from MASKTECH INTERNATIONAL GMBH to the IC Sheet Manu- facturer The term issuance and issued are used to describe the transport of of hardware, soft- ware or guidance documentation between the life cycle phases 2 and 3 or phases 3 and 4, respectively: • IC sheet from the IC Sheet Manufacturer to the Booklet Manufacturer • key data from the IC Sheet Manufacturer to the Booklet Manufacturer (or vice versa, if the Booklet Manufacturer provides the keys) • guidance documentation from the IC Sheet Manufacturer to the Booklet Manufacturer • the personalized ePassport from the Booklet Manufacturer to the Passport Holder Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 10 Security Target 2 Conformance Claims (ASE_CCL.1) 2.1 CC Conformance Claim This Security Target claims conformance to • Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; CCMB-2022-11-001, Version CC:2022, Revision 1, November 2022 [CC_Part1] • Common Criteria for Information Technology Security Evaluation, Part 2: Security Func- tional Components; CCMB-2022-11-002, Version CC:2022, Revision 1, November 2022 [CC_Part2] • Common Criteria for Information Technology Security Evaluation, Part 3: Secu- rity Assurance Components; CCMB-2022-11-003, Version CC:2022, November 2022 [CC_Part3] • Common Criteria for Information Technology Security Evaluation, Part 4: Framework for the Specification of Evaluation Methods and Activities; CCMB-2022-11-004, Version CC:2022, Revision 1, November 2022 [CC_Part4] • Common Criteria for Information Technology Security Evaluation, Part 5: Pre-defined Packages of Security Requirements; CCMB-2022-11-005, Version CC:2022, Revision 1, November 2022 [CC_Part5] as follows • Part 2 conformant • Part 3 conformant The • Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1), Version 1.1, 2024-07-22 [CC_Errata] and • Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; CCMB-2022-11-006, Version CC:2022, Revision 1, November 2022 [CC_PartEM] has to be taken into account. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 11 Security Target 2.2 PP Claim This ST complies substantially to ’Protection Profile for ePassport IC with SAC (BAC+PACE) and Active Authentication’, version 1.00, [CC_PP-C0500] (English translation), which requires strict compliance. For formal reasons no strict conformance to the original Japanese Protection Profile is claimed, because the English translation of [CC_PP-C0500] is not officially certified. The Japanese PP is certified with CC 3.1 while this TOE is certified with CC:2022 as stated in section 2.1. 2.3 Package Claim • In [CC_PP-C0500], the assurance requirement package applicable to the TOE is EAL4 augmented. • Assurance components augmented are ALC_DVS.2 and ALC_FLR.3. 2.4 Conformance Rationales The ST claims no conformance to other PP and thereby provides no description of confor- mance rationales. 2.5 PP Additions and Adaptions The following items have been adapted, expanded or added, respectively, to those addressed in [CC_PP-C0500]: Threat • T.Physical_Attack (expanded to emphasize the threat of exploitment of informa- tion leakage and to include secret cryptographic keys other than the Active Au- thentication Private key) Organizational Security Policies • P.Personalization (added to address the security policy for personalization) Security Objective • O.Logical_Attack (expanded to include the protection of all secret cryptographic keys) • O.Physical_Attack (expanded to include the protection against exploitment of information leakage and to include secret cryptographic keys other than the Active Authentication Private key) • OE.Personalization (added to address the objective for personalization) Security Functional Requirement • This ST uses the SFRs as defined in CC:2022. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 12 Security Target • Some SFRs changed in wording and/or dependencies due to the transition from CC 3.1 to CC:2022. • FCS_CKM.6 (refactored according to CC:2022 from FCS_CKM.4; dependencies of other SFR are updated accordingly) • FPT_EMS.1 (added to address TOE emanation) Life Cycle • ALC_FLR.3 (added to address flaw remediation procedures) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 13 Security Target 3 Security Problem Definition (ASE_SPD.1) This chapter defines security problems related to the TOE. The security problems are defined from the three aspects: threats (to be countered by the TOE and/or environment), organiza- tional security policies (to be handled by the TOE and/or environment), and assumptions (to be met by the environment). The TOE and environment shall address these security problems in a proper way. The threats, organizational security policies, and assumptions are named using an identi- fier with the prefix “T.”, “P.”, or “A.”, respectively. 3.1 Users and Assets The following Users are defined: User Description Related to Subject1 IC Sheet Manufacturer Embedding of the IC to the plastic sheet and ap- plying the antenna (not within the scope of this certification); performing pre-issuance personal- ization User Process Booklet Manufacturer Including the IC sheet into the passport booklet; performing post-issuance personalization User Process Authorized Terminal Interface for reading the passport in phase 4 Process on behalf of terminal Passport Holder Person for whom the passport has been person- alized Process on behalf of terminal Table 3.1: User definition. The following assets are defined: 1 as defined in section 6.1 Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 14 Security Target Asset Description Properties to be main- tained User data Personal data of the passport holder Related Objects: Files EF.DG[1, 2, 13], EF.COM Confidentiality, Integrity, Authenticity Secret cryptographic keys Permanently or temporarily stored secret cryptographic material used by the TOE in or- der to enforce its security functionality Related Objects: transport key, readout key, Active Authentication Information Access key, Basic Access keys, password key, Active Au- thentication private key Confidentiality, Integrity Non-secret key mate- rial Permanentlyortemporarilystorednon-secret cryptographic (public) keys and other non- secret material used by the TOE in order to enforce its security functionality. Related Objects: EF.DG[14, 15], EF.SOD Integrity, Authenticity Table 3.2: Asset definition and relationship to Objects. 3.2 Threats This section describes threats that a TOE shall counter. These threats shall be countered by the TOE, its operational environment or combination of these two. T.Copy An attacker trying to forge an ePassport may do so by reading personal information along with digital signature from the TOE and writing the copied data in an IC chip having the same functionality as that of the TOE. This attack damages the credibility of the entire passport booklet system including TOEs. Note 2: If information retrieved from the legitimate TOE is copied into an illicit IC chip, as information stored in the TOE will be copied together with the associated digital signature, forgery protection by means of digital signature verification becomes inef- fective. Since the original information can be protected against tampering by means of digital signature, passport forgery may be detected by means of comparative verifica- tion of the facial image. However, it is difficult to surely detect forged passport just by comparing the facial image. T.Logical_Attack In the operational environment after issuing a TOE embedded passport booklet, an attacker who can read the MRZ data of the passport booklet may try to read confi- dential information (Active Authentication Private Key) stored in the TOE through the contactless communication interface of the TOE. Note 3: If an attacker has physical access to a passport booklet, the attacker can visually read personal information printed on the passport booklet and optically read the printed MRZ data. Since the security functions of the TOE cannot prevent such Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 15 Security Target sort of readings, the information and data stated above is not included in the threat- related assets to be protected by the TOE. In other words, the intended meaning of the threat here is an attack aimed to read confidential information (Active Authentication Private Key) stored in the TOE by having access to the said TOE through the contactless communication interface using data that the attacker has read from the MRZ. T.Communication_Attack In the operational environment after issuing a TOE embedded passport booklet, an attacker who does not know about MRZ data may interfere with the communication between the TOE and a terminal to disclose and/or alter communication data that should be concealed. Note 4: As for an attack which interferes with communication between a terminal and a passport booklet, it is considered impossible that the attacker physically accesses the target passport booklet without being noticed by the passport holder and/or an immigration official. An attacker can obtain MRZ data only when the passport booklet is physically accessible. Therefore, the attacker mentioned here is assumed to be unaware of the MRZ data. T.Physical_Attack In the operational environment after issuing a TOE embedded passport booklet, an attacker may attempt to disclose confidential information (secret cryptographic keys) stored in the TOE, unlock the state of the locked key, or reactivate a deactivated access control function by physical means. This physical means include both of nondestructive attacks made without impairing the TOE functions and destructive attacks made by destroying part of the TOE to have mechanical access to the inside of the TOE. Furthermore, an attacker may exploit information leaking from the TOE during its usage in order to disclose confidential user data or/and confidential information (secret cryptographic keys) stored on the TOE or/and exchanged between the TOE and the terminal connected. The information leakage may be inherent in the normal operation or caused by the attacker. Note 5: An attacker may attempt to read confidential information (secret cryptographic keys) or rewrite information stored in the TOE through physical access to the TOE. Making such a physical attack may impair the security function operated by the TOE program to provide the original functionality thereof, resulting in potential violation of SFR. The example of nondestructive attacks includes measurements on leaked electro- magnetic wave associated with the TOE operation and induction of malfunctions in security functions by applying environmental stress (e.g. changes in temperature or clock, or application of high-energy electromagnetic fields) to the TOE in operation. The example of destructive attacks shows those collecting, analyzing, and then disclosing confidential information by probing and manipulating the internal circuit. Test pins and power supply pins left in the TOE may be used to make the said attacks. The TOE that has been subject to a destructive attack may not be reused as an ePassport IC. Even in such case, however, the disclosed private key may be abused to forge TOEs. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 16 Security Target Note 6: T.Physical_Attack from [CC_PP-C0500] has been expanded to emphasize the threat emerging from information leaking from the TOE during regular operational usage. Beside the Active Authentication Private key an attacker may disclose other secret cryptographic keys (PACE-key) and confidential user data. 3.3 Organizational Security Policies This section describes organizational security policies that apply to TOEs and operational environment. In [CC_PP-C0500], the organizational security policies include conformance to the standards provided by ICAO and conditions required by the passport issuing authorities in Japan. P.BAC In the operational environment after issuing a TOE embedded passport booklet, the TOE shall allow a terminal to read certain information from the TOE in accordance with the BAC procedure defined by Part 11 of [ICAO_9303]. This procedure includes mutual authentication and Secure Messaging between the TOE and terminal devices. TOE files to be read are EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, and EF.SOD under the rules stated above. As for any files under the same rules except the files stated above, the handling of such files which are not listed in this ST is not defined. Note that this organizational security policy will not be applied after disabling BAC with P.Disable_BAC. P.PACE In the operational environment after issuing a TOE embedded passport booklet, the TOE shall allow a terminal to read a certain information from the TOE in accordance with the PACE procedure defined by Part 11 of [ICAO_9303]. This procedure includes mutual authentication and Secure Messaging between the TOE and terminal devices. TOE files to be read are EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, and EF.SOD under the rules stated above. As for any files under the same rules except the files stated above, the handling of such files which are not listed in this ST is not defined. P.Authority TheTOEunderthecontrolofthepassportissuingauthoritiesshallallowonlyauthorized users (persons who succeeded in verification of readout key, transport key, or Active Authentication Information Access Key) to have access to the internal data of the TOE, as shown in Table 3.3. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 17 Security Target Authentication status*1 File subject to access control Operation permitted Reference: Data to be operated Successful verification with readout key EF.DG13*2 Read IC chip serial number (entered by manufacturer) Successful verification with transport key Transport key file Write Transport key data (update of old data) Basic access key file Basic access key (Encryption key) Basic access key (Message Au- thentication Code key) Password key file Password key EF.DG1 Read or Write MRZ data EF.DG2 Facial image EF.DG13*2 Management data (Passport number and Booklet management number) EF.DG14 PACE v2 Security information Active Authentication hash func- tion information EF.COM*3 Common data EF.SOD Security data related to Passive Authentication defined by Part 10 of [ICAO_9303]. EF.CardAccess Write PACE v2 Security information EF.DG15 Read ActiveAuthenticationPublicKey Successful verification with Active Authentication Information Access Key EF.DG15 Write ActiveAuthenticationPublicKey Private key file Active Authentication Private Key Table 3.3: Internal data of the TOE access control by passport issuing authorities. *1 The readout key, transport key, and Active Authentication Information Access Key are configured by the manufacturer (IC Sheet Manufacturer). The transport key can be changed (updated) by an authorized user. With regard to the files subject to access control included in this table and files storing the read key and Active Authentication Information Access Key which may vary the authentication status, user access that is not stated in this table or Notes is prohibited. (The access controls to information in the TOE from terminals after issuing a TOE embedded passport booklet to the passport holder, i.e., BAC and PACE are separately specified.) *2 In EF.DG13, an IC chip serial number has been recorded by the manufacturer (IC Sheet Manufacturer), and the management data is appended to the file by the passport issuing authorities (Booklet Manufacturer). Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 18 Security Target *3 EF.COM file may not be created according to the passport issuing authorities’ instruc- tions. Note 7: All files stated in the table above store user data or TSF data. The transport key file stores TSF data, and all other files store user data (cryptographic keys are managed as user data). The TSF data file is not included in files subject to access control stated in Section 6.1 “Security Functional Requirements,” but treated in FMT_MTD.1. Note 8: Note that the transport key, the readout key and the Active Authentication Information Access key are realized as passwords. P.Data_Lock When the TOE detects a failure in authentication with the transport key, readout key or Active Authentication Information Access Key, it will permanently disable authen- tication related to each key, thereby prohibiting reading or writing the file based on successful authentication thereof. Table 3.3 shows the relationship between the key used for authentication and its corresponding file in the TOE. P.Prohibit Any and all writings to the files in the TOE and readings from the files in the TOE based on successful authentication with readout key are prohibited after issuing an ePassport to the passport holder. Disabling authentication through authentication failure with the transport key, readout key, and Active Authentication Information Access Key (see P.Data_Lock) shall be used as the means for that purpose. P.Personalization The passport issuing authority guarantees the correctness of the biographical data, the printed portrait and the digitized portrait and other data of the ePassport with respect to the Passport Holder. The personalization of the ePassport for the Passport Holder is performed by an agent authorized by the passport issuing authority only. Note 9: This policy has been taken from [CC_PP-0056-V2] and adapted to match the wording conventions of this ST. P.Disable_BAC In accordance with the passport issuing authorities’ policies against compromise of BAC, TOEs issued after a certain time shall not accept the BAC procedure. As a means to achieve it, a TOE provides the procedure of disabling the BAC functions, and a user au- thorized by the passport issuing authorities disables the BAC function by implementing the procedure. Note 10: This organizational security policy shall be applied only if the passport issuing authorities demand to terminate issuing IC chip equipped with the BAC function. 3.4 Assumptions This section describes assumptions to be addressed in the operational environment of TOEs. These assumptions need to be true for TOEs’ security functionality becomes effective. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 19 Security Target A.Administrative_Env The TOE that was delivered from the TOE manufacturer to the passport issuing author- ities and is under the control of the authorities shall be securely controlled and go through an issuing process until it is finally issued to the passport holder. A.PKI In order for the passport inspection authorities of the receiving state or organization to verify the authenticity of information that has been digitally signed by the pass- port issuer and stored in the TOE (including the Active Authentication Public Key), the interoperability of the PKI environment both of the issuing and receiving states or organizations of the passport shall be maintained by passport issuing authorities. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 20 Security Target 4 Security Objectives (ASE_OBJ.2) This chapter describes security objectives for TOEs and its environment for the security problemsdescribedinChapter3. Section4.1describesthesecurityobjectivestobeaddressed bythe TOEs, whileSection4.2describes thosetobeaddressedby its environment. Inaddition, Section 4.3 describes rationales for the appropriateness of the security objectives for solving the security problems. The security objectives for the TOEs and the security objectives for the operational environment are represented by an identifier with the prefix “O.” or “OE.” respectively. 4.1 Security Objectives for the TOE This section describes security objectives that TOEs should address to solve problems with regard to the threats and organizational security policies that are defined as the security problems. O.AA TOEs shall provide a means to verify the authenticity of the IC chip itself that com- poses the TOE in order to prevent the copy of personal information including the digital signature on an illicit IC chip and the forgery of the passport. This means shall be stan- dardized so as to ensure the global interoperability of ePassport and, for this purpose, shall support the Active Authentication defined by Part 11 of [ICAO_9303]. O.Logical_Attack TOEs shall, under any circumstances, prevent confidential information in them (secret cryptographic keys, e.g. Active Authentication Private Key) from being externally read through the contactless communication interface of the TOE. Note 11: O.Logical_Attack has been expanded to address the protection of all secret cryptographic keys. O.Physical_Attack TOEs shall prevent the confidential information (secret cryptographic keys, e.g. Active Authentication Private Key) within the TOEs from being disclosed or the information relating to the security from being tampered with by the attackers using physical means. TOEs shall counter attacks applicable to TOEs themselves out of known attacks against IC chips, considering physical means including both nondestructive attacks and de- structive attacks. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 21 Security Target Furthermore, he TOE must provide protection against disclosure of confidential user data or/and confidential information (secret cryptographic keys) stored and/or pro- cessed by the travel document by exploitment of information leakage during regular operational usage. Note 12: O.Physical_Attack from [CC_PP-C0500] has been expanded to address pro- tection against any disclosure by information leaking from the TOE during regular operational usage. O.BAC This security objective applies to the operational environment after issuing the passport booklet. The BAC procedure defined by Part 11 of [ICAO_9303], if the terminals require, shall be used to ensure the global interoperability of the ePassport. This procedure shall be used in the mutual authentication and Secure Messaging between the TOE and terminals. Information the terminal reads from the TOE is stored in the EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, and EF.SOD files among the files contained in the rules stated above. The TOE shall permit only the terminal that has succeeded in mutual authentication to read the files stated above. As for any files under the same rules except the files stated above, the handling of such files which are not listed in this ST is not defined. O.PACE This security objective applies to the operational environment after issuing the passport booklet. PACE procedure defined by Part 11 of [ICAO_9303], if the terminals require, shall be used to ensure the global interoperability of the ePassport. This procedure shall be used in the mutual authentication and Secure Messaging between the TOE and terminals. Information the terminal reads from the TOE is stored in the EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, and EF.SOD files among the files contained in the rules stated above. The TOE shall permit only the terminal that has succeeded in mutual authentication to read the files stated above. As for any files under the same rules except the files stated above, the handling of such files which are not listed in this ST is not defined. O.Authority The TOE shall limit users who can access the internal TOE data and their operations, in the environment under the control of the passport issuing authorities according to Table 3.3 described in the organizational security policy P. Authority. O.Data_Lock The operation of the internal TOE data shall be available only to the authorized user (i.e., authorized personnel under the control of the passport issuing authorities or the terminal after issuing the passport) to prevent illicit reading and writing by any users other than those stated above. As a means for this purpose, if the TOE detects an authentication failure with the readout key, transport key, or Active Authentication Information Access Key, it shall be permanently prohibited to read and to write the internal TOE data permitted according to authentication related to each of the said keys. This security objective shall also apply in the event that the passport issuing Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 22 Security Target authorities disable readout key, transport key, or Active Authentication Information Access Key by causing an authentication failure intentionally before the TOE is issued to the passport holder. The relationship between the readout key, transport key, and Active Authentication Information Access Key and their corresponding internal TOE data is as listed in Table 3.3 of the organizational security policy P.Authority. After the security objective O.Data_Lock is achieved, only the access to TOE stated in the security objective O.BAC or O.PACE is permitted. O.Disable_BAC TOEs with the BAC function shall provide procedure to disable the functions. 4.2 Security Objectives for the Operational Environment This section describes security objectives that TOEs should address in the operational envi- ronment to solve problems with regard to the threats and organizational security policies and assumptions defined as the security problems. OE.Administrative_Env The TOEs under the control of the passport issuing authorities are subjected to secure management and treatment until each of these TOEs is delivered to the passport holder through the issuing procedures. OE.Disable_BAC A user authorized by the passport issuing authorities shall perform a procedure for disabling the BAC function of TOE in accordance with the passport issuing authorities. OE.PKI In order for the ePassport inspection authorities of the receiving state or organization to verify the authenticity of information that has been digitally signed by the passport issuing state or organization and stored in the TOE (i.e., information on the passport holder and the Active Authentication Public Key), passport issuing authorities shall maintain the interoperability of the PKI environment in both the passport issuing state and receiving state. OE.Personalization The passport issuing authority must ensure that the Booklet Manufacturer acting on his behalf (i) establish the correct identity of the Passport Holder and create the biographi- cal data for the ePassport, (ii) enroll the biometric reference data of the Passport Holder, (iii) write a subset of these data on the physical Passport (optical personalization) and store them in the ePassport (electronic personalization) for the Passport Holder as defined in [ICAO_9303], (iv) write the document details data, (v) write the initial TSF data, (vi) sign the document security object defined in [ICAO_9303]. The IC Sheet Manufacturer and Booklet Manufacturer must ensure the confidentiality andintegrityofalldatabyactingwithinasecureoperationalenvironment. Furthermore, all secret cryptographic keys or passwords to be personalized, respectively, must be of appropriate quality to prevent disclosure by trial and error. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 23 Security Target Note 13: This policy has been taken from [CC_PP-0056-V2] and adapted to match the wording conventions of this ST and to emphasize the secure operational environment and the usage of secure values for secret cryptographic keys. 4.3 Security Objectives Rationales This chapter describes rationales for the effectiveness of the security objectives stated above for individual parameters of the security problem definition. Section 4.3.1 describes that each of the security objective can be traced back to any of the security problems, while Section 4.3.2 describes that any of the security problems is effectively addressed by the corresponding security objective. 4.3.1 Correspondence between Security Problem Definition and Secu- rity Objectives Table 4.1 shows the correspondence between the security problem definition and the security objectives. As shown in the table, all security objectives can be traced back to one (or more) item(s) in the security problem definition. Security problem definition Security objective O.AA O.Logical_Attack O.Physical_Attack O.BAC O.PACE O.Authority O.Data_Lock O.Disable_BAC OE.Administrative_Env OE.Disable_BAC OE.PKI OE.Personalization T.Copy x x T.Logical_Attack x T.Communication_Attack x x T.Physical_Attack x P.BAC x P.PACE x P.Authority x P.Data_Lock x P.Prohibit x P.Personalization x x P.Disable_BAC x x A.Administrative_Env x A.PKI x Table 4.1: Correspondence between security problem definition and security objectives Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 24 Security Target 4.3.2 Security Objectives Rationale This section describes rationales for the security objectives for the TOE and the operational environment to thoroughly counter all identified threats, implement organizational security policies, and also properly meet the assumptions. T.Copy If an attacker copies the personal information (with digital signature) read from the TOE to the IC chip having the same functionality as that of the TOE, the forged passport cannot be detected through the verification of digital signature. To prevent this attack, the security objective for the TOE: O.AA and the security objective for the environment: OE.Personalization address embedding of data that enable verifying the authenticity of the IC chip itself in the TOE. This enables the TOE to detect illicit IC chips and prevent the forgery of passports, thus removing the threat of T.Copy. Note14: TheTOEprovidesthepreconditionfortheterminaltoeffectivelyverifyintegrity and authenticity of the data received from the TOE. T.Logical_Attack The security objective for the TOE: O.Logical_Attack makes it possible to prohibit read- ing confidential information (Active Authentication Private Key) in the TOE through the contactless communication interface of the TOE, under any circumstances. Thus the threat of T.Logical_Attack is removed. T.Communication_Attack The security objectives for the TOE: O.BAC and O.PACE make it possible to use a se- cure communication path for the communication between the terminals and the TOE. Thus the threat of disclosure and alteration of the communication data of T.Communication_Attack can be diminished to an adequate level for the practical use. T.Physical_Attack The security objective for the TOE: O.Physical_Attack makes it possible to counter an attack to disclose confidential information (secret cryptographic keys) in the TOE or tamper security-related information not via the contactless communication interface of theTOEbutphysicalmeans. Regardingthephysicalmeans, bothnondestructiveattacks and destructive attacks are considered, and countermeasures shall be implemented so that the TOE can counter known attacks against the IC chip. Thus the threat can be diminished to an adequate level for the practical use. Note 15: In addition to T.Physical_Attack and O.Physical_Attack from [CC_PP-C0500] the threat of exploitment of information leakage during regular operational usage and the protection against this threat has been addressed. P.BAC The security objective for the TOE: O.BAC allows only the authorized personnel (termi- nal) to read the internal TOE data through a secure communication path by applying the BAC procedure defined by [ICAO_9303] Part 11. O.BAC includes all contents of P.BAC, thus the organizational security policy P.BAC is properly implemented. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 25 Security Target P.PACE The security objective for the TOE: O.PACE allows only the authorized personnel (termi- nal) to read the internal TOE data through a secure communication path by applying PACE procedure defined by Part 11 of [ICAO_9303]. O.PACE includes all contents of P.PACE, thus the organizational security policy P.PACE is properly implemented. P.Authority The security objective for the TOE: O.Authority provides the contents to directly imple- ment the organizational security policy P.Authority. P.Data_Lock The security objective for the TOE: O.Data_Lock includes the contents required by the organizational security policy P.Data_Lock and properly implements P.Data_Lock. P.Prohibit The organizational security policy P.Prohibit requires the implementation of an inten- tional authentication failure by the authorized TOE user as the implementation means. Actions required for the TOE to address P.Prohibit are the same as those for the orga- nizational security policy P.Data_Lock that has assumed an illicit attack on the TOE. Therefore, the security objective for the TOE: O.Data_Lock will also implement the contents of P.Prohibit. P.Personalization The organizational security policy P.Personalization addresses the (i) the enrollment of the logical travel document by the Booklet Manufacturer as described in the security objective for the TOE environment OE.Personalization, and (ii) the access control for the user data and TSF data as described by the security objective O.Authority. P.Disable_BAC The security objective for the TOE: O.Disable_BAC and the security objective for the Operational Environment: OE.Disable_BAC includes the contents required by the orga- nizational security policy P.Disable_BAC and properly implements P. Disable_BAC. A.Administrative_Env The security objective for the operational environment: OE.Administrative_Env directly corresponds to the assumption A.Administrative_Env, thus this assumption is met. A.PKI The security objective for the operational environment: OE.PKI directly corresponds to the assumption A.PKI, thus this assumption is met. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 26 Security Target 5 Extended Components Definition (ASE_ECD.1) The Security Target uses only the components defined in CC:2022. No other components are used1 . 1 The extended components FCS_RND and FPT_EMS defined in the base certification BSI-DSZ-CC-1073-V2- 2021 are included in CC:2022 as FCS_RNG and FPT_EMS. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 27 Security Target 6 Security Requirements (ASE_REQ.2) 6.1 Security Functional Requirements Table 6.1 shows the list of the security functional requirements (SFRs) defined by the PP. Chapter No. Identifier name 6.1.1 FCS_CKM.1b Cryptographic key generation (BAC) 6.1.2 FCS_CKM.1p Cryptographic key generation (PACE, session keys) 6.1.3 FCS_CKM.1e Cryptographic key generation (PACE, ephemeral key pairs) 6.1.4 FCS_CKM.6 Cryptographic key destruction (refactored from FCS_CKM.4, see note 16) 6.1.5 FCS_COP.1a Cryptographic operation (Active Authentication, signa- ture generation) 6.1.6 FCS_COP.1h Cryptographic operation (Active Authentication, hash functions) 6.1.7 FCS_COP.1hb Cryptographic operation (BAC, hash functions) 6.1.8 FCS_COP.1mb Cryptographic operation (BAC, mutual authentication) 6.1.9 FCS_COP.1sb Cryptographic operation (BAC, Secure Messaging) 6.1.10 FCS_COP.1n Cryptographic operation (Nonce encryption) 6.1.11 FCS_COP.1e Cryptographic operation (Key agreement) 6.1.12 FCS_COP.1hp Cryptographic operation (PACE, hash functions) 6.1.13 FCS_COP.1mp Cryptographic operation (PACE, mutual authentication) 6.1.14 FCS_COP.1sp Cryptographic operation (PACE, Secure Messaging) 6.1.15 FCS_RNG.1 Random number generation (FCS_RND in PP) 6.1.16 FDP_ACC.1a Subset access control (Issuance procedure) 6.1.17 FDP_ACC.1b Subset access control (BAC) 6.1.18 FDP_ACC.1p Subset access control (PACE) 6.1.19 FDP_ACF.1a Security attribute-based access control (Issuance proce- dure) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 28 Security Target 6.1.20 FDP_ACF.1b Security attribute-based access control (BAC) 6.1.21 FDP_ACF.1p Security attribute-based access control (PACE) 6.1.22 FDP_ITC.1 Import of user data without security attributes 6.1.23 FDP_UCT.1b Basic data exchange confidentiality (BAC) 6.1.24 FDP_UCT.1p Basic data exchange confidentiality (PACE) 6.1.25 FDP_UIT.1b Data exchange integrity (BAC) 6.1.26 FDP_UIT.1p Data exchange integrity (PACE) 6.1.27 FIA_AFL.1a Authentication failure handling (Active Authentication Information Access Key) 6.1.28 FIA_AFL.1d Authentication failure handling (Transport key) 6.1.29 FIA_AFL.1r Authentication failure handling (Readout key) 6.1.30 FIA_UAU.1 Timing of authentication 6.1.31 FIA_UAU.4 Single-use authentication mechanism 6.1.32 FIA_UAU.5 Multiple authentication mechanisms 6.1.33 FIA_UID.1 Timing of identification 6.1.34 FMT_MOF.1 Management of the behaviors of security functions 6.1.35 FMT_MTD.1 Management of TSF data 6.1.36 FMT_SMF.1 Specification of management functions 6.1.37 FMT_SMR.1 Security roles 6.1.38 FPT_EMS.1 TOE Emanation 6.1.39 FPT_PHP.3 Resistance to physical attack 6.1.40 FTP_ITC.1 Inter-TSF trusted channel Table 6.1: List of SFRs. Note 16: SFR FCS_CKM.4 has been refactored to FCS_CKM.6 according to CC:2022. SFR is defined by performing as-needed operation on the security functional component defined by CC Part 2. The operation is denoted for each SFR by the following method: • SFRsubjecttoiterationoperationisidentifiedbyaddingalow-casealphabeticcharacter such as “a” and a parenthesized brief description showing the purpose of SFR (e.g. “Active Authentication”) after the corresponding component identifier. • Thepointofassignmentorselectionoperationisshownas[assignment: XXX (italicized)] or [selection: XXX (italicized)]. Refinement is also italicized. • For the selection operation, items not subject to selection are shown by strike-through (Strikethrough). • The PP has some uncompleted operations, which are shown as [assignment: XXX (Itali- cized and underlined)]. The ST author shall complete these uncompleted operations. The following section describes SFRs defined by [CC_PP-C0500]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 29 Security Target 6.1.1 FCS_CKM.1b Cryptographic key generation (BAC) Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryptographic key derivation, or FCS_COP.1 Cryptographic operation] [FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of random numbers] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_CKM.1.1b The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: session key generation algorithm in the Basic Access Control spec- ified by Part 11 of [ICAO_9303]] and specified cryptographic key sizes [assignment: 112 bits] that meet [assignment: Standards for session key generation in the Basic Access Control specified by Part 11 of [ICAO_9303]]. Note 17: The dependencies have been enhanced according to CC:2022. Note 18: Session key generation (BAC) is specified in Part 11 of [ICAO_9303], sec. 9.7.2. 6.1.2 FCS_ CKM.1p Cryptographic key generation (PACE, session keys) Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryptographic key derivation, or FCS_COP.1 Cryptographic operation] [FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of random numbers] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_CKM.1.1p The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: session key generation algorithm in PACE specified by Part 11 of [ICAO_9303] and [BSI_TR-03111]] and specified cryptographic key sizes [assignment: 128 bits and 256 bits] that meet the following: [assignment: Standards for session key generation in PACE speci- fied by Part 11 of [ICAO_9303] and [BSI_TR-03111]]. Note 19: The dependencies have been enhanced according to CC:2022. Note 20: Session key generation (PACE) is specified in Part 11 of [ICAO_9303], sec. 9.7.3 and [BSI_TR-03111], sec. 4.3.3.2. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 30 Security Target 6.1.3 FCS_CKM.1e Cryptographic key generation (PACE, ephemeral key pairs) Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryptographic key derivation, or FCS_COP.1 Cryptographic operation] [FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of random numbers] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_CKM.1.1e The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: Elliptic Curve Key Pair Generation] and specified cryptographic key sizes [assignment: 256 bits and 384 bits] that meet the following: [assignment: Standards for the key pair generation specified by [BSI_TR-03111]]. Note 21: The dependencies have been enhanced according to CC:2022. Note 22: Cryptographic key generation for PACE (ephemeral key pairs) is specified in [BSI_TR-03111], sec. 4.1.3. The domain parameters NIST P-256 and NIST P-384 are used. 6.1.4 FCS_CKM.6 Timing and event of 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6.1 The TSF shall destroy [assignment: session keys (including key material)] when [selection: nolonger needed]. FCS_CKM.6.2 The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified crypto- graphic key destruction method [assignment:physical deletion of key value] that meets the following: [assignment: [FIPS_140-3]]. Note 23: The SFR FCS_CKM.4 defined by [CC_PP-C0500] was refactored to FCS_CKM.6 in CC:2022. Note 24: The TOE shall destroy cryptographic keys on volatile memory by overwriting the key data with random data. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 31 Security Target 6.1.5 FCS_COP.1a Cryptographic operation (Active Authentication, signature generation) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1a The TSF shall perform [assignment: generation of digital signa- ture for Active Authentication data] in accordance with a specified cryptographic algorithm [assignment: ECDSA] and cryptographic key sizes [assignment: 256 bits and 384 bits] that meet the follow- ing: [assignment: the Digital Signature Standards specified by [BSI_TR-03111], [ICAO_9303], [ICAO_SAC]and[BSI_TR-03110-1]]. Note 25: The dependencies have been enhanced according to CC:2022. Note 26: Only the combination of 256 bits and SHA-256 or that of 384 bits and SHA-384 is permitted as the key sizes for this requirement and the hash algorithm of FCS_COP.1h. Note27: ECDSAsignaturegenerationisspecifiedin [BSI_TR-03111], sec. 4.2.1 inconformance with [ANSI_X9-62], sec. 7. The domain parameters NIST P-256 and NIST P-384 are used. 6.1.6 FCS_COP.1h Cryptographic operation (Active Authentication, hash functions) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1h The TSF shall perform [assignment: generation of data for Active Authentication] in accordance with a specified cryptographic algo- rithm [assignment: SHA-256 and SHA-384] and cryptographic key sizes [assignment: none] that meet the following: [assignment: the Digital Signature Standards specified by [BSI_TR-03111]]. Note 28: The dependencies have been enhanced according to CC:2022. Note 29: Cryptographic hash functions are specified in [BSI_TR-03111], sec. 4.1.2 and [FIPS_180-4], sec. 6.2 (SHA-256) and sec. 6.5 (SHA-384). Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 32 Security Target 6.1.7 FCS_COP.1hb Cryptographic operation (BAC, hash functions) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1hb The TSF shall perform [assignment: generation of session keys used for BAC] in accordance with a specified cryptographic al- gorithm [assignment: SHA-1] and cryptographic key sizes [as- signment: none] that meet [assignment: Standards for session key generation in the Basic Access Control specified by Part 11 of [ICAO_9303]]. Note 30: The dependencies have been enhanced according to CC:2022. Note 31: Cryptographic hash functions are specified in Part 11 of [ICAO_9303], sec. 9.7.1.1 and [FIPS_180-4], sec. 6.1 (SHA-1). 6.1.8 FCS_COP.1mb Cryptographic operation (BAC, mutual authenti- cation) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1mb The TSF shall perform [assignment: cryptographic operation shown in Table 6.2] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm shown in Table 6.2] and cryptographic key sizes [assignment: cryptographic key sizes shown in Table 6.2] that meet the following: [assignment: Standards for mutual authentication included in the Basic Access Control specified by Part 11 of [ICAO_9303]]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 33 Security Target Cryptographic algorithm Cryptographic key size Cryptographic operation Single DES in CBC mode 56 bits Message Authentication Code and verifica- tion (excluding the final block of message) Triple DES in CBC mode 112 bits Message encryption and decryption Message Authentication Code and verifi- cation (final block of message) Table 6.2: Cryptographic mechanisms in Mutual authentication (BAC). Note 32: The dependencies have been enhanced according to CC:2022. Note 33: The Message Authentication Code generation process shown in Table 6.2 is equiva- lent to that specified by ISO/IEC 9797-1 MAC Algorithm 3 (Retail-MAC). Note 34: BAC (mutual authentication) specified in Part 11 of [ICAO_9303], sec. 4.3; 3DES is specifiedin[NIST_SP800-67], Retail-MACisspecifiedin[ISO_9797-1], sec. 7.4, CBCisspecified in [ISO_10116], sec. 7. 6.1.9 FCS_COP.1sb Cryptographic operation (BAC, Secure Messaging) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1sb The TSF shall perform [assignment: cryptographic operation shown in Table 6.3] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm shown in Table 6.3] and cryptographic key sizes [assignment: cryptographic key sizes shown in Table 6.3] that meet the following: [assignment: Standards for Secure Messaging included in the Basic Access Con- trol defined by Part 11 of [ICAO_9303]]. Cryptographic algorithm Cryptographic key size Cryptographic operation Single DES in CBC mode 56 bits Message Authentication Code and verifica- tion (excluding the final block of message) Triple DES in CBC mode 112 bits Message encryption and decryption Message Authentication Code and verifi- cation (final block of message) Table 6.3: Cryptographic mechanisms in Secure Messaging (BAC). Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 34 Security Target Note 35: The dependencies have been enhanced according to CC:2022. Note 36: The Message Authentication Code generation process shown in Table 6.3 is equiva- lent to that specified by ISO/IEC 9797-1 MAC Algorithm 3 (Retail-MAC). Note37: BAC(SecureMessaging)specifiedinPart11of[ICAO_9303],sec. 9.8; 3DESisspecified in [NIST_SP800-67], CBC mode is specified in [ISO_10116], sec. 7, Retail-MAC is specified in [ISO_9797-1], sec. 7.4. Note 38: Whether the Secure Messaging is applied or not depends on the type of commands. Therefore, not all commands and responses are assigned data encryption and Message Authentication Codes. 6.1.10 FCS_COP.1n Cryptographic operation (Nonce encryption) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1n The TSF shall perform [assignment: nonce encryption] in accor- dance with a specified cryptographic algorithm [assignment: AES- CBC] and cryptographic key sizes [assignment: 128 bits and 256 bits] that meet the following: [assignment: Standards for the PACE procedure specified by Part 11 of [ICAO_9303]]. Note 39: The dependencies have been enhanced according to CC:2022. Note 40: Nonce encryption is specified in Part 11 of [ICAO_9303], sec. 4.4.3.3 according to [ISO_10116], sec. 7 (CBC mode). 6.1.11 FCS_COP.1e Cryptographic operation (Key agreement) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 35 Security Target FCS_COP.1.1e The TSF shall perform [assignment: key agreement] in accordance with a specified cryptographic algorithm [assignment: ECDH] and cryptographic key sizes [assignment: 256 bits and 384 bits] that meet the following: [assignment: Standards for the PACE proce- dure specified by Part 11 of [ICAO_9303]]. Note 41: The dependencies have been enhanced according to CC:2022. Note42: KeyagreementisspecifiedinPart11of[ICAO_9303]and[BSI_TR-03111], sec. 4.3.2.1. The domain parameters NIST P-256 and NIST P-384 are used. 6.1.12 FCS_COP.1hp Cryptographic operation (PACE, hash functions) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1hp The TSF shall perform [assignment: generation of session keys for PACE] in accordance with a specified cryptographic algorithm [assignment: SHA-1 and SHA-256] and cryptographic key sizes [assignment: none] that meet the following: [assignment: Stan- dards for session key generation in PACE specified by Part 11 of [ICAO_9303]]. Note 43: The dependencies have been enhanced according to CC:2022. Note 44: Cryptographic hash functions are specified in Part 11 of [ICAO_9303], sec. 9.7.1.2, [BSI_TR-03111], sec. 4.1.2 and [FIPS_180-4], sec. 6.1 (SHA-1) and sec. 6.2 (SHA-256). 6.1.13 FCS_COP.1mp Cryptographic operation (PACE, mutual authen- tication) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 36 Security Target FCS_COP.1.1mp The TSF shall perform [assignment: authentication token genera- tion and verification] in accordance with a specified cryptographic algorithm [assignment: AES-CMAC] and cryptographic key sizes [assignment: 128 bits and 256 bits] that meet the following: [as- signment: Standards for mutual authentication included in PACE specified by Part 11 of [ICAO_9303]]. Note 45: The dependencies have been enhanced according to CC:2022. Note 46: PACE (mutual authentication) specified in Part 11 of [ICAO_9303], sec. 4.4; AES is specified in [FIPS_197], sec. 7, CMAC is specified on [NIST_SP800-38B], sec. 6. 6.1.14 FCS_COP.1sp Cryptographic operation (PACE, Secure Messag- ing) 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, or FCS_CKM.5 Cryptographic key derivation] FCS_CKM.6 Timing and event of cryptographic key destruction FCS_COP.1.1sp The TSF shall perform [assignment: cryptographic operation shown in Table 6.4] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm shown in Table 6.4] and cryptographic key sizes [assignment: cryptographic key sizes shown in Table 6.4] that meet the following: [assignment: Standards for Secure Messaging included in PACE specified by [ICAO_9303]]. Cryptographic algorithm Cryptographic key size Cryptographic operation AES in CBC mode 128 bits and 256 bits Message encryption and decryption AES-CMAC 128 bits and 256 bits Message Authentication Code generation and verification Table 6.4: Cryptographic mechanisms in Secure Messaging (PACE). Note 47: The dependencies have been enhanced according to CC:2022. Note 48: PACE (Secure Messaging) is specified in Part 11 of [ICAO_9303], sec. 9.8; AES is specified in [FIPS_197], CBC mode is specified in [ISO_10116], sec. 7, CMAC is specified on [NIST_SP800-38B], sec. 6. Note 49: Whether Secure Messaging is applied or not depends on the type of commands. Therefore, data encryption and message authentication codes are not necessarily applied to all commands and responses. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 37 Security Target 6.1.15 FCS_RNG.1 Random number generation Hierarchical to: No other components. Dependencies: No dependencies. FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] random num- ber generator that implements: [assignment (PTG.3.1) A total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output. (PTG.3.2) If a total failure of the entropy source occurs while the RNG is being operated, the RNG [selection: prevents the output of any internal random number that depends on some raw ran- dom numbers that have been generated after the total failure of the entropy source, generates the internal random numbers with a post-processing algorithm of class DRG.3 as long as its internal state entropy guarantees the claimed output entropy]. (PTG.3.3) The online test shall detect non-tolerable statistical de- fects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test and the seeding of the DRG.3 post-processing algorithm have been finished successfully or when a defect has been detected. (PTG.3.4) The online test procedure shall be effective to detect non- tolerable weaknesses of the random numbers soon. (PTG.3.5) The online test procedure checks the raw random number sequence. It is triggered [selection: externally, at regular intervals, continuously, upon specified internal events]. The online test is suitable for detecting nontolerable statistical defects of the statis- tical properties of the raw random numbers within an acceptable period of time. (PTG.3.6) The algorithmic post-processing algorithm belongs to Class DRG.3 with cryptographic state transition function and cryp- tographic output function, and the output data rate of the post- processing algorithm shall not exceed its input data rate.] Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 38 Security Target FCS_RNG.1.2 The TSF shall provide [selection: bits, octets of bits, numbers [assignment: format of the numbers] ] that meet: [assignment (PTG.3.7) Statistical test suites cannot practically distinguish the internal random numbers from output sequences of an ideal RNG. The internal random numbers must pass test procedure A1 [assign- ment: none]. (PTG.3.8) The internal random numbers shall [selection: use PTRNG of class PTG.2 as random source for the postprocessing, have [assignment: work factor], require [assignment: guess work] ]. Note 50: This SFR has been changed according to CC:2022. In [CC_PP-C0500] it is defined as FCS_RND.1. 6.1.16 FDP_ACC.1a Subset access control (Issuance procedure) Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute-based access control FDP_ACC.1.1a The TSF shall enforce the [assignment: Issuance procedure access control SFP] on [assignment: Subject [User process], Objects [Files shown in Table 3.3 of Organizational security policy P.Authority] and List of operations among subjects and objects addressed by SFP [Data Input/Output operation to/from object]]. 6.1.17 FDP_ACC.1b Subset access control (BAC) Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1b The TSF shall enforce the [assignment: BAC SFP] on [assign- ment: Subject [Process on behalf of terminal], Objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, basic access key file, password key file, transport key file, and private key file] and list of operations among subjects and objects addressed by SFP [Reading data from object]]. Note 51: BAC SFP is the access control policy applied after succeeding in mutual authentica- tion based on BAC. 1 See [KiSch-RNG] Section 2.4.4. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 39 Security Target 6.1.18 FDP_ACC.1p Subset access control (PACE) Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute-based access control FDP_ACC.1.1p The TSF shall enforce the [assignment: PACE SFP] on [assign- ment: Subject [Process on behalf of terminal], Objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, password key file, transport key file, and private key file] and list of operations among subjects and objects addressed by SFP [Reading data from object]]. Note 52: PACE SFP is the access control policy applied after succeeding in mutual authentica- tion based on PACE. 6.1.19 FDP_ACF.1a Security attribute-based access control (Issuance procedure) Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1a The TSF shall enforce the [assignment: Issuance procedure access control SFP] to objects based on the following: [assignment: Sub- ject controlled under the indicated SFP [User process], objects [Files shown in Table 3.3 of the organizational security policy P.Authority], and, the SFP-relevant security attributes [Authentication status shown in Table 3.3 of the organizational security policy P.Authority] according to each]. FDP_ACF.1.2a The TSF shall enforce the following rules to determine if an opera- tion among controlled subjects and controlled objects is allowed: [assignment: When the authentication status shown in Table 3.3 of the organizational security policy P.Authority is met, an oper- ation to the file associated with the said authentication status is allowed]. FDP_ACF.1.3a The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4a The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: Access to files that are not listed in Table 3.3 of the organizational security policy P.Authority is prohibited.]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 40 Security Target 6.1.20 FDP_ACF.1b Security attribute based access control (BAC) Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1b The TSF shall enforce the [assignment: BAC SFP] to objects based on the following: [assignment: Subject controlled under the in- dicated SFP [Process on behalf of terminal], objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, basic access key file, password key file, transport key file, and private key file], and the SFP-related security attributes [Authentication status of terminal based on mutual authentication]]. FDP_ACF.1.2b The TSF shall enforce the following rules to determine if an opera- tion among controlled subjects and controlled objects is allowed: [assignment: Where the authentication status of terminal has been successful, subjects are allowed to read data from objects]. FDP_ACF.1.3b The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4b The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: Subjects are pro- hibited to write data to or read data from the transport key file, basic access key file, password key file, and private key file.]. 6.1.21 FDP_ACF.1p Security attribute-based access control (PACE) Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1p The TSF shall enforce the [assignment: PACE SFP] to objects based on the following: [assignment: Subject controlled under the in- dicated SFP [Process on behalf of terminal], objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, password key file, transport key file, and private key file], and the SFP-related security attributes [Authentication status of terminal based on mu- tual authentication]]. FDP_ACF.1.2p The TSF shall enforce the following rules to determine if an opera- tion among controlled subjects and controlled objects is allowed: [assignment: Where the authentication status of terminal has been successful, subjects are allowed to read data from objects]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 41 Security Target FDP_ACF.1.3p The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4p The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: Subjects are pro- hibited to write data to or read data from the transport key file, password key file, and private key file]. 6.1.22 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 initialization FDP_ITC.1.1 The TSF shall enforce the [assignment: Issuance procedure access control SFP] when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3 The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [assignment: none]. 6.1.23 FDP_UCT.1b Basic data exchange confidentiality (BAC) 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.1b The TSF shall enforce of [assignment: BAC SFP] to [selection: transmit, receive] user data in a manner protected from unau- thorized disclosure. 6.1.24 FDP_UCT.1p Basic data exchange confidentiality (PACE) Hierarchical to: No other components. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 42 Security Target 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.1p The TSF shall enforce of [assignment: PACE SFP] to [selection: transmit, receive] user data in a manner protected from unautho- rized disclosure. 6.1.25 FDP_UIT.1b Data exchange integrity (BAC) 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.1b The TSF shall enforce the [assignment: BAC SFP] to [selection: transmit, receive] user data in a manner protected from [selection: modification, deletion, insertion, replay] errors. FDP_UIT.1.2b The TSF shall be able to determine, on receipt of user data, whether [selection: modification, deletion, insertion, replay] has occurred. 6.1.26 FDP_UIT.1p Data exchange integrity (PACE) 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.1p The TSF shall enforce the [assignment: PACE SFP] to [selection: transmit, receive] user data in a manner protected from [selection: modification, deletion, insertion, replay] errors. FDP_UIT.1.2p The TSF shall be able to determine, on receipt of user data, whether [selection: modification, deletion, insertion, replay] has occurred. 6.1.27 FIA_AFL.1a Authentication failure handling (Active Authenti- cation Information Access Key) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 43 Security Target Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1a The TSF shall detect when [selection: [assignment: 3], an administrator configurable positive integer within [assignment: range of acceptable values] ] unsuccessful authentication at- tempts occur related to [assignment: authentication with the Ac- tive Authentication Information Access Key]. FIA_AFL.1.2a When the defined number of unsuccessful authentication at- tempts has been [selection: met, surpassed], the TSF shall [as- signment: permanently stop authentication with the Active Au- thentication Information Access Key (fix the authentication status with the Active Authentication Information Access Key to “Not au- thenticated yet”)]. 6.1.28 FIA_AFL.1d Authentication failure handling (Transport key) Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1d The TSF shall detect when [selection: [assignment: 3], an administrator configurable positive integer within [assignment: range of acceptable values] ] unsuccessful authentication at- tempts occur related to [assignment: authentication with the transport key]. FIA_AFL.1.2d When the defined number of unsuccessful authentication at- tempts has been [selection: met, surpassed], the TSF shall [as- signment: permanently stop authentication with the transport key (fix the authentication status with the transport key to “Not authenticated yet”)]. 6.1.29 FIA_AFL.1r Authentication failure handling (Readout key) Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication FIA_AFL.1.1r The TSF shall detect when [selection: [assignment: 3], an administrator configurable positive integer within [assignment: range of acceptable values] ] unsuccessful authentication at- tempts occur related to [assignment: authentication with the readout key]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 44 Security Target FIA_AFL.1.2r When the defined number of unsuccessful authentication at- tempts has been [selection: met, surpassed], the TSF shall [as- signment: permanently stop authentication with the readout key (fix the authentication status with the readout key to “Not authen- ticated yet”)]. 6.1.30 FIA_UAU.1 Timing of authentication Hierarchical to: No other components Dependencies: FIA_UID.1 Timing of identification FIA_UAU.1.1 The TSF shall allow [assignment: readout of EF.CardAccess and EF.ATR/INFO], 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. 6.1.31 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 [assignment: mutual authentication mechanism with the BAC pro- cedure and the PACE procedure]. 6.1.32 FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1 The TSF shall provide [assignment: multiple authentication mech- anisms shown in Table 6.5] to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according to the [assignment: rules describing how the multiple authentica- tion mechanisms shown in Table 6.5 provide authentication]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 45 Security Target Authentication mechanism name Rule applicable to authentication mechanism Transport key Rule of authenticating the authorized personnel of the passport issuing authorities by verifying transport key that have been already stored in the TOE Readout key Rule of authenticating the authorized personnel of the passport issuing authorities by verification with readout key that have been already stored in the TOE Active Authentication Information Access Key Rule of authenticating the authorized personnel of the passport issu- ing authorities by verification with Active Authentication Information Access Key that have been already stored in the TOE Mutual authentication Rule of authenticating terminals according to the mutual authentica- tion procedure in BAC and PACE defined by [ICAO_9303] Table 6.5: Multiple authentication mechanisms 6.1.33 FIA_UID.1 Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1 The TSF shall allow [assignment: readout of EF.CardAccess and EF.ATR/INFO], on behalf of the user to be performed before the user is identified. FIA_UID.1.2 TheTSFshallrequireeachusertobesuccessfullyidentifiedbefore allowing any other TSF-mediated actions on behalf of that user. 6.1.34 FMT_MOF.1 Management of security functions behavior Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of management functions FMT_MOF.1.1 The TSF shall restrict the ability to [selection: determine the behaviors of, disable, enable, modify the behaviors of] the func- tions [assignment: Basic access control] to [assignment: the au- thorized personnel of the passport issuing authorities]. Note53: TodisabletheBasicAccessControlfunctionalityauthenticationagainstthetransport key is required. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 46 Security Target 6.1.35 FMT_MTD.1 Management of TSF data Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of management functions FMT_MTD.1.1 The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations] ] the [assignment: transport key] to [assignment: the authorized per- sonnel of the passport issuing authorities]. Note 54: This requirement has to do with the configuration of transport key used to transport the TOE from the passport booklet manufacturer to a regional passport office in Phase 3. In this requirement, the authorized personnel who are allowed to manage TSF data are the staff of the passport manufacturer. The staff has no chance to rewrite the transport key after the TOE has been transported to the regional passport office. On the other hand, when the TOE is located in either the passport manufacturer or a regional passport office, there is also no threat that an attacker illicitly rewrites the transport key. Therefore, there is no necessity to distinguish between the staff of the National Printing Bureau and that of the regional passport office. For this reason, this requirement makes no particular distinction between them and refers the authorized administrator as the “authorized personnel of the passport issuing authorities.” 6.1.36 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 manage- ment functions: [assignment: modification of transport key and disabling the BAC function]. 6.1.37 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 [assignment: authorized person- nel of the passport issuing authorities]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 47 Security Target 6.1.38 FPT_EMS.1 TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1 The TSF shall ensure that the TOE does not emit emissions over its attack surface in such amount that these emissions enable access to TSF data and user data as specified in Table 6.6: ID Emissions attack surface TSF data User data 1 Information about IC power consump- tion and command execution time Smart card cir- cuit contacts PACE session keys, PACE ephemeral private key, BAC session keys Transport key, Readout key, Active Authentica- tion Information Access key, Active Authentica- tion Private key Table 6.6: FPT_EMS.1.1 Table Note 55: SFR FPT_EMS.1 is taken in addition to the SFRs from [CC_PP-C0500]; the SFR applies to life cycle phase 4. 6.1.39 FPT_PHP.3 Resistance to physical attack Hierarchical to: No other components. Dependencies: No dependencies. FPT_PHP.3.1 The TSF shall resist [assignment: attacks defined by the CC Sup- porting Documents related to Smartcards] to the [assignment: hardware of the TOE and software composing the TSF] by respond- ing automatically such that the SFRs are always enforced. Note 56: The supporting documents that are the latest version at the time of the evaluation for the TOE are applied. The document at the time of [CC_PP-C0500] issuance is the [JIL_AP]. 6.1.40 FTP_ITC.1 Inter-TSF trusted channel Hierarchical to: No other components. Dependencies: No dependencies. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 48 Security Target FTP_ITC.1.1 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 channel data from modification or disclosure. FTP_ITC.1.2 The TSF shall permit [selection: the TSF, another trusted IT prod- uct] to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: reading data from the TOE]. Note 57: Communication between terminal and TSF shall be performed via the Secure Messagingchanneldefinedby[ICAO_9303]. AftertheSecureMessagingchannelisestablished, only the Secure Messaging channel is to be available for the communication path between terminal and TOE. 6.2 Security Assurance Requirements Security assurance requirements applicable to this TOE are defined by assurance components shown in Table 6.7. These components are all included in CC Part 3. Components except ALC_DVS.2 and ALC_FLR.3 are included in the EAL4 assurance package. ALC_DVS.2 is a high- level component of ALC_DVS.1. ALC_FLR.3 covers flaw remediation. [CC_PP-C0500] applies no operation to all components shown in Table 6.7. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 49 Security Target Assurance class Assurance component Security target evaluation ASE_CCL.1 ASE_ECD.1 ASE_INT.1 ASE_OBJ.2 ASE_REQ.2 ASE_SPD.1 ASE_TSS.1 Development ADV_ARC.1 ADV_FSP.4 ADV_IMP.1 ADV_TDS.3 Guidance documents AGD_OPE.1 AGD_PRE.1 Life-cycle support ALC_CMC.4 ALC_CMS.4 ALC_DEL.1 ALC_DVS.2 ALC_FLR.3 ALC_LCD.1 ALC_TAT.1 Tests ATE_COV.2 ATE_DPT.1 ATE_FUN.1 ATE_IND.2 Vulnerability assessment AVA_VAN.3 Table 6.7: Assurance components 6.3 Security Requirements Rationale 6.3.1 Security Functional Requirements Rationale This chapter describes rationales for that the defined SFRs properly achieve the security objectives for the TOE. Section 6.3.1.1 describes that each of the SFRs can be traced back to any of the security objectives for the TOE, while Section 6.3.1.2 describes that each of the security objectives for the TOE is properly met by the corresponding effective SFR. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 50 Security Target 6.3.1.1 Tracing between Security Objectives and Security Functional Requirements Table 6.8 shows the SFRs corresponding to the security objectives for the TOE. This table provides the rationales for the traceability of all SFRs to at least one security objective for the TOE. SFR Security objective for the TOE O.Logical_Attack O.Physical_Attack O.AA O.BAC O.PACE O.Authority O.Data_Lock O.Disable_BAC FCS_CKM.1b x FCS_CKM.1p x FCS_CKM.1e x FCS_CKM.6 x x x FCS_COP.1a x FCS_COP.1h x FCS_COP.1hb x FCS_COP.1mb x FCS_COP.1sb x FCS_COP.1n x FCS_COP.1e x FCS_COP.1hp x FCS_COP.1mp x FCS_COP.1sp x FCS_RNG.1 x FDP_ACC.1a x x FDP_ACC.1b x x FDP_ACC.1p x x FDP_ACF.1a x x FDP_ACF.1b x x FDP_ACF.1p x x FDP_ITC.1 x x x x FDP_UCT.1b x FDP_UCT.1p x FDP_UIT.1b x Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 51 Security Target SFR Security objective for the TOE O.Logical_Attack O.Physical_Attack O.AA O.BAC O.PACE O.Authority O.Data_Lock O.Disable_BAC FDP_UIT.1p x FIA_AFL.1a x FIA_AFL.1d x FIA_AFL.1r x FIA_UAU.1 x x x x FIA_UAU.4 x x FIA_UAU.5 x x x x FIA_UID.1 x x x x FMT_MOF.1 x FMT_MTD.1 x FMT_SMF.1 x x FMT_SMR.1 x x FPT_EMS.1 x FPT_PHP.3 x FTP_ITC.1 x x Table 6.8: Tracing between security objectives for the TOE and SFRs 6.3.1.2 Justification for the tracing This section describes rationales for that the security objectives for the TOE are met by their corresponding SFRs and, at the same time, indicates that individual SFRs have effectiveness in meeting the security objectives for the TOE. O.AA To achieve the security objective O.AA, it shall address the Active Authentication procedure defined by Part 11 of [ICAO_9303]. This Active Authentication is a process for a terminal to authenticate the IC chip of the TOE, and the TOE itself is not required to provide any authentication mechanism. The TOE is authenticated by properly re- sponding the authentication procedure. To meet requirements for the authentication procedure from the terminal, the TOE incorporates the public key and private key pair, performs cryptographic operation using the private key defined by FCS_COP.1a, and hashing operation defined by FCS_COP.1h. The public key and private key pair is im- Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 52 Security Target ported to the TOE by FDP_ITC.1. Access control associated with FDP_ITC.1 is defined by FDP_ACC.1a and FDP_ACF.1a. Destruction of the private key on RAM is defined by FCS_CKM.6. The security objective O.AA is sufficiently achieved by the said SFRs. O.Logical_Attack Confidential information (Active Authentication Private Key) subject to protection is stored in the private key file of the TOE. It is denied for the user process on behalf of the terminal to read data from the private key file, by FDP_ACC.1b and FDP_ACF.1b or FDP_ACC.1p and FDP_ACF.1p, respectively, applied to the TOE after issu- ing the TOE embedded passport. The security objective O.Logical_Attack is sufficiently achieved by the said SFRs. O.Physical_Attack Attack scenarios trying to disclose secret cryptographic keys that are confidential information, and to tamper security-related information within the TOE, by physical means are stated in the list of attacks shown in the FPT_PHP.3 section. The TSF automatically resists the attacks according to FPT_PHP.3 to protect against the disclosure of the confidential information. Protection against disclosure of confidential user- or/and TSF-data stored on / processed by the TOE by information leakage is, fur- thermore, achieved by FPT_EMS.1. With that, the security objective O.Physical_Attack is sufficiently achieved. O.BAC The TOE provides its services to the user (equivalent to a terminal) who has suc- ceeded in identification and authentication by FIA_UID.1 and FIA_UAU.1. User au- thentication requires the mutual authentication procedure with the BAC defined by ICAO, which is defined by FIA_UAU.5. This mutual authentication procedure requires new authentication data based on random numbers for each authentication, which is defined by FIA_UAU.4. Likewise, Secure Messaging required by BAC is defined by the requirement for the protection of transmitted and received data by FDP_UCT.1b and FDP_UIT.1b, and the requirement of cryptographic communication channels by FTP_ITC.1. Furthermore, with regard to cryptographic processing required for the BAC procedure, FCS_COP.1mb defines cryptographic operations necessary for the mutual authentication procedure and FCS_COP.1sb defines cryptographic operations for Se- cure Messaging. With regard to the cryptographic keys used for Secure Messaging, FDP_ITC.1 defines the import of basic access keys, FCS_CKM.1b and FCS_COP.1hb de- fine the generation of session keys, and FCS_CKM.6 defines the destruction of these keys. In order for only permitted personnel to read given information from the TOE, rules governing access control with FDP_ACC.1b and FDP_ACF.1b are defined. The security objective O.BAC is sufficiently achieved by the said SFRs. O.PACE The TOE provides its services to the user who has succeeded in identification and authentication by FIA_UID.1 and FIA_UAU.1. User authentication requires the mutual authentication procedure with PACE defined by ICAO, which is defined by FIA_UAU.5. The mutual authentication procedure requires new authentication data based on a random number for each authentication, which is defined by FIA_UAU.4. Likewise, Secure Messaging required by PACE is defined by the requirements for the protection of transmitted and received data by FDP_UCT.1p and FDP_UIT.1p, and the require- ment of cryptographic communication channels by FTP_ITC.1. Furthermore, with regard to cryptographic processing required for the PACE procedure, FCS_COP.1mp defines cryptographic operations necessary for the mutual authentication procedure and FCS_COP.1sp defines cryptographic operations for Secure Messaging. With regard Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 53 Security Target to the cryptographic keys used for Secure Messaging, FDP_ITC.1 defines the import of password key, FCS_CKM.1e defines the generation of ephemeral key pairs, FCS_COP.1e defines the key agreement, FCS_CKM.1p and FCS_COP.1hp define the generation of session keys, FCS_RNG.1 defines the generation of random numbers such as random Nonce, FCS_COP.1n defines the encryption of Nonce, and FCS_CKM.6 defines the de- struction of these keys. In order for only permitted personnel to read given information from the TOE, rules governing access control with FDP_ACC.1p and FDP_ACF.1p are defined. O.PACE is sufficiently achieved by the said SFRs. O.Authority During the TOE process done by the passport issuing authorities, the iden- tification and authentication requirements FIA_UID.1 and FIA_UAU.1 are applied in order to grant the processing authority only to the duly authorized user. As for the user authentication mechanisms, FIA_UAU.5 defines the use of the transport key, readout key, or Active Authentication Information Access Key. If a user is successfully authenti- cated by the verification with the key, the user is permitted to access to the internal data of the TOE defined by O.Authority, applying the access control rule FDP_ACC.1a and FDP_ACF.1a. The user operation includes writing of the authentication key (trans- port key), cryptographic keys (Active Authentication Public Key and private key pair, basic access key and password key for Secure Messaging), and other user data in the TOE. The association between objects and security attributes when writing is defined by FDP_ITC.1. O.Authority includes updating (rewriting) of the transport keys by the authorized personnel of the passport issuing authorities and is defined by FMT_MTD.1, FMT_SMF.1, and FMT_SMR.1. The security objective O.Authority is sufficiently achieved by the said SFRs. O.Data_Lock In the event of an authentication failure with the transport key, readout key or Active Authentication Information Access Key, authentication corresponding to the relevant key is permanently prohibited, and as the result, the security objective of permanently prohibiting readout and write of the internal data of the TOE is sufficiently achieved by the three SFRs: FIA_AFL.1a, FIA_AFL.1d, and FIA_AFL.1r. O.Disable_BAC During the TOE process done by the passport issuing authorities, the identification and authentication requirements FIA_UID.1 and FIA_UAU.1 are applied in order to grant the processing authority only to the duly authorized user. It is allowed to disable the BAC function, which is defined by FMT_MOF.1, FMT_SMF.1, and FMT_SMR.1, for the user that has been succeeded in authentication by verification with the transport key by FIA_UAU.5. The security objective O.Disable_BAC is sufficiently achieved by the said SFRs. 6.3.1.3 Dependencies for Security Functional Requirements Table 6.9 shows dependencies and support for the dependencies defined for SFRs. In the table, the ’Dependencies’ column describes dependencies defined for SFRs, and the ’Support for the Dependencies’ column describes by what SFRs the defined dependencies are satisfied or rationales indicating the justification for non-satisfied dependencies. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 54 Security Target SFR Dependencies Support of the Dependencies FCS_CKM.1b [FCS_CKM.2 or FCS_CKM.5 or FCS_COP.1] [FCS_RBG.1 or FCS_RNG.1] FCS_CKM.6 FCS_COP.1sb, FCS_CKM.6 and FCS_RNG.1 support to sat- isfy the dependencies. FCS_CKM.1p [FCS_CKM.2 or FCS_CKM.5 or FCS_COP.1] [FCS_RBG.1 or FCS_RNG.1] FCS_CKM.6 FCS_COP.1sp, FCS_COP.1mp, FCS_CKM.6 and FCS_RNG.1 support to satisfy the dependencies. FCS_CKM.1e [FCS_CKM.2 or FCS_CKM.5 or FCS_COP.1] [FCS_RBG.1, or FCS_RNG.1] FCS_CKM.6 FCS_COP.1e, FCS_CKM.6 and FCS_RNG.1 support to satisfy the dependencies. FCS_CKM.6 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FDP_ITC.1, FCS_CKM.1e, and FCS_CKM.1p support to sat- isfy the dependency. FDP_ITC.1 supports keys only on volatile memory. FCS_COP.1a [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FDP_ITC.1 supports. FCS_CKM.6 supports keys on volatile memory. Since the modification and destruction of keys on nonvolatile memory are prohibited, FCS_CKM.6 does not apply to. FCS_COP.1h [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 Since keys do not exist, any requirements do not apply to. FCS_COP.1hb [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 Since keys do not exist, any requirements do not apply to. FCS_COP.1mb [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FDP_ITC.1 supports. FCS_CKM.6 supports keys on volatile memory. Since the modification and destruction of keys on nonvolatile memory are prohibited, FCS_CKM6 does not apply to. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 55 Security Target SFR Dependencies Support of the Dependencies FCS_COP.1sb [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FCS_CKM.1b and FCS_CKM.6 support to satisfy the depen- dencies. FCS_COP.1n [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FDP_ITC.1 supports. FCS.CKM.6 supports on keys on volatile memory. Since the modification and destruction of keys on nonvolatile memory are prohibited, FCS_CKM.6 does not apply to. FCS_COP.1e [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FCS_CKM.1e and FCS_CKM.6 support to satisfy the depen- dencies. FCS_COP.1hp [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 Since keys do not exist, any requirements do not apply to. FCS_COP.1mp [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FCS_CKM.1p and FCS_CKM.6 support to satisfy the depen- dencies. FCS_COP.1sp [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 or FCS_CKM.5] FCS_CKM.6 FCS_CKM.1p and FCS_CKM.6 support to satisfy the depen- dencies. FCS_RNG.1 No dependencies N/A FDP_ACC.1a FDP_ACF.1 FDP_ACF.1a supports to satisfy the dependency. FDP_ACC.1b FDP_ACF.1 FDP_ACF.1b supports to satisfy the dependency. FDP_ACC.1p FDP_ACF.1 FDP_ACF.1p supports to satisfy the dependency. FDP_ACF.1a FDP_ACC.1 FMT_MSA.3 FDP_ACC.1a supports. Objects are created at initial config- uration, but not created in the operational environment of the TOE. Therefore, FMT_MSA.3 related to file creation does not apply to. FDP_ACF.1b FDP_ACC.1 FMT_MSA.3 FDP_ACC.1b supports. Objects are created at initial config- uration, but not created in the operational environment of the TOE. Therefore, FMT_MSA.3 related to file creation does not apply to. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 56 Security Target SFR Dependencies Support of the Dependencies FDP_ACF.1p FDP_ACC.1 FMT_MSA.3 FDP_ACC.1p supports. Objects are created at initial config- uration, but not created in the operational environment of the TOE. Therefore, FMT_MSA.3 related to file creation does not apply to. FDP_ITC.1 [FDP_ACC.1 or FDP_IFC.1] FMT_MSA.3 FDP_ACC.1a supports. Objects are created at initial config- uration, but not created in the operational environment of the TOE. Therefore, FMT_MSA.3 related to file creation does not apply to. FDP_UCT.1b [FTP_ITC.1 or FTP_TRP.1] [FDP_ACC.1 or FDP_IFC.1] FTP_ITC.1 and FDP_ACC.1b support to satisfy the depen- dencies. FDP_UCT.1p [FTP_ITC.1 or FTP_TRP.1] [FDP_ACC.1 or FDP_IFC.1] FTP_ITC.1 and FDP_ACC.1p support to satisfy the depen- dencies. FDP_UIT.1b [FDP_ACC.1 or FDP_IFC.1] [FTP_ITC.1 or FTP_TRP.1] FTP_ITC.1 and FDP_ACC.1b support to satisfy the depen- dencies. FDP_UIT.1p [FDP_ACC.1 or FDP_IFC.1] [FTP_ITC.1 or FTP_TRP.1] FTP_ITC.1 and FDP_ACC.1p support to satisfy the depen- dencies. FIA_AFL.1a FIA_UAU.1 FIA_UAU.1 supports to satisfy the dependency. FIA_AFL.1d FIA_UAU.1 FIA_UAU.1 supports to satisfy the dependency. FIA_AFL.1r FIA_UAU.1 FIA_UAU.1 supports to satisfy the dependency. FIA_UAU.1 FIA_UID.1 FIA_UID.1 supports to satisfy the dependency. FIA_UAU.4 No dependencies N/A FIA_UAU.5 No dependencies N/A FIA_UID.1 No dependencies N/A FMT_MOF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 and FMT_SMF.1 support to satisfy the depen- dencies. FMT_MTD.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 and FMT_SMF.1 support to satisfy the depen- dencies. FMT_SMF.1 No dependencies N/A FMT_SMR.1 FIA_UID.1 FIA_UID.1 supports to satisfy the dependency. FPT_EMS.1 No dependencies N/A FPT_PHP.3 No dependencies N/A FTP_ITC.1 No dependencies N/A Table 6.9: Dependencies for SFRs Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 57 Security Target 6.3.2 Security Assurance Requirements Rationale In environments that the TOE is used, communication with inspection terminals that the BAC procedure is used for is assumed. The BAC procedure is assumed to thwart attackers possessing an Enhanced-Basic attack potential, and AVA_VAN.3 is adopted as the security assurance requirement for the vulnerability assessment of the TOE to assure that it can counter such level of the attack. In addition, ALC_DVS.2 is adopted as the development security assurance requirement to provide stricter protection of development information used for an attack means. ALC_FLR.3 is chosen to address a systematic flaw management along the whole life cycle of a long lasting product. When using the IC chip as the TOE, state of the art technologies are required for SFRs and design methods to realize such SFRs. However, there are no significant variations in the security functionality of product, and points to be checked for the vulnerability assessment are also well-defined. Consequently, EAL4, which is the top level for commercial product is adopted as the development and manufacturing assurance requirements except develop- ment security. Note that dependencies among the security assurance components shown in Table 6.7 are all satisfied because ALC_DVS.2 and ALC_FLR.3 do not have dependencies on other components. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 58 Security Target 7 TOE Summary Specification (ASE_TSS.1) This chapter describes the TOE security functions and the assurance measures covering the requirements of the previous chapter. 7.1 TOE Security Functions This chapter gives the overview description of the different TOE Security Functions composing the TSF. 7.1.1 TOE Security Functions from Hardware and Cryptographic Library 7.1.1.1 F.IC_CL: Security Functions of the Hardware and Cryptographic Library This Security Function covers the security functions of the hardware (IC) as well as of the cryptographic library (CL) according to the Certification Report and the Security Target of the hardware[ST_ST31N600]andthelibrary[ST_ST31N600_Neslib]. Thesecurtityfunctionalities are listed in detail in 7.4. 7.1.2 TOE Security Functions from Basic Software – Operating System 7.1.2.1 F.Access_Control This TSF regulates all access by external entities to operations of the TOE which are only executed after this TSF allowed access. 1. Access to objects is controlled based on subjects, objects (any file) and security at- tributes 2. No access control policy allows reading of any key 3. Any access not explicitly allowed is denied 4. Access Control in phase 2 (manufacturing): Configuration and initialization of the TOE, configuring of Access Control policy only by the Manufacturer or on behalf of him; doing key management by the Manufacturer or on behalf of him or by the IC Sheet Manufacturer or on behalf of him (see F.Management) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 59 Security Target 5. Access Control in phase 3 (personalization): Personalization including the writing of user and dedicated TSF data and reading of initialization data only by the Booklet Manufacturer identified with the correct authentication key (see F.Management) 6. Access Control in phase 4 (operational use): Reading of user data only by an Authorized Terminal after a successful PACE or BAC authentication and using Secure Messaging 7.1.2.2 F.Identification_Authentication This function provides identification/authentication of the user roles • IC Sheet Manufacturer • Booklet Manufacturer • Authorized terminal by the methods: 1. In phase 2 (manufacturing): • PIN verification (transport key) that is blocked after three failed authentications. The PIN is stored on the card in a SHA-256 hash representation. 2. In phase 3 (personalization): • PIN verification (transport key, readout key, Active Authentication information access key) that is blocked after three failed authentications. The PINs are stored on the card in a SHA-256 hash representation. 3. In phase 4 (operational use): • Symmetric BAC authentication method [ICAO_9303] with following properties: – The authentication is as specified by ICAO. – It uses a challenge from the MRTD. – The cryptographic method for confidentiality is Triple-DES/CBC provided by F.Crypto. – The cryptographic method for authenticity is DES/Retail MAC provided by F.Crypto. – On error (wrong MAC, wrong challenge) the user role is not identi- fied/authenticated. – On success the session keys are created and stored for Secure Messaging. • Secure Messaging (BAC) with following properties – The Secure Messaging is as specified by ICAO. – The cryptographic method for confidentiality is Triple-DES/CBC provided by F.Crypto. – The cryptographic method for authenticity is DES/Retail MAC provided by F.Crypto. – In a Secure Messaging protected command the method for confidentiality and the method for authenticity must be present. – The initialization vector is an encrypted Send Sequence Counter (SSC). – On any command that is not protected correctly with the session keys these are overwritten according to [FIPS_140-3] (or better) and a new BAC authenti- cation is required. – Keys in transient memory are overwritten after usage. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 60 Security Target • PACE authentication method [BSI_TR-03110-1] with following properties: – It uses an MRZ. – The cryptographic method for confidentiality is AES/CBC provided by F.Crypto. – The cryptographic method for authenticity is CMAC provided by F.Crypto. – On error (wrong MAC, wrong challenge) the user role is not identi- fied/authenticated. – On success the session keys are created and stored for Secure Messaging. – Keys and data in transient memory are overwritten after usage. • Secure Messaging (PACE) with following properties: – The cryptographic method for confidentiality is AES/CBC provided by F.Crypto. – The cryptographic method for authenticity is CMAC provided by F.Crypto. – In a Secure Messaging protected command the method for confidentiality and the method for authenticity must be present. – The initialization vector is an encrypted Send Sequence Counter (SSC) for AES encryption and CMAC. – A session key is used. – On any command that is not protected correctly with the session keys these are overwritten according to [FIPS_140-3] (or better) and a new PACE authen- tication is required. – Keys and data in transient memory are overwritten after usage. 4. Active Authentication with following properties: • According to [ICAO_9303] using ECDSA from F.IC_CL. 7.1.2.3 F.Management In phase 2 the Manufacturer applies the basic software and application software to the chip. The application software includes the configuration and the file layout, which determines the security attributes. The IC Sheet Manufacturer performs the following steps: • Writing of the (new) transport key, the readout key and the Active Authentication infor- mation access key. In phase 3 the Booklet Manufacturer performs the following steps: • Optionally disabling the BAC functionality. • Formatting of all data to be stored in the TOE. • Writing of all the required data to the appropriate files. • Changing the TOE into the end-usage mode for phase 4 where reading of the initializa- tion data is prevented. 7.1.2.4 F.Crypto This function provides a high level interface to Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 61 Security Target • AES (supplied by F.IC_CL) • CMAC • Triple-DES/CBC (supplied by F.IC_CL) • DES/Retail MAC (supplied by F.IC_CL) • ECC (supplied by F.IC_CL) • SHA-1 (supplied by F.IC_CL) • SHA-256 (supplied by F.IC_CL) • SHA-384 (supplied by F.IC_CL) • RNG (PTG.3 consisting of PTG.2 (supplied by F.IC_CL) and cryptographic postprocessing) 7.1.2.5 F.Verification TOE internal functions ensures correct operation. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 62 Security Target 7.2 Assurance Measures The assurance measures fulfilling the requirements of EAL4 augmented by ALC_DVS.2 and ALC_FLR.3 are given in table 7.1. Measure Measure ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification ADV_IMP.1 Implementation representation of the TSF ADV_TDS.3 Basic modular design AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.4 Production support, acceptance procedures, automation ALC_CMS.4 Problem tracking CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.2 Sufficiency of security measures ALC_FLR.3 Systematic flaw remediation ALC_LCD.1 Developer defined life-cycle model ALC_TAT.1 Well-defined development tools ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample AVA_VAN.3 Focused vulnerability analysis Table 7.1: Assurance Measures. 7.3 TOE Summary Specification Rationale Table 7.2 shows the coverage of the SFRs by TSFs. SFR TSFs FCS_CKM.1b F.IC_CL FCS_CKM.1p F.IC_CL FCS_CKM.1e F.IC_CL FCS_CKM.6 F.Identification_Authentication FCS_COP.1a F.IC_CL Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 63 Security Target SFR TSFs FCS_COP.1h F.IC_CL, F.Crypto FCS_COP.1hb F.IC_CL, F.Crypto FCS_COP.1mb F.IC_CL, F.Crypto FCS_COP.1sb F.IC_CL, F.Crypto FCS_COP.1n F.IC_CL, F.Crypto FCS_COP.1e F.IC_CL FCS_COP.1hp F.IC_CL, F.Crypto FCS_COP.1mp F.IC_CL, F.Crypto FCS_COP.1sp F.IC_CL, F.Crypto FCS_RNG.1 F.IC_CL, F.Crypto FDP_ACC.1a F.Access_Control FDP_ACC.1b F.Access_Control FDP_ACC.1p F.Access_Control FDP_ACF.1a F.Access_Control FDP_ACF.1b F.Access_Control FDP_ACF.1p F.Access_Control FDP_ITC.1 F.Access_Control, F.Identification_Authentication FDP_UCT.1b F.Access_Control FDP_UCT.1p F.Access_Control FDP_UIT.1b F.Access_Control FDP_UIT.1p F.Access_Control FIA_AFL.1a F.Identification_Authentication FIA_AFL.1d F.Identification_Authentication FIA_AFL.1r F.Identification_Authentication FIA_UAU.1 F.Access_Control FIA_UAU.4 F.Identification_Authentication FIA_UAU.5 F.Access_Control, F.Identification_Authentication FIA_UID.1 F.Access_Control FMT_MOF.1 F.Access_Control, F.Management FMT_MTD.1 F.Access_Control, F.Management FMT_SMF.1 F.Management FMT_SMR.1 F.Identification_Authentication FPT_EMS.1 F.IC_CL FPT_PHP.3 F.IC_CL FTP_ITC.1 F.Access_Control, F.Identification_Authentication Table 7.2: Coverage of SFRs for the TOE by TSFs. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 64 Security Target The SFR FCS_CKM.1b requires session key generation algorithm in Basic Access Control, which is supplied by F.IC_CL. TheSFRFCS_CKM.1prequiressessionkeygenerationalgorithminPACE,whichissupplied by F.IC_CL. The SFR FCS_CKM.1e requires the ECDH algorithm. This is provided by the cryptographic library function F.IC_CL. The SFR FCS_CKM.6 requires the destroying of cryptographic keys. This is done in F.Identification_Authentication. The SFR FCS_COP.1a requires ECDSA. F.IC_CL provides the functions. The SFR FCS_COP.1h requires SHA-256 and SHA-384. F.IC_CL and F.Crypto provide these hash algorithms. The SFR FCS_COP.1hb requires SHA-1. F.IC_CL and F.Crypto provide this hash algorithm. The SFR FCS_COP.1mb requires DES/Triple-DES. F.IC_CL and F.Crypto provide these algorithms. The SFR FCS_COP.1sb requires DES/Triple-DES in CBC mode and cryptographic key size 56 bits and 112 bits to perform Secure Messaging – encryption and decryption and DES/Triple- DES in Retail MAC mode and cryptographic key size 56 bits and 112 bits to perform Secure Messaging – Message Authentication Code. This is provided in F.IC_CL and F.Crypto. The SFR FCS_COP.1n requires AES, which is supplied by F.IC_CL and F.Crypto. The SFR FCS_COP.1e requires the ECDH algorithm for key agreement with key size 256 bits and 384 bits. This is provided by the cryptographic library function F.IC_CL. The SFR FCS_COP.1hp requires SHA-1 and SHA-256. F.IC_CL and F.Crypto provide these hash algorithms. The SFR FCS_COP.1mp requires AES in CMAC mode. This is provided in F.IC_CL and F.Crypto. The SFR FCS_COP.1sp requires AES in CBC mode and cryptographic key size 128 bits and 256 bits to perform Secure Messaging – encryption and decryption and AES in CMAC mode and cryptographic key size 128 bits and 256 bits to perform Secure Messaging – Message Authentication Code. This is provided in F.IC_CL and F.Crypto. The SFR FCS_RNG.1 requires the generation of random numbers which is provided by F.IC_CL and F.Crypto. The SFR FDP_ACC.1a requires the enforcement of the issuance procedure access control policy to the user process for data input/output operation to/from the files as listed in Table 3.3. This is done by F.Access_Control. The SFR FDP_ACC.1b requires the enforcement of the BAC policy to the process on behalf of terminal for reading data from the files Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, basic access key file, password key file, transport key file, and private key file. This is done by F.Access_Control. The SFR FDP_ACC.1p requires the enforcement of the PACE policy to the process on behalf of terminal for reading data from the files Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, basic access key file, password key file, transport key file, and private key file. This is done by F.Access_Control. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 65 Security Target The SFR FDP_ACF.1a requires the enforcement of the issuance procedure access control policy to the user process, the files as listed in Table 3.3 and the authentication status as listed in Table 3.3. This is done by F.Access_Control. The SFR FDP_ACF.1b requires the enforcement of the BAC policy on the process on behalf of terminal for reading data from the files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, basic access key file, password key file, transport key file, and private key file and the authentication status of terminal based on mutual authentication. This is done by F.Access_Control. The SFR FDP_ACF.1p requires the enforcement of the PACE policy on the process on behalf of terminal for reading data from the files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, basic access key file, password key file, transport key file, and private key file and the authentication status of terminal based on mutual authentication. This is done by F.Access_Control. The SFR FDP_ITC.1 requires the enforcement of the issuance procedure access control policy when importing user data from outside of the TOE. This is done by F.Identification _Authentication and F.Access_Control. The SFR FDP_UCT.1b requires the enforcement of BAC policy to transmit/receive user data in a manner protected from unauthorized disclosure. This is done by F.Access_Control. The SFR FDP_UCT.1p requires the enforcement of PACE policy to transmit/receive user data in a manner protected from unauthorized disclosure. This is done by F.Access_Control. The SFR FDP_UIT.1b requires the enforcement of BAC policy to transmit/receive user data in a manner protected from modification, deletion, insertion and replay errors. This is done by F.Access_Control. The SFR FDP_UIT.1p requires the enforcement of PACE policy to transmit/receive user data in a manner protected from modification, deletion, insertion and replay errors. This is done by F.Access_Control. The SFR FIA_AFL.1a requires the detection of an unsuccessful authentication at- tempt authentication with the Active Authentication Information Access key and per- manently stop authentication with the Active Authentication Information Access key. F.Identification_Authentication detects unsuccessful authentication attempts. The SFR FIA_AFL.1d requires the detection of an unsuccessful authentication attempt authenticationwiththetransportkeyandpermanentlystopauthenticationwiththetransport key. F.Identification_Authentication detects unsuccessful authentication attempts. The SFR FIA_AFL.1r requires the detection of an unsuccessful authentication attempt authentication with the readout key and permanently stop authentication with the readout key. F.Identification_Authentication detects unsuccessful authentication attempts. The SFR FIA_UAU.1 requires the timing of authentication. The readout of EF.CardAccess and EF.ATR/INFO shall be allowed on behalf of the user to be performed before the user is authenticated. This is done by F.Access_Control. The SFR FIA_UAU.4 requires prevention of authentication data reuse related to mutual authentication mechanism with the BAC procedure and the PACE procedure. This is done by F.Identification_Authentication. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 66 Security Target The SFR FIA_UAU.5 requires multiple authentication mechanisms as shown in Table 6.5 and the authentication of any user’s claimed identity. This is done by F.Access_Control and F.Identification_Authentication. The SFR FIA_UID.1 requires the timing of identification. The readout of EF.CardAccess and EF.ATR/INFO on behalf of the user to be performed before the user is identified. This is done by F.Access_Control. The SFR FMT_MOF.1 requires the management of the behaviors of security functions. The the ability to disable and enable the function Basic access control shall be restricted to the authorized personnel of the passport issuing authorities. This is done by F.Access_Control and F.Management. TheSFRFMT_MTD.1requiresthemanagementofTSFdata. Theabilitytomodifythetrans- port key shall be restricted to the authorized personnel of the passport issuing authorities. This is done by F.Access_Control and F.Management. The SFR FMT_SMF.1 requires the specification of management functions. The modifica- tion of the transport key and disabling the BAC function shall be possible. This is done by F.Management. The SFR FMT_SMR.1 requires the maintenance of the role authorized personnel of the passport issuing authorities. The roles are managed by F.Identification_Authentication. The SFR FPT_EMS.1 requires limiting of emanations. This is provided by F.IC_CL. The SFR FPT_PHP.3 requires the enforcement to resistance to physical attacks. This is provided by F.IC_CL. The SFR FTP_ITC.1 requires the usage of a trusted channel. This is done by F.Access_Control and F.Identification_Authentication. 7.4 Statement of Compatibility This is a statement of compatibility between this Composite Security Target and the Security Targets of ST31N600 [ST_ST31N600] and cryptographic library Neslib 6.7.4 [ST_ST31N600_Neslib]. 7.4.1 Compatibility: TOE Security Environment 7.4.1.1 Security Objectives Table 7.3 gives a mapping of the security objectives of the hardware and the cryptographic library to those of the composite ST. With the exception of “AUG1.O.Add-Functions-Lib”, which is only defined in [ST_ST31N600_Neslib], all objectives are given in both the hardware and the cryptographic library ST corresponding to each other. The OEs are categorized according to [CC_PartEM]. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 67 Security Target HW objective Matches TOE objective Remarks BSI.O.Leak-Inherent (protection against inherent information leakage) O.Physical_Attack BSI.O.Phys-Probing (protection against physical probing) O.Physical_Attack BSI.O.Malfunction (protection against malfunctions) O.Physical_Attack BSI.O.Phys-Manipulation (protection against physical manipula- tion) O.Physical_Attack BSI.O.Leak-Forced (protection against forced information leakage) O.Physical_Attack BSI.O.Abuse-Func (protection against abuse of functional- ity) O.Physical_Attack BSI.O.Identification (TOE identification) O.Authority BSI.O.RND (random numbers) – basic objective for the secu- rity of the TOE; no conflicts with any security objective of the TOE BSI.O.Cap_Avail_Loader (capability and availability of the loader) – not applicable (the loader is deactivated before delivery) BSI.O.Ctrl_Auth_Loader (access control and authenticity for the loader) – not applicable (the loader is deactivated before delivery) BSI.O.Authentication (authentication to external entities) – no conflict AUG1.O.Add-Functions (additional specific security functional- ity) O.Logical_Attack AUG1.O.Add-Functions-Lib (additional specific security functional- ity) O.Logical_Attack Neslib only AUG4.O.Mem-Access (area based memory access control) O.Physical_Attack JIL.O.Prot_TSF_Confidentiality (protection of the confidentiality of the TSF) – no conflict JIL.O.Secure_Load_ACode (secure loading of the additional code) – not applicable Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 68 Security Target HW objective Matches TOE objective Remarks JIL.O.Secure_AC_Activation (secure activation of the additional code) – not applicable JIL.O.TOE-Identification (secure identification of the TOE) – no conflict O.Secure-Load-AMemImage (secureloadingoftheadditionalmemory image) – not applicable O.MemImage-Identification (secure identification of the memory im- age) – no conflict BSI.OE.Resp-Appl (treatment of user data) – CfOE, no conflict BSI.OE.Process-Sec-IC (protection during composite product manufacturing) – CfOE, no conflict BSI.OE.Lim_Block_Loader (limitation of capability and blocking the loader) – IrOE, not applicable (the loader is deactivated before delivery) BSI.OE.Loader_Usage (secure usage of the Loader) – IrOE, not applicable (the loader is deactivated before delivery) BSI.OE.TOE-Auth (external entities authenticating of the TOE) – CfOE, no conflict OE.Composite-TOE-Id (composite TOE identification) – CfOE, no conflict OE.TOE-Id (TOE identification) – CfOE, no conflict OE.Enable-Disable-Secure-Diag (enabling or disabling the Secure Diag- nostic) – CfOE, no conflict OE.Secure-Diag-Usage (secure communication and usage of the Secure Diagnostic) – CfOE, no conflict Table 7.3: Mapping of base component security objectives to TOE security objectives including those of the environment. 7.4.1.2 Security Requirements Table 7.4 addresses the base component security requirements and their relevance for the TOE (ANSSI-CC-2022/21-R02 abbreviated as “HW” and ANSSI-CC-2022/42-R02 abbreviated as “CL”). None of the SFRs show any conflicts with the base component SFRs. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 69 Security Target The SFRs are categorized according to [CC_PartEM]: • IP_SFR: Irrelevant base component-SFRs not being used by the composite-ST; • RP_SFR-SERV: Relevant base component-SFRs being used by the composite-ST to implement a security service with associated TSFI; • RP_SFR-MECH: Relevant base component-SFRs being used by the composite-ST be- cause of their security properties providing protection against attacks to the TOE as a whole and being addressed in ADV_ARC. These required security properties are a result of the security mechanisms and services that are implemented in the base component. HW SFRs Matches TOE SFR Remarks FRU_FLT.2 (limited fault tolerance) – RP_SFR-MECH, no conflict (HW, CL) FPT_FLS.1 (failure with preservation of secure state) – RP_SFR-MECH, no conflict (HW, CL) FMT_LIM.1/Test (limited capabilities) – RP_SFR-MECH, no conflict (HW, CL) FMT_LIM.2/Test (limited availability) – RP_SFR-MECH, no conflict (HW, CL) FAU_SAS.1 (audit storage) – RP_SFR-MECH, no conflict (HW, CL) FDP_SDC.1 (stored data confidentiality) – RP_SFR-MECH, no conflict (HW, CL) FDP_SDI.2 (stored data integrity monitoring and ac- tion) – RP_SFR-MECH, no conflict (HW, CL) FPT_PHP.3 (resistance to physical attack) FPT_PHP.3 RP_SFR-SERV (HW, CL) FDP_ITT.1 (basic internal transfer protection) FPT_EMS.1 RP_SFR-SERV (HW, CL) FPT_ITT.1 (basic internal TSF data transfer protec- tion) FPT_EMS.1 RP_SFR-SERV (HW, CL) FDP_IFC.1 (subset information flow control) FPT_EMS.1 RP_SFR-SERV (HW, CL) FCS_RNG.1/PTG.2 (random number generation – PTG.2) FCS_RNG.1 RP_SFR-SERV (HW, CL) FCS_COP.1/TDES (cryptographic operation – TDES) FCS_COP.1sb RP_SFR-SERV (HW) FCS_COP.1/AES (cryptographic operation – AES) FCS_COP.1n FCS_COP.1mp FCS_COP.1sp RP_SFR-SERV (HW) FDP_ACC.2/Memories (complete access control) – RP_SFR-MECH, no conflict (HW, CL) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 70 Security Target HW SFRs Matches TOE SFR Remarks FDP_ACF.1/Memories (security attribute based access control) – RP_SFR-MECH, no conflict (HW, CL) FMT_MSA.3/Memories (static attribute initialization) – RP_SFR-MECH, no conflict (HW, CL) FMT_MSA.1/Memories (management of security attributes) – RP_SFR-MECH, no conflict (HW, CL) FMT_SMF.1/Memories (specification of management functions) – RP_SFR-MECH, no conflict (HW, CL) FIA_API.1 (authentication proof of identity) – IP_SFR, not applicable (HW) FMT_LIM.1/Loader (limited capabilities – loader) – IP_SFR, not applicable (HW, CL) FMT_LIM.2/Loader (limited availability – loader) – IP_SFR, not applicable (HW, CL) FTP_ITC.1/Loader (inter-TSF trusted channel – loader) – IP_SFR, not applicable (HW, CL) FDP_UCT.1/Loader (basic data exchange confidentiality – loader) – IP_SFR, not applicable (HW, CL) FDP_UIT.1/Loader (basic data exchange confidentiality – loader) – IP_SFR, not applicable (HW, CL) FDP_ACC.1/Loader (subset access control – loader) – IP_SFR, not applicable (HW, CL) FDP_ACF.1/Loader (security attribute based access control – loader) – IP_SFR, not applicable (HW, CL) FMT_MSA.3/Loader (static attribute initialization – loader) – IP_SFR, not applicable (HW, CL) FMT_MSA.1/Loader (management of attribute initialization – loader) – IP_SFR, not applicable (HW, CL) FMT_SMR.1/Loader (security roles – loader) – IP_SFR, not applicable (HW, CL) FMT_SMF.1/Loader (specification of management functions – loader) – IP_SFR, not applicable (HW, CL) FMT_UID.1/Loader (timing of identification – loader) – IP_SFR, not applicable (HW, CL) FMT_UAU.1/Loader (timing of authentication – loader) – IP_SFR, not applicable (HW, CL) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 71 Security Target HW SFRs Matches TOE SFR Remarks FPT_FLS.1/Loader (failure with preservation of secure state – loader) – IP_SFR, not applicable (HW, CL) FAU_SAR.1/Loader (audit review – loader) – IP_SFR, not applicable (HW, CL) FAU_SAS.1/Loader (audit storage – loader) – IP_SFR, not applicable (HW, CL) FMT_LIM.1/Stest (limited capabilities – secure device test) – IP_SFR, not applicable (HW, CL) FMT_LIM.2/Stest (limited availability – secure device test) – IP_SFR, not applicable (HW, CL) FTP_ITC.1/Sdiag (inter-TSF trusted channel – secure diag- nostic) – IP_SFR, not applicable (HW, CL) FAU_SAR.1/Sdiag (audit review – secure diagnostic) – IP_SFR, not applicable (HW, CL) FMT_LIM.1/Sdiag (limited capabilities – secure diagnostic) – IP_SFR, not applicable (HW, CL) FMT_LIM.2/Sdiag (limited availability – secure diagnostic) – IP_SFR, not applicable (HW, CL) FCS_SBO.1/Copy (secure basic operation on data – copy) – RP_SFR-MECH, no conflict (CL) FCS_SBO.1/Compare (secure basic operation on data – com- pare) – RP_SFR-MECH, no conflict (CL) FCS_SBO.1/Swap (secure basic operation on data – swap) – RP_SFR-MECH, no conflict (CL) FCS_SBO.1/Shift (secure basic operation on data – shift) – RP_SFR-MECH, no conflict (CL) FCS_SBO.1/XOR (secure basic operation on data – XOR) – RP_SFR-MECH, no conflict (CL) FCS_COP.1/SW-TDES (cryptographic operation – DES & Triple DES) FCS_COP.1sb RP_SFR-SERV (CL) FCS_COP.1/SW-AES (cryptographic operation – AES) FCS_COP.1n FCS_COP.1mp FCS_COP.1sp RP_SFR-SERV (CL) FCS_COP.1/RSA (cryptographic operation – RSA) – IP_SFR, not used (CL) FCS_COP.1/ECC-WC (cryptographic operation – ECC-WC) FCP_COP.1a FCP_COP.1e RP_SFR-SERV (CL) FCS_COP.1/ECC-EC (cryptographic operation – ECC-EC) – IP_SFR, not used (CL) Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 72 Security Target HW SFRs Matches TOE SFR Remarks FCS_COP.1/ECC-MC (cryptographic operation – ECC-MC) – IP_SFR, not used (CL) FCS_COP.1/SHA (cryptographic operation – SHA) FCP_COP.1h FCP_COP.1hb FCP_COP.1hp RP_SFR-SERV (CL) FCS_COP.1/Keccak (cryptographic operation – Keccak) – IP_SFR, not used (CL) FCS_COP.1/Keccak-p (cryptographic operation – Keccak-p) – IP_SFR, not used (CL) FCS_COP.1/Diffie-Hellman (cryptographic operation – Diffie- Hellman) – IP_SFR, not used (CL) FCS_COP.1/DRBG (cryptographic operation – DRBG) – IP_SFR, not used (CL) FCS_CKM.1/Prime-generation (cryptographic key generation – prime generation) – IP_SFR, not used (CL) FCS_CKM.1/RSA-key-generation (cryptographic key generation – RSA key generation) – IP_SFR, not used (CL) Table 7.4: Mapping of base component SFRs to TOE SFRs. 7.4.1.3 Assurance Requirements The level of assurance of • the TOE is EAL4 augmented by ALC_DVS.2 and ALC_FLR.3. • the platform is EAL6 augmented by ALC_FLR.2 and ASE_TSS.2. • the cryptographic library is EAL5 augmented by ALC_DVS.2, ALC_FLR.2 and AVA_VAN.5. The TOE’s life-cycle requirement regarding flaw remediation ALC_FLR.3 exceeds the cer- tified ALC_FLR.2 of the base components. The processes for flaw remediation of the base components and the TOE do not interfere.The higher ASE_TSS.2 of the base component do not interfere the ASE_TSS.1 of the TOE. This shows that the Assurance Requirements of the TOE do not interfere, is matched or exceeded by the Assurance Requirements of the base component. There are no conflicts. 7.4.2 Conclusion Overall no contradictions between the Security Targets of the TOE and the base component can be found. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 73 Security Target 8 Glossary 8.1 CC Related PP Protection Profile CC Common Criteria; the same contents of the CC are also established as ISO/IEC 15408 Standards. OE Security objectives for the operational environment SFR Security functional requirements ST Security Target TOE Target of Evaluation 8.2 ePassport Related ICAO International Civil Aviation Organization SAC Supplemental Access Control: This is written in 1.1.3 Supplemental Access Control of [ICAO_SAC] as follows. This Technical Report specifies PACE v2 as an access control mecha- nism that is supplemental to Basic Access Control. PACE MAY be imple- mented in addition to Basic Access Control, i.e. • States MUST NOT implement PACE without implementing Basic Access Control if global interoperability is required. • InspectionSystemsSHOULDimplementandusePACEifprovided by the MRTD chip. Passport manufacturer An organization, which manufactures passport booklets and configures basic data (e.g. management data such as passport number, and Active Authentication Public Key and private key pair) to the TOE. Passport office An organization, which configures the passport booklet including the TOE with the personal information of the passport holder, and issues the passport. The passport offices are set up in various regions and serve as a counter to deliver the passport to the passport holder. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 74 Security Target Active Authentication Security mechanism, by which means the public key and private key pair based on the public key cryptography system is stored and the private key is kept secret in the IC chip that is a part of the TOE. The publickeyistransmittedtoanexternaldevicetryingtoauthenticatethe TOE and the TOE is authenticated through cryptographic calculation by the challenge response system using the private key, which has been kept a secret in the TOE. The Active Authentication procedure has been standardized by ICAO. Passive Authentication Security mechanism, by which the digital signature of the passport issuing authority is applied to personal information data stored in the TOE, and the authenticity of data read from the TOE is verified by using the PKI system with assured interoperability both on the passport issuing and receiving sides. The Passive Authentication procedure has been standardized by ICAO. Readout key A key which is used at issuing a passport, and is embedded in the TOE at the manufacturing stage. Refer to Table 3.3 for operations which are permitted by successful verification. Transport key Same as above. Active Authentication Information Access Key Same as above. MRZ data Data which are printed on a surface of ePassport and readable with terminals. Basic access key file A file storing the keys, which are derived from MRZ data, used for en- cryption and generation of Message Authentication Codes at the mu- tual authentication procedure of BAC. Password key file A file storing the key, which is derived from MRZ data, used for encryp- tion of Nonce at the PACE procedure. PACE v2 security information Information used for PACE v2 such as cryptographic algorithms and domain parameters. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 75 Security Target 9 Bibliography [AGD] User Guidance – Xaica-α PLUS ePassport on MTCOS Pro 2.6 / ST31N600, MaskTech International GmbH. [ANSI_X9-62] ANSI X9.62-2005, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005-11-16. [BSI_AIS31] Anwendungshinweise und Interpretationen zum Schema – Funktion- alitätsklassen und Evaluationsmethodologie für physikalische Zufall- szahlengeneratoren, BSI, AIS 31, Version 3, 2013-05-15. [BSI_TR-03110-1] TR-03110-1, Technical Guideline TR-03110-1: Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS To- ken – Part 1 – eMRTDs with BAC/PACEv2 and EACv1, BSI, Version 2.20, 2015-02-26. [BSI_TR-03110-3] TR-03110-3, Technical Guideline 03110: Advanced Security Mecha- nisms for Machine Readable Travel Documents and eIDAS Token - Part 3 – Common Specifications, BSI, Version 2.21, 2016-12-21. [BSI_TR-03111] TR-03111, Technical Guideline TR-03111: Elliptic Curve Cryptography, BSI, Version 2.1, 2018-06-01. [BSI_TR-03116-2] TR-03116-2, Technische Richtlinie – Kryptographische Verfahren für Projekte der Bundesregierung - Teil 2 – Hoheitliche und eID- Dokumente, BSI, Stand 2025, 2025-07-03. [CC_Errata] CCMB-2024-002, Version 1.1, Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1), Common Criteria Maintenance Board, 2024-07-22. [CC_Part1] CCMB-2022-11-001, Version CC:2022, Revision 1, Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Common Criteria Maintenance Board, 2022-11. [CC_Part2] CCMB-2022-11-002, Version CC:2022, Revision 1, Common Criteria for Information Technology Security Evaluation, Part 2: Security func- tional components, Common Criteria Maintenance Board, 2022-11. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 76 Security Target [CC_Part3] CCMB-2022-11-003, Version CC:2022, Revision 1, Common Criteria for Information Technology Security Evaluation, Part 3: Security assur- ance components, Common Criteria Maintenance Board, 2022-11. [CC_Part4] CCMB-2022-11-004, Version CC:2022, Revision 1, Common Criteria for Information Technology Security Evaluation, Part 4: Framework for the specification of evaluation methods and activities, Common Criteria Maintenance Board, 2022-11. [CC_Part5] CCMB-2022-11-005, Version CC:2022, Revision 1, Common Criteria for Information Technology Security Evaluation, Part 5: Pre-defined packages of security requirements, Common Criteria Maintenance Board, 2022-11. [CC_PartEM] CCMB-2022-11-006, Version CC:2022, Revision 1, Common Method- ology for Information Technology Security Evaluation, Evaluation Methodology, Common Criteria Maintenance Board, 2022-11. [CC_PP-0056-V2] BSI-CC-PP-0056-V2-2012-MA-02, Common Criteria Protection Pro- file / Machine Readable Travel Document with ’ICAO Application’, Extended Access Control with PACE, BSI, Version 1.3.2, 2012-12-05. [CC_PP-0084] BSI-CC-PP-0084-2014, Security IC Platform Protection Profile with Augmentation Packages, EUROSMART, Version 1.0, 2014-01-13. [CC_PP-C0500] JISEC C0500, version 1.00, Protection Profile for ePassport IC with SAC (BAC+PACE) and Active Authentication, JBMIA, 2016-03-08. [FIPS_140-3] FIPS PUB 140-3, Security Requirements for Cryprographic Modules, National Institute of Standards and Technology, 2019-03. [FIPS_180-4] FIPS PUB 180-4, Secure Hash Standard (SHS), National Institute of Standards and Technology, 2015-08. [FIPS_197] FIPS PUB 197, Specification for the Advanced Encryption Standard (AES), National Institute of Standards and Technology, 2023-05. [ICAO_9303] ICAO Doc 9303, Machine Readable Travel Documents, International Civil Aviation Organization, 2021. [ICAO_SAC] Technical Report: Supplemental Access Control for Machine Read- able Travel Documents, ICAO, TR-SAC V1.1, 2014-04-15. [ISO_10116] ISO/IEC 10116-2017, Information technology – Security techniques - Modes of operation for an n-bit block cipher, ISO/IEC, 2017-07. [ISO_7816] ISO/IEC 7816, Identification cards – Integrated circuit cards – Multi- part Standard, ISO/IEC, 2008. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 77 Security Target [ISO_9797-1] ISO/IEC 9797-1:2011, Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher, ISO/IEC, 2011. [JIL_AP] Joint Interpretation Library, Application of Attack Potential to Smart- cards and Similar Devices, Joint Interpretation Working Group, Ver- sion 3.2.1, 2024-02. [KiSch-RNG] Version 2.0, A proposal for: Functionality classes for random number generators, W. Killmann and W. Schindler, 2011-09-18. [NIST_SP800-38B] NIST SP 800-38B, Recommendation for Block Cipher Modes of Oper- ation: The CMAC Mode for Authentication, National Institute of Stan- dards and Technology, 2016-10. [NIST_SP800-67] NIST SP 800-67 Rev. 2, Recommendation for the Triple Data Encryp- tion Algorithm (TDEA) Block Cipher, NIST, 2017-11. [NIST_SP800-90A] NISTSP800-90ARev.1,RecommendationforRandomNumberGener- ation Using Deterministic Random Bit Generators, National Institute of Standards and Technology, 2015-06. [ST_ST31N600] STMicroelectronics, ST31N600 A03 Security Target for composition, ANSSI-CC-2022/21-R02, 2024-11-13. [ST_ST31N600_Neslib] STMicroelectronics, Cryptographic library NESLIB 6.7.4 on ST31N600 A03 – Security Target for composition, ANSSI-CC-2022/42-R02, 2024- 08-13. Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 78 Security Target 10 Revision History Version Date Changes 1.0 2025-11-24 Public version Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 79 Security Target 11 Contact MASKTECH GMBH – Headquarters Nordostpark 45 Phone +49 911 955149 0 D-90411 Nuernberg Fax +49 911 955149 7 Germany Email info@masktech.de MASKTECH GMBH – Support Bahnhofstr. 13 Phone +49 911 955149 0 D-87435 Kempten Fax +49 831 5121077 5 Germany Email support@masktech.de NTT DATA CORPORATION – Sponsor Toyosu Center Building ANNEX 3-9 Toyosu 3 Chome Koto-ku Tokyo Japan Homepage www.nttdata.com Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 80 Security Target A Overview Cryptographic Algorithms The following cryptographic algorithms are used by the TOE to enforce its security policy: Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments ST-Reference 1 Authenticated Key Agreement PACEv2 (Generic Map- ping), PACE (key agreement, authentication), Elliptic Curve Diffie-Hellman, Nonce Encryption, Authentication Token [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303], [BSI_TR-03111] sec. 4.3.2.1, [FIPS_197] (AES), [NIST_SP800-38B], sec. 6 (CMAC) also cf. line 6 and 11 | MRZ| = 160, | Nonce| = 128, NIST: 256, 384, Session keys: AES: 128, 256, [BSI_TR-03110-1] [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303] FCS_COP.1e, FCS_COP.1mp, FIA_UAU.1, FIA_UAU.5 2 Authentication Active Authentication ECDSA signature gen- eration (using NIST P-256/SHA-256 and NIST P-384/SHA-384) [BSI_TR-03111], sec. 4.2.1, [ANSI_X9-62], sec. 7, [FIPS_180-4], sec. 6, also cf. line 14 NIST: 256, 384 [ICAO_9303], [ICAO_SAC], [BSI_TR-03110-1] FCS_COP.1a 3 Integrity Secure Messaging, DES and 3DES in CBC mode (Retail-MAC) [ICAO_9303], [NIST_SP800-67] (3DES), [ISO_9797-1], sec. 7.4, MAC Algorithm 3 (Retail- MAC) 56 (excluding the final block of message), 112 (final block of message) [BSI_TR-03110-1], [ICAO_9303] FCS_COP.1sb, FDP_UIT.1b 4 Integrity Secure Messaging, AES/CMAC [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303], [FIPS_197] (AES), [NIST_SP800-38B], sec. 6 (CMAC) 128, 256 [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303] FCS_COP.1sp, FDP_UIT.1p 5 Key Generation PACE (ephemeral private keys), Elliptic Curve Diffie-Hellman (using NIST P-256 and NIST P-384) [BSI_TR-03111], sec. 4.1.3 256, 384 [BSI_TR-03111] FCS_CKM.1e 6 Key Derivation Cryptographic key gen- eration (PACE, session keys) [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303] part 11, sec. 9.7.3, [FIPS_180-4] sec. 6, [BSI_TR-03111] sec. 4.3.3.2, AES: 128, 256 [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303] FCS_CKM.1p Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 81 Security Target Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments ST-Reference 7 Key Derivation Cryptographic key gener- ation (BAC) [BSI_TR-03110-1], [ICAO_9303], part 11, sec. 9.7.2 112 [BSI_TR-03110-1], [ICAO_9303] FCS_CKM.1b 8 Confidentiality Secure Messaging, 3DES in CBC mode [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_9303], part 11, sec. 9.7.2, [NIST_SP800-67], (3DES), [ISO_10116], sec. 7 (CBC) 112 [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_9303] FCS_COP.1sb, FDP_UCT.1b 9 Confidentiality Secure Messaging, AES in CBC mode [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303], part 11, sec. 9.8, [FIPS_197], (AES), [ISO_10116], sec. 7 (CBC) 128, 256 [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303] FCS_COP.1sp, FDP_UCT.1p 10 Trusted Channel Secure Messaging in ENC/MAC (BAC and PACE) [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC] (PACE), [ICAO_9303] additionally cf. lines 3 and 8 (BAC) and 4 and 9 (PACE) - [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_SAC], [ICAO_9303] FTP_ITC.1 11 Nonce encryption AES in CBC mode [ICAO_9303], sec. 4.4.3.3, [FIPS_197], (AES), [ISO_10116], sec. 7 (CBC) - [BSI_TR-03110-3] [ICAO_9303] FCS_COP.1n 12 Cryptographic Primitive PTG.3 Random number generator (PTG.2 and cryptographic post- processing) [BSI_AIS31], [NIST_SP800-90A], sec. 10.2, 10.3.2 - [BSI_TR-03116-2] FCS_RNG.1 13 Hash for key derivation (Cryptographic Primitive) SHA-[1, 256] [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_9303], [ICAO_SAC], [FIPS_180-4], sec. 6 - [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_9303], [ICAO_SAC] FCS_COP.1hb, FCS_COP.1hp 14 Hash for signature gen- eration (Cryptographic Primitive) SHA-[256, 384] [BSI_TR-03110-1], [ICAO_9303], [ICAO_SAC], [FIPS_180-4], sec. 6 - [BSI_TR-03110-1], [BSI_TR-03110-3], [ICAO_9303], [BSI_TR-03111] FCS_COP.1h Table A.1: Overview Cryptographic Algorithms Xaica-α PLUS ePassport on MTCOS Pro 2.6 with SAC (BAC+PACE) and Active Authentication / ST31N600, Version 1.0 82