SECURITY TARGET COMMON CRITERIA DOCUMENTS | Version 1.1 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01 Certification-ID: BSI-DSZ-CC-1074-V2    Public Version MaskTech International GmbH | Nordostpark 45 | Nuernberg | www.masktech.com | +49 (0)911 95 51 49-0 SECURITY TARGET Contents 1 ST Introduction 5 1.1 ST 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 Claim 11 2.1 CC Conformance Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 PP Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Package Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Conformance Rationales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 PP Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Security Problem Definition 13 3.1 Users and Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4 Security Objectives 20 4.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Security Objectives for the Operational Environment . . . . . . . . . . . . . 22 4.3 Security Objectives Rationales . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.1 Correspondence between Security Problem Definition and Security Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.2 Security Objectives Rationale . . . . . . . . . . . . . . . . . . . . . . 24 5 Extended Components Definition 26 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 1 SECURITY TARGET 5.1 FCS_RND: Random number generation . . . . . . . . . . . . . . . . . . . . . 26 5.2 FPT_EMS: TOE emanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6 Security Requirements 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 Cryptographickeygeneration(PACE,ephemeralkeypairs) 30 6.1.4 FCS_CKM.4 Cryptographic key destruction . . . . . . . . . . . . . . 31 6.1.5 FCS_COP.1a Cryptographic operation (Active Authentication, signa- ture generation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.6 FCS_COP.1h Cryptographic operation (Active Authentication, hash functions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1.7 FCS_COP.1hb Cryptographic operation (BAC, hash functions) . . . . 32 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) . . . . . . 34 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_RND.1 Random number generation . . . . . . . . . . . . . . . . 37 6.1.16 FDP_ACC.1a Subset access control (Issuance procedure) . . . . . . . 38 6.1.17 FDP_ACC.1b Subset access control (BAC) . . . . . . . . . . . . . . . 38 6.1.18 FDP_ACC.1p Subset access control (PACE) . . . . . . . . . . . . . . . 39 6.1.19 FDP_ACF.1a Security attribute based access control (Issuance proce- dure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 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) . . . . . 40 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) . . . . . . . . 41 6.1.24 FDP_UCT.1p Basic data exchange confidentiality (PACE) . . . . . . . 41 6.1.25 FDP_UIT.1b Data exchange integrity (BAC) . . . . . . . . . . . . . . . 42 6.1.26 FDP_UIT.1p Data exchange integrity (PACE) . . . . . . . . . . . . . . 42 6.1.27 FIA_AFL.1a Authenticationfailurehandling(ActiveAuthenticationIn- formation Access Key) . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.28 FIA_AFL.1d Authentication failure handling (Transport key) . . . . . 43 6.1.29 FIA_AFL.1r Authentication failure handling (Readout key) . . . . . . 43 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 2 SECURITY TARGET 6.1.30 FIA_UAU.1 Timing of authentication . . . . . . . . . . . . . . . . . . 44 6.1.31 FIA_UAU.4 Single-use authentication mechanisms . . . . . . . . . . 44 6.1.32 FIA_UAU.5 Multiple authentication mechanisms . . . . . . . . . . . 44 6.1.33 FIA_UID.1 Timing of identification . . . . . . . . . . . . . . . . . . . 45 6.1.34 FMT_MOF.1 Management of security functions behavior . . . . . . . 45 6.1.35 FMT_MTD.1 Management of TSF data . . . . . . . . . . . . . . . . . 46 6.1.36 FMT_SMF.1 Specification of management functions . . . . . . . . . 46 6.1.37 FMT_SMR.1 Security roles . . . . . . . . . . . . . . . . . . . . . . . . 46 6.1.38 FPT_EMS.1 TOE Emanation . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.39 FPT_PHP.3 Resistance to physical attack . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . . . . . . . . . 49 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 . . . . . . . . . . . . . . 56 7 TOE Summary Specification 57 7.1 TOE Security Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1.1 TOE Security Functions from Hardware (IC) and Cryptographic Library 57 7.1.1.1 F.IC_CL: Security Functions of the Hardware (IC) and Cryp- tographic Library . . . . . . . . . . . . . . . . . . . . . . . 57 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 . . . . . . . . . . . . . . . 58 7.1.2.3 F.Management . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1.2.4 F.Crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1.2.5 F.Verification . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2 Assurance Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.3 TOE Summary Specification Rationale . . . . . . . . . . . . . . . . . . . . . 61 7.4 Statement of Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4.1 Relevance of Hardware TSFs . . . . . . . . . . . . . . . . . . . . . . . 65 7.4.2 Compatibility: TOE Security Environment . . . . . . . . . . . . . . . 66 7.4.2.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4.2.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 3 SECURITY TARGET 7.4.2.3 Organizational Security Policies . . . . . . . . . . . . . . . 67 7.4.2.4 Security Objectives . . . . . . . . . . . . . . . . . . . . . . 68 7.4.2.5 Security Requirements . . . . . . . . . . . . . . . . . . . . 69 7.4.2.6 Assurance Requirements . . . . . . . . . . . . . . . . . . . 72 7.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 8 Glossary 73 8.1 CC Related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.2 ePassport Related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9 Revision History 78 10 Contact 79 A Overview Cryptographic Algorithms 80 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 4 SECURITY TARGET 1 ST Introduction 1.1 ST and TOE Reference Title Security Target – Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01 Version number 1.1 Issue Date 2020-07-17 Author MASKTECH INTERNATIONAL GMBH Sponsor NTT Data Corporation Developer MASKTECH INTERNATIONAL GMBH Registration BSI-DSZ-CC-1074-V2 CC Reference 3.1 (Revision 5) Compliant to Protection Profile for ePassport IC with SAC (BAC+PACE) and Active Au- thentication (JISEC C0500) Assurance Level The assurance level for this ST is EAL4 augmented TOE name Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01 TOE hardware STMicroelectronics, ST31G480 D01, smartcard IC including crypto- graphic library Neslib 6.2.1 TOE version MTCOS Pro 2.5 Key Words Smartcard, ICcard, ePassport, BasicAccessControl(BAC),Supplemen- tal Access Control (SAC), PACE, Active Authentication N The notation “Xaica-α” may be substituted by the notation “Xaica-Alpha” to pre- vent 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 5 SECURITY TARGET 1.2 TOE Overview 1.2.1 TOE Types The TOE is ePassport IC (including necessary software). This ePassport IC is composed of IC chip hardware with the contactless communication interface, and basic software (operat- ing system) and ePassport application program that are installed in the said hardware (here- inafter, theterman“ICchip”shallmeanan“ePassportIC”). Anexternalantennaisconnected 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 soft- ware. It comprises of: • the integrated circuit (IC) ST31G480 D01 by STMicroelectronics, • the basic software (operating system, OS) MTCOS Pro 2.5 implemented on the IC, • the ePassport application software, • the configuration script and • the associated guidance documentation [AGD]. The IC hardware ST31G480 D01 including the cryptographic library Neslib 6.2.1 provides basic functionality, among others the contactless communication interface, and low-level security features (e.g. random number generator, 3DES-, AES and EC-support). It is certi- fied (ANSSI-CC-2019/12) according to CC EAL5 augmented compliant to the Protection Profile [CC_PP-0084]. MTCOS Pro is a fully interoperable multi-application smart card operating system com- pliant 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) com- pliant to [ICAO_9303]. N The TOE is configured for an antenna capacitance of either 20 pF or 68 pF. The con- figuration is done during production. This difference is not security-relevant, thus both variants are taken as one single configuration. The ePassport is viewed as unit of the physical part of the ePassport in form of the IC sheet/booklet and chip. It presents visualreadabledataincluding(butnotlimitedto)personaldataofthePassportHolder 1. the biographical data on the biographical data page of the travel document sur- face, 2. the printed data in the Machine Readable Zone (MRZ) and 3. the printed portrait. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 6 SECURITY TARGET the logical ePassport as data of the Passport Holder stored according to the Logical Data Structure as defined in [ICAO_9303] as specified by ICAO on the contactless in- tegrated 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 equiva- lent 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 pur- poses. In order to prevent such forgery, an IC chip containing personal information with dig- ital 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 preven- tion 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. ThistypeofforgeryattackcanbecounteredbyaddingtheActiveAuthenticationfunction 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 im- migration, 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 digital- ized 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. The main security functions of the TOE are to protect data stored in the TOE from illicit reading or writing. The operation of the security functions applied to contactless communi- 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 7 SECURITY TARGET cation with the terminal shall comply with the BAC, PACE, and Active Authentication speci- fications 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 em- bedding 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 envi- ronment 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 associ- ated guidance documentation. In phase 1, threats in the operational environment are not considered, but proper devel- opment security shall be maintained to protect the confidentiality and integrity of develop- ment data. Security related to the TOE in the development phase is evaluated as the devel- opment security in assurance requirements. The TOE security functions are still not validly operational in the development phase. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 8 SECURITY TARGET All sites maintain a secure development environment. The basic software and the application software is securely delivered from MASKTECH IN- TERNATIONAL GMBH to STMicroelectronics. Phase 2 Phase 2 is a manufacturing phase. STMicroelectronics The hardware for the IC chip is manufactured, and operating sys- tem and application software for passport are installed in this hardware. A file object necessary 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 ex- ternal 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). Inthisphase, threatsfromtheoperationalenvironmentarenotconsidered, butproper 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 issuing authorities, the TOE is required to have security functionality that allows only autho- rized 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 in- formation of the passport holder (e.g. name, information on birth and so on) and 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. 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 9 SECURITY TARGET 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 im- migration procedures. In phase 4, no information stored in the TOE is altered or deleted. The TOE security func- tion protects the information necessary for immigration procedures against illicit reading, unless the information is read by an Authorized Terminal. The private key for Active Au- thentication 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- 2019/12. 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 describethetransportofhardware,softwareorguidancedocumentationwithinthelifecycle 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 10 SECURITY TARGET 2 Conformance Claim 2.1 CC Conformance Claim CC, to which this ST conforms, are identified. The ST conforms to the following CC V3.1: • Part 1: Overview and the General Model; April 2017, Version 3.1 Revision 5, CCMB-2017- 04-001 [CC_Part1] • Part 2: Security Functional Components; April 2017, Version 3.1 Revision 5, CCMB-2017- 04-002 [CC_Part2] • Part 3: Security Assurance Components; April 2017, Version 3.1 Revision 5, CCMB-2017- 04-003 [CC_Part3] • Conformance to CC Part 2: CC part 2 extended • Conformance to CC Part 3: CC part 3 conformant • Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; April 2017, Version 3.1 Revision 5 CCMB-2017-04-004 [CC_PartEM] 2.2 PP Claim This ST complies substantially to ’Protection Profile for ePassport IC with SAC (BAC+PACE) andActiveAuthentication’, version1.00, [CC_PP-C0500](Englishtranslation), whichrequires strict compliance. For formal reasons no strict conformance to the original Japanese Pro- tection Profile is claimed, because the English translation of [CC_PP-C0500] is not officially certified. 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. 2.4 Conformance Rationales The ST claims no conformance to other PP and thereby provides no description of confor- mance rationales. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 11 SECURITY TARGET 2.5 PP Additions The following items have been 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 in- formation 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 • FCS_RND.1 (changed with regard to the SFR given in [CC_PP-C0500] in order to provide detailed information; see also chapter 5) • FPT_EMS.1 (added to address TOE emanation; see also chapter 5) Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 12 SECURITY TARGET 3 Security Problem Definition ThischapterdefinessecurityproblemsrelatedtotheTOE.Thesecurityproblemsaredefined 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 prob- lems in a proper way. The threats, organizational security policies, and assumptions are named using an iden- tifier 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 person- alization 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 13 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 Ac- cesskey, BasicAccesskeys, passwordkey, Ac- tive Authentication private key Confidentiality, Integrity Non-secret key mate- rial Permanently or temporarily stored non- 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 verifi- cation 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 at- tacker who can read the MRZ data of the passport booklet may try to read confidential information (Active Authentication Private Key) stored in the TOE through the contact- less communication interface of the TOE. Note 3: If an attacker has physical access to a passport booklet, the attacker can visu- ally 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 sort of Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 14 SECURITY TARGET 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 com- munication 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 at- tacker who does not know about MRZ data may interfere with the communication be- tween theTOE and a terminalto disclose and/oralter communication data thatshould 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 book- let 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 nondestruc- tive 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 us- age 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 ter- minal 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 crypto- graphic 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 viola- tion of SFR. The example of nondestructive attacks includes measurements on leaked electromagnetic wave associated with the TOE operation and induction of malfunc- tions in security functions by applying environmental stress (e.g. changes in tempera- ture or clock, or application of high-energy electromagnetic fields) to the TOE in oper- ation. 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 ePass- port IC. Even in such case, however, the disclosed private key may be abused to forge TOEs. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 15 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 us- age. BesidetheActiveAuthenticationPrivatekeyanattackermaydiscloseothersecret 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], theorganizationalsecuritypoliciesincludeconformanceto 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. TOEfilestobereadareEF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM,andEF.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. NotethatthisorganizationalsecuritypolicywillnotbeappliedafterdisablingBACwith 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. TOEfilestobereadareEF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM,andEF.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 The TOE under the control of the passport issuing authorities shall allow only autho- rized 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 16 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 function 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 Active Authentication Public Key Successful verification with Active Authentication Information Access Key EF.DG15 Write Active Authentication Public Key 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 theTOEfromterminalsafterissuingaTOEembeddedpassportbooklettothepassport holder, i.e., BAC and PACE are separately specified.) *2 InEF.DG13,anICchipserialnumberhasbeenrecordedbythemanufacturer(ICSheet Manufacturer), and the management data is appended to the file by the passport issu- ing authorities (Booklet Manufacturer). Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 17 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 ePass- port 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 re- spect 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,TOEsissuedafteracertaintimeshallnotaccepttheBACprocedure. Asameansto 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 implement- ing the procedure. Note10: Thisorganizationalsecuritypolicyshallbeappliedonlyifthepassportissuing authorities demand to terminate issuing IC chip equipped with the BAC function. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 18 SECURITY TARGET 3.4 Assumptions ThissectiondescribesassumptionstobeaddressedintheoperationalenvironmentofTOEs. These assumptions need to be true for TOEs’ security functionality becomes effective. A.Administrative_Env The TOE that was delivered from the TOE manufacturer to the passport issuing au- thorities 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 passport issuer and stored in the TOE (including the Active Authentication Public Key), the in- teroperability of the PKI environment both of the issuing and receiving states or orga- nizations of the passport shall be maintained by passport issuing authorities. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 19 SECURITY TARGET 4 Security Objectives ThischapterdescribessecurityobjectivesforTOEsanditsenvironmentforthesecurityprob- lems described in Chapter 3. Section 4.1 describes the security objectives to be addressed by the TOEs, while Section 4.2 describes those to be addressed by its environment. In addi- tion, 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 objec- tives 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 composes the TOE in order to prevent the copy of personal information including the digital sig- nature 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. Ac- tive Authentication Private Key) within the TOEs from being disclosed or the informa- tion 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 at- tacks against IC chips, considering physical means including both nondestructive at- tacks and destructive attacks. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 20 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 op- erational usage. O.BAC This security objective applies to the operational environment after issuing the pass- port 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 pro- cedure shall be used in the mutual authentication and Secure Messaging between the TOEandterminals. InformationtheterminalreadsfromtheTOEisstoredintheEF.DG1, EF.DG2,EF.DG13,EF.DG14,EF.DG15,EF.COM,andEF.SODfilesamongthefilescontained 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 pass- port booklet. PACE procedure defined by Part 11 of [ICAO_9303], if the terminals re- quire, shall be used to ensure the global interoperability of the ePassport. This proce- dure 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 ex- cept 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 au- thentication failure with the readout key, transport key, or Active Authentication Infor- mation 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 authorities Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 21 SECURITY TARGET 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 Authenti- cation 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 en- vironment 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 se- cure 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 bio- graphical 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 personal- ization) 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 confidential- ity and integrity of all data by acting within a secure operational environment. Fur- thermore, 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 22 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 Thischapterdescribesrationalesfortheeffectivenessofthesecurityobjectivesstatedabove 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 Sec- tion 4.3.2 describes that any of the security problems is effectively addressed by the corre- sponding 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 secu- rity 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 23 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 securityobjective forthe TOE:O.AA and thesecurity objectivefor theenvironment: OE.Personalization address embedding of data that enables 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. Note 14: The TOE provides the precondition for the terminal to effectively verify in- tegrity 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- ingconfidentialinformation(ActiveAuthenticationPrivateKey)intheTOEthroughthe 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 secure 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 the TOE but physical means. Regarding the physical means, both nondestructive attacks and destructive attacks are considered, and countermeasures shall be imple- mented 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 (ter- minal) to read the internal TOE data through a secure communication path by apply- ing 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 24 SECURITY TARGET P.PACE The security objective for the TOE: O.PACE allows only the authorized personnel (ter- minal) to read the internal TOE data through a secure communication path by apply- ing 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- tionalauthenticationfailurebytheauthorizedTOEuserastheimplementationmeans. 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,thesecurityobjectivefortheTOE:O.Data_Lockwillalsoimplementthecon- tents of P.Prohibit. P.Personalization TheorganizationalsecuritypolicyP.Personalizationaddressesthe(i)theenrollmentof 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 or- ganizational security policy P.Disable_BAC and properly implements P. Disable_BAC. A.Administrative_Env The security objective for the operational environment: OE.Administrative_Env di- rectly 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 25 SECURITY TARGET 5 Extended Components Definition The extended component FCS_RND (Random number generation) as defined in [CC_PP-0084] (FCS_RNG) is used (replacing the extended component FCS_RND de- fined in [CC_PP-C0500]). In addition this ST uses the extended component FPT_EMS (TOE emanation), which is defined in [CC_PP-0068-V2]. 5.1 FCS_RND: Random number generation Family Behavior This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes. Component leveling FCS_RND: Random number generation —— 1 FCS_RND.1 Generation of random numbers requires that random numbers meet a defined quality metric. Management: FCS_RND.1 There are no management activities foreseen. Audit: FCS_RND.1 There are no actions defined to be auditable. FCS_RND.1 Random number generation Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a [selection: physical, non-physical true, deter- ministic, hybrid physical, hybrid deterministic] random number genera- tor that implements: [assignment: list of security capabilities]. FCS_RND.1.2 The TSF shall provide [selection: bits, octets of bits, numbers [assign- ment: format of the numbers]] that meet [assignment: a defined quality metric]. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 26 SECURITY TARGET 5.2 FPT_EMS: TOE emanation The family FPT_EMS (TOE Emanation) of the class FPT (Protection of the TSF) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against secret data stored in and used by the TOE where the attack is based on external ob- servable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This family describes the functional requirements for the limitation of intelligible emanations being not directly addressed by any other component of CC part 2 [CC_Part2]. The family ’TOE Emanation (FPT_EMS)’ is specified as follows: FPT_EMS: TOE emanation Family Behavior This family defines requirements to mitigate intelligible emanations. Component leveling FPT_EMS: TOE emanation —— 1 FPT_EMS.1 TOE emanation has two constituents: FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling ac- cess to TSF data or user data. FPT_EMS.1.2 Interface Emanation requires to not emit interface emanation enabling access to TSF data or user data. Management: FPT_EMS.1 There are no management activities foreseen. Audit: FPT_EMS.1 There are no actions defined to be auditable. FPT_EMS.1 TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [as- signment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. FPT_EMS.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 27 SECURITY TARGET 6 Security Requirements 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.4 Cryptographic key destruction 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 authentica- tion) 6.1.14 FCS_COP.1sp Cryptographic operation (PACE, Secure Messaging) 6.1.15 FCS_RND.1 Random number generation 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 pro- cedure) 6.1.20 FDP_ACF.1b Security attribute based access control (BAC) Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 28 SECURITY TARGET 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. 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: • SFR subject to iteration operation is identified by adding a low-case alphabetic charac- ter such as “a” and a parenthesized brief description showing the purpose of SFR (e.g. “Active Authentication”) after the corresponding component identifier. • The point of assignment or selection operation is shown as [assignment: XXX (itali- cized)] 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 (Ital- icized 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 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_COP.1 Cryptographic operation] FCS_CKM.4 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 sessionkeygenerationintheBasicAccessControlspecifiedbyPart 11 of [ICAO_9303]]. Note 16: 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_COP.1 Cryptographic operation] FCS_CKM.4 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 17: 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. 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_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 30 SECURITY TARGET 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: 256bitsand384bits] that meet the follow- ing: [assignment: Standards for the key pair generation specified by [BSI_TR-03111]]. Note 18: 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.4 Cryptographic key destruction Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: [selection: method for erasing cryptographic keys on volatile memory by shutting down power supply, overwriting new cryp- tographic key data, and [assignment: other cryptographic key destruction method]]] that meets the following: [assignment: none]. Note 19: The TOE shall destroy cryptographic keys on volatile memory by overwriting the key data with random data. 6.1.5 FCS_COP.1a Cryptographic operation (Active Authentication, sig- nature 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] FCS_CKM.4 Cryptographic key destruction Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 31 SECURITY TARGET FCS_COP.1.1a The TSF shall perform [assignment: generation of digital signa- ture for Active Authentication data] in accordance with a spec- ified cryptographic algorithm [assignment: ECDSA] and cryp- tographic key sizes [assignment: 256 bits and 384 bits] that meet the following: [assignment: the Digital Signature Stan- dards specified by [BSI_TR-03111], [ICAO_9303], [ICAO_SAC]and [BSI_TR-03110-1]]. Note 20: 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. Note 21: ECDSA signature generation is specified in [BSI_TR-03111], sec. 4.2.1 in conformance 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] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1h The TSF shall perform [assignment: generation of data for Active Authentication] in accordance with a specified crypto- graphic algorithm [assignment: SHA-256 and SHA-384] and cryp- tographic key sizes [assignment: none] that meet the follow- ing: [assignment: the Digital Signature Standards specified by [BSI_TR-03111]]. Note 22: 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). 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] FCS_CKM.4 Cryptographic key destruction Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 32 SECURITY TARGET 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 23: 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 authentica- tion) Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.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]]. Cryptographic algorithm Cryptographic key size Cryptographic operation Single DES in CBC mode 56 bits Message Authentication Code and verifi- cation (excluding the final block of mes- sage) 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 24: The Message Authentication Code generation process shown in Table 6.2 is equiv- alent to that specified by ISO/IEC 9797-1 MAC Algorithm 3 (Retail-MAC). Note 25: BAC (mutual authentication) specified in Part 11 of [ICAO_9303], sec. 4.3; 3DES is specified in [NIST_SP800-67], Retail-MAC is specified in [ISO_9797-1], sec. 7.4, CBC is speci- fied in [ISO_10116], sec. 7. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 33 SECURITY TARGET 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] FCS_CKM.4 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 verifi- cation (excluding the final block of mes- sage) 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). Note 26: The Message Authentication Code generation process shown in Table 6.3 is equiv- alent to that specified by ISO/IEC 9797-1 MAC Algorithm 3 (Retail-MAC). Note 27: BAC (Secure Messaging) specified in Part 11 of [ICAO_9303], sec. 9.8; 3DES is speci- fied 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 28: 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 Au- thentication 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] FCS_CKM.4 Cryptographic key destruction Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 34 SECURITY TARGET FCS_COP.1.1n The TSF shall perform [assignment: nonce encryption] in ac- cordance 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 29: 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] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1e The TSF shall perform [assignment: key agreement] in accor- dance 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 procedure specified by Part 11 of [ICAO_9303]]. Note30: 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] FCS_CKM.4 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 31: Cryptographic hash functions are specified in Part 11 of [ICAO_9303], sec. 9.7.1.2, Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 35 SECURITY TARGET [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 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] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1mp The TSF shall perform [assignment: authentication token gen- eration and verification] in accordance with a specified crypto- graphic algorithm [assignment: AES-CMAC] and cryptographic key sizes [assignment: 128 bits and 256 bits] that meet the follow- ing: [assignment: Standards for mutual authentication included in PACE specified by Part 11 of [ICAO_9303]]. Note 32: PACE (mutual authentication) specified in Part 11 of [ICAO_9303], sec. 4.4; AES is specified in [FIPS_197], CMAC is specified on [NIST_SP800-38B], sec. 6. 6.1.14 FCS_COP.1sp Cryptographicoperation(PACE,SecureMessaging) Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.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 Ta- ble 6.4] and cryptographic key sizes [assignment: cryptographic key sizes shown in Table 6.4] that meet the following: [assign- ment: 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 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 36 SECURITY TARGET Table 6.4: Cryptographic mechanisms in Secure Messaging (PACE). Note 33: 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 34: 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. 6.1.15 FCS_RND.1 Random number generation Hierarchical to: – Dependencies: – FCS_RND.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybridphysical, hybriddeterministic]randomnum- 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 de- tected, 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 TSFmustnotoutputanyrandomnumbersbeforethepower-upon- line test and the seeding of the DRG.3 post-processing algorithm have been finished successfully or when a defect has been de- tected. (PTG.3.4)Theonlinetestprocedureshallbeeffectivetodetectnon- tolerable weaknesses of the random numbers soon. (PTG.3.5) The online test procedure checks the raw random num- ber sequence. It is triggered [selection: externally, at regular intervals, continuously, upon specified internal events]. The on- line test is suitable for detecting nontolerable statistical defects of the statistical properties of the raw random numbers within an ac- ceptable 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 37 SECURITY TARGET FCS_RND.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. TheinternalrandomnumbersmustpasstestprocedureA1 [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 35: This SFR has been changed according to [CC_PP-0084] (FCS_RNG.1) to specify the requirements given in [BSI_AIS31v3] for PTG.3. 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 ac- cess control SFP] on [assignment: Subject [User process], Ob- jects [Files shown in Table 3.3 of Organizational security policy P.Authority]andListofoperationsamongsubjectsandobjectsad- dressed 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: BACSFP] on [assignment: 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 36: BAC SFP is the access control policy applied after succeeding in mutual authenti- cation based on BAC. 1 See [KiSch-RNG] Section 2.4.4. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 38 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, pass- word key file, transport key file, and private key file] and list of op- erations among subjects and objects addressed by SFP [Reading data from object]]. Note 37: PACE SFP is the access control policy applied after succeeding in mutual authenti- cation 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 ac- cess control SFP] to objects based on the following: [assignment: Subject controlled under the indicated SFP [User process], ob- jects [Files shown in Table 3.3 of the organizational security policy P.Authority], and, the SFP-relevant security attributes [Authentica- tion 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 op- eration among controlled subjects and controlled objects is al- lowed: [assignment: When the authentication status shown in Ta- ble 3.3 of the organizational security policy P.Authority is met, an operationtothefileassociatedwiththesaidauthenticationstatus 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 pol- icy P.Authority is prohibited.]. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 39 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 TheTSFshallenforcethe[assignment: BACSFP]toobjectsbased 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 op- eration among controlled subjects and controlled objects is al- lowed: [assignment: Where the authentication status of terminal has been successful, subjects are allowed to read data from ob- jects]. 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 indicated SFP [Process on behalf of terminal], objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, EF.SOD, pass- word 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.2p The TSF shall enforce the following rules to determine if an op- eration among controlled subjects and controlled objects is al- lowed: [assignment: Where the authentication status of terminal has been successful, subjects are allowed to read data from ob- jects]. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 40 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 ac- cess 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: [assign- ment: 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]userdatainamannerprotectedfromunautho- rized disclosure. 6.1.24 FDP_UCT.1p Basic data exchange confidentiality (PACE) 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] Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 41 SECURITY TARGET FDP_UCT.1.1p The TSF shall enforce of [assignment: PACE SFP] to [selection: transmit, receive]userdatainamannerprotectedfromunautho- 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 [selec- tion: 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 [selec- tion: 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 Authentica- tion Information Access Key) Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 42 SECURITY TARGET 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(fixtheauthenticationstatuswiththetransportkeyto“Notau- thenticated 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]. 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”)]. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 43 SECURITY TARGET 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 beforeallowinganyotherTSF-mediatedactionsonbehalfofthat 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 [as- signment: mutual authentication mechanism with the BAC proce- dure 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 mechanisms 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 44 SECURITY TARGET Authentication mechanism name Rule applicable to authentication mechanism Transport key Rule of authenticating the authorized personnel of the passport is- suing authorities by verifying transport key that have been already stored in the TOE Readout key Rule of authenticating the authorized personnel of the passport issu- ing 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 The TSF shall require each user to be successfully identified be- fore 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]. Note 38: To disable the Basic Access Control functionality authentication against the trans- port key is required. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 45 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 39: This requirement has to do with the configuration of transport key used to trans- port the TOE from the passport booklet manufacturer to a regional passport office in Phase 3. Inthisrequirement, theauthorizedpersonnelwhoareallowedtomanageTSFdataarethe 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 neces- sity 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 TheTSFshallmaintaintheroles[assignment: authorizedperson- 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 46 SECURITY TARGET 6.1.38 FPT_EMS.1 TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1 The TOE shall not emit [assignment: information about IC power consumption and command execution time] in excess of [assign- ment: non-useful information] enabling access to [assignment: 1. PACE session keys, 2. the PACE ephemeral private key, 3. BAC session keys] and [assignment: 4. Transport key, 5. Readout key, 6. Active Authentication Information Access key, 7. Active Authentication Private key]. FPT_EMS.1.2 The TSF shall ensure [assignment: any users] are unable to use the following interface [assignment: smart card circuit con- tacts] to gain access to [assignment: 1. PACE session keys, 2. the PACE ephemeral private key, 3. BAC session keys] and [assignment: 4. Transport key, 5. Readout key, 6. Active Authentication Information Access key, 7. Active Authentication Private key]. Note 40: SFR FPT_EMS.1 is taken in addition to the SFRs from [CC_PP-C0500] (see also chap- ter 5); 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 re- sponding automatically such that the SFRs are always enforced. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 47 SECURITY TARGET Note 41: The supporting documents that are the latest version at the time of the evalua- tion 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. 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 identifica- tion of its end points and protection of channel data from modi- fication 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 42: Communication between terminal and TSF shall be performed via the Secure Mes- saging channel defined by [ICAO_9303]. After the Secure Messaging channel is established, 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 compo- nents shown in Table 6.6. These components are all included in CC Part 3. Components except ALC_DVS.2 are included in the EAL4 assurance package. ALC_DVS.2 is a high-level component of ALC_DVS.1. [CC_PP-C0500] applies no operation to all components shown in Table 6.6. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 48 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_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.6: 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 ob- jectives for the TOE. Section 6.3.1.1 describes that each of the SFRs can be traced back to any ofthesecurityobjectivesfortheTOE,whileSection6.3.1.2describesthateachofthesecurity objectives for the TOE is properly met by the corresponding effective SFR. 6.3.1.1 Tracing between Security Objectives and Security Functional Requirements Table 6.7 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. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 49 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 FCS_CKM.1b x FCS_CKM.1p x FCS_CKM.1e x FCS_CKM.4 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_RND.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 FDP_UIT.1p x FIA_AFL.1a x FIA_AFL.1d x Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 50 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 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.7: 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- 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.4. The security objective O.AA is sufficiently achieved by the said SFRs. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 51 SECURITY TARGET 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 pro- cess 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 issuing the TOE embedded passport. The security objective O.Logical_Attack is suffi- ciently achieved by the said SFRs. O.Physical_Attack Attackscenariostryingtodisclosesecretcryptographickeysthatare 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 TSFautomaticallyresiststheattacksaccordingtoFPT_PHP.3toprotectagainstthedis- closure 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 succeeded 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.4 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 se- curity 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 protectionoftransmittedandreceiveddatabyFDP_UCT.1pandFDP_UIT.1p,andthere- quirementofcryptographiccommunicationchannelsbyFTP_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 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 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 52 SECURITY TARGET session keys, FCS_RND.1 defines the generation of random numbers such as random Nonce, FCS_COP.1n defines the encryption of Nonce, and FCS_CKM.4 defines the de- structionofthesekeys. Inorderforonlypermittedpersonneltoreadgiveninformation from the TOE, rules governing access control with FDP_ACC.1p and FDP_ACF.1p are de- fined. 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 or- der 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 authen- ticated 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 suffi- ciently 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 identificationandauthenticationrequirementsFIA_UID.1andFIA_UAU.1areappliedin 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 trans- port 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.8 shows dependencies and support for the dependencies defined for SFRs. In the table, the ’Dependencies’ column describes dependencies defined for SFRs, and the ’Sup- port for the Dependencies’ column describes by what SFRs the defined dependencies are satisfied or rationales indicating the justification for non-satisfied dependencies. SFR Dependencies Support of the Dependencies FCS_CKM.1b [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_COP.1sb and FCS_CKM.4 support to satisfy the de- pendencies. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 53 SECURITY TARGET SFR Dependencies Support of the Dependencies FCS_CKM.1p [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_COP.1sp, FCS_COP.1mp, and FCS_CKM.4 support to satisfy the dependencies. FCS_CKM.1e [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_COP.1e and FCS_CKM.4 support to satisfy the depen- dencies. FCS_CKM.4 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FDP_ITC.1, FCS_CKM.1b, FCS_CKM.1e, and FCS_CKM.1p support to satisfy 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] FCS_CKM.4 FDP_ITC.1 supports. FCS_CKM.4 supports keys on volatile memory. Since the modification and destruction of keys on nonvolatile memory are prohibited, FCS_CKM.4 does not apply to. FCS_COP.1h [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 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] FCS_CKM.4 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] FCS_CKM.4 FDP_ITC.1 supports. FCS_CKM.4 supports keys on volatile memory. Since the modification and destruction of keys on nonvolatile memory are prohibited, FCS_CKM.4 does not apply to. FCS_COP.1sb [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1bandFCS_CKM.4supporttosatisfythedepen- dencies. FCS_COP.1n [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FDP_ITC.1 supports. FCS.CKM.4 supports on keys on volatile memory. Since the modification and destruc- tion of keys on nonvolatile memory are prohibited, FCS_CKM.4 does not apply to. FCS_COP.1e [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1e and FCS_CKM.4 support to satisfy the depen- dencies. FCS_COP.1hp [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 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] FCS_CKM.4 FCS_CKM.1pandFCS_CKM.4supporttosatisfythedepen- dencies. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 54 SECURITY TARGET SFR Dependencies Support of the Dependencies FCS_COP.1sp [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1pandFCS_CKM.4supporttosatisfythedepen- dencies. FCS_RND.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 con- figuration, but not created in the operational environ- mentof the TOE.Therefore, FMT_MSA.3 relatedto filecre- ation does not apply to. FDP_ACF.1b FDP_ACC.1 FMT_MSA.3 FDP_ACC.1b supports. Objects are created at initial con- figuration, but not created in the operational environ- mentof the TOE.Therefore, FMT_MSA.3 relatedto filecre- ation does not apply to. FDP_ACF.1p FDP_ACC.1 FMT_MSA.3 FDP_ACC.1p supports. Objects are created at initial con- figuration, but not created in the operational environ- mentof the TOE.Therefore, FMT_MSA.3 relatedto filecre- ation 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 con- figuration, but not created in the operational environ- mentof the TOE.Therefore, FMT_MSA.3 relatedto filecre- ation 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. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 55 SECURITY TARGET SFR Dependencies Support of the Dependencies 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.8: Dependencies for SFRs 6.3.2 Security Assurance Requirements Rationale InenvironmentsthattheTOEisused, communicationwithinspectionterminalsthattheBAC procedure is used for is assumed. The BAC procedure is assumed to thwart attackers pos- sessing an Enhanced-Basic attack potential, and AVA_VAN.3 is adopted as the security assur- ance 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 as- surance requirement to provide stricter protection of development information used for an attack means. 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.6 are all satisfied because ALC_DVS.2 does not have dependencies on other com- ponents. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 56 SECURITY TARGET 7 TOE Summary Specification 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 compos- ing the TSF. 7.1.1 TOE Security Functions from Hardware (IC) and Cryptographic Li- brary 7.1.1.1 F.IC_CL: Security Functions of the Hardware (IC) and Cryptographic Library This Security Function covers the security functions of the hardware (IC) as well as of the cryptographic library. According to the Certification Report the Security Target of the hard- ware [ST_ST31G480] defines the following Security Services: • Physical tampering protection. (STSS_PTP) • Initialization of the hardware platform and attributes. (STSS_IPA) • Secure management of the lifecycle. (STSS_MLC) • Logical integrity of the product. (STSS_LI) • Memory firewalls. (STSS_MF) • Management of security violations. (STSS_MSV) • Unobservability of sensitive data. (STSS_USD) • Loading and management of the Flash memory. (STSS_LMF) • Support for symmetric key cryptography. (STSS_CS) • Support for asymmetric key cryptography. (STSS_CS) • Support for random number generation. (STSS_CS) • TheoptionalserviceofacryptographiclibraryNesLib6.2.1offeringDES,AES,RSA,SHA, ECC,andDRGBimplementationaswellasthesecuregenerationofprimenumbersand RSA keys. (STSS_CS) The acronyms in parenthesis (STSS_.. meaning ST Security Service) were added for eas- ier referencing and are used in the following text of this ST. In addition to the services in the Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 57 SECURITY TARGET list above the hardware supports AES and DES/3DES which are also referenced via STSS_CS (Cryptographic Support). 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; do- ing key management by the Manufacturer or on behalf of him or by the IC Sheet Manu- facturer or on behalf of him(see F.Management) 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 Man- ufacturer identified with the correct authentication key (see F.Management) 6. AccessControlinphase4(operationaluse): ReadingofuserdataonlybyanAuthorized 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. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 58 SECURITY TARGET – 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-2 [FIPS_140-2] (or better) and a new BAC authentication is required. – Keys in transient memory are overwritten after usage. • 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-2 [FIPS_140-2] (or better) and a new PACE authentication 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. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 59 SECURITY TARGET 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 deter- mines the security attributes. The IC Sheet Manufacturer performs the following steps: • Writing of the (new) transport key, the readout key and the Active Authentication in- formation 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 • 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, supplied by F.IC_CL) 7.1.2.5 F.Verification TOE internal functions ensures correct operation. 7.2 Assurance Measures The assurance measures fulfilling the requirements of EAL4 augmented with ALC_DVS.2 are given in table 7.1. Measure Measure ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 60 SECURITY TARGET Measure Measure 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_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.4 F.Identification_Authentication FCS_COP.1a F.IC_CL 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 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 61 SECURITY TARGET SFR TSFs FCS_RND.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. The SFR FCS_CKM.1b requires session key generation algorithm in Basic Access Control, which is supplied by F.IC_CL (STSS_CS(3DES)). The SFR FCS_CKM.1p requires session key generation algorithm in PACE, which is sup- plied by F.IC_CL (STSS_CS(AES)). The SFR FCS_CKM.1e requires the ECDH algorithm. This is provided by the cryptographic library function F.IC_CL (STSS_CS(ECC)). The SFR FCS_CKM.4 requires the destroying of cryptographic keys. This is done in F.Identification_Authentication. The SFR FCS_COP.1a requires ECDSA. F.IC_CL (STSS_CS(ECC)) provides the functions. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 62 SECURITY TARGET The SFR FCS_COP.1h requires SHA-256 and SHA-384. F.IC_CL (STSS_CS(SHA)) and F.Crypto provide these hash algorithms. The SFR FCS_COP.1hb requires SHA-1. F.IC_CL (STSS_CS(SHA)) and F.Crypto provide this hash algorithm. The SFR FCS_COP.1mb requires DES/Triple-DES. F.IC_CL (STSS_CS(SHA)) 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 (STSS_CS(3DES)) and F.Crypto. The SFR FCS_COP.1n requires AES, which is supplied by F.IC_CL (STSS_CS(AES)) 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 (STSS_CS(ECC)). The SFR FCS_COP.1hp requires SHA-1 and SHA-256. F.IC_CL (STSS_CS(SHA)) and F.Crypto provide these hash algorithms. The SFR FCS_COP.1mp requires AES in CMAC mode. This is provided in F.IC_CL (STSS_CS(AES)) 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 (STSS_CS(AES)) and F.Crypto. The SFR FCS_RND.1 requires the generation of random numbers which is provided by F.IC_CL (STSS_CS) 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 pri- vate key file. This is done by F.Access_Control. 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 be- half 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 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 63 SECURITY TARGET 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 be- half 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 authentication with the transport key and permanently stop authentication with the trans- port 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. 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. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 64 SECURITY TARGET The SFR FMT_MOF.1 requires the management of the behaviors of security func- tions. The the ability to disable and enable the function Basic access control shall be re- stricted to the authorized personnel of the passport issuing authorities. This is done by F.Access_Control and F.Management. The SFR FMT_MTD.1 requires the management of TSF data. The ability to modify the transport key shall be restricted to the authorized personnel of the passport issuing author- ities. 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 (STSS_USD). The SFR FPT_PHP.3 requires the enforcement to resistance to physical attacks. This is provided by F.IC_CL (STSS_MLC, STSS_USD, STSS_PTP, STSS_LI). 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 Target of ST31G480 D01[ST_ST31G480]. Note 43: The optional technology MIFARE DESFire EV1 and MIFARE Plus X are not used by the TOE, the corresponding hardware security services are not relevant for the composite Security Target. Also the security problems, objectives and requirements concerning these technologies are not relevant for the composite ST. 7.4.1 Relevance of Hardware TSFs Table 7.3 shows the relevance of the hardware security functions for the composite Security Target. HW-TSFs1 Description Relevant Not relevant STSS_PTP Physical tampering protection x STSS_IPA Initialization of the hardware platform and attributes x STSS_MLC Secure management of the lifecycle x STSS_LI Logical integrity of the product x STSS_MF Memory firewalls x 1 See definition in 7.1.1.1 Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 65 SECURITY TARGET STSS_MSV Management of security violations x STSS_USD Unobservability of sensitive data x STSS_LMF Loading and management of the Flash memory x STSS_CS (3DES) Cryptographic Support x STSS_CS (AES) Cryptographic Support x STSS_CS (RSA) Cryptographic Support x STSS_CS (ECC) Cryptographic Support x STSS_CS (SHA) Cryptographic Support x STSS_CS (TRNG) Cryptographic Support x Table 7.3: Relevance of Hardware TSFs for Composite ST 7.4.2 Compatibility: TOE Security Environment 7.4.2.1 Assumptions The following list shows that the assumptions of the hardware are either not relevant for this Security Target or are covered by appropriate security objectives. The assumptions for the TOE are not relevant for the hardware ST. • Assumptions of the TOE – A.Administrative_Env: no conflict – A.PKI: no conflict • Assumptions of the hardware – A.Process-Sec-IC (Protection during Packaging, Finishing and Personalization): no conflict – A.Resp-Appl (Treatment of User Data): covered by security objective O.Logical_Attack of the TOE ST 7.4.2.2 Threats The threats of the TOE and the hardware can be mapped (see Table 7.4) or are not relevant. They show no conflicts between each other. • Threats of the TOE – T.Copy: no conflict – T.Logical_Attack: matches T.Abuse-Func of the hardware ST – T.Communication_Attack: no conflict – T.Physical_Attack: matches T.Phys-Manipulation, T.Phys-Probing, T.Malfunction, T.Mem-Access, T.Leak-Inherent and T.Leak-Forced of the hardware ST • Threats of the hardware – T.Phys-Manipulation (Physical Manipulation): matches T.Physical_Attack of the TOE ST Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 66 SECURITY TARGET – T.Phys-Probing (Physical Probing): matches T.Physical_Attack of the TOE ST – T.Malfunction (Malfunction due to Environmental Stress): matches T.Physical_Attack of the TOE ST – T.Leak-Inherent (Inherent Information Leakage): matches T.Physical_Attack of the TOE ST – T.Leak-Forced (Forced Information Leakage): matches T.Physical_Attack of the TOE ST – T.Abuse-Func (Abuse of Functionality): matches T.Logical_Attack of the TOE ST – T.RND (Deficiency of Random Numbers): basic threat concerning especially the BAC/PACE functionality of the TOE; no conflict – T.Mem-Access (Memory Access Violation): matches T.Physical_Attack of the TOE ST Hardware threats TOE threats T.Logical_Attack T.Physical_Attack T.Phys-Manipulation x T.Phys-Probing x T.Malfunction x T.Leak-Inherent x T.Leak-Forced x T.Abuse-Func x T.Mem-Access x Table 7.4: Mapping of hardware to TOE threats (only threats that can be mapped directly are shown) 7.4.2.3 Organizational Security Policies The organizational security policies of the TOE and the hardware have no conflicts between each other. They are shown in the following list. • Organizational Security Policies of the TOE – P.BAC: not applicable – P.PACE: not applicable – P.Authority: not applicable – P.Data_Lock: not applicable – P.Prohibit: not applicable – P.Personalization: not applicable – P.Disable_BAC: not applicable Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 67 SECURITY TARGET • Organizational Security Policies of the hardware – P.Process-TOE (Identification during TOE Development and Production): not ap- plicable – P.Add-Functions (Additional Specific Security Functionality): not applicable – P.Lim_Block_Loader (Limiting and Blocking the Loader Functionality): not appli- cable – P.Controlled-ES-Loading (Controlled loading of the Security IC Embedded Soft- ware): not applicable – P.Resp-Appl (Treatment of user data): not applicable 7.4.2.4 Security Objectives • Security objectives for the TOE – O.AA: no conflicts – O.Logical_Attack: matches O.Add-Functions of the hardware ST – O.Physical_Attack: matches O.Phys-Manipulation, O.Phys-Probing, O.Mal- function, O.Abuse-Func, O.Mem-Access, O.Leak-Inherent and O.Leak-Forced of the hardware ST – O.BAC: no conflicts – O.PACE: no conflicts – O.Authority: matches O.Identification of the hardware ST – O.Data_Lock: no conflicts – O.Disable_BAC: no conflicts • Security Objectives for the hardware – O.Phys-Manipulation (Protection against Physical Manipulation): covered by O.Physical_Attack of the TOE ST – O.Phys-Probing (Protection against Physical Probing): covered by O.Physical_Attack of the TOE ST – O.Malfunction (Protection against Malfunctions): covered by O.Physical_Attack of the TOE ST – O.Leak-Inherent (Protection against Inherent Information Leakage): covered by O.Physical_Attack of the TOE ST – O.Leak-Forced (Protection against Forced Information Leakage): covered by O.Physical_Attack of the TOE ST – O.Abuse-Func (Protection against Abuse of Functionality): covered by O.Physical_Attack of the TOE ST – O.Identification (TOE Identification): covered by O.Authority of the TOE ST – O.RND (Random Numbers): basic objective for the security of the TOE; no con- flicts with any security objective of the TOE – O.Cap_Avail_Loader (Capability and availability of the Loader): no conflicts – O.Add-Functions (Additional specific security functionality): covered by O.Logical_Attack of the TOE ST – O.Mem-Access (Area based Memory Access Control): covered by O.Physical_Attack of the TOE ST – O.Controlled-ES-Loading (Controlled loading of the Security IC Embedded Soft- ware): no conflicts Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 68 SECURITY TARGET – OE.Lim_Block_Loader (Limitation of capability and blocking the Loader): no con- flicts – OE.Resp-Appl (Treatment of User Data): no conflicts – OE.Process-Sec-IC (Protection during Packaging, Finishing and Personalization): no conflicts Hardware objectives TOE objectives O.Logical_Attack O.Physical_Attack O.Authority O.Phys-Manipulation x O.Phys-Probing x O.Malfunction x O.Leak-Inherent x O.Leak-Forced x O.Abuse-Func x O.Identification x O.Add-Functions x O.Mem-Access x Table 7.5: Mapping of hardware to TOE security objectives including those of the envi- ronment (only those that can be mapped directly are shown) 7.4.2.5 Security Requirements None of the SFRs show any conflicts between each other. • Relevant Security Requirements of the TOE – FCS_CKM.1b (Cryptographic key generation (BAC)): no conflicts – FCS_CKM.1p (Cryptographic key generation (PACE, session keys)): no conflicts – FCS_CKM.1e (Cryptographic key generation (PACE, ephemeral key pairs)): no con- flicts – FCS_CKM.4 (Cryptographic key destruction): no conflicts – FCS_COP.1a (Cryptographic operation (Active Authentication, signature genera- tion)): matches FCS_COP.1/ECC of the hardware ST – FCS_COP.1h (Cryptographic operation (Active Authentication, hash functions)): matches FCS_COP.1/SHA of the hardware ST – FCS_COP.1hb (Cryptographic operation (BAC, hash functions)): matches FCS_COP.1/SHA of the hardware ST – FCS_COP.1mb (Cryptographic operation (BAC, mutual authentication)): matches FCS_COP.1/TDES of the hardware ST – FCS_COP.1sb (Cryptographic operation (BAC, Secure Messaging)): matches FCS_COP.1/TDES of the hardware ST Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 69 SECURITY TARGET – FCS_COP.1n (Cryptographic operation (Nonce encryption)): matches FCS_COP.1/AES of the hardware ST – FCS_COP.1e(Cryptographicoperation(Keyagreement)): matchesFCS_COP.1/ECC of the hardware ST – FCS_COP.1hp (Cryptographic operation (PACE, hash functions)): matches FCS_COP.1/SHA of the hardware ST – FCS_COP.1mp (Cryptographic operation (PACE, mutual authentication)): matches FCS_COP.1/AES of the hardware ST – FCS_COP.1sp (Cryptographic operation (PACE, Secure Messaging)): matches FCS_COP.1/AES of the hardware ST – FCS_RND.1 (Random number generation): matches FCS_RNG.1 of the hardware ST – FDP_ACC.1a (Subset access control (Issuance procedure)): no conflicts – FDP_ACC.1b (Subset access control (BAC)): no conflicts – FDP_ACC.1p (Subset access control (PACE)): no conflicts – FDP_ACF.1a (Security attribute based access control (Issuance procedure)): no conflicts – FDP_ACF.1b (Security attribute based access control (BAC)): no conflicts – FDP_ACF.1p (Security attribute based access control (PACE)): no conflicts – FDP_ITC.1 (Import of user data without security attributes): no conflicts – FDP_UCT.1b (Basic data exchange confidentiality (BAC)): no conflicts – FDP_UCT.1p (Basic data exchange confidentiality (PACE)): no conflicts – FDP_UIT.1b (Data exchange integrity (BAC)): no conflicts – FDP_UIT.1p (Data exchange integrity (PACE)): no conflicts – FIA_AFL.1a (Authentication failure handling (Active Authentication Information Access Key)): no conflicts – FIA_AFL.1d (Authentication failure handling (Transport key)): no conflicts – FIA_AFL.1r (Authentication failure handling (Readout key)): no conflicts – FIA_UAU.1 (Timing of authentication): no conflicts – FIA_UAU.4 (Single-use authentication mechanism): no conflicts – FIA_UAU.5 (Multiple authentication mechanisms): no conflicts – FIA_UID.1 (Timing of identification): no conflicts – FMT_MOF.1 (Management of the behaviors of security functions): no conflicts – FMT_MTD.1 (Management of TSF data): no conflicts – FMT_SMF.1 (Specification of management functions): no conflicts – FMT_SMR.1 (Security roles): no conflicts – FPT_EMS.1 (TOE emanation): Matches FDP_ITT.1, FDP_IFC.1 and FPT_ITT.1 of the hardware ST – FPT_PHP.3 (Resistance to physical attack): matches FPT_PHP.3 of the hardware ST – FTP_ITC.1 (Inter-TSF trusted channel): no conflicts • Security Requirements of the hardware (SFRs that cannot be mapped directly to SFRs of the TOE, but are used implicitly, are underlined) – FRU_FLT.2 (Limited fault tolerance): used implicitly, no conflicts to the TOE SFRs – FPT_FLS.1 (Failure with preservation of secure state): used implicitly, no conflicts to the TOE SFRs Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 70 SECURITY TARGET – FMT_LIM.1/Test (Limited capabilities - Test): used implicitly, no conflicts to the TOE SFRs – FMT_LIM.2/Test (Limited capabilities - Test): used implicitly, no conflicts to the TOE SFRs – FMT_LIM.1/Loader (Limited capabilities - Loader): not applicable – FMT_LIM.2/Loader (Limited availability - Loader): not applicable – FAU_SAS.1 (Audit storage): used implicitly, no conflicts to the TOE SFRs – FDP_SDC.1 (Stored data confidentiality): no conflicts to the TOE SFRs – FDP_SDI.2 (Stored data integrity monitoring and action): no conflicts to the TOE SFRs – FPT_PHP.3 (Resistance to physical attack): matches FPT_PHP.3 of the TOE ST – FDP_ITT.1 (Basic internal transfer protection): matches FPT_EMS.1 of the TOE ST – FPT_ITT.1 (Basic internal TSF data transfer protection): matches FPT_EMS.1 of the TOE ST – FDP_IFC.1 (Subset information flow control): matches FPT_EMS.1 of the TOE ST – FCS_RNG.1 (Random number generation): matches FCS_RND.1 of the TOE ST – FCS_COP.1/TDES (Cryptographic operation (EDES)): matches FCS_COP.1sb of the TOE ST – FCS_COP.1/AES (Cryptographic operation (AES)): matches FCS_COP.1n, FCS_COP.1mp and FCS_COP.1sp of the TOE ST – FCS_COP.1/RSA (Cryptographic operation (RSA)): not relevant – FCS_COP.1/ECC (Cryptographic operation (ECC)): matches FCS_COP.1a and FCS_COP.1e of the TOE ST – FCS_COP.1/SHA (Cryptographic operation (SHA)): matches FCS_COP.1h, FCS_COP.1hb and FCS_COP.1hp of the TOE ST – FCS_CKM.1/Primegeneration(Cryptographickeygeneration(Primegeneration)): not relevant – FCS_CKM.1/RSA key generation (Cryptographic key generation (RSA key genera- tion)): not relevant – FDP_ACC.2/Memories (Complete access control): used implicitly, no conflicts to the TOE SFRs – FDP_ACF.1/Memories (Security attribute based access control): used implicitly, no conflicts to the TOE SFRs – FMT_MSA.1/Memories (Management of security attributes): used implicitly, no conflicts to the TOE SFRs – FMT_MSA.3/Memories(Staticattributeinitialization): usedimplicitly, noconflicts to the TOE SFRs – FMT_SMF.1/Memories (Specification of Management Functions): used implicitly, no conflicts to the TOE SFRs – FDP_ITC.1/Loader (Import of user data without security attributes - Loader): not applicable – FDP_ACC.1/Loader (Subset access control - Loader): not applicable – FDP_ACF.1/Loader (Security attribute based access control - Loader): not appli- cable – FMT_MSA.1/Loader (Management of security attribute - Loader): not applicable – FMT_MSA.3/Loader (Static attribute initialization - Loader): not applicable Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 71 SECURITY TARGET – FMT_SMR.1/Loader (Security roles - Loader): not applicable – FIA_UID.1/Loader (Timing of identification - Loader): not applicable – FMT_SMF.1/Loader (Specification of management functions - Loader): not appli- cable Hardware SFRs TOE SFRs FCS_COP.1a FCS_COP.1h FCS_COP.1hb FCS_COP.1mb FCS_COP.1sb FCS_COP.1n FCS_COP.1e FCS_COP.1hp FCS_COP.1mp FCS_COP.1sp FCS_RND.1 FPT_EMS.1 FPT_PHP.3 FPT_PHP.3 x FDP_ITT.1 x FPT_ITT.1 x FDP_IFC.1 x FCS_RNG.1 x FCS_COP.1/TDES x x x FCS_COP.1/AES x x x FCS_COP.1/ECC x x FCS_COP.1/SHA x x x Table 7.6: Mapping of hardware to TOE SFRs (only SFRs that can be mapped directly are shown). 7.4.2.6 Assurance Requirements The level of assurance of the • TOE is EAL4 augmented with ALC_DVS.2. • Hardware is EAL5 augmented with ADV_IMP.2, ADV_TDS.5, ALC_CMC.5, ALC_DVS.2, ALC_FLR.1, ALC_TAT.3, ASE_TSS.2 and AVA_VAN.5. This shows that the Assurance Requirements of the TOE is matched or exceeded by the Assurance Requirements of the hardware. There are no conflicts. 7.4.3 Conclusion Overall no contradictions between the Security Targets of the TOE and the hardware can be found. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 72 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. 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 Ac- cess 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 im- plemented in addition to Basic Access Control, i.e. • States MUST NOT implement PACE without implementing Basic Access Control if global interoperability is required. • Inspection Systems SHOULD implement and use PACE if pro- vided by the MRTD chip. Passport manufacturer An organization, which manufactures passport booklets and config- ures 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 73 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 public key is transmitted to an external device trying to authenticate the TOE and the TOE is authenticated through cryptographic calcu- lation by the challenge response system using the private key, which has been kept a secret in the TOE. The Active Authentication proce- dure has been standardized by ICAO. Passive Authentication Security mechanism, by which the digital signature of the passport is- suing authority is applied to personal information data stored in the TOE, and the authenticity of data read from the TOE is verified by us- ing 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 74 SECURITY TARGET Bibliography [AGD] User Guidance – Xaica-α PLUS ePassport, MaskTech International GmbH, Version 1.1, 2020-07-17. [ANSI_X9.62] ANSI X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), Inc. Accredited Standards Committee X9, 2005-11-16. [BSI_AIS31v3] AIS 31, Version 3, Anwendungshinweise und Interpretationen zum Schema – Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, BSI, 2013-05-15. [BSI_TR-03110-1] TR-03110-1, Technical Guideline TR-03110-1: Advanced Security Mech- anisms for Machine Readable Travel Documents and eIDAS Token – 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- nismsforMachineReadableTravelDocumentsandeIDASToken-Part 3 – Common Specifications, BSI, Version 2.21, 2016-12-21. [BSI_TR-03111] TR-03111, Technical Guideline TR-03111: Elliptic Curve Cryptography, BSI, Version 2.1, 2018-06-01. [BSI_TR-03116-2] TR-03116-2, Technische Richtlinie – Kryptographische Verfahren für Projekte der Bundesregierung - Teil 2 – Hoheitliche Ausweisdoku- mente, BSI, Stand 2018, 2018-04-12. [CC_Part1] CCMB-2017-04-001, Version 3.1, Revision 5, Common Criteria for In- formation Technology Security Evaluation, Part 1: Introduction and General Model, Common Criteria Maintenance Board, 2017-04. [CC_Part2] CCMB-2017-04-002, Version3.1, Revision5, CommonCriteriaforInfor- mation Technology Security Evaluation, Part 2: Security Functional Components, Common Criteria Maintenance Board, 2017-04. [CC_Part3] CCMB-2017-04-003, Version 3.1, Revision 5, Common Criteria for In- formationTechnologySecurityEvaluation, Part3: SecurityAssurance Components, Common Criteria Maintenance Board, 2017-04. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 75 SECURITY TARGET [CC_PartEM] CCMB-2017-04-004, Version 3.1, Revision 5, Common Methodology for Information Technology Security Evaluation, Evaluation Method- ology, Common Criteria Maintenance Board, Version 3.1, Revision 5, 2017-04. [CC_PP-0056-V2] BSI-CC-PP-0056-V2-2012, Common Criteria Protection Profile / Ma- chine Readable Travel Document with ’ICAO Application’, Extended Access Control with PACE, BSI, Version 1.3.2, 2012-12-05. [CC_PP-0068-V2] BSI-CC-PP-0068-V2-2011, Common Criteria Protection Profile / Ma- chine Readable Travel Document using Standard Inspection Proce- dure with PACE (ePass_PACE PP), BSI, Version 1.0, 2011-11-02. [CC_PP-0084] BSI-CC-PP-0084-2014, Security IC Platform Protection Profile with Augmentation Packages, BSI, 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-2] FIPS PUB 140-2, Security Requirements for Cryptographic Modules, National Institute of Standards and Technology, 2001-05. [FIPS_180-4] FIPS PUB 180-4, Secure Hash Standard, National Institute of Stan- dards and Technology, 2012-03. [FIPS_197] FIPS PUB 197, ADVANCED ENCRYPTION STANDARD (AES), National In- stitute of Standards and Technology, 2001-11-26. [ICAO_9303] ICAO Doc 9303, Machine Readable Travel Documents, ICAO, 2015. [ICAO_SAC] TR-SAC, Supplemental Access Control for Machine Readable Travel Documents, ICAO, Version 1.1, 2014-04-15. [ISO_10116] ISO/IEC 10116:2006, Information technology – Security techniques – Modes of operation for an n-bit block cipher, ISO/IEC, 2006-02-01. [ISO_7816] ISO/IEC7816:2008, Informationtechnology–Identificationcards–In- tegrated circuit cards – Multipart Standard, ISO/IEC, 2008. [ISO_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, Joint Interpretation Working Group, Version 3.0, 2019-04. [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 Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, National In- stitute of Standards and Technology, 2005-05. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 76 SECURITY TARGET [NIST_SP800-67] NISTSpecialPublication800-67, RecommendationfortheTripleData Encryption Algorithm (TDEA) Block Cipher, version 1.1, NIST. [NIST_SP800-90a-R1] NIST Special Publication 800-90A Rev. 1, Recommendation for Ran- dom Number Generation Using Deterministic Random Bit Genera- tors, National Institute of Standards and Technology, 2015-06. [ST_ST31G480] STMicroelectronics, ST31G480 D01 including optional cryptographic library NESLIB, and optional technologies MIFARE® DESFire® EV1 and MIFARE Plus® X – Security Target for composition, ANSSI-CC-2019/12, 2019-03-05. Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 77 SECURITY TARGET 9 Revision History Version Date Author Changes 1.0 2020-04-09 Gudrun Schürer First public version 1.1 2020-07-17 Gudrun Schürer Revised cryptographic overview in appendix A Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 78 SECURITY TARGET 10 Contact MASKTECH GMBH – Headquarters Nordostpark 45 Phone +49 911 955149 0 D-90411 Nuernberg Fax +49 911 955149 7 Germany Email support@masktech.de MASKTECH GMBH – Support Bahnhofstr. 13 Phone +49 831 5121077 1 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 Homepage www.nttdata.com Koto-ku Tokyo Japan Xaica-α PLUS ePassport on MTCOS Pro 2.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 79 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 mes- sage), 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 key pairs), 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 80 SECURITY TARGET Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments ST-Reference 7 Key Derivation Cryptographic key gen- eration (BAC) [BSI_TR-03110-1], [ICAO_9303], part11, 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], part11, 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, [ISO_10116], sec. 7 (CBC) - [BSI_TR-03110-3] [ICAO_9303] FCS_COP.1n 12 Cryptographic Primitive PTG.3 Random num- ber generator (PTG.2 and cryptographic post-processing) [BSI_AIS31v3], [NIST_SP800-90a-R1], sec. 10.2, 10.3.2 - [BSI_TR-03116-2] FCS_RND.1 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.5 with SAC (BAC+PACE) and Active Authentication / ST31G480 D01, Version 1.1 81