KONA2 D2320N ePassport BAC Security Target Lite V01.00 (2018.11.07) © 2018 Kona I, Inc. All Rights Reserved. R&D Center KONA2 D2320N ePassport BAC Security Target Lite Revision History KONA2 D2320N ePassport BAC Security Target Lite No. Ver. Date Description of Change Chapter Writer 1 V01.00 2018/11/07 New Publication All KONA I © Kona I All Rights Reserved. The content of this specification is protected by copyright laws. 2018. Nov 07, 1st Release KONA2 D2320N ePassport BAC Security Target Lite Table of Contents 1. ST Introduction ..............................................................................................................1 1.1. ST Reference......................................................................................................................................... 1 1.2. TOE Reference...................................................................................................................................... 1 1.3. TOE Overview ....................................................................................................................................... 1 2. TOE Description.............................................................................................................2 2.1. TOE Architecture .................................................................................................................................. 4 TOE guidance............................................................................................................................................5 3. Conformance Claim.......................................................................................................6 3.1. Conformance Claim rationale ............................................................................................................. 6 4. Security Problem Definition..........................................................................................8 4.1. Introduction........................................................................................................................................... 8 4.2. Assumptions......................................................................................................................................... 9 4.2.1. A.MRTD_Manufact MRTD manufacturing on step 4 to 6................................................................9 4.2.2. A.MRTD_Delivery MRTD delivery during steps 4 to 6 ....................................................................9 4.2.3. A.Pers_Agent Personalization of the MRTD’s chip .........................................................................9 4.2.4. A.Insp_Sys Inspection Systems for global interoperability............................................................10 4.2.5. A.BAC-Keys Cryptographic quality of Basic Access Control Keys................................................10 4.3. Threats................................................................................................................................................. 10 4.3.1. T.Chip_ID Identification of MRTD’s chip........................................................................................10 4.3.2. T.Skimming Skimming the logical MRTD ......................................................................................10 4.3.3. T.Eavesdropping Eavesdropping to the communication between TOE and inspection system ...10 4.3.4. T.Forgery Forgery of data on MRTD’s chip ...................................................................................10 4.3.5. T.Abuse-Func Abuse of Functionality............................................................................................10 4.3.6. T.Information_Leakage Information Leakage from MRTD’s chip ..................................................10 4.3.7. T.Phys-Tamper Physical Tampering ..............................................................................................10 4.3.8. T.Malfunction Malfunction due to Environmental Stress................................................................ 11 4.4. Organizational Security Policies........................................................................................................11 4.4.1. P.Manufact Manufacturing of the MRTD’s chip ............................................................................. 11 4.4.2. P.Personalization Personalization of the MRTD by issuing State or Organization only................ 11 4.4.3. P.Personal_Data Personal data protection policy ......................................................................... 11 5. Security Objectives......................................................................................................12 5.1. Security Objectives for the TOE........................................................................................................ 12 5.1.1. OT.AC_Pers Access Control for Personalization of logical MRTD................................................12 5.1.2. OT.Data_Int Integrity of personal data...........................................................................................12 5.1.3. OT.Data_Conf Confidentiality of personal data .............................................................................12 5.1.4. OT.Identification Identification and Authentication of the TOE ......................................................12 KONA2 D2320N ePassport BAC Security Target Lite 5.1.5. OT.Prot_Abuse-Func Protection against Abuse of Functionality ..................................................12 5.1.6. OT.Prot_Inf_Leak Protection against Information Leakage ..........................................................12 5.1.7. OT.Prot_Phys-Tamper Protection against Physical Tampering.....................................................12 5.1.8. OT.Prot_Malfunction Protection against Malfunctions...................................................................12 5.2. Security Objectives for the Operational Environment.................................................................... 13 5.2.1. OE.MRTD_Manufact Protection of the MRTD Manufacturing ......................................................13 5.2.2. OE.MRTD_ Delivery Protection of the MRTD delivery..................................................................13 5.2.3. OE.Personalization Personalization of logical MRTD ...................................................................13 5.2.4. OE.Pass_Auth_Sign Authentication of logical MRTD by Signature..............................................13 5.2.5. OE.BAC-Keys Cryptographic quality of Basic Access Control Keys.............................................13 5.2.6. OE.Exam_MRTD Examination of the MRTD passport book.........................................................13 5.2.7. OE.Passive_Auth_Verif Verification by Passive Authentication ....................................................13 5.2.8. OE.Prot_Logical_MRTD Protection of data from the logical MRTD..............................................13 5.3. Security Objectives Rationale........................................................................................................... 13 6. Extended Components definition...............................................................................17 6.1. Definition of Family FAU_SAS .......................................................................................................... 17 6.2. Definition of Family FCS_RND .......................................................................................................... 17 6.3. Definition of Family FMT_LIM............................................................................................................ 17 6.4. Definition of Family FPT_EMSEC ..................................................................................................... 17 7. Security Requirements................................................................................................18 7.1. Security Functional Requirements for the TOE .............................................................................. 18 7.1.1. Class FAU Security Audit ..............................................................................................................18 7.1.2. Class FCS Cryptographic Support ................................................................................................19 7.1.3. Class FIA Identification and Authentication ...................................................................................20 7.1.4. Class FDP User Data Protection...................................................................................................23 7.1.5. Class FMT Security Management .................................................................................................25 7.1.6. Class FPT Protection of the Security Functions............................................................................26 7.2. Security Assurance Requirements for the TOE .............................................................................. 28 7.3. Security Functional Requirement Rationale.................................................................................... 28 7.4. Dependency Rationale....................................................................................................................... 28 7.5. Security Assurance Requirement Rationale.................................................................................... 29 8. TOE summary specification........................................................................................30 9. Acronyms .....................................................................................................................36 10. Bibliography...............................................................................................................37 KONA2 D2320N ePassport BAC Security Target Lite 1 1. ST Introduction 1.1. ST Reference Document No: SP-08-22 Document Title: KONA2 D2320N ePassport BAC Security Target Lite Version: 1 Revision: 0 Release date: 2018-11-07 Table 1. ST Reference 1.2. TOE Reference Name: KONA2 D2320N ePassport [BAC configuration] Version: 02 Revision: 10 Update (patch) 00 Table 2. TOE Reference 1.3. TOE Overview The TOE defines the security objectives and requirements for the contactless chip of machine readable travel documents (MRTD) based on the requirements and recommendations of the International Civil Aviation Organization (ICAO). It addresses the advanced security methods Basic Access Control in the ‘ICAO Doc 9303’ [ICAO 9303]. The TOE is composed of:   the circuitry of the MRTD’s chip (16-Bit RISC Microcontroller for Smart Cards, S3FT9MG rev 0)   the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated Support Software,   the IC Embedded Software (KONA2 D2320N ePassport V02.10.00),   the associated guidance documentation. It provides the security level of EAL4 augmented with ALC_DVS.2. The TOE type of the current security target is "the contactless integrated circuit chip of machine readable travel documents (MRTD’s chip) programmed according to the Logical Data Structure (LDS) and providing the Basic Access Control", compatible with the expected TOE type described in the [BAC-PP]. KONA2 D2320N ePassport BAC Security Target Lite 2 2. TOE Description The Target of Evaluation (TOE) is the contactless integrated circuit chip of machine readable travel documents (MRTD’s chip) programmed according to the Logical Data Structure (LDS) and providing the Basic Access Control according to ‘ICAO Doc 9303’ [ICAO 9303]. The TOE comprises:   the circuitry of the MRTD’s chip (16-Bit RISC Microcontroller for Smart Cards, S3FT9MG rev 0)   the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated Support Software,   the IC Embedded Software (KONA2 D2320N ePassport V02.10.00),   the associated guidance documentation. TOE usage and security features for operational use: A State or Organization issues MRTD to be used by the holder for international travel. The traveller presents a MRTD to the inspection system to prove his or her identity. The MRTD in context of this security target contains (i) visual (eye readable) biographical data and portrait of the holder, (ii) a separate data summary (MRZ data) for visual and machine reading using OCR methods in the Machine readable zone (MRZ) and (iii) data elements on the MRTD’s chip according to LDS for contactless machine reading. The authentication of the traveller is based on (i) the possession of a valid MRTD personalized for a holder with the claimed identity as given on the biographical data page and (ii) optional biometrics using the reference data stored in the MRTD. The issuing State or Organization ensures the authenticity of the data of genuine MRTD’s. The receiving State trusts a genuine MRTD of an issuing State or Organization. For this security target the MRTD is viewed as unit of: the physical MRTD as travel document in form of paper, plastic and chip. It presents visual readable data including (but not limited to) personal data of the MRTD holder: (1) the biographical data on the biographical data page of the passport book, (2) the printed data in the Machine-Readable Zone (MRZ) and (3) the printed portrait. The logical MRTD as data of the MRTD holder stored according to the Logical Data Structure [ICAO 9303] as specified by ICAO on the contactless integrated circuit. It presents contactless readable data including (but not limited to) personal data of the MRTD holder: (1) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1), (2) the digitized portraits (EF.DG2), (3) the optional biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both1 (4) the other data according to LDS (EF.DG5 to EF.DG16) and (5) the Document security object. The issuing State or Organization implements security features of the MRTD to maintain the authenticity and integrity of the MRTD and their data. The MRTD as the passport book and the MRTD’s chip is uniquely identified by the Document Number. The physical MRTD is protected by physical security measures (e.g. watermark on paper, security printing), logical (e.g. authentication keys of the MRTD’s chip) and organizational security measures (e.g. control of materials, personalization procedures) [ICAO 9303]. KONA2 D2320N ePassport BAC Security Target Lite 3 These security measures include the binding of the MRTD’s chip to the passport book. The logical MRTD is protected in authenticity and integrity by a digital signature created by the document signer acting for the issuing State or Organization and the security features of the MRTD’s chip. The ICAO defines the baseline security methods Passive Authentication and the optional advanced security methods Basic Access Control to the logical MRTD, Active Authentication of the MRTD’s chip, Extended Access Control to and the Data Encryption of additional sensitive biometrics as optional security measure in the ‘ICAO Doc 9303’ [ICAO 9303]. The Passive Authentication Mechanism and the Data Encryption are performed completely and independently on the TOE by the TOE environment. This security target addresses the protection of the logical MRTD (i) in integrity by write only-once access control and by physical means, and (ii) in confidentiality by the Basic Access Control Mechanism. This security target does not address the Active Authentication and the Extended Access Control as optional security mechanisms. The Basic Access Control is a security feature which is mandatory supported by the TOE. The inspection system (i) reads optically the MRTD, (ii) authenticates itself as inspection system by means of Document Basic Access Keys. After successful authentication of the inspection system the MRTD’s chip provides read access to the logical MRTD by means of private communication (secure messaging) with this inspection system [ICAO 9303], normative appendix 5. TOE life cycle: According to [BAC-PP], the TOE life cycle is described in terms of the four life cycle phases which are additionally subdivided into 7 steps. Phase 1 “Development” (Step1) The TOE is developed in phase 1. The IC developer develops the integrated circuit, the IC Dedicated Software and the guidance documentation associated with these TOE components. (Step2) The software developer uses the guidance documentation for the integrated circuit and the guidance documentation for relevant parts of the IC Dedicated Software and develops the IC Embedded Software (operating system), the MRTD application and the guidance documentation associated with these TOE components. The manufacturing documentation of the IC including the IC Dedicated Software and the Embedded Software in the non-volatile programmable memories (FLASH) is securely delivered to the IC manufacturer. The IC Embedded Software in the non- volatile programmable memories, the MRTD application and the guidance documentation is securely delivered to the MRTD manufacturer. Phase 2 “Manufacturing” (Step3) 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 non-volatile programmable memories (FLASH). The IC manufacturer writes the IC Identification Data onto the chip to control the IC as MRTD material during the IC manufacturing and the delivery process to the MRTD manufacturer. The IC is securely delivered from the IC manufacture to the MRTD manufacturer. If necessary the IC manufacturer adds the parts of the IC Embedded Software in the KONA2 D2320N ePassport BAC Security Target Lite 4 non-volatile programmable memories (for instance FLASH). (Step4) The MRTD manufacturer combines the IC with hardware for the contactless interface in the passport book. The MRTD together with the IC Identifier is securely delivered from the MRTD manufacturer to the Personalization Agent. The software developer of the step 2 also provides the relevant parts of the guidance documentation to the Personalization Agent. Phase 3 “Personalization of the MRTD” (Step5) the Personalization Agent equips MRTD’s chips with pre-personalization Data. (Step6) The personalization of the MRTD includes (i) the survey of the MRTD holder’s biographical data, (ii) the enrolment of the MRTD holder biometric reference data (i.e. the digitized portraits and the optional biometric reference data), (iii) the printing of the visual readable data onto the physical MRTD, (iv) the writing of the TOE User Data and TSF Data into the logical MRTD and (v) configuration of the TSF if necessary. The step (iv) is performed by the Personalization Agent and includes but is not limited to the creation of (i) the digital MRZ data (EF.DG1), (ii) the digitized portrait (EF.DG2), and (iii) the Document security object. The signing of the Document security object by the Document Signer [ICAO 9303] finalizes the personalization of the genuine MRTD for the MRTD holder. The personalized MRTD (together with appropriate guidance for TOE use if necessary) is handed over to the MRTD holder for operational use. Phase 4 “Operational Use” (Step7) The TOE is used as MRTD chip by the traveler and the inspection systems in the “Operational Use” phase. The user data can be read according to the security policy of the issuing State or Organization and can be used according to the security policy of the issuing State but they can never be modified. (See the Protection profile for applicable application notes: 1, 2, 3, 4 and 5) A matching table between the card lifecycle states and the TOE lifecycle phases is: Card lifecycle state TOE lifecycle phase Creation State Phase 2. Manufacturing Initialization State Phase 3. Personalization of the MRTD Operation State Phase 4. Operational Use Termination State 2.1. TOE Architecture The TOE is a composition of IC hardware and embedded software that controls the IC. KONA2 D2320N ePassport BAC Security Target Lite 5 Figure 1. TOE Scope The TOE is defined to comprise the chip and the hardware abstraction layer and application. Note, the inlay holding the chip as well as the antenna and the booklet (holding the printed MRZ) are needed to represent a complete MRTD, nevertheless these parts are not inevitable for the secure operation of the TOE. TOE guidance The guidance documentation consists of the:  [AGD_OPE] this guide is delivered to the card holder (card holder or receiving state)  [AGD_PRE] this guide is delivered to the personalization agent (issuing state) ,  [ALC_DEL] this guide is used by all the entities to deliver the TOE between them, KONA2 D2320N ePassport BAC Security Target Lite 6 3. Conformance Claim This security target claims the following conformance with Common Criteria:  Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model, Version 3.1, Revision 4, September 2012 conformant.  Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012 extended conformance with FAU_SAS.1, FCS_RND.1, FMT_LIM.1, FMT_LIM.2 and FPT_EMSEC.1 (defined in the chapter 6. Extended component definition).  Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1, Revision 4, September 2012 conformant. This security target claims the following conformance with protection profiles:  A strict conformance with Common Criteria Protection Profile Machine Readable Travel Document with “ICAO Application”, Basic Access Control version 1.10, 25th March 2009. This security target and the TOE claim conformity with EAL4+, augmented with ALC_DVS.2 (Sufficiency of security measures). 3.1. Conformance Claim rationale The security target and the TOE are conformant with CC version 3.1 Release 4 and the protection profile with CC version 3.1 Release 1 for Part 1 and Release 2 for Part 2 and Part 3. The following statements show the non-incompatibility between both:  The differences between part 1 of CC version 3.1 in Release 1 and Release 4 are only in definitions and in identification of glossary, therefore it is not relevant.  The differences between part 2 of CC version 3.1 in Release 2 and Release 4 applicable in the definition of some SFRs. Some of them are refined for aligning the SFR with the whole definition of the TOE. The following list shows the SFR that suffered changes:  FAU_SAR.1, description of components  FAU_SEL.1.1, requirements modification  FDP_ACF.1.4, requirements modification Information flow control functions (FDP_IFF), family behaviour  FDP_UCT.1.1, requirements modification  FDP_UIT.1.1, requirements modification  TSF self-test (FPT_TST), requirements modification, because in the PP conformant with Revision 2, the requirements of FPT_TST.1.3 applies to TSF executable code, while in Revision 3, it applies TSF or parts of TSF. Our selection covers all the TSF  The differences between part 3 of CC version 3.1 in Release 2 and Release 4 applicable in the definition of some SAR.  Definition of EAL4 reducing the ATE_DPT from 2 to 1 KONA2 D2320N ePassport BAC Security Target Lite 7  Definition of EAL6 level  APE class definitions  Refinement of the definition of TSFI meaning  Suppression of ADV_SPM.1.5C  Mandatory providing of the delivery documentation, Development site security, flaw remediation and documentation of tools and techniques  Renaming terms of architectural design for security architecture description.  Module definition regarding implementation of SFR. These differences don't affects to the compatibility between TOE conformant with CC v3.1 Revision 4 and PP conformant with CC v3.1 Revision 1 and Revision 2. The difference in the SFR is identified in the current ST. This security target uses the iteration operation to differentiate features over the same requirements, being:  FIA_AFL.1/TRANS (for transport key authentication method)  FIA_AFL.1/ISSUER (for Issuer authentication method)  FIA_AFL.1/BAC (for basic access control authentication method)  FIA_UAU.1/TRANS (for transport key authentication method)  FIA_UAU.1/ISSUER (for Issuer authentication method)  FIA_UAU.1/BAC (for basic access control authentication method)  FIA_UID.1/TRANS (for transport key authentication method)  FIA_UID.1/ISSUER (for Issuer authentication method)  FIA_UID.1/BAC (for basic access control authentication method) The TOE type of the current security target is "the contactless integrated circuit chip of machine readable travel documents (MRTD’s chip) programmed according to the Logical Data Structure (LDS) and providing the Basic Access Control", compatible with the expected TOE type described in the [BAC-PP]. KONA2 D2320N ePassport BAC Security Target Lite 8 4. Security Problem Definition 4.1. Introduction Assets The assets to be protected by the TOE include the User Data on the MRTD’s chip. Logical MRTD Data The logical MRTD data consists of the EF.COM, EF.DG1 to EF.DG16 (with different security needs) and the Document Security Object EF.SOD according to LDS [ICAO 9303]. These data are user data of the TOE. The EF.COM lists the existing elementary files (EF) with the user data. The EF.DG1 to EF.DG13 and EF.DG 16 contain personal data of the MRTD holder. The Chip Authentication Public Key (EF.DG 14) is used by the inspection system for the Chip Authentication. The EF.SOD is used by the inspection system for Passive Authentication of the logical MRTD. Due to interoperability reasons as the ‘ICAO Doc 9303’ [ICAO 9303] the TOE described in this security target specifies only the BAC mechanisms with resistance against enhanced basic attack potential granting access to:  Logical MRTD standard User Data (i.e. Personal Data) of the MRTD holder (EF.DG1, EF.DG2, EF.DG5 to EF.DG13, EF.DG16),  Chip Authentication Public Key in EF.DG14,  Active Authentication Public Key in EF.DG15,  Document Security Object (SOD) in EF.SOD,  Common data in EF.COM. The TOE prevents read access to sensitive User Data.  Sensitive biometric reference data (EF.DG3, EF.DG4). A sensitive asset is the following more general one. Authenticity of the MRTD’s chip The authenticity of the MRTD’s chip personalized by the issuing State or Organization for the MRTD holder is used by the traveller to prove his possession of a genuine MRTD. Subjects This security target considers the following subjects: Manufacturer The generic term for the IC Manufacturer producing the integrated circuit and the MRTD Manufacturer completing the IC to the MRTD’s chip. The Manufacturer is the default user of the TOE during the Phase 2 Manufacturing. The TOE does not distinguish between the users IC Manufacturer and MRTD Manufacturer using this role Manufacturer. Personalization Agent The agent is acting on behalf of the issuing State or Organization to personalize the MRTD for the holder by some or all of the following activities (i) establishing the identity the holder for the biographic data in the MRTD, (ii) enrolling the biometric reference data of the MRTD KONA2 D2320N ePassport BAC Security Target Lite 9 holder i.e. the portrait, the encoded finger image(s) and/or the encoded iris image(s) (iii) writing these data on the physical and logical MRTD for the holder as defined for global, international and national interoperability, (iv) writing the initial TSF data and (iv) signing the Document Security Object defined in [ICAO 9303]. Terminal A terminal is any technical system communicating with the TOE through the contactless interface. Inspection system (IS) 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. The Basic Inspection System (BIS) (i) contains a terminal for the contactless communication with the MRTD’s chip, (ii) implements the terminals part of the Basic Access Control Mechanism and (iii) gets the authorization to read the logical MRTD under the Basic Access Control by optical reading the MRTD or other parts of the passport book providing this information. The General Inspection System (GIS) is a Basic Inspection System which implements additionally the Chip Authentication Mechanism. The Extended Inspection System (EIS) in addition to the General Inspection System (i) implements the Terminal Authentication Protocol and (ii) is authorized by the issuing State or Organization through the Document Verifier of the receiving State to read the sensitive biometric reference data. The security attributes of the EIS are defined of the Inspection System Certificates. MRTD Holder The rightful holder of the MRTD for whom the issuing State or Organization personalized the MRTD. Traveller Person presenting the MRTD to the inspection system and claiming the identity of the MRTD holder. Attacker A threat agent trying (i) to identify and to trace the movement of the MRTD’s chip remotely (i.e. without knowing or optically reading the printed MRZ data), (ii) to read or to manipulate the logical MRTD without authorization, or (iii) to forge a genuine MRTD. 4.2. Assumptions 4.2.1. A.MRTD_Manufact MRTD manufacturing on step 4 to 6 This assumption is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 54). 4.2.2. A.MRTD_Delivery MRTD delivery during steps 4 to 6 This assumption is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 55). 4.2.3. A.Pers_Agent Personalization of the MRTD’s chip This assumption is included in the ST and it is described in the MRTD, “ICAO KONA2 D2320N ePassport BAC Security Target Lite 10 Application", Basic Access Control PP (paragraph 56). 4.2.4. A.Insp_Sys Inspection Systems for global interoperability This assumption is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 57). 4.2.5. A.BAC-Keys Cryptographic quality of Basic Access Control Keys This assumption is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 59). 4.3. Threats 4.3.1. T.Chip_ID Identification of MRTD’s chip This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 63). 4.3.2. T.Skimming Skimming the logical MRTD This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP, paragraph 64. 4.3.3. T.Eavesdropping Eavesdropping to the communication between TOE and inspection system This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 65). 4.3.4. T.Forgery Forgery of data on MRTD’s chip This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 66). 4.3.5. T.Abuse-Func Abuse of Functionality This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 68). 4.3.6. T.Information_Leakage Information Leakage from MRTD’s chip This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 69). 4.3.7. T.Phys-Tamper Physical Tampering This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 70). KONA2 D2320N ePassport BAC Security Target Lite 11 4.3.8. T.Malfunction Malfunction due to Environmental Stress This threat is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 71). 4.4. Organizational Security Policies 4.4.1. P.Manufact Manufacturing of the MRTD’s chip This security policy is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 73). 4.4.2. P.Personalization Personalization of the MRTD by issuing State or Organization only This security policy is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 74). 4.4.3. P.Personal_Data Personal data protection policy This security policy is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 75). KONA2 D2320N ePassport BAC Security Target Lite 12 5. Security Objectives This chapter describes the security objectives for the TOE and the security objectives for the TOE environment. The security objectives for the TOE environment are separated into security objectives for the development and production environment and security objectives for the operational environment. 5.1. Security Objectives for the TOE 5.1.1. OT.AC_Pers Access Control for Personalization of logical MRTD This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 79). 5.1.2. OT.Data_Int Integrity of personal data This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 81). 5.1.3. OT.Data_Conf Confidentiality of personal data This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 82). 5.1.4. OT.Identification Identification and Authentication of the TOE This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 84). 5.1.5. OT.Prot_Abuse-Func Protection against Abuse of Functionality This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 87). 5.1.6. OT.Prot_Inf_Leak Protection against Information Leakage This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 88). 5.1.7. OT.Prot_Phys-Tamper Protection against Physical Tampering This security objective for the TOE is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 90). 5.1.8. OT.Prot_Malfunction Protection against Malfunctions This security objective for the TOE is included in the ST and it is described in the MRTD, KONA2 D2320N ePassport BAC Security Target Lite 13 “ICAO Application", Basic Access Control PP (paragraph 91). 5.2. Security Objectives for the Operational Environment 5.2.1. OE.MRTD_Manufact Protection of the MRTD Manufacturing This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 94). 5.2.2. OE.MRTD_ Delivery Protection of the MRTD delivery This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 95). 5.2.3. OE.Personalization Personalization of logical MRTD This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 96). 5.2.4. OE.Pass_Auth_Sign Authentication of logical MRTD by Signature This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 97). 5.2.5. OE.BAC-Keys Cryptographic quality of Basic Access Control Keys This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 98). 5.2.6. OE.Exam_MRTD Examination of the MRTD passport book This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 100). 5.2.7. OE.Passive_Auth_Verif Verification by Passive Authentication This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 101). 5.2.8. OE.Prot_Logical_MRTD Protection of data from the logical MRTD This security objective for the environment is included in the ST and it is described in the MRTD, “ICAO Application", Basic Access Control PP (paragraph 102). 5.3. Security Objectives Rationale KONA2 D2320N ePassport BAC Security Target Lite 14 The following table provides an overview for security objectives coverage: OT.AC_Pers OT.Data_Int OT.Data_Conf OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction OE.MRTD_Manufact OE.MRTD_Delivery OE.Personalization OE.Pass_Auth_Sign OE.BAC-Keys OE.Exam_MRTD OE.Passive_Auth_Verif OE.Prot_Logical_MRTD T.Chip-ID X X T.Skimming X X T.Eavesdropping X T.Forgery X X X X X X T.Abuse-Func X X T.Information_Leak age X T.Phys-Tamper X T.Malfunction X P.Manufact X P.Personalization X X X P.Personal_Data X X A.MRTD_Manufact X A.MRTD_Delivery X A.Pers_Agent X A.Insp_Sys X X A.BAC-Keys X Table 3. Coverage table between SPD and Objectives The OSP P.Manufact “Manufacturing of the MRTD’s chip” requires a unique identification of the IC by means of the Initialization Data and the writing of the Pre-personalization Data as being fulfilled by OT.Identification. The OSP P.Personalization “Personalization of the MRTD by issuing State or Organization only” addresses the (i) the enrolment of the logical MRTD by the Personalization Agent as described in the security objective for the TOE environment OE.Personalization “Personalization of logical MRTD”, and (ii) the access control for the user data and TSF data as described by the security objective OT.AC_Pers “Access Control for Personalization of logical MRTD”. Note the manufacturer equips the TOE with the Personalization Agent Key(s) according to OT.Identification “Identification and Authentication of the TOE”. The security objective OT.AC_Pers limits the management of TSF data and management of TSF to the Personalization Agent. The OSP P.Personal_Data “Personal data protection policy” requires the TOE (i) to support the protection of the confidentiality of the logical MRTD by means of the Basic Access Control and (ii) enforce the access control for reading as decided by the issuing State or Organization. This policy is implemented by the security objectives OT.Data_Int “Integrity of personal data” describing the unconditional protection of the integrity of the stored data and during transmission. The security objective OT.Data_Conf “Confidentiality of personal data” describes the protection of the confidentiality. The threat T.Chip_ID “Identification of MRTD’s chip” addresses the trace of the MRTD KONA2 D2320N ePassport BAC Security Target Lite 15 movement by identifying remotely the MRTD’s chip through the contactless communication interface. This threat is countered as described by the security objective OT.Identification by Basic Access Control using sufficiently strong derived keys as required by the security objective for the environment OE.BAC-Keys. The threat T.Skimming “Skimming digital MRZ data or the digital portrait” and T.Eavesdropping “Eavesdropping to the communication between TOE and inspection system” address the reading of the logical MRTD trough the contactless interface or listening the communication between the MRTD’s chip and a terminal. This threat is countered by the security objective OT.Data_Conf “Confidentiality of personal data” through Basic Access Control using sufficiently strong derived keys as required by the security objective for the environment OE.BAC-Keys. The threat T.Forgery “Forgery of data on MRTD’s chip” addresses the fraudulent alteration of the complete stored logical MRTD or any part of it. The security objective OT.AC_Pers “Access Control for Personalization of logical MRTD“ requires the TOE to limit the write access for the logical MRTD to the trustworthy Personalization Agent (cf. OE.Personalization). The TOE will protect the integrity of the stored logical MRTD according the security objective OT.Data_Int “Integrity of personal data” and OT.Prot_Phys-Tamper “Protection against Physical Tampering”. The examination of the presented MRTD passport book according to OE.Exam_MRTD “Examination of the MRTD passport book” shall ensure that passport book does not contain a sensitive contactless chip which may present the complete unchanged logical MRTD. The TOE environment will detect partly forged logical MRTD data by means of digital signature which will be created according to OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature” and verified by the inspection system according to OE.Passive_Auth_Verif “Verification by Passive Authentication”. The threat T.Abuse-Func “Abuse of Functionality” addresses attacks using the MRTD’s chip as production material for the MRTD and misuse of the functions for personalization in the operational state after delivery to MRTD holder to disclose or to manipulate the logical MRTD. This threat is countered by OT.Prot_Abuse-Func “Protection against Abuse of Functionality”. Additionally this objective is supported by the security objective for the TOE environment: OE.Personalization “Personalization of logical MRTD” ensuring that the TOE security functions for the initialization and the personalization are disabled and the security functions for the operational state after delivery to MRTD holder are enabled according to the intended use of the TOE. The threats T.Information_Leakage “Information Leakage from MRTD’s chip”, T.Phys-Tamper “Physical Tampering” and T.Malfunction “Malfunction due to Environmental Stress” are typical for integrated circuits like smart cards under direct attack with high attack potential. The protection of the TOE against these threats is addressed by the directly related security objectives OT.Prot_Inf_Leak “Protection against Information Leakage”, OT.Prot_Phys-Tamper “Protection against Physical Tampering” and OT.Prot_Malfunction “Protection against Malfunctions”. The assumption A.MRTD_Manufact “MRTD manufacturing on step 4 to 6” is covered by the security objective for the TOE environment OE.MRTD_Manufact “Protection of the MRTD Manufacturing” that requires to use security procedures during all manufacturing steps. The assumption A.MRTD_Delivery “MRTD delivery during step 4 to 6” is covered by the security objective for the TOE environment OE.MRTD_ Delivery “Protection of the MRTD delivery” that requires to use security procedures during delivery steps of the MRTD. KONA2 D2320N ePassport BAC Security Target Lite 16 The assumption A.Pers_Agent “Personalization of the MRTD’s chip” is covered by the security objective for the TOE environment OE.Personalization “Personalization of logical MRTD” including the enrolment, the protection with digital signature and the storage of the MRTD holder personal data. The examination of the MRTD passport book addressed by the assumption A.Insp_Sys “Inspection Systems for global interoperability” is covered by the security objectives for the TOE environment OE.Exam_MRTD “Examination of the MRTD passport book”. The security objectives for the TOE environment OE.Prot_Logical_MRTD “Protection of data from the logical MRTD” will require the Basic Inspection System to implement the Basic Access Control and to protect the logical MRTD data during the transmission and the internal handling. The assumption A.BAC-Keys “Cryptographic quality of Basic Access Control Keys” is directly covered by the security objective for the TOE environment OE.BAC-Keys “Cryptographic quality of Basic Access Control Keys” ensuring the sufficient key quality to be provided by the issuing State or Organization. KONA2 D2320N ePassport BAC Security Target Lite 17 6. Extended Components definition This security target uses components defined as extensions to CC part 2. 6.1. Definition of Family FAU_SAS This family and components (FAU_SAS.1) of security functional requirements are included and described in the MRTD, “ICAO Application", Basic Access Control PP (section 5.1). 6.2. Definition of Family FCS_RND This family and components (FCS_RND.1) of security functional requirements are included and described in the MRTD, “ICAO Application", Basic Access Control PP (section 5.2). 6.3. Definition of Family FMT_LIM This family and components (FMT_LIM.1 and FMT_LIM.2) of security functional requirements are included and described in the MRTD, “ICAO Application", Basic Access Control PP (section 5.3). 6.4. Definition of Family FPT_EMSEC This family and components (FPT_EMSEC.1) of security functional requirements are included and described in the MRTD, “ICAO Application", Basic Access Control PP (section 5.4). KONA2 D2320N ePassport BAC Security Target Lite 18 7. Security Requirements This chapter describes the security requirements for the TOE, considering this notation for the operation for SFR:  Assignment: value defined between square-bracket and italic; e.g.: [assignment: values ]  Selection: value defined between square-bracket and italic; e.g.: [selection: value]  Iteration: denoted with / separator and component identifier; e.g.: FCS_COP.1/SHA  Refinement: denoted as bold text; e.g.: Content The definition of the subjects “Manufacturer”, “Personalization Agent”, “Basic Inspection System” and “Terminal” used in the following chapter is given in section 3.1 from the [BAC-PP]. Note that all these subjects are acting for homonymous external entities. All used objects are defined in section 7 from the [BAC-PP]. The operations “write”, “read”, “modify”, and “disable read access” are used in accordance with the general linguistic usage. The operations “transmit”, “receive” and “authenticate” are originally taken from Common Criteria 3.1 R3 Part 2. Definition of security attributes: security attribute meaning values Terminal authentication status None (any Terminal) Default role (i.e. without authorisation after start-up) Basic Inspection System Terminal is authenticated as Basic Inspection System after successful Authentication in accordance with the definition in rule 2 of FIA_UAU.5.2. Personalisation Agent Terminal is authenticated as Personalisation Agent after successful Authentication in accordance with the definition in rule 1 of FIA_UAU.5.2. Table 4. Definition of Security Attributes 7.1. Security Functional Requirements for the TOE This section describes the security functional requirements for the TOE. 7.1.1. Class FAU Security Audit Audit storage (FAU_SAS.1) The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common Criteria Part 2 extended). FAU_SAS.1 Audit storage Hierarchical to: No other components. Dependencies No dependencies. FAU_SAS.1.1 The TSF shall provide the Manufacturer with the capability to store the IC Identification Data in the audit records. KONA2 D2320N ePassport BAC Security Target Lite 19 7.1.2. Class FCS Cryptographic Support Cryptographic key generation (FCS_CKM.1) The TOE shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” as specified below (Common 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 Cryptographic key generation – Generation of Document Basic Access Keys by the TOE 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 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm Document Basic Access Key Derivation Algorithm and specified cryptographic key sizes 112 bit that meet the following: [ICAO 9303] normative appendix 5 Cryptographic key destruction (FCS_CKM.4) The TOE shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as specified below (Common Criteria Part 2). FCS_CKM.4 Cryptographic key destruction – 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.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: randomisation] that meets the following: [assignment: none]. Cryptographic operation (FCS_COP.1) The TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below (Common Criteria Part 2). The iterations are caused by different cryptographic algorithms to be implemented by the TOE. FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation 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/ SHA The TSF shall perform hashing in accordance with a specified cryptographic algorithm [selection: SHA-1] and cryptographic key sizes none that meet the following: [selection: FIPS 180-4]. FCS_COP.1/ENC Cryptographic operation – Encryption / Decryption Triple DES 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 KONA2 D2320N ePassport BAC Security Target Lite 20 FCS_COP.1.1/ ENC The TSF shall perform secure messaging (BAC) – encryption and decryption in accordance with a specified cryptographic algorithm Triple-DES in CBC mode and cryptographic key sizes 112 bit that meet the following: FIPS 46-3 [DES] and [ICAO 9303]; normative appendix 5, A5.3 FCS_COP.1/AUTH Cryptographic operation – Authentication 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/ AUTH The TSF shall perform symmetric authentication – encryption and decryption in accordance with a specified cryptographic algorithm [selection: Triple-DES] and cryptographic key sizes [selection: 112] bit that meet the following: [selection: FIPS 46-3]. FCS_COP.1/MAC Cryptographic operation – Retail 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] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ MAC The TSF shall perform secure messaging – message authentication code in accordance with a specified cryptographic algorithm Retail MAC and cryptographic key sizes 112 bit that meet the following: ISO 9797 (MAC algorithm 3, block cipher DES, Sequence Message Counter, padding mode 2). Random Number Generation (FCS_RND.1) The TOE shall meet the requirement “Quality metric for random numbers (FCS_RND.1)” as specified below (Common Criteria Part 2 extended). FCS_RND.1 Quality metric for random numbers Hierarchical to: No other components. Dependencies No dependencies FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet [assignment: 1. Test procedure A does not distinguish the internal random numbers from output sequences of an ideal RNG. 2. The average Shannon entropy per internal random bit exceeds 0.997(7.976 bits per octet) ] 7.1.3. Class FIA Identification and Authentication Timing of identification (FIA_UID.1) The TOE shall meet the requirement “Timing of identification (FIA_UID.1)” as specified below (Common Criteria Part 2). FIA_UID.1/TRANS Timing of identification Hierarchical to: No other components. KONA2 D2320N ePassport BAC Security Target Lite 21 Dependencies No dependencies FIA_UID.1.1 The TSF shall allow [assignment: request of commands which are available in the ‘Creation state’ of Card lifecycle] on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user FIA_UID.1/ISSUER Timing of identification Hierarchical to: No other components. Dependencies No dependencies FIA_UID.1.1 The TSF shall allow [assignment: request of commands which are available in the ‘Initialization state’ of Card lifecycle, except the dedicated commands for ISSUER key authenticated channel] on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user FIA_UID.1/BAC Timing of identification Hierarchical to: No other components. Dependencies No dependencies FIA_UID.1.1 The TSF shall allow [assignment: reading the random identifier in Phase 4 “Operational Use”] on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user Timing of authentication (FIA_UAU.1) The TOE shall meet the requirement “Timing of authentication (FIA_UAU.1)” as specified below (Common Criteria Part 2). FIA_UAU.1/TRANS Timing of authentication Hierarchical to: No other components. Dependencies FIA_UID.1 Timing of identification. FIA_UAU.1.1 The TSF shall allow [assignment: request of commands which are available in the ‘Creation state’ of Card lifecycle] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.1/ISSUER Timing of authentication Hierarchical to: No other components. Dependencies FIA_UID.1 Timing of identification. FIA_UAU.1.1 The TSF shall allow [assignment: request of commands which are available in the ‘Initialization state’ of Card lifecycle, except the dedicated commands for ISSUER key authenticated channel] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.1/BAC Timing of authentication Hierarchical to: No other components. Dependencies FIA_UID.1 Timing of identification. FIA_UAU.1.1 The TSF shall allow [assignment: reading the random identifier in Phase 4 “Operational Use”] on behalf of the user to be performed KONA2 D2320N ePassport BAC Security Target Lite 22 before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Single-use authentication mechanisms (FIA_UAU.4) The TOE shall meet the requirements of “Single-use authentication mechanisms (FIA_UAU.4)” as specified below (Common Criteria Part 2). FIA_UAU.4 Single-use authentication mechanisms - Single-use authentication of the Terminal by the TOE Hierarchical to: No other components. Dependencies No dependencies. FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to: 1.Basic Access Control Authentication Mechanism, 2. Authentication Mechanism based on [selection: Triple-DES]. Multiple authentication mechanisms (FIA_UAU.5) The TOE shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)” as specified below (Common Criteria Part 2). FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. Dependencies No dependencies FIA_UAU.5.1 The TSF shall provide 1. Basic Access Control Authentication Mechanism 2. Symmetric Authentication Mechanism based on [selection: Triple- DES] to support user authentication. FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according to the following rules: 1. the TOE accepts the authentication attempt as Personalization Agent by one of the following mechanism(s) [selection: the Symmetric Authentication Mechanism with the Personalization Agent Key ] 2. the TOE accepts the authentication attempt as Basic Inspection System only by means of the Basic Access Control Authentication Mechanism with the Document Basic Access Keys. Re-authenticating (FIA_UAU.6) The TOE shall meet the requirement “Re-authenticating (FIA_UAU.6)” as specified below (Common Criteria Part 2). FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies No dependencies. FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions each command sent to the TOE during a BAC mechanism based communication after successful authentication of the terminal with Basic Access Control Authentication Mechanism. Authentication failure handling (FIA_AFL.1) The TOE shall meet the requirement “Authentication failure handling (FIA_AFL.1)” as specified below (Common Criteria Part 2). FIA_AFL.1/TRANS Authentication failure handling-Transport key authentication using KONA2 D2320N ePassport BAC Security Target Lite 23 Hierarchical to: No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1 /TRANS The TSF shall detect when [selection: [assignment: 30]] consecutive unsuccessful authentication attempts occur related to [assignment: failure of a Triple-DES based Transport key authentication]. FIA_AFL.1.2 /TRANS When the defined number of unsuccessful authentication attempts has been [assignment: met], the TSF shall [assignment: terminate itself or generate security reset]. FIA_AFL.1/ISSUER Authentication failure handling-Issuer authentication using Hierarchical to: No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1 /ISSUER The TSF shall detect when [selection: [assignment: 30]] consecutive unsuccessful authentication attempts occur related to [assignment: failure of a Triple-DES based issuer authentication]. FIA_AFL.1.2 /ISSUER When the defined number of unsuccessful authentication attempts has been [assignment: met], the TSF shall [assignment: terminate itself or generate security reset]. FIA_AFL.1/BAC Authentication failure handling - BAC authentication using Hierarchical to: No other components. Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1 /BAC The TSF shall detect when [selection: [assignment: 1]] consecutive unsuccessful authentication attempts occur related to [assignment: failure of a Triple-DES based basic access control]. FIA_AFL.1.2 /BAC When the defined number of unsuccessful authentication attempts has been [assignment: met], the TSF shall [assignment: increase the reaction time of the TOE to the next authentication attempt using BAC by 0.1 seconds until reaching a maximum of 3 seconds]. 7.1.4. Class FDP User Data Protection Subset access control (FDP_ACC.1) The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below (Common Criteria Part 2). FDP_ACC.1 Subset access control – Basic Access control Hierarchical to: No other components. Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.1.1 The TSF shall enforce the Basic Access Control SFP on terminals gaining write, read and modification access to data in the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD. Security attribute based access control (FDP_ACF.1) The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified below (Common Criteria Part 2). FDP_ACF.1 Basic Security attribute based access control – Basic Access Control Hierarchical to: No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1 The TSF shall enforce the Basic Access Control SFP to objects based on the following: KONA2 D2320N ePassport BAC Security Target Lite 24 1. Subjects: a. Personalization Agent, b. Basic Inspection System, c. Terminal, 2. Objects: a. data EF.DG1 to EF.DG16 of the logical MRTD, b. data in EF.COM, c. data in EF.SOD, 3. Security attributes a. authentication status of terminals. FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 1. the successfully authenticated Personalization Agent is allowed to write and to read the data of the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD, 2. the successfully authenticated Basic Inspection System is allowed to read the data in EF.COM, EF.SOD, EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 of the logical MRTD. FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the rule: 1. Any terminal is not allowed to modify any of the EF.DG1 to EF.DG16 of the logical MRTD. 2. Any terminal is not allowed to read any of the EF.DG1 to EF.DG16 of the logical MRTD. 3. The Basic Inspection System is not allowed to read the data in EF.DG3 and EF.DG4. Basic data exchange confidentiality (FDP_UCT.1) The TOE shall meet the requirement “Basic data exchange confidentiality (FDP_UCT.1)” as specified below (Common Criteria Part 2). FDP_UCT.1 Basic data exchange confidentiality – MRTD Hierarchical to: No other components. Dependencies [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_UCT.1.1 The TSF shall enforce the Basic Access Control SFP to be able to transmit and receive user data in a manner protected from unauthorized disclosure. FDP_UIT.1 Data exchange integrity - MRTD Hierarchical to: No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_UIT.1.1 The TSF shall enforce the Basic Access Control SFP to be able to transmit and receive user data in a manner protected from modification, deletion, insertion and replay errors. FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay has occurred. KONA2 D2320N ePassport BAC Security Target Lite 25 7.1.5. Class FMT Security Management Specification of Management Functions (FMT_SMF.1) The TOE shall meet the requirement “Specification of Management Functions (FMT_SMF.1)” as specified below (Common Criteria Part 2). FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. Dependencies No Dependencies FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 1. Initialization, 2. Pre-personalization, 3. Personalization. Security roles (FMT_SMR.1) The TOE shall meet the requirement “Security roles (FMT_SMR.1)” as specified below (Common Criteria Part 2). FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies FIA_UID.1 Timing of identification. FMT_SMR.1.1 The TSF shall maintain the roles 1. Manufacturer, 2. Personalization Agent, 3. Basic Inspection System. FMT_SMR.1.2 The TSF shall be able to associate users with roles Limited capabilities (FMT_LIM.1) The TOE shall meet the requirement “Limited capabilities (FMT_LIM.1)” as specified below (Common Criteria Part 2 extended). FMT_LIM.1 Limited capabilities Hierarchical to: No other components. Dependencies FMT_LIM.2 Limited availability. FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow 1. User Data to be disclosed or manipulated 2. TSF data to be disclosed or manipulated 3. software to be reconstructed and 4. substantial information about construction of TSF to be gathered which may enable other attacks Limited availability (FMT_LIM.2) The TOE shall meet the requirement “Limited availability (FMT_LIM.2)” as specified below (Common Criteria Part 2 extended). 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 KONA2 D2320N ePassport BAC Security Target Lite 26 that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: Deploying Test Features after TOE Delivery does not allow 1. User Data to be disclosed or manipulated, 2. TSF data to be disclosed or manipulated 3. software to be reconstructed and 4. substantial information about construction of TSF to be gathered which may enable other attacks. Management of TSF data (FMT_MTD.1) The TOE shall meet the requirement “Management of TSF data (FMT_MTD.1)” as specified below (Common Criteria Part 2). The iterations address different management functions and different TSF data. FMT_MTD.1/INI_ENA Management of TSF data – Writing of Initialization Data and Pre-personalization Data Hierarchical to: No other components. Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/INI_ENA The TSF shall restrict the ability to write the Initialization Data and Pre-personalization Data to the Manufacturer. FMT_MTD.1/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 FMT_SMR.1 Security roles FMT_MTD.1.1/INI_DIS The TSF shall restrict the ability to disable read access for users to the Initialization Data to the Personalization Agent. FMT_MTD.1/KEY_WRITE Management of TSF data – Key Write Hierarchical to: No other components. Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/KEY_WRITE The TSF shall restrict the ability to write the Document Basic Access Keys to the Personalization Agent. FMT_MTD.1/KEY_READ Management of TSF data – Key Read Hierarchical to: No other components. Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1/ KEY_READ The TSF shall restrict the ability to read the Document Basic Access Keys and Personalization Agent Keys to none. 7.1.6. Class FPT Protection of the Security Functions The TOE shall prevent inherent and forced illicit information leakage for User Data and TSF Data. The security functional requirement FPT_EMSEC.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 preservation of secure state (FPT_FLS.1)” and “TSF testing (FPT_TST.1)” on the one hand and “Resistance to physical 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 KONA2 D2320N ePassport BAC Security Target Lite 27 SAR “Security architecture description” (ADV_ARC.1) prevent bypassing, deactivation and manipulation of the security features or misuse of TOE functions. TOE Emanation (FPT_EMSEC.1) The TOE shall meet the requirement “TOE Emanation (FPT_EMSEC.1)” as specified below (Common Criteria Part 2 extended). FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components. Dependencies No Dependencies. FPT_EMSEC.1.1 The TOE shall not emit [assignment: electromagnetic field] in excess of [assignment: values that allows deduce sensitive information] enabling access to Personalization Agent Key(s) and [assignment: none]. FPT_EMSEC.1.2 The TSF shall ensure any unauthorized users are unable to use the following interface smart card circuit contacts to gain access to Personalization Agent Key(s) and [assignment: none]. Failure with preservation of secure state (FPT_FLS.1) The TOE shall meet the requirement “Failure with preservation of secure state (FPT_FLS.1)” as specified below (Common Criteria Part 2). FPT_FLS.1 Failure with preservation of secure state Hierarchical to: No other components. Dependencies No Dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: 1. Exposure to out-of-range operating conditions where therefore a malfunction could occur, 2. failure detected by TSF according to FPT_TST.1. TSF testing (FPT_TST.1) The TOE shall meet the requirement “TSF testing (FPT_TST.1)” as specified below (Common Criteria Part 2). 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 [selection: during initial start-up at the conditions [assignment: before the cryptographic operation is activated, and after the cryptographic operation has been activated.]] 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. FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of TSF executable code. Resistance to physical attack (FPT_PHP.3) The TOE shall meet the requirement “Resistance to physical attack (FPT_PHP.3)” as specified below (Common Criteria Part 2). 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 KONA2 D2320N ePassport BAC Security Target Lite 28 TSF by responding automatically such that the SFRs are always enforced. 7.2. Security Assurance Requirements for the TOE The for the evaluation of the TOE and its development and operating environment are those taken from the   Evaluation Assurance Level 4 (EAL4) and augmented by taking the following component:   ALC_DVS.2 7.3. Security Functional Requirement Rationale The traceability table and the coverage rationale between SFR and security objectives is provided in the [BAC-PP], section 6.3.1. Rationale for additional SFRs as below: OT.AC_Pers OT.Data_Int OT.Data_Conf OT.Identification OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction OT.Prot_Abuse-Func FIA_AFL.1/TRANS X X FIA_AFL.1/ISSUER X X FIA_AFL.1/BAC X X FIA_UAU.1/TRANS X X FIA_UAU.1/ISSUER X X FIA_UAU.1/BAC X X FIA_UID.1/TRANS X X FIA_UID.1/ISSUER X X FIA_UID.1/BAC X X 7.4. Dependency Rationale The dependency analysis for the SFRs is provided in the [BAC-PP], section 6.3.2. Rationale for additional Dependency as below SFR Dependencies Support of the Dependencies FIA_AFL.1/TRANS FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1/TRANS FIA_AFL.1/ISSUER FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1/ISSUER KONA2 D2320N ePassport BAC Security Target Lite 29 FIA_AFL.1/BAC FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1/BAC FIA_UAU.1/TRAN S FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1/TRANS FIA_UAU.1/ISSU ER FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1/ISSUER FIA_UAU.1/BAC FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1/BAC FMT_SMR.1 FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1/TRANS, FIA_UID.1/ISSUER, FIA_UID.1/BAC 7.5. Security Assurance Requirement Rationale The EAL4 was chosen to permit a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. EAL4 is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur sensitive security specific engineering costs. The selection of the component ALC_DVS.2 provides a higher assurance of the security of the MRTD’s development and manufacturing especially for the secure handling of the MRTD’s material. The component ALC_DVS.2 augmented to EAL4 has no dependencies to other security requirements. KONA2 D2320N ePassport BAC Security Target Lite 30 8. TOE summary specification Access Control Access Control generates a session key for secure messaging according to the appropriate security procedures. It can also perform authentication according to the life cycle of the TOE. It ensures that at any time, sensitive data must be Invisible: It also controls access to the life cycle according to the policy below: In the personalization phase: - The authorized user through the key can perform limited control TOE and can perform the personalization of the TOE. In the operational use: - No one should be able to change the functions and control of the TOE. - The TOE shall ensure that the personalization data must not be modified except for migration certification by certificate chaining. BAC mechanism The TSF ensures securely BAC operation for generates session key. Secure Messaging The TSF ensures the integrity, confidentiality, and authenticity. After BAC, a secure channel is established. Safety management The TSF provides the following security measures. - Low atomic write to correct the problem when Sudden power off - Sensors and security codes that can detect security attacks. Supports a killing mechanism for protecting the TOE when an attack is continuously detected - Using the active shield to protect TOE against physical attacks. Test to verify TSFs: - The data integrity is checked before data usage - The Security functions is checked at each power on This section provides a detail of how the TOE satisfies all the security functional requirements:   FAU_SAS.1 Audit storage IC Manufacturer writes IC Serial Number during IC manufacturing process. MRTD Manufacturer does not deal with any Pre-personalization data.   FCS_CKM.1 Cryptographic key generation Document Access Keys are stored in TOE during personalization phase by Personalization Agent. When secure messaging begins the TSF generates session keys using Basic Access Keys which protect commands and responses exchanged between a terminal and a card.   FCS_CKM.4 Cryptographic key destruction While secure messaging is performing, if the TSF detects that retail-MAC is incorrect or a decrypted APDU is invalid, it destroys the generated session keys by overwriting them with random numbers.   FCS_COP.1/SHA Cryptographic operation KONA2 D2320N ePassport BAC Security Target Lite 31 The TOE is capable of performing a message digest operations with SHA-1 algorithm defined in all iterations of this SFR. It also meets each standard as specified. Each operation is implemented in software.   FCS_COP.1/ENC Cryptographic operation The TOE is capable of performing the secure messaging – encryption and decryption operation with Triple-DES CBC mode (112 bits key) defined in all iterations of this SFR. It also meets each standard as specified. Each operation is implemented in software.   FCS_COP.1/AUTH Cryptographic operation The TOE is capable of performing the symmetric authentication – encryption and decryption operation with Triple-DES (112 bits key) algorithm defined in all iterations of this SFR. It also meets each standard as specified. Each operation is implemented in software.   FCS_COP.1/MAC Cryptographic operation The TOE is capable of performing the secure messaging – message authentication code operation with ISO 9797 Triple-DES MAC M3 algorithm with 112 bits key defined in all iterations of this SFR. It also meets each standard as specified. Each operation is implemented in software.   FCS_RND.1 Quality metric for random numbers The TSF uses random numbers generated by underlying platform which ensures level of entropy specified in [STIC]. The TSF also execute the AIS31 statistical tests(Test Procedure A) of goodness recommended in [AIS31] on the random numbers. Moreover, the TOE does not use or output any random numbers in the cases that they do not pass the statistical test or RNG hardware test fails.   FIA_UID.1/TRANS Timing of identification Since the ‘Creation State’ is an irreversible state which allows operations for TRANPORT key authentication, the TOE with the ‘Creation State’ assumes that an entity who accesses the TOE is a ‘Personalization Agent’ having the TRANSPORT key. So, by sending GET CHALLENGE command for ISSUER AUTHENTICATE, the user claims his identity as ‘Personalization Agent’ to the TOE in the ‘Creation State’.   FIA_UID.1/ISSUER Timing of identification The ‘Initialization State’ is an irreversible state which allows operations for issuing process, and the TOE with ‘Initialization State’ is transited state from the ‘Creation State’ by successful authentication with the TRANPORT key. So, by sending GET CHALLENGE command for the ISSUER AUTHENTICATE, the user claims his identity as ‘ISSUER’ to the TOE in the ‘Initialization State’.   FIA_UID.1/BAC Timing of identification After completion of personalization phase, the card life-cycle transfers to OPERATION state which is “Operational Use” phase of MRTD. In that state, nobody is allowed to read IC Serial Number (Initialization data) except a user which identifies itself as Personalization Agent. In all states, the TOE uses random identifier for contactless activation, so it is not possible track each TOE by the identifier. The rest of commands are not available if the user is not identified KONA2 D2320N ePassport BAC Security Target Lite 32   FIA_UAU.1/TRANS Timing of authentication The TOE implements four life-cycle states, which are CREATION, INITIALISATION, OPERATION and TERMINATE states. In CREATION state, Transport Key must be authenticated to activate card functionality.   FIA_UAU.1/ISSUER Timing of authentication After Transport Key authentication, the card life-cycle transfers to INITIALISATION state and a user which authenticates Personalization Agent keys is allowed to write personalization data. The user in CREATION and INITIALISATION state is allowed to read IC Serial Number (Initialization data) to identify each TOE in the life-cycle state.   FIA_UAU.1/BAC Timing of authentication After completion of personalization phase, the card life-cycle transfers to OPERATION state which is “Operational Use” phase of MRTD. In that state, nobody is allowed to read IC Serial Number (Initialization data) except a user which identifies itself as Personalization Agent. In all states, the TOE uses random identifier for contactless activation, so it is not possible track each TOE by the identifier. The rest of commands are not available if the user is not authenticated   FIA_UAU.4 Single-use authentication mechanisms The TSF requires using random number to establish secure channel for Basic Access Control according to [ICAO 9303]. It also requires using challenge to authenticate Personalization Agent keys.   FIA_UAU.5 Multiple authentication mechanisms The TSF implements Basic Access Control Authentication Mechanism using Document Basic Access Keys based on Triple-DES algorithm. It also supports Personalization Agent Authentication using Symmetric Authentication Mechanism based on Triple-DES algorithm.   FIA_UAU.6 Re-authenticating The TSF implements Basic Access Control Authentication Mechanism according to [ICAO 9303]. The TOE always enforces checking by secure messaging in MAC_ENC mode each command based on Retail-MAC whether it was sent by the successfully authenticated terminal. The does not process any commands with incorrect MAC. So the TSF re-authenticates the user for each received command and accepts only those commands received from the previously authenticated BAC user.   FIA_AFL.1/TRANS Authentication failure handling-Transport key authentication using The TOE terminates (reset) itself if 30 times unsuccessful Transport key authentication attempts have been occurred. Since the successful authentication with the TRANSPORT KEY causes state transition of the TOE to the Initialization state, the failure counter doesn’t have to be initialized. So, the TOE doesn’t initialize the failure counter of the TRANSPORT key.   FIA_AFL.1/ISSUER Authentication failure handling-Issuer authentication using KONA2 D2320N ePassport BAC Security Target Lite 33 The TOE terminates (reset) itself if 30 times consecutive unsuccessful Personalization Agent key authentication attempts have been occurred. Once ISSUER Authentication success, the accumulated counter is initialized by 0.   FIA_AFL.1/BAC Authentication failure handling - BAC authentication using When the BAC authentication fails, the TOE returns state word which indicating BAC authentication failure, and increases its response delay by 0.1 seconds. The response delay can be increased up to 3 seconds, and if the consecutive authentication failure exceeds 30 times, the TOE still returns 3 seconds delayed response. Once BAC authentication success, the accumulated counter is initialized by 0. BAC authentication failure doesn’t cause any security reset or card killing mechanism.   FDP_ACC.1 Subset access control The TSF implements the basic access control, applying the rules and operations over objects defined in FDP_ACF.1   FDP_ACF.1 Basic Security attribute based access control The TSF implements all objects, subjects, rules and operations defined in this SFR as specified in [BAC-PP] subsection 6.1.4.2   FDP_UCT.1 Basic data exchange confidentiality The TSF implements Basic Access Control mechanism according to [ICAO 9303], which enforces MAC_ENC mode to protect user data from unauthorised disclosure.   FDP_UIT.1 Data exchange integrity The TSF implements Basic Access Control mechanism according to [ICAO 9303], which enforces MAC_ENC mode to protect user data from modification, deletion, insertion and replay errors. Also The TOE does not process a received command if it detects that modification, deletion, insertion or replay has occurred on the command by verifying MAC and by checking presence of essential tags of secure messaging.   FMT_SMF.1 Specification of Management Functions The TOE requires Transport Key authentication to initializes (activate) itself. The TOE provides functionality to write Personalization Agent keys (Pre-personalization) after default Personalization Agent keys have been authenticated. After Personalization Agent key authentication, the TOE allows to write user data using UPDATE BINARY commands (Personalization).   FMT_SMR.1 Security roles The TSF defines roles of Personalization Agent, Basic Inspection System as specified in [BAC-PP] and associates users with each of those roles. The TSF associates a user with role of Personalization Agent, Basic Inspection System by authenticating following keys.  Manufacturer: None.  Personalization Agent: Personalization Agents keys.  Basic Inspection System: Document Basic Access keys. Manufacturer does not have to be authenticated by key because it does not deal with any sensitive user data. Also the TOE is protected by Transport key before being delivered to Personalization Agent.   FMT_LIM.1 Limited capabilities The TSF provides limited capabilities through LDS system and security code. KONA2 D2320N ePassport BAC Security Target Lite 34 The TSF does not have test features after TOE Delivery.   FMT_LIM.2 Limited availability The TSF provides limited capabilities through LDS system and security code. The TSF does not have test features after TOE Delivery.   FMT_MTD.1/INI_ENA Management of TSF data When TOE is delivered from MRTD manufacturer to Personalization Agent, it is protected by Transport Key.   FMT_MTD.1/INI_DIS Management of TSF data Personalization Agent is able to transfer card life-cycle state from INITIALISATION state to OPERATION state by sending SET LIFECYCLE command.   FMT_MTD.1/KEY_WRITE Management of TSF data During INITIALISATION state, the Document Basic Access Keys are written by a Personalization Agent using UPDATE BINARY command. After completion of personalization, the TOE does not support functionality to write the Document Basic Access keys again.   FMT_MTD.1/KEY_READ Management of TSF data The TSF does not provide functionality to read Personalization Agent keys to anyone in any life-cycle states because it is not possible to read the files that stores the keys.   FPT_EMSEC.1 TOE Emanation The IC is designed to avoid disclosing of private date by means of electromagnetic emanations. Moreover the OS provides measures to balance conditions and variables in critical operations generating same consumption that it is reflected in electromagnetic emanations. Moreover the OS introduces noise when critical data is handled.   FPT_FLS.1 Failure with preservation of secure state When the TOE is exposed to out-of-range operating conditions such as extreme temperature, intensive light or abnormal voltage etc., the IC triggers sensor reset and the TSF increases a security counter. When the security counter reaches a specific number, the TOE destroys itself. If the TSF detects that one of the self-test fails, it responses a status word to inform which self-test has been failed and reset itself.   FPT_TST.1 TSF testing Verification of TSF executable code integrity stored in NVM is done by IC manufacturer during FLASH masking process. Also IC triggers sensor reset automatically when it detects parity error. The TSF executes self-test (DES, RSA, CRC) of crypto co-processor once after each start-up. Also Random Number Generator is tested (1) each time random numbers are generated before using it, (2) after cryptographic operations are done.   FPT_PHP.3 Resistance to physical attack The IC chip has several security detector that detect whether some abnormal condition occur. KONA2 D2320N ePassport BAC Security Target Lite 35  Voltage detector  Frequency detector  Active Shield Removal Detector  Light and laser detector  Temperature detector  Voltage Glitch detector KONA2 D2320N ePassport BAC Security Target Lite 36 9. Acronyms BIS Basic Inspection System CC Common Criteria EAL Evaluation Assurance Level EF Elementary File EIS Extended Inspection System GIS General Inspection System ICAO International Civil Aviation Organization IT Information Technology MRTD Machine Readable Travel Document OSP Organizational security policy PP Protection Profile RNG Random Number Generator SAR Security assurance requirements SFP Security Function Policy SFR Security functional requirement ST Security Target TOE Target of evaluation TSF TOE Security Functions PA Passive Authentication AA Active Authentication BAC Basic Access Control PACE Password Authenticated Connection Establishment CAN Card Access Number SOD Security object Data MRZ Machine readable Zone KONA2 D2320N ePassport BAC Security Target Lite 37 10. Bibliography [BAC-PP] Common Criteria Protection Profile Machine Readable Travel Document with "ICAO Application”, Basic Access Control, Version 1.10, 25th March 2009, BSI-CC-PP-0055 [ICAO 9303] Doc Series, ICAO Doc 9303, Machine Readable Travel Documents, seventh Edition, 2015 [ICPP] Euro smart Security IC Platform Protection Profile with Augmentation Packages, version 1.0, BSI-CC-PP-0084-2014 [STIC] S3FT9MH/ S3FT9MV/ S3FT9MG 16-bit RISC Microcontroller for Smart Card with optional specific IC Dedicated Software Version 3.2 27th March 2017 [GDOM] Security Application Note for S3FT9MD/MC,MF/MT/MS,MH/MK/MG Version 1.9 09th June 2015 [AIS31] A proposal for: Functionality classes and evaluation methodology for true (physical) random number generators version 3.1 25.09.2001 [FIPS 180- 4] Federal Information Processing Standards Publication 180-4 SECURE HASH STANDARD, U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, 2015 August [DES] 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 Technology [AGD_OPE] KONA2 D2320N ePassport Operational Guidance, Version 1.16 [AGD_PRE] KONA2 D2320N ePassport Preparative Procedure Guidance, Version 1.16 [ALC_DEL] KONA2 D2320N ePassport Delivery Procedure, Version 1.14 End of Document