cv act ePasslet Suite v2.1 – Java Card ap- plet configuration providing Machine Readable Travel Document with „ICAO Application”, Extended Access Control with PACE Security Target BSI-DSZ-CC-0913 Common Criteria / ISO 15408 EAL 4+ Document Version 1.5 • 2014-10-01 cv cryptovision GmbH • Munscheidstr. 14 • 45886 Gelsenkirchen • Germany www.cryptovision.com • info@cryptovision.com • +49-209-167-2450 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 2 of 98 Content 1 Introduction............................................................................................................................................ 5 1.1 ST/TOE Identification.....................................................................................................................................5 1.2 ST overview ...................................................................................................................................................5 1.3 TOE overview.................................................................................................................................................6 2 Conformance claims ............................................................................................................................. 13 2.1 CC conformance ..........................................................................................................................................13 2.2 PP Claim.......................................................................................................................................................13 2.3 Statement of Compatibility concerning Composite Security Target ...........................................................14 3 Security problem definition.................................................................................................................. 28 3.1 Introduction.................................................................................................................................................28 3.2 Assumptions ................................................................................................................................................30 3.3 Threats.........................................................................................................................................................30 3.4 Organizational security policies...................................................................................................................32 4 Security objectives................................................................................................................................ 33 4.1 Security Objectives for the TOE...................................................................................................................33 4.2 Security Objectives for the Operational Environment ................................................................................34 4.3 Security Objective Rationale .......................................................................................................................35 5 Extended Components Definition......................................................................................................... 39 5.1 Definition of the Family FIA_API..................................................................................................................39 6 Security Requirements.......................................................................................................................... 40 6.1 Security Definitions .....................................................................................................................................40 6.2 Security Functional Requirements for the TOE ...........................................................................................42 6.3 Security Assurance Requirements for the TOE............................................................................................66 6.4 Security Requirements Rationale ................................................................................................................66 7 TOE summary specification (ASE_TSS) ................................................................................................. 73 7.1 TOE Security Functionality...........................................................................................................................73 7.2 TOE summary specification rationale..........................................................................................................85 8 Crypto disclaimer.................................................................................................................................. 88 References..................................................................................................................................................... 91 Common Criteria........................................................................................................................................................91 Protection Profiles .....................................................................................................................................................91 TOE and Platform References....................................................................................................................................91 ICAO specifications ....................................................................................................................................................92 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 3 of 98 Cryptography .............................................................................................................................................................92 Glossary ......................................................................................................................................................... 94 Version Control Version Date Author Changes to Previous Version 0.1 2012-11-26 Benjamin Drisch Initial version based on PP0056v2 and Security Target for BSI-DSZ-CC-0799 0.2 2013-03-18 Thomas Zeggel Chapter 2.2 added, additional minor changes and correc- tions. 0.3 2013-09-04 Thomas Zeggel Changes and corrections:  FCS_COP.1/CA_ENC  Changes according to OR1  Product and TOE naming modified 0.4 2013-09-26 Thomas Zeggel Added specified elliptic curve key lengths (224, 256, 320 bit) and elliptic curves (based on the SFR of the Java Card plat- form). Constraint “as the only application that has access to the contactless interface” deleted. TOE short name changed to “ePasslet/MRTD-EACv1-SAC”. Additional small changes and corrections. 0.5 2013-10-08 Thomas Zeggel Changes according to OR from TüvIT Change of short TOE name from ePasslet/MRTD-EACv1-SAC to ePasslet2.0/MRTD-EACv1-SAC 0.6 2013-10-25 Thomas Zeggel Changes based on OR 0912_EAC_OR_ASE_3 from TüvIT 0.7 2013-10-28 Thomas Zeggel Changes based on OR 0913_OR_ASE_3.1from TüvIT 0.8 2013-10-29 Thomas Zeggel Changes based on OR 0913_OR_ASE_5 from TüvIT 0.9 2013-10-31 Thomas Zeggel Typing error (AIS32 -> AIS32) corrected. 1.0 2014-06-18 Thomas Zeggel Changes because of results of the platform re-assessment (crypto library) and changes of the TOE (new version 2.1 in- stead of version 2.0). Crypto Disclaimer added as addi-tional chapter 8. Objectives for the environment added with respect to the Java card platform. Expressions that will be subject to changes due to the CC maintenance process of the NXP platform are marked in yel- low. 1.1 2014-07-24 Thomas Zeggel Changes according to the observation report 7 added. 1.2 2014-08-22 Thomas Zeggel Changes according to the results of the AVA kickoff (14th Au- guts 2014) and the OR from 6th of August 2014. 1.3 2014-09-02 Thomas Zeggel Changes according to the OR from 25th of August 2014. JCOP and CL reference updated. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 4 of 98 1.4 2014-09-29 Thomas Zeggel Changes according to the OR from 26th of September 2014. 1.5 2014-10-01 Thomas Zeggel Changes according to the OR from the 30th of September (footnote 2, references). cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 5 of 98 1 Introduction 1.1 ST/TOE Identification Title: cv act ePasslet Suite v2.1 – Java Card applet configuration providing Ma- chine Readable Travel Document with „ICAO Application”, Extended Access Control with PACE – Security Target Version: v1.4 Origin: cv cryptovision GmbH Compliant to: Common Criteria Protection Profile - Machine Readable Travel Document with „ICAO Application”, Extended Access Control with PACE (EAC PP) (BSI-CC-PP0056v2) [PP0056v2] Product identification: cv act ePasslet Suite v2.1 TOE identification: cv act ePasslet Suite v2.1 – Java Card applet configuration providing Ma- chine Readable Travel Document with „ICAO Application”, Extended Access Control with PACE Short TOE name: ePasslet2.1/MRTD-EACv1-SAC ROM identification value: “D4B949” or “784C6C”1 Javacard OS platform: NXP JCOP 2.4.2 R3 [ZertJCOP] Cryptographic library: [ZertCL] Security controller: [ZertIC] TOE documentation: Administration and user guide [Guidance] 1.2 ST overview This document contains the Security Target for MRTD chips based on the EACv2-SAC application of the cv act ePassslet Suite. The cv act ePasslet Suite is a set of Javacard applications intended to be used exclusively on the NXP JCOP Javacard OS platforms, which are certified according to CC EAL 5+ [ZertJCOP]. The cv act ePasslet Suite as well as the NXP JCOP operating system are provided within the ROM mask of a smart card chip based on the NXP P5CD security controller, which is itself certified according to CC EAL 5+ [ZertIC], and certified cryptographic library [ZertCL]. This Security Target defines the security objectives and requirements for the contact based / contactless smart card of machine readable travel documents based on the requirements and recommendations of the International Civil Aviation Organization (ICAO). It addresses the advanced security methods Password Au- thenticated Connection Establishment, Extended Access Control, and Chip Authentication similar to the Ac- tive Authentication in ‘ICAO Doc 9303’ [ICAODoc]. This security target claims strict conformance to the Protection Profile Machine Readable Travel Document with “ICAO Application”, Extended Access Control with PACE (EAC PP) (BSI-CC-PP0056v2) [PP0056v2] and Protection Profile Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2-2011 [PP0068]. The main objectives of this ST are: 1The cv act ePasslet Suite v2.1 is produced on one specific hardware (P5Cx145V0v, cf. [ZertIC]) that differs only with respect to the memory, interface configuration and the additional biometry provider (not used by the TOE and with non-interfering security functionality). The two different possible biometry providers lead to the two different ROM identification values. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 6 of 98  to introduce TOE and the MRTD application,  to define the scope of the TOE and its security features,  to describe the security environment of the TOE, including the assets to be protected and the threats to be countered by the TOE and its environment during the product development, produc- tion and usage.  to describe the security objectives of the TOE and its environment supporting in terms of integrity and confidentiality of application data and programs and of protection of the TOE.  to specify the security requirements which includes the TOE security functional requirements, the TOE assurance requirements and TOE security functionalities. The assurance level for the TOE is CC EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. 1.3 TOE overview 1.3.1 Overview of cv act ePasslet Suite cryptovision’s cv act ePasslet Suite is a set of Java Card applets for e-ID document applications built upon an underlying core library. The following Table 1 provides an overview of the individual applications included in cv act ePasslet Suitev2.1: Product / Application Specification Configuration ICAO MRTD application with Basic Access Con- trol (BAC) ICAO Doc 9303 ePasslet2.1/MRTD-BAC ICAO MRTD application with Basic and Supplemental Access Control (BAC/SAC) ICAO Doc 9303, TR03110v2.11 ePasslet2.1/MRTD-BAC- SAC ISO File System application ISO 7816 ePasslet2.1/ISO-FS International Driving License application with Basic Access Protection (BAP) ISO 18013 ePasslet2.1/IDL-Basic International Driving License application with Extended Access Protection (EAP) ISO 18013 ePasslet2.1/IDL-Extended ICAO MRTD application with Extended and Basic Access Control (EACv1-BAC) ICAO Doc 9303, TR03110v1.11 ePasslet2.1/MRTD-EACV1- BAC ICAO MRTD application with Extended and Supplemental Access Control (EACv1-SAC) ICAO Doc 9303, TR03110v1.11, TR03110v2.11 ePasslet2.1/MRTD-EACV1- SAC eID Document application with flexible access configuration (EACv2-SAC) ICAO Doc 9303, TR03110v2.11 ePasslet2.1/EACv2-SAC EU Electronic Vehicle Registration application EU Council Directive 1999/37/EC ePasslet2.1/eVR German eID Document application ICAO Doc 9303, TR03110v2.11, TR03127 ePasslet2.1/GeID ePKI application (Secure Signature Creation Device) ISO 7816, PKCS#15 ePasslet2.1/ePKI-SSCD European Citizen Card application CEN/TS 15480-2 ePasslet2.1/EuCC EU Electronic Residence Permit application TR03127 v1.15 ePasslet2.1/eRP EU Electronic Health Insurance application CWA 15974 ePasslet2.1/eHIC Table 1: Configurations of the cv act ePasslet Suite. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 7 of 98 These configurations are based on one or more predefined applets; different configurations might use the same underlying applet. While the whole applet code resides in ROM, the applets providing these different configurations are in- stantiated into EEPROM. Multiple configurations (and hence support for different applications) can be pre- sent at the same time by instantiating multiple applets with their distinct configurations with some re- strictions detailed below. A common combination could be an ICAO MRTD applet and an ePKI applet provid- ing a travel application with LDS data and EAC authentication together with a signature application. The following configurations are certified according to Common Criteria:  configuration providing Machine Readable Travel Document with „ICAO Application”, Basic Access Control (BAC),  configuration providing Machine Readable Travel Document with „ICAO Application”, Extended Access Control (EAC),  configuration providing Machine Readable Travel Document with „ICAO Application”, Extended Access Control with PACE,  configuration providing Secure Signature Creation Device with key generation. Combinations of certified and non-certified applications are possible. Via configuration the instanciated applets can be tied to the contactless and/or the contact interface, re- spectively. 1.3.2 TOE definition The Target of Evaluation (TOE) is the contactless integrated circuit chip containing components for a machine readable travel document (MRTD chip). After instantiation and configuration of the cv act ePasslet Suite as EACv1-PACE configuration it can be programmed according to ICAO Technical Report “Supplemental Access Control for Machine Readable Travel Documents” [ICAO_SAC] (which means amongst others according to the Logical Data Structure (LDS) defined in [ICAODoc]) and additionally providing the Extended Access Control according to the ‘ICAO Doc 9303’ [ICAODoc] and BSI TR-03110 [TR- 03110], respectively. The communication between terminal and chip shall be protected by Password Authenticated Connection Establishment (PACE) according to Electronic Passport using Standard Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2 [PP0068]. The TOE consists of  the circuitry of the MRTD’s chip (the integrated circuit, IC) including the contact-based interface2 with hardware for the contactless interface including contacts for the antenna,  the platform – including the IC Dedicated Software and the IC Embedded Software, namely the Java Card operation system JCOP 2.4.2 R3 by NXP – in the variants o J3E120_M65, o J3E082_M65, o J2E120_M65, and o J2E082_M65. 2 Please note that the MRTD’s chip itself (the integrated circuit, IC) is also equipped with a contact-based interface. ‘ePasslet Suite v2.1 – Java Card applet configuration providing Machine Readable Travel Docu- ment with „ICAO Application”, Extended Access Control with PACE’, is the only application that has access to the contactless interface. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 8 of 98  All platforms listed above are only configuration/interface variants and are certified within one cer- tification process (see [ZertJCOP]. They are based on a certified cryptographic library [ZertCL] and a certified hardware [ZertIC].  ePasslet Suite v2.1 – Java Card applet configuration providing Machine Readable Travel Document with „ICAO Application”, Extended Access Control with PACE,  the associated guidance documentation Administrator and User Guidance [Guidance]. The TOE’s functionality claimed by this Security Target is realized by the cv act ePasslet Suite v2.1 in the MRTD-EACv1-SAC configuration only. Some of the underlying platform variants of this composite TOE provide MIFARE functionality; please note that this functionality is out of scope of the TOE’s security functionality claimed by this Security Target. 1.3.3 TOE usage and security features for operational use This paragraph is directly based on the corresponding paragraph in the protection profile [PP0056v2]. A State or Organisation issues travel documents to be used by the holder for international travel. The trav- eller presents a travel document to the inspection system to prove his or her identity. The travel document in context of this security target contains (i) visual (eye readable) biographical data and portrait of the holder, (ii) a separate data summary (MRZ data) for visual and machine reading using OCR methods in the Machine readable zone (MRZ) and (iii) data elements on the travel document’s chip according to LDS in case of contactless machine reading. The authentication of the traveller is based on (i) the possession of a valid travel document personalised for a holder with the claimed identity as given on the biographical data page and (ii) biometrics using the reference data stored in the travel document. The issuing State or Organisation ensures the authenticity of the data of genuine travel documents. The receiving State trusts a genuine travel document of an issuing State or Organisation. For this security target the travel document is viewed as unit of (i) the physical part of the travel document in form of paper and/or plastic and chip. It presents vis- ual readable data including (but not limited to) personal data of the travel document holder (a) the biographical data on the biographical data page of the travel document surface, (b) the printed data in the Machine Readable Zone (MRZ) and (c) the printed portrait. (ii) the logical travel document as data of the travel document holder stored according to the Logical Data Structure as defined in [ICAODoc] as specified by ICAO on the contact based or contactless integrated circuit. It presents contact based / contactless readable data including (but not limited to) personal data of the travel document holder (a) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1), (b) the digitized portraits (EF.DG2), (c) the biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both1 (d) the other data according to LDS (EF.DG5 to EF.DG16) and (e) the Document Security Object (SOD). The issuing State or Organisation implements security features of the travel document to maintain the au- thenticity and integrity of the travel document and their data. The physical part of the travel document and the travel document’s chip are identified by the Document Number. The physical part of the travel document is protected by physical security measures (e.g. watermark, secu- rity printing), logical (e.g. authentication keys of the travel document’s chip) and organisational security cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 9 of 98 measures (e.g. control of materials, personalisation procedures) [ICAODoc]. These security measures can include the binding of the travel document’s chip to the travel document. The logical travel document is protected in authenticity and integrity by a digital signature created by the document signer acting for the issuing State or Organisation and the security features of the travel docu- ment’s chip. The ICAO defines the baseline security methods Passive Authentication and the optional advanced security methods Basic Access Control to the logical travel document, Active Authentication of the travel document’s chip, Extended Access Control to and the Data Encryption of sensitive biometrics as optional security meas- ure in the ICAO Doc 9303 [ICAODoc], and Password Authenticated Connection Establishment [ICAO_SAC]. The Passive Authentication Mechanism is performed completely and independently of the TOE by the TOE environment. This security target addresses the protection of the logical travel document (i) in integrity by write-only- once access control and by physical means, and (ii) in confidentiality by the Extended Access Control Mech- anism. This security target addresses the Chip Authentication Version 1 described in [TR-03110] as an alter- native to the Active Authentication stated in [ICAODoc]. If BAC is supported by the TOE, the travel document has to be evaluated and certified separately. This is due to the fact that [PP0055] does only consider extended basic attack potential to the Basic Access Control Mechanism (i.e. AVA_VAN.3). The confidentiality by Password Authenticated Connection Establishment (PACE) is a mandatory security feature of the TOE. The travel document shall strictly conform to the ‘Common Criteria Protection Profile Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE PP)’ [PP0068]. Note that [PP0068] considers high attack potential. For the PACE protocol according to [ICAO_SAC], the following steps shall be performed: (i) the travel document's chip encrypts a nonce with the shared password, derived from the MRZ resp. CAN data and transmits the encrypted nonce together with the domain parameters to the terminal. (ii) The terminal recovers the nonce using the shared password, by (physically) reading the MRZ resp. CAN data. (iii) The travel document's chip and terminal computer perform a Diffie-Hellmann key agreement together with the ephemeral domain parameters to create a shared secret. Both parties de- rive the session keys KMAC and KENC from the shared secret. (iv) Each party generates an authentication token, sends it to the other party and verifies the re- ceived token. After successful key negotiation the terminal and the travel document's chip provide private communica- tion (secure messaging) [TR-03110], [ICAO_SAC]. The protection profile requires the TOE to implement the Extended Access Control as defined in [TR-03110]. The Extended Access Control consists of two parts (i) the Chip Authentication Protocol Version 1 and (ii) the Terminal Authentication Protocol Version 1 (v.1). The Chip Authentication Protocol v.1 (i) authenticates the travel document’s chip to the inspectionsystem and (ii) establishes secure messaging which is used by Ter- minal Authentication v.1 to protect the confidentiality and integrity of the sensitive biometric reference data during their transmission from the TOE to the inspection system. Therefore Terminal Authentication v.1 can only be performed if Chip Authentication v.1 has been successfully executed. The Terminal Authen- tication Protocol v.1 consists of (i) the authentication of the inspection system as entity authorized by the receiving State or Organisation through the issuing State, and (ii) an access control by the TOE to allow reading the sensitive biometric reference data only to successfully authenticated authorized inspection sys- tems. The issuing State or Organisation authorizes the receiving State by means of certification the authen- tication public keys of Document Verifiers who create Inspection System Certificates. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 10 of 98 1.3.4 Major security features of the TOE The TOE provides the following TOE security functionalities:  TSF_Access manages the access to objects (files, directories, data and secrets) stored in the applet’s file system. It also controls write access of initialization, pre-personalization and personalization data.  TSF_Admin manages the storage of manufacturing data, pre-personalization data and personaliza- tion data.  TSF_Secret ensures secure management of secrets such as cryptographic keys. This covers secure key storage, access to keys as well as secure key deletion. These mechanisms are mainly provided by TSF_OS.  TSF_Crypto performs high level cryptographic operations. The implementation is mainly based on the Security Functionalities provided by TSF_OS. The supported crypto mechanisms are: o hashing with SHA-1, SHA-224 and SHA-256 o the Diffie-Hellman key derivation Protocol with cryptographic key sizes between 1976 and 2048 bit, and ECDH compliant with ISO 15946 with cryptographic key sizes between 256 and 320 bit with specific elliptic curves (domain parameters), o digital signature verification with ECDSA and cryptographic key sizes of 160, 192, 224, 256 and 320 bit with specified curves o digital signature generation for the optional Active Authentication in accordance with RSA and cryptographic key sizes between 1976 and 2048 bit, o encryption and decryption with AES and cryptographic key sizes 128, 192, 256 bit, o AES CMAC and cryptographic key sizes of 128, 192, 256 bit  TSF_SecureMessaging realizes a secure communication channel with MACs and encryption based on AES (128, 192 or 256 bit key length).  TSF_Auth realizes different authentication mechanisms: TSF_Auth_PACE (key lengths 256 or 320 bit), TSF_Auth_Term (Terminal Authentication), TSF_Auth_Sym with AES used for personalization and TSF_Auth_Chip to manage the capability of the TOE to authenticate itself to the terminal using the Chip Authentication Protocol.  TSF_Integrity protects the integrity of internal applet data like the Access control lists.  TSF_OS contains all security functionalities provided by the certified platform (IC, crypto library, Javacard operation system). Besides some minor additions, the cryptographic operations are pro- vided by this platform. 1.3.5 TOE life cycle The TOE life cycle is described in terms of the four life cycle phases. This paragraph is directly based on the corresponding paragraph in the protection profile [PP0056v2]; instead of the terms “ePassport” and “travel document” used in [PP0056v2] the akronym “MRTD” is used uniformly here. 1.3.5.1 Phase 1: Development (Step 1) The TOE is developed in phase 1. The IC developer develops the integrated circuit, the IC Dedicated Software and the guidance documentation associated with these TOE components. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 11 of 98 (Step 2) The software developer3 uses the guidance documentation for the integrated circuit and the guid- ance documentation for relevant parts of the IC Dedicated Software and develops the IC Embedded Soft- ware (operating system), the MRTD application and the guidance documentation associated with these TOE components. The manufacturing documentation of the IC including the IC Dedicated Software and the Embedded Soft- ware in the non-volatile non-programmable memories (ROM) is securely delivered to the IC manufacturer. The IC Embedded Software in the nonvolatile programmable memories, the MRTD application, the initiali- sation data and the guidance documentation is securely delivered to the MRTD manufacturer. 1.3.5.2 Phase 2: Manufacturing (Step 3) In a first step the TOE integrated circuit is produced containing the MRTD’s chip Dedicated Software and the parts of the MRTD’s chip Embedded Software in the nonvolatile non-programmable memories (ROM). The IC manufacturer writes the IC Identification Data onto the chip to control the IC as MRTD mate- rial during the IC manufacturing and the delivery process to the MRTD manufacturer. The IC is securely delivered from the IC manufacturer to the MRTD manufacturer. The TOE delivery according to CC is the delivery of the IC (with the application code in ROM) from the IC manufacturer to the MRTD manufacturer. If necessary the IC manufacturer adds the parts of the IC Embedded Software in the non-volatile program- mable memories (for instance EEPROM). (Step4 optional) The MRTD manufacturer combines the IC with hardware for the contact based / contactless interface in the MRTD unless the travel document consists of the card only. (Step5) The MRTD manufacturer (i) adds the IC Embedded Software or part of it in the non-volatile pro- grammable memories (for instance EEPROM or FLASH) if necessary, (ii) creates the ePassport application, and (iii) equips the MRTD’s chips with pre-personalization Data. PP application note1: Creation of the application implies applet instantiation.4 In this step the final (but not yet personalized) MRTD is generated from the certified components accord- ing to the binding initialization and pre-personalization guidelines provided in [Guidance]. The pre-personalized MRTD together with the IC Identifier is securely delivered fromthe MRTD manufac- turer to the Personalization Agent. The MRTD manufacturer also provides the relevant parts of the guidance documentation to the Personalization Agent. 1.3.5.3 Phase 3: Personalisation of the MRTD (Step 6) The personalization of the MRTD includes (i) the survey of the MRTD holder biographical data, (ii) the enrolment of the MRTD holder biometric reference data (i.e. the digitized portraits and the optional biometric reference data), (iii) the printing of the visual readable data onto the physical MRTD and their secure transfer to the personalisation agent, (iv) the writing of the TOE User Data and TSF Data into the logical MRTD and (v) the writing the TSF Data into the logical MRTD and configuration of the TSF if necessary. The step (iv) is performed by the Personalisation Agent and includes but is not limited to the creation of (i) the digital MRZ data (DG1), (ii) the digitised portrait (DG2), and (iii) the Document security object. The signing of the Document security object by the Document signer [ICAODoc] finalizes the personalization of the genuine MRTD for the MRTD holder. The personalized MRTD (together with appropriate guidance for TOE use if necessary) is handed over to the MRTD holder for operational use. 3Please note that in this ST the role software developer of the protection profile is subdivided into two separate roles: the operating system is developed by the OS software developer, and the MRTD application by the (MRTD) software developer. 4PP0056v2 and PP0068 application note 1. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 12 of 98 PP and PP0068 application note 2:The TSF data (data created by and for the TOE, that might affect the operation of the TOE) comprise the Personalisation Agent Authentication Key(s), the Terminal Authentica- tion trust anchor, the effective date and the Chip Authentication Private Key. PP and PP0068 application note 3: This ST distinguishes between the Personalisation Agent as entity known to the TOE and the Document Signer as entity in the TOE IT environment signing the Document security object as described in [ICAODoc]. This approach allows but does not enforce the separation of these roles. 1.3.5.4 Phase 4: Operational use (Step 7) The TOE is used as MRTD’s chip by the traveller and the inspection systems in the “Operational Use” phase. The user data can be read according to the security policy of the Issuing State or Organization and used according to the security policy of the Issuing State but they can never be modified. PP and PP0068 application note 4:The intention of the underlying PP [PP0056v2] is to consider at least the phases 1 and parts of phase 2 (i.e. Step1 to Step3) as part of the evaluation and therefore to define the TOE delivery according to CC after this phase. Since specific production steps of phase 2 are of minor security relevance (e. g. booklet manufacturing and antenna integration) these are not part of the CC evaluation under ALC. Nevertheless the decision about this has to be taken by the certification body resp. the national body of the issuing State or Organization. In this case the national body of the issuing State or Organization is responsible for these specific production steps. Note that the personalization process and its environment may depend on specific security needs of an issuing State or Organization. All production, generation and installation procedures after TOE delivery up to the “Operational Use” (phase 4) have to be considered in the product evaluation process under AGD assurance class. Some production steps, e.g. Step 4 in Phase 2 may also take place in the Phase 3. Remark: This ST considers only phase 1 and parts of phase 2 (steps 1 - 3) as part of CC evaluation under ALC. 1.3.6 Non-TOE hardware/software/firmware required by the TOE There is no explicit non-TOE hardware, software or firmware required by the TOE to perform its claimed security features. The TOE is defined to comprise the chip and the complete operating system and applica- tion. Note, the inlay holding the chip as well as the antenna and the booklet (holding the printed MRZ) are needed to represent a complete MRTD, nevertheless these parts are not inevitable for the secure operation of the TOE. PP0068 application note 5:A terminal shall always start a communication session using PACE. If successfully, it should then proceed with passive authentications. If the trial with PACE failed, the terminal may try to establish a communication session using other valid options as described above. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 13 of 98 2 Conformance claims 2.1 CC conformance This security target claims conformance to:  Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; Version 3.1, Revision 4, September 2012; CCMB-2012-09-001, [CC_1],  Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Re- quirements; Version 3.1, Revision 4, September 2012; CCMB-2012-09-002, [CC_2],  Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Re- quirements; Version 3.1, Revision 4, September 2012; CCMB-2012-09-003, [CC_3], as follows:  Part 2 extended,  Part 3 conformant  Package conformant to EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 defined in CC part 3 [CC_3]. The  Common Methodology for Information Technology Security Evaluation, Evaluation Methodol- ogy; Version 3.1, Revision 4, September 2012; CCMB-2012-09-004, [CC_4] has to be taken into account. The requirements for the evaluation of the TOE and its development and operating environment are those takenfrom the Evaluation Assurance Level 4 (EAL4) and augmented by taking the following components: ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. 2.2 PP Claim This security target claims strict conformance to  the Protection Profile Machine Readable Travel Document with “ICAO Application”, Extended Ac- cess Control with PACE (EAC PP) (BSI-CC-PP0056v2) [PP0056v2],  the Protection Profile Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2-2011 [PP0068]. This Security Target has been extended to include Active Authentication according to [ICAODoc]. The evaluation of the TOE uses the result of the CC evaluation of the chip platform claiming conformance to the PP [PP_Javacard]. The hardware part of the composite evaluation is covered by the certification re- port [ZertIC].In addition, the evaluation of the TOE uses the result of the CC evaluation of the crypto library and the JCOP 2.4.2 R3 Javacard OS. The Javacard OS part of the composite evaluation is covered by the certification reports [ZertJCOP], the crypto library by the certification reports [ZertCL]. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 14 of 98 2.3 Statement of Compatibility concerning Composite Security Target 2.3.1 Assessment of the Platform TSFs The following Table 2 lists all Security Functionalities of the underlying Platform ST and shows, which Secu- rity Functionalities of the Platform ST are relevant for this Composite ST and which are irrelevant. The first column addresses specific Security Functionality of the underlying platform, which is assigned to Security Functionalities of the Composite ST in the second column. The last column provides additional information on the correspondence if necessary. Platform TSF-group Correspondence in this ST References/Remarks SF.AccessControl TSF_Access SF.Audit TSF_Admin SF.CryptoKey TSF_Secret SF.CryptoOperation TSF_Crypto SF.I&A TSF_Access SF.SecureManagement TSF_Admin, TSF_Integrity SF.PIN - This platform TSF focuses on PIN au- thentication, which is irrelevant for this ST. For other configurations of ePasslet Suite, the corresponding TSF is TSF_Access. SF.LoadIntegrity - This platform TSF ensures the origin and the integrity of a received pack- age. This is not corresponding to any TSF of the TOE. Security measures for the loading of additional applets are not in the scope of this ST, but are in the responsibility of the card issuer. SF.Transaction TSF_Integrity SF.Hardware TSF_OS Implicitly used via JCOP (TSF_OS)* SF.CryptoLib TSF_OS Implicitly used via JCOP (TSF_OS)* Table 2: Platform TSF-groups and their correspondence * Remark: The Platform TSF-groups “SF.Hardware” and “SF.CryptoLib” are not directly used by Security functionalities of the TOE, they are (implicitly) invoked by calls to the JCOP operating system, though. These OS calls are grouped in the TSF_OS. 2.3.2 Assessment of the Platform SFRs The following table provides an assessment of all Platform SFRs. The Platform SFRs are listed in the order used within the security target of the platform [ST_JCOP]. Platform SFR Correspondence in this ST References/Remarks CoreG_LC Security Functional Requirements (chapter 6.1 in platform ST) cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 15 of 98 Platform SFR Correspondence in this ST References/Remarks Firewall Policy (chapter 6.1.1 in platform ST) FDP_ACC.2/FIREWALL No correspondence Out of scope (internal Java Card Fire- wall). The resulting requirements for applets are reflected in the User Guidance of the TOE. No contradic- tion to this ST. FDP_ACF.1/FIREWALL No correspondence Out of scope (internal Java Card Fire- wall). The resulting requirements for applets are reflected in the User Guidance of the TOE. No contradic- tion to this ST. FDP_IFC.1/JCVM No correspondence Out of scope (internal Java Virtual Machine). No contradiction to this ST. FDP_IFF.1/JCVM No correspondence Out of scope (internal Java Virtual Machine). No contradiction to this ST. FDP_RIP.1/OBJECTS No correspondence. Out of scope (internal Java Card Fire- wall). No contradiction to this ST. FMT_MSA.1/JCRE No correspondence Out of scope (internal Java Card Fire- wall). No contradiction to this ST. FMT_MSA.1/JCVM No correspondence Out of scope (internal Java Card Fire- wall). No contradiction to this ST. FMT_MSA.2/FIREWALL_JCVM No correspondence Out of scope (internal Java Card Fire- wall). The resulting requirements for applets are reflected in the User Guidance of the TOE. No contradic- tion to this ST. FMT_MSA.3/FIREWALL No correspondence Out of scope (internal Java Card Fire- wall). The resulting requirements for applets are reflected in the User Guidance of the TOE. No contradic- tion to this ST. FMT_MSA.3/JCVM No correspondence Out of scope (internal Java Card Fire- wall). No contradiction to this ST. FMT_SMF.1 No correspondence Out of scope (internal Java Card Fire- wall). No contradiction to this ST. FMT_SMR.1 No correspondence Out of scope (internal Java Card Fire- wall). No contradiction to this ST. Application Programming Interface (chapter 6.1.2 in platform ST) FCS_CKM.1 FCS_CKM.1/DH-PACE FCS_CKM.1/CA FCS_CKM.1/AA The requirementin this ST is equiva- lent to parts of the platform ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 16 of 98 Platform SFR Correspondence in this ST References/Remarks FCS_CKM.2 No correspondence Out of scope (managed within JCOP). No contradiction to this ST. FCS_CKM.3 No correspondence Out of scope (managed within JCOP). No contradiction to this ST. FCS_CKM.4 FCS_CKM.4 The requirements are equivalent (physically overwriting the keys with zeros). FCS_COP.1 (FCS_COP.1.1/TripleDES, FCS_COP.1.1/AES, FCS_COP.1.1/RSACipher, FCS_COP.1.1/ RSASigna- turePKCS#1, FCS_COP.1.1/ RSASignaturePKCS#1_PSS, FCS_COP.1.1/ RSASigna- tureISO9796, FCS_COP.1.1/ DHKeyExchange, FCS_COP.1.1/ DESMAC,FCS_COP.1.1/ AESMAC, FCS_COP.1.1/ ECSig- nature, FCS_COP.1.1/ ECAdd, FCS_COP.1.1/SHA-1, FCS_COP.1.1/ SHA-224, FCS_COP.1.1/ SHA-256, FCS_COP.1.1/ AES_CMAC, FCS_COP.1.1/ TDES_CMAC) FCS_COP.1/PACE_ENC FCS_COP.1/PACE_MAC FCS_COP.1/CA_ENC FCS_COP.1/CA_MAC FCS_COP.1/SIG_VER FCS_COP.1/SIG_GEN The platform requirements are nec- essary to fulfill the requirements of this ST: FCS_COP.1/PACE_ENC of this ST cor- responds to the platform SFRs- FCS_COP.1.1/AES. FCS_COP.1/PACE_MAC of this ST cor- responds to the platform SFR FCS_COP.1.1/AES_CMAC. FCS_COP.1/CA_ENC of this ST corre- sponds to the platform SFRs- FCS_COP.1.1/AES. FCS_COP.1/CA_MAC of this ST corre- sponds to the platform SFRs- FCS_COP.1.1/ AES_CMAC. FCS_COP.1/SIG_VER of this ST corre- sponds to the platform SFR FCS_COP.1/ECSignature. FCS_COP.1/SIG_GEN of this ST corre- sponds to the platform SFR FCS_COP.1.1/RSASignaturePKCS#1. FDP_RIP.1/ABORT FDP_RIP.1 Implicitly used for this ST. No contra- diction to this ST. FDP_RIP.1/APDU No correspondence. Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_RIP.1/bArray FDP_RIP.1 Implicitly used for this ST. No contra- diction to this ST. FDP_RIP.1/KEYS FDP_RIP.1 Implicitly used for this ST. No contra- diction to this ST. FDP_RIP.1/TRANSIENT No correspondence. Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_ROL.1/FIREWALL No correspondence. Out of scope (internal Java Card Fire- wall). The resulting requirements for applets are reflected in the User Guidance of the TOE. No contradic- tion to this ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 17 of 98 Platform SFR Correspondence in this ST References/Remarks Card Security Management (chapter 6.1.3 in platform ST) FAU_ARP.1 FPT_FLS.1, FPT_PHP.3 Not directly corresponding, but plat- form SFR is basis of fulfillment of FPT_FLS.1 and FPT_PHP.3. Internal counter for security violations com- plement JCOP mechanisms- No con- tradiction to this ST. FDP_SDI.2 FPT_FLS.1, FPT_PHP.3 Not directly corresponding, but plat- form SFR is basis of fulfillment of FPT_FLS.1 and FPT_PHP.3. No con- tradiction to this ST. FPR_UNO.1 No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FPT_FLS.1 FPT_FLS.1 The fulfillment of the platform SFR is part of the basis of the fulfillment of the SFR of this ST. Internal counter- measures for detecting security vio- lations complement JCOP mecha- nisms. No contradiction to this ST. FPT_TDC.1 No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. Aid Management (chapter 6.1.4 in platform ST) FIA_ATD.1/AID No correspondence. Out of scope (internal Java Card func- tionality). No contradiction to this ST. FIA_UID.2/AID No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FIA_USB.1/AID No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MTD.1/JCRE No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MTD.3/JCRE No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. INSTG Security Functional Requirements (chapter 6.1.5 in platform ST) This group consists of the SFRs related to the installation of the applets, which addresses security aspects outside the runtime. FDP_ITC.2/Installer No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMR.1/Installer No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FPT_FLS.1/Installer No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FPT_RCV.3/Installer No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 18 of 98 Platform SFR Correspondence in this ST References/Remarks ADELG Security Functional Requirements (chapter 6.1.6 in platform ST) This group consists of the SFRs related to the deletion of applets and/or packages, enforcing the applet deletion manager (ADEL) policy on security aspects outside the runtime. FDP_ACC.2/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_ACF.1/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_RIP.1/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.1/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.3/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMF.1/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMR.1/ADEL No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FPT_FLS.1/ADEL FPT_FLS.1 The fulfillment of the platform SFR is part of the basis of the fulfillment of the SFR of this ST.Internal counter- measures for detecting security vio- lations complement JCOP mecha- nisms. No contradiction to this ST. RMIG Security Functional Requirements (chapter 6.1.7 in platform ST) This group specifies the policies that control the access to the remote objects and the flow of information that takes place when the RMI service is used. FDP_ACC.2/JCRMI No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_ACF.1/JCRMI No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. ODELG Security Functional Requirements (chapter 6.1.8 in platform ST) The following requirements concern the object deletion mechanism. This mechanism is triggered by the applet that owns the deleted objects by invoking a specific API method. FDP_RIP.1/ODEL FDP_RIP.1 Implicitly used for this ST. No contra- diction to this ST. FPT_FLS.1/ODEL FPT_FLS.1 The fulfillment of the platform SFR is part of the basis of the fulfillment of the SFR of this ST. Internal counter- measures for detecting security vio- lations complement JCOP mecha- nisms. No contradiction to this ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 19 of 98 Platform SFR Correspondence in this ST References/Remarks CARG Security Functional Requirements (chapter 6.1.9 in platform ST) This group includes requirements for preventing the installation of packages that has not been bytecode verified, or that has been modified after bytecode verification. FCO_NRO.2/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_IFC.2/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_IFF.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_UIT.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FIA_UID.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.3/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMF.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMR.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FTP_ITC.1/CM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. EMG Security Functional Requirements (chapter 6.1.10 in platform ST) This group includes requirements for managing the external memory. FDP_ACC.1/EXT_MEM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_ACF.1/EXT_MEM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.1/EXT_MEM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.3/EXT_MEM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMF.1/EXT_MEM No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. Further Functional Requirements not contained in the PP (chapter 6.1.11 in platform ST) SCPG Security Functional Requirements (chapter 6.1.12 in platform ST) For the Java card platform evaluation the smart card platform belongs to the TOE and the requirements are stated in the ST as functional requirements for the TOE. FPT_FLS.1/SCP FPT_FLS.1 The fulfillment of the platform SFR is part of the basis of the fulfillment of the SFR of this ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 20 of 98 Platform SFR Correspondence in this ST References/Remarks FRU_FLT.2/SCP No correspondence Out of scope (platform functionality). No contradiction to this ST. FPT_PHP.3/SCP FPT_PHP.3 The fulfillment of the SFR in this ST is based on the platform SFR. No con- tradiction to this ST. FDP_ACC.1/SCP No correspondence Out of scope (platform functionality). No contradiction to this ST. FDP_ACF.1/SCP No correspondence Out of scope (platform functionality). No contradiction to this ST. FMT_MSA.3/SCP No correspondence Out of scope (platform functionality). No contradiction to this ST. LifeCycle Security Functional Requirements (chapter 6.1.13 in platform ST) This group contains the security requirements for life cycle control mechanism . FDP_ACC.1/LifeCycle No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_ACF.1/LifeCycle No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.1/LifeCycle No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.3/LifeCycle No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. Further Functional Requirements (chapter 6.1.14 in platform ST) FIA_AFL.1/PIN No correspondence Out of scope (PINs are not used). No contradiction to this ST. FTP_ITC.1/ LifeCycle No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FAU_SAS.1/SCP FAU_SAS.1 Fulfillment of the platform SFR leads directly to the SFR of this ST. FCS_RNG.1 FCS_RND.1 In this ST, random numbers accord- ing to AIS20 class DRG.3 are re- quired. The platform generates ran- dom numbers with a defined quality metric that can be used directly. FCS_RNG.1/RNG2 No correspondence This ST requires random numbers ac- cording to AIS20 class DRG.3; thus, this platform SFR with an optional DRG.2 random generator mode has no direct correspondence. FPT_EMSEC.1 FPT_EMS.1 The fulfillment of the SFR in this ST is based on the platform SFR (together with additional countermeasures). cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 21 of 98 Platform SFR Correspondence in this ST References/Remarks Functional Requirements for the Secure Box This group contains the functional requirements for the Secure Box which is part of the TOE. FDP_ACC.2/SecureBox No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FDP_ACF.1/SecureBox No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.3/SecureBox No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_MSA.1/SecureBox No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. FMT_SMF.1/SecureBox No correspondence Out of scope (internal Java Card func- tionality). No contradiction to this ST. Table 3: Assessment of the platform SFRs. 2.3.3 Assessment of the Platform Objectives The following table provides an assessment of all relevant Platform objectives. Relevant Platform Objective Correspondence in this ST References/Remarks OT.SEC_BOX_FW No correspondence Out of scope.No contradiction to this ST. OT.IDENTIFICATION OT.Identification No contradiction to this ST. OT.RND No correspondence Indirectly relevant for the correct function of the TOE of this ST, but no corresponding objectives for the TOE of this ST. No contradictions. OT.MF_FW No correspondence Out of scope.No contradiction to this ST. OT.SID No correspondence Out of scope.No contradiction to this ST. OT.FIREWALL No correspondence Out of scope.No contradiction to this ST. OT.GLOBAL_ARRAYS_CONFID OT.Data-Confidentiality No contradiction to this ST. OT.GLOBAL_ARRAYS_INTEG OT.Data-Integrity No contradiction to this ST. OT.NATIVE No correspondence Out of scope.No contradiction to this ST. OT.OPERATE No correspondence Out of scope.No contradiction to this ST. OT.REALLOCATION No correspondence Out of scope.No contradiction to this ST. OT.RESOURCES No correspondence Out of scope.No contradiction to this ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 22 of 98 Relevant Platform Objective Correspondence in this ST References/Remarks OT.ALARM No correspondence Out of scope.No contradiction to this ST. OT.CIPHER No correspondence Indirectly relevant for the correct function of the TOE of this ST, but no corresponding objectives for the TOE of this ST. No contradictions. OT.KEY-MNGT No correspondence Out of scope.No contradiction to this ST. OT.PIN-MNGT No correspondence Out of scope.No contradiction to this ST. OT.REMOTE No correspondence Out of scope.No contradiction to this ST. OT.TRANSACTION No correspondence Out of scope.No contradiction to this ST. OT.OBJ-DELETION No correspondence Out of scope.No contradiction to this ST. OT.DELETION No correspondence Out of scope.No contradiction to this ST. OT.LOAD No correspondence Out of scope.No contradiction to this ST. OT.INSTALL No correspondence Out of scope.No contradiction to this ST. OT.CARD-MANAGEMENT No correspondence Out of scope.No contradiction to this ST. OT.SCP.IC OT.Prot_Phys-Tamper The objectives are related. No con- tradiction to this ST. OT.SCP.RECOVERY OT.Prot_Malfunction The objectives are related. No con- tradiction to this ST. OT.SCP.SUPPORT No correspondence Out of scope.No contradiction to this ST. OT.EXT-MEM No correspondence Out of scope.No contradiction to this ST. Table 4: Assessment of the platform objectives. 2.3.4 Assessment of Platform Threats The following table provides an assessment of all relevant Platform threats. Platform Thread Correspondence in this ST References/Remarks T.OS_OPERATE No correspondence Out of scope. No contradiction to this ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 23 of 98 Platform Thread Correspondence in this ST References/Remarks T.SEC_BOX_BORDER No correspondence Out of scope. No contradiction to this ST. T.RND No correspondence Out of scope. No contradiction to this ST. T.CONFID-APPLI-DATA T.Forgery No contradiction to this ST. T.CONFID-JCS-CODE No correspondence Out of scope. No contradiction to this ST. T.CONFID-JCS-DATA T.Information_Leakage No contradiction to this ST. T.INTEG-APPLI-CODE No correspondence Out of scope. No contradiction to this ST. T.INTEG-APPLI-CODE.LOAD No correspondence Out of scope. No contradiction to this ST. T.INTEG-APPLI-DATA T.Forgery No contradiction to this ST. T.INTEG-APPLI-DATA.LOAD No correspondence Out of scope. No contradiction to this ST. T.INTEG-JCS-CODE No correspondence Out of scope. No contradiction to this ST. T.INTEG-JCS-DATA No correspondence Out of scope. No contradiction to this ST. T.SID.1 No correspondence Out of scope. No contradiction to this ST. T.SID.2 No correspondence Out of scope. No contradiction to this ST. T.EXE-CODE.1 No correspondence Out of scope. No contradiction to this ST. T.EXE-CODE.2 No correspondence Out of scope. No contradiction to this ST. T.EXE-CODE-REMOTE No correspondence Out of scope. No contradiction to this ST. T.NATIVE No correspondence Out of scope. No contradiction to this ST. T.RESOURCES No correspondence Out of scope. No contradiction to this ST. T.DELETION No correspondence Out of scope. No contradiction to this ST. T.INSTALL No correspondence Out of scope. No contradiction to this ST. T.OBJ-DELETION No correspondence Out of scope. No contradiction to this ST. T.PHYSICAL T.Phys-Tamper No contradiction to this ST. Table 5: Threats of the platform ST. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 24 of 98 2.3.5 Assessment of Platform Organisational Security Policies The platform ST contains the Organisational Security Policy “OSP.PROCESS-TOE” referring to accurate iden- tification of each TOE instance. This policy will be fulfilled by a distinct product code for the platform and for the composite TOE each. This policy does not contradict to the policies of this ST. The other Organisa- tional Security Policy “OSP.VERIFICATION” focuses on the integrity of loaded applets, which is fulfilled by the TOE of this ST since the applet is loaded from ROM only. 2.3.6 Assessment of Platform Operational Environment 2.3.6.1 Assessment of Platform Assumptions In the first column, the following table lists all significant assumptions of the Platform ST. The last column provides an explanation of relevance for the Composite TOE. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 25 of 98 Significant Platform Assumption Relevance for Composite ST A.APPLET A.APPLET states that applets loaded post-issuance do not contain na- tive methods. This assumption leads to appropriate directives in the user guidance [Guidance]. A.VERIFICATION This assumption targets the applet code verification. In the context of this ST the applet is loaded from ROM only and was verified before ROM mask production. Regarding post-issuance loading of third party applets, this objective for the environment leads to appropriate di- rectives in the user guidance [Guidance]. A.USE_DIAG A.USE_DIAG is required in the Platform ST to cover secure communi- cation during packaging, finishing and personalisation. This is corre- sponding to OT.Data_Integrity of this composite ST. A.USE_KEYS During Operational use, this assumption is corresponding to A.Insp_Sys of this ST. Regarding the packaging, finishing and person- alisation phase, this assumption is corresponding to P.Manufact.There are no contradictions in the assumptions. A.PPROCESS-SEC-IC This assumption focuses on the security of the production process af- ter chip delivery; this is also targeted by P.Pre-Operational of this ST and leads to appropriate directives in the user guidance [Guidance]. A.PPROCESS-SEC-IC of the platform ST states that it is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to delivery to the end consumer to maintain confi- dentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorised use). This means that the Phases after TOE Delivery are assumed to be protected appropriately. The assets to be protected are: - the Security IC Embedded Software including specifications, imple- mentation and related documentation, - pre-personalisation and personalisation data including specifications of formats and memory areas, test related data, - the User Data and related documentation, and - material for software development support as long as they are not under the control of the TOE Manufacturer. For the TOE of this ST, the Security IC Embedded Software is inte- grated in the ROM by the manufacturer of the platform. Thus, it is under control of the platform manufacturer. The protection of pre- personalisation and personalisation data as well as User Data is cor- responding to the Organizational Security Policies (OSP) P.Manufact and P.Personalisation. Thus, the main aspects of A.PPROCESS-SEC-IC are also addressed in this ST, and there are no contradictions in the assumptions. Table 6: Assumptions of the Platform ST. 2.3.6.2 Assessment of Platform Security Objectives and SFRs for the Operational Environment There are the following significant Platform Security Objectives for the Operational Environment that have to be considered. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 26 of 98 Significant Platform Objective for the Environment Relevance for Composite ST OE.APPLET The platform objective for the environment states that applets loaded post-issuance do not contain native methods. This objective leads to appropri- ate directives in the user guidance [Guidance]. OE.VERIFICATION According to the document [JIL_1], the correspond- ing objective for the environment in [Guidance] is ex- tended to the following: OE.VERIFICATION All the bytecodes shall be verified at least once, be- fore the loading, before the installation or before the execution, depending on the card capabilities, in or- der to ensure that each bytecode is valid at execution time. Additionally, the applet shall follow all the recom- mendations, if any, mandated in the platform guid- ance for maintaining the isolation property of the platform. The platform objective for the environment tar- gets the applet code verification. In the context of this ST the TOE applet code is loaded from ROM only and was verified before ROM mask produc- tion. Regarding post-issuance loading of third party applets, this objective for the environment leads to appropriate directives in the user guid- ance [Guidance]. There it is stated that all applets loaded to the TOE have to be verified. OE.USE_DIAG The platform objective for the environment co- vers secure communication during packaging, fin- ishing and personalisation. This is corresponding to OT.Data_Integrity of this composite ST. OE.USE_KEYS During Operational use, this assumption is corre- sponding to A.Insp_Sys of this ST. Regarding the packaging, finishing and personalisation phase, this assumption is corresponding to P.Manufact. OE.PROCESS_SEC_IC For the TOE of this ST, the Security IC Embedded Software is integrated in the ROM by the manu- facturer of the platform. Thus, it is under control of the platform manufacturer. The protection of pre-personalisation and personalisation data as well as User Data is corresponding to the Organi- zational Security Policies (OSP) P.Manufact and P.Personalisation. According to the document [JIL_1], an additional ob- jective for the environment is necessary for an open and isolating platform: OE.CODE-EVIDENCE For application code loaded pre-issuance, evaluated technical measures implemented by the TOE or au- dited organizational measures must ensure that loaded application has not been changed since the code verifications required in OE.VERIFICATION. For application code loaded post-issuance and veri- fied off-card according to the requirements of This objective for the environment is relevant, since it targets additional applets loaded to the TOE. Thus it leads to an appropriate objective for the environment in the user guidance [Guidance]. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 27 of 98 OE.VERIFICATION, the verification authority shall provide digital evidence to the TOE that the applica- tion code has not been modified after the code veri- fication and that he is the actor who performed code verification. For application code loaded post-issuance and par- tially or entirely verified on-card, technical measures must ensure that the verification required in OE.VERIFICATION are performed. On-card bytecode verifier is out of the scope of this Protection Profile. Application Note: The technical measure to fulfill OE.VERIFICATION is the bytecode verifier provided by the Java card OS manufacturer. For application code loaded pre-issuance, organizational measures must ensure that a loaded application has not been changed since the code verification. For application code loaded post-issuance, the verification authority shall provide digital evidence that the application code has not been modified after the code verifica- tion and that he is the actor who performed code verification. This can be achieved by electronic signa- ture of the application code, after code verification, by the actor who performed verification. Table 7: Platform Security Objectives and SFRs for the Operational Environment cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 28 of 98 3 Security problem definition This chapter has been taken from [PP0056v2] and [PP0068] with only minor modifications. 3.1 Introduction 3.1.1 Assets The assets to be protected by the TOE include the User Data on the travel document’s chip, user data trans- ferred between the TOE and the terminal, and travel document tracing data from the claimed PACE PP [PP0068], chap 3.1. PP0068 application note 6: Please note that user data being referred to in [PP0068] include, amongst other, individual-related (personal) data of the travel document holder which also include his sensitive (i.e. bio- metric) data. Hence, the general security policy also secures these specific travel document holder’s data as stated in the table above. PP0068 application note 7: Since the travel document does not support any secret travel document hold- erauthentication data and the latter may reveal, if necessary, his or her verification values of the PACE pass- word to an authorised person or device, a successful PACE authentication of a terminal does not unambig- uously mean that the travel document holder is using TOE. PP0068 application note 8: Travel document communication establishment authorisation data are repre- sented by two different entities: (i) reference information being persistently stored in the TOE and (ii) veri- fication information being provided as input for the TOE by a human user as an authorisation attempt. The TOE shall secure the reference information as well as – together with the terminal connected– the verification information in the ‘TOE ↔ terminal’ channel, if it has to be transferred to the TOE. Please note that PACE passwords are not to be send to the TOE. 3.1.1.1 Logical MRTD sensitive User Data Sensitive biometric reference data (EF.DG3, EF.DG4). PP application note5: Due to interoperability reasons the ‘ICAO Doc 9303’ [ICAODoc] requires that Basic Inspection Systems may have access to logical travel document data DG1, DG2, DG5 to DG16. The TOE is not in certified mode, if it is accessed using BAC [ICAODoc]. Note that the BAC mechanism cannot resist attacks with high attack potential (cf. [PP0055]). If supported, it is therefore recommended to used PACE instead of BAC. If nevertheless BAC has to be used, it is recommended to perform Chip Authentication v.1 before getting access to data (except DG14), as this mechanism is resistant to high potential attacks. A sensitive asset is the following more general one. 3.1.1.2 Authenticity of the MRTD’s chip The authenticity of the travel document’s chip personalised by the issuing State or Organisation for the travel document holder is used by the traveller to prove his possession of a genuine travel document. Due to strict conformance to PACE PP, this security target also includes all assets listed in [PP0068], chap 3.1, namely the primary assets user data stored on the TOE (object 1), user data transferred between the TOE and the terminal connected (object 2), travel document tracing data (object 3), and the secondary assets accessibility to the TOE functions and data only for authorised subjects (object 4) Genuineness of the TOE (object 5), TOE intrinsic secret cryptographic keys (object 6), TOE intrinsic non secret cryptographic material (object 7), and travel document communication establishment authorisation data (object 8). Due to identical names and definitions these are not repeated here. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 29 of 98 3.1.2 Subjects This Security Targetconsiders the following subjects additionally to those defined in the PACE PP [PP0068]: 3.1.2.1 Country Verifying Certification Authority The Country Verifying Certification Authority (CVCA) enforces the privacy policy of the issuing State or Or- ganization with respect to the protection of sensitive biometric reference data stored in the MRTD. The CVCA represents the country specific root of the PKI of Inspection Systems and creates the Document Ver- ifier Certificates within this PKI. The updates of the public key of the CVCA are distributed in the form of Country Verifying CA Link-Certificates. 3.1.2.2 Document Verifier The Document Verifier (DV) enforces the privacy policy of the receiving State with respect to the protection of sensitive biometric reference data to be handled by the Extended Inspection Systems. The Document Verifier manages the authorization of the Extended Inspection Systemsfor the sensitive data of the MRTD in the limits provided by the issuing States or Organizations in the form of the Document Verifier Certifi- cates. 3.1.2.3 Terminal A terminal is any technical system communicating with the TOE through the contact interface or through the contactless interface. 3.1.2.4 Inspection system (IS) A technical system used by the border control officer of the receiving State (i) examining an travel document presented by the traveller and verifying its authenticity and (ii) verifying the traveller as travel document holder. The Extended Inspection System (EIS) performs the Advanced Inspection Procedure and therefore (i) con- tains a terminal for the communication with the travel document’s chip, (ii) implements the terminals part of PACE and/or BAC; (iii) gets the authorization to read the logical travel document either under PACE or BAC by optical reading the travel document providing this information. (iv) implements the Terminal Au- thentication and Chip Authentication Protocols both Version 1 according to [5] and (v) is authorized by the issuing State or Organisation through the Document Verifier of the receiving State to read the sensitive biometric reference data. Security attributes of the EIS are defined by means of the Inspection System Cer- tificates. BAC may only be used if supported by the TOE. If both PACE and BAC are supported by the TOE and the BIS, PACE must be used. PP Application note 6: For definition of Basic Inspection System (BIS) resp. Basic Inspection System with PACE (BIS-PACE) see PACE PP [PP0068]. 3.1.2.5 Attacker Additionally to the definition from PACE PP [PP0068], chap 3.1 the definition of an attacker is refined as followed: A threat agent trying (i) to manipulate the logical travel document without authorization, (ii) to read sensitive biometric reference data (i.e. EF.DG3, EF.DG4), (iii) to forge a genuine travel document, or (iv) to trace a travel document. PP Application note 7: An impostor is attacking the inspection system as TOE IT environment independent on using a genuine, counterfeit or forged travel document. Therefore the impostor may use results of suc- cessful attacks against the TOE but the attack itself is not relevant for the TOE. PP0068 application note 9: Since the TOE does not use BAC, a Basic Inspection System with BAC (BIS-BAC) cannot be recognised by the TOE. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 30 of 98 This ST includes all subjects from the PACE Protection Profile [PP0068], chap 3.1, namely Manufacturer, Personalisation Agent, Basic Inspection System (with PACE), Document Signer (DS), and Country Signing Certification Authority (CSCA), Travel Document Holder and Travel Document Presenter (traveller). Due to identical definitions and names they are not repeated here. 3.2 Assumptions The assumptions describe the security aspects of the environment in which the TOE will be usedor is in- tended to be used. 3.2.1 A.Insp_Sys Inspection Systems for global interoperability The Extended Inspection System (EIS) for global interoperability (i) includes the Country Signing CA Public Key and (ii) implements the terminal part of PACE [ICAO_SAC] and/or BAC [PP0055]. BAC may only be used if supported by the TOE. If both PACE and BAC are supported by the TOE and the IS, PACE must be used. The EIS reads the logical travel document under PACE or BAC and performs the Chip Authentication v.1 to verify the logical travel document and establishes secure messaging. EIS supports the Terminal Authentica- tion Protocol v.1 in order to ensure access control and is authorized by the issuing State or Organisation through the Document Verifier of the receiving State to read the sensitive biometric reference data. Justification: The assumption A.Insp_Sys does not confine the security objectives of the [PP0068] as it re- peats the requirements of P.Terminal and adds only assumptions for the Inspection Systems for handling the the EAC functionality of the TOE. 3.2.2 A.Auth_PKI PKI for Inspection Systems The issuing and receiving States or Organizations establish a public key infrastructure for card verifiable certificates of the Extended Access Control. The Country Verifying Certification Authorities, the Document Verifier and Extended Inspection Systems hold authentication key pairs and certificates for their public keys encoding the access control rights. The Country Verifying Certification Authorities of the issuing States or Organizations are signing the certificates of the Document Verifier and the Document Verifiers are signing the certificates of the Extended Inspection Systems of the receiving States or Organizations. The issuing States or Organizations distribute the public keys of their Country Verifying Certification Authority to their MRTD’s chip. This ST includes the assumption from the PACE PP [PP0068], chap 3.4, namely A.Passive_Auth. 3.3 Threats This section describes the threats to be averted by the TOE independently or in collaboration with its IT environment. These threats result from the TOE method of use in the operational environment and the assets stored in or protected by the TOE. The TOE in collaboration with its IT environment shall avert the threats as specified below. 3.3.1 T.Read_Sensitive_Data Read the sensitive biometric reference data Adverse action: An attacker tries to gain the sensitive biometric reference data through the com- munication interface of the travel document’s chip. The attack T.Read_Sensitive_Data is similar to the threat T.Skimming (cf. [PP0055]) in respect of the attack path (communication interface) and the motivation (to get data stored on the travel document’s chip) but differs from those in the asset under cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 31 of 98 the attack (sensitive biometric reference data vs. digital MRZ, digitized portrait and other data), the opportunity (i.e. knowing the PACE Password) and therefore the possible attack methods. Note, that the sensitive biometric reference data are stored only on the travel document’s chip as private sensitive personal data whereas the MRZ data and the portrait are visually readable on the physical part of the travel document as well. Threat agent: having high attack potential, knowing the PACE Password, being in possession of a legitimate travel document Asset: confidentiality of logical travel document sensitive user data (i.e. biometric refer- ence) 3.3.2 T.Counterfeit MRTD’s chip Adverse action: An attacker with high attack potential produces an unauthorized copy orreproduc- tion of a genuine MRTD’s chip to be used as part of a counterfeit MRTD. This violates the authenticity of the MRTD’s chip used for authentication of a traveler by posses- sion of a MRTD. The attacker may generate a new data set or extract completely or partially the data from a genuine MRTD’s chip and copy them on another appropriate chip to imitate this genuine MRTD’s chip. Threat agent: having high attack potential, being in possession of one or more legitimate MRTDs Asset: authenticity of user data stored on the TOE This ST includes all threats from the PACE PP [PP0068], chap 3.2, namely T.Skimming, T.Eavesdropping, T.Tracing, T.Abuse-Func, T.Information_Leakage, T.Phys-Tamper, and T.Malfunction. Due to identical defi- nitions and names they are not repeated here as well. PP0068 application notes 10 – 19: PP Application note 8: T.Forgery from the PACE PP [PP0068] is extended by the Extended Inspection System additionally to the PACE authenticated BIS-PACE being outsmarted by the attacker. 3.3.3 T.Forgery Forgery of Data Adverse action: An attacker fraudulently alters the User Data or/and TSF-data stored on the travel documentor/andexchanged between the TOE and the terminal connectedin or- derto outsmart the PACE authenticated BIS-PACE or the Extended Inspection Sys- tem by means of changedtraveldocumentholder’s related reference data (like bi- ographicor biometric data).The attacker does it in such a way that the terminal con- nected perceives these modified data as authentic one. Threat agent: having high attack potential Asset: integrity of the travel document cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 32 of 98 3.4 Organizational security policies The TOE shall comply with the following Organizational Security Policies (OSP) as security rules, procedures, practices, or guidelines imposed by an organization upon its operations (see CCpart 1 [CC_1], section 3.2). 3.4.1 P.Sensitive_Data Privacy of sensitive biometric reference data The biometric reference data of finger(s) (EF.DG3) and iris image(s) (EF.DG4) are sensitive private personal data of the MRTD holder. The sensitive biometric reference data can be used only by inspection systems which are authorized for this access at the time the MRTD is presented to the inspection system (Extended Inspection Systems). The issuing State or Organization authorizes the Document Verifiers of the receiving States to manage the authorization of inspection systems within the limits defined by the Document Verifier Certificate. The MRTD’s chip shall protect the confidentiality and integrity of the sensitive private personal data even during transmission to the Extended Inspection System after Chip Authentication Version 1. 3.4.2 P.Personalization Personalization of the MRTD by issuing State or Organization only The issuing State or Organization guarantees the correctness of the biographical data, the printed portrait and the digitized portrait, the biometric reference data and other data of the logical MRTD with respect to the MRTD holder. The personalization of the MRTD for the holder is performed by an agent authorized by the issuing State or Organization only. This ST includes all OSPs from the PACE PP [PP0068], chap 3.3, namely P.Pre-Operational, P.Card_PKI, P.Trustworthy_PKI, P.Manufact and P.Terminal. Due to identical definitions and names they are also not repeated here. PP0068 application note 20: cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 33 of 98 4 Security objectives This chapter describes the security objectives for the TOE and the security objectives for the TOE environ- ment. The security objectives for the TOE environment are separated into security objectives for the devel- opment and production environment and security objectives for the operational environment. 4.1 Security Objectives for the TOE This section describes the security objectives for the TOE addressing the aspects of identified threats to be countered by the TOE and organizational security policies to be met by the TOE. 4.1.1 OT.Sens_Data_Conf Confidentiality of sensitive biometric reference data The TOE must ensure the confidentiality of the sensitive biometric reference data (EF.DG3 andEF.DG4) by granting read access only to authorized Extended Inspection Systems. The authorization of the inspection system is drawn from the Inspection System Certificate used forthe successful authentication and shall be a non-strict subset of the authorization defined in theDocument Verifier Certificate in the certificate chain to the Country Verifier Certification Authority of the issuing State or Organization. The TOE must ensure the confidentiality of the logical MRTD data during their transmission to the Extended Inspection System. The confidentiality of the sensitive biometric reference data shall be protected against attacks withhigh attack potential. 4.1.2 OT.Chip_Auth_Proof Proof of MRTD’s chip authenticity The TOE must support the General Inspection Systems to verify the identity and authenticity ofthe MRTD’s chip as issued by the identified issuing State or Organization by means of the Chip Authentication as defined in [TR-03110]. The authenticity proof provided by MRTD’s chip shall be protected against attacks with high attack potential. PP application note 9: The OT.Chip_Auth_Proof implies the MRTD’s chip to have (i) a unique identity as given by the MRTD’s Document Number, (ii) a secret to prove its identity by knowledge i.e. a private au- thentication key as TSF data. The TOE shall protect this TSF data to prevent their misuse. The terminal shall have the reference data to verify the authentication attempt of MRTD’s chip i.e. a certificate for the Chip Authentication Public Key that matches the Chip Authentication Private Key of the MRTD’s chip. This certif- icate is provided by (i) the Chip Authentication Public Key (EF.DG14) in the LDS [ICAODoc] and (ii) the hash value of the Chip Authentication Public Key in the Document Security Object signed by the Document Signer. This ST includes all Security Objectives for the TOE from the PACE PP [PP0068], chap 4.1, namely OT.Data_Integrity, OT.Data_Authenticity, OT.Data_Confidentiality, OT.Tracing, OT.Prot_Abuse-Func, OT.Prof_Inf_Leak, OT.Prot_Phys-Tamper, OT.Identification, OT.AC_Pers and OT.Prot_Malfunction. Due to identical definitions and names they are not repeated here as well. PP0068 application notes 21 – 23: The following Security Objective for the TOE is defined in addition to the objectives given by the Protection Profiles to cover the Active Authentication mechanism. 4.1.3 OT.Active_Auth_Proof Proof of travel document’s chip authenticity The TOE shall support the Basic Inspection Systems to verify the identity and authenticity of the travel doc- ument’s chip as issued by the identified issuing State or Organisation by means of the Active Authentication cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 34 of 98 as defined in [ICAODoc]. The authenticity proof provided by travel document’s chip shall be protected against attacks with high attack potential. 4.2 Security Objectives for the Operational Environment 4.2.1 Issuing State or Organization The issuing State or Organization will implement the following security objectives of the TOE environment. 4.2.1.1 OE.Auth_Key_Travel_Document Travel document Authentication Key The issuing State or Organisation has to establish the necessary public key infrastructure in order to (i) gen- erate the travel document’s Chip Authentication Key Pair, (ii) sign and store the Chip Authentication Public Key in the Chip Authentication Public Key data in EF.DG14 and (iii) support inspection systems of receiving States or Organisations to verify the authenticity of the travel document’s chip used for genuine travel doc- ument by certification of the Chip Authentication Public Key by means of the Document Security Object. Justification: This security objective for the operational environment is needed additionally to those from [PP0068] in order to counter the Threat T.Counterfeit as it specifies the pre-requisite for the Chip Authen- tication Protocol Version 1 which is one of the additional features of the TOE described only in the Protec- tion Profile [PP0056v2] and not in [PP0068]. 4.2.1.2 OE.Authoriz_Sens_Data Authorization for Use of Sensitive Biometric Reference Data The issuing State or Organisation has to establish the necessary public key infrastructure in order to limit the access to sensitive biometric reference data of travel document holders to authorized receiving States or Organisations. The Country Verifying Certification Authority of the issuing State or Organisation gener- ates card verifiable Document Verifier Certificates for the authorized Document Verifier only. Justification: This security objective for the operational environment is needed additionally to those from [PP0068] in order to handle the Threat T.Read_Sensitive_Data, the Organisational Security Policy P.Sensi- tive_Data and the Assumption A.Auth_PKI as it specifies the pre-requisite for the Terminal Authentication Protocol v.1 as it concerns the need of an PKI for this protocol and the responsibilities of its root instance. The Terminal Authentication Protocol v.1 is one of the additional features of the TOE described only in the Protection Profile [PP0056v2] and not in [PP0068]. 4.2.2 Receiving State or Organization The receiving State or Organization will implement the following security objectives of the TOE environ- ment. 4.2.2.1 OE.Exam_Travel_Document Examination of the travel document passport book The inspection system of the receiving State or Organisation must examine the travel document presented by the traveller to verify its authenticity by means of the physical security measures and to detect any ma- nipulation of the physical part of the travel document. The Basic Inspection System for global interoperabil- ity (i) includes the Country Signing CA Public Key and the Document Signer Public Key of each issuing State or Organisation, and (ii) implements the terminal part of PACE [ICAO_SAC] and/or the Basic Access Control [6]. Extended Inspection Systems perform additionally to these points the Chip Authentication Protocol Ver- sion 1 to verify the Authenticity of the presented travel document’s chip. Justification: This security objective for the operational environment is needed additionally to those from [PP0068] in order to handle the Threat T.Counterfeit and the Assumption A.Insp_Sys by demanding the Inspection System to perform the Chip Authentication protocol v.1. OE.Exam_Travel_Document also re- peats partly the requirements from OE.Terminal in [PP0068] and therefore also counters T.Forgery and A.Passive_Auth from [PP0068]. This is done because a new type of Inspection System is introduced in the cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 35 of 98 protection profile [PP0056v2] as the Extended Inspection System is needed to handle the additional fea- tures of a travel document with Extended Access Control. 4.2.2.2 OE.Prot_Logical_Travel_Document Protection of data from the logical travel document The inspection system of the receiving State or Organisation ensures the confidentiality and integrity of the data read from the logical travel document. The inspection system will prevent eavesdropping to their com- munication with the TOE before secure messaging is successfully established based on the Chip Authenti- cation Protocol Version 1. Justification: This security objective for the operational environment is needed additionally to those from [PP0068] in order to handle the Assumption A.Insp_Sys by requiring the Inspection System to perform se- cure messaging based on the Chip Authentication Protocol v.1. 4.2.2.3 OE.Ext_Insp_Systems: Authorization of Extended Inspection Systems The Document Verifier of receiving States or Organisations authorizes Extended Inspection Systems by cre- ation of Inspection System Certificates for access to sensitive biometric reference data of the logical travel document. The Extended Inspection System authenticates themselves to the travel document’s chip for access to the sensitive biometric reference data with its private Terminal Authentication Key and its Inspec- tion System Certificate. Justification: This security objective for the operational environment is needed additionally to those from [PP0068] in order to handle the Threat T.Read_Sensitive_Data, the Organisational Security Policy P.Sensi- tive_Data and the Assumption A.Auth_PKI as it specifies the pre-requisite for the Terminal Authentication Protocol v.1 as it concerns the responsibilities of the Document Verifier instance and the Inspection Sys- tems. This ST includes all Security Objectives of the TOE environment from the PACE PP [PP0068], chap. 4.2, namely OE.Legislative_Compliance, OE.Passive_Auth_Sign, OE.Personalisation, OE.Terminal, and OE.Travel_Document_Holder. Due to identical definitions and names they are not repeated here. PP0068 application note 24: The following objective for the environment was added: 4.2.2.4 OE.Active_Auth_Key_MRTD: The inspection system of the receiving State or Organisation must carry out Active Authentication to verify the Authenticity of the presented travel document’s chip. Justification: This security objective for the operational environment is needed additionally to those from [PP0068]and [PP0056v2] in order to handle the Threat T.Counterfeit. It neither mitigates a threat meant to be addressed by security objectives for the TOE – this is achieved by chip authentication alone - nor fulfils an OSP meant to be addressed by security objectives for the TOE. 4.3 Security Objective Rationale The following table provides an overview for security objectives coverage. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 36 of 98 OT.Sens_Data_Conf OT.Chip_Auth_Proof OT.AC_Pers 5 OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Tracing OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Identification OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.Active_Auth_Proof OE.Auth_Key_Travel_Document OE.Authoriz_Sens_Data OE.Exam_Travel_Document OE.Prot_Logical_Travel_Document OE.Ext_Insp_Systems OE.Personalisation OE.Passive_Auth_Sign OE.Terminal OE.Travel_Document_Holder OE.Legislative_Compliance OE.Active_Auth_Key_MRTD T.Read_Sensitive_Data x x x T.Counterfeit x x x x x T.Skimming6 x x x x T.Eavesdropping x T.Tracing x x T.Abuse-Func x T.Information_Leakage x T.Phys-Tamper x T.Malfunction x T.Forgery x x x x x x x x x P.Sensitive_Data x x x P.Personalisation x x x P.Manufact x P.Pre-Operational x x x x P.Terminal x x P.Card_PKI x P.Trustworthy_PKI x A.Insp_Sys x x A.Auth_PKI x x A.Passive_Auth x x Table 8: Overview of the security objectives coverage The OSP P.Personalisation “Personalisation of the travel document by issuing State or Organisation only” addresses the (i) the enrolment of the logical travel document by the Personalisation Agent as described in the security objective for the TOE environment OE.Personalisation “Personalisation of logical travel docu- ment”, and (ii) the access control for the user data and TSF data as described by the security objective OT.AC_Pers “Access Control for Personalisation of logical travel document”. Note the manufacturer equips the TOE with the Personalisation Agent Key(s) according to OT.Identification “Identification and Authenti- cation of the TOE”. The security objective OT.AC_Pers limits the management of TSF data and the manage- ment of TSF to the Personalisation Agent. The OSP P.Sensitive_Data “Privacy of sensitive biometric reference data” is fulfilled and the threat T.Read_Sensitive_Data “Read the sensitive biometric reference data” is countered by the TOE-objective OT.Sens_Data_Conf “Confidentiality of sensitive biometric reference data” requiring that read access to 5 The Objectives marked in italic letters are included from the claimed PACE-PP [PP0068]. They are listed for the complete overview of the security objectives. 6 Threats and assumptions included from the claimed PACE-PP [PP0068] are marked in italic letters. They are listed for the complete overview of threats and assumptions. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 37 of 98 EF.DG3 and EF.DG4 (containing the sensitive biometric reference data) is only granted to authorized inspec- tion systems. Furthermore it is required that the transmission of these data ensures the data’s confidenti- ality. The authorization bases on Document Verifier certificates issued by the issuing State or Organisation as required by OE.Authoriz_Sens_Data “Authorization for use of sensitive biometric reference data”. The Document Verifier of the receiving State has to authorize Extended Inspection Systems by creating appro- priate Inspection System certificates for access to the sensitive biometric reference data as demanded by OE.Ext_Insp_Systems “Authorization of Extended Inspection Systems”. The OSP P.Terminal “Abilities and trustworthiness of terminals” is countered by the security objective OE.Exam_Travel_Document additionally to the security objectives from PACE PP [PP0068]. OE.Exam_Travel_Document enforces the terminals to perform the terminal part of the PACE protocol. The threat T.Counterfeit “Counterfeit of travel document chip data” addresses the attack of unauthorized copy or reproduction of the genuine travel document's chip. This attack is thwarted by chip identification and authenticity proof required by OT.Chip_Auth_Proof “Proof of travel document’s chip authentication” using an authentication key pair to be generated by the issuing State or Organisation. The Public Chip Au- thentication Key has to be written into EF.DG14 and signed by means of Documents Security Objects as demanded by OE.Auth_Key_Travel_Document “Travel document Authentication Key”. According to OE.Exam_Travel_Document “Examination of the physical part of the travel document” the General Inspec- tion system has to perform the Chip Authentication Protocol Version 1 to verify the authenticity of the travel document’s chip. The threat T.Forgery “Forgery of data” addresses the fraudulent, complete or partial alteration of the User Data or/and TSF-data stored on the TOE or/and exchanged between the TOE and the terminal. Additionally to the security objectives from PACE PP [PP0068] which counter this threat, the examination of the pre- sented MRTD passport book according to OE.Exam_Travel_Document “Examination of the physical part of the travel document” shall ensure its authenticity by means of the physical security measures and detect any manipulation of the physical part of the travel document. The examination of the travel document addressed by the assumption A.Insp_Sys “Inspection Systems for global interoperability” is covered by the security objectives for the TOE environment OE.Exam_Travel_Document “Examination of the physical part of the travel document” which requires the inspection system to examine physically the travel document, the Basic Inspection System to implement the Basic Access Control, and the Extended Inspection Systems to implement and to perform the Chip Au- thentication Protocol Version 1 to verify the Authenticity of the presented travel document’s chip. The se- curity objectives for the TOE environment OE.Prot_Logical_Travel_Document “Protection of data from the logical travel document” require the Inspection System to protect the logical travel document data during the transmission and the internal handling. The assumption A.Passive_Auth “PKI for Passive Authentication” is directly covered by the security objec- tive for the TOE environment OE.Passive_Auth_Sign “Authentication of travel document by Signature” from PACE PP [PP0068] covering the necessary procedures for the Country Signing CA Key Pair and the Document Signer Key Pairs. The implementation of the signature verification procedures is covered by OE.Exam_Travel_Document “Examination of the physical part of the travel document”. The assumption A.Auth_PKI “PKI for Inspection Systems” is covered by the security objective for the TOE environment OE.Authorize_Sens_Data “Authorization for use of sensitive biometric reference data” re- quires the CVCA to limit the read access to sensitive biometrics by issuing Document Verifier certificates for authorized receiving States or Organisations only. The Document Verifier of the receiving State is required by OE.Ext_Insp_Systems “Authorization of Extended Inspection Systems” to authorize Extended Inspection Systems by creating Inspection System Certificates. Therefore, the receiving issuing State or Organisation has to establish the necessary public key infrastructure. In addition to the rationale given by the Protection Profiles, the threat T.Counterfeit“Conterfeit of travel document’s chip data” is thwarted through the chip by anidentification and authenticity proof required by OT.Active_Auth_Proof “Proof of travel document’s chip authentication” using an authentication key pair cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 38 of 98 to be generated by the issuing state or organisation. The Public Active Authentication Key has to be written into EF.DG15 and signed by means of Documents Security Objects as demanded by OE.Active_Auth_Key_MRTD “Travel Document ActiveAuthentication Key”. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 39 of 98 5 Extended Components Definition This security target uses components defined as extensions to CC part 2. Some of these components are defined in [PP0068], other components are defined in the protection profile [PP0056v2]. 5.1 Definition of the Family FIA_API To describe the IT security functional requirements of the TOE a sensitive family (FIA_API) of the Class FIA (Identification and authentication) is defined here. This family describes the functional requirements for the proof of the claimed identity for the authentication verification by an external entity where the other fam- ilies of the class FIA address the verification of the identity of an external entity. PP application note 10: The other families of the Class FIA describe only the authentication verification of users’ identity performed by the TOE and do not describe the functionality of the user to prove their iden- tity. [PP0056v2] defines the family FIA_API in the style of [CC_2] from a TOE point of view. FIA_API Authentication Proof of Identity Family behavior This family defines functions provided by the TOE to prove their identity and to be verified by anexternal entity in the TOE IT environment. Component leveling: FIA_API.1 Authentication Proof of Identity. Management: FIA_API.1 The following actions could be considered for the management functions in FMT: Management of authentication information used to prove the claimedidentity. Audit: There are no actions defined to be auditable. FIA_API.1 Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide a [assignment:authentication mechanism] to prove the iden- tity of the [assignment: authorized user or role]. This ST includes all Extended Component Definitions from the PACE PP [PP0068], chap. 5, namely FAU_SAS, FCS_RND, FMT_LIM, FPT_EMS. These definitions are taken over as described in [PP0068], therefore they are not repeated here. PP0068 application note 25: FIA_API Authentication Proof of Identity 1 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 40 of 98 6 Security Requirements The CC allows several operations to be performed on functional requirements; refinement, selection, as- signment, and iteration are defined in paragraph C.4 of Part 1 [CC_1] of the CC. Each of these operations is used in this ST and the underlying PP. Operations already performed in the underlying PPs [PP0056v2, PP0068] are uniformly marked by bold italic font style; for further information on details of the operation, please refer to [PP0068, PP0056v2]. Operations performed within this Security Target are marked by bold underlined font style; further infor- mation on details of the operation is provided in foot notes. 6.1 Security Definitions Definition of security attributes: Security Attribute Values Meaning Terminal Authenti- cation Status none (any Terminal) default role (i.e. without authorisation after start-up) CVCA roles defined in the certificate used for authentication (cf. [TR-03110]); Terminal is authenticated as Country Verify- ing Certification Authority after successful CA v.1 and TA v.1 DV (domestic) roles defined in the certificate used for authentication (cf. [TR-03110]); Terminal is authenticated as domestic Docu- ment Verifierafter successful CA v.1 and TA v.1 DV (foreign) roles defined in the certificate used for authentication (cf. [TR-03110]); Terminal is authenticated as foreign Docu- ment Verifier after successful CA v.1 and TA v.1 IS roles defined in the certificate used for authentication (cf. [TR-03110]); Terminal is authenticated as Extended In- spection System after successful CA v.1 and TA v.1 Terminal Authori- zation none DG4 (Iris) Read access to DG4: (cf. [TR-03110]) DG3 (Fingerprint) Read access to DG3: (cf. [TR-03110]) DG3 (Iris) / DG4 (Fin- gerprint) Read access to DG3 and DG4: (cf. [TR-03110]) Table 9: Definition of security attributes. The following table provides an overview of the keys and certificates used. Further keys and certificates are listed in [PP0068]. Name Abbrevia- tion Description TOE intrinsic secret cryptographic keys - Permanently or temporarily stored secret cryptographic ma- terial used by the TOE in order to enforce its security func- tionality. Country Verifying Certi- fication Authority Pri- vate Key SKCVCA The Country Verifying Certification Authority (CVCA) holds a private key (SKCVCA) used for signing the Document Verifier Certificates. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 41 of 98 Name Abbrevia- tion Description Country Verifying Certi- fication Authority Public Key PKCVCA The TOE stores the Country Verifying Certification Authority Public Key (PKCVCA) as part of the TSF data to verify the Docu- ment Verifier Certificates. The PKCVCA has the security attrib- ute Current Date as the most recent valid effective date of the Country Verifying Certification Authority Certificate or of a domestic Document Verifier Certificate. Country Verifying Certi- fication Authority Cer- tificate CCVCA The Country Verifying Certification Authority Certificate may be a self-signed certificate or a link certificate (cf. [PP0055] and Glossary). It contains (i) the Country Verifying Certifica- tion Authority Public Key (PKCVCA) as authentication reference data, (ii) the coded access control rights of the Country Veri- fying Certification Authority, (iii) the Certificate Effective Date and the Certificate Expiration Date as security attrib- utes. Document Verifier Cer- tificate CDV The Document Verifier Certificate CDV is issued by the Country Verifying Certification Authority. It contains (i) the Document Verifier Public Key (PKDV) as authentication reference data (ii) identification as domestic or foreign Document Verifier, the coded access control rights of the Document Verifier, the Certificate Effective Date and the Certificate Expiration Date as security attributes. Inspection System Cer- tificate CIS The Inspection System Certificate (CIS) is issued by the Docu- ment Verifier. It contains (i) as authentication reference data the Inspection System Public Key (PKIS), (ii) the coded access control rights of the Extended Inspection System, the Certifi- cate Effective Date and the Certificate Expiration Date as se- curity attributes. Chip Authentication Public Key Pair The Chip Authentication Public Key Pair (SKICC, PKICC) are used for Key Agreement Protocol: Diffie-Hellman (DH) according to RFC 2631 or Elliptic Curve Diffie-Hellman according to ISO 11770-3 [ISO11770-3]. Chip Authentication Public Key PKICC The Chip Authentication Public Key (PKICC) is stored in the EF.DG14 Chip Authentication Public Key of the TOE’s logical MRTD and used by the inspection system for Chip Authenti- cation of the MRTD’s chip. It is part of the user data provided by the TOE for the IT environment. Chip Authentication Pri- vate Key SKICC The Chip Authentication Private Key (SKICC) is used by the TOE to authenticate itself as authentic MRTD’s chip. It is part of the TSF data. Country Signing Certifi- cation Authority Key Pair Country Signing Certification Authority of the Issuing State or Organization signs the Document Signer Public Key Certifi- cate with the Country Signing Certification Authority Private Key and the signature will be verified by Receiving State or Organization (e.g. a Basic Inspection System) with the Coun- try Signing Certification Authority Public Key. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 42 of 98 Name Abbrevia- tion Description Document Signer Key Pairs Document Signer of the Issuing State or Organization signs the Document Security Object of the logical MRTD with the Document Signer Private Key and the signature will be veri- fied by a Basic Inspection Systems of the Receiving State or organization with the Document Signer Public Key. Chip Authentication Session Key Secure messaging Triple-DES key and Retail-MAC key agreed between the TOE and a GIS in result of the Chip Authentica- tion Protocol. PACE Session KEys KENC, KMAC Secure messaging encryption key and MAC computation key agreed between the TOE and an Inspection System in result of PACE. Active Authentication KeyPair The Active Authentication Key Pair (KPrAA, KPuAA) is used for the Active Authentication mechanism according to [ICAO- Doc]. Active Authentication Public Key KPuAA The Active Authentication Public Key (KPuAA) is stored in EF.DG15 and used by the inspection system for Active Au- thentication of the travel document’s chip. It is part of the user data provided by the TOE for the IT environment. A hash representation of DG15 (Public Key (KPuAA) info) is stored in the Document Security Object (SOD). Active Authentication Private Key KPrAA The Active Authentication Private Key (KPrAA) is used by the TOE to authenticate itself as authentic travel document’s chip. It is part of the TSF data. Table 10: Overview of the keys and certificates. PP application note 11: The Country Verifying Certification Authority identifies a Document Verifier as “do- mestic” in the Document Verifier Certificate if it belongs to the same State as the Country Verifying Certifi- cation Authority. The Country Verifying Certification Authority identifies a Document Verifier as “foreign” in the Document Verifier Certificate if it does not belong to the same State as the Country Verifying Certifi- cation Authority. From MRTD’s point of view the domestic Document Verifier belongs to the issuing State or Organization. 6.2 Security Functional Requirements for the TOE This section on security functional requirements for the TOE is divided into sub-section following the main security functionality. Note that this ST contains SFRs from PP0068 and PP0056v2. SFRs from the PACE PP [PP0068] are not repeated in PP0056v2 but listed in the following Table 11. Only those SFRs from PACE PP that are extended are written down in PP0056v2. SFRs taken directly from PACE PP [PP0068] FAU_SAS.1 FCS_CKM.1/DH_PACE FCS_CKM.47 7Please also refer to PP Application note 15 in this ST cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 43 of 98 FCS_COP.1/PACE_ENC FCS_COP.1/PACE_MAC FCS_RND.18 FIA_AFL.1/PACE FIA_UAU.6/PACE FDP_RIP.19 FDP_UCT.1/TRM10 FDP_UIT.1/TRM11 FMT_SMF.1 FMT_MTD.1/INI_ENA FMT_MTD.1/INI_DIS FMT_MTD.1/PA FPT_TST.1 FPT_FLS.1 FPT_PHP.3 FTP_ITC.1/PACE12 Table 11: SFRs taken from PACE PP 6.2.1 Class Cryptographic Support (FCS) The TOE shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” as specified below (Com- mon Criteria Part 2). The iterations are caused by different cryptographic key generation algorithms to be implemented and key to be generated by the TOE. FCS_CKM.1/DH-PACE Cryptographic key generation – Diffie-Hellman for 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: fulfilled by FCS_CKM.4 FCS_CKM.1.1/ DH_PACE The TSF shall generate cryptographic keys in accordance with a specified crypto- graphic key generation algorithm: based on the Diffie-Hellman key derivation Pro- tocol compliant to PKCS#3 or ECDH compliant to ISO 15946 with the domain pa- rameters provided in NIST DSS standard FIPS 186-3 [FIPS186-3] Appendix D or in 8Please also refer to PP Application note 26 in this ST 9Please also refer to PP Application note 15 in this ST 10Please also refer to PP Application note 35 in this ST 11Please also refer to PP Application note 35 in this ST 12Please also refer to PP Application note 25 in this ST cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 44 of 98 Brainpool ECC Standard Curves [Brainpool] chapters 3.1 to 3.513 with crypto- graphic key sizes of 1976 - 2048 bit or 256 and 320 bit, respectively14 that meet the following: [TR-03110] , Annex A.1. PP0068 application note 26: PP0068 application note 27: FCS_CKM.1/DH_PACE implicitly contains the requirements for the hashing functions used for key derivation by demanding compliance to [ICAO_SAC]. FCS_CKM.1/CA Cryptographic key generation – Diffie-Hellman for Chip Authentication session keys Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation]: fulfilled by FCS_COP.1/CA_ENCand FCS_COP.1/CA_MAC FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_CKM.1.1/CA The TSF shall generate cryptographic keys in accordance with a specified crypto- graphic key generation algorithm: Diffie-Hellman key derivation or ECDH protocol with the domain parameters provided in NIST DSS standard FIPS 186-3 [FIPS186- 3] Appendix D or in Brainpool ECC Standard Curves [Brainpool] chapters 3.1 to 3.515 with cryptographic key sizes of 1976 - 2048 bit or 256 and 320 bit, respec- tively16 that meet the following: based on the Diffie-Hellman key derivation pro- tocol compliant to [PKCS#3] and [TR-03110] or ECDH protocol compliant to ISO 15946 17 . PP Application note 12: FCS_CKM.1/CA implicitly contains the requirements for the hashing functions used for key derivation by demanding compliance to [TR-03110]. PP Application note 13: The TOE generates a shared secret value with the terminal during the Chip Authen- tication Protocol Version 1, see [TR-03110]. This protocol may be based on the Diffie-Hellman-Protocol com- pliant to PKCS#3 (i.e. modulo arithmetic based cryptographic algorithm, cf. [PKCS#3]) or on the ECDH com- pliant to TR-03111 (i.e. an elliptic curve cryptography algorithm) (cf. [TR-03111], for details). The shared secret value is used to derive the Chip Authentication Session Keys used for encryption and MAC computa- tion for secure messaging (defined in Key Derivation Function [TR-03110]). PP Application note 14:The PP application note was refined due to inconsistencies between [PP0056v2], [TR-03110] (part 3) and [ICAO_SAC]: a) The TOE uses SHA-1 to derive 128 (AES) bit session keys for secure messaging. 13[assignment: cryptographic key generation algorithm] 14 [assignment: cryptographic key sizes] 15[assignment: cryptographic key generation algorithm]. Please also note the remark in the JCOP user guid- ance manual [JCOP_UGM] on EC domain parameters. 16 [assignment: cryptographic key sizes] 17[selection: based on the Diffie-Hellman key derivation protocol compliant to [PKCS#3] and [TR-03110], based on an ECDH protocol compliant to [ISO 15946]] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 45 of 98 b) According to requirements given in section 4.2 of [ICAO_SAC] and section A.2.3 of [TR-03110] (part 3), the bit-length of the hash function shall be greater or equal to the bit-length of the de- rived key. For this reason the Chip Authentication Protocol implemented by the TOE uses SHA-256 to derive session keys for secure messaging based on AES with 192 and 256 bit keys. c) The Terminal Authentication implemented by the TOE supports SHA-1, SHA-224, and SHA-256. PP Application note 15: . The following SFR has been added with respect to the Active Authentication mechanism. FCS_CKM.1/AA Cryptographic key generation – Active Authentication key pair Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/AA The TSF shall generate cryptographic keys pair in accordance with a specified cryp- tographic key generation algorithm: RSA CRT key generation18 with cryptographic key sizes 1976 - 2048 bit19 that meet the following: RSA CRT key generation com- pliant with [ISO9796-2] 20 . Application Note: The Active Authentication key pair can either be generated in the TOE or imported by the Personalisation Manager (cf. FMT_MTD.1/AA). This SFR has been included in this security target in addition to the SFRs defined by the Protection Profiles claimed in clause 2.2. This extension does not conflict with the strict conformance to the claimed Protection Profiles. 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]: fulfilled by FCS_CKM.1/DH_PACE FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified crypto- graphic key destruction method physically overwriting the keys with zeros21 that meets the following: none22 . PP0068 application note 28: The TOE shall destroy the PACE session keys after detection of an error in a received command by verification of the MAC. The TOE shall clear the memory area of any session keys before starting the communication with the terminal in a new after-reset-session as required by FDP_RIP.1. 6.2.1.1 Cryptographic operation (FCS_COP.1) 18 [assignment: cryptographic key generation algorithm] 19 [assignment: cryptographic key sizes] 20 [assignment: list of standards] 21 [assignment: cryptographic key destruction method] 22 [assignment: list of standards] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 46 of 98 FCS_COP.1/PACE_ENC Cryptographic operation – Encryption / Decryption AES / 3DES 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]: fulfilled by FCS_CKM.1/DH_PACE FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_COP.1.1/ PACE_ENC The TSF shall perform secure messaging – encryption and decryption in accordance with a specified cryptographic algorithm: AES in CBC mode23 and cryptographic key size 128, 192, 256 bit24 that meets the following: compliant to [ICAO_SAC]. PP0068 application note 29:This SFR requires the TOE to implement the cryptographic primitive AES for secure messaging with encryption of transmitted data and encrypting the nonce in the first step of PACE. The related session keys are agreed between the TOE and the terminal as part of the PACE protocol accord- ing to the FCS_CKM.1/DH_PACE (PACE-KEnc). FCS_COP.1/PACE_MAC Cryptographic operation – MAC 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]: fulfilled by FCS_CKM.1/DH_PACE FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_COP.1.1/ PACE_MAC The TSF shall perform secure messaging – message authentication code in accord- ance with a specified cryptographic algorithm: AES-CMAC25 and cryptographic key size 128, 192, 256 bit26 that meets the following: [ICAO_SAC]. PP0068 application note 30: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with message authentication code over transmitted data. The related session keys are agreed between the TOE and the terminal as part of either the PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KMAC). FCS_COP.1/CA_ENC Cryptographic operation – Symmetric Encryption / Decryption 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 23 [assignment: cryptographic algorithm] 24 [assignment: cryptographic key sizes] 25 [assignment: cryptographic algorithm] 26 [assignment: cryptographic key sizes] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 47 of 98 FCS_CKM.1 Cryptographic key generation]: fulfilled by FCS_CKM.1/CA FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_COP.1.1/CA_ENC The TSF shall perform secure messaging – encryption and decryption in accordance with a specified cryptographic algorithm: AES27 and cryptographic key size 128, 192, 256 bit28 that meets the following: [ICAO_SAC]29 . PP Application note 16: This SFR requires the TOE to implement the cryptographic primitives (AES) for se- cure messaging with encryption of the transmitted data. The keys are agreed between the TOE and the terminal as part of the Chip Authentication Protocol Version 1 according to the FCS_CKM.1/CA. FCS_COP.1/CA_MAC Cryptographic operation – MAC 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]: fulfilled by FCS_CKM.1/CA FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_COP.1.1/CA_MAC The TSF shall perform secure messaging – message authentication code in accord- ance with a specified cryptographic algorithm: AES-CMAC30 and cryptographic key size 128, 192 and 256 bit31 that meets the following: [TR-03110]. PP Application note 18: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with encryption and message authentication code over the transmitted data. The key is agreed between the TSF by Chip Authentication Protocol Version 1 according to the FCS_CKM.1/CA. Furthermore the SFR is used for authentication attempts of a terminal as Personalisation Agent by means of the authen- tication mechanism. FCS_COP.1/SIG_VER Cryptographic operation – Signature verification by MRTD 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]: fulfilled by FCS_CKM.1/CA FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_COP.1.1/SIG_VER The TSF shall perform digital signature verification in accordance with a specified cryptographic algorithm: ECDSA with SHA-1, SHA-224 or SHA-256 and the domain parameters provided in NIST DSS standard FIPS 186-3 [FIPS186-3] Appendix D or 27 [assignment: cryptographic algorithm] 28 [assignment: cryptographic key sizes] 29 [assignment: list of standards] 30 [assignment: cryptographic algorithm] 31 [assignment: cryptographic key sizes] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 48 of 98 in Brainpool ECC Standard Curves [Brainpool] chapters 3.1 to 3.532 and crypto- graphic key sizes of 160, 192, 224, 256 and 320 bit33 that meet the following: [ISO15946]34 . PP Application note 17: Applied. The signature verification is used to verify the card verifiable certificates and the authentication attempt of the terminal creating a digital signature for the TOE challenge. FCS_COP.1/SIG_GEN Cryptographic operation – Signature generation by MRTD Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/SIG_GEN The TSF shall perform digital signature generation35 in accordance with a specified cryptographic algorithm: RSA-Digital Signature Scheme 136 and cryptographic key sizes of 1976 - 2048 bit37 that meet the following: [ISO9796-2]38 . Application Note: The TOE performs digital signature generation with RSA. This SFR has been included in this security target in addition to the SFRs defined by the Protection Profiles claimed in section 2.2. The digital signature creation is necessary to allow Active Authentication (AA). This extension does not conflict with the strict conformance to the claimed Protection Profiles. 6.2.1.2 Random Number Generation (FCS_RND.1) FCS_RND.1 Quality metric for random numbers Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet the AIS20 Class DRG.3 quality metric39 . PP0068 application note 31: This SFR requires the TOE to generate random numbers (random nonce) used for the authentication protocol (PACE) as required by FIA_UAU.4/PACE. 32 [assignment: cryptographic algorithm] 33 [assignment: cryptographic key sizes] 34 [assignment: list of standards] 35 [assignment: list of cryptographic operations] 36 [assignment: cryptographic algorithm] 37 [assignment: cryptographic key sizes] 38 [assignment: list of standards] 39 [assignment: a defined quality metric] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 49 of 98 Developer note: The corresponding platform SFR (FCS_RNG.1) states that the platform provides a deter- ministic random number generator that implements AIS20 [AIS20] class DRG.3. If initialized with a random seed using the PTRNG of the HW platform conform to class P2 in AIS31, the internal state of the RNG shall have at least 100 bit MIN entropy. The RNG provides forward secrecy and enhanced backward secrecy. Initialized with a random seed - initialization is initiated at startup when the first APDU is received using the PTRNG of the HW platform conform to class P2 in [AIS31] - generates output for which 235 strings of bit length 128 are mutually different with probability above 1-2-37 . 6.2.2 Class FIA Identification and Authentication PP Application note 19, extended to include Active Authentication: The following table provides an over- view of the authentication mechanisms used: Name SFR for the TOE Symmetric Authentication Mechanismfor Personalisation Agents FIA_UAU.4/PACE Chip Authentication Protocol FIA_API.1, FIA_UAU.5/PACE, FIA_UAU.6/EAC Terminal Authentication Protocol FIA_UAU.5/PACE PACE protocol FIA_UAU.1/PACE FIA_UAU.5/PACE FIA_AFL.1/PACE Passive Authentication FIA_UAU.5/PACE Active Authentication Mechanism FIA_API.1/AA Table 12: Overview on authentication SFR Note the Chip Authentication Protocol Version 1 as defined in this security target includes  the asymmetric key agreement to establish symmetric secure messaging keys between the TOE and the terminal based on the Chip Authentication Public Key and the Terminal Public Key used later in the Terminal Authentication Protocol Version 1,  the check whether the TOE is able to generate the correct message authentication code with the expected key for any message received by the terminal. The Chip Authentication Protocol v.1 may be used independent of the Terminal Authentication Protocol v.1. But if the Terminal Authentication Protocol v.1 is used the terminal shall use the same public key as pre- sented during the Chip Authentication Protocol v.1. The TOE shall meet the requirement “Timing of identification (FIA_UID.1)” as specified below (Common Criteria Part 2). FIA_AFL.1/PACE Authentication failure handling – PACE authentication using non-blocking authorisation data Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 50 of 98 FIA_AFL.1.1/PACE The TSF shall detect when 1040 unsuccessful authentication attempt occurs related to authentication attempts using the PACE password as shared password. FIA_AFL.1.2/PACE When the defined number of unsuccessful authentication attempts has been met, the TSF shall delay each of the following authentication attempt until the next successful authentication attempt by an increasing amount of time41 . PP0068 Application Note 32: The open assignment operation shall be performed according to a concrete implementation of the TOE, whereby actions to be executed by the TOE may either be common for all data concerned (PACE passwords, see [ICAO_SAC]) or for an arbitrary subset of them or may also separately be defined for each datum in question. Since all non-blocking authorisation data (PACE passwords) being used as a shared secret within the PACE protocol do not possess a sufficient entropy42, the TOE shall not allow a quick monitoring of its behaviour (e.g. due to a long reaction time) in order to make the first step of the skimming attack43 requiring an attack potential beyond high, so that the threat T.Tracing can be averted in the frame of the security policy of this ST. One of some opportunities for performing this operation might be ‘consecutively increase the reaction time of the TOE to the next authentication attempt using PACE pass- words’. FIA_API.1 Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide a Chip Authentication Protocol Version 1 according to [TR- 03110] to prove the identity of the TOE. PP Application note 30: This SFR requires the TOE to implement the Chip Authentication Mechanism v.1 specified in [TR-03110]. The TOE and the terminal generate a shared secret using the Diffie-Hellman Proto- col (DH or EC-DH) and two session keys for secure messaging in ENC_MAC mode according to [ICAODoc]. The terminal verifies by means of secure messaging whether the travel document’s chip was able or not to run his protocol properly using its Chip Authentication Private Key corresponding to the Chip Authentication Key (EF.DG14). FIA_API.1/AA Authentication Proof of Identity (Active Authentication) Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/AA The TSF shall provide the Active Authentication Mechanisms according to [ICAO- Doc]44 to prove the identity of the TOE45 . 40 [assignment: positive integer number] 41[assignment: list of actions] 42 ≥ 100 bits; a theoretical maximum of entropy which can be delivered by a character string is N*ld(C), whereby N is the length of the string, C – the number of different characters which can be used within the string. 43 guessing CAN or MRZ, see T.Skimming above 44 [assignment: authentication mechanism] 45 [assignment: authorized user or role] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 51 of 98 Application Note: The SFR FIA_API.1/AA has been included inthis security target in addition to the SFRs defined by the Protection Profiles claimed insection 2.2. This extension does not conflict with the strict conformance to the claimed Protection Profiles. FIA_UID.1/PACE Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/PACE The TSF shall allow 1. to establish the communication channel, 2. carrying out the PACE Protocol according to [ICAO_SAC], 3. to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, 4. to carry out the Chip Authentication Protocol v.1 according to [TR-03110], 5. to carry out the Terminal Authentication Protocol v.1 according to [TR- 03110], 6. to carry out the Active Authentication Mechanism46 on behalf of the user to be performed before the user is identified. FIA_UID.1.2/PACE The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. PP0068 application note 33: User identified after a successfully performed PACE protocol is a PACE authen- ticated BIS-PACE. Please note that neither CAN nor MRZ effectively represent secrets (but other PACE pass- words may do so), but are restricted-revealable; i.e. it is either the travel document holder itself or an au- thorised other person or device (BIS-PACE). PP Application note 20: The SFR FIA_UID.1/PACE in PP0056v2 covers the definition in PACE PP [PP0068] and extends it by EAC aspect 4. This extension does not conflict with the strict conformance to PACE PP. PP Application note 21: In the Phase 2 “Manufacturing of the TOE” the Manufacturer is the only user role known to the TOE which writes the Initialization Data and/or Pre-personalisation Data in the audit records of the IC. The travel document manufacturer may create the user role Personalisation Agent for transition from Phase 2 to Phase 3 “Personalisation of the travel document”. The users in role Personalisation Agent identify themselves by means of selecting the authentication key. After personalisation in the Phase 3 the PACE domain parameters, the Chip Authentication data and Terminal Authentication Reference Data are written into the TOE. The Inspection System is identified as default user after power up or reset of the TOE i.e. the TOE will run the PACE protocol, to gain access to the Chip Authentication Reference Data and to run the Chip Authentication Protocol Version 1. After successful authentication of the chip the terminal may identify itself as (i) Extended Inspection System by selection of the templates for the Terminal Authentica- tion Protocol Version 1 or (ii) if necessary and available by authentication as Personalisation Agent (using the Personalisation Agent Key). PP Application note 22: User identified after a successfully performed PACE protocol is a terminal. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted revealable; i.e. it is either the travel document holder itself or an authorised other person or device (Basic Inspection System with PACE). PP Application note 23: In the life-cycle phase ‘Manufacturing’ the Manufacturer is the only user role known to the TOE. The Manufacturer writes the Initialisation Data and/or Pre-personalisation Data in the audit 46 [assignment: list of TSF-mediated actions] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 52 of 98 records of the IC. Please note that a Personalisation Agent acts on behalf of the travel document Issuer under his and CSCA and DS policies. Hence, they define authentication procedure(s) for Personalisation Agents. The TOE must functionally support these authentication procedures being subject to evaluation within the assurance components ALC_DEL.1 and AGD_PRE.1. The TOE assumes the user role ‘Personalisa- tion Agent’, when a terminal proves the respective Terminal Authorisation Level as defined by the related policy (policies). FIA_UAU.1/PACE Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification FIA_UAU.1.1/PACE The TSF shall allow 1. to establish the communication channel, 2. carrying out the PACE Protocol according to [ICAO_SAC], 3. to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, 4. to identify themselves by selection of the authentication key, 5. to carry out the Chip Authentication Protocol v.1 according to [TR-03110], 6. to carry out the Terminal Authentication Protocol v.1 according to [TR- 03110], 7. to carry out the Active Authentication Mechanism 8. None47 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/PACE The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. PP0068 application note 34: . PP application note 24: The SFR FIA_UAU.1/PACE in this ST covers the definition in PACE PP [PP0068] and extends it by EAC aspect 5. This extension does not conflict with the strict conformance to PACE PP. PP application note 25: The user authenticated after a successfully performed PACE protocol is a terminal. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted revealable; i.e. it is either the travel document holder itself or an authorised other person or device (BIS-PACE).If PACE was successfully performed, secure messaging is started using the derived session keys (PACE-KMAC, PACE- KEnc), cf. FTP_ITC.1/PACE. FIA_UAU.4/PACE Single-use authentication of the Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.4.1/PACE The TSF shall prevent reuse of authentication data related to 1. PACE Protocol according to [ICAO_SAC] 2. Authentication Mechanism based on AES,48 47 [assignment: list of TSF-mediated actions] 48 [assignment: identified authentication algorithms] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 53 of 98 3. Terminal Authentication Protocol v.1 according to [TR-03110]49 PP0068 application note 35: For the PACE protocol, the TOE randomly selects a nonce s of 128 bits length being (almost) uniformly distributed. PP application note 26: The SFR FIA_UAU.4.1 in this ST covers the definition in PACE PP [PP0068] and ex- tends it by the EAC aspect 3. This extension does not conflict with the strict conformance to PACE PP. The generation of random numbers (random nonce) used for the authentication protocol (PACE) and Terminal Authentication as required by FIA_UAU.4/PACE is required by FCS_RND.1 from [PP0068]. PP application note 27: The authentication mechanisms may use either a challenge freshly and randomly generated by the TOE to prevent reuse of a response generated by a terminal in a successful authentication attempt. However, the authentication of Personalisation Agent may rely on other mechanisms ensuring protection against replay attacks, such as the use of an internal counter as a diversifier. FIA_UAU.5/PACE Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/PACE The TSF shall provide 1. PACE Protocol according to [ICAO_SAC], 2. Passive Authentication according to [ICAODoc], 3. Secure Messaging in MAC-ENC mode according to [ICAO_SAC], 4. Symmetric Authentication Mechanism based on AES, 5. Terminal Authentication Protocol v.1 1 according to [TR-03110]50 to support user authentication. FIA_UAU.5.2/PACE The TSF shall authenticate any user’s claimed identity according to the following rules: 1. Having successfully run the PACE protocol the TOE accepts only received commands with correct message authentication code sent by means of se- cure messaging with the key agreed with the terminal by means of the PACE protocol. 2. The TOE accepts the authentication attempt as Personalisation Agent by Au- thentication Mechanism with Personalization Agent Keys51. 3. After run of the Chip Authentication Protocol v. 1 the TOE accepts only re- ceived commands with correct message authentication code sent by means of secure messaging with key agreed with the terminal by means of the Chip Authentication Mechanism v. 1. 4. The TOE accepts the authentication attempt by means of the Terminal Au- thentication Protocol v.1 only if the terminal uses the public key presented during the Chip Authentication Protocol v.1 and the secure messaging estab- lished by the Chip Authentication Protocol v.1.52 49[assignment: identified authentication mechanism(s)] 50[selection: Triple-DES, AES or other approved algorithms] 51[selection: the Authentication Mechanism with Personalisation Agent Key(s)] 52 [assignment: rules describing how the multiple authentication mechanisms provide authentication] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 54 of 98 5. None.53 PP application note 28: The SFR FIA_UAU.5.1/PACE in this ST covers the definition in PACE PP [PP0068] and extends it by EAC aspects 4), 5), and 6). The SFR FIA_UAU.5.2/PACE in this ST covers the definition in PACE PP [PP0068] and extends it by EAC aspects 2), 3), 4) and 5). These extensions do not conflict with the strict conformance to PACE PP. PP0068 application note 36: Please note that Passive Authentication does not authenticate any TOE’s user, but provides evidence enabling an external entity (the terminal connected) to prove the origin of ePassport application. FIA_UAU.6/EAC Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/EAC The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authentication Protocol Version 1 shall be verified as being sent by the Inspection System. PP application note 29: The Password Authenticated Connection Establishment and the Chip Authentica- tion Protocol specified in [ICAODoc] include secure messaging for all commands exchanged after successful authentication of the Inspection System. The TOE checks by secure messaging in MAC_ENC mode each command based on a corresponding MAC algorithm whether it was sent by the successfully authenticated terminal (see FCS_COP.1/CA_MAC for further details). The TOE does not execute any command with incor- rect message authentication code. Therefore the TOE re-authenticates the user for each received command and accepts only those commands received from the previously authenticated user. FIA_UAU.6/PACE Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/PACE The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the PACE protocol shall be verified as being sent by the PACE terminal. PP0068 Application note 37:The PACE protocol specified in [ICAO-SAC] starts secure messaging used for all commands exchanged after successful PACE authentication. The TOE checks each command by secure mes- saging in encrypt-then-authenticate mode based on CMAC or Retail-MAC, whether it was sent by the suc- cessfully authenticated terminal (see FCS_COP.1/PACE_MAC for further details). The TOE does not execute any command with incorrect message authentication code. Therefore, the TOE re-authenticates the termi- nal connected, if a secure messaging error occurred, and accepts only those commands received from the initially authenticated terminal. 6.2.3 Class FDP User Data Protection The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below (Common Cri- teria Part 2). 53[assignment: rules describing how the multiple authentication mechanisms provide authentication] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 55 of 98 FDP_ACC.1/TRM Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/TRM The TSF shall enforce the Access Control SFP on terminals gaining access to the User data and data stored in EF.Sod of the logical travel document. PP Application note 31: The SFR FDP_ACC.1.1 in this ST covers the definition in PACE PP [PP0068] and ex- tends it by data stored in EF.SOD of the logical travel document. This extension does not conflict with the strict conformance to PACE PP. PP0068 application note 38: FDP_ACF.1/TRM Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/TRM The TSF shall enforce the Access Control SFP to objects based on thefollowing: 1. Subjects: a. Terminal, b. BIS-PACE, c. Extended Inspection System. 2. Objects: a. data EF.DG1, EF.DG2 and EF.DG5 to EF.DG16, EF.SOD and EF.COM of the logicalMRTD, b. data in EF.DG3 of the logical MRTD, c. data in EF.DG4 of the logical MRTD, d. all TOE intrinsic secret cryptographic keys stored in the travel document. 3. Security attributes: a. PACE Authentication, b. Terminal Authentication v.1, c. Authorization of the Terminal. FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an operation among con- trolled subjects and controlled objects is allowed: A BIS-PACE is allowed to read data objects from FDP_ACF.1.1/TRM according to [TR-03110] after a successful PACE authentication as required by FIA_UAU.1/PACE. FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the rule: 1. Any terminal being not authenticated as PACE authenticated BIS-PACE is not allowed to read, to write, to modify, to use any User Data stored on the travel document. 2. Terminals not using secure messaging are not allowed to read, to write, to modify, to use any data stored on the travel document. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 56 of 98 3. Any terminal being not successfully authenticated as Extended Inspection Sys- tem with the Read access to DG 3 (Fingerprint) granted by the relative certifi- cate holder authorization encoding is not allowed to read the data objects 2b) of FDP_ACF.1.1/TRM. 4. Any terminal being not successfully authenticated as Extended Inspection Sys- tem with the Read access to DG 4 (Iris) granted by the relative certificate holder authorization encoding is not allowed to read the data objects 2c) of FDP_ACF.1.1/TRM. 5. Nobody is allowed to read the data objects 2d) of FDP_ACF.1.1/TRM. 6. Terminals authenticated as CVCA or as DV are not allowed to read data in the EF.DG3 and EF.DG4. PP application note 32: The SFR FDP_ACF.1.1/TRM in this ST covers the definition in PACE PP [PP0068] and extends it by additional subjects and objects. The SFRs FDP_ACF.1.2/TRM and FDP_ACF.1.3/TRM in this ST cover the definition in PACE PP [PP0068]. The SFR FDP_ACF.1.4/TRM in this ST covers the definition in PACE PP [PP0068] and extends it by 3) to 6).These extensions do not conflict with the strict conformance to PACE PP. PP0068 application note 39: PP application note 33: The relative certificate holder authorization encoded in the CVC of the inspection system is defined in [TR-03110]. The TOE verifies the certificate chain established by the Country Verifying Certification Authority, the Document Verifier Certificate and the Inspection System Certificate (cf. FMT_MTD.3). The Terminal Authorization is the intersection of the Certificate Holder Authorization in the certificates of the Country Verifying Certification Authority, the Document Verifier Certificate and the In- spection System Certificate in a valid certificate chain. PP application note 34, PP0068 application note 40: Please note that the Document Security Object (SOD) stored in EF.SOD (see [ICAODoc]) does not belong to the user data, but to the TSF data. The Document Security Object can be read out by Inspection Systems using PACE, see [ICAO_SAC]. PP application note 35: FDP_UCT.1/TRM and FDP_UIT.1/TRM require the protection of the User Data trans- mitted from the TOE to the terminal by secure messaging with encryption and message authentication codes after successful Chip Authentication Version 1 to the Inspection System. The Password Authenticated Connection Establishment, and the Chip Authentication Protocol v.1 establish different key sets to be used for secure messaging (each set of keys for the encryption and the message authentication key). PP0068 application note 41: Please note that the control on the user data transmitted between the TOE and the PACE terminal is addressed by FTP_ITC.1/PACE. FDP_RIP.1 Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from54 the following objects: 1. Session Keys (immediately after closing related communication session), 2. the ephemeral private key ephem SKPICC PACE (by having generated a DH shared secret K) 54[selection: allocation of the resource to, deallocation of the resource from] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 57 of 98 3. None55 PP0068 application note 42: The functional family FDP_RIP possesses such a general character, so that it is applicable not only to user data (as assumed by the class FDP), but also to TSF-data; in this respect it is similar to the functional family FPT_EMS. Applied to cryptographic keys, FDP_RIP.1 requires a certain quality metric (‘any previous information content of a resource is made unavailable’) for key’s destruction in addi- tion to FCS_CKM.4 that merely requires a fact of key destruction according to a method/standard. FDP_UCT.1/TRM Basic data exchange confidentiality – MRTD Hierarchical to: No other components. Dependencies: FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]: fulfilled by FTP_ITC.1/PACE [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by FDP_ACC.1/TRM FDP_UCT.1.1/TRM The TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from unauthorized disclosure. FDP_UIT.1/TRM Data exchange integrity Hierarchical to: No other components. Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]: fulfilled by FTP_ITC.1/PACE [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by FDP_ACC.1/TRM FDP_UIT.1.1/TRM The TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay er- rors. FDP_UIT.1.2/TRM The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred. 6.2.4 Class FTP Trusted Path/Channels FTP_ITC.1/PACE Inter-TSF trusted channel after PACE Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/PACE The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2/PACE The TSF shall permit another trusted IT product to initiate communication via the trusted channel. FTP_ITC.1.3/PACE The TSF shall initiate enforce communication via the trusted channel for any data exchange between the TOE and the Terminal. 55[assignment: list of objects] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 58 of 98 PP0068 application note 43: The trusted IT product is the terminal. In FTP_ITC.1.3/PACE, the word “initiate” is changed to ‘enforce”, as the TOE is a passive device that can not initiate the communication. All the com- munication are initiated by the Terminal, and the TOE enforce the trusted channel. PP0068 application note 44: The trusted channel is established after successful performing the PACE pro- tocol (FIA_UAU.1/PACE). If the PACE was successfully performed, secure messaging is immediately started using the derived session keys (PACE-KMAC, PACE-KEnc): this secure messaging enforces preventing tracing while Passive Authentication and the required properties of operational trusted channel; the cryptographic primitives being used for the secure messaging are as required by FCS_COP.1/PACE_ENC and FCS_COP.1/PACE_MAC. The establishing phase of the PACE trusted channel does not enable tracing due to the requirements FIA_AFL.1/PACE. PP0068 application note 45: Please note that the control on the user data stored in the TOE is addressed by FDP_ACF.1/TRM. 6.2.5 Class FAU Security Audit FAU_SAS.1 Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide the Manufacturer with the capability to store the Initialisa- tion and Pre-Personalisation Data in the audit records. PP0068 application note 46: The Manufacturer role is the default user identity assumed by the TOE in the life cycle phase ‘manufacturing’. The IC manufacturer and the travel document manufacturer in the Manu- facturer role write the Initialisation and/or Pre-personalisation Data as TSF-data into the TOE. The audit records are usually write-only-once data of the travel document (see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also be such audit records which cannot be read out, but directly used by the TOE. 6.2.6 Class FMT Security Management FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. Dependencies: No Dependencies FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 1. Initialization, 2. Pre-personalization, 3. Personalization, 4. Configuration. PP application note 36:The SFR FMT_SMR.1/PACE provides basic requirements to the management of the TSF data. FMT_SMR.1/PACE Security roles Hierarchical to: No other components. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 59 of 98 Dependencies: FIA_UID.1 Timing of identification. FMT_SMR.1.1/PACE The TSF shall maintain the roles 1. Manufacturer, 2. Personalization Agent, 3. Terminal, 4. PACE authenticated BIS-PACE, 5. Country Verifying Certification Authority, 6. Document Verifier, 7. Domestic Extended Inspection System, 8. Foreign Extended Inspection System. FMT_SMR.1.2/PACE The TSF shall be able to associate users with roles. PP application note 37: The SFR FMT_SMR.1.1/PACE in this ST covers the definition in PACE PP [PP0068] and extends it by 5) to 8). This extension does not conflict with the strict conformance to PACE PP. PP application note 38: The SFR FMT_LIM.1 and FMT_LIM.2 address the management of the TSF and TSF data to prevent misuse of test features of the TOE over the life-cycle phases. PP0068 application note 47: For explanation on the role Manufacturer and Personalisation Agent please refer to the glossary of [PP0068]. The role Terminal is the default role for any terminal being recognised by the TOE as not PACE authenticated BIS-PACE (‘Terminal’ is used by the travel document presenter). The TOE recognises the travel document holder or an authorised other person or device (BIS-PACE) by using PACE authenticated BIS-PACE (FIA_UAU.1/PACE). FMT_LIM.1 Limited capabilities Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability. FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in con- junction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow, 1. User Data to be manipulated, 2. TSF data to be disclosed or manipulated, 3. software to be reconstructed, 4. substantial information about construction of TSF to be gathered which may enable other attacks, 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. FMT_LIM.2 Limited availability Hierarchical to: No other components. Dependencies: FMT_LIM.1 Limited capabilities. FMT_LIM.2.1 The TSF shall be designed in a manner that limits their availability so that in con- junction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow 1. User Data to be manipulated, 2. TSF data to be disclosed or manipulated, cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 60 of 98 3. software to be reconstructed, 4. substantial information about construction of TSF to be gathered which may enable other attacks, 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. PP application note 39: The formulation of “Deploying Test Features …” in FMT_LIM.2.1 might be a little bit misleading since the addressed features are no longer available (e.g. by disabling or removing the respective functionality). Nevertheless the combination of FMT_LIM.1 and FMT_LIM.2 is introduced to provide an op- tional approach to enforce the same policy. PP0068 application note 48: Note that the term “software” in item 4 of FMT_LIM.1.1 and FMT_LIM.2.1 refers to both IC Dedicated and IC Embedded Software. PP application note 40: The following SFR are iterations of the component Management of TSF data (FMT_MTD.1). The TSF data include but are not limited to those identified below. FMT_MTD.1/CVCA_INI Management of TSF data – Initialisation of CVCA Certificate and Current Date Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled byFMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/ CVCA_INI The TSF shall restrict the ability to write the 1. initial Country Verifying Certification Authority Public Key, 2. initial Country Verifying Certification Authority Certificate, 3. initial Current Date 4. None56 To the Personalization Agent57 . PP application note 41:. The initial Country Verifying Certification Authority Public Keys (and their updates later on) are used to verify the Country Verifying Certification Authority Link-Certificates. The initial Country Verifying Certification Authority Certificate and the initial Current Date is needed for verification of the certificates and the calculation of the Terminal Authorization. FMT_MTD.1/CVCA_UPD Management of TSF data – Country Verifying Certification Authority Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/ CVCA_UPD The TSF shall restrict the ability to update the 1. Country Verifying Certification Authority Public Key, 56[assignment: list of TSF data] 57 [assignment: the authorised identified roles] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 61 of 98 2. Country Verifying Certification Authority Certificate, to Country Verifying Certification Authority. PP application note 42: The Country Verifying Certification Authority updates its asymmetric key pair and distributes the public key be means of the Country Verifying CA Link-Certificates (cf. [TR-03110]). The TOE updates its internal trust-point if a valid Country Verifying CA Link-Certificates (cf. FMT_MTD.3) is provided by the terminal (cf. [TR-03110]). FMT_MTD.1/DATE Management of TSF data – Current date Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/DATE The TSF shall restrict the ability to modify the Current date to 1. Country Verifying Certification Authority, 2. Document Verifier, 3. Domestic Extended Inspection System. PP application note 43: The authorized roles are identified in their certificate (cf. [TR-03110]) and author- ized by validation of the certificate chain (cf. FMT_MTD.3). The authorized role of the terminal is part of the Certificate Holder Authorization in the card verifiable certificate provided by the terminal for the identifica- tion and the Terminal Authentication v.1 (cf. to [TR-03110]). FMT_MTD.1/CAPK Management of TSF data – Chip Authentication Private Key Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/CAPK The TSF shall restrict the ability to load58 the Chip Authentication Private Key to the Personalization Agent59 . PP application note 44: The verb “load” means here that the Chip Authentication Private Key is generated securely outside the TOE and written into the TOE memory. Thus according to PP application note 44 no additional key generation SFR is necessary. FMT_MTD.1/INI_ENA Management of TSF data – Writing of Initialization Data and Prepersonalization Data Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE 58 [selection: create, load] 59 [assignment: the authorised identified roles] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 62 of 98 FMT_MTD.1.1/ INI_ENA The TSF shall restrict the ability to write the Initialization Data and Prepersonaliza- tion Data to the Manufacturer. FMT_MTD.1/INI_DIS Management of TSF data – Disabling of Read Access to Initialization Data and Pre- personalization Data Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/ INI_DIS The TSF shall restrict the ability to disable read access for users to the Initialization Data to the Personalization Agent. PP0068 application note 49: The TOE may restrict the ability to write the Initialisation Data and the Pre- personalisation Data by (i) allowing writing these data only once and (ii) blocking the role Manufacturer at the end of the manufacturing phase. The Manufacturer may write the Initialisation Data (as required by FAU_SAS.1) including, but being not limited to a unique identification of the IC being used to trace the IC in the life cycle phases ‘manufacturing’ and ‘issuing’, but being not needed and may be misused in the ‘oper- ational use’. Therefore, read and use access to the Initialisation Data shall be blocked in the ‘operational use’ by the Personalisation Agent, when he switches the TOE from the life cycle phase ‘issuing’ to the life cycle phase ‘operational use’. FMT_MTD.1/KEY_READ Management of TSF data – Key Read Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/ KEY_READ The TSF shall restrict the ability to read the 1. PACE passwords, 2. Chip Authentication Private Key, 3. Personalization Agent Keys, to none. PP application note 45:The SFR FMT_MTD.1/KEY_READ in [PP0056v2] covers the definition in PACE PP [PP0068] and extends it by additional TSF data. This extension does not conflict with the strict conformance to PACE PP. FMT_MTD.1/PAManagement of TSF data – Personalisation Agent Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/PA The TSF shall restrict the ability to write the Document Security Object (SOD) to the Personalisation Agent. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 63 of 98 PP0068 application note 50: By writing SOD into the TOE, the Personalisation Agent confirms (on behalf of DS) the correctness and genuineness of all the personalisation data related. This consists of user- and TSF- data. FMT_MTD.1/AAManagement of TSF data – Active Authentication Private Key Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE FMT_MTD.1.1/AA The TSF shall restrict the ability to create or load60 the Active Authentication Pri- vate Key61 to the Manufacturer and the Personalisation Agent62 . Application Note: This SFR has been included in this security target in addition to the SFRs defined by the Protection Profiles claimed in section 2.2. This extension does not conflict with the strict conformance to the claimed Protection Profiles. FMT_MTD.3 Secure TSF data Hierarchical to: No other components. Dependencies: FMT_MTD.1 Management of TSF data FMT_MTD.3.1 The TSF shall ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol and the Access Control. Refinement: The certificate chain is valid if and only if 1. the digital signature of the Inspection System Certificate can be verified as correct with the public key of the Document Verifier Certificate and the expiration date ofthe Inspection System Certifi- cate is not before the Current Date of the TOE, 2. the digital signature of the Document Verifier Certificate can be verified as correct´with the public key in the Certificate of the Country Verifying Certification Authority and the expiration date of the Document Verifier Certificate is not before the Current Date of the TOE, 3. the digital signature of the Certificate of the Country Verifying Certification Authority can be ver- ified as correct with the public key of the Country Verifying Certification Authority known to the TOE and the expiration date of the Certificate of the Country Verifying Certification Authority is not before the Current Date of the TOE. The Inspection System Public Key contained in the Inspection System Certificate in a valid certificate chain is a secure value for the authentication reference data of the Extended Inspection System. The intersection of the Certificate Holder Authorizations contained in the certificates of a valid certificate chain is a secure value for Terminal Authorization of a successful authenticated Extended Inspection Sys- tem. 60 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 61 [assignment: list of TSF data] 62 [assignment: the authorised identified roles] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 64 of 98 The intersection of the Certificate Holder Authorizations contained in the certificates of a valid certificate chain is a secure value for Terminal Authorization of a successful authenticated Extended Inspection Sys- tem. PP application note 46: The Terminal Authentication Version 1 is used for Extended Inspection System as required by FIA_UAU.4/PACE and FIA_UAU.5/PACE. The Terminal Authorization is used as TSF data for ac- cess control required by FDP_ACF.1/TRM. 6.2.7 Class FPT Protection of the Security Functions The TOE shall prevent inherent and forced illicit information leakage for User Data and TSF Data. The secu- rity functional requirement FPT_EMS.1 addresses the inherent leakage. With respect to the forced leakage they have to be considered in combination with the security functional requirements “Failure with preser- vation of secure state (FPT_FLS.1)” and “TSFtesting (FPT_TST.1)” on the one hand and “Resistance to phys- ical attack (FPT_PHP.3)” on the other. The SFRs “Limited capabilities (FMT_LIM.1)”, “Limited availability (FMT_LIM.2)” and“Resistance to physical attack (FPT_PHP.3)” together with the SAR “Security architecture- description” (ADV_ARC.1) prevent bypassing, deactivation and manipulation of the security features or mis- use of TOE security functionality. FPT_EMS.1 TOE Emanation Hierarchical to: No other components. Dependencies: No Dependencies. FPT_EMS.1.1 The TOE shall not emit variations in power consumption or timing during com- mand execution63 in excess of non-useful information64 enabling access to 1. Chip Authentication Session Keys, 2. PACE Session Keys (PACE-KMAC, PACE-KENC), 3. the ephemeral private key ephem SKPICC-PACE, 4. none65 5. Personalization Agent Key(s), 6. Chip Authentication Private Key66 , 7. Active Authentication Private Key and 8. none67 . FPT_EMS.1.2 The TSF shall ensure any users are unable to use the following interface: smart card circuit contacts or contactless interface68 to gain access 1. Chip Authentication Session Keys, 2. PACE Session Keys (PACE-KMAC, PACE-KENC), 3. the ephemeral private key ephem SKPICC-PACE, 63 [assignment: types of emissions] 64 [assignment: specified limits] 65 [assignment: list of types of TSF data] 66 [assignment: type of users] 67 [assignment: list of types of user data] 68 [assignment: type of connection] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 65 of 98 4. none69 5. Personalization Agent Key(s), 6. Chip Authentication Private Key70 , 7. Active Authentication Private Key and 8. none71 . PP application note 47: The SFR FPT_EMS.1.1 in this ST covers the definition in PACE PP [PP0068] and ex- tends it by EAC aspects 1., 5. and 6. The SFR FPT_EMS.1.2 in this ST covers the definition in PACE PP [PP0068] and extends it by EAC aspects 4) and 5). These extensions do not conflict with the strict conformance to PACE PP. PP application note 48: PP0068 application note 51: The TOE shall prevent attacks against the listed secret data where the attack is based on external observable physical phenomena of the TOE. Such attacks may be observable at the interfaces of the TOE or may be originated from internal operation of the TOE or may be caused by an attacker that varies the physical environment under which the TOE operates. The set of measurable physical phenomena is influenced by the technology employed to implement the smart card. The travel document’s chip has to provide a smart card contactless interface, but may have also (not used by the terminal, but maybe by an attacker) sensitive contacts according to ISO/IEC7816-2 as well. Examples of measurable phe- nomena include, but are not limited to variations in the power consumption, the timing of signals and the electromagnetic radiation due to internal operations or data transmissions. FPT_FLS.1 Failure with preservation of secure state Hierarchical to: No other components. Dependencies: No Dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: 1. Exposure to out-of-range operating conditions where therefore a malfunction could occur, 2. Failure detected by TSF according to FPT_TST.1. 3. None.72 FPT_TST.1 TSF testing Hierarchical to: No other components. Dependencies: No Dependencies. FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up73 to demonstrate the correct operation of the TSF. FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of TSF data. 69 [assignment: list of types of TSF data] 70 [assignment: type of users] 71 [assignment: list of types of user data] 72 [assignment: list of types of failures in the TSF] 73 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self test should occur]] cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 66 of 98 FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code. PP0068 application note 52: If the travel document’s chip uses state of the art smart card technology, it will run some self tests at the request of an authorised user and some self tests automatically. E.g. a self test for the verification of the integrity of stored TSF executable code required by FPT_TST.1.3 may be executed during initial start-up by the ‘authorised user’ Manufacturer in the life cycle phase ‘Manufacturing’. Other self tests may automatically run to detect failures and to preserve the secure state according to FPT_FLS.1 in the phase ‘operational use’, e.g. to check a calculation with aprivate key by the reverse calculation with the corresponding public key as a countermeasure against Differential Failure Analysis. FPT_PHP.3 Resistance to physical attack Hierarchical to: No other components. Dependencies: No dependencies. FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing to the TSF by re- sponding automatically such that the SFRs are always enforced. PP0068 application note 53: The TOE will implement appropriate measures to continuously counter physi- cal manipulation and physical probing. Due to the nature of these attacks (especially manipulation) the TOE can by no means detect attacks on all of its elements. Therefore, permanent protection against these at- tacks is required ensuring that the TSP could not be violated at any time. Hence, “automatic response” means here (i) assuming that there might be an attack at any time and (ii) countermeasures are provided at any time. 6.3 Security Assurance Requirements for the TOE The requirements for the evaluation of the TOE and its development and operating environment are those taken from the Evaluation Assurance Level 4 (EAL4) and augmented by taking the following components: ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. PP application note 49: The TOE shall protect the assets against high attack potential under the assumption that the inspection system will prevent eavesdropping to their communication with the TOE before secure messaging is successfully established based on the Chip Authentication Protocol v.1 (OE.Prot_Logical_MRTD). If the TOE is operated in non-certified mode using the BAC-established communi- cation channel, the confidentiality of the standard data shall be protected against attackers with at least Enhanced-Basic attack potential (AVA_VAN.3). 6.4 Security Requirements Rationale 6.4.1 Security Functional Requirements Rationale The following table provides an overview for security functional requirements coverage. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 67 of 98 OT.Sens_Data_Conf OT.Chip_Auth_Proof OT.AC_Pers OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Tracing OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.Active_Auth_Proof FAU_SAS.174 X X FCS_CKM.1/DH_PACE X X X FCS_CKM.1/CA X X X X X X FCS_CKM.1/AA X FCS_CKM.4 X X X X X FCS_COP.1/PACE_ENC X FCS_COP.1/PACE_MAC X X FCS_COP.1/CA_ENC X X X X X FCS_COP.1/CA_MAC X X X X FCS_COP.1/SIG_VER X X FCS_COP.1/SIG_GEN X FCS_RND.1 X X X X FIA_AFL.1/PACE X FIA_API.1 X FIA_API.1/AA X FIA_UID.1/PACE75 X X X X X FIA_UAU.1/PACE X X X X X FIA_UAU.4/PACE X X X X X FIA_UAU.5/PACE X X X X X FIA_UAU.6/PACE X X X FIA_UAU.6/EAC X X X X X FDP_ACC.1/TRM X X X X FDP_ACF.1/TRM X X X X FDP_RIP.1 X X X FDP_UCT.1/TRM X X X FDP_UIT.1/TRM X X FMT_SMF.1 X X X X X X FMT_SMR.1/PACE X X X X X X FMT_LIM.1 X FMT_LIM.2 X FMT_MTD.1/INI_ENA X X FMT_MTD.1/INI_DIS X X FMT_MTD.1/CVCA_INI X FMT_MTD.1/CVCA_UPD X FMT_MTD.1/DATE X FMT_MTD.1/CAPK X X X FMT_MTD.1/PA X X X X 74 SFRs and security objectives from PACE PP [PP0068] are marked in italic letters. 75 SFRs from PACE PP [PP0068] which are extended in EAC PP are marked in bold letters. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 68 of 98 OT.Sens_Data_Conf OT.Chip_Auth_Proof OT.AC_Pers OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Tracing OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.Active_Auth_Proof FMT_MTD.1/AA X FMT_MTD.1/KEY_READ X X X X X X FMT_MTD.3 X FPT_EMS.1 X X FPT_TST.1 X X FPT_FLS.1 X X FPT_PHP.3 X X X FTP_ITC.1/PACE X X X X Table 13: Overview of the security functional requirements coverage. This security target claims strict conformance to the Protection Profiles given insection 2.2. Therefore this security target includes the Security Requirements Rationale of the Protection Profiles as summarized above; for details on the Rationale please refer to the Protection Profiles [PP0056v2] and [PP0068]. The security objective OT.Active_Auth_Proof “Proof of travel document’s chipauthenticity” is ensured by the Active Authentication Mechanism [ICODoc] provided by FIA_API.1/AA proving the identity of the TOE. The Active Authentication Protocol defined by FIA_API.1/AA is performed using a TOE internally stored con- fidential private key as required by FMT_MTD.1/AA. This key can either be written to the TOE as defined by FMT_MTD.1/AA or created on the TOE itself as supported by FCS_CKM.1/AA. The Active Authentication Protocol requires additional TSF according to FCS_COP.1/SIG_GEN. 6.4.2 Dependency Rationale The dependency analysis for the security functional requirements shows that the basis for mutual support and internal consistency between all defined functional requirements is satisfied. All dependencies between the chosen functional components are analyzed, and non-dissolved dependencies are appropriately ex- plained. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 69 of 98 SFR Dependencies Support of the Dependencies FAU_SAS.1 No dependencies. n.a. FCS_CKM.1/DH_PACE [FCS_CKM.2 Cryptographic key dis- tribution or FCS_COP.1 Cryptographic opera- tion], FCS_CKM.4 Cryptographic key de- struction Justification 2 for non-satisfied dependencies Fulfilled by FCS_CKM.4 FCS_CKM.1/CA [FCS_CKM.2 Cryptographic key dis- tribution or FCS_COP.1 Cryptographic opera- tion], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_COP.1/CA_ENC, and FCS_COP.1/CA_MAC, Fulfilled by FCS_CKM.4 FCS_CKM.1/AA [FCS_CKM.2 Cryptographic key dis- tribution or FCS_COP.1 Cryptographic opera- tion], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_COP.1/SIG_GEN, Justification 3 for non-satisfied dependencies FCS_CKM.4 from[PP0068] [FDP_ITC.1 Import of user data with- out security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key gen- eration] Fulfilled by FCS_CKM.1/DH_PACE, FCS_CKM.1/AA and FCS_CKM.1/CA FCS_COP.1/PACE_ENC [FDP_ITC.1 Import of user data with- out security attributes, FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key gen- eration], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_CKM.1/DH_PACE, Fulfilled by FCS_CKM.4 FCS_COP.1/PACE_MAC [FDP_ITC.1 Import of user data with- out security attributes, FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key gen- eration], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_CKM.1/DH_PACE, Fulfilled by FCS_CKM.4 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 70 of 98 FCS_COP.1/CA_ENC [FDP_ITC.1 Import of user data with- out security attributes, FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographickey gener- ation], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_CKM.1/CA, Fulfilled by FCS_CKM.4 FCS_COP.1/CA_MAC [FDP_ITC.1 Import of user data with- out security attributes, FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key gen- eration], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_CKM.1/CA, Fulfilled by FCS_CKM.4 FCS_COP.1/SIG_VER [FDP_ITC.1 Import of user data with- out security attributes, FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key gen- eration], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_CKM.1/CA, Fulfilled by FCS_CKM.4 FCS_COP.1/SIG_GEN [FDP_ITC.1 Import of user data with- out security attributes, FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key gen- eration], FCS_CKM.4 Cryptographic key de- struction Fulfilled by FCS_CKM.1/AA, Fulfilled by FCS_CKM.4 FCS_RND.1 No dependencies n.a. FIA_AFL.1/PACE FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1/PACE FIA_UID.1/PACE No dependencies n.a. FIA_UAU.1/PACE FIA_UID.1 Timing ofidentfication Fulfilled by FIA_UID.1/PACE FIA_UAU.4/PACE No dependencies n.a. FIA_UAU.5/PACE No dependencies n.a. FIA_UAU.6/EAC No dependencies n.a. FIA_API.1 No dependencies n.a. FDP_ACC.1/TRM FDP_ACF.1 Security attribute based access control Fulfilled by FDP_ACF.1/TRM cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 71 of 98 FDP_ACF.1/TRM FDP_ACC.1 Subset accesscontrol, FMT_MSA.3 Static attribute initiali- zation Fulfilled by FDP_ACC.1/TRM, Justification 1 for non-satisfied dependencies FDP_RIP.1 No dependencies n.a. FDP_UCT.1/TRM [FTP_ITC.1 Inter-TSF trusted chan- nel, or FTP_TRP.1 Trusted path] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] Fulfilled by FTP_ITC.1/PACE Fulfilled by FDP_ACC.1/TRM FDP_UIT.1/TRM [FTP_ITC.1 Inter-TSF trusted chan- nel, or FTP_TRP.1 Trusted path] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] Fulfilled by FTP_ITC.1/PACE Fulfilled by FDP_ACC.1/TRM FMT_SMF.1 No dependencies n.a. FMT_SMR.1/PACE FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1/PACE FMT_LIM.1 FMT_LIM.2 Fulfilled by FMT_LIM.2 FMT_LIM.2 FMT_LIM.1 Fulfilled by FMT_LIM.1 FMT_MTD.1/INI_ENA FMT_SMF.1 Specification of man- agement functions FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.1/INI_DIS FMT_SMF.1 Specification of man- agement functions FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.1/CVCA_INI FMT_SMF.1 Specification of man- agement functions, FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.1/CVCA_UPD FMT_SMF.1 Specification of man- agement functions, FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.1/DATE FMT_SMF.1 Specification of man- agement functions, FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.1/CAPK FMT_SMF.1 Specification of man- agement functions, FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 72 of 98 FMT_MTD.1/ PA FMT_SMF.1 Specification of man- agement functions FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.1/AA FMT_SMF.1 Specification of man- agement functions, FMT_SMR.1 Security roles Fulfilled by FMT_SMF.1 Fulfilled by FMT_SMR.1/PACE FMT_MTD.3 FMT_MTD.1 Fulfilled by FMT_MTD.1/CVCA_INI andFMT_MTD.1/CVCA_UPD FPT_EMS.1 No dependencies n.a. FTP_ITC.1/PACE No dependencies n.a. Table 14: Dependencies between the SFR for the TOE Justifications for non-satisfied dependencies between the SFR for TOE: No. 1: The access control TSF according to FDP_ACF.1/TRM uses security attributes which are defined during the personalisation and are fixed over the whole life time of the TOE. No management of these security attribute (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary here. No. 2: A Diffie-Hellman key agreement is used in order to have no key distribution, therefore FCS_CKM.2 makes no sense in this case.76 No. 3: The Active Authentication key pair cannot be deleted or regenerated. 6.4.3 Security Assurance Requirements Rationale This security target claims strict conformance to the Protection Profiles given insection 2.2. Therefore this security target includes the Security Assurance Requirements Rationale of the Protection Profiles without repeating these here. 6.4.4 Security Requirements – Mutual Support and Internal Consistency This security target claims strict conformance to the Protection Profiles given insection 2.2. Therefore this security target includes the analysis of the internal consistency of the Security Requirements of the Protec- tion Profiles without repeating these here. As the complete Security Problem Definition, the Extended Components and the Security Functional Re- quirements have also been included, the consistency analysis of the Protection Profiles is also valid for this security target. The additions made to include the Active Authentication Mechansim have been integrated in a consistent way to the model designed by the Protection Profiles, e. g. by using the subject, object and operation defi- nitions. Inconsistency between functional and assurance requirements could only arise if there are functional-as- surance dependencies which are not met, a possibility which has been shown not to arise in sections 6.3.2 Dependency Rationale and 6.3.3 Security Assurance Requirements Rationale. Furthermore, as also dis- cussed in section 6.3.3 Security Assurance Requirements Rationale, the chosen assurance components are adequate for the functionality of the TOE. So the assurance requirements and security functional requirements support each other and there are no inconsistencies between the goals ofthese two groups of security requirements. 76 This justification was taken from [PP0068]. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 73 of 98 7 TOE summary specification (ASE_TSS) 7.1 TOE Security Functionality 7.1.1 TSF_Access: Access Control This security functionality manages the access to objects (files, directories, data and secrets) stored in the applet’s file system. It also controls write access of initialization, pre-personalization and personalization data. Access control for initialization and pre-personalization in Phase 2 – while the actual applet is not yet present – is based on the card manager of the underlying JCOP Java Card platform (SF.AccessControl, SF.I&A). Access is granted (or denied) in accordance to access rights that depend on appropriate identification and authentication mechanisms. TSF_Access covers the following SFRs:  FIA_UID.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to carry out the Chip Authentication Protocol, to carry out the Terminal Au- thentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is identified. FIA_UID.1.2 requires that the TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. TSF_Access realizes the appropriate control of the access rights, TSF_Auth the authentication mechanisms.  FIA_UAU.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to identify themselves by selection of the authentication key, to carry out the Chip Authentication Protocol, to carry out the Terminal Authentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is au- thenticated. FIA_UAU.1.2 requires that the TSF shall require each user to be successfully authenti- cated before allowing any other TSF-mediated actions on behalf of that user. TSF_Access realizes the appropriate control of the access rights.  FIA_UAU.4/PACE requires that the TSF shall prevent reuse of authentication data related to the PACE Protocol, the Terminal Authentication Protocol, and the Authentication Mechanism based on AES. TSF_Access realizes the appropriate control of the access rights.  FIA_UAU.5.1/PACE requires that the TSF shall provide the PACE Protocol, Passive Authentication, Terminal Authentication, Secure messaging in MAC-ENC mode, Symmetric Authentication Mecha- nism based on AES, and the Terminal Authentication Protocol to support user authentication. FIA_UAU.5.2/PACE requires that the TSF shall authenticate any user’s claimed identity according to specified rules. TSF_Access realizes the appropriate control of the access rights.  FIA_UAU.6/PACE requires that the TSF shall re-authenticate the user under the condition that each command sent to the TOE after successful run of the PACE Protocol shall be verified as being sent by the terminal. TSF_Access realizes the appropriate control of the access rights.  FIA_UAU.6/EAC requires that the TSF shall re-authenticate the user under the condition that each command sent to the TOE after successful run of the Chip Authentication Protocol shall be verified as being sent by the Inspection System. TSF_Access realizes the appropriate control of the access rights.  FDP_ACC.1/TRMrequires that the TSF shall enforce the Access Control SFP on terminals gaining ac- cess to the User data and data stored in EF.Sod of the logical travel document.. TSF_Access realizes the appropriate control of the access rights. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 74 of 98  FDP_ACF.1/TRM:FDP_ACF.1.1 requires that the TSF shall enforce the Access Control SFP to objects based on Subjects (Terminal,BIS-PACE, Extended Inspection System), Objects (data EF.DG1, EF.DG2 and EF.DG5 to EF.DG16, EF.SOD and EF.COM of the logical MRTD, data in EF.DG3 of the logical MRTD, data in EF.DG4 of the logical MRTD, all TOE intrinsic secret cryptographic keys stored in the travel document) and Security attributes (PACE Authentication,Terminal Authentication v.1,Author- ization of the Terminal). FDP_ACF.1.2 requires that the TSF shall enforce the following rules to de- termine if an operation among con-trolled subjects and controlled objects is allowed: a BIS-PACE is allowed to read data objects from FDP_ACF.1.1/TRM according to [TR-03110] after a successful PACE authentication as required by FIA_UAU.1/PACE. FDP_ACF.1.3 requires that the TSF shall ex- plicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 requires that the TSF shall explicitly deny access of subjects to objects based on the rules: (1.) Any terminal being not authenticated as PACE authenticated BIS-PACE is not allowed to read, to write, to modify, to use any User Data stored on the travel document; (2) Terminals not using secure messaging are not allowed to read, to write, to modify, to use any data stored on the travel document; (3) Any terminal being not successfully authenticated as Extended Inspection Sys- tem with the Read access to DG 3 (Fingerprint) granted by the relative certificate holder authoriza- tion encoding is not allowed to read the data objects 2b) of FDP_ACF.1.1/TRM; (4) any terminal being not successfully authenticated as Extended Inspection System with the Read access to DG 4 (Iris) granted by the relative certificate holder authorization encoding is not allowed to read the data objects 2c) of FDP_ACF.1.1/TRM; (5) nobody is allowed to read the data objects 2d) of FDP_ACF.1.1/TRM; (6) terminals authenticated as CVCA or as DV are not allowed to read data in the EF.DG3 and EF.DG4.TSF_Access realizes the appropriate control of the access rights.  FDP_UCT.1/TRM requires that the TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from unauthorized disclosure. TSF_Access realizes the appropriate control of the access rights.  FDP_UIT.1/TRM requires that the TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay er- rors. FDP_UIT.1.2 requires that the TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred. TSF_Access realizes the appropriate con- trol of the access rights.  FMT_SMR.1/PACE requires that the TSF shall maintain the roles (1.) Manufacturer , (2.) Personali- zation Agent , (3) Terminal, (4) PACE authenticated BIS-PACE, (5) Country Verifying Certification Authority, (6) Document Verifier, (7) Domestic Extended Inspection System, (8) Foreign Extended Inspection System. FMT_SMR.1.2 requires that the TSF shall be able to associate users with roles. TSF_Access realizes the appropriate control of the access rights.  FMT_LIM.1 requires that the TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow (1) User Data to be manipulated, (2) TSF data to be disclosed or manipulated, (3) software to be reconstructed, (4) substantial information about con- struction of TSF to be gathered which may enable other attacks, (5) sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. This is realized by TSF_Access.  FMT_LIM.2 requires that the TSF shall be designed in a manner that limits their availability so that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow (1) User Data to be manipulated, (2) TSF data to be disclosed or manipulated, (3) software to be reconstructed, (4) substantial information about con- struction of TSF to be gathered which may enable other attacks, (5) sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. This is realized by TSF_Access. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 75 of 98  FMT_MTD.1.1/CVCA_INI requires that the TSF shall restrict the ability to write the (1.) initial Coun- try Verifying Certification Authority Public Key, the (2.) initial Country Verifying Certification Author- ity Certificate, and the (3.) initial Current Date to the Personalization Agent. TSF_Access realizes the appropriate control of the access rights.  FMT_MTD.1.1/CVCA_UPD requires that the TSF shall restrict the ability to update the (1.) Country Verifying Certification Authority Public Key and the (2.) Country Verifying Certification Authority Certificate to the Country Verifying Certification Authority. TSF_Access realizes the appropriate con- trol of the access rights.  FMT_MTD.1.1/DATE requires that the TSF shall restrict the ability to modify the Current date to the (1.) Country Verifying Certification Authority, the (2.) Document Verifier, and the (3.) Domestic Ex- tended Inspection System. TSF_Access realizes the appropriate control of the access rights.  FMT_MTD.1.1/CAPK requires that the TSF shall restrict the ability to load the Chip Authentication Private Key to the Personalization Agent. TSF_Access realizes the appropriate control of the access rights.  FMT_MTD.1.1/KEY_READ requires that the TSF shall restrict the ability to read the (1.) PACE pass- words, the (2.) Chip Authentication Private Key, and the (3.) Personalization Agent Keys to none. TSF_Access realizes the appropriate control of the access rights.  FMT_MTD.1/AA requires that the TSF shall restrict the ability to create or load the Active Authen- tication Private Key to the Manufacturer and the Personalisation Agent. TSF_Access realizes the appropriate control of the access rights.  FMT_MTD.1/PA requires that the TSF shall restrict the ability to write the Document Security Object (SOD) to the Personalisation Agent. TSF_Access realizes the appropriate control of the access rights.  FIA_AFL.1/PACE requires that the TOE shall detect when 10 unsuccessful authentication attempts have occured related to authentication attempts using the PACE password, and that there shall be an delay by an increasing amount of time after each of the following authentication attempt until the next successful authentication attempt has happened. This is realized by TSF_Access.  FTP_ITC.1/PACE: FTP_ITC.1.1/PACE requires that the TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure; FTP_ITC.1.2/PACE requires that the TSF shall permit another trusted IT product to initiate communication via the trusted channel, and FTP_ITC.1.3/PACE re- quires that the TSF shall initiate enforce communication via the trusted channel for any data ex- change between the TOE and the Terminal. The according access rights are realized by TSF_Access. 7.1.2 TSF_Admin: Administration This Security Functionality manages the storage of manufacturing data, pre-personalization data and per- sonalization data. This storage area is a write-only-once area and write access is subject to Manufacturer or Personalization Agent authentication. Management of manufacturing and pre-personalization data in Phase 2 – while the actual applet is not yet present – is based on the card manager of the underlying JCOP Java Card platform (SF.SecureManagement); also Audit functionality is based on JCOP functionality (SF.Audit). During Operational Use phase, read access is only possible after successful authentication. TSF_Admin covers the following SFRs:  FAU_SAS.1: FAU_SAS.1 requires that the TSF shall provide the Manufacturer with the capability to store the Initialisation and Pre-Personalisation Data in the audit records. This is realized by TSF.Admin. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 76 of 98  FMT_SMF.1:FMT_SMF.1.1 requires that the TSF shall be capable of performing the following man- agement functions: (1.) Initialization , (2.) Pre-personalization , (3.) Personalization, (4) Configura- tion. This is realized within TSF_Admin.  FMT_SMR.1/PACE requires that the TSF shall maintain the roles (1.) Manufacturer , (2.) Personali- zation Agent , (3) Terminal, (4) PACE authenticated BIS-PACE, (5) Country Verifying Certification Authority, (6) Document Verifier, (7) Domestic Extended Inspection System, (8) Foreign Extended Inspection System. FMT_SMR.1.2 requires that the TSF shall be able to associate users with roles. This is realized within TSF_Admin.  FMT_LIM.1 requires that the TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow (1) User Data to be manipulated, (2) TSF data to be disclosed or manipulated, (3) software to be reconstructed, (4) substantial information about con- struction of TSF to be gathered which may enable other attacks, (5) sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. This is realized by TSF_Admin.  FMT_LIM.2 requires that the TSF shall be designed in a manner that limits their availability so that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow (1) User Data to be manipulated, (2) TSF data to be disclosed or manipulated, (3) software to be reconstructed, (4) substantial information about con- struction of TSF to be gathered which may enable other attacks, (5) sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. This is realized by TSF_Admin.  FMT_MTD.1.1/CVCA_INI requires that the TSF shall restrict the ability to write the (1.) initial Coun- try Verifying Certification Authority Public Key, the (2.) initial Country Verifying Certification Author- ity Certificate, and the (3.) initial Current Dateto the Personalization Agent. This is realized within TSF_Admin.  FMT_MTD.1.1/CVCA_UPD requires that the TSF shall restrict the ability to update the (1.) Country Verifying Certification Authority Public Key and the (2.) Country Verifying Certification Authority Certificate to the Country Verifying Certification Authority. This is realized within TSF_Admin.  FMT_MTD.1.1/DATE requires that the TSF shall restrict the ability to modify the Current date to the (1.) Country Verifying Certification Authority, the (2.) Document Verifier, and the (3.) Domestic Ex- tended Inspection System. This is realized within TSF_Admin.  FMT_MTD.1.1/CAPK requires that the TSF shall restrict the ability to load the Chip Authentication Private Key to the Personalization Agent. This is realized within TSF_Admin.  FMT_MTD.1/AA requires that the TSF shall restrict the ability to create or load the Active Authen- tication Private Key to the Manufacturer and the Personalisation Agent. This is realized within TSF_Admin.  FMT_MTD.1/PA requires that the TSF shall restrict the ability to write the Document Security Object (SOD) to the Personalisation Agent. This is realized within TSF_Admin. 7.1.3 TSF_Secret: Secret key management This Security Functionality ensures secure management of secrets such as cryptographic keys. This covers secure key storage, access to keys as well as secure key deletion. These functions make use of SF.CryptoKey of the underlying JCOP Java Card OS. TSF_Secret covers the following SFRs:  FMT_MTD.1.1/CAPK requires that the TSF shall restrict the ability to load the Chip Authentication Private Key to the Personalization Agent. This is realized by TSF_Admin, TSF_Access and TSF_OS. This is realized within TSF_Secret. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 77 of 98  FMT_MTD.1/KEY_READ requires that the TSF shall restrict the ability to read (1.) the PACE pass- words, (2.) the Chip Authentication Private Key, and (3.) the Personalization Agent Keys to none. This is realized within TSF_Secret.  FMT_MTD.1/PA requires that the TSF shall restrict the ability to write the Document Security Ob- ject (SOD) to the Personalisation Agent. This is realized within TSF_Secret.  FMT_MTD.1/AA requires that the TSF shall restrict the ability to create or load the Active Authen- tication Private Key to the Manufacturer and the Personalisation Agent. This is realized within TSF_Secret. 7.1.4 TSF_Crypto: Cryptographic operations This Security Functionality performs high level cryptographic operations. The implementation is based on the Security Functionalities provided by TSF_OS. TSF_Crypto covers the following SFRs:  FCS_CKM.1/DH_PACE and FCS_CKM.1/CA require that the TSF shall generate cryptographic keys based on the Diffie-Hellman key derivation Protocol compliant to PKCS#3 with cryptographic key sizes of 1976 - 2048 bit, or ECDH compliant to ISO 15946 with specific domain parameters and with cryptographic key sizes of 256 and 320 bit, meeting [TR-03110], Annex A.1. This is realized within TSF_Crypto (Diffie-Hellman) and TSF_OS (ECDH).  FCS_CKM.1/AA requires that the TSF shall provide RSA CRT key generation compliant with [ISO9796- 2] with cryptographic key sizes 1976 - 2048 bit. This is realized within TSF_OS. This is realized in the security functionalities provided by TSF_Crypto based on the functionality of TSF_OS.  FCS_CKM.4: FCS_CKM.4.1 requires that the TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method physically overwriting the keys with zeros by method (e.g. clearKey of [Java_RES]) or automatically on applet deselection. This is realized by TSF_Crypto using the security functionality provided by TSF_OS.  FDP_RIP.1 requires that any previous information about specific keys is made unavailable upon the deallocation of the resource. This is realized in the security functionality provided by TSF_Crypto by using key objects as provided by TSF_OS.  FCS_COP.1/PACE_MAC requires that the TSF shall perform secure messaging – message authenti- cation code in accordance with a specified cryptographic algorithm: CMAC and cryptographic key size 128, 192, 256 bit that meets [ICAO_SAC]. This is realized by TSF_Crypto using the security functionality provided by TSF_OS.  FCS_COP.1/PACE_ENC requires that the TSF shall shall perform secure messaging – encryption and decryption in accordance with a specified cryptographic algorithm: AES in CBC mode and crypto- graphic key size 128, 192, 256 bit that meets [ICAO_SAC]. This is realized by TSF_Crypto using the security functionality provided by TSF_OS.  FCS_COP.1/CA_ENC requires that the TSF shall perform secure messaging – encryption and decryp- tion in accordance with a specified cryptographic algorithm: AES and cryptographic key size 128, 192, 256 bit that meets [ICAO_SAC]. This is realized by TSF_Crypto using the security functionality provided by TSF_OS.  FCS_COP.1/CA_MAC requires that the TSF shall perform secure messaging – message authentica- tion code in accordance with a specified cryptographic algorithm: CMAC and cryptographic key size 128, 192 and 256 bit that meets [TR-03110]. This is realized by TSF_Crypto using the security func- tionality provided by TSF_OS. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 78 of 98  FCS_COP.1.1/SIG_VER requires that the TSF shall perform digital signature verification in accord- ance with a specified cryptographic algorithm: ECDSA with SHA-1, SHA-224 or SHA-256 and speci- fied elliptic curves and cryptographic key sizes of 160, 192, 224, 256 and 320 bit, respectively that meet the following: [ISO15946]. This is realized within TSF_Crypto and TSF_OS.  FCS_COP.1/SIG_GEN requires that the TSF shall perform digital signature generation in accordance with RSA-SSA with cryptographic key sizes of 1976 - 2048 bit that meet the following: [ISO9796-2]. This is realized within TSF_Crypto and TSF_OS.  FIA_API.1.1/AA requires that the TSF shall provide the Active Authentication Mechanisms according to [ICAODoc] to prove the identity of the TOE. This is provided by TSF_Crypto (based on SFR FCS_COP.1/SIG_GEN).  FIA_UAU.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to identify themselves by selection of the authentication key, to carry out the Chip Authentication Protocol, to carry out the Terminal Authentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is au- thenticated. FIA_UAU.1.2 requires that the TSF shall require each user to be successfully authenti- cated before allowing any other TSF-mediated actions on behalf of that user. Active Authentication is provided by TSF_Crypto.  FIA_UAU.5.1/PACE requires that the TSF shall provide the PACE Protocol, Passive Authentication, Terminal Authentication, Secure messaging in MAC-ENC mode, Symmetric Authentication Mecha- nism based on AES, and the Terminal Authentication Protocol to support user authentication. FIA_UAU.5.2/PACE requires that the TSF shall authenticate any user’s claimed identity according to specified rules. TSF_Crypto adds parts of the cryptographic implementation. 7.1.5 TSF_ SecureMessaging: Secure Messaging This Security Functionality realizes a secure communication channel after successful authentication for per- sonalization and BAC during operational use. TSF_SecureMessaging covers the following SFRs:  FIA_UAU.5.1/PACE requires that the TSF shall provide the PACE Protocol, Passive Authentication, Terminal Authentication, Secure messaging in MAC-ENC mode, Symmetric Authentication Mecha- nism based on AES, and the Terminal Authentication Protocol to support user authentication. FIA_UAU.5.2/PACE requires that the TSF shall authenticate any user’s claimed identity according to specified rules.TSF_SecureMessaging provides the secure messaging mechanism.  FCS_COP.1/PACE_MAC requires that the TSF shall perform secure messaging with AES CMAC and cryptographic key sizes of 128, 192, 256 bit. The implementation is realized by TSF_SecureMessaging.  FDP_UIT.1/TRMrequires that the TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay er- rors. FDP_UIT.1.2 requires that the TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred. TSF_SecureMessaging provides the pro- tected communication.  FTP_ITC.1/PACE: FTP_ITC.1.1/PACE requires that the TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure; FTP_ITC.1.2/PACE requires that the TSF shall permit another trusted IT product to initiate communication via the trusted channel, and FTP_ITC.1.3/PACE re- cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 79 of 98 quires that the TSF shall initiate enforce communication via the trusted channel for any data ex- change between the TOE and the Terminal. The according secure messaging is realized by TSF_Access. 7.1.6 TSF_Auth: Authentication protocols This security functionality realizes different authentication mechanisms. 7.1.6.1 TSF_Auth_Term TSF_Auth_Term performs the Terminal Authentication to authenticate the terminal (EAC). TSF_Auth_Term covers the following SFRs:  FIA_UAU.5:FIA_UAU.5.1 requires that the TSF shall provide Terminal Authentication Protocol, Se- cure messaging in MAC-ENC mode, and Symmetric Authentication Mechanism based on AES to sup- port user authentication. FIA_UAU.5.2 requires that the TSF shall authenticate any user’s claimed identity according to specified rules. The authentication mechanisms are provided by TSF_Auth_Term.  FIA_UID.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to carry out the Chip Authentication Protocol, to carry out the Terminal Au- thentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is identified. FIA_UID.1.2 requires that the TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. TSF_Access realizes the appropriate control of the access rights, TSF_Auth the authentication mechanisms.  FDP_ACC.1/TRM requires that the TSF shall enforce the Access Control SFP on terminals gaining access to the User data and data stored in EF.Sod of the logical travel document.. TSF_Access real- izes the appropriate control of the access rights.. The authentication mechanism is provided by TSF_Auth_Term.  FDP_ACF.1/TRM:FDP_ACF.1.1 requires that the TSF shall enforce the Access Control SFP to objects based on Subjects (Terminal,BIS-PACE, Extended Inspection System), Objects (data EF.DG1, EF.DG2 and EF.DG5 to EF.DG16, EF.SOD and EF.COM of the logical MRTD, data in EF.DG3 of the logical MRTD,data in EF.DG4 of the logical MRTD, all TOE intrinsic secret cryptographic keys stored in the travel document) and Security attributes (PACE Authentication,Terminal Authentication v.1,Author- ization of the Terminal).FDP_ACF.1.2 requires that the TSF shall enforce the following rules to de- termine if an operation among con-trolled subjects and controlled objects is allowed: a BIS-PACE is allowed to read data objects from FDP_ACF.1.1/TRM according to [TR-03110] after a successful PACE authentication as required by FIA_UAU.1/PACE. FDP_ACF.1.3 requires that the TSF shall ex- plicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 requires that the TSF shall explicitly deny access of subjects to objects based on the rules: (1.) Any terminal being not authenticated as PACE authenticated BIS-PACE is not allowed to read, to write, to modify, to use any User Data stored on the travel document; (2) Terminals not using secure messaging are not allowed to read, to write, to modify, to use any data stored on the travel document; (3) Any terminal being not successfully authenticated as Extended Inspection Sys- tem with the Read access to DG 3 (Fingerprint) granted by the relative certificate holder authoriza- tion encoding is not allowed to read the data ob-jects 2b) of FDP_ACF.1.1/TRM; (4) any terminal being not successfully authenticated as Extended Inspection System with the Read access to DG 4 (Iris) granted by the relative certificate holder authorization encoding is not allowed to read the data objects 2c) of FDP_ACF.1.1/TRM; (5) nobody is allowed to read the data objects 2d) of FDP_ACF.1.1/TRM; (6) terminals authenticated as CVCA or as DV are not allowed to read data in the EF.DG3 and EF.DG4. This is realized within TSF_Auth_Term. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 80 of 98  FIA_UAU.5.1/PACErequires that the TSF shall provide the PACE Protocol, Passive Authentication, Terminal Authentication, Secure messaging in MAC-ENC mode, Symmetric Authentication Mecha- nism based on AES, and the Terminal Authentication Protocol to support user authentication. FIA_UAU.5.2/PACE requires that the TSF shall authenticate any user’s claimed identity according to specified rules.TSF_Auth_Term provides the Terminal Authentication.  FMT_MTD.3.1 requires that the TSF shall ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol and the Access Control. This is real- ized by TSF_Auth_Term. The refinement to FMT_MTD.3.1 requires that the certificate chain is valid if and only if  the digital signature of the Inspection System Certificate can be verified as correct with the public key of the Document Verifier Certificate and the expiration date of the Inspection System Certificate is not before the Current Date of the TOE,  the digital signature of the Document Verifier Certificate can be verified as correct´with the public key in the Certificate of the Country Verifying Certification Authority and the expira- tion date of the Document Verifier Certificate is not before the Current Date of the TOE,  the digital signature of the Certificate of the Country Verifying Certification Authority can be verified as correct with the public key of the Country Verifying Certification Authority known to the TOE and the expiration date of the Certificate of the Country Verifying Certi- fication Authority is not before the Current Date of the TOE. The Inspection System Public Key contained in the Inspection System Certificate in a valid certificate chain is a secure value for the authentication reference data of the Extended Inspection System. The intersection of the Certificate Holder Authorizations contained in the certificates of a valid cer- tificate chain is a secure value for Terminal Authorization of a successful authenticated Extended Inspection System. The intersection of the Certificate Holder Authorizations contained in the certificates of a valid cer- tificate chain is a secure value for Terminal Authorization of a successful authenticated Extended Inspection System. This is realized by TSF_Auth_Term.  FTP_ITC.1/PACE: FTP_ITC.1.1/PACE requires that the TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure; FTP_ITC.1.2/PACE requires that the TSF shall permit another trusted IT product to initiate communication via the trusted channel, and FTP_ITC.1.3/PACE re- quires that the TSF shall initiate enforce communication via the trusted channel for any data ex- change between the TOE and the Terminal. The according terminal authentication is realized by TSF_Auth_Term. 7.1.6.2 TSF_Auth_Sym TSF_Auth_Sym performs an authentication mechanism based on TDES used for BAC and based on AES used for symmetric authentication with pre-shared keys for personalization. TSF_Auth_Sym covers the following SFRs:  FDP_ACF.1:FDP_ACF.1.1 requires that the TSF shall enforce the Access Control SFP to objects based on subjects (Personalization Agent, Extended Inspection System, Terminal), objects (data EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 of the logical MRTD, data EF.DG3 and EF.DG4 of the logical MRTD, data in EF.COM, data in EF.SOD), and security attributes (authentication status of terminals, Termi- nal Authorization). FDP_ACF.1.2 requires that the TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) the successfully cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 81 of 98 authenticated Personalization Agent is allowed to write and to read the data of the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD, (2.) the successfully authenticated Extended Inspection System with the Read access to DG 3 (Fingerprint) granted by the relative certificate holder author- ization encoding is allowed to read the data in EF.DG3 of the logical MRTD, and (3.) the successfully authenticated Extended Inspection System with the Read access to DG 4 (Iris) granted by the rela- tive certificate holder authorization encoding is allowed to read the data in EF.DG4 of the logical MRTD. FDP_ACF.1.3 requires that the TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 requires that he TSF shall explicitly deny access of subjects to objects based on the rules: (1.) A terminal authenticated as CVCA is not allowed to read data in the EF.DG3, (2.) A terminal authenticated as CVCA is not allowed to read data in the EF.DG4, (3.) A terminal authenticated as DV is not allowed to read data in the EF.DG3, (4.) A terminal authenticated as DV is not allowed to read data in the EF.DG4, (5.) Any terminal is not allowed to modify any of the EF.DG1 to EF.DG16 of the logi-cal MRTD, (6.) Any terminal not being successfully authenticated as Extended Inspection System is not allowed to read any of the EF.DG3 to EF.DG4 of the logical MRTD. The authentication mechanism for the Access Control SFP is provided by TSF_Auth_Sym.  FIA_UAU.5.1/PACE requires that the TSF shall provide the PACE Protocol, Passive Authentication, Terminal Authentication, Secure messaging in MAC-ENC mode, Symmetric Authentication Mecha- nism based on AES, and the Terminal Authentication Protocol to support user authentication. FIA_UAU.5.2/PACE requires that the TSF shall authenticate any user’s claimed identity according to specified rules. TSF_Auth_Sym realizes the symmetric authentication mechanism.  FMT_MTD.1.1/CVCA_INI requires that the TSF shall restrict the ability to write the (1.) initial Coun- try Verifying Certification Authority Public Key, the (2.) initial Country Verifying Certification Author- ity Certificate, and the (3.) initial Current Date to the Personalization Agent. The authentication mechanism is provided by TSF_Auth_Sym.  FMT_MTD.1.1/CVCA_UPD requires that the TSF shall restrict the ability to update the (1.) Country Verifying Certification Authority Public Key and the (2.) Country Verifying Certification Authority Certificate to the Country Verifying Certification Authority. The authentication mechanism is pro- vided by TSF_Auth_Sym.  FMT_MTD.1.1/DATE requires that the TSF shall restrict the ability to modify the Current date to the (1.) Country Verifying Certification Authority, the (2.) Document Verifier, and the (3.) Domestic Ex- tended Inspection System. The authentication mechanism is provided by TSF_Auth_Sym.  FMT_MTD.1.1/CAPK requires that the TSF shall restrict the ability to load the Chip Authentication Private Key to the Personalization Agent. The authentication mechanism is provided by TSF_Auth_Sym. 7.1.6.3 TSF_Auth_Chip This security functionality manages the capability of the TOE to authenticate itself to the terminal using the Chip Authentication Protocol (EAC). TSF_Auth_Chip covers the following SFRs:  FIA_UID.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to carry out the Chip Authentication Protocol, to carry out the Terminal Au- thentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is identified. FIA_UID.1.2 requires that the TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. TSF_Access realizes the appropriate control of the access rights, TSF_Auth the authentication mechanisms.  FIA_UAU.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 82 of 98 FMT_MTD.1/INI_DIS, to identify themselves by selection of the authentication key, to carry out the Chip Authentication Protocol, to carry out the Terminal Authentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is au- thenticated. FIA_UAU.1.2 requires that the TSF shall require each user to be successfully authenti- cated before allowing any other TSF-mediated actions on behalf of that user. The chip authentica- tion mechanism is provided by TSF_Auth_Chip.  FIA_UAU.6/EAC requires that the TSF shall re-authenticate the user under the condition that each command sent to the TOE after successful run of the Chip Authentication Protocol shall be verified as being sent by the Inspection System. The authentication mechanism is provided by TSF_Auth_Chip.  FIA_API.1.1requires that the TSF shall provide a Chip Authentication Protocol according to [TR- 03110] to prove the identity of the TOE. This is provided by TSF_Auth_Chip.  FDP_UCT.1/TRM:FDP_UCT.1.1 requires that the TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from unauthorized disclosure after Chip Authentication. The authentication mechanism is provided by TSF_Auth_Chip.  FDP_UIT.1/TRM:FDP_UIT.1.1 requires that the TSF shall enforce the Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay errors after Chip Authentication. FDP_UIT.1.2 requires that the TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred after Chip Authentication. The authentication mechanism for the Access Control SFP is provided by TSF_Auth_Chip. 7.1.6.4 TSF_Auth_PACE This Security Functionality provides the PACE protocol.  FIA_UID.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to carry out the Chip Authentication Protocol, to carry out the Terminal Au- thentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is identified. FIA_UID.1.2 requires that the TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. TSF_Access realizes the appropriate control of the access rights, TSF_Auth_PACE the PACE mechanism.  FIA_UAU.1.1/PACE requires that the TSF shall allow to establish the communication channel, to carry out the PACE Protocol, to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS, to identify themselves by selection of the authentication key, to carry out the Chip Authentication Protocol, to carry out the Terminal Authentication Protocol, and to carry out the Active Authentication Mechanism on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 requires that the TSF shall require each user to be successfully authen- ticated before allowing any other TSF-mediated actions on behalf of that user. The PACE protocol is provided by TSF_Auth_PACE.  FIA_UAU.5.1/PACE requires that the TSF shall provide the PACE Protocol, Passive Authentication, Terminal Authentication, Secure messaging in MAC-ENC mode, Symmetric Authentication Mecha- nism based on AES, and the Terminal Authentication Protocol to support user authentication. FIA_UAU.5.2/PACE requires that the TSF shall authenticate any user’s claimed identity according to specified rules. TSF_Auth_PACE realizes the PACE protocol. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 83 of 98  FIA_UAU.6/PACE requires that the TSF shall re-authenticate the user under the condition that each command sent to the TOE after successful run of the PACE Protocol shall be verified as being sent by the terminal. This is provided by TSF_Auth_PACE. 7.1.7 TSF_Integrity: Integrity protection This Security Functionality protects the integrity of internal applet data like the Access control lists. This function makes use of SF.SecureManagement and SF.Transaction of the underlying JCOP Java Card OS (cf. the according security target[ST_JCOP]). TSF_Integrity covers the following SFRs:  FPT_FLS.1requires that the TSF shall preserve a secure state when the following types of failures occur: (1) exposure to out-of-range operating conditions where therefore a malfunction could oc- cur, and (2) failure detected by TSF according to FPT_TST.1. This is realized within TSF_Integrity. 7.1.8 TSF_OS: Javacard OS Security Functionalities The Javacard operation system (part of the TOE) features the following Security Functionalities. The exact description can be found in the Javacard OS security target [ST_JCOP]; the realization is partly based on the security functionalities of the certified cryptographic library and the certified IC platform:  Enforcement of access control (SF.AccessControl)  Audit functionality (SF.Audit)  Cryptographic key management (SF.CryptoKey)  Cryptographic operations (SF.CryptoOperation)  Identification and authentication (SF.I&A)  Secure management of TOE resources (SF.SecureManagement)  Transaction management (SF.Transaction) Since the applet layer of the TOE is based on the Javacard OS, the realization of all TOE security functional- ities and thus the fulfillment of all SFRs has dependencies to TSF_OS. The following items list all SFRs where TSF_OS has an impact above this level:  FCS_CKM.1/AA requires that the TSF shall provide RSA CRT key generation compliant with [ISO9796- 2] with cryptographic key sizes 1976 - 2048 bit. This is realized within TSF_OS. This is realized in the security functionalities provided by TSF_Crypto based on the functionality of TSF_OS.  FCS_CKM.1/DH_PACE and FCS_CKM.1/CA require that the TSF shall generate cryptographic keys based on the Diffie-Hellman key derivation Protocol compliant to PKCS#3 with cryptographic key sizes of 1976 - 2048 bit, or ECDH compliant to ISO 15946 with specific domain parameters and with cryptographic key sizes of 256 and 320 bit, meeting [TR-03110], Annex A.1.  FCS_CKM.4.1 requires that the TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method. This is realized by TSF_Crypto using the security functional- ity provided by TSF_OS.  FDP_RIP.1 requires that any previous information about specific keys is made unavailable upon the deallocation of the resource. This is realized in the security functionality provided by TSF_OS.  FCS_COP.1/PACE_ENC requires that the TSF shall shall perform secure messaging – encryption and decryption in accordance with a specified cryptographic algorithm: AES in CBC mode and crypto- graphic key size 128, 192, 256 bit that meets the following: compliant to [ICAO_SAC]. This is realized by TSF_Crypto using the security functionality provided by TSF_OS. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 84 of 98  FCS_COP.1/PACE_MAC requires that the TSF shall perform secure messaging – message authenti- cation code in accordance with a specified cryptographic algorithm: AES-CMAC and cryptographic key size 128, 192, 256 bit that meets the following: [ICAO_SAC]. This is realized by TSF_Crypto us- ing the security functionality provided by TSF_OS.  FCS_COP.1/CA_ENC requires that the TSF shall perform secure messaging – encryption and decryp- tion in accordance with a specified cryptographic algorithm: AES and cryptographic key size 128, 192, 256 bit that meets [ICAO_SAC]. This is realized by TSF_Crypto using the security functionality provided by TSF_OS.  FCS_COP.1/CA_MAC requires that the TSF shall perform secure messaging – message authentica- tion code in accordance with a specified cryptographic algorithm: AES-CMAC and cryptographic key size 128, 192 and 256 bit that meets [TR-03110]. This is realized by TSF_Crypto using the security functionality provided by TSF_OS.  FCS_COP.1.1/SIG_VER requires that the TSF shall perform digital signature verification in accord- ance with a specified cryptographic algorithm: ECDSA with SHA-1, SHA-224 or SHA-256 and speci- fied elliptic curves and cryptographic key sizes of 160, 192, 224, 256 and 320 bit, respectively that meet the following: [ISO15946]. This is realized within TSF_Crypto and TSF_OS.  FCS_COP.1/SIG_GEN requires that the TSF shall perform digital signature generation in accordance with RSA-SSA and cryptographic key sizes of 1976 - 2048 bit that meet the following: [ISO9796-2]. This is realized within TSF_Crypto and TSF_OS.  FCS_RND.1: FCS_RND.1.1 requires that the TSF shall provide a mechanism to generate random numbers that meet the AIS 20 Class DRG.3 quality metric. This is realized within TSF_OS.  FMT_LIM.1 requires that the TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow (1) User Data to be manipulated, (2) TSF data to be disclosed or manipulated, (3) software to be reconstructed, (4) substantial information about con- struction of TSF to be gathered which may enable other attacks, (5) sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. This is realized by TSF_OS.  FMT_LIM.2 requires that the TSF shall be designed in a manner that limits their availability so that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow (1) User Data to be manipulated, (2) TSF data to be disclosed or manipulated, (3) software to be reconstructed, (4) substantial information about con- struction of TSF to be gathered which may enable other attacks, (5) sensitive User Data (EF.DG3 and EF.DG4) to be disclosed. This is realized by TSF_OS.  FMT_MTD.1.1/INI_ENA requires that the TSF shall restrict the ability to write the Initialization Data and Prepersonalization Data to the Manufacturer. This is realized by TSF_OS.  FMT_MTD.1.1/INI_DIS requires that the TSF shall restrict the ability to disable read access for users to the Initialization Data to the Personalization Agent. This is realized by TSF_OS.  FMT_MTD.1.1/KEY_READ requires that the TSF shall restrict the ability to read the (1.) PACE pass- words the (2.) Chip Authentication Private Key, and the (3.) Personalization Agent Keys to none. This is realized by TSF_OS.  FPT_EMS.1: FPT_EMS.1.1 requires that the TOE shall not emit variations in power consumption or timing during command execution in excess of non-useful information enabling access to (1) Chip Authentication Session Keys, (2) PACE Session Keys (PACE-KMAC, PACE-KENC), (3) the ephemeral private key ephem SKPICC-PACE, (4) none, (5) Personalization Agent Key(s), (6) Chip Authentication Private Key, (7) Active Authentication Private Key and (8) none. FPT_EMS.1.2 requires that the TSF shall ensure any users are unable to use the following interface: smart card circuit contacts or con- tactless interface to gain access to (1) Chip Authentication Session Keys, (2) PACE Session Keys cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 85 of 98 (PACE-KMAC, PACE-KENC), (3) the ephemeral private key ephem SKPICC-PACE, (4) Personalization Agent Key(s), (5) Chip Authentication Private Key, (6) Active Authentication Private Key. This is mainly realized by appropriate measures in TSF_OS together with the strict following of the security implementation guidelines of the Javacard platform.  FPT_FLS.1.1 requires that the TSF shall preserve a secure state when the following types of failures occur: (1) exposure to out-of-range operating conditions where therefore a malfunction could oc- cur, and (2) failure detected by TSF according to FPT_TST.1. This is realized within TSF_OS (together with TSF_Integrity).  FPT_TST.1.1 requires that the TSF shall run a suite of self tests during initial start-up to demonstrate the correct operation of the TSF. FPT_TST.1.2 requires that the TSF shall provide authorised users with the capability to verify the integrity of TSF data. FPT_TST.1.3 requires that the TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code. This all is realized by TSF_OS, in parts due to the characteristics of the hardware platform.  FPT_PHP.3.1 requires that the TSF shall resist physical manipulation and physical probing to the TSF by responding automatically such that the SFRs are always enforced. This all is realized by TSF_OS, in parts due to the characteristics of the hardware platform. 7.2 TOE summary specification rationale This summary specification shows that the TSF and assurance measures are appropriateto fulfill the TOE security requirements. Each TOE security functional requirement is implemented by at least one security functionality. The map- ping of TOE Security Requirements and TOE Security Functionalities isgiven in the following table. If itera- tions of a TOE security requirement are covered by the same TOE security functionality the mapping will appear only once. The description of the TSF is given in section 7.1. TSF_Access TSF_Admin TSF_Secret TSF_Crypto TSF_SecureMessaging TSF_Auth TSF_Integrity TSF_OS FAU_SAS.1 x FCS_CKM.1/AA x x FCS_CKM.1/CA x x FCS_CKM.1/DH_PACE x x FCS_CKM.4 x x FCS_COP.1/CA_ENC x x FCS_COP.1/CA_MAC x x FCS_COP.1/PACE_ENC x x FCS_COP.1/PACE_MAC x x FCS_COP.1/SIG_VER x x cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 86 of 98 TSF_Access TSF_Admin TSF_Secret TSF_Crypto TSF_SecureMessaging TSF_Auth TSF_Integrity TSF_OS FCS_COP.1/SIG_GEN x x FCS_RND.1 x FIA_UID.1/PACE x x x FIA_UAU.1/PACE x x FIA_UAU.4/PACE x FIA_UAU.5/PACE x x x x FIA_UAU.6/PACE x x FIA_UAU.6/EAC x x FIA_AFL.1/PACE x FIA_API.1 x FIA_API.1/AA x FDP_ACC.1/TRM x x FDP_ACF.1/TRM x x FDP_RIP.1 x x FDP_UCT.1/TRM x x FDP_UIT.1/TRM x x x FMT_SMF.1 x FMT_SMR.1/PACE x x FMT_LIM.1 x x x FMT_LIM.2 x x x FMT_MTD.1/INI_ENA x FMT_MTD.1/INI_DIS x FMT_MTD.1/CVCA_INI x x x FMT_MTD.1/CVCA_UPD x x x FMT_MTD.1/DATE x x x FMT_MTD.1/AA x x x FMT_MTD.1/CAPK x x x FMT_MTD.1/KEY_READ x x x FMT_MTD.1/PA x x x FMT_MTD.3 x FPT_EMS.1 x FPT_FLS.1 x x cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 87 of 98 TSF_Access TSF_Admin TSF_Secret TSF_Crypto TSF_SecureMessaging TSF_Auth TSF_Integrity TSF_OS FPT_TST.1 x FPT_PHP.3 x FTP_ITC.1/PACE x x x Table 15: Mapping of TOE Security Requirements and TOE Security Functionalities. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 88 of 98 8 Crypto disclaimer This chapter contains a summary of the cryptographic mechanisms used to implement the security func- tionality of the TOE according to this security target. Nr. Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments 1 Authenticity ECDSA-signature verification of card verifiable certificates using SHA-{1,224,256} [ISO15946] (ECDSA), [FIPS180-4] (SHA) 160, 192, 224, 256 and 320 bit; elliptic curves brainpoolP{160, 192,224,256,320 }r1 (RFC 5639), NIST P-{160, 192, 224,256} (FIPS186-3) [ICAODoc] (ECDSA), [TR- 03110] Verification of certificates for authentication; FCS_COP.1/SIG_V ER 2 Authentication PACE [ICAO_SAC] Length of MRZ or CAN, |Nonce|=128 [ICAO-SAC], [TR-03110] FIA_UID.1/PACE, FIA_UAU.1/PACE 3 Chip Authentication v.1 for authentication of travel document's chip to inspection system based on ephemeral-static ECDH in combination with AES [ISO15946] AES cf. Confidentiality/Integri ty Key sizes corresponding to the used elliptic curve brainpoolP{256, 320}r1 (RFC 5639), NIST P- {256} (FIPS186- 3) [ICAODoc], [TR-03110] FIA_API.1.1 4 Chip Authentication v.1 for authentication of travel document's chip to inspection system based on ephemeral-static DH in combination with AES [PKCS3], AES cf. Confidentiality/Integri ty Plength = 1976- 2048 [ICAODoc], [TR-03110] FIA_API.1.1 5 Terminal Authentication v.1 for authentication of inspection system to travel documents's chip based on ECDSA using SHA- {1,224,256} [ISO15946] (ECDSA), [FIPS180-4] (SHA) 160, 192, 224, 256 and 320 bit; elliptic curves brainpoolP{160, 192,224,256,320 }r1 (RFC 5639), NIST P-{160, 192, 224,256} (FIPS186-3) [TR-03110] FIA_UAU.5/PACE cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 89 of 98 Nr. Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments 6 Active Authentication of the MRTD’s chip based on RSA using SHA-{1,224,256} [ISO9796-2] (RSA), [FIPS180-4] (SHA) Moduluslength= 1976- 2048 bit [ICAODoc] FCS_COP.1/SIG_G EN 7 Symmetric Authentication Mechanism based on AES for Personalization Agent Standard equivalent to ISO 18013-3 |k|=128, 192, 256 [ICAODoc] but with AES 8 Key Derivation ECDH using SHA-{1, 256} [ISO15946] (ECDH), [FIPS180-4] (SHA), [TR-03110] , Annex A.1 (PACE) 256 and 320 bit; Elliptic curves brainpoolP{256, 320}r1 (RFC 5639), NIST P- {256} (FIPS186- 3) [TR-03110] For PACE, Chip Authentication. [ICAO_SAC] implicitly contains the requirements for hash functions FCS_CKM.1/DH_ PACE, FCS_CKM.1/CA 9 ) DH using SHA-{1, 256} [PKCS3] (DH), [FIPS180-4] (SHA), [TR-03110] , Annex A.1 (PACE). Plength= 1976- 2048 bit [TR-03110] For PACE, Chip Authentication FCS_CKM.1/DH_ PACE, FCS_CKM.1/CA 10 Confidentiality AES in CBC mode [FIPS197] (AES), [NIST800-38A] (CBC) |k|=128, 192, 256 [ICAO_SAC] FCS_COP.1/PACE _ENC FCS_COP.1.1/CA_ ENC 11 Integrity AES in CMAC mode [FIPS197] (AES), [NIST800-38B] (CMAC) |k|=128, 192, 256 [ICAO_SAC] [TR-03110] FCS_COP.1/PACE _MAC FCS_COP.1/CA_M AC 12 Trusted Channel Secure messaging in ENC_MAC mode is established during PACE [ICAO_SAC] Cf. Confidentiality/I ntegrity [ICAO_SAC], [TR-03110] FIA_UAU.5/PACE 13 Secure messaging in ENC_MAC mode is established during Chip Authentication v1 after PACE [ICAO_SAC] Cf. Confidentiality/I ntegrity [ICAO_SAC], [TR-03110] FIA_UAU.5/PACE cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 90 of 98 Nr. Purpose Cryptographic Mechanism Standard of Implementation Key Size in Bits Standard of Application Comments 14 Secure messaging for personalization Standard equivalent to ISO 18013-3 |k|=128, 192, 256 [ICAODoc] but with AES 15 Cryptographic primitive Deterministic RNG DRG.3 [AIS20] n.a. FCS_RND.1 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 91 of 98 References In the following tables, the references used in this document are summarized. Common Criteria [CC_1] Common Criteria for Information Technology Security Evaluation, Part 1: In- troduction and General Model; Version 3.1, Revision 4, September 2012; CCMB-2012-09-001. [CC_2] Common Criteria for Information Technology Security Evaluation, Part 2: Se- curity Functional Requirements; Version 3.1, Revision 4, September 2012; CCMB-2012-09-002. [CC_3] Common Criteria for Information Technology Security Evaluation, Part 3: Se- curity Assurance Requirements; Version 3.1, Revision 4, September 2012; CCMB-2012-09-003. [CC_4] Common Methodology for Information Technology Security Evaluation, Eval- uation Methodology; Version 3.1, Revision 4, September 2012; CCMB-2012- 09-004. [JIL_1] Joint Interpretation Library: Certification of "open" smart card products; Ver- sion 1.1 (for trial use), 4 February 2013 Protection Profiles [PP0056v2] Common Criteria Protection Profile Machine Readable Travel Document with “ICAO Application”, Extended Access Control with PACE (EAC PP), Version 1.3.2, 5.12.2012, BSI-CC-PP-0056v2-2012, Bundesamt für Sicherheit in der In- formationstechnik. [PP0068] Common Criteria Protection Profile Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE PP), Version 1.0, 2.11.2011, BSI-CC-PP-0068v2-2011, Bundesamt für Sicherheit in der Informationstech- nik. [PP0002] PP conformant to Smartcard IC Platform Protection Profile, Version 1.0, July 2001; registered and certified by Bundesamt für Sicherheit in der Infor- mationstechnik (BSI) under the reference BSI-PP-0002-2001. [PP0035] Security IC Platform Protection Profile, Version 1.0, June 2007; registered and certified by BSI (Bundesamt für Sicherheit in der Informationstechnik) under the reference BSI-PP-0035-2007. [PP0055] Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Basic Access Control, BSI-PP-0055, Version 1.10, 25th March 2009. [PP_Javacard] Java Card System - Open Configuration Protection Profile, Version 2.6, Certi- fied by ANSSI, the French Certification Body April, 19th 2010. TOE and Platform References [Guidance] cv act ePasslet Suite v2.1 - Java Card applet configuration providing Machine Readable Travel Document with “ICAO Application”, Extended Access Control cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 92 of 98 (EAC) with PACE - Guidance Manual. For the exact version please refer to the certification report. [ZertIC] Certification Report BSI-DSZ-CC-0858-2013 for NXP Secure PKI Smart Card- Controllers P5CD128V0v/ V0B(s), P5CC128V0v/ V0B(s), P5CD145V0v/ V0B(s), P5CC145V0v/ V0B(s), P5CN145V0v/V0B(s), each including IC Dedicated Soft- ware from NXP Semiconductors Germany GmbH; 12.6.2013. [ZertJCOP] Certification Report NSCIB-CC-13-37760-CR2 for NXP J3E145_M64, J3E120_M65, J3E082_M65, J2E145_M64, J2E120_M65, and J2E082_M65 Se- cure Smart Card Controller Revision 3, TÜV Rheinland Nederland B.V.; 25.8.2014. [ZertCL] Certification Report BSI-DSZ-CC-0750-V2-2014 for NXP Crypto Library V2.7/2.9 on SmartMX P5Cx128/P5Cx145 V0v/V0B(s) from NXP Semiconduc- tors Germany GmbH; 16.07.2014. [ST_JCOP] NXP J3E145_M64, J3E120_M65, J3E082_M65, J2E145_M64, J2E120_M65, and J2E082_M65 Secure Smart Card Controller Revision 3, Security Target Lite, Rev. 00.03 - 13 August 2014, NSCIB-CC-13-37760 [ST_CL] Crypto Library V2.7/2.9 on SmartMX P5Cx128/P5Cx145 V0v/ V0B(s), Secu-rity Target Lite, Rev. 1.7, 26 June 2014, BSI-DSZ-CC-0750-V2 [ST_IC] NXP Secure Smart Card Controllers P5Cx128V0v / P5Cx145V0v/V0B(s), Secu- rity Target Lite, Rev. 2.1, 16. November 2013 , BSI-DSZ-CC-0858 ICAO specifications [ICAODoc] ICAO Doc 9303, Machine Readable Travel Documents, part 1 – Machine Read- able Passports, Sixth Edition, 2006, International Civil Aviation Organization [ICAO_SAC] International Civil Avation Organisation, ICAO Machine Readable Travel Doc- uments, Technical Report, Supplemental Access Control for Machine Reada- ble Travel Documents, Version 1.01, November 11, 2010 Cryptography [TR-03110] Technical Guideline TR-03110-1, Advanced Security Mechanisms for Machine Readable Travel Documents –Part 1 – eMRTDs with BAC/PACEv2 and EACv1, Version 2.10, Bundesamt für Sicherheit in der Informationstechnik (BSI), 20.03.2012 [TR-ECC] Technical Guideline: Elliptic Curve Cryptography according to ISO 15946.TR- ECC, BSI 2006. [ISO7816-4] ISO 7816, Identification cards – Integrated circuit(s) cards with contacts, Part 4: Organization, security and commands for interchange, FDIS 2004 [AIS20] Anwendungshinweise und Interpretationen zum Schema (AIS); AIS 20, Ver- sion 3, 15.05.2013, Bundesamt für Sicherheit in der Informationstechnik [AIS31] Anwendungshinweise und Interpretationen zum Schema, AIS 31: Funk-tiona- litätsklassen und Evaluationsmethodologie für physikalische Zufalls-zahlenge- neratoren, Version 3, Stand:15.05.2013 [ISO14888-3] ISO/IEC 14888-3: Information technology – Security techniques – Digital sig- natures withappendix – Part 3: Certificate-based mechanisms, 1999 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 93 of 98 [FIPS46-3] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION FIPS PUB 46-3, DATA ENCRYPTION STANDARD (DES), Reaffirmed 1999 October 25, U.S.DEPARTMENT OF COMMERCE/National Institute of Standards and Tech- nlogy [NIST800-20] NIST Special Publication 800-20, Modes of Operation Validation System for the Triple Data Encryption Algorithm, US Department of Commerce, October 1999 [FIPS180-2] Federal Information Processing Standards Publication 180-2 SECURE HASH STANDARD(+ Change Notice to include SHA-224), U.S. DEPARTMENT OF COMMERCE/NationalInstitute of Standards and Technology, 2002 August 1 [FIPS180-4] Federal Information Processing Standards Publication 180-4 SECURE HASH STANDARD (SHS), U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, March 2012 [FIPS197] Federal Information Processing Standards Publication 197, ADVANCED ENCRYPTIONSTANDARD (AES), U.S. DEPARTMENT OF COMMERCE/National Institute of Standardsand Technology, November 26, 2001 [ANSIX9.19] ANSI X9.19, AMERICAN NATIONAL STANDARD, Financial Institution Retail Message Authentication, 1996 [ANSIX9.62] AMERICAN NATIONAL STANDARD X9.62-1999: Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA),September 20, 1998 [ISO9796-2] ISO/IEC 9796-2, Information Technology – Security Techniques – Digital Sig- nature Schemes giving message recovery – Part 2: Integer factorisation based mechanisms, 2002 [ISO15946] ISO/IEC 15946. Information technology – Security techniques – Cryptographic techniques based on elliptic curves, 2002. [PKCS#3] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories Tech- nical Note, Version 1.4, Revised November 1, 1993 [NIST800-38B] Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800-38B, National Institute of Stand- ards and Technology, May 2005 [RFC4493] Request for Comments: 4493, The AES-CMAC Algorithm, JH. Song et al. Uni- versity of Washington, Category: Informational, June 2006 [ISO11770-3] ISO/IEC 11770 Part 3: Information technology- Security techniques - Key man- agement: Mechanisms using asymmetric techniques [Brainpool] RFC 5639 ECC Brainpool Standard Curves & Curve Generation, March 2010; available at:http://tools.ietf.org/html/rfc5639 [FIPS186-3] Digital Signature Standard (DSS) - FIPS PUB 186-3, FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, June, 2009 [PKCS#1-v2_1] PKCS #1: RSA Encryption Standard – An RSA Laboratories Technical Note Ver- sion 2.1 [TR-03111] Technical Guideline TR-03111: Elliptic Curve Cryptography; BSI, Version 2.0, 28.6.2012 cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 94 of 98 Glossary Active authentication Security mechanism defined in [ICAODoc] by which means the MTRD’s chip proves and the inspection system verifies the identity and authenticity of the MTRD’s chip as part of a genuine MRTD issued by a known State of organization. AES The AES (Advanced Encryption Standard) has been defined as a standard for symmetric data encryption. It is a block cipher with a block length of 128 bit and key lengths of 128, 192 and 256 bit. Application note Optional informative part of the PP containing additional supporting infor- mation that is considered relevant or useful for the construction, evaluation, or use of the TOE. Asymmetric cipher Encryption procedures employing two different keys (in contrast to a symmetric cipher): one publicly known (public key) for data encryption and one key only known to the message receiver (private key) for decryption. Audit records Write-only-once non-volatile memory area of the MRTDs chip to store the Ini- tialization Data and Pre-personalization Data. Authentication Authentication defines a procedure that verifies the identity of the communica- tion partner. The most elegant method is based on the use of so called digital signatures. BAC Basic access control. Security mechanism defined in [ICAODoc] by which means the MTRD’s chip proves and the inspection system protects their communica- tion by means of secure messaging. Basic access keys Pair of symmetric Triple-DES keys used for secure messaging with encryption (key KENC) and message authentication (key KMAC) of data transmitted between the MRTD’s chip and the inspection system [ICAODoc]. It is drawn from the printed MRZ of the passport book to authenticate an entity able to read the printed MRZ of the passport book. Block cipher An algorithm processing the plaintext in bit groups (blocks). Its alternative is called stream cipher. CA Certification authority Certificate see digital certificate Certificate revocation list A list of revoked certificates issued by a certificate authority Certification authority An entity responsible for registering and issuing, revoking and generally manag- ing digital certificates Country signing CA cer- tificate (CCSCA) Certificate of the Country Signing Certification Authority Public Key (KPuCSCA) issued by Country Signing Certification Authority. The CCSCA is stored in the in- spection system. Country verifying CA The country specific root of the PKI of Inspection Systems. It creates the Docu- ment Verifier Certificates within this PKI. It enforces the Privacy policy of the issuing country or organization in respect to the protection of sensitive bio- metric data stored in the MRTD. CRL see Certificate Revocation List Cryptography In the classical sense, the science of encrypting messages. Today, this notion comprises a larger field and also includes problems like authentication or digital signatures. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 95 of 98 Current date The maximum of the effective dates of valid CVCA, DV and domestic Inspection System certificates known to the TOE. It is used the validate card verifiable cer- tificates. CVCA link certificate Certificate of the new public key of the Country Verifying Certification Authority signed with the old public key of the Country Verifying Certification Authority where the certificate effective date for the new key is before the certificate ex- piration date of the certificate for the old key. DES (Data Encryption Standard) symmetric 64 bit block cipher, which was developed (first under the name Lucifer) by IBM. The key length is 64 bit of which 8 bit serve for a parity check. DES is the classic among the encryption algorithms, which nevertheless is no longer secure due to its insufficient key length. Alternatives are Triple-DES or the successor AES. Digital certificate A data set that identifies the certification authority issuing it, identifies its owner, contains the ower's public key, identifies its operational period, and is digitally signed by the certification authority issuing it. Digital signature The counterpart of a handwritten signature for documents in digital format. A digital signature grants authentication, integrity, and non-repudiation. These features are achieved by using asymmetric procedures. Document verifier Certification authority creating the Inspection System Certificates and managing the authorization of the Extended Inspection Systems for the sensitive data of the MRTD in the limits provided by the issuing States or Organizations EAC Extended access control. Security mechanism identified in [ICAODoc]by which means the MTRD’s chip (i) verifies the authentication of the inspection systems authorized to read the optional biometric reference data, (ii) controls the access to the optional biometric reference data and (iii) protects the confidentiality and integrity of the optional biometric reference data during their transmission to the inspection system by secure messaging. ECC (Elliptic Curve Cryptography) class of procedures providing an attractive alterna- tive for the probably most popular asymmetric procedure, the RSA algorithm. Elliptic curves A mathematical construction, in which a part of the usual operations applies, and which has been employed successfully in cryptography since 1985. Fingerprint (digital) Checksum that can be used to easily determine the correctness of a key without having to compare the entire key. This is often done by comparing the hash val- ues after application of a hash function. Hash function A function which forms the fixed-size result (the hash value) from an arbitrary amount of data (which is the input). These functions are used to generate the electronic equivalent of a fingerprint. The significant factor is that it must be impossible to generate two entries which lead to the same hash value (so called collisions) or even to generate a matching message for a defined hash value. Common hash functions are RIPEMD-160 and SHA-1, each having hash values with a length of 160 bit as well as the MD5, which is still often used today having a hash value length of 128 bit. Inspection system A technical system used by the border control officer of the receiving State (i) examining an MRTD presented by the traveller and verifying its authenticity and (ii) verifying the traveller as MRTD holder. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 96 of 98 Integrity The test on the integrity of data is carried out by checking messages for changes during the transmission by the receiver. Common test procedures employ Hash- functions, MACs (Message Authentication Codes) or – with additional function- ality – digital signatures. Javacard A smart card with a Javacard operation system. Key exchange The use of symmetric cipher procedures requires that two communication part- ners decide on one joint key only known to themselves. The difficulty is that for the exchange of such information usually only partially secure channels exist. Additionally, protocols for key exchange must be prepared in such a way that only those pieces of information are exchanged which do not lead to knowledge of the real secret (the key). The most popular protocol of that type is diffie- Hellman, whose presentation in 1976 can be regarded as the birth of public key cryptography. LDS Logical data structure. The collection of groupings of data elements stored in the optional capacity expansion technology, defined in [ICAODoc]. MAC Algorithm that expands the message by means of a secret key by special redun- dant pieces of information, which are stored or transmitted together with the message. To prevent an attacker from targeted modification of the attached re- dundancy, requires its protection in a suitable way. MRTD Machnine-readable travel document. Official document issued by a State or Or- ganization which is used by the holder for international travel (e.g. passport, visa, official document of identity) and which contains mandatory visual (eye readable) data and a separate mandatory data summary, intended for global use, reflecting essential data elements capable of being machine read. MRZ Fixed dimensional area located on the front of the MRTD or MRP Data Page or, in the case of the TD1, the back of the MRTD, containing mandatory and optional data for machine reading using OCR methods. Non-repudiation One of the objectives in the employment of digital signatures. It describes the fact that the sender of a message is prevented from denying the preparation of the message. The problem cannot be simply solved with cryptographic routines, but the entire environment needs to be considered and respective framework conditions need to be provided by pertinent laws. Passive authentication (i) verification of the digital signature of the Document Security Object and (ii) comparing the hash values of the read LDS data fields with the hash values con- tained in the Document Security Object. Passphrase A long, but memorable character sequence (e.g. short sentences with punctua- tion) which should replace passwords as they offer more security. Password A secret character sequence whose knowledge is to serve as a replacement for the authentication of a participant. A password is usually short to really ensure that an attacker cannot guess the password by trial and error. Personalization The process by which the portrait, signature and biographical data are applied to the document. Personalization agent The agent acting on the behalf of the issuing State or organisation to personalize the MRTD for the holder by (i) establishing the identity the holder for the bio- graphic data in the MRTD, (ii) enrolling the biometric reference data of the MRTD holder i.e. the portrait, the encoded finger image(s) or (ii) the encoded iris image(s) and (iii) writing these data on the physical and logical MRTD for the holder. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 97 of 98 PKI Cf. Public Key Infrastructure PP Protection Profile Private key Secret key only known to the receiver of a message, which is used in asymmetric ciphers for encryption or generation of digital signatures. Pseudo random num- ber Many cryptographic mechanisms require random numbers (e.g. in key genera- tion). The problem, however, is that it is difficult to implement true random numbers in software. Therefore, so called pseudo-random number generators are used, which then should be initialized with a real random element (the so called seed). Public key Publicly known key in an asymmetric cipher which is used for encryption and verification of digital signatures. Public key infrastruc- ture (PKI) Combination of hardware and software components, policies, and different pro- cedures used to manage digital certificates. Random numbers Many cryptographic algorithms or protocols require a random element, mostly in form of a random number, which is newly generated in each case. In these cases, the security of the procedure depends in part on the suitability of these random numbers. As the generation of real random numbers within computers still imposes a problem (a source for real random events can in fact only be gained by exact observation of physical events, which is not easy to realize for a software), so called pseudo random numbers are used instead. Secure messaging Secure messaging using encryption and message authentication code according to ISO/IEC 7816-4. SFR Security functional requirement. Skimming Imitation of the inspection system to read the logical MRTD or parts of it via the contactless communication channel of the TOE without knowledge of the printed MRZ data. Smart card A smart card is a chip card which contains an internal micro controller with CPU, volatile (RAM) and non-volatile (ROM, EEPROM) memory, i.e. which can carry out its own calculations in contrast to a simple storage card. Sometimes a smart card has a numerical coprocessor (NPU) to execute public key algorithms effi- ciently. Smart cards have all of their functionality comprised on a single chip (in contrast to chip cards, which contain several chips wired to each other). There- fore, such a smart card is ideal for use in cryptography as it is almost impossible to manipulate its internal processes. SOD Document Security Object (stored in EF.SOD). A RFC3369 CMS Signed Data Structure, signed by the Document Signer (DS). Carries the hash values of the LDS Data Groups. It is stored in the MRTD’s chip. It may carry the Document Signer Certificate (CDS). ST Security Target Stream cipher Symmetric encryption algorithm which processes the plaintext bit-by-bit or byte-by-byte. The other usually employed class of procedures comprises so called block cipher. Symmetric cipher Encryption procedure using the same key for enciphering and deciphering (or, in which these two keys can simply be derived from each other). One distin- guishes between block ciphers processing plaintext in blocks of fixed length (mostly 64 or 128 bit) and stream ciphers working on the basis of single charac- ters. cv act ePasslet2.1/MRTD-EACv1-SAC Security Target 98 of 98 TOE Target of evaluation. Travel document A passport or other official document of identity issued by a State or organiza- tion, which may be used by the rightful holder for international travel. TSF TOE security functionality. Verification The process of comparing a submitted biometric sample against the biometric reference template of a single enrolee whose identity is being claimed, to de- termine whether it matches the enrolee’s template. X.509 Standard for certificates, CRLs and authentication services. It is part of the X.500 standard of the ITU-T for realization of a worldwide distributed directory service realized with open system.