Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) Compliant to EU-Residence Permit Specification V 1.0 BSI-CC-PP-0069 Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 2 of 133 Foreword This Protection Profile ‘Electronic Residence Permit Card (RP_Card PP)’ is issued by Bundesamt für Sicherheit in der Informationstechnik, Germany. The document has been prepared as a Protection Profile (PP) following the rules and formats of Common Criteria version 3.1 [1], [2], [3], Revision 3. Correspondence and comments to this Protection Profile should be referred to: Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 D-53133 Bonn, Germany Phone: +49 228 99 9582-0 Fax: +49 228 99 9582-400 Email: bsi@bsi.bund.de Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 3 of 133 Contents 1 PP Introduction 7 1.1 PP reference 7 1.2 TOE Overview 7 1.2.1 TOE definition and operational usage 7 1.2.2 TOE major security features for operational use 9 1.2.3 TOE type 9 1.2.4 Non-TOE hardware/software/firmware 9 2 Conformance Claims 14 2.1 CC Conformance Claim 14 2.2 PP Claim 14 2.3 Package Claim 15 2.4 Conformance Claim Rationale 15 2.4.1 ‘Protection Profile Machine Readable Travel Document with „ICAO Application", Extended Access Control’ 15 2.4.2 ‘Protection Profile Electronic Passport using Standard Inspection Procedure with PACE’ 17 2.4.3 ‘Protection Profiles for Secure Signature Creation Device – Part 2: Device with key generation’18 2.5 Conformance statement 19 3 Security Problem Definition 20 3.1 Introduction 20 3.2 Threats 30 3.3 Organisational Security Policies 34 3.4 Assumptions 39 4 Security Objectives 41 4.1 Security Objectives for the TOE 41 4.2 Security Objectives for Operational Environment 46 4.3 Security Objective Rationale 53 5 Extended Components Definition 57 5.1 Definition of the Family FAU_SAS 57 5.2 Definition of the Family FCS_RND 57 5.3 Definition of the Family FIA_API 58 5.4 Definition of the Family FMT_LIM 59 5.5 Definition of the Family FPT_EMSEC 61 6 Security Requirements 63 6.1 Security Functional Requirements for the TOE 63 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 4 of 133 Bundesamt für Sicherheit in der Informationstechnik 6.1.1 Overview 63 6.1.2 Class FCS Cryptographic Support 69 6.1.3 Class FIA Identification and Authentication 76 6.1.4 Class FDP User Data Protection 86 6.1.5 Class FTP Trusted Path/Channels 91 6.1.6 Class FAU Security Audit 93 6.1.7 Class FMT Security Management 94 6.1.8 Class FPT Protection of the Security Functions 106 6.2 Security Assurance Requirements for the TOE 110 6.3 Security Requirements Rationale 110 6.3.1 Security Functional Requirements Rationale 110 6.3.2 Rationale for SFR’s Dependencies 116 6.3.3 Security Assurance Requirements Rationale 116 6.3.4 Security Requirements – Internal Consistency 117 7 Glossary and Acronyms 119 8 Bibliography 132 List of Tables Table 1: RP_Card applications vs. terminal types.................................................................................13 Table 2: Primary assets..........................................................................................................................21 Table 3: Secondary assets......................................................................................................................23 Table 4: Subjects and external entities...................................................................................................29 Table 5: Threats taken over from [6].....................................................................................................33 Table 6: Threats taken over from [7].....................................................................................................33 Table 7: Threats taken over from [8].....................................................................................................34 Table 8: OSPs taken over from [6] ........................................................................................................38 Table 9: OSPs taken over from [7] ........................................................................................................38 Table 10: OSPs taken over from [8] ......................................................................................................39 Table 11: Assumptions taken over from [6] ..........................................................................................40 Table 12: Assumptions taken over from [8] ..........................................................................................40 Table 13: TOE objectives taken over from [6] ......................................................................................45 Table 14: TOE objectives taken over from [7] ......................................................................................45 Table 15: TOE objectives taken over from [8] ......................................................................................46 Table 16: TOE’s environment objectives taken over from [6]..............................................................51 Table 17: TOE’s environment objectives taken over from [7]..............................................................51 Table 18: TOE’s environment objectives taken over from [8]..............................................................52 Common Criteria Protection Profile Version Electronic Residence Permit Card (RP_Card PP) 1.00, 13th August 2010 BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 5 of 133 Table 19: TOE’s environment objectives effectively resulting from the conformance claims made (a digest of Table 16, Table 17, Table 18) ..........................................................................................53 Table 20: Security Objective Rationale.................................................................................................54 Table 21: Security functional groups vs. SFRs......................................................................................66 Table 22: Keys and Certificates.............................................................................................................68 Table 23: Overview of authentication SFRs..........................................................................................76 Table 24: Coverage of Security Objectives for the TOE by SFR........................................................112 Table 25: SAR Dependencies..............................................................................................................117 Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 7 of 133 1 PP Introduction 1 This section provides document management and overview information required to register the protection profile and to enable a potential user of the PP to determine, whether the PP is of interest. 1.1 PP reference 2 Title: Protection Profile ‘Electronic Residence Permit Card (RP_Card PP)’ Sponsor: Bundesamt für Sicherheit in der Informationstechnik Editor(s): Dr. Igor Furgel T-Systems GEI GmbH, SC Security Analysis & Testing CC Version: 3.1 (Revision 3) Assurance Level: Minimum assurance level for this PP is EAL4 augmented. General Status: final Version Number: 1.00 as of 13th August 2010 Registration: BSI-CC-PP-0069 Keywords: Electronic Residence Permit Card, RP_Card, ePassport, eID, eSign, MRTD, PACE, EAC, BAC 1.2 TOE Overview 1.2.1 TOE definition and operational usage 3 The Target of Evaluation (TOE) addressed by the current protection profile is an electronic Residence Permit Card (RP_Card) representing a contactless smart card programmed according to BSI TR-03110, version 2.03 [12] and being compliant to EU – Residence permit Specification [16]. This smart card provides the following applications: – the ePassport1 containing the related user data2 (incl. biometric) as well as data needed for authentication (incl. MRZ); this application is intended to be used by authorities, amongst other as a machine readable travel document (MRTD); – the eID3 including the related user data4 and data needed for authentication; this application is intended to be used for accessing official and commercial services, which require access to the user data stored in the context of this application; – the eSign5 containing data needed for generating qualified electronic signatures on behalf of the RP_Card holder as well as for authentication; this application is intended to be used in the context of official and commercial services, where a qualified electronic signature of the RP_Card holder 1 as specified in [12], sec. 3.1.1; see also [9], [10]. 2 according to [12], sec. 1.1 and 3.1.1; see also chap. 7 below for definitions 3 as specified in [12], sec. 3.1.2 4 according to [12], sec. 3.1.2 5 as specified in [12], sec. 3.1.3 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 8 of 133 Bundesamt für Sicherheit in der Informationstechnik is required. The eSign application is optional: it means that it can optionally be activated on the RP_Card by a Certification Service Provider (or on his behalf). 4 For the ePassport application, the RP_Card holder can control access to his user data by conscious presenting his RP_Card to authorities6. 5 For the eID application, the RP_Card holder can control access to his user data by inputting his secret PIN (eID-PIN) or by conscious presenting his RP_Card to authorities7. 6 For the eSign application, the RP_Card holder can control access to the electronic signature functionality by conscious presenting his RP_Card to a service provider and inputting his secret PIN for this application: eSign-PIN8. 7 Application note 1: In principle, it might technically be possible to grant access to the electronic signature functionality by inputting CAN only (see [12], sec. 3.3); however, this technical option shall not be allowed by the security policy defined for the eSign application (see the related conformance claim in sec. 2.2 below) due to the fact that solely the Signatory (here: the RP_Card holder) shall be able to generate an electronic signature on his own behalf. 8 Application note 2: Using a secret PIN by the PIN’s owner represents a manifestation of his declaration of intent bound to this secret PIN. In order to reflect this fact, the eID and the eSign applications shall organisationally get different values of the respective secret PINs (eID-PIN and eSign-PIN). It is especially important, if qualified electronic signatures shall be generated by the eSign application. 9 The RP_Card is integrated into a plastic, optically readable part of the Residence Permit Card, which – as the final product – shall supersede the existing, merely optically readable Residence Permit labels. The plastic, optically readable cover of the Residence Permit Card, where the electronic Residence Permit Card is embedded in, is not part of the TOE. The tying-up of the electronic Residence Permit Card to the plastic Residence Permit Card is achieved by physical and organisational security measures being out of the scope of the current PP. 10 The TOE shall comprise at least i) the circuitry of the contactless chip incl. all IC dedicated software9 being active in the operational phase of the TOE (the integrated circuit, IC), ii) the IC Embedded Software (operating system)10, iii) the ePassport, the eID and, optionally11, the eSign applications and iv) the associated guidance documentation. 11 Application note 3: Since contactless interface parts (e.g. antenna) may have impact on specific aspects of vulnerability assessment and, thus, be security relevant, these parts might be 6 CAN or MRZ user authentication, see [12], sec. 3.3 7 eID-PIN or CAN user authentication, see [12], sec. 3.3 8 CAN and eSign-PIN user authentication, see [12], sec. 3.3 9 usually preloaded (and often security certified) by the Chip Manufacturer 10 usually – together with IC – completely implementing executable functions 11 it means activated or not activated on the RP_Card Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 9 of 133 considered as part of the TOE. The decision upon this is up to the certification body in charge by defining the evaluation methodology for the assessment of the contactless interface. 1.2.2 TOE major security features for operational use 12 The following TOE security features are the most significant for its operational use: – Only authenticated terminals can get access to the user data stored on the TOE and use the security functionality of the RP_Card under the control of the RP_Card holder, – Verifying authenticity and integrity as well as securing confidentiality of user data12 in the communication channel between the TOE and the service provider connected13, – Creation of electronic signatures, if the eSign application is operational, – Averting of inconspicuous tracing of the RP_Card, – Self-protection of the TOE security functionality and the data stored inside. 1.2.3 TOE type 13 The TOE type is contactless smart card with the ePassport, the eID and the eSign applications named as a whole ‘electronic Residence Permit Card (RP_Card)’. 14 The typical life cycle phases for the current TOE type are development14, manufacturing15, card issuing16 and, finally, operational use. Operational use of the TOE is explicitly in the focus of current PP. Some single properties of the manufacturing and the card issuing life cycle phases being significant for the security of the TOE in its operational phase are also considered by the current PP. A security evaluation/certification being conform with this PP will have to involve all life cycle phases into consideration to the extent as required by the assurance package chosen here for the TOE (see chap. 2.3 ‘Package Claim’ below). 1.2.4 Non-TOE hardware/software/firmware 15 In order to be powered up and to communicate with the ‘external world’ the TOE needs a terminal (card reader) supporting the contactless communication according to [22]. 16 From the logical point of view, the TOE shall be able to distinguish between the following terminal types, which, hence, shall be available (see [12], sec. 3.2): 12 please note that user data might also be imported from outside of the TOE, e.g. data to be signed or a repre- sentation thereof by the eSign application 13 a service provider can technically be represented by a local RF-terminal as the end point of secure communication in the sense of this PP (local authentication) or by a remote terminal as the end point of secure communication in the sense of this PP (online authentication) 14 IC itself and IC embedded software 15 IC manufacturing and smart card manufacturing including installation of a native card operating system 16 including installation of the smart card applications and their electronic personalisation (i.e. tying the application data up to the RP_Card holder) Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 10 of 133 Bundesamt für Sicherheit in der Informationstechnik – Inspection System17: an official terminal that is always operated by a governmental organisation (i.e. an Official Domestic or Foreign Document Verifier), – Authentication terminal: a terminal that may be operated by a governmental organisation (Official Domestic Document Verifier) or by any other organisation (Non-Official / Foreign Document Verifier), and – Signature terminal: a terminal used by RP_Card holder for the generation of electronic signatures. 17 The TOE shall require the terminal of each type to authenticate itself before access according to effective terminal authorisation is granted. To authenticate a terminal either as an inspection system or authentication terminal or signature terminal as stated above, the related Inspection or Authentication Procedures must be used. 18 Application note 4: The specification [12], sec. 3.2.1 in conjunction with sec. 3.1.1 knows the following types of inspection systems: – BIS-PACE: Basic Inspection System18 with PACE19, – BIS-BAC: Basic Inspection System with BAC20, – EIS-AIP-PACE: Extended Inspection System using Advanced Inspection Procedure with PACE21, – EIS-AIP-BAC: Extended Inspection System using Advanced Inspection Procedure with BAC22, – EIS-GAP: Extended Inspection System using General Authentication Procedure23, The current PP defines security policy for the usage of EIS-GAP, BIS-PACE (due to compliance with [7], see sec. 2.2) and EIS-AIP-BAC (due to compliance with [16] and, hence, with [6], see sec. 2.2) types of inspection systems as well as of authentication and signature terminals unconditionally using General Authentication Procedure. GAP is essentially in the scope of the current PP. It is due to the fact that GAP offers the most functionality according to [12] and the most extended protection of assets in the sense of the current PP. Using other types of inspection systems (BIS-BAC and EIS-AIP-PACE) is out of the scope of the current PP. BIS-BAC and EIS-AIP-PACE24 may functionally be supported by an RP_Card, but is not part of the TOE in the context of the current PP. The current PP has to be compliant to EU – Residence permit Specification [16] by claiming a 17 see the Application note 4 in § 18 for further details 18 a Basic Inspection Systems (BIS) always uses Standard Inspection Procedure (SIP). 19 SIP with PACE means: PACE and passive authentication with SOD according to [12], sec. 4.2, 1.1, G.1 and G.2. 20 SIP with BAC means: BAC and passive authentication with SOD according to [12], sec. H, 1.1, G.1 and G.2. It is commensurate with BIS in [5] and [6]; i.e. the terminal proven the possession of MRZ optically read out from the plastic part of the card. 21 Advanced Inspection Procedure (AIP) with PACE means: PACE, chip authentication, passive authentication with SOD and terminal authentication according to [12], sec. 4.2, 4.3 (version 1), 1.1, 4.4 (version 1), G.1 and G.3. 22 AIP with BAC means: BAC, chip authentication, passive authentication with SOD and terminal authentication according to [12], sec. H, 4.3 (version 1), 1.1, 4.4 (version 1), G.1 and G.3. It is commensurate with EIS in [5] and [6]; please note that this EIS also covers the General Inspection Systems (GIS) in the sense of [5] and [6]. 23 General Authentication Procedure (GAP) means: PACE, terminal authentication (version 2), passive authentication with SOC and chip authentication (version 2) according to [12], sec. 4.2, 4.3 and 4.4. 24 EIS-AIP-PACE simultaneously represents a feasible/sensible option for a future dedicated PP Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 11 of 133 formal conformance to [6], cf. [16], sec. 6.3 what induces supporting EIS-AIP-BAC for the ePassport application. Since the security properties of BAC protocol25 cannot withstand some attack scenarios with a high attack potential, the related threats26 are considered either not to be allied with using EIS-AIP-BAC or to be confined to only selected data groups within the ePassport application27 when using EIS-AIP-BAC. Therefore, organisations being responsible for the operation of inspection systems (CVCAs and DVs) shall be aware of this context. 19 Application note 5: A [12]-compliant terminal28 shall always start a communication session using PACE. If successfully, it shall then try to proceed with terminal- and chip-authentications as required by GAP in [12]. The terminal will be authorised (depending on its certificate) as the EIS-GAP in the sense of [12]. If the trial with PACE and GAP failed, the [12]-compliant terminal may try to establish a communication session using other valid options as described above. 20 Application note 6: After the General Authentication Procedure has successfully been performed, the authenticated terminal can request for a sector-specific chip-identifier (Restricted Identification, see sec. 2.1.5, 2.4, 4.5 of [12]). Restricted Identification aims providing a temporary RP_Card identifier being specific for a terminal sector (pseudo-anonymisation) and supporting revocation features (sec. 2.4, 4.1.1.1 of [12]). The security status of RP_Card is not affected by Restricted Identification. 21 Application note 7: Concerning terminals for the eSign application, the parallels with the terminals as defined in [8] are as follows: the Authentication Terminal in the context of [12] (and of the current PP) is CGA29 in [8]; the Signature Terminal in the context of [12] represents a combination of SCA30 and HID31 in [8]. 22 The authorisation level of an authenticated terminal shall be determined by the effective terminal authorisation calculated from the certificate chain presented by this terminal to the TOE32. All necessary certificates of the related public key infrastructure – Country Verifying Certification Authority (CVCA) Link Certificates, Document Verifiers Certificates and Terminal Certificates – shall be available in a card verifiable format as specified in [12], Appendix C.1; see also [12], sec. 2.2.3. 23 The following table gives an overview which types of terminals shall be supported for which single application of the TOE, see [12], sec. 3.1 – 3.4 (please note that the effective ability of a terminal depends on its terminal authorisation level finally derived from the presented certificate chain as stated above): 25 see [12], appendix H 26 see sec. 3.2 for further details 27 DG3, DG4, cf. [12], sec. 1.1. 28 see appendix G of [12] for further details 29 Certification Generation Application 30 Signature Creation Application 31 Human Interface Device 32 It is based on Certificate Holder Authorization Template (CHAT), see [12], C.1.5. A CHAT is calculated as an AND-operation from the certificate chain of the terminal and the RP_Card holder’s restricting input at the terminal. This final CHAT reflects the effective authorisation level, see [12], sec. 2.3 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3 und B.11.1 of [12]). Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 12 of 133 Bundesamt für Sicherheit in der Informationstechnik Basic Inspection System using SIP with PACE (BIS-PACE, official terminal) Extended Inspection System using AIP with BAC (EIS-AIP-B AC, official terminal) Extended Inspection System using GAP (EIS-GAP, official terminal) Authentication Terminal (official or commercial terminal) Signature Terminal ePassport Operations: reading all data groups excepting DG3 and DG4 User interaction: CAN or MRZ for PACE Operations: reading only DG3 and DG4 and optional DG5- DG1333 User interaction: MRZ for BAC Operations: reading all data groups (incl. biometrical) User interaction: CAN or MRZ for PACE - - eID - - Operations: reading all data groups User interaction: CAN for PACE Operations: writing a subset of data groups; reading all or a subset of data groups User interaction: eID-PIN or eID-PUK or CAN34 for PACE - eSign - - - Operations: activating eSign application User interaction: eID-PIN or eID-PUK or CAN34 for PACE Operations: generating qualified electronic signatures User interaction: CAN for PACE, then eSign-PIN for access to 33 cf. table 1.2 in sec. 1.1 of [12]. 34 if the terminal indicates such required authorisation with PACE (an official terminal), see sec. 2.3 in [12] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 13 of 133 Basic Inspection System using SIP with PACE (BIS-PACE, official terminal) Extended Inspection System using AIP with BAC (EIS-AIP-B AC, official terminal) Extended Inspection System using GAP (EIS-GAP, official terminal) Authentication Terminal (official or commercial terminal) Signature Terminal In the eSign context, the current terminal is equivalent to CGA in [8] the signature function In the eSign context, the current terminal is equivalent – as a general term – to SCA and HID in [8] Table 1: RP_Card applications vs. terminal types Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 14 of 133 Bundesamt für Sicherheit in der Informationstechnik 2 Conformance Claims 2.1 CC Conformance Claim 24 This protection profile claims conformance to – Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; CCMB-2009-07-001, Version 3.1, Revision 3, July 2009 [1] – Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components; CCMB-2009-07-002, Version 3.1, Revision 3, July 2009 [2] – Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements; CCMB-2009-07-003, Version 3.1, Revision 3, July 2009 [3] as follows - Part 2 extended, - Part 3 conformant. 25 The – Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; CCMB-2009-07-004, Version 3.1, Revision 3, July 2009, [4] has to be taken into account. 2.2 PP Claim 26 This PP claims strict conformance to ‘Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Extended Access Control, BSI-CC-PP-0056-2009, version 1.10, 25th March 2009’ [6]. 27 Application note 8: The conformance claim above covers the part of the security policy for the ePassport application of the TOE corresponding to the security policy defined in [6]. This conformance claim is a requirement of [16], sec. 6.3 and, in such a way, enforces including the EIS-AIP-BAC type of inspection system in the current PP. Since [6] (see sec. 2.2 and P.BAC-PP there) requires the TOE to fulfill the ‘Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Basic Access Control, BSI-CC-PP-0055-2009, version 1.10, 25th March 2009’ [5] as a premise to the protection profile [6], the conformance claim above ‘conveys’ this requirement into the current PP, i.e. the TOE has also to successfully be evaluated and certified in accordance with [5]. 28 This PP claims strict conformance to ‘Common Criteria Protection Profile Electronic Passport using Standard Inspection Procedure with PACE, BSI-CC-PP-0068-2010, version 0.92, 30th April 2010’ [7]. 29 Application note 9: The conformance claim above covers the part of the security policy for the ePassport application of the TOE corresponding to the security policy defined in [7]. This conformance claim enforces including the BIS-PACE type of inspection system in the current PP. 30 This PP claims strict conformance to ‘Protection Profiles for Secure Signature Creation Device – Part 2: Device with key generation, EN 14169-1:2009, ver. 1.03, 2009-12, BSI-CC-PP-0059- 2009’ [8]. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 15 of 133 31 Application note 10: The last conformance claim covers the part of the security policy for the eSign application of the TOE corresponding to the security policy defined in [8] and, hence, is applicable, if the eSign application is operational. In addition to [8], the current PP specifies authentication and communication protocols (GAP) having to be used for the eSign application of the TOE. These protocols contribute to securing SVD-export, DTBS-import and VAD-import functionality. 32 Application note 11: The eSign application of the TOE is intended to generate qualified electronic signatures. The main specific property distinguishing qualified electronic signatures from advanced is that they base on qualified certificates35 and are created by secure signature creation devices (SSCD). Since the current TOE (its part the eSign application) shall be used as SSCD due to the PP conformance claim above, the only specific difference remained is using qualified certificates for qualified signatures. Whether a certificate is qualified or not is a pure organisational issue from the point of view of the TOE which does not impact the TOE functionality. Therefore, the PP conformance claim above covers not only qualified signatures, but can also do this for advanced signatures under an appropriate interpretation of the organisational security policies P.CSP_QCert and P.QSign in [8]. 2.3 Package Claim 33 The current PP is conformant to the following security requirements package: – Assurance package EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 as defined in the CC, part 3 [3]. 2.4 Conformance Claim Rationale 34 Application note 12: The current PP claims strict conformance to the following protection profiles as required there: ICAO-EAC PP (sec. 2.5 in [6]), PACE-Pass PP (sec. 2.5 in [7]) and SSCD Core PP (sec. 6.4 in [8]). Due to this fact, it is sensible to distinguish between separated sets of {TOE type, SPD statement, security objectives statement, security requirements statement} for each application residing in the TOE: ePassport, eID and eSign, respectively36, unless the items are identical or hierarchical as in the case of the SARs. The author of the current PP will mark item’s belonging to each TOE’s application off. 2.4.1 ‘Protection Profile Machine Readable Travel Document with „ICAO Application", Extended Access Control’ TOE Type 35 The PP [6] does not explicitly state any TOE type, but it can be inferred from the TOE definition in sec. 1.2 there: ‘… (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 and Extended Access Control according to the ‘ICAO Doc 9303’ … and BSI TR-03110…’. 35 being valid at signature creation time 36 see Application notes in sec. 2.2 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 16 of 133 Bundesamt für Sicherheit in der Informationstechnik 36 This TOE type is obviously commensurate with the current TOE type in the part being provided by the ePassport application, see sec. 1.2.1 and 1.2.3 above. SPD Statement 37 The security problem definition (SPD) of the current PP contains the security problem definition of the PP [6]. The current SPD includes the same threats, organisational security policies and assumptions as for the TOE in [6] and comprehends several additional items as stated in chap. 3 below. 38 Application note 13: Strict conformance presumes that assumptions of the current PP shall be identical to the assumptions of each PP to which the conformance is being claimed. As explained in the Application note 12 above, the assumptions for the current PP might consist of three blocks: assumptions for the ePassport, for the eID and assumptions for the eSign application. In this context and due to the current state of the art of writing PPs/STs, all assumptions from [6] are completely covered by the OSP block for the ePassport application and by the assurance package chosen within the current PP; see sec. 3.4 for further details. Security Objectives Statement 39 The security objectives statement for the TOE in the current PP includes all the security objectives for the TOE of the PP [6] and comprehends several additional items as stated in chap. 4.1 below. 40 The security objectives statement for the TOE’s operational environment in the current PP includes all security objectives for the operational environment of the PP [6] and comprehends several additional items as stated in chap. 4.2 below. 41 Application note 14: Strict conformance presumes that the security objectives for the operational environment of the current PP shall be identical to those items of each PP to which the conformance is being claimed (unless a re-assignment according to [1], sec. 9.3). As explained in the Application note 12 above, the security objectives for the operational environment for the current PP might consist of three blocks: objectives for the ePassport, for the eID and objectives for the eSign application. In this context, the current block of environmental objectives for the ePassport application completely covers the respective objectives from [6]. Security Requirements Statement 42 The PP [6] conforms to CC v3.1, revision 2, the current PP – to CC v3.1, revision 3. In respect to this, it is to rely on the statement of CCMB that respective assurance levels achieved by applying different CC revisions are equivalent to each other. 43 The SFR statement for the TOE in the current PP includes all the SFRs for the TOE of the PP [6] and comprehends several additional items as stated in chap. 6.1 below. 44 The SAR statement for the TOE in the current PP includes all the SARs for the TOE of the PP [6] as stated in chap. 6.2 below. 45 Application note 15: Strict conformance allows that the security requirements for the TOE of the current PP may be hierarchically stronger than those items of each PP to which the conformance is being claimed. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 17 of 133 2.4.2 ‘Protection Profile Electronic Passport using Standard Inspection Procedure with PACE’ TOE Type 46 The TOE type stated in [7], sec. 1.2.3 is ‘…contactless smart card with the ePassport application named as a whole ‘electronic Passport (ePass)’’. 47 This TOE type is obviously commensurate with the current TOE type in the part being provided by the ePassport application, see sec. 1.2.1 and 1.2.3 above. SPD Statement 48 The security problem definition (SPD) of the current PP contains the security problem definition of the PP [7]. The current SPD includes the same threats, organisational security policies and assumptions as for the TOE in [7] and comprehends several additional items as stated in chap. 3 below. 49 Application note 16: Strict conformance presumes that assumptions of the current PP shall be identical to the assumptions of each PP to which the conformance is being claimed. As explained in the Application note 12 above, the assumptions for the current PP might consist of three blocks: assumptions for the ePassport, for the eID and assumptions for the eSign application. In this context, the current assumptions block for the ePassport application is identical to the assumptions from [7] (there is no assumption for the ePassport application). Security Objectives Statement 50 The security objectives statement for the TOE in the current PP includes all the security objectives for the TOE of the PP [7] and comprehends several additional items as stated in chap. 4.1 below. 51 The security objectives statement for the TOE’s operational environment in the current PP includes all security objectives for the operational environment of the PP [7] and comprehends several additional items as stated in chap. 4.2 below. 52 Application note 17: Strict conformance presumes that the security objectives for the operational environment of the current PP shall be identical to those items of each PP to which the conformance is being claimed (unless a re-assignment according to [1], sec. 9.3). As explained in the Application note 12 above, the security objectives for the operational environment for the current PP might consist of three blocks: objectives for the ePassport, for the eID and objectives for the eSign application. In this context, the current block of environmental objectives for the ePassport application is identical to the equivalent objectives from [7]. Security Requirements Statement 53 The SFR statement for the TOE in the current PP includes all the SFRs for the TOE of the PP [7] and comprehends several additional items as stated in chap. 6.1 below. 54 The SAR statement for the TOE in the current PP includes all the SARs for the TOE of the PP [7] as stated in chap. 6.2 below. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 18 of 133 Bundesamt für Sicherheit in der Informationstechnik 55 Application note 18: Strict conformance allows that the security requirements for the TOE of the current PP may be hierarchically stronger than those items of each PP to which the conformance is being claimed. 2.4.3 ‘Protection Profiles for Secure Signature Creation Device – Part 2: Device with key generation’ TOE Type 56 The TOE type stated in [8], sec. 5.4.2 is ‘… a combination of hardware and software configured to securely create, use and manage signature-creation data (SCD). The SSCD protects the SCD during its whole life cycle as to be used in a signature-creation process solely by its signatory’. 57 This TOE type is obviously commensurate with the current TOE type in the part being provided by the eSign application, see sec. 1.2.1 and 1.2.3 above. SPD Statement 58 The security problem definition (SPD) of the current PP contains the security problem definition of the PP [8]. The current SPD includes the same threats, organisational security policies and assumptions as for the TOE in [8] and comprehends several additional items as stated in chap. 3 below. 59 Application note 19: Strict conformance presumes that assumptions of the current PP shall be identical to the assumptions of each PP to which the conformance is being claimed. As explained in the Application note 12 above, the assumptions for the current PP might consist of three blocks: assumptions for the ePassport, for the eID and assumptions for the eSign application. In this context, the current assumptions block for the eSign application is identical to the assumptions from [8]. Security Objectives Statement 60 The security objectives statement for the TOE in the current PP includes all the security objectives for the TOE of the PP [8] and comprehends several additional items as stated in chap. 4.1 below. 61 The security objectives statement for the TOE’s operational environment in the current PP includes all security objectives for the operational environment of the PP [8] and comprehends several additional items as stated in chap. 4.2 below. 62 Application note 20: Strict conformance presumes that the security objectives for the operational environment of the current PP shall be identical to those items of each PP to which the conformance is being claimed (unless a re-assignment according to [1], sec. 9.3). As explained in the Application note 12 above, the security objectives for the operational environment for the current PP might consist of three blocks: objectives for the ePassport, for the eID and objectives for the eSign application. In this context, the current block of environmental objectives for the eSign application is identical to the equivalent objectives from [8]. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 19 of 133 Security Requirements Statement 63 The SFR statement for the TOE in the current PP includes all the SFRs for the TOE of the PP [8] and comprehends several additional items as stated in chap. 6.1 below. 64 The SAR statement for the TOE in the current PP includes all the SARs for the TOE of the PP [8] as stated in chap. 6.2 below. The current assurance package contains the assurance components ALC_DVS.2 and ATE_DPT.2 being hierarchical to ALC_DVS.1 respectively ATE_DPT.1 as required by [8]. 65 Application note 21: Strict conformance allows that the security requirements for the TOE of the current PP may be hierarchically stronger than those items of each PP to which the conformance is being claimed. 2.5 Conformance statement 66 This PP requires strict conformance of any ST or PP claiming conformance to this PP. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 20 of 133 Bundesamt für Sicherheit in der Informationstechnik 3 Security Problem Definition 67 Application note 22: Since the current PP covers three different applications – ePassport, eID and eSign –, the author decided to trace the belonging of each formal item within the set of {SPD statement, security objectives statement, security requirements statement} to the respective application; cf. also the Application note 12 in sec. 2.4 above. 3.1 Introduction Assets 68 The primary assets to be protected by the TOE as long as they are in scope of the TOE are (please refer to the glossary in chap. 7 for the term definitions) Object No. Asset Definition Generic security property to be maintained by the current security policy ePassport, eID, eSign 1 user data stored on the TOE All data (being not authentication data) stored in the context of the applications of the RP_Card as defined in [12] and (i) being allowed to be read out Confidentiality39 Integrity Authenticity cation according to [12], sec. 4.5 represents just a functionality of the RP_Card, e 38 c 37 Since the Restricted Identifi the key material needed for this functionality and stored in the TOE is treated here as User Data in the sens of the CC. orresponds to SCD in [8] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 21 of 133 Object No. Asset Definition Generic security property to be maintained by the current security policy or written solely by an authenticated terminal (in the sense of [12], sec. 3.2) f [12], ivate , data stored on the TOE’ ’ respectively (ii) being allowed to be used solely by an authenticated terminal (in the sense o sec. 3.2) (the private Restricted Identification key37) respectively (iii) being allowed to be used solely by the authenticated RP_Card holder (the pr signature key within the eSign application38). This asset covers ‘User Data on the MRTD’s chip’ and ‘Logical MRTD sensitive User Data’ in [6] ‘user (object #1) in [7] as well as ‘SCD and ‘DTBS/R’ in [8]. 2 user data transferred between the TOE and the service provider connected40 ication the nt This asset covers ‘user data transferred between the TOE and [8]. Confidentiality41 Integrity Authenticity All data (being not authent data) being transferred in the context of the applications of RP_Card as defined in [12] between the TOE and an authenticated terminal (in the sense of [12], sec. 3.2). User data can be received and se (exchange  {receive, send}). the service provider connected (i.e. an authority represented by Basic Inspection System with PACE)’ (object #2) in [7] and ‘DTBS’ in 3 RP_Card tracing Technical information about the unavailability42 39 Though not each data element stored on the TOE represents a secret, the specification [12] anyway requires securing their confidentiality: only terminals authenticated either using GAP or as EIS-AIP-BAC or as BIS- PACE according to [12] can get access to the user data stored. 40 for the ePassport application, the service provider is always an authority represented by a local RF-terminal 41 Though not each data element being transferred represents a secret, the specification [12] anyway requires securing their confidentiality: the secure messaging in encrypt-then-authenticate mode is required for all messages according to [12], sec. 4.2.2, 4.3.2, 4.4.2. 42 represents a prerequisite for anonymity of the RP_Card holder Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 22 of 133 Bundesamt für Sicherheit in der Informationstechnik Object No. Asset Definition Generic security property to be maintained by the current security policy data current a the RP_Card gathered by inconspicuous (for the RP_Card holder) recognising the TOE know nd previous locations of ing neither CAN nor MRZ ta can be provided / nor eID-PIN nor eID-PUK. TOE tracing da gathered. This asset covers ‘ePass tracing data’ (object #3) in [7]. Table 2: Primary assets 69 Application Note 23: Please note that user data being referred to in the table above include, am gs l- also include his sensitive (biometrical) dat by the current PP also secures P_ 70 All these primary assets re the CC. 71 The secondar cient pr cti a on t other, individua these specific R related (personal) data of the RP_Ca a. Hence, the general security policy Card holder’s data as stated in the table rd holder which defined above. present User Data in the sense of having to be pr y assets also on of the primary otected by the TOE in order to achieve a suffi ssets are: ote Object No. Asset Definition Property to be maintained by the current security policy ePassport, eID, eSign 4 Accessibility to the TOE functions and data only for s Availability authorised subjects Property of the TOE to restrict access to TSF and TSF-data stored in the TOE to authorised subject only. This asset covers the equivalent object #4 in [7]. 5 Genuineness of ty of the TOE Property of the TOE to be authentic in order to provide claimed security functionality in a proper way. This asset covers the equivalent object #5 in [7] and ‘Authenticity the MRTD’s chip’ in [6]. Availabili 6 TOE immanent secret cryptographic keys y stored secret cryptographic material used by the TOE in order to enforce its security functionality43. object #6 in [7]. Confidentiality Integrity Permanently or temporaril This asset covers the equivalent 43 please note that the private signature key within the eSign application (SCD) belongs to the object No. 1 ‘user data stored’ above. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 23 of 133 Object No. Asset Definition Property to be maintained by the current security policy 7 TOE imm non-secret cryptographic material anent arily stored blic) material rity , nd ‘SVD’ in [8]. ity Permanently or tempor non-secret cryptographic (pu keys and other non-secret (Card/Chip and Document Secu Objects SOC and SOD, respectively containing digital signatures) used by the TOE in order to enforce its security functionality. This asset covers the respective object #7 in [7] a Integrity Authentic 8 Secret RP_Card holder Secret authentication information for the RP_Card holder being used Confidentiality authentication data for verification of the authentication attempts as authorised RP_Card holder (– eID-PIN and eID-PUK44 stored in the RP_Card as well as – eSign-PIN (and eSign-PUK, if any)45 (i) stored in the RP_Card46 and (ii) transferred to it47) Integrity 9 RP_Card authorisation Restricted-revealable48 verification of the authorisation pts as authorised user (CAN for ePassport, eID, eSign; MRZ for ed in to it. This asset covers the respective object #8 in [7]. Confidentiality48 communication establishment authorisation information for a human user being used for Integrity data attem ePassport). These data are stor the TOE and are not to convey Table 3 ondary assets 72 Application Note 24: RP_Card holder authen nication establishment authorisation data are represented by two persistently stored in the TOE and (ii) verif TOE by a human user as an authentication/au The TOE shall secure the reference info l connected49 – the verification information e transferred to the TOE. Please note that CAN to the TOE. : Sec tication and RP_Card commu different entities: (i) reference information being ication information being provided as input for the thorisation attempt. rmation as well as – together with the termina in the ‘TOE <-> terminal’ channel, if it has to b , MRZ, eID-PIN and eID-PUK are not to convey 44 eID-PIN and eID-PUK are global secrets being valid for the entire RP_Card. 45 eSign-PIN (and eSign-PUK, if any) are local secrets being valid only within the eSign application. 47 is f necessary, his or her verification values of CAN and MRZ to an are trustworthy. e terminal 46 is commensurate with RAD in [8] commensurate with VAD in [8] 48 The RP_Card holder may reveal, i authorised person or device who definitely act according to respective regulations and 49 the input device of th Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 24 of 133 Bundesamt für Sicherheit in der Informationstechnik 73 The secondary assets represent TSF and TSF-data in the sense of t Subjects and external entities 74 This protection profile considers the followin he CC. g subjects: External Entity No. Subject No. Role Definition 1 1 RP_Card holder lised the RP_Card50. [7] and n A person for whom the RP_Card Issuer has persona This entity is commensurate with ‘MRTD Holder’ in [6], ‘ePass holder’ (subject #1) in ‘Signatory’ in [8]. Please note that an RP_Card holder can also be a attacker (s. below). 2 - RP_Card presenter ass presenter’ (external entity lso be A person presenting the RP_Card to a terminal51 and claiming the identity of the RP_Card holder. This external entity is commensurate with ‘Traveller’ in [6], ‘eP #2) in [7] and ‘User’ in [8]. Please note that an RP_Card presenter can a an attacker (s. below). 3 - Service Provider (SP) g er. s rightful terminals managed by An official or commercial organisation providin services which can be used by the RP_Card hold Service Provider use a DV. This external entity is commensurate with the respective external entity #3 in [7]. 4 2 Terminal nor EIS- e A terminal is any technical system communicating with the TOE through the contactless interface. The role ‘Terminal’ is the default role for any terminal being recognised by the TOE as neither PCT nor BIS-PACE nor EIS-AIP-BAC GAP nor ATT nor SGT (‘Terminal’ is used by th RP_Card presenter). This entity is commensurate with ‘Terminal’ in [6] and the respective external entity #4 in [7]. 5 3 PACE Terminal (PCT) A technical system verifying correspondence between the password stored in the RP_Card and the related value presented to the terminal by the RP_Card presenter. PCT implements the terminal’s part of the PACE protocol and authenticates itself to the RP_Card using a shared password (CAN, eID-PIN, eID-PUK with a concrete electronic Residence Permit Card 50 i.e. this person is uniquely associated 51 in the sense of [12] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 25 of 133 External Entity No. Subject No. Role Definition or MRZ). This entity is commensurate with the respective and external entity #5 in [7]. See also Application note 4 and par. 23 above [12], chap. 3.3, 4.2, table 1.2 and G.2 6 4 Basic Inspection System with PACE (BIS-PACE) by a governmental he RP_Card by the tion r to ta stored in the ePassport A technical system being used by an inspecting authority52 and operated organisation (i.e. an Official Domestic or Foreign Document Verifier) and verifying t presenter as the RP_Card holder (for ePassport: comparing the real biometrical data (face) of ePass presenter with the stored biometrical data (DG2) of the RP_Card holder). BIS-PACE is a PCT additionally supporting/applying the Passive Authentica protocol and is authorised53 by the RP_Card Issue through the Document Verifier of receiving state read a subset of da application on the RP_Card. BIS-PACE in the context of [12] (and of the current PP) is similar, but not equivalent to the Basic Inspection System (BIS) as defined in [5]. This entity is commensurate with the respective external entity #6 in [7]. See also Application note 4 and par. 23 above and [12], chap. 3.2.1, G.1 and G.2. 7 5 Extended Inspection System using AIP with BAC (EIS-AIP-BAC) verifying the RP_Card by (BIS) ) entication protocols in the A technical system being used by an inspecting authority54 and operated by a governmental organisation (i.e. an Official Domestic or Foreign Document Verifier) and presenter as the RP_Card holder (for ePassport: comparing the real biometrical data (face, fingerprint or iris) of the RP_Card presenter with the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-AIP-BAC is a Basic Inspection System in the sense of [5] additionally supporting/applying Chip Authentication (incl. passive authentication and Terminal Auth context of AIP and is authorised55 by the RP_Card Issuer through the Document Verifier of receiving 52 concretely, by a control officer 53 by organisational measures 54 concretely, by a control officer 55 by issuing terminal certificates Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 26 of 133 Bundesamt für Sicherheit in der Informationstechnik External Entity No. Subject No. Role Definition state to read a subset of data stored on the RP_ EIS-AIP-BAC in the context of [12] (and of the current PP) is equivalent to the Extended Inspection System (EIS) as defined in [6]. Card. See also Application note 4 and par. 23 above and [12], chap. 3.2 and C.4. 8 6 Extended Inspection System using GAP (EIS-GAP) cial Domestic or Foreign th tication (incl. passive authentication) d . ent ation note 4 and par. 23 above and A technical system being used by an inspecting authority56 and operated by a governmental organisation (i.e. an Offi Document Verifier) and verifying the RP_Card presenter as the RP_Card holder (for ePassport: by comparing the real biometrical data (face, fingerprint or iris) of the RP_Card presenter wi the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-GAP is a PCT additionally supporting/applying Chip Authen and Terminal Authentication protocols in the context of GAP and is authorised57 by the RP_Car Issuer through the Document Verifier of receiving state to read a subset of data stored on the RP_Card EIS-GAP in the context of [12] (and of the curr PP) is similar, but not equivalent to the Extended Inspection System (EIS) as defined in [6]. See also Applic [12], chap. 3.2 and C.4. 9 7 Authentication Terminal (ATT) mental organisation (Official Domestic ign Chip Authentication (incl. passive A technical system being operated and used either by a govern Document Verifier) or by any other, also commercial organisation and (i) verifying the RP_Card presenter as the RP_Card holder (using secret eID-PIN58), (ii) updating a subset of the data of the eID application and (iii) activating the eS application. An Authentication Terminal is a PCT additionally supporting the authentication) and the Terminal Authentication protocols in the context of GAP and is authorised by the RP_Card Issuer through the Document Verifier of receiving branch (by issuing terminal certificates) to access a subset of the data stored on 56 concretely, by a control officer 57 by issuing terminal certificates 58 secret eID-PUK can be used for unblocking the eID-PIN as well as the eSign-PIN and resetting the related retry counters. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 27 of 133 External Entity No. Subject No. Role Definition the RP_Card. See also par. 23 above and [12], chap. 3.2 and C.4. 10 8 Signature Terminal (SGT) c .4. A technical system used for generation of electroni signatures. A Signature Terminal is a PCT additionally supporting the Chip Authentication (incl. passive authentication) and the Terminal Authentication protocols in the context of GAP and is authorised by the RP_Card Issuer through the Document Verifier of receiving branch (by issuing terminal certificates) to access a subset of the data stored on the RP_Card. See also par. 23 above and [12], chap. 3.2 and C 11 9 Document Verifier l uer; a t (DV) An organisation enforcing the policies of the CVCA and of a Service Provider (governmental or commercial organisation) and managing terminals belonging together (e.g. terminals operated by a State’s border police), by – inter alia – issuing Terminal Certificates. A Document Verifier is therefore a CertA, authorised by at least the nationa CVCA to issue certificates for national terminals, see [12], chap. 2.2.2. There can be Domestic and Foreign DV: A domestic DV is acting under the policy of the domestic CVCA being run by the RP_Card Iss foreign DV is acting under a policy of the respective foreign CVCA (in this case there shall be an appropriate agreement59 between the RP_Card Issuer und a foreign CVCA ensuring enforcing the RP_Card Issuer’s privacy policy60). This entity is commensurate with ‘Documen Verifier’ in [6] and with the respective external entity #7 in [7]. 12 1 (CVCA) es of the public 0 Country Verifying Certification Authority An organisation enforcing the privacy policy of the RP_Card Issuer with respect to protection of user data stored in the RP_Card (at a trial of a terminal to get an access to these data). The CVCA represents the country specific root of the PKI for the rightful terminals (EIS-AIP-BAC, EIS-GAP, ATT, SGT) and creates the Document Verifier Certificates within this PKI. Updat key of the CVCA are distributed in form of CVCA 59 the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current PP in order to reflect an appropriate relationship between the parties involved. 60 Existing of such an agreement may technically be reflected by means of issuing a CCVCA-F for the Public Key of the foreign CVCA signed by the domestic CVCA. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 28 of 133 Bundesamt für Sicherheit in der Informationstechnik External Entity No. Subject No. Role Definition Link-Certificates, see [12], chap. 2.2.1. es for Document Signers grated wever, ed spective external entity #8 in [7]. The Country Signing Certification Authority (CSCA) issuing certificat (cf. [9]) and the domestic CVCA may be inte into a single entity, e.g. a Country CertA. Ho even in this case, separate key pairs must be us for different roles, see [12], sec. 2.2.1. This entity is commensurate with ‘Country Verifying Certification Authority’ in [6] and with the re 13 - Document Signer (DS) CA ity An organisation enforcing the policy of the CS and signing the Card/Chip and Document Secur Objects stored on the RP_Card for passive authentication. A Document Signer is authorised by the national CSCA issuing the Document Signer Certificate (CDS), see [12], chap. 1.1 and [9]. This role is usually delegated to a Personalisation Agent. This entity is commensurate with the respective external entity #9 in [7]. 14 - Country Signing Certification Authority (CSCA) or the RP_Cards and s le different An organisation enforcing the policy of the RP_Card Issuer with respect to confirming correctness of user and TSF data stored in the RP_Card. The CSCA represents the country specific root of the PKI f creates the Document Signer Certificates within thi PKI. The CSCA also issues the self-signed CSCA Certificate (CCSCA) having to be distributed by strictly secure diplomatic means, see. [9], 5.1.1. The Country Signing Certification Authority issuing certificates for Document Signers (cf. [9]) and the domestic CVCA may be integrated into a sing entity, e.g. a Country CertA. However, even in this case, separate key pairs must be used for roles, see [12], sec. 2.2.1. This entity is commensurate with the respective external entity #10 in [7]. 15 - Certification Service Provider (CSP) re Certification Service Provider can also issue qualified certificates61. An organisation issuing certificates and providing other services related to electronic signatures. The can be ‘common’ and ‘qualified’ CSP: A ‘qualified’ 61 cf. Application note 11 in sec. 2.2 above. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 29 of 133 External Entity No. Subject No. Role Definition A CSP is the Certification Service Provider in the sense of [8]. 16 11 Personalisation Agent RP_Card holder for f these data on the ard holder ument An organisation acting on behalf of the RP_Card Issuer to personalise the RP_Card for the RP_Card holder by some or all of the following activities: (i) establishing the identity of the the biographic data in the RP_Card62, (ii) enrolling the biometric reference data of the RP_Card holder63, (iii) writing a subset o physical Residence Permit Card (optical personalisation) and storing them in the RP_Card (electronic personalisation) for the RP_C as defined in [12], (iv) writing the document details data, (v) writing the initial TSF data, (vi) signing the Card/Chip Security Object and the Doc Security Object (ePassport) defined in [9] (in the role of DS). Please note that the role ‘Personalisation Agent’ may be distributed among several institutions according to the operational policy of the RP_Card Issuer. Generating signature key pair(s) is not in the scope of the tasks of this role. This entity is commensurate with ‘Personalisation agent’ in [6], the respective external entity #11 in [7] and ‘Administrator’ in [8]. 17 12 Manufacturer anufacturer E inguish between the IC Manufacturer and RP_Card Manufacturer using this role Manufacturer. This entity is commensurate with ‘Manufacturer’ in [6] and the respective external entity #12 in [7]. Generic term for the IC Manufacturer producing integrated circuit and the RP_Card M completing the IC to the RP_Card. The Manufacturer is the default user of the TOE during the manufacturing life cycle phase64. The TO itself does not dist 18 - Attacker A threat agent (a person or a process acting on his behalf) trying to undermine the security policy defined by the current PP, especially to change properties of the assets having to be maintained. The attacker is assumed to possess an at most high attack potential. Please note that the attacker might ‘capture’ any levant for the ePassport, the eID and the eSign applications levant for the ePassport application f. also par. 14 62 re 63 re 64 c in sec. 1.2.3 above Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 30 of 133 Bundesamt für Sicherheit in der Informationstechnik External Entity No. Subject No. Role Definition subject role recognised by the TOE. This entity is commensurate with ‘Attacker’ in [6], the respective external entity #13 in [7] and ‘Attacker’ in [8]. Table 4: Subjects and external entities65 3.2 75 T on with it TOE and the method of TOE’s use in the operational environment. 76 T B 77 T.Skimming Skimming RP_Card / Capturing Card-Terminal Communication nsferred between the TOE and the service provider connected via the contactless interface of the TOE. The attacker cannot read and does not know Threats his section describes the threats to be averted by the TOE independently or in collaborati s IT environment. These threats result from the assets protected by the he following threats are defined in the current PP (they are initially derived from the ICAO- AC PP [5] and ICAO-EAC PP [6], then from the ID_Card PP BSI-CC-PP-0061-2009): An attacker imitates an inspection system, an authentication or a signature terminal in order to get access to the user data stored on or tra This item conce s): ePassport, eID, eSign. Application note 4 above. revealable, cf. OE.Card-Holder. communication between the TOE and a rightful terminal n. the correct value of the shared password (CAN, MRZ, eID-PIN, eID-PUK) in advance. rns the following application( Application Note 25: A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this threat is confined to only selected data groups (DG3, DG4) within the ePassport application, see also the Application Note 26: MRZ is printed and CAN is printed or stuck on the Residence Permit Card. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted- 78 T.Eavesdropping Eavesdropping on the An attacker is listening to the communication between the RP_Card and a rightful terminal in order to gain the user data transferred between the TOE and the service provider connected. This item concerns the following application(s): ePassport, eID, eSig table defines external entities and subjects in the sense of [1]. Subjects can be recognised by the TOE ependent of their nature (human or technical user). As result of an appropriate identification and thentication process, the TOE crea rks’ then with this TOE internal im 65 This ind au tes – for each of the respective external entity – an ‘image’ inside and ‘wo age (also called subject in [1]). From this point of view, the TOE here is no dedicated subject with the role ight ‘capture’ any subject role recognised by the TOE. itself does not differ between ‘subjects’ and ‘external entities’. T ‘attacker’ within the current security policy, whereby an attacker m Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 31 of 133 Application Note 27: A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this threat is confined to only selected data groups (DG3, DG4) within the ePassport application, see also the Application note 4 above. .Tracing Tracing RP_Card 79 T An attacker tries to gather TOE tracing data (i.e. to trace the movement of the RP_Card) unambiguously identifying it remotely by establishing or listening to a communication via the contactless interface of the TOE. The attacker cannot read and does not know the correct values of shared passwords (CAN, MRZ, eID-PIN, eID-PUK) in advance. This item concerns the following application(s): ePassport, eID, eSign. Application Note 28: A product using BAC (whatever the type of the inspection system is: or EIS-AIP-BAC) cannot avert this threat in the context of the security policy defined in this PP. Hence, this threat is considered not to be allied with using EIS-AIP-BAC, see also 80 T rd and copy them on another functionally enticity of the RP_Card being used either for authentication of an RP_Card presenter as the RP_Card holder or for o ignature creation device. This item concerns the following application(s): ePassport, eID, eSign. plication note 4 above. 81 T.Forgery Forgery of Data ged between the TOE and the service provider connected in order to outsmart either the authenticated terminal (BIS-PACE, EIS-AIP-BAC, EIS-GAP, ATT or SGT) by the means of aphic or biometric data or SCD/SVD) or the TOE by altering data being sent to the TOE (like DTBS/R). The attacker 82 T BIS-BAC the Application note 4 above. .Counterfeit Counterfeiting RP_Card An attacker produces an unauthorised copy or reproduction of a genuine RP_Card to be used as part of a counterfeit Residence Permit Card: he or she may generate a new data set or extract completely or partially the data from a genuine RP_Ca appropriate chip to imitate this genuine RP_Card. This violates the auth authentication f the RP_Card as a genuine secure s Application Note 29: Since the Standard Inspection Procedure does not support any unique-secret-based authentication of the chip (no Chip Authentication), a product using Basic Inspection System (whatever the used protocol is: BAC or PACE) cannot avert this threat in the context of the security policy defined in this PP. Hence, this threat is considered not to be allied with using BIS-PACE, see also the Ap An attacker fraudulently alters the User Data or/and TSF-data stored on the RP_Card or/and exchan changed RP_Card holder’s related reference data (like biogr does it in such a way that the Service Provider (represented by the terminal connected) or the TOE perceives these modified data as authentic one. This item concerns the following application(s): ePassport, eID, eSign. .Abuse-Func Abuse of Functionality An attacker may use functions of the TOE which shall not be used in TOE operational phase in order (i) to manipulate or to disclosure the User Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored in the TOE or (iii) to manipulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. This threat addresses the misuse of the functions for the initialisation and personalisation in the operational phase after delivery to the RP_Card Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 32 of 133 Bundesamt für Sicherheit in der Informationstechnik holder. This item concerns the following application(s): ePassport, eID, eSign. Application Note 30: Details of the relevant attack scenarios depend, for instance, on the C Dedicated Test Software being not specified here. 83 T s usage in order to disclose exchanged between the TOE and the service provider connected. The information leakage may be inherent in the (DPA). Moreover the attacker may try actively to enforce information leakage by fault injection a 84 T eID, eSign. Application Note 32: Physical tampering may be focused directly on the disclosure or to enable information leakage through power analysis). Physical tampering requires a direct interaction with the P_Card’s internals. Techniques commonly employed in IC failure analysis and IC reverse engineering efforts may be used. Before that, hardware security mechanisms and layout TSF data may also be a pre-requisite. The modification may result in the deactivation of a security function. Changes of circuitry or data can be permanent or temporary. 85 T.Malfunction to Environmental Stress u nction the R Software by applying environmental stress in order to features or functionality of the TOE’ hardware or to or modify security bedded Software. This may be achieved e.g. by operating the utside th perating c ditions, exploiting errors in the RP_Card’s Embedded Software or misusing administrative functions. To exploit these vulnerabilities an capabilities of the test features provided by the I .Information_Leakage Information Leakage from RP_Card An attacker may exploit information leaking from the TOE during it confidential User Data or/and TSF-data stored on the RP_Card or/and normal operation or caused by the attacker. This item concerns the following application(s): ePassport, eID, eSign. Application Note 31: Leakage may occur through emanations, variations in power consumption, I/O characteristics, clock frequency, or by changes in processing time requirements. This leakage may be interpreted as a covert channel transmission, but is more closely related to measurement of operating parameters which may be derived either from measurements of the contactless interface (emanation) or direct measurements (by contact to the chip still available even for a contactless chip) and can then be related to the specific operation being performed. Examples are Differential Electromagnetic Analysis (DEMA) and Differential Power Analysis (e.g. Differenti l Fault Analysis). .Phys-Tamper Physical Tampering An attacker may perform physical probing of the RP_Card in order (i) to disclose the TSF-data, or (ii) to disclose/reconstruct the TOE’s Embedded Software. An attacker may physically modify the RP_Card in order to alter (i) its security functionality (hardware and software part, as well), (ii) the User Data or the TSF-data stored on the RP_Card. This item concerns the following application(s): ePassport, manipulation of the user data (e.g. the biometric reference data for the inspection system) or the TSF data (e.g. authentication key of the RP_Card) or indirectly by preparation of the TOE to following attack methods by modification of security features (e.g. R characteristics need to be identified. Determination of software design including treatment of the user data and the Malfunction due An attacker may ca se a malfu P_Card’s hardware and Embedded (i) deactivate or modify security (ii) circumvent, deactivate functions of the TOE’s Em RP_Card o e normal o on Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 33 of 133 attacker needs infor m co mation about the functional operation. This ite ncerns the following application(s): ePassport, eID, eSign. on note 33: the TOE may also be caused using a direct interaction with elements on the chip surface. This is considered as being a manipulation (refer to the threat er) assu ed knowledge about TOE’s internals. 86 The current PP also includes all threats of the ICAO-EAC PP [6]. Formally, they only concern the e cation. Applicati A malfunction of T.Phys-Tamp ming a detail Passport appli Threat identifier from [6] Equivalent to / covered by item in the current PP Comments T.Read_Sensitive_Data T.Skimming Sensitive biometric reference data (DG3, DG4) stored on the RP_Card are part of the asset user data stored on the TOE. T.Counterfeit T.Counterfeit - T.Forgery T.Forgery - T.Abuse-Func T.Abuse-Func - T.Information_Leakag e T.Information_Leakage - T.Phys-Tamper per T.Phys-Tam - T.Malfunction ion T.Malfunct - Table 5: Thr taken o 87 The current PP also includes all threats of the PACE-Pass PP [7]. Formally, they only concern the e cation. eats ver from [6] Passport appli Threat identifier from [7] Equivalent to / covered by item in the current PP Comments T.Skimming T.Skimming - T.Eavesdropping T.Eavesdropping - T.Tracing T.Tracing - T.Forgery T.Forgery - T.Abuse-Func T.Abuse-Func - T.Information_Leakag ation_Leakage - T.Inform Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 34 of 133 Bundesamt für Sicherheit in der Informationstechnik Threat identifier from [7] Equivalent to / covered by item in the current PP Comments e T.Phys-Tamper T.Phys-Tamper - T.Malfunction T.Malfunction - Table 6: Threats taken over from [7] 88 The current PP also includes all threats of the SSCD PP [8]. These items are applicable, if the eSign application is operational. Formally, they only concern the eSign application. Threat identifier from [8] Equivalent to / covered by item in the current PP Comments T.SCD_Divulge - - T.SCD_Derive - - T.Hack_Phys T.Phys-Tamper - T.SVD_Forgery T.Forgery T.Eavesdropping T.Forgery covers SVD stored; T.Eavesdropping covers SVD being sent to the CGA T.SigF_Misuse T.Abuse-Func - T.DTBS_Forgery T.Skimming T.Skimming covers a rightful SCA T.Forgery covers DTBS/R being sent to the TOE. T.Forgery T.Sig_Forgery - - Table 7: Threats taken over from [8] 89 Application note 34: The threat T.Hack_Phys from the SSCD PP [8] is completely covered by the threat T.Phys-Tamper identified in the current PP: these items cover the same content. Hence, a parallel using both the items would not add anything to the security policy defined by the current PP. It means that the threat T.Phys-Tamper implicates the item T.Hack_Phys. Therefore, in order to avoid multiple formal items for same content and to make the PP easier comprehensible, we explicitly use, where appropriate66, only the item of the current PP (for this example: T.Phys-Tamper), what implicitly includes the related item from the PP, to which the conformance claim has been made (for this example: T.Hack_Phys). This approach will be applied throughout the current PP. 66 A prerequisite for this is a complete coverage / equivalence of the items in question. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 35 of 133 3.3 Organisational Security Policies 90 The TOE and/or its environment shall comply with the following Organisational Security Policies ng of the RP_Card rminals complying with able 2) 3) (OSP) as security rules, procedures, practices, or guidelines imposed by an organisation upon its operation. 91 P.Pre-Operational Pre-operational handli 1) The RP_Card Issuer issues the RP_Cards and approves using the te all applic laws and regulations. The RP_Card Issuer guarantees correctness of the user data (amongst other of those, concerning the RP_Card holder) and of the TSF-data permanently stored in the TOE67. The RP_Card Issuer uses only such TOE’s technical components (IC) which enable traceability of the RP_Cards in their manufacturing and issuing life cycle phases, i.e. before they are in the operational phase, cf. sec. 1.2.3 above. tificates belonging to the PKI are securely distributed / made available to their final destination, e.g. by using directory ) and the Document Signer Certificates (CDS) available to the CVCAs under agreement69 (who shall finally distribute them to their rightful terminals). 2) The CSCA shall securely generate, store and use the CSCA key pair. The CSCA shall keep having to be 3) A Document Signer shall (i) generate the Document Signer Key Pair, (ii) hand over the Document Signer Public Key to the CSCA for certification, (iii) keep the Document Signer Private Key secret, (iv) securely use the Document Signer Private Key for signing the 4) If the RP_Card Issuer authorises a Personalisation Agent to personalise the RP_Cards for RP_Card holders, the RP_Card Issuer has to ensure that the Personalisation Agent acts in accordance with the RP_Card Issuer’s policy. This item concerns the following application(s): ePassport, eID, eSign. 92 P.Card_PKI PKI for Chip and Passive Authentication (issuing branch)68 Application Note 35: The description below states the responsibilities of involved parties and represents the logical, but not the physical structure of the PKI. Physical distribution ways shall be implemented by the involved parties in such a way that all cer services. 1) The RP_Card Issuer shall establish a public key infrastructure for the passive authentication, i.e. for digital signature creation and verification for the RP_Card. For this aim, he runs a Country Signing Certification Authority (CSCA). The RP_Card Issuer shall make the CSCA Certificate (CCSCA the CSCA Private Key secret and issue a self-signed CSCA Certificate (CCSCA) made available to the RP_Card Issuer by strictly secure means, see [9], 5.1.1. The CSCA shall create the Document Signer Certificates for the Document Signer Public Keys (CDS) and make them available to the RP_Card Issuer, see [9], 5.5.1. 67 cf. Table 2 and Table 3 above 68 Passive authentication using SOC is considered to be part of the chip authentication protocol within this PP. e form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current PP in order to reflect an appropriate relationship between the parties involved. 69 th Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 36 of 133 Bundesamt für Sicherheit in der Informationstechnik Card/Chip and Document Security Objects of RP_Cards and (v) manage Chip Authentication Key Pairs {SKPICC, PKPICC} used for the chip authentication as defined in [12], sec. 4.3.70 Application Note 36: The description below states the responsibilities of involved parties and 1) The RP_Card Issuer shall establish a public key infrastructure for the card verifiable se the CVCA key pair. A CVCA shall keep the CVCA Private Key secret and issue a self-signed CVCA Certificate (CCVCA) having to be to the CVCA for certification, (iii) keep the Document Verifier Private Key secret and (iv) securely use the Document Verifier Private Key for managed by him. The Document Verifier shall make C , C and CCVCA available to the respective Service Private Keys (SKPCD) secret, (iv) securely use the Terminal Authentication Private Keys for the terminal authentication as This item concerns the following application(s): ePassport, eID, eSign. 93 P.Terminal_PKI PKI for Terminal Authentication (receiving branch) represents the logical, but not the physical structure of the PKI. Physical distribution ways shall be implemented by the involved parties in such a way that all certificates belonging to the PKI are securely distributed / made available to their final destination, e.g. by using directory services. certificates used for terminal authentication. For this aim, the RP_Card Issuer shall run a domestic Country Verifying Certification Authority (domestic CVCA) and may use already existing foreign CVCAs71. The RP_Card Issuer shall make the CVCA Link Certificate available to the CSCA (who shall finally distribute it to its RP_Cards). 2) A CVCA shall securely generate, store and u made available to the RP_Card Issuer by strictly secure means as well as to the respective Document Verifiers. A CVCA shall create the Document Verifier Certificates for Document Verifier Public Keys (CDV) and distribute them back to the respective Document Verifiers72. 3) A Document Verifier shall (i) generate the Document Verifier Key Pair, (ii) hand over the Document Verifier Public Key signing the Terminal Certificates (CT) of the terminals being T DV Provider (who puts them in his terminals)73. 4) A Service Provider shall (i) generate the Terminal Authentication Key Pairs {SKPCD, PKPCD}, (ii) hand over the Terminal Authentication Public Keys (PKPCD) to the DV for certification, (iii) keep the Terminal Authentication defined in [12], sec. 4.4 and (v) install CT, CDV and CCVCA in the rightful terminals operated by him. 70 A Document Signer shall also manage Restricted Identification Key Pairs {SKID, PKID} [12], sec. 2.4 and 4.5. The private Restricted Identification Key SKID shall be stored in the TOE, whereby the public Restricted 71 In be by means of issuing a C for the Public Key of the foreign CVCA signed by the domestic 72 A } [12], sec. 2.4 and 4.5. For 73 A } [12], sec. 2.4 and 4.5. For Restricted te 6 and Table 2, object #1. Identification Key PKID – in a database of the DS. See also Application note 6 and Table 2, object #1. this case there shall be an appropriate agreement between the RP_Card Issuer und a foreign CVCA ensuring enforcing the RP_Card Issuer’s privacy policy. Existence of such an agreement may technically reflected CVCA-F CVCA. CVCA shall also manage a Revocation Sector Key Pair {SK , PK Revocation Revocation Restricted Identification please see Application note 6 and Table 2, object #1. DV shall also manage Sector’s Static Key Pairs {SKSectorNN, PKSectorNN Identification please see Application no Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 37 of 133 This item concerns the following application(s): ePassport, eID, eSign. 94 P.Trustworthy_PKI Trustworthiness of PKI 1) The CSCA shall ensure that it issues its certificates exclusively to the rightful organisations d DS and Document Security Objects having to be stored on the RP_Cards. hey issue their certificates exclusively to the rightful equipment (terminals)74. 1) Rightful terminals (BIS-PACE, EIS-AIP-BAC, EIS-GAP, authentication terminal and S-AIP-BAC), of the Terminal Authentication protocol [12], sec. 4.4, of the Passive Authentication with ting ephemeral keys for Diffie-Hellmann). pair {SKPCD, PKPCD} and the terminal certificate (CT) over PKPCD issued by the DV related as well as CDV and CCVCA; the terminal certificate includes an ntry Signing Public Key and the Document Signer Public Key (in form of CCSCA and CDS) in order to enable and to perform Passive Authentication with and SOD (determination of the authenticity of the data groups stored in the ePassport, [12], sec. 1.1). (DS) an s shall ensure that they sign exclusively correct Card/Chip 2) CVCAs shall ensure that they issue their certificates exclusively to the rightful organisations (DV) and DVs shall ensure that t 3) CSPs shall ensure that they issue their certificates exclusively for the rightful data (public signature key of the RP_Card holder)75. This item concerns the following application(s): ePassport, eID, eSign. 95 P.Terminal Abilities and trustworthiness of rightful terminals signature terminal, cf. Table 1 above) shall be used by Service Providers and by RP_Card holders as defined in [12], sec. 3.2. 2) They shall implement either the terminal parts of the PACE protocol [12], sec. 4.2 (for BIS- PACE, EIS-GAP) or the terminal parts of the BAC protocol [12], sec. H (for EI SOC [12], sec. 3.4, of the Chip Authentication protocol [12], sec. 4.376 and of the Passive Authentication with SOD [12], sec. 1.1 and use them – dependent on the type of terminal – in the order as required by [12], sec. 3.1.1 and 3.2. A rightful terminal shall use randomly and (almost) uniformly selected nonces, if required by the protocols (for genera 3) Rightful terminals shall store the related credentials needed for the terminal authentication77 (terminal authentication key authorisation mask (CHAT) for access to the data stored on the RP_Card) in order to enable and to perform the terminal authentication as defined in [12], sec. 4.4. 4) They shall also store the Cou SOC (determination of the authenticity of PKPICC, [12], sec. 4.3.1.2) 76 T e Authentication with SO is considered to be part of the Chip Authentication (CA) Protocol within ACE) 74 This rule is relevant for T.Skimming 75 This property is affine to P.CSP_QCert from [8]. he Passiv C this PP. 77 not applicable to any BIS (here: BIS-P Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 38 of 133 Bundesamt für Sicherheit in der Informationstechnik 5) a (e.g. eSign-PIN, DTBS) to the TOE within the PACE session, but first having successfully performed the Chip Authentication after the Terminal Authentication78. 6) A rightful terminal and its environment shall ensure confidentiality and integrity of ata han confiden Z, integrity of PKI certificates and DTBS, etc.), where i n of the TOE according to the cu This item concerns the following application(s): ePassport, eID, eSign. 96 The current PP also includes all OSPs of the IC nly concern the ePassport application. A rightful termin l must not send assets respective d dled by it (e.g. tiality of PINs/PUKs, CAN and MR t is necessary for a secure operatio rrent PP. AO-EAC PP [6]. Formally, they o OSP identifier from [6] Equivalent to / covered by item in the current PP Comments P.BAC-PP - - P.Sensitive_Data P.Terminal_PKI T.Eavesdropping the authorization of inspection systems P.Terminal_PKI covers ‘The issuing State or Organization authorizes the Document Verifiers of the receiving States to manage within the limits defined by the Document Verifier Certificate.’ T.Eavesdroppin e MRTD’s chip shall protect the confidentiality and integrity of the sensitive private personal ta even during transmission to the ed Inspection System after Chip thentication.’ g covers ‘Th da Extend Au P.Manufact P.Pre-Operational - P.Personalization P.Pre-Operational - Table 8: OSPs taken over from [6] 7 The current PP also includes all OSPs of the PACE-Pass PP [7]. Formally, they only concern the 9 ePassport application. OSP identifier from [7] Equivalent to / covered by item in the current PP Comments P.Pre-Operational P.Pre-Operational - P.Card_PKI P.Card_PKI - P.Trustworthy_PKI P.Trustworthy_PKI - 78 This rule is relevant for T.Skimming Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 39 of 133 OSP identifier from [7] Equivalent to / covered by item in the current PP Comments P.Terminal P.Terminal - Table 9: OSPs taken over from [7] 98 The current PP also includes all OSPs of the SSCD PP [8] (please regard the Application note 11 above). These items are applicable, if the eSign application is operational. Formally, they only c application. oncern the eSign OSP identifier from [8] Equivalent to / covered by item in the current PP Comments P.CSP_QCert P.Trustworthy_PKI (partially) P.Trustworthy_PKI covers rightful SVDs within related certificates. CGA, to put correct names of the certificate or other publicly av Additionally, CSP has to use a trustworthy signatories into its certificates and to ensure that the use of the TOE as SSCD is evident with signatures through the ailable information. P.QSig - n - P.Sigy_SSCD - - P.Sig_Non-Repud - - T ken 3.4 Assumptions 99 The assumptions describe the security aspects o TOE will be used or is intended to be use 100 The current PP includes all assumptions of the Application note 13 above). Formally, they only concern the able 10: OSPs ta over from [8] f the environment in which the d. ICAO-EAC PP [6] (please regard the ePassport application. Assumption identifier from [6] Equivalent to / covered by item in the current PP Comments (some notions in this column are used as in [6] for better comparability) A.MRTD_Manufact ALC_DVS.2, see sec. 6.2 below Such a kind of assumptions is always automatically covered by a component of the assurance family ALC_DVS, if chosen. A.MRTD_Delivery see sec. 6.2 ch a kind of assumptions is always covered by a component of e assurance family ALC_DEL, if chosen. ALC_DEL.1, below Su automatically th Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 40 of 133 Bundesamt für Sicherheit in der Informationstechnik Assumption identifier from [6] Equivalent to / covered by item in the current PP Comments (some notions in this column are used as in [6] for better comparability) A.Pers_Agent P.Pre-Operational P.Card_PKI P.Pre-Operational covers ensuring the correctness of the logical MRTD with respect to the MRTD holder P.Card_PKI covers ensuring the correctness of keys and certificates stored on the MRTD’s chip an Security Object (SOD). d signing the Document A.Insp_Sys P.Terminal_PKI P.Terminal P.Terminal_PKI covers availability of keys and certificates stored in the inspection system P.Terminal covers supporting necessary authentication protocols according to [12]. A.Signature_PKI P.Card_PKI - A.Auth_PKI P.Terminal_PKI - Table 11 tion note 37 Assumptions A.MRTD_Manufact and A.MRTD_Delivery from [6] address manufacturing, testing and delivery tions is a necessary condition for a ‘pass’ judgement components ALC_DVS.2 and ALC_DEL.1, respective means that if the respective assurance components ALC_DVS.2 and ALC_DEL.1 have positively been judged, the fulfilment of these tions is ‘auto : th ponsible for applying all the related procedures with respect to the TOE. Therefore, the assumptions A.MRTD_Manufact and A.MRTD_Delivery are implicitly included into the current PP by choosing the assurance EL.1. The remaining assumptions from [6] A. A.Auth_PKI are completely covered by the respective items (OSPs) defined in the current PP. above, we will explicitly use the items of the current PP. rd the Application note 19 and Table 1 above). These items are applicable, if the eSign application is operational. Formally, they only concern the eSign application. : Assumptions taken over from [6] Applica : aspects. Fulfillment of such assump by applying the chosen assurance ly. It assump matically’ ensured e manufacturer is required and res components ALC_DVS.2 and ALC_D Pers_Agent, A.Insp_Sys, A.Signature_PKI and Hence, according to the Application note 34 101 The current PP includes all assumptions of the PACE-Pass PP [7]: they represent an empty set. 102 The current PP includes all assumptions of the SSCD PP [8] (please rega Assumption identifier [8] Equivalent to / covered by item in the current PP Comments A.CGA - This item concerns not only qualified, but also non-qualified certificates, cf. Application note 11 above – remark of the Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 41 of 133 Assumption identifier [8] Equivalent to / covered by item in the current PP Comments author A.SCA P.Terminal (partially) P.Terminal covers using trustworthy SCAs. Additionally, the SCA shall generate and send the DTBS/R to the TOE. Table 12: Assumptions taken over from [8] 103 The current PP does not c include any additional, ‘own’ assumptions. Hence, as a result of the urrent section, there are explicitly only two assumptions within the current PP: A.CGA and .SCA being exclusively applicable to the eSign application of the TOE. A Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 42 of 133 Bundesamt für Sicherheit in der Informationstechnik 4 S 104 T e 4.1 E 105 The following TOE se o 106 O The TOE must ensure integrity of the User Data and the TSF-data79 stored on it by protecting sical manipulation and unauthorised modifying). ation Note 25 above. d be either BIS-PACE, ups (DG3, DG4) within the ePassport application, see also the Application Note 25 above. ecurity Objectives his chapter describes the security objectives for the TOE and the security objectives for the TOE nvironment. Security Objectives for the TO curity objectives address the protection provided by the TOE independent f TOE environment. T.Data_Integrity Integrity of Data these data against unauthorised modification (phy The TOE must ensure integrity of the User Data and the TSF-data79 during their exchange between the TOE and the Service Provider connected (and represented by either BIS-PACE, EIS-AIP-BAC, EIS-GAP or ATT or SGT) after the PACE Authentication as well as the Terminal- and the Chip Authentication. This item concerns the following application(s): ePassport, eID, eSign. Application Note 38: A product using BIS-BAC cannot achieve this objective either for stored or being transmitted data in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this objective is confined to only selected data groups (DG3, DG4) within the ePassport application, see also the Applic 107 OT.Data_Authenticity Authenticity of Data The TOE must ensure authenticity of the User Data and the TSF-data80 stored on it by enabling verification of their authenticity at the terminal-side81. The TOE must ensure authenticity of the User Data and the TSF-data80 during their exchange between the TOE and the Service Provider connected (and represente EIS-AIP-BAC, EIS-GAP or ATT or SGT) after the PACE Authentication as well as the Terminal- and the Chip Authentication. It shall happen by enabling such a verification at the terminal-side (at receiving by the terminal) and by an active verification by the TOE itself (at receiving by the TOE)82. This item concerns the following application(s): ePassport, eID, eSign. Application Note 39: A product using BIS-BAC cannot achieve this objective either for stored or being transmitted data in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this objective is confined to only selected data gro 108 OT.Data_Confidentiality Confidentiality of Data 80 w 81 v 82 s 79 where appropriate, see Table 3 above here appropriate, see Table 3 above erification of SOC ecure messaging after the PACE authentication, see also [12], sec. 4.2.2 as well as after the chip authentication, see also [12], sec. 4.4.2 Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 43 of 133 The TOE must ensure confidentiality of the User Data and the TSF-data83 by granting read access only to authorised rightful terminals (BIS-PACE, EIS-AIP-BAC, EIS-GAP, ATT, SGT) according to the effective terminal authorisation level (CHAT)84 presented by the terminal connected85. The TOE must ensure confidentiality of the User Data and the TSF-data83 during their exchange between the TOE and the Service Provider connected (and represented be either BIS- entication as well as the Terminal- and the Chip Authentication. lication, see also the Application Note 25 and Application Note 27 above. 109 OT.Tracing Tracing RP_Card racing data by means of unambiguous identifying the RP_Card remotely through establishing or listening to a communication via the contactless llowing application(s): ePassport, eID, eSign. atever the type of the inspection system is: his objective in the context of the security policy th using EIS-AIP-BAC, 110 O ticity of the RP_Card as a eID, eSign. by knowledge, i.e. a Chip Authentication Private Key as PICC by (i) the Chip of this PKPICC in the curity Object (SOC) signed by the Document Signer. PACE, EIS-AIP-BAC, EIS-GAP or ATT or SGT) after the PACE Auth This item concerns the following application(s): ePassport, eID, eSign. Application Note 40: A product using BIS-BAC cannot achieve this objective in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this objective is confined to only selected data groups (DG3, DG4) within the ePassport app The TOE must prevent gathering TOE t interface of the TOE without knowledge of the correct values of shared passwords (CAN, MRZ, eID-PIN, eID-PUK) in advance. This item concerns the fo Application Note 41: A product using BAC BIS-BAC or EIS-AIP-BAC) cannot achieve t (wh defined in this PP. Hence, this objective is considered not to be allied wi see also the Application Note 28 above. T.Chip_Auth_Proof Proof of RP_Card authenticity The TOE must enable the terminal connected to verify the authen whole device as issued by the RP_Card Issuer (issuing PKI branch of the RP_Card Issuer) by means of the Passive (using SOC) and Chip Authentication as defined in [12], sec. 4.3. This item concerns the following application(s): ePassport, Application note 42: The OT.Chip_Auth_Proof implies the RP_Card’s chip to have a unique secret to prove its authenticity TSF-data. The terminal shall have the reference data to verify the authentication attempt of the RP_Card’s , i.e. a certificate for the respective Chip Authentication Public Key (PK ) fitting to the chip Chip Authentication Private Key (SKPICC). This certificate is provided Authentication Public Key stored on the TOE and (ii) the hash value Card/Chip Se 83 where appropriate, see Table 3 above 84 CHAT is not applicable to BIS (here: BIS-PACE). For BIS-PACE, table 1.2 in sec. PACE) shall be applied. 1.1 of [12] (column 85 The authorisation of the terminal connected (CHAT) is drawn from the terminal certificate chain used for the be a non-strict subset of the authorisation defined in the Terminal Certificate (CT), the Document Verifier Certificate (CDV) and the CC (re restricted successful terminal authentication as defined in [12], sec. 4.4 and shall VCA in the certificate chain up to the Country Verifying Certification Authority of the RP_Card Issuer ceiving PKI branch of the RP_Card Issuer). The effective terminal authorisation can additionally be by the RP_Card holder by a respective input at the terminal. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 44 of 133 Bundesamt für Sicherheit in der Informationstechnik Application Note 43: Since the Standard Inspection Procedure does not support any unique-secret-based authentication of the chip (no Chip Authentication), a product using Basic Inspection System in the context of the security policy defined in this PP. Hence, this objec (whatever the used protocol is: BAC or PACE) cannot achieve this objective tive is considered not to be allied with using BIS-PACE, see also the Application Note 29 above. 111 OT.Prot_Abuse-Func Protection against Abuse of Functionality unctions of the TOE, which may not be used in TOE operational phase, can be abused in order (i) to manipulate or to disclose the User Data stored in the TOE, the TOE, (iii) to manipulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. 112 O The TOE must provide protection against disclosure of confidential User Data or/and TSF-data pplication note 44: This objective pertains to measurements with subsequent complex signal al operation of the TOE or operations enforced by an attacker. de entiality and i the User Data, the TSF- data and RP_Card’s by means of ring throug cts representing a direct physical probing on the chip’s ept o ded (using standard tools for measuring voltage and t) or – measuring not using galvanic contacts, but other types of physical interaction between rges l re analysis), – manipulation of the hardware and its secu – controlled manipulation of memory conte a, TSF-data) eeri des roperties and functionality. the on(s ePassport, eID, eSign. 114 OT.Prot_Malfunction Protection against Malfunctions rect operation. The TOE must prevent its operation outside the been proven or The TOE must prevent that f (ii) to manipulate or to disclose the TSF-data stored in This item concerns the following application(s): ePassport, eID, eSign. T.Prot_Inf_Leak Protection against Information Leakage stored and/or processed by the RP_Card – by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines, – by forcing a malfunction of the TOE and/or – by a physical manipulation of the TOE. This item concerns the following application(s): ePassport, eID, eSign. A processing due to norm 113 OT.Prot_Phys-Tamper Protection against Physical Tampering The TOE must provi the protection of confid Embedded Software ntegrity of – measu surface exc h galvanic conta n pads being bon curren electrical cha (using tools used in so id-state physics research and IC failu rity functionality, as well as nts (User Dat with a prior – reverse-engin ng to understand the ign and its p This item concerns following applicati ): The TOE must ensure its cor normal operating conditions where reliability and secure operation have not Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 45 of 133 tested. This is to prevent functional errors in the TOE. The environmental conditions may include external energy (esp. electromagnetic) fields, voltage (on any contacts), clock frequency or temperature. rns the ation(s): ePassport, eID, eSign. 115 T secu ress e aspects of identified threats to be countered involving TOE’s environment. 116 OT.Identification Identification of the TOE le phases of the RP_Card. 117 OT.Personalisation RP_Card ensur data TS stored in the TOE can be written by authorised nts ip a Document Security Objects can be updated by a le f DS), if the related data have been modified. be activated on the TOE on behalf of the CSP s eSign appli e RP_Card holder had applied for this. ation(s): ePassport, eID, eSign. 118 The current PP also includes all secu tives for the TOE of the ICAO-EAC PP [6]. F onc pli tion. This item conce following applic he following TOE rity objectives add th The TOE must provide means to store Initialisation86 and Pre-Personalisation Data in its non-volatile memory. The Initialisation Data must provide a unique identification of the IC during the manufacturing and the card issuing life cyc This item concerns the following application(s): ePassport, eID, eSign. Personalisation of The TOE must e that the user (amongst other those concerning the RP_Card holder87) and the Personalisation Age F-data permanently only. The Card/Ch nd authorised Personalis The optional eSign app tion Agents (in the ro lication can additionall o y issuing thi This item concerns the following applic cation, if th rity objec ormally, they only c ern the ePassport ap ca Objective identifier from [6] Equivalent to / covered by item in the current PP Comments OT.AC_Pers OT.Personalisation - OT.Data_Int OT.Data_Integrity - OT.Sens_Data_Conf OT.Data_Confidentiality DG3 and DG4 in the ePassport application are part of the User Data in the sense of the current PP. OT.Identification OT.Identification - OT.Chip_Auth_Proof OT.Chip_Auth_Proof - OT.Prot_Abuse-Func - OT.Prot_Abuse-Func 86 amongst other, IC Identification data 87 biographical and biometrical data as well as the SCD, if the eSign is operational. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 46 of 133 Bundesamt für Sicherheit in der Informationstechnik Objective identifier from [6] Equivalent to / covered by item in the current PP Comments OT.Prot_Inf_Leak .Prot_Inf_Leak OT - OT.Prot_Phys-Tamper OT.Prot_Phys-Tamper - OT.Prot_Malfunction OT.Prot_Malfunction - Table 13: TOE objectives taken over from [6] 119 The current PP also includes all security objectives for the TOE of the PACE-Pass PP [7]. F only concern the ePassport application. ormally, they Objective identifier from [7] Equivalent to / covered by item in the current PP Comments OT.Data_Integrity OT.Data_Integrity - OT.Data_Authenticity ity OT.Data_Authentic - OT.Data_Confidentiality OT.Data_Confidentiality - OT.Tracing OT.Tracing - OT.Prot_Abuse-Func OT.Prot_Abuse-Func - OT.Prot_Inf_Leak OT.Prot_Inf_Leak - OT.Prot_Phys-Tamper OT.Prot_Phys-Tamper - OT.Prot_Malfunction OT.Prot_Malfunction - OT.Identification OT.Identification - OT.Personalisation OT.Personalisation - Table 14: TOE objectives taken over from [7] 120 T a on is operational. Formally, they only concern the eSign a he current PP also includes all security objectives for the TOE of the SSCD PP [8]. These items re applicable, if the eSign applicati pplication. Objective identifier from [8] Equivalent to / covered by item in the current PP Comments OT.Lifecycle_Security - - OT.SCD/SVD_Gen - - Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 47 of 133 Objective identifier from [8] Equivalent to / covered by item in the current PP Comments OT.SCD_Unique - - OT.SCD_SVD_Corresp - - OT.SCD_Secrecy OT.Data_Con (partially) confidentiality of the SCD at storage. Additionally, generation, signing and destruction concerning SCD are addressed by OT.SCD_Secrecy. fidentiality OT.Data_Confidentiality covers the OT.Sig_Secure - - OT.Sigy_SigF - - OT.DTBS_Integrity_TO OT.Data_Integrity - E OT.EMSEC_Design OT.Prot_Inf_Leak - OT.Tamper_ID OT.Prot_Phys-Tamper OT.Prot_Malfunction - OT.Tamper_Resistance OT.Prot_Phys-Tamper - T 4.2 t I. 121 T im 122 O minals complying with This item concerns the following application(s): ePassport, eID. II. RP_Card Issuer and CSCA: RP_Card’s PKI (issuing) branch 123 The RP_Card Issuer and the related CSCA will implement the following security objectives for the TOE environment (see also the Application Note 35 above): rd by Signature able 15: TOE objectives taken over from [8] Security Objectives for Operational Environmen RP_Card Issuer as the general responsible he RP_Card Issuer as the general responsible for the global security policy related will plement the following security objectives for the TOE environment: E.Legislative_Compliance The RP_Card Issuer must issue the RP_Cards and approve using the ter all applicable laws and regulations. 124 OE.Passive_Auth_Sign Authentication of RP_Ca Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 48 of 133 Bundesamt für Sicherheit in der Informationstechnik The RP_Card Issuer has to establish the necessary public key infrastructure as follows: the CSCA acting on behalf and according to the policy of the RP_Card Issuer must (i) generate a ocument Signer Certificates (CDS) available to the RP_Card Issuer, who makes them available to his own (domestic) CVCA as nd integrity of these certificates are being maintained. 125 O 126 O the biographical data for the RP_Card89, (ii) enrol the biometric reference data of the RP_Card holder90, (iii) write a subset alisation) and store them in the RP_Card (electronic personalisation) for the RP_Card holder as defined in [12], (iv) write This item concerns the following application(s): ePassport, eID. cryptographically secure CSCA Key Pair, (ii) ensure the secrecy of the CSCA Private Key and sign Document Signer Certificates in a secure operational environment, and (iii) make the Certificate of the CSCA Public Key (CCSCA) and the D well as to the foreign CVCAs under agreement88. Hereby authenticity a A Document Signer acting in accordance with the CSCA policy must (i) generate a cryptographically secure Document Signing Key Pair, (ii) ensure the secrecy of the Document Signer Private Key, (iii) hand over the Document Signer Public Key to the CSCA for certification, (iv) sign Card/Chip and Document Security Objects of genuine RP_Cards in a secure operational environment only. The digital signature in the Card/Chip Security Object relates to all security information objects according to [12], Appendix A. The CSCA must issue its certificates exclusively to the rightful organisations (DS) and DSs must sign exclusively correct Card/Chip and Document Security Objects having to be stored on RP_Cards. This item concerns the following application(s): ePassport, eID. E.Chip_Auth_Key Chip Authentication Key A Document Signer acting in accordance with the CSCA policy has to (i) generate the RP_Card’s Chip Authentication Key Pair {SKPICC, PKPICC} used for the chip authentication as defined in [12], sec. 4.3, (ii) sign and store the Chip Authentication Public Key in the Chip Authentication Public Key Info (Appendix A of [12]) and (iii) support Service Providers to verify the authenticity of the RP_Card’s chips used for genuine RP_Cards by certification of the Chip Authentication Public Key by means of the Card/Chip Security Object. A Document Signer has also to manage Restricted Identification Key Pairs {SKID, PKID} [12], sec. 2.4 and 4.5: the private Restricted Identification Key SKID is to store in the TOE, whereby the public Restricted Identification Key PKID – in a database of the DS. See also Application note 6 and Table 2, object #1. This item concerns the following application(s): ePassport, eID. E.Personalisation Personalisation of RP_Card The RP_Card Issuer must ensure that the Personalisation Agents acting on his behalf (i) establish the correct identity of the RP_Card holder and create of these data on the physical Residence Permit Card (optical person the document details data, (v) write the initial TSF data, (vi) sign the Card/Chip and Document Security Objects defined in [12] (in the role of a DS). 88 CVCAs represent the roots of receiving branch, see below 89 relevant for the ePassport, the eID and the eSign applications 90 relevant for the ePassport application Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 49 of 133 III. RP_Card Issuer and CVCA: Terminal’s PKI (receiving) branch The RP_Card Issuer and the related domestic CVCA as well as the foreign CVCAs under agreement (with the RP_Card Issuer) 127 128 ary public key infrastructure as follows: the domestic CVCA acting on behalf and according to the policy of the RP_Card Issuer as well as v) distribute Document Verifier Certificates (CDV) back to the respective Document Verifiers. Hereby authenticity and integrity of these certificates are being over the Document Verifier Public Key to the respective CVCA for certification, (iv) sign the Terminal Certificates (C ) of the terminals being managed orisation level of pertained terminals for differentiated data access on the RP_Card. A DV has also to manage Sector’s Static Key Pairs {SK , Authentication Private Keys, (iii) hand over the Terminal Authentication Public Keys {PK } to the DV for certification, (iv) securely use the Terminal efined in [12], sec. 4.4 and (v) install CT, CDV and CCVCA in the rightful terminals operated by him. s exclusively to the rightful organisations (DV) and DVs lusively to the rightful equipment (terminals)95. 129 O c. 3.2. 91 will implement the following security objectives for the TOE environment (see also the Application Note 36 above): OE.Terminal_Authentication Authentication of rightful terminals The RP_Card Issuer has to establish the necess each foreign CVCA acting under agreement with the RP_Card Issuer and according to its policy must (i) generate a cryptographically secure CVCA Key Pair, (ii) ensure the secrecy of the CVCA Private Key and sign Document Verifier Certificates in a secure operational environment, (iii) make the Certificate of the CVCA Public Key (CCVCA) available to the RP_Card Issuer (who make it available to his own CSCA92) as well as to the respective Document Verifiers, (i maintained. A CVCA has also to manage a Revocation Sector Key Pair {SKRevocation, PKRevocation} [12], sec. 2.4 and 4.593. A Document Verifier acting in accordance with the respective CVCA policy must (i) generate a cryptographically secure Document Verifying Key Pair, (ii) ensure the secrecy of the Document Verifying Private Key, (iii) hand T by him in a secure operational environment only, and (v) make CT, CDV and CCVCA available to the respective Service Providers operating the terminals certified. This certificate chain contains, amongst other, the auth SectorNN PKSectorNN} [12], sec. 2.4 and 4.594. A Service Provider participating in this PKI (and, hence, acting in accordance with the policy of the related DV) must (i) generate Terminal Authentication Key Pairs {SKPCD, PKPCD}, (ii) ensure the secrecy of Terminal PCD Authentication Private Keys for the terminal authentication as d CVCAs must issue their certificate must issue their certificates exc This item concerns the following application(s): ePassport, eID. E.Terminal Terminal operating The Service Providers participating in the current PKI (and, hence, acting in accordance with the policy of the related DV) must operate their terminals as follows: 1) They use their terminals (BIS-PACE, EIS-AIP-BAC, EIS-GAP, authentication or signature terminals, cf. Table 1 above) as defined in [12], se 91 the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current PP in order to reflect an appropriate relationship between the parties involved. 93 For Restricted Identification please see Application note 6 and Table 2, object #1 ation note 6 and Table 2, object #1. 92 CSCA represents the root of the issuing branch, see above. 94 For Restricted Identification please see Applic 95 This rule is relevant for T.Skimming Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 50 of 133 Bundesamt für Sicherheit in der Informationstechnik 2) Their terminals implement the terminal parts of the PACE protocol [12], sec. 4.2 (for BIS- PACE, EIS-GAP) or the terminal parts of the BAC protocol [12], sec. H (for EIS-AIP- BAC), of the Terminal Authentication protocol [12], sec. 4.4, of the Passive Authentication with SOC [12], sec. 3.4 (by verification of the signature of the Card/Chip ation protoco . 4.396 and of the Passive A cation wi and use them – dependent on the type of terminal – in the order as required by [12], sec. 3.1.1 and 3.2. A rightful terminal uses randomly and rm g ephemeral keys for Diffie- nn). 3) Their terminals securely store the e terminal authentication97 (terminal authenticatio KPCD} and the terminal T) over PK issued by the DV related as well as C and CCVCA; the ific s data stored on the RP_Card) in order to enable and as defined in [12], sec. 4.4. 4) Their terminals securely store the Count ment Signer (in D nd to perform Passive Authentication with SOC ination of the authenticity of PKPICC, .1. nation of the authenticity of the data groups stored in the ePassport, [1 5) Their terminals m gn-PIN, DTBS) to the TOE within the PACE fi y performed the Chip Authentication after the Terminal Authentication . terminals and its environment must rity of respective data handled by it (e.g. confidentiality of PINs/PUKs, CAN and MRZ, integrity of PKI and DTBS, etc.), where it e TOE according to the current PP. This item concerns the following application(s): ePassport, eID. IV. RP_Card holder Obligations 130 OE.Card-Holder RP_Card h er his or her ve UK secret. he RP_Card Holder may reveal, if necessary N and MRZ to an authorised pers inite ons and are trustworthy. This item concerns the following application(s): ePassport, eID. Security Object), of the Chip Authentic uthenti l [12], sec th SOD [12], sec. 1.1 (almost) unifo ly selected nonces, if re Hellma quired by the protocols (for generatin related credentials needed for th n key pair {SKPCD, P certificate (C terminal cert PCD ate includes the authori DV ation mask (CHAT) for access to the to perform the terminal authentication ry Signing Public Key and the Docu Public Key form of CCSCA and C of the RP_Card (determ S) in order to enable a [12], sec. 4.3 2) and SOD (determi 2], sec. 1.1). ust not send assets (e.g. eSi session, but rst having successfull 98 6) Their ensure confidentiality and integ certificates is necessary for a secure operation of th older Obligations The RP_Card Hold T has to keep rification values of eID-PIN and eID-P , his or her verification values of CA ly act according to respective regulati on or device who def 96 The Passive Authentication with SOC is considered to b Protocol within this PP 97 not a ) 98 This le is relevant for T.Skimming e part of the Chip Authentication (CA) pplicable to any BIS (here: BIS-PACE ru Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 51 of 133 131 The current PP also includes all security objectives for the TOE’s environment of the ICAO-EAC PP [6] (please regard the Application note 20). Formally, they only concern the ePassport application. Objective identifier from [6] Equivalent to / covered by item in the current PP Comments OE.MRTD_Manufact ALC_DVS.2, see sec. 6.2 below the assurance family ALC_DVS, if chosen; see also the Such a kind of environmental objectives is always automatically covered by a component of Application note 37 above. OE.MRTD_Delivery ALC_DEL.1, see sec. 6.2 below Application note 37 above. Such a kind of environmental objectives is always automatically covered by a component of the assurance family ALC_DEL, if chosen; see also the OE.Personalization OE.Personalisation - OE.Pass_Auth_Sign OE.Passive_Auth_Sign - OE.Auth_Key_MRTD OE.Chip_Auth_Key - OE.Authoriz_Sens_Dat OE.Terminal_Authenticati - a on OE.BAC_PP - see also the Application note 8 above OE.Exam_MRTD OE.Terminal_Authenticati OE.Terminal .Chip_Auth_Key OE.Terminal_Authentication covers availability of k tificates stored in the inspection system .Chip_Auth_Key covers availability of keys and certificates stored in the TOE. .Terminal covers supporting necessary authentication protocols according to [12]. on OE eys and cer OE OE OE.Passive_Auth_Veri OE.Terminal OE.Passive_Auth_Sign OE.Terminal covers ‘The inspection stems must have successfully verified the signature of Document Security jects and the integrity data elements of the logical MRTD before they are used.’ OE.Passive_Auth_Sign covers ‘The receiving States and Organizations must f sy Ob manage the Country Signing CA Public Key and the Document Signer Public Key maintaining their authenticity and availability in all inspection systems.’ OE.Prot_Logical_MRT OE.Terminal - D Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 52 of 133 Bundesamt für Sicherheit in der Informationstechnik Objective identifier from [6] Equivalent to / covered by item in the current PP Comments OE.Ext_Insp_Systems OE.Terminal_Authentica on ti Organizations authorizes Extended logical MRTD.’ Extended Inspection System authenticates entication Key and its Inspection System Certificate.’ OE.Terminal OE.Terminal_Authentication covers ‘The Document Verifier of receiving States or Inspection Systems by creation of Inspection System Certificates for access to sensitive biometric reference data of the OE.Terminal covers ‘The themselves to the MRTD’s chip for access to the sensitive biometric reference data with its private Terminal Auth Table 16: TOE’s environment objectives take : Applying the approach as describe in the Application note 34 above for tiple for r same conte n over from [6] Application note 45 avoiding mul mal items fo nt and for making the PP easier comprehensible, we explicitly use, where appropriate99, only the items of the current PP, what implicitly includes the related it hic 132 The current PP also includes all security objectives for the TOE’s environment of the PACE-Pass PP [7] (please regard the Application note 2 application. ems from the PP, to w h the conformance claim has been made. 0). Formally, they only concern the ePassport Objective identifier from [7] Equivalent to / covered by item in the current PP Comments OE.Legislative_Compl OE.Legislative_Complianc - iance e OE.Passive_Auth_Sign OE.Passive_Auth_Sign - OE.Personalisation OE.Personalisation - OE.Terminal OE.Terminal - OE.Card-Holder OE.Card-Holder - Table 17: TOE’s environment objectives taken over from [7] 133 Th inclu ectives for the TOE’s environment of the SSCD PP [8] (please regard the Application note 20 and Table 1 above). These items are applicable, if the e tion is operational. Formally, they o e current PP also des all security obj Sign applica nly concern the eSign application. 99 A prerequisite for this is a complete coverage / equivalence of the items in question. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 53 of 133 Objective identifier from [8] Equivalent to / covered by item in the current PP Comments OE.SVD_Auth OE.Passive_Auth_Sign (partially) al (partially) Auth_Sign and OE.Terminal cover ensuring the integrity of the SVD exported by the TOE to the CGA. D in the SSCD of the signatory and the SVD exported, cf. OE.SSCD_Prov_Service. OE.Termin OE.Passive_ Additionally, the CGA shall verify the correspondence between the SC OE.CGA_QCert OE.Personalisation (partially) nalisation covers the correct identity of the Signatory (RP_Card holder). and the advanced signature of the CSP in its certificates. also ensures the property #3 (CSP duties) of P.Trustworthy_PKI OE.Perso Additionally, CGA shall include the SVD matching the SCD stored in the TOE This item OE.SSCD_Prov_Servi ce OT.Chip_Auth_Proof - OE.HID_VAD OE.Terminal - OE.DTBS_Intend OE.Terminal (partially) inal covers enabling verification of the integrity of the DTBS/R by the TOE. y intends to sign, (ii) send the DTBS/R to the TOE and (iii) attach the signature OE.Term Additionally, SCA shall (i) generate the DTBS/R of the data which the signator produced by the TOE to the data. OE.DTBS_Protect OT.Data_Integrity - OE.Signato covers keeping his or her Signatory VAD confidential. Additionally, Signatory has to check that the SCD stored in the SSCD received from SSCD provisioning service is ry OE.Card-Holder (partially) OE.Card-Holder in non-operational state. Table 18: TOE’s environment objectives taken over from [8] 134 As a result of the current section, there are the following security objectives for the TOE environment explicitly resulting from the conformance claims made: Objective identifier from [6], [7] and [8] Equivalent to / covered by item in the current PP Comments OE.BAC_PP - The TOE has also to successfully be evaluated and certified in accordance with [5]. concerns the following application(s): Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 54 of 133 Bundesamt für Sicherheit in der Informationstechnik Objective identifier from [6], [7] and [8] Equivalent to / covered by item in the curr P ent P Comments – ePassport OE.SVD h ) the following application(s) – eSign _Aut OE (pa OE .Pass rtiall .Term ive_A y) inal uth_ (part Sign ially Ad be SV concerns ditio tween D ex nally the porte , CG SCD d. A in shall the S ve SCD rify of t the he si : corr gnato espon ry a denc nd th e e OE.CGA_QCert E.P rso is n art lly) dd on y, GA shall include the SVD ma e CD tor in e E d the ad anc si atu e o P cert cat . nc ns e f ow g a lic io O e nal atio (p ia A iti all C tching th S s ed th TO an v ed gn r f the CS in its ifi es co er th oll in pp at n(s): – eSign OE.DTBS_Intend OE.Termi l (p rtia ) dd n y, SCA shall (i) generate t S ata h th si ato int nds to sign, (ii) send the ii) attach rod ed y t TOE to e d . n(s): eS n na a lly A itio all he DTB /R of the d DTBS/R to the TOE and (i w ich e gn ry e the signature p uc b he th ata concerns the following applicatio – ig OE.Signatory OE.Card-Holder (partially) ly, Signatory s to check that the SCD stored th eived from SSCD provisioning n -op ational state. onc ns e f ow g a lic ion(s): eS n Additiona in l ha e SSCD rec service is in on er c er th oll in pp at – ig Table 19: TOE’s environment objectives effectively resulting from the conformance claims made (a digest of Table 16, Table 17, Table 18) 4.3 Security Objective Rationale 135 The following table provides an overview for security objectives coverage (TOE and its environment) also giving an evidence for sufficiency and necessity of the objectives defined. It shows that all threats and OSPs are addressed by the security objectives. It also shows that all assumptions are addressed by the security objectives for the TOE environment. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 55 of 133 OT.Identification OT.Perso nalisation OT.Data_In tegrity OT.Data_Authenticity OT.Data_ tiality Confiden OT.Tracing OT.Chip of _Auth_Pro OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_ er Phys-Tamp OT.Prot_Malfuntion OE.Perso nalisation OE.Passiv Sign e_Auth_ OE.Chip y _Auth_Ke OE.Termina tication l_Authen OE.Terminal OE.Card-Holder OE.Legislativ liance e_Comp OE.CGA_ ) 100 QCert ([8] T.Skimming x x x x x x T.Eavesdropping x T.Tracing x x T.Counterfeit x x x T.Forgery x x x x x x x T.Abuse-Func x T.Information_Leakage x T.Phys-Tamper x T.Malfunction x P.Pre-Operational x x x x P.Terminal x P.Card_PKI x x P.Terminal_PKI x P.Trustworthy_PKI x x x Table 20: Security Objective Rationale 137 The threat T.Skimming addresses accessing the User Data (stored on the TOE or transferred entication (its property ‘CVCAs must issue their certificates exclusively to the rightful organisations (DV) and ). The b e e end as ntication’). The objective OE.Card-Holder ensures that a PACE session can only be 136 A detailed justification required for suitability of the security objectives to coup with the security problem definition is given below. between the TOE and the Service Provider) using the TOE’s contactless interface. This threat is countered by the security objectives OT.Data_Integrity, OT.Data_Authenticity and OT.Data_Confidentiality through the Terminal- and the Chip Authentication. The objective OE.Terminal_Authentication sets a prerequisite up for an effective terminal auth DV must issue their certificates exclusively to the rightful equipment (terminals)’ o jectiv OE.Terminal sets a prerequisite up that no assets will be transferred between the TOE and th Service Provider before the Chip Authentication has successfully been accomplished (in its property ‘Their (Service Provider’s – remark of the author) terminals must not s sets (e.g. eSign-PIN, DTBS) to the TOE within the PACE session, but first having successfully performed the chip authe 100 This item is applicable, if the eSign application is operational. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 56 of 133 Bundesamt für Sicherheit in der Informationstechnik established either by the RP_Card holder itself or by an authorised person or device, and, hence, cannot be captured by an attacker. 138 The threat T.Eavesdropping addresses listening to the communication between the TOE and a ality through a trusted channel based on the Chip Authentication. mmunication via the contactless interface of the TOE, whereby the attacker does not a priori know the correct values of CAN, MRZ, eID-PIN and eID-PUK). This 140 The threat T.Counterfeit addresses the attack of unauthorised copy or reproduction of the genuine RP_Card. This attack is countered by the chip authenticity proof as aimed by OT.Chip_Auth_Proof using a chip authentication key pair to be generated within the issuing PKI branch as aimed by OE.Chip_Auth_Key. According to OE.Terminal the Service Provider’s terminals has to perform the Chip Authentication Protocol to verify the authenticity of the RP_Card. 141 The threat T.Forgery 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 Service Provider. The security objective OT.Personalisation requires the TOE to limit the write access for the RP_Card to the trustworthy Personalisation Agent (cf. OE.Personalisation). The TOE will protect the integrity and authenticity of the stored and exchanged User Data or/and TSF-data as aimed by the security objectives OT.Data_Integrity and OT.Data_Authenticity, respectively. The objectives OT.Prot_Phys-Tamper and OT.Prot_Abuse-Func contribute to protecting integrity of the User Data or/and TSF-data stored on the TOE. A Service Provider operating his terminals according to OE.Terminal and performing the Passive Authentication using the Card/Chip Security Object as aimed by OE.Passive_Auth_Sign will be able to effectively verify integrity and authenticity of the data received from the TOE. 142 The threat T.Abuse-Func addresses attacks of misusing TOE’s functionality to manipulate or to disclosure the stored User- or TSF-data as well as to disable or to bypass the soft-coded security functionality. The security objective OT.Prot_Abuse-Func ensures that the usage of functions having not to be used in the operational phase is effectively prevented. 143 The threats T.Information_Leakage, T.Phys-Tamper and T.Malfunction are typical for integrated circuits like smart cards under direct attack with high attack potential. The protection of the TOE against these threats is obviously addressed by the directly related security objectives OT.Prot_Inf_Leak, OT.Prot_Phys-Tamper and OT.Prot_Malfunction, respectively. 144 The OSP P.Pre-Operational is enforced by the following security objectives: OT.Identification is affine to the OSP’s property ‘traceability before the operational phase’; OT.Personalisation and OE.Personalisation together enforce the OSP’s properties ‘correctness of the User- and the TSF-data stored’ and ‘authorisation of Personalisation Agents’; OE.Legislative_Compliance is affine to the OSP’s property ‘compliance with laws and regulations’. 145 The OSP P.Terminal is obviously enforced by the objective OE.Terminal, whereby the one-to- one mapping between the related properties is applicable. rightful terminal in order to gain the User Data transferred there. This threat is countered by the security objective OT.Data_Confidenti 139 The threat T.Tracing addresses gathering TOE tracing data identifying it remotely by establishing or listening to a co threat is directly countered by security objectives OT.Tracing (no gathering TOE tracing data) and OE.Card-Holder (the attacker does not a priori know the correct values of the shared passwords). Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 57 of 133 146 The OSP P.Card_PKI is enforced by establishing objectives OE.Passive_Auth_Sign (for the Card/Chi the issuing PKI branch as aimed by the p Security Object) and OE.Chip_Auth_Key erminal_PKI is enforced by establishing the receiving PKI branch as aimed by the objective OE.Terminal_Authentication. E.Passive_Auth_Sign (for CSCA, issuing PKI CVCA, receiving PKI branch) and by (for managing the RP_Card’s Chip Authentication Key Pairs). 147 The OSP P.T 148 The OSP P.Trustworthy_PKI is enforced by O branch), by OE.Terminal_Authentication (for OE.CGA_QCert (see [8]). 149 The rationale related to the security objectives taken over from [6], [7] and [8] are exactly the same as given for the respective items of the security policies definitions in sec. 4.3 of [6], sec. 4.3 of [7] and sec. 8.4 of [8], respectively. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 5 Extended Components Definition 150 This protection profile uses components defined as extensions to CC part 2. They are drawn [6] and [7]. from 5.1 e Family FAU_SAS 151 To d FAU is family describes the functional requirements for the storage of audit data. It has a more general approach than FAU_GEN, because it does not n ta to be generated by the TOE itself and because it does not give specific details of the content of the audit records. 152 The family ‘Audit data storage (FAU_SAS)’ is specified as follows: dit da This family defines fu Definition of th escribe the security functional requirements of the TOE, the family FAU_SAS of the class (Security audit) is defined here. Th ecessarily require the da FAU_SAS Au ta storage Family behaviour nctional requirements for the storage of audit data. Component levelling FAU_SAS 1 Audit data storage lity to store audit data. M udit: There are no actions defined to be auditable. e the IT security functional requirements of the TOE, the family FCS_RND of the class FCS (Cry mily describes the functional requirements fo raphic purposes. The component FCS_RND.1 is FAU_SAS.1 Requires the TOE to provide the possibi anagement: FAU_SAS.1 There are no management activities foreseen. FAU_SAS.1 A FAU_SAS.1 Audit storage Hierarchical to: No other components Dependencies: No dependencies FAU_SAS.1.1 The TSF shall provide [assignment: authorised users] with the capability to store [assignment: list of audit information] in the audit records. 5.2 Definition of the Family FCS_RND 153 To describ ptographic support) is defined here. This fa r random number generation used for cryptog page 58 of 133 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 n tion of cryptographic keys unlike the component FCS_CKM.1. The similar component FIA_SOS.2 is intended for non-cryptographic use. 154 The ND)’ is specified as follows: of random numbers Family behaviour ily defines quality requirements for th ration of random numbers intended to ot limited to genera family ‘Generation of random numbers (FCS_R FCS_RND Generation This fam e gene be used for cryptographic purposes. Component levelling: FCS_RND Generation of random numbers 1 FCS_RND.1 Generation of random numbers requires that random numbers meet a Management: FC es foreseen. Audit: FCS_RND.1 tions defined to be FCS_RND.1 Hierarchical to: No other components chanism to generate random numbers that meet [assignment: a defined quality metric]. f the class FIA (Identification and authentication) is defined here. This family describes the functional re e authentication verification by an external entity, where the other families of the class FIA address the verification of the identity of an e 156 App of u its o Crit (cf. [3], chapter ‘Extended components definition (APE_ECD)’) from a TOE point of view. FIA_API Authentication Proof of Identity defined quality metric. S_RND.1 There are no management activiti There are no ac auditable. Quality metric for random numbers Dependencies: No dependencies FCS_RND.1.1 The TSF shall provide a me 5.3 Definition of the Family FIA_API 155 To describe the IT security functional requirements of the TOE, the family FIA_API o quirements for proof of the claimed identity for th xternal entity. lication note 46: Other families of the class FIA describe only the authentication verification ser’s identity performed by the TOE and do not describe the functionality of the TOE to prove wn identity. The following paragraph defines the family FIA_API in the style of the Common eria part 2 Bundesamt für Sicherheit in der Informationstechnik page 59 of 133 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Family behaviour This family defines functions provided by the TOE to prove its identity and to be verified by an external entity in the TOE IT environment. elling Component lev : FI 1 A_API Authentication Proof of Identity Management: The following actions could be considered for the management of authentication information used to prove the claimed identity. Audit: FIA_API.1 There are no actions defined to be auditable. FIA_API.1 Authentication Proof of Identity Hierarchical to: No other components nt: authentication mechanism] to 5.4 efinition of the Family FMT_LIM 157 The fa ments for the test features of the TOE. The ne uir n the class FMT because this class addresses the ma ctio mechanism used in the TOE sh r cl specific issues of preventing abuse of fu ng th 158 The family ‘Limited ca MT_LIM Limited capabilities and availability s in a combined manner. Note, that FDP_ACF restricts access to functions whereas the Limited m FIA_API.1 Authentication Proof of Identity. FIA_API.1 functions in FMT: Management Dependencies: No dependencies FIA_API.1.1 The TSF shall provide a [assignme prove the identity of the [assignment: authorised user or role]. D mily FMT_LIM describes the functional require w functional req nagement of fun ements were defined i ns of the TSF. The examples of the technical ass is appropriate to address the ow that no othe nctions by limiti e capabilities of the functions and by limiting their availability. pabilities and availability (FMT_LIM)’ is specified as follows: F Family behaviour This family defines requirements that limit the capabilities and availability of function capability of this family requires the functions themselves to be designed in a specific anner. Component levelling: page 60 of 133 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 FMT_LIM Limited capabilities and availability 1 2 SF is built to provide only the ther information) necessary for its genuine purpose. . 1, FMT_LIM.2 There are no actions defined to be auditable. FM o 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 t: Limited capability and availability policy]. FMT_LIM.2 Limited availability Hierarchical to: abilities in a manner that limits their availability so that in IM.1)’ the following polic availability 159 Application note 47: The functional requirements FMT_LIM.1 and FMT_LIM.2 assume e capabilities and limited availability) which together shall provide protection in order to enforce the related policy. This also allows that ( rov ns in the product in its user environment, but its re so licy is enforced or conversely FMT_LIM.1 Limited capabilities requires that the T capabilities (perform action, ga FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions (refer to Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by removing or by disabling functions in a specific phase of the TOE’s life-cycle. Management: FMT_LIM.1, FMT_LIM.2 There are no management activities foreseen Audit: FMT_LIM. T_LIM.1 Limited capabilities Hierarchical to: N following policy is enforced [assignmen No other components Dependencies: FMT_LIM.1 Limited cap FMT_LIM.2.1 The TSF shall be designed conjunction with ‘Limited capabilities (FMT_L y is enforced [assignment: Limited capability and policy]. xistence of two types of mechanisms (limited i) the TSF is p capabilities a ided without restri limited that the po ctio Bundesamt für Sicherheit in der Informationstechnik page 61 of 133 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 ( n its nt The combination of both the require 5.5 Definition of the Family FPT_EMSEC 160 The family FPT_EMSEC (TOE Emanation) of the class FPT (Protection of the TSF) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against secret data stored in and used by the TOE where the attack is based on external observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This family describes the functional requirements for the limitation of intelligible emanations being not directly addressed by any other component of CC part 2 [2]. 161 The family ‘TOE Emanation (FPT_EMSEC)’ is specified as follows: FPT_EMSEC TOE emanation Family behaviour This family defines requirements to mitigate intelligible emanations. Component levelling: ii) the TSF is desig user environme ed with high functionality, but is removed or disabled in the product in . ments shall enforce the related policy. FPT_EMSEC TOE emanation 1 FPT_EMSEC.1 TOE emanation has two constituents: FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF data or user data. FPT_EMSEC.1.2 Interface Emanation requires to not emit interface emanation enabling access to TSF data or user data. Management: FPT_EMSEC.1 There are no management activities foreseen. Audit: FPT_EMSEC.1 There are no actions defined to be auditable. FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components Dependencies: No dependencies FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. page 62 of 133 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 63 of 133 FPT_EMSEC.1.2 The TSF shall following inte ensure [assignment: type of users] are unable to use the rface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 64 of 133 Bundesamt für Sicherheit in der Informationstechnik 6 Secur 162 This part of the PP defines the detailed securi that shall be satisfied by the TOE. The statement of TOE security requirements urity requirements that the TOE needs to satisfy in o 163 The CC allows several operations to be perfo component level); refinement, selection, assignment and i f Part 1 [1] of the CC. Each of these operations is used in this PP 164 The refinement operation is used to add det ts a r requirem rds a re crosse ity Requirements ty requirements shall define the functional and assurance sec rder to meet the security objectives for the TOE. rmed on security requirements (on the teration are defined in sec. 8.1 o . ail to a requirement, and, thus, further restric equirement. Refinements of security re in bold text and removed words a ents are denoted in such a way that added wo d out. 165 T n operation is used to select one ng a requirement. Selections having been made b P author are denoted as underlined text he selectio or more options provided by the CC in stati y the P . Selections to be filled in by the ST author appear in square brackets with an indication that a selection is to be made, [selection:], and are ita 166 The assignment operation is used to assign a such as the length of a password. Assignments havi ted by showing as underlined text licised. specific value to an unspecified parameter, ng been made by the PP author are deno . Assignments to r appear in square brackets with an indication that an assignmen ent:], and are italicised. In some cases the assignment made by the PP au to be performed by the ST author. Thus this text is underlined and italicis be filled in by the ST autho t is to be made [assignm thors defines a selection ed like this. 167 The iteration operation is used when a compo is denoted by showing a slash “/”, and the itera For the sake of a better readability, the iteration operation may also be applied to some single components (being not nent is repeated with varying operations. Iteration tion indicator after the component identifier. repeated) in order to indicate belonging of such SFRs to same functional cluster. In such a case, the iteration operation i ent. 168 In order to distinguish between the SFRs taken aimed to be conformant, and other SFRs having the sa SFRs by - ‘/ICAO-EAC’ or ‘/XXX_ICAO-EAC’ for the - ‘/PACE-Pass’ or ‘/XXX_PACE_Pass’ for the - ‘/SSCD’ or ‘/XXX_SSCD’ for the SSCD PP 6.1 nt 6.1.1 Overview 169 In order to give an overview of the security fu ents in the context of the security services offered by the TOE, the author of the PP defined the security functional groups and allocated the functional requirements described s applied to only one single compon over from the PPs, to which this PP is cl me denotation, the author iterated these ICAO-EAC PP [6], PACE-Pass PP [7], and [8]. Security Functional Requireme s for the TOE nctional requirem in the following sections to them: Security Functional Groups Security Functional Requirements concerned Access control to the User Data stored in the TOE M} – {FDP_ACC.1/TRM, FDP_ACF.1/TR Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 65 of 133 Security Functional Groups Security Functional Requirements concerned Supported by: – FIA_UAU.1/Rightful_Terminal: Terminal GAP, ATT, SGT) Authentication (BIS-PACE, EIS- – FIA_UAU.1/ICAO-EAC: Terminal Authentication (EIS-AIP-BAC) {FDP_ACC.1/Signature-creation_SFP_SSCD, – FDP_ACF.1/Signature-creation_SFP_SSCD} Secure data exchange between the RP_Card and the Service Provider connected C: MAC _Terminal: Terminal uthentication (BIS-PACE, EIS-GAP, ATT, SGT) _ICAO-EAC: MAC eneration/verification AO-EAC: Chip – FTP_ITC.1/CA: trusted channel for EIS-AIP- BAC, EIS-GAP, ATT, SGT – FTP_ITC.1/PACE: trusted channel for BIS- PACE Supported by: a) for GAP: – FCS_COP.1/AES: encryption/decryption – FCS_COP.1/CMA generation/verification – FIA_API.1/CA: Chip Identification/Authentication (version 2) – FIA_UAU.1/Rightful A b) for AIP: – FCS_COP.1/SYM_ICAO-EAC: encryption/decryption – FCS_COP.1/MAC g – FIA_API.1/IC Identification/Authentication (version 1) – FIA_UAU.1/ICAO-EAC: Terminal Authentication (EIS-AIP-BAC) Identification and authentication of users and components BIS-PACE) cation (PCT – FIA_UID.1/PACE: PACE Identification (PCT equiv. – FIA_UID.1/Rightful_Terminal: Terminal Identification (EIS-GAP, ATT, SGT) – FIA_UID.1/ICAO-EAC: Terminal Identification (EIS-AIP-BAC) – FIA_UAU.1/PACE: PACE Authenti equiv. BIS-PACE) FIA_UAU.1/Rightful_Terminal: Terminal – Authentication (EIS-GAP, ATT, SGT) – FIA_API.1/CA: Chip Identification / Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 66 of 133 Bundesamt für Sicherheit in der Informationstechnik Security Functional Groups Security Functional Requirements concerned Authentication for GAP (version 2) FIA_UAU.1/ICAO-EAC: Terminal r AIP (version 1) A_PACE-Pass: Passive using SO (with previous entication of Terminal _Suspending ful PACE communication using non-blocking authentication SCD: Identification of RP_Card Card tory (eSign-PIN) locking of the Signatory’s FCS_CKM.1/DH_PACE: PACE authentication : Terminal T) – FCS_CKM.1/DH_CA: Chip Authentication – FCS_CKM.4: session keys destruction (authentication expiration) HA: Keys derivation – FTP_ITC.1/PACE: preventing tracing while – Authentication (EIS-AIP-BAC) – FIA_API.1/ICAO-EAC: Chip entification/Authentication fo Id – FIA_APO.1/P Authentication D FIA_UAU.1/PACE => BIS-PACE) – FIA_UAU.4: single-use of authentication data – FIA_UAU.5: multiple authentication mechanisms Re-auth – FIA_UAU.6: IA_AFL.1/eID-PIN – F – FIA_AFL.1/eID-PIN_Blocking: reaction to unsuccessful authentication attempts for establishing PACE communication using blocking authentication data – FIA_AFL.1/PACE: reaction to unsuccess authentication attempts for establishing and authorisation data – FIA_UID.1/S holder as Signatory (eSign-PIN) – FIA_UIA.1/SSCD: Authentication of RP_ holder as Signa – FIA_AFL.1/SSCD: B RAD (eSign-PIN) Supported by: – (PCT) – FCS_COP.1/SIG_VER Authentication (EIS-AIP-BAC, EIS-GAP, ATT, SG – FCS_CKM.2/DH: Diffie-Hellmann key distribution within PACE and Chip Authentication – FCS_COP.1/S – FCS_RND.1: random numbers generation Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 67 of 133 Se unctional Groups curity F Security Fu al Requirements concerned nction establishing Chip Authentication – FMT_SMR.1: security roles definition. Audit – FAU_SAS.1 : Audit storage Supported by: – FMT_MTD.1/INI_ENA: Writing Initialisation and Pre-personalisation – FMT_MTD.1/INI_DIS: Disabling access to Initialisation and Pre-personalisation Data in the operational phase Generation of the Signature the eSign application – Key Pair for – FCS_CKM.1/SSCD Supported by: – FCS_CKM.4/SSCD {FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD, FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD} – {FDP_ACC.1/SVD_Transfer_SFP_SSCD, FDP_ACF.1/SVD_Transfer_SFP_SSCD} Creation of Electronic Signa eSign application tures by the – FCS_COP.1/SSCD Management of an TSF-data d access to TSF and – The entire class FMT. Supported by: – the entire class FIA: user identification / authentication Accuracy of the TOE security functionality – The entire class FPT / Self-protection – FDP_RIP.1: enforced memory/storage cleaning – FDP_SDI.2/Persistent_SSCD – FDP_SDI.2/DTBS_SSCD Supported by: – the entire class FMT. Table 21: Security functiona 170 T ovides security policy defined in the l groups vs. SFRs he following table pr an overview of the keys and certificates used for enforcing the current PP: Name Data Receiving PKI branch Country Verifying Certification Authority Private Key (SKCVCA) CVCA i The Country Verifying Certification Authority (CVCA) holds a private key (SK ) used for signing the Document Verifier Certif cates. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 68 of 133 Bundesamt für Sicherheit in der Informationstechnik Name Data Country Verifying Certification Authority stores the Country Verifying Certification Authority Public Key part of the TSF-data to verify the Public Key (PKCVCA) The TOE (PKCVCA) as Document Verifier Certificates. Country Verify Certification A ing uthority Certificate (CCVCA) ation Authority Public The Country Verifying Certification Authority Certificate may be a self-signed certificate or a link certificate (cf. [12] and Glossary). It contains (i) the Country Verifying Certific Key (PKCVCA) as authentication reference data, (ii) the coded access control rights of the Country Verifying Certification Authority, (iii) the Certificate Effective Date and the Certificate Expiration Date as security attributes. Document Verifier Certificate (CDV) fier Certificate CDV is issued by the Country Verifying ority. It contains (i) the Document The Document Veri Certification Auth Verifier Public Key (PKDV) as authentication reference data (ii) an 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. Terminal Certificate (CT) . It c Key (PK ) as authentication The ed by the Document Verifier Terminal Certificate (CT) is issu ontains (i) the Terminal Public PCD reference data, (ii) the coded access control rights of the terminal (EIS-AIP-BAC, EIS-GAP, ATT, SGT), the Certificate Effective Date and the Certificate Expiration Date as security attributes. Issuing PKI branch Country Signing Certification Authority Key Pair and Certificate t Signer Public Key Certificate (CDS) with the CSCA Country Signing Certification Authority of the RP_Card Issuer signs the Documen Country Signing Certification Authority Private Key (SKCSCA) and the signature will be verified by receiving terminal with the Country Signing Certification Authority Public Key (PK ). The CSCA also issues the self-signed CSCA Certificate (CCSCA) having to be distributed by strictly secure diplomatic means, see. [9], 5.1.1. Document Signer Key The Docum ificate CDS is issued by the Country of the ePassport application with the Document Pairs and Certificates ent Signer Cert Signing Certification Authority. It contains the Document Signer Public Key (PKDS) as authentication reference data. The Document Signer acting under the policy of the CSCA signs the Card/Chip Security Object (SOC) of the RP_Card and the Document Security Object (SOD) Signer Private Key (SKDS) and the signature will be verified by a terminal as the Passive Authentication with the Document Signer Public Key (PKDS). Chip Authentication Public Key (PKPICC) Authentication. Its authenticity is verified by the inal in the context of the Passive Authentication (verification of SOC). PKPICC is stored in an EF on the RP_Card and used by the terminal for the Chip term Chip Authentication Private Key (SKPICC) The static Chip Authentication Key Pair {SKPICC, PKPICC} is used for Key Agreement Protocol: Diffie-Hellman (DH) according to PKCS#3 or Elliptic Curve Diffie-Hellman (ECDH; ECKA key agreement algorithm) according to TR-03111 [14], cf. [12], table. SKPICC is used by the TOE to authenticate itself as authentic A.2. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 69 of 133 Name Data RP_Card. Session keys PACE Session Keys (PACE-KMAC, Secure messaging AES keys for message authentication (CMAC-mode) and for message encryption (CBC-mode) agreed PACE-KEnc) between the TOE and a terminal (PCT101) as result of the PACE Protocol, see [12], sec. A.3, F.2.2, A.2.3.2. Chip Authentication -KM s for message authentication nd for message encryption (CBC-mode) agreed and a terminal (EIS-AIP-BAC, EIS-GAP, ATT, Protoc l, see [12], sec. Session Keys (CA CA-K ) AC, (CMAC-mode) a between the TOE Enc Secure messaging AES key SGT) as result of the Chip Authentication o A.4, F.2.2, A.2.3.2. Ephemeral keys PACE authentica ephemeral key pair tion (ephem-SKPICC-PACE ephem-PKPICC-PACE) #3 or t , The ephemeral PACE Authentication Key Pair {ephem-SKPICC-PACE, ephem-PKPICC-PACE } is used for Key Agreement Protocol: Diffie-Hellman (DH) according to PKCS Elliptic Curve Diffie-Hellman (ECDH; ECKA key agreemen algorithm) according to TR-03111 [14], cf. [12], table. A.2. Restricted Identification keys Restricted Identification Static Diffie-Hellman key pair, whereby the related private key eneration of the sector- dentification please also refer to the Application Key Pair {SKID, PKID} SKID is stored in the TOE and used for g specific chip-identifier ID I (pseudo-anonymisation), see [12], sec. 4.1.3.1 and Table 4.1, 4.5.1. This key represents user data within the current security policy, cf. Table 2, object #1. The belonging public key PKID is used for a revocation request and should not be stored in the TOE, see [12], sec. 4.1.3.1 and Table 4.1, 4.5.3. For Restricted I Sector note 6. Signature keys Signature Creation Key } Signature Creation Data (SCD) is represented by a private being used by the RP_Card holder (signatory) to represents user data (Table lic e Pair {SCD, SVD cryptographic key create an electronic signature. This key 2, object #1). Signature Verification Data (SVD) is represented by a pub cryptographic key corresponding with SCD and being used for th purpose of verifying an electronic signature. Properties of this key pair shall fulfil the relevant requirements stated in [17]. Table 22: Keys and Certificates 101 From the point of view of the terminal’s rights, there is no difference beween PCT and BIS-PACE, cf. glossary Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 70 of 133 Bundesamt für Sicherheit in der Informationstechnik 6.1.2 Class FCS Crypto 6.1.2.1 FCS_COP.1 Cryptographic operation]: fulfilled by FCS_CKM.2/DH. FC KM.4 cryptographic keys in accordance with a specified ellman- graphic Support Cryptographic key generation (FCS_CKM.1) 171 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 S_CKM.4 Cryptographic key destruction: fulfilled by FCS_C FCS_CKM.1.1 The TSF shall generate cryptographic key generation algorithm [selection: Diffie-H Protocol compliant to PKCS#3, ECDH compliant to [14]]102 ment: cry and ptographic key sizes] specified cryptographic key sizes [assign that meet the following: [12], Appendix A.3 103. ation(s): ePassport, eID, eSign. This item concerns the following applic 172 Application note 48: e PACE protocol, see ll Protocol compliant to PKCS#3 (i.e. modulo arithmetic based cryptographic algorithm, cf. [19]) ptographic algorithm ret value K is used for AES ses required by FCS_COP.1/AES and FCS_COP.1/CMAC. 173 H_CA r Chip Hierarchical to: M.4 CS_CKM.1.1 phic keys in accordance with a specified cryptographic key generation algorithm [selection: Diffie-Hellman- The TOE generates a shared secret value K with the terminal during th [12], sec. 4.2 and A.3. This protocol may be based on the Diffie-He man- or on the ECDH compliant to TR-03111 [14] (i.e. the elliptic curve cry ECKA, cf. [12], Appendix A.3 and [14] for details). The shared sec deriving the sion keys for message encryption and message authentication (PACE-KMAC, PACE-KEnc) according to [12], F.2.2 and A.2.3.2 for the TSF FCS_CKM.1/D Cryptographic key generation – Diffie-Hellman fo Authentication session keys No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation]: fulfilled by FCS_CKM.2/DH. FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CK The TSF shall generate cryptogra F Protocol compliant to PKCS#3, ECDH compliant to [14]]104 and yptographic key sizes] specified cryptographic key sizes [assignment: cr generation algorithm] generation algorithm] 102 [assignment: cryptographic key 103 [assignment: list of standards] 104 [assignment: cryptographic key Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 71 of 133 that meet the following: [12], Annex A.4 105. This item concerns the following application(s): ePassport, eID, eSign. 174 Application note 49: The TOE generates a shared secret value with the terminal during the CA Protocol, see [12], sec. 4.3 and A.4. This protocol may be based on the Diffie-Hellman-Protocol d cryptographic algorithm, cf. [19]) or on the liptic curve cryptography algorithm, cf. [12], Appendix A.4 and [14] for details). The shared secret value is used to derive the AES session keys for message encryption and message authentication (CA-KMAC, CA-KEnc) according to the .3.2 for . 175 hic key distribution – Diffie-Hellman Dependencies: FCS_CKM.2.1 with a st compliant to PKCS#3 (i.e. modulo arithmetic base ECDH compliant to TR-03111 [14] (i.e. an el [12], F.2.2 and A.2 the TSF required by FCS_COP.1/AES and FCS_COP.1/CMAC FCS_CKM.2/DH Cryptograp Hierarchical to: No other components. [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]: fulfilled by FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4: fulfilled by FCS_CKM.4 The TSF shall distribute cryptographic keys in accordance specified cryptographic key distribution method as specified in the li below106 that meets the following: a) PACE: as specified in [12], sec. 4.2 and A.3; b) CA: as specified in [12], sec. 4.3 (version 2 (for GAP)) and A.4107. This item concerns the following application(s): ePassport, eID, eSign. 176 FCS_CKM.4 Cryptographic key destruction – Session keys Hierarchical to: No other components. that meets the following: [assignment: list of standards]. This item concerns the following application(s): ePassport, eID, eSign. 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.1/DH_CA FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: cryptographic key destruction method] to 107 105 [assignment: list of standards] 106 [assignment: cryp graphic key distribution method] [assignment: list of standards] Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 72 of 133 Bundesamt für Sicherheit in der Informationstechnik 177 Application note 50: Th PACE session keys (i) after detection of an error in a received command by verification of the MAC, and (ii) after succe Chip A otocol error in a received command by session keys before star s required by FDP_RIP.1. 6.1.2.2 Cryptographic 178 FCS_COP.1/SHA Hierarchical to: Dependencies: without security attributes, or FCS_CKM.4 Cryptographic key destruction: not fulfilled, but justified ey; hence, a e. FCS_COP.1.1 The TSF shall perform hashing e TOE shall destroy the ssful run of the . The TOE shall destroy the CA session keys after detection of an verification of the MAC. The TOE shall clear the memory area of any ting the communication with the terminal in a new after-reset-session a uthentication Pr operation (FCS_COP.1) Cryptographic operation – Hash for key derivation No other components. [FDP_ITC.1 Import of user data FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: not fulfilled, but justified A hash function does not use any cryptographic key; hence, neither a respective key import nor key generation can be expected here. A hash function does not use any cryptographic k respective key destruction cannot be expected her 108 in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes none 109 that meet the following: FIPS 180-2 [21]110. This item concerns the following application(s): ePassport, eID, eSign. 179 Application note 51: ompressing (hashing) an ephemeral public key for DH (PACE and CA112), the hash fun HA-1 shall be used ([12], table A.2). For c 111 ction S The TOE shall implement hash functions either SHA-1 or SHA-224 or SHA-256 for the Terminal A toco nd A.14). W tive 2] states that the hash tion A-256 – for deriving 192-bit an 180 FCS_COP.1/SIG_VER uthentication Pro l (cf. [12], tables A.13 a ithin the norma func Appendix A of [12], section A.2.3 ‘Key Derivation Function’, [1 SHA-1 shall be used for deriving 128-bit AES keys, whereas SH d 256-bit AES keys. Cryptographic operation – Signature verification 108 [assignment: list of cryptographic operations] 109 [assignment: cryptographic key sizes] 110 [assignment: list of standards] 111 IDPICC ≡ Comp(ephem-PKPICC-PACE) in [12], sec. 4.4; the public key compression function is defined in table A.2 of [12]. ublic key [12]. 112 Comp(ephem-PK -TA) in [12], sec. 4.3.1 (version 1 for AIP, version 2 for GAP); the p PCD compression function is defined in table A.2 of Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 73 of 133 Hierarchical to: Dependencies: The root key PKCVCA used for verifying CDV is stored in the TOE cycle phase)113. Since T DV y special security measures except those required by the current SFR (cf. No other components. [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]: not fulfilled, but justified during its personalisation (in the card issuing life importing the respective certificates (C , C ) does not require an FMT_MTD.3 below), the current PP does not contain any dedicated requirement like FDP_ITC.2 for the import function. FCS_CKM.4 Cryptographic key destruction: not fulfilled, but justified Cryptographic keys used for the purpose of the current SFR (PKPCD, PKDV, PKCVCA) are public keys; they do not represent any secret and, hence, needn’t to be destroyed. FCS_COP.1.1 The TSF shall perform digital signature verification 114 in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. 181 A T e ts for e signature algorithms the Terminal Authentication Protoc details). The signature verification is used to verify the card verifiable terminal generated a d tic pu D, PK the TA and are extracted by uring its personalisation (see P.T 182 FCS_COP.1/AES ES No other components. ttributes, 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.1/DH_CA ptographic key destruction: fulfilled by FCS_CKM.4. This item concerns the following application(s): ePassport, eID, eSign. pplication note 52: he ST writer shall perform the missing operation of the assignm n th key lengths and standards implemented by the TOE for ol (cf. [12], Appendix A.6.3, A.6.4 and D.3 for certificates and the authentication attempt of the igital signature for the TOE challenge, see [12], sec. 4.4. The related sta blic keys (PKPC DV) are imported within the respective certificates (CT, CDV) during the TOE using PKCVCA as the root key stored in the TOE d erminal_PKI). Cryptographic operation – Encryption / Decryption A Hierarchical to: Dependencies: [FDP_ITC.1 Import of user data without security a FCS_CKM.4 Cry 113 as already mentioned, operational use of the TOE is explicitly in focus of the current PP ic operations] 114 [assignment: list of cryptograph Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 74 of 133 Bundesamt für Sicherheit in der Informationstechnik FCS_COP.1.1 The TSF shall perform secure messaging – encryption and decryption 115 in accordance with a specified cryptographic algorithm AES in CBC mode 116 and cryptographic key sizes [selection: 128, 192, 256] bit 117 that meet the following: FIPS 197 [18] and [12] Appendix F.2.2118. This item concerns the following application(s): ePassport, eID, eSign. 183 Application note 53: This SFR requires the TOE to implement the cryptographic primitive AES for secure messaging with encryption of transmitted data. The related session keys are agreed between the TOE and the terminal as part of either the PACE protocol according to the uthentication Protocol according to the nce with [12] Appendix F.2.1 and A.2.3.1 the (two-key) Triple-DES could be used in CBC mode for secure messaging. It is also a valid option in the ICAO-EAC PP [6] (see FCS_COP.1/SYM there). Due to the fact that the (two-key) not recomm is applicable only to using EIS-AIP-BAC for reason of compliance with [6] and is also covered by [6]. For all other te ng rrent PP, Triple-DES in any mode is no longer ap this P 184 FCS_COP.1/CMAC ierarchical to: No other components. butes, or utes, or FCS_CKM.1 Cryptographic key generation]: fulfilled by KM.4. FCS_COP.1.1 The TSF shall perform secure messaging – message authentication FCS_CKM.1/DH_PACE (PACE-KEnc) or the Chip A FCS_CKM.1/DH_CA (CA-KEnc). Note that in accorda Triple-DES is ended any more (cf. [13], sec. 1.3), Triple-DES rminal types bei in the scope of the cu plicable within P. Cryptographic operation – CMAC H Dependencies: [FDP_ITC.1 Import of user data without security attri FDP_ITC.2 Import of user data with security attrib FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_C code 119 in accordance with a specified cryptographic algorithm CMAC 120 and cryptographic key sizes [selection: 128, 192, 256] bit 121 that meet the following: ‘The CMAC Mode for Authentication, NIST Special Publication 800-38B’ [20] and ndix F.2.2 [12] Appe 122. s th ion(s ePassport, eID, eSign. This item concern e following applicat ): 115 [assignm togr s] 116 [as hic 117 [assignment: cryptographic key sizes] 118 [as da 119 [assignm list of cryptogr erations] 120 [assignment: cryptographic algorithm] 121 [assignment: cryptographic key sizes] 122 [assignment: list of standards] ent: list of cryp signment: cryptograp aphic operation algorithm] signment: list of stan ent: rds] aphic op Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 75 of 133 185 A T OE to implement the cryptographic primitive for secure messaging with m on 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 DH -KMAC) or the Chip Authentication Protocol according to the FCS_CKM.1/DH_ MAC). Note that in accordance with [12] Appendix F.2.1 and A.2.3.1 the (two-key) Triple-DES could be used . It is also a valid option in the ICAO-EAC PP [6] (see FC AC there). Due to the fact that the (two-key) Triple-DES is not recommended any more (cf. [13], sec. 1.3), Triple-DES is applicable o - omp nce with [6] and is also covered by [6]. For all o l types being in the scope of the current PP, Triple-DES in any mode is no longer applicable within this PP 6.1.2.3 Random Number Generation (FCS_RND.1) 186 FCS_RND.1 Quality metric for random numbers N FCS_RND.1.1 Th a mechanism to generate random numbers that meet [assignment: a defined quality metric]. th lication(s): ePassport, eID, eSign. 187 Application note 55: This SFR requires the TOE to generate random numbers (random nonce) u icat s (PACE, CA and TA) as required by FIA_UAU.4. 188 The current PP also includes all SFRs of the ICAO-EAC PP [6]. Formally, they only concern the ePassport application. For the functional class FCS, there are the following components: pplication note 54: his SFR requires the T essage authenticati the FCS_CKM.1/ _PACE (PACE CA (CA-K in Retail mode for secure messaging S_COP.1/M nly to using EIS-AIP ther termina BAC for reason of c lia . Hierarchical to: No other components. Dependencies: o dependencies. e TSF shall provide This item concerns e following app sed for the authent ion protocol SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FCS_CKM.1/ICAO- EAC FCS_CKM.1/DH_CA - FCS_CKM.4/ICAO- EAC FCS_CKM.4 - FCS_COP.1/SHA_ICA O-EAC FCS_COP.1/SHA - FCS_COP.1/SYM_IC FCS_COP.1/AES FCS_COP.1/AE AO-EAC (partially) S covers only AES. Additionally, /SYM allows Triple-DES. FCS_COP.1 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 76 of 133 Bundesamt für Sicherheit in der Informationstechnik SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FCS_COP.1/MAC_IC AO-EAC S_COP.1/MAC (partially) S_COP.1/MAC covers only AES. ditionally, FCS_COP.1/SYM allows Triple-DES. FC FC Ad FCS_COP.1/SIG_VER _ICAO-EAC FCS_COP.1/SIG_VER - FCS_RND.1/ICAO- EAC FCS_RND.1 - includes all SFRs of the PACE-Pass PP [7]. Formally, they only concern the ePassport application. For the functional class FCS, there are the following components: 189 The current PP also SFR identifier from [7] Equivalent to / covered by item P in the current P Comments FCS_CKM.1/DH_PAC E_PACE-Pass FCS_CKM.1/DH_PACE - FCS_CKM.2/DH_PAC E-Pass FCS_CKM.2/DH - FCS_CKM.4/PACE- Pass FCS_C - KM.4 FCS_COP.1/AES_PA FCS_ CE-Pass COP.1/AES - FCS_COP.1/MAC_PA CE-Pass FCS_COP.1/MAC - FCS_RND. Pass 1/PACE- FCS_RND.1 - 190 The current PP also includes all SFRs of the SSCD PP [8]. These items are applicable, if the eSign y only concern the eSign application. For the f S, t mponents: application is operational. For unctional class FC mally, the here are the following co SFR identifier from [8] Equivalent to / covered by item in the current PP Comments Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 77 of 133 SFR identifier from [8] Equivalent to / covered by item in the current PP Comments FCS_CKM.1/SSCD - - FCS_CKM.4/SSCD - - FCS_COP.1/SSCD - - 6.1.3 enti 191 For the sake of bett ion mechanisms used: Class FIA Id fication and Authentication er readability, Table 23 provides an overview of the authenticat Name SFR for the TOE Comments PACE protocol FIA_AFL.1/eID-PIN_Suspending FCS_CKM.1/DH_PACE FIA_UAU.1/PACE FIA_UAU.5 as required by FIA_AFL.1/eID-PIN_Blocking FIA_AFL.1/PACE Terminal Authentication Protocol version 2 (for GAP) FIA_UAU.1/Rightful_Terminal FIA_UAU.5 as required by FCS_COP.1/SIG_VER Chip Authentication Protocol version 2 (for GAP) FIA_API.1/CA, FIA_UAU.5, as required by FCS_CKM.1/DH_CA FIA_UAU.6 Terminal Authentication FIA_UAU.1/ICAO-EAC inherited from [6] Protocol version 1 (for AIP) FIA_UAU.5/ICAO-EAC Chip Authentication Protocol FIA_API.1/ICAO-EAC, FIA_UAU.5/ICAO-EAC, inherited from [6] version 1 (for AIP) -EAC FIA_UAU.6/ICAO Passive Authentication using FIA_APO.1/PA_P SOD ACE-Pass inherited from [7] eSign-PIN FIA_UAU.1/SSCD inherited from [8] Table 23: Overview of 192 FIA_AFL.1/eID-PIN_Suspending Authentication failure handling – Suspending eID-PIN IA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE when [selection: [assignment: positive integer dministrator configurable positive integer within assignment: range of acceptable values]] unsuccessful authentication pts occur related to consecutive failed authentication attempts using authentication SFRs Hierarchical to: No other components. Dependencies: F FIA_AFL.1.1 The TSF shall detect number], an a [ attem Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 78 of 133 Bundesamt für Sicherheit in der Informationstechnik eID-PIN as the shared password for PACE123. When the defined number of unsuccessful authentication FIA_AFL.1.2 attempts has been met124, the TSF shall suspend the reference value of eID-PIN according to [12], sec. 3.3.2125. ion attempts occur related to consecutive failed authentication attempts using This item concerns the following application(s): eID, eSign. 193 FIA_AFL.1/eID-PIN_Blocking Authentication failure handling – Blocking eID-PIN Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE FIA_AFL.1.1 The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authenticat suspended126 eID-PIN as the shared password for PACE127. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met128, the TSF shall block the reference value of eID-PIN according to [12], sec. 3.3.2129. This item concerns the following application(s): eID, eSign. 56: Acco t value of the retry counter for eID-PIN shall be RC = ue of the retry counter for eID-PIN shall be R val [12]. The assignment shall be consistent with the im entic d resistant against attacks with high attack potential. 195 IA_AFL.1/PACE Authentication failure handling – PACE authentication authorisation data FIA_AFL.1.1 The TSF shall detect when 1 194 Application note rding to [12], sec. 3.3.2, a suspending curren 1, the blocking current val ue of RC is defined in C = 0; no initial plemented auth ation mechanism an F using non-blocking authentication / Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE 130 unsuccessful authentication attempts occurs related to authentication attempts using CAN, MRZ, eID-PUK as shared passwords for PACE131. 123 [assignment: list of authentication events] 124 [selection: met ,surpassed] [assignm 125 ent: list of actions] 126 as required by FIA_AFL.1/eID-PIN_Suspending 127 [assignment: list of authentication events] 128 [selection: met ,surpassed] 129 [assignment: list of actions] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 79 of 133 FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met132, the TSF shall [assignment: list of actions]. This item concerns the following application(s): ePassport, eID, eSign. 196 Application Note 57: The open assignment operation shall be performed according to a concrete implementation of the TOE, whereby actions to be executed mmon for all data concerned (CAN, MRZ, eID-PUK) or for an arbitrary subset of them or may also separately be defined for each datum in question. Since all non-blocking authorisation and authentication data (CAN, MRZ and eID-PUK) being used as a shared secret within the PACE protocol do not possess a sufficient entropy by the TOE may either be co attack134 requiring an attack potential beyond high, so that ng this operation might be ‘consecutively increase the reaction time of the TOE to the next authentication attempt using CAN, MRZ, eID-PUK’. 97 Application Note 58: Please note that since guessing CAN, MRZ and eID-PUK requires an attack KPICC and SOC in the P_ITC.1/PACE), so that it is not essential, whether PKPICC and SO ‘card-generation / batch’ or ‘card-individual’ data are. 198 F ation Proof of Identity Hierarchical to: N t Dependencies: N T 12], 133, 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 the threat T.Tracing135 can be averted in the frame of the security policy of the current PP. One of some opportunities for performi 1 potential beyond high according to the current PP, monitoring the static P context of the chip authentication will also fail (due to FT C IA_API.1/CA Authentic o o her components. o dependencies. FIA_API.1.1 he TSF shall provide the Chip Authentication Protocol according to [ sec. 4.3, version 2 (for GAP) 136 to prove the identity of the TOE 137. This item concerns the following application(s): ePassport, eID, eSign. 199 Application note 59: The Chip Authentication shall be triggered by a rightful terminal immediately after the successful Terminal Authentication (as required 130 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 131 [assignment: list of authentication events] 2 [selection: met ,surpassed] 133 a character string is N*ld(C), racters which can be used within the string. 134 guessing CAN or MRZ or eID-PUK, see T.Skimming above hentication mechanism] 13 ≥ 100 bits; a theoretical maximum of entropy which can be delivered by whereby N is the length of the string, C – the number of different cha 135 Please note that this threat is considered not to be allied with using EIS-AIP-BAC 136 [assignment: aut 137 [assignment: authorised user or role] Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 80 of 133 Bundesamt für Sicherheit in der Informationstechnik F ful_Te st other, Comp(ephem-PKPCD-TA)138 from the acco neness of the RP_Card by verifying the authentication token TPI e RP_Card using ephem-PKPCD-TA and CA-KMAC, (and, hence, finally maki the Chip Authentication Key (SKPICC)). The Passive Authenticati m C by verifying the Card/Chip Security Object (SOC) u ely after the successful Terminal h red to be IA_UAU.1/Right rminal) using, among mplished TA. The terminal verifies genui CC calculated by th ng evident possessing on aking evident authenticity of the PKPIC p to CSCA shall be triggered by the rightful terminal immediat Aut entication before the Chip Authentication139 and is conside part of the CA protocol within this PP (see also P.Terminal). Please note that this SFR does not require authentication of any TOE’s user, but providing evidence enabling an ext If enticatio the de eys (CA g is continued using the p Enc), cf. FTP_ITC.1/PACE. Please note that the Chip Authentication Protocol according to [12], sec. 4.3, version 1 (for AIP) is Dependencies: No dependencies. ernal entity (the terminal connected) to prove the TOE’s identity. the Chip Auth rived session k n was successfully performed, Secure Messaging is restarted using -KMAC, CA-KEnc), cf. FTP_ITC.1/CA. Otherwise, Secure Messagin reviously established session keys (PACE-KMAC, PACE-K covered by [6] (see FIA_API.1 there). 200 FIA_UID.1/PACE Timing of identification Hierarchical to: No other components. FIA_UID.1.1 The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE Protocol according to [12], sec. 4.2140 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. This item concerns the following application(s): ePassport, eID, eSign. User rmed PACE protocol is a PACE terminal (PCT). In case eID-PIN or eID-PUK were used for PACE, it is the RP_Card holder using PCT. Please n nor MRZ effectively represent secrets, but are restricted-rev re used for PACE, it is either the RP_Card ho auth 202 FIA_UID.1/Rightful_Terminal Timing of identification 201 Application note 60: identified after a successfully perfo ote that neither CAN n case CAN or MRZ we ealable; i.e. i lder itself or an orised other person or device. 138 Comp() is public key compression function. It is defined in [12], table A.2 as SHA-1 (for Diffie-Hellmann) 139 cf. [12], sec. 3.4 140 [assignment: list of TSF-mediated actions] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 81 of 133 Hierarchical to: IA_UID.1.1 1. establishing a communication channel, No other components. Dependencies: No dependencies. The TSF shall allow F [12], sec. 4.2, 2. carrying out the PACE protocol according to 3. carrying out the Terminal Authentication Protocol according to [12], sec. 4.4, version 2 (for GAP)141 Passport, eID, eSign. 03 Application note 61: The user identified after a successfully performed TA protocol is a rightful g to [12], sec. 4.4, version 1 (for AIP) is covered by [6] (see FIA_UID.1 there). In this case, the user identified after a successfully pe oco al, namely EIS-AIP-BAC. 204 Application note 62: I turing’ the Manufacturer is the only user role known to the turer writes the Initialisation Data and/or Pre- personalisation Data in Please note that a Person CSCA and DS policies. Hence, they Agents. The TOE mu evaluation within the assu AGD_PRE.1. The TOE assumes the user role ‘Personal inal A el lik 205 F 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. This item concerns the following application(s): e 2 terminal, i.e. for GAP: either EIS-GAP or ATT or SGT. Please note that the Terminal Authentication Protocol accordin rformed TA prot l is also a rightful termin n the life cycle phase ‘Manufac TOE. The Manufac the audit records of the IC. alisation Agent acts on behalf of the RP_Card Issuer under his and define authentication procedure(s) for Personalisation st functionally support these authentication procedures being subject to rance components ALC_DEL.1 and isation Agent’, when a terminal (e.g. ATT) proves the respective Term uthorisation Lev e e.g. a ‘privileged terminal’, cf. [12], sec. C.4.3, Table C.4. IA_UAU.1/PACE Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/PACE FIA_UAU.1.1 The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE Protocol according to [12], sec. 4.2142,143 on behalf of the user to be performed before the user is authenticated. 142 identifies itself within the PACE protocol by selection of the authentication key ephem-PKPICC- 141 [assignment: list of TSF-mediated actions] RP_Card PACE Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 82 of 133 Bundesamt für Sicherheit in der Informationstechnik 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. This item concerns the following application(s): ePassport, eID, eSign. 206 Application note 63: The user authenticated after a successfully performed PACE protocol is a P CT) ID-PUK were used for PACE, it is the RP_Card ho . Ple r CAN nor MRZ effectively represent secrets, but are restricted-rev ho auth If PACE was successfully g the derived session keys (PACE-KMAC, PACE-K ) 207 F nication channel, ACE terminal (P . In case eID-PIN or e lder using PCT ase note that neithe ealable; i.e. i lder itself or an n case CAN or MRZ were used for PACE, it is either the RP_Card orised other person or device. performed, secure messaging is started usin Enc , cf. FTP_ITC.1/PACE. IA_UAU.1/Rightful_Terminal Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/Rightful_Terminal FIA_UAU.1.1 The TSF shall allow 1. establishing a commu 2. carrying out the PACE protocol according to [12], sec. 4.2, 3. carrying out the Terminal Authentication Protocol according to [12], sec. 4.4, version 2 (for GAP)144,145 on is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before al ediated actions on behalf of that user. This item concerns the following application(s): ePassport, eID, eSign. 208 Application note 64: The user authenticated after a successfully performed TA protocol is a Service Provider represented by a rightful terminal, i.e. for GAP: either EIS-GAP or ATT or SGT. The authenticated terminal will immediately perform the Chip Authentication (version 2) as required by FIA_API.1/CA using, amongst other, Comp(ephem-PKPCD-TA) from the accomplished TA. Please note that the Passive Authentication using SOC is considered to be part of the CA protocol within this PP. Please note that the Terminal Authentication Protocol according to [12], sec. 4.4, version 1 (for AIP) is covered by [6] (see FIA_UAU.1 there). In this case, the user authenticated after a behalf of the user to be performed before the user lowing any other TSF-m 143 [assignment: list of TSF-mediated actions] 144 RP_Card identifies itself within the TA protocol by using the identifier IDPICC ≡ Comp(ephem-PKPICC- PACE). 145 [assignment: list of TSF-mediated actions] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 83 of 133 su rmed T rvice Provider, concretely, an inspection system using EIS-AIP-BAC. 209 FIA_UAU.4 e TOE Hierarchical to: No other components. Dependencies: No endencies. FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to 1. ccessfully perfo A protocol is also a Se Single-use authentication of the Terminals by th dep PACE Protocol according to [12], sec. 4.2, erminal Authentication 2. T Protocol according to [12], sec. 4.4, version 2 (for GAP).146 This item concerns the 210 Application note 65: For the ts length being (almost) unifor based on AES; see [12], sec. a nonce rPICC of 64 bits len Please note that the Termina ersion 1 (for AIP) is covered by [6] (see F 211 F s following application(s): ePassport, eID, eSign. PACE protocol, the TOE randomly selects a nonce s of 128 bi mly distributed (the current PP supports the key derivation function A.3.3 and A.2.3). For the TA protocol, the TOE randomly selects gth, see [12], sec. B.3 and B.11.6. l Authentication Protocol according to [12], sec. 4.4, v IA_UAU.4 there). IA_UAU.5 Multiple authentication mechanism Hierarchical to: No other components. Dependencies: No dependencies. 146 [assignment: identified authentication mechanism(s)] Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 84 of 133 Bundesamt für Sicherheit in der Informationstechnik FIA_UAU.5.1 The TSF shall provide entication Procedure as the sequence the General Auth 1. PACE Protocol according to [12], sec. 4.2, 2. Terminal Authentication Protocol according to [12], sec. 4.4, version 2, 3. Chip Authentication Protocol according to [12], sec. 4.3, version 2°147, and 4. Secure messaging in encrypt-then-authenticate mode according to [12], Appendix F 148 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 by means of the Terminal Authentication Protocol, only if (i) the terminal presents its static public key149 being successfully verifiable up to CVCA and (ii) the terminal uses the PICC identifier150 calculated during and the secure messaging established by the current PACE authentication. lly run the Chip Authentication Protocol the TOE 2. Having successfu accepts only received commands with c message orrect authentication code sent by means of secure messaging with the key agreed with the term ation inal by means of the Chip Authentic Protocol.151 s th ollowing application(s 212 Application note 66: Please note that Chip Au col does not authenticate any TOE’s user, but provides evidence enabling an external entity (the terminal connected) to prove th Please note that the Chip Authentication Protoc 1 (for AIP) is covered in this context by [6] (see FIA_UAU.5 there). 213 FIA_UAU.6 Re-authenticating of Terminal by the TOE This item concern e f ): ePassport, eID, eSign. thentication Proto e TOE’s identity. ol according to [12], sec. 4.3, version 147 the Passive Authentication using SOC is considered to b tocol within this PP. [assignment: list of multiple authentication mechanisms] 9 PKPCD 150 IDPICC ≡ Comp(ephem-PKPICC-PACE) provide authentication] e part of the Chip Authentication (CA) Pro 148 14 151 [assignment: rules describing how the multiple authentication mechanisms Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 85 of 133 Hierarchical to: No other components. Dependencies: No dependencies. F The TSF shall re-authenticate the user under the conditions each command IA_UAU.6.1 sent to the TOE after successful run of the Chip Authentication Protocol shall be verified as being sent by the rightful terminal. 152 ation(s): ePassport, eID, eSign. 214 Application note 67: The PACE and the Chip ied in [12] start secure d after successful PACE authentication and C s by secure messaging in encrypt-then-authenticate mode based on CMAC, whether it was sent by the successfully authenticated terminal (see FCS_COP.1/CMAC for further details). The TO does not execute any command with incorrect m ion , the TOE re-authenticates the terminal connected, if a secure occurred, and accepts only those commands received from the initially a nal. minal Authentication, the current secure messaging session is b d on Comp(ephem-PKPCD-TA). 215 The current PP also includes all SFRs of the ICAO-EAC PP [6]. Formally, they only concern the ePassport application. For the functional class FIA, there are the following components: This item concerns the following applic Authentication protocols specif messaging used for all co A. The TOE check mmands exchange each command E essage authenticat messaging error code. Therefore uthenticated termi ounde For the Ter SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FIA_UID.1/ICAO- EAC - is akin to FIA_UID.1/Rightful_Terminal and covers the TA protocol version 1 (for AIP) in [12], sec. 4.4 FIA_UAU.1/ICAO- - is akin to FIA_UAU.1/Rightful_Terminal EAC and covers the TA AIP) in [12], sec. 4 protocol version 1 (for .4 FIA_UAU.4/ICAO- EAC - is akin to FIA_UID.4 and covers the TA 4.4 protocol version 1 (for AIP) in [12], sec. FIA_UAU.5/ICAO- EAC n ec. 4.3, 4.4. - is akin to FIA_UID.5 and covers the CA and TA protocols version 1 (for AIP) i [12], s FIA_UAU.6/ICAO- EAC FIA_UID.6 - FIA_API.1/ICAO- EAC - I.1/CA and covers the sec. 4.3. is akin to FIA_AP CA protocol version 1 (for AIP) in [12], 152 [assignment: list of conditions under which re-authentication is required] Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 86 of 133 Bundesamt für Sicherheit in der Informationstechnik 216 The current PP also in the eP tion. cludes all SFRs of the PACE-Pass PP [7]. Formally, they only concern assport applica For the functional class FIA, there are the following components: SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FIA_AFL.1/PACE_PA FIA_AFL.1/PACE - CE-Pass FIA_APO.1/PA_PACE - Performing Passive Authentication according to [12 ing SOD. -Pass ], sec. 1.1 us FIA_UID.1/PACE_PA FIA_UID.1/PACE - CE-Pass FIA_UAU.1/PACE_P ACE-Pass FIA_UAU.1/PACE - FIA_UAU.4/PACE- Pass A_UAU.4 FI - FIA_UAU.5/PACE- Pass FIA_UAU.5 - FIA_UAU.6/PACE- FIA_UAU.6 - Pass 217 The current PP also includes all SFRs of the SSCD PP [8]. These items are applicable, if the or the the component FIA_UAU.1/SSCD is explicitly re-defined (supplemented) in the current PP: 218 FIA_UAU.1/SSCD No other components. Dependencies: FIA_ [8] FIA_UAU.1.1 The 1. self test according to FPT_TST.1, eSign application is operational. Formally, they only concern the eSign application. F functional class FIA, there are the following components, whereby Timing of authentication Hierarchical to: UID.1 Timing of identification: fulfilled by FIA_UID.1/SSCD, cf. TSF shall allow 2. identification of the user by means of TSF required by FIA_UID.1/SSCD in [8], 3. establishing a trusted channel between CGA and the TOE by means of TSF required by FTP_ITC.1/CA153, 4. establishing a trusted channel between HID and the TOE by means of TSF required by FTP_ITC.1/CA154, 5. [assignment: list of additional TSF-mediated actions]155 on behalf of the user to be performed before the user is authenticated. 153 the authenticated terminal is ATT, cf. FIA_UAU.1/Rightful_Terminal f. FIA_UAU.1/Rightful_Terminal; the trusted channel by FTP_ITC.1/CA 154 the authenticated terminal is SGT, c implements a trusted path between HID and the TOE. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 87 of 133 FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before This item concerns th allowing any other TSF-mediated actions on behalf of that user. e following application(s): eSign. SFR identifier from [8] Equivalent to / covered by i rent PP tem in the cur Comments FIA_UID.1/SSCD - This requirement concerns dedicated e eSign authentication data for th application like eSign-PIN and eSign-PUK, if any. FIA_AFL.1/SSCD ement concerns dedicated authentication data for the eSign eSign-PIN and - This requir application like eSign-PUK, if any. 6.1.4 Class FDP User Data Pr 219 FDP_ACC.1/TRM Hierarchical to: Dependencies: FDP_ACC.1.1 otection Subset access control – Terminal Access No other components. FDP_ACF.1 Security attribute based access control: fulfilled by FDP_ACF.1/TRM The TSF shall enforce the Terminal Access Control SFP 156 on terminals gaining write, read, modification and usage access to the User Data stored in the RP_Card . llowing application(s): ePassport, eID, eSign. 157 This item concerns the fo 220 FDP_ACF.1/TRM Hierarchical to: No other components. Security attribute based access control – Terminal Access 155 [assignment: list of TSF mediated actions] 157 ts, and operations among subjects and objects covered by the SFP] 156 [assignment: access control SFP] [assignment: list of subjects, objec Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 88 of 133 Bundesamt für Sicherheit in der Informationstechnik Dependencies: FM The ecurity r the attr FDP_ACF.1.1 The cess Control SFP FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/TRM T_MSA.3 Static attribute initialisation: not fulfilled, but justified access control TSF according to FDP_ACF.1/TRM uses s attributes having been defined during the personalisation and fixed ove whole life time of the TOE. No management of these security ibutes (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary here. TSF shall enforce the Terminal Ac 158 to objects based on the following: 1. Subjects: a. Terminal, b. PACE Terminal (PCT equiv. BIS-PACE), c. Rightful Terminal (EIS-AIP-BAC, EIS-GAP, ATT, SGT); 2. Objects: ; User Data stored in the TOE 3. Security attributes: a. Authentication status of terminals, b. Terminal Authorisation Level, c. CA authentication status, d. Authentication status of the RP_Card holder as Signatory (if the eSign is operational) 159. FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation allowed: 1. a successfully authenticated EIS-GAP is allowed to read User Data among controlled subjects and controlled objects is according to [12], sec. C.4.1 after a successful CA as required by FIA_API.1/CA. 2. a successfully authenticated Authentication Terminal (ATT) is allowed to read, modify and write User Data as well as to generate signature key pair(s) within the eSign application (SCD/SVD160) according to [12], sec. C.4.2 after a successful CA as required by FIA_API.1/CA. 3. a successfully authenticated Signature Terminal (SGT) is allowed to use the private signature key within the eSign application (SCD, if the eSign is operational) for generating electronic signatures according to [12], sec. C.4.3 after a successful CA as required by FIA_API.1/CA and a successful authentication of the RP_Card holder as Signatory as required by FIA_UAU.1/SSCD. 161 FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on 158 [assignment: access control SFP] 159 [assignment: list of subjects and objects controlled under the indicated SFP, and. for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] _CKM.1/SSCD ules governing access among controlled subjects and controlled objects using controlled 160 as required by FCS 161 [assignment: r operations on controlled objects] 162 biometric: finger Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 89 of 133 the following additional rules: 4. A successfully authenticated EIS-AIP-BAC is allowed to read User Data (only DG3 and DG4) according to [12], sec. 1.1 (ICAO/EAC version 1), G.3 and C.4.1 after a successful TA as required by FIA_UAU.1/ICAO-EAC (this rule is inherited from [6]). 5. A BIS-PACE (PCT) is allowed to read User Data (except DG3162 and DG4163) according to [12], sec. 1.1 and G.2 after a successful PACE authentication as required by FIA_UAU.1/PACE_PACE-Pass (this rule is inherited from [7]).164 FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. rminal (i.e. as Any terminal being not authenticated as a rightful te either BIS-PACE or EIS-AIP-BAC or EIS-GAP or ATT or SGT) is not allowed to read, to write, to modify, to use any User Data stored on the RP_Card. hic 2. Nobody is allowed to read ‘TOE immanent secret cryptograp keys’ stored on the RP_Card. 3 Nobody is allowed to read ‘secret RP_Card holder authentication data’ stored on the RP_Card. 4. Nobody is allowed to read the private Restricted Identification (SKID) key stored on the RP_Card. 5. Nobody is allowed to read the private signature key(s) within the eSign application (SCD; if the eSign is operational)165. This item concerns the fo 221 Application note 68: T ncoded in the Card Verifiable Certifi te y the Service Provider. The TOE verifies the certificate he Document Verifier Certifi f. FMT_MTD.3). The Terminal Authorisation Level is the tes of the Country Verify the Terminal Certificate in a der Authorization Template (C see [12], C.1.5. A CHAT is calculated as an AND-operation from the certificate c _Card holder’s restricting input at the terminal. This final CHAT reflects the effective authorisation level, see [12], sec. 2.3 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3 und B llowing application(s): ePassport, eID, eSign. he relative certificate holder (Service Provider) authorisation is e cate of the terminals being opera d b chain established by the Country Verifying Certification Authority, t cate and the Terminal Certificate (c intersection of the Certificate Holder Authorisation in the certifica ing Certification Authority, the Document Verifier Certificate and valid certificate chain. It is technically based on Certificate Hol HAT), hain of the terminal and the RP .11.1 of [12]). 222 Application note 69: Please note that the Card/Chip Security Object (SOC) does not belong to the user data, but to the TSF-data. Read access to the Card/Chip Security Object is ruled by [12], A.1.2 and table A.1 for EF.CardSecurity/EF.ChipSecurity, respectively. Also the Document Security Object (SOD) stored in EF.SOD (see [9], sec. A.10.4) does not 163 biometric: iris 164 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] ity attributes, that explicitly deny access of subjects to objects] 165 [assignment: rules, based on secur Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 90 of 133 Bundesamt für Sicherheit in der Informationstechnik belong to the user data, but to the TSF-data. The Document Security Object can be read out by the PCT as well as after accomplishing the BAC procedure, see [12], G.1. 223 A le ional requirem vers the ability to activate the eSign application usin appropriate Terminal Authorisation Level, see [12], sec. C.4.2, and acting on behalf of the CSP and upon an application by the RP_Card holder. 224 Application note 71: Please note that the control on the user data transmitted between the TOE and the rightful terminal is addressed by FTP_ITC.1/CA. 225 F ubset resid protection onents. Dependencies: No dependencies. FDP_RIP.1.1 The TSF shall ensure that any previous information content of a 1. the Chip Authentication Private Key SK pplication note 70: P ase note that this funct g the ATT with an ent also co DP_RIP.1 S ual information Hierarchical to: No other comp resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] the following objects: PICC (when its temporarily stored value is not to use any more), 2. d holder authentication data eID-PIN, eID-PUK, the secret RP_Car eSign-PIN (RAD; if eSign is operational) (when their the temporarily stored values are not to use any more), 3. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc) elated co munication session), (by closing r m 4. the ephemeral private key ephem-SKPICC-PACE (by having generated a DH shared secret K166), 5. the private Restricted Identification key SKID (when its temporarily stored value is not to use any more), 6. the private signature key of the RP_Card holder (SCD; if the eSign is operational) (when its temporarily stored value is not to use any more), 7. [assignment: list of objects]. This item concerns the (s): ePassport, e . 226 A mily FDP_RIP possesses such a general character, so that it is 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_EMSEC. 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 addition to FCS_CKM.4 that merely requires a fact of k ing to a method/standard. following application ID, eSign pplication note 72: The functional fa applicable not only ey destruction accord 166 according to [12], sec. 4.2.1, #3.b Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 91 of 133 227 The current PP also includes all SFRs of the ICAO-EAC PP [6]. Formally, they only concern the ePassport application. For the functional class FDP, there are the following components: SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FDP_ACC.1/ICAO- EAC FDP_ACC.1/TRM - FDP_ACF.1/ICAO- EAC FDP_ACF.1/TRM - FDP_UCT.1/ICAO- EAC FTP_ITC.1/CA for EIS-AIP-BAC FDP_UIT.1/ICAO- EAC A FTP_ITC.1/C for EIS-AIP-BAC 228 The current PP also includes all SFRs of the PACE-Pass PP [7]. Formally, they only concern the ePassport application. For the functional class FDP, there are the following components: SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FDP_ACC.1/TRM_PA CE-Pass FDP_ACC.1/TRM - FDP_ACF.1/TRM_PA CE-Pass FDP_ACF.1/TRM - FDP_RIP.1/PACE- Pass FDP_RIP.1 - 229 also in f the SSCD PP [8]. These items are applicable, if the on is o r the functional class FDP, t The current PP cludes all SFRs o eSign applicati perational. Formally, they only concern the eSign application. Fo here are the following components: SFR identifier from [8] Equivalent to / covered by item in the current PP Comments FDP_ACC.1/SCD/SV D_Generation_SFP_SS CD - - FDP_ACF.1/SCD/SV - - D_Generation_SFP_SS CD FDP_ACC.1/SVD_Tra - - Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 92 of 133 Bundesamt für Sicherheit in der Informationstechnik SFR identifier from [8] Equivalent to / covered by item in the current PP Comments nsfer_SFP_SSCD FDP_ACF.1/SVD_Tra nsfer_SFP_SSCD - - FDP_ACC.1/Signature -creation_SFP_SSCD - - FDP_ACF.1/Signature- creation_SFP_SSCD - - FDP_RIP.1/SSCD P.1 FDP_RIP.1 contributes to achie OT.Sigy_SigF (eSign-PIN) a FDP_RI vement of nd OT.SCD_Secrecy (SCD) FDP_SDI.2/Persistent_ - SSCD - FDP_SDI.2/DTBS_SS CD - - 6.1.5 Trust 230 F CE Class FTP ed Path/Channels TP_ITC.1/PACE Inter-TSF trusted channel after PA Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted IT product PACE terminal (PCT) after PACE 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 The TSF shall permit another trusted IT product the PCT167 to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate enforce communication via the trusted channel for any data exchange between the TOE and the PCT after PACE. 168 This item concerns the following application(s): ePassport, eID, eSign. 167 [selection: the TSF, another trusted IT product] [assignment: list of functions fo 168 r which a trusted channel is required] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 93 of 133 231 Application note 73: The trusted channel is established after successful performing the PACE protocol (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 establishing Chip Authentication; the cryptographic primitives being used for the secure messaging are as required by FCS_COP.1/AES and FCS_COP.1/CMAC. The establishing phase of the PACE trusted channel does not enable tracing due to the requirements FIA_AFL.1/PACE and FIA_AFL.1/eID-PIN_Blocking. 232 FTP_ITC.1/CA F trusted channel after CA H ents. Dependencies: No dependencies. FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted IT product The PACE secure messaging session is immediately superseded by a CA secure messaging session after successful Chip Authentication as required by FTP_ITC.1/CA. Inter-TS ierarchical to: No other compon rightful terminal (EIS-AIP-BAC, EIS-GAP, d identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2 The TSF shall permit another trusted IT product ATT, SGT) after Chip Authentication that is logically distinct from other communication channels and provides assure the rightful terminal (EIS-AIP-BAC, EIS-GAP, ATT, SGT)169 to initiate communication via hannel. FTP_ITC.1.3 The TSF shall initiate the trusted c enforce communication via the trusted channel for any data exchange between the TOE and the Service Provider represented by the rightful terminal after Chip Authentication. 170 This item concerns the following application(s): ePassport, eID, eSign. 233 Application note 74: The trusted channel is established after successful performing the PACE protocol (FIA_UAU.1/P Rightful_Terminal for GAP or F -EAC or FIA_API.1/ICAO-EAC re messaging is immediately restarted using the derived session keys (CA-KMAC, CA-KEnc)171: this secure messaging enforces the required properties of operational trusted channel; the c e as required by (i) FCS_COP.1/AES and FCS_COP.1/CMAC for GAP or (ii) FCS_COP.1/SYM_ICAO-EAC and FCS_COP.1/MAC_ICAO-EAC for AIP being compliant with [6]. 5: Please note that the control on the user data stored in the TOE is addressed ACE), the TA protocol (FIA_UAU.1/ IA_UAU.1/ICAO for AIP) and the CA protocol (FIA_API.1/CA for GAP for AIP). If the Chip Authentication was successfully performed, secu ryptographic primitives being used for the secure messaging ar 234 Application note 7 by FDP_ACF.1/TRM. IT product] nctions for which a trusted channel is required] ntinued using the previously established session keys (PACE-KMAC, PACE- 169 [selection: the TSF, another trusted 170 [assignment: list of fu 171 otherwise, secure messaging is co KEnc), cf. FTP_ITC.1/PACE. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 94 of 133 Bundesamt für Sicherheit in der Informationstechnik 235 Application note 76: The requirement FTP_ITC.1/CA also covers a secure transport of (i) SVD172 from the TOE to CGA173 as well as of (ii) VAD174 from HID175 and of (iii) DTBS176 from SCA175 to the TOE. It also covers TOE’s capability to generate and to provide CGA with evidence that can be used as a guarantee of the validity of SVD. The current SFR reflects the main additional security feature concerning the eSign application comparing to [8]. 236 The current PP also includes all SFRs of the ICAO-EAC PP [6]. Formally, they only concern the ePassport application. For the functional class FTP, there are no components there. 237 The current PP also includes all SFRs of the PACE-Pass PP [7]. Formally, they only concern the eP F FTP, there are ing components: assport application. or the functional class the follow SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FTP_ITC.1/PACE_PA CE-Pass FTP_ITC.1/PACE - e eSign application. For the functional class FTP, there are no components there. 6.1.6 Hierarchical to: No other components. Dependencies: No dependencies. ide the Manufacturer 238 The current PP also includes all SFRs of the SSCD PP [8]. Formally, they only concern th Class FAU Security Audit 239 FAU_SAS.1 Audit storage FAU_SAS.1.1 The TSF shall prov 177 with the capability to store the Initialisation and Pre-Personalisation Data 178 in the audit records. This item concerns the following application(s): ePassport, eID, eSign. 172 inte 173 the au inal is ATT 1, . 174 confidentiality is to secure 175 the authenticated terminal 176 integrity is to secure 177 [assignment: authorised users] 178 [assignment: list of audit information] grity is to secure thenticated term cf. [12], sec. C.4.2 with bits 7 (install qualified certificate) or/and 6 (install certificate) set to is SGT Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 95 of 133 240 Application note 77: T ntity assumed by the TOE in the life cycle phase ‘manufac P_Card manufacturer in the Manufacturer role write the Initialisation and/ ion Data as TSF-data into the TOE. The audit records are usually write-only-once data of the RP_Card (see F ould also be such audit re ormally, they only concern the llowing components: he Manufacturer role is the default user ide turing’. The IC manufacturer and the R or Pre-personalisat MT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there c cords which cannot be read out, but directly used by the TOE. 241 The current PP also includes all SFRs of the ICAO-EAC PP [6]. F ePassport application. For the functional class FAU, there are the fo SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FAU_SAS.1/ICAO- EAC FAU_SAS.1 - 242 The current PP also in ally, they only concern the ePassport application. For AU, there are the following components: cludes all SFRs of the PACE-Pass PP [7]. Form the functional class F SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FAU_SAS.1/PACE- Pass FAU_SAS.1 - 43 The current P concern the eSign application. For the functional class FAU, there are no components there. 6.1.7 Class FMT Security Management . FMT_SMF.1.1 The TSF shall be capable of performing the following management 2 P also includes all SFRs of the SSCD PP [8]. Formally, they only 244 The SFR FMT_SMF.1 and FMT_SMR.1 provide basic requirements on the management of the TSF data. 245 FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components Dependencies: No dependencies. functions: 1. Initialisation, 2. Personalisation, 3. Configuration, Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 96 of 133 Bundesamt für Sicherheit in der Informationstechnik 4. Resume and unblock the eID-PIN179, 5. Activate and deactivate the eID-PIN. 180 246 FMT_SMR.1 Security s ion note 78 below. FMT_SMR.1.1 This item concerns the following application(s): ePassport, eID, eSign. role Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/PACE, FIA_UID.1/Rightful_Terminal see also the Applicat The TSF shall maintain the roles 1. Manufacturer, 2. Personalisation Agent, 3. Country Verifying Certification Authority, 4. Document Verifier, Terminal, 5. 6. PACE Terminal (PCT equiv. BIS-PACE), AC (EIS-AIP-BAC), 7. Extended Inspection System using AIP with B 8. Extended Inspection System using GAP (EIS-GAP), 9. Authentication Terminal (ATT), 10. Signature Terminal (SGT), 11. RP_Card holder. 181 s with roles. rns th 247 Application note 78: F Application note 77; on the role Personalisat The role Terminal is the d ised by the TOE as neither PCT nor EIS-AIP-BA is used by the RP_Card presenter). The roles CVC d by analysing the current T GAP or FIA_UAU.1/ICAO The TOE recognises the RP_Card holder by using PCT upon input eID-PIN or eID-PUK FMT_SMR.1.2 The TSF shall be able to associate user This item conce e following application(s): ePassport, eID, eSign. or explanation on the role Manufacturer please refer to the ion Agent – to the Application note 62. efault role for any terminal being recogn C nor EIS-GAP nor ATT nor SGT (‘Terminal’ A, DV, EIS-AIP-BAC, EIS-GAP, ATT182 and SGT are recognise erminal Certificate CT, cf. [12], C.4 (FIA_UAU.1/Rightful_Terminal for -EAC for AIP). 179 unb ng eSign-PIN is managed by FMT_SMF.1/SSCD 180 [assignment: list of management functions to be provided by the TSF] 181 [assignment: the authorised identified roles] if bits 7 (install qualified certificate) or/and 6 al authorisation level, cf. [12], sec. C.4.2; an ATT CSP to act as CGA on its behalf. locki 182 ATT plays a special role ‘CGA’ for the eSign application, (install certificate) are set to 1 within the effective termin with such a terminal authorisation level is authorised by the related Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 97 of 133 (FIA_UAU.1/PACE) as well as – in the context of the eSign application – by using SGT upon U.1/SSCD). input eSign-PIN (FIA_UA 248 The SFR FM e management of the TSF and TSF data to pr test 249 FMT_LIM.1 ependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2 FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that M.2)’ the following policy is enforced: Deploying test features after TOE delivery do not allow T_LIM.1 and FMT_LIM.2 address th event misuse of features of the TOE over the life cycle phases. Limited capabilities Hierarchical to: No other components. D in conjunction with ‘Limited availability (FMT_LI 1. User Data to be manipulated and disclosed, 2. TSF data to be manipulated or disclosed, 3. embedded software to be reconstructed and tion about construction of TSF to be gathered 4. substantial informa which may enable other attacks.183 This item concerns th 50 FMT_LIM.2 Limited availability e following application(s): ePassport, eID, eSign. 2 Hierarchical to: No other components. Dependencies: FMT_LIM.1 Limited capabilities: fulfilled by FMT_LIM.1 FMT_LIM.2.1 The TSF shall be designed in a manner that limits their availability so that in conjunction with ‘Limited capabilities (FMT_LIM.1)’ the following policy is enforced: Deploying test features after TOE delivery do not allow 1. User Data to be manipulated and disclosed, 2. TSF data to be manipulated or disclosed, 3. embedded software to be reconstructed and 4. substantial information about construction of TSF to be gathered which may enable other attacks.184 This item concerns the following application(s): ePassport, eID, eSign. 183 [assignment: Limited capability and availability policy] ity policy] 184 [assignment: Limited capability and availabil Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 98 of 133 Bundesamt für Sicherheit in der Informationstechnik 251 FMT_MTD.1/INI_ENA Management of TSF data – Writing Initialisation and Pre-personalisation 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 FMT_MTD.1.1 The TSF shall restrict the ability to write 185 the Initialisation Data and Pre-personalisation Data186 to the Manufacturer. 187 This item concerns th o 252 FMT_MTD.1/INI_DIS Management of TSF data – Reading and Using Initialisation and Pre-personalisation Data No other components. e f llowing application(s): ePassport, eID, eSign. Hierarchical to: Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1 The TSF shall restrict the ability to read out and to use 188 the Initialisation Data 189 to the Personalisation Agent. 190 This item concerns the following application(s): ePassport, eID, eSign. 253 Application note 79: The TOE may restrict the ability to write the Initialisation Data and the P Da ng these data only once and (ii) blocking the role Manufacturer phase. The Manufacturer may write the In (as unique identification of the IC trace the IC in the life cycle phases ‘manufacturing’ and ‘issuing’, but being no herefore, read and use access to the Initialisation Data shall be by the P ent, ase ‘issuing’ to the life cycle phase ‘operation s re-personalisation at the end ta by (i) allowing writi of the manufacturing itialisation Data required by FAU_SAS.1) including, but being not limited to a being used to t needed and may be misused in the ‘operational use’. T blocked in the ‘operational use’ ersonalisation Ag when he switches the TOE from the life cycle ph al u e’. Please also refer to the Application note 62. 185 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 186 [assignment: list of TSF data] 187 [assignment: the authorised identified roles] 188 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 189 [assignment: list of TSF data] 190 [assignment: the authorised identified roles] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 99 of 133 254 F itialisation of CVCA Certificate and Current Date FM he ability to write MT_MTD.1/CVCA_INI Management of TSF data – In Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 T_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1 The TSF shall restrict t 191 the 1. initial Country Verifying Certification Authority Public Key (PKCVCA), ty 2. metadata of the initial Country Verifying Certification Authori Certificate (CCVCA) as required in [12], sec. A.6.2.3, 3. initial Current Date, 4. [assignment: list of TSF data] to [assignment: the authorised identified roles]. This item concerns th o 255 Application note 80: The initial Country Verifying Certification Authority Public Key may be written by is cation Authority Public FMT_MTD.1/CVCA_UPD Management of TSF data – Country Verifying e f llowing application(s): ePassport, eID, eSign. the Manufacturer in the manufacturing phase or by the Personalisation Agent in the suing phase (cf. [12], sec. 2.2.5). The initial Country Verifying Certifi Keys (and their updates later on) are used to verify the Country Verifying Certification Authority Link-Certificates. The metadata of the initial Country Verifying Certification Authority Certificate and the initial Current Date are needed for verification of the certificates and the calculation of Terminal Authorisation Level. Please note that only a subset of the metadata must be stored in the TOE, see [12], sec. A.6.2.3; storing of further certificate’s content is optional. 256 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 FMT_MTD.1.1 The TSF shall restrict the ability to update 192 the 1. Country Verifying Certification Authority Public Key (PKCVCA), 2. metadata of the Country Verifying Certification Authority Certificate (CCVCA) as required in [12], sec. A.6.2.3, 3. [assignment: list of TSF data] to Country Verifying Certification Authority. 193 191 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 192 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 193 [assignment: the authorised identified roles] Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 100 of 133 Bundesamt für Sicherheit in der Informationstechnik This item concerns the following application(s): ePassport, eID, eSign. 257 Application note 81: The Country Verifying Certification Authority updates its asymmetric key pair and distributes the public key and the related metadata be means of the CVCA Link-Certificates (cf. [12], sec. 2.2). The TOE updates its internal trust-point, if a valid CVCA Link-Certificates (cf. FMT_MTD.3) is provided by the terminal (cf. [12], sec. 2.2.3 and 2.2.5). 258 FMT_MTD.1/DATE Management of TSF data – Current date Hierarchical to: No other components. Specification of management functions: fulfilled by FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 he ability to modify Dependencies: FMT_SMF.1 FMT_SMF.1 FMT_MTD.1.1 The TSF shall restrict t 194 the Current Date195 to 1. Country Verifying Certification Authority, 2. Document Verifier, 3. Rightful Terminal (EIS-AIP-BAC, EIS-GAP, ATT or SGT) possessing an Accurate Terminal Certificate.196 This item concerns the following application(s): ePassport, eID, eSign. 259 Application note 82: The authorised roles are identified in their certificates (cf. [12], sec. 2.2.5 a CA (cf. FMT_MTD.3). The authoris card oles: fulfilled by FMT_SMR.1 nd C.4) and authorised by validation of the certificate chain up to CV ed role of terminal is part of the Certificate Holder Authorization in the verifiable certificate provided by the terminal within the Terminal Authentication (cf. [12], A.6.2.3, B.11.1, C.1.3, C.1.5, D.2 for details). 260 FMT_MTD.1/PA_UPD Management 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 r FMT_MTD.1.1 The TSF shall restrict the ability to write 197 the Card/Chip Security Object (SOC) and the Document Security Object (SOD)198 to the Personalisation Agent. 199 194 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] ntified roles] 195 [assignment: list of TSF data] 196 [assignment: the authorised ide 197 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 198 [assignment: list of TSF data] 199 [assignment: the authorised identified roles] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 101 of 133 This item concerns the following application(s): ePassport, eID, eSign. 261 A lisation Agent confirms (on behalf of DS) the correctness and genuineness of all the personalisation data related. The latter consist of user- and TSF- data, as well. Due to this fact and to the scope of the SFR FMT_MTD.1 (management of TSF-data), the entire set of the personalisation data is formally not wing way: ‘The TSF shall restrict the ability to write pplication note 83: By writing SOC and SOD into the TOE, the Persona addressed above. Nevertheless, FMT_MTD.1/PA_UPD shall be understood in the follo the personalisation data to the Personalisation Agent.’ O alis r to the Application note 62. 262 FMT_MTD.1/SK_PIC ntication Private ierarchical to: No other components. fulfilled by n the role ‘Person ation Agent’ please refe C Management of TSF data – Chip Authe Key H Dependencies: FMT_SMF.1 Specification of management functions: FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1 The TSF shall restrict the ability to [selection: create, load] 200 the Chip Authentication Private Key (SKPICC)201 to [assignment: the authorised identified roles]. This item concerns the following application(s): ePassport, eID, eSign. ponent FMT_MTD.1 263 Application note 84: The com /SK_PICC is refined by (i) selecting other op def operations ‘create’ and ‘load’ to be performed by th ver at the Chip Authentication Private Key is securely ge the T ere that the Chip Authenticatio is generated by the TOE itself. In the latter case, the ST writer might include a .1 as SFR for this key generation. 264 FMT_MTD.1/KEY_R agement of TSF data – Private Key Read Hierarchical to: ependencies: FM m nt functions: fulfilled by FMT_SMF.1 illed by FMT_SMR.1 FMT_MTD.1.1 The TSF shall restrict the ability to read erations and (ii) e ST writer. The ining a selection for the b ‘load’ means here th nerated outside OE and written into the TOE memory. The verb ‘create’ means h n Private Key n appropriate instantiation of the component FCS_CKM EAD Man No other components. T_SMF.1 Specification of manage e D FMT_SMR.1 Security roles: fulf 202 the Chip Authentication Private Key (SKPICC) 203 to none. 204 200 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 201 [assignment: list of TSF data] 202 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 203 [assignment: list of TSF data] 204 [assignment: the authorised identified roles] Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 102 of 133 Bundesamt für Sicherheit in der Informationstechnik This item concerns the following application(s): ePassport, eID, eSign. 265 FMT_MTD.1/eID-PIN_Resume Management of TSF data – Resuming eID-PIN Hierarchical to: No other components. FMT_SMF.1 oles: fulfilled by FMT_SMR.1 Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMR.1 Security r FMT_MTD.1.1 The TSF shall restrict the ability to resume 205 the suspended eID-PIN 206 to the RP_Card holder. 207 s th 266 Application note 85: The r using PACE with CAN and PACE with eID-PIN. It must be implemented according to [12], sec. 3.5.1 and is relevant for the status as required by FIA_AFL.1/eID-PIN_Suspending. The RP_Card holder is a PIN as the shared password. ing eID-PIN Hierarchical to: No other components. : FM anagement functions: fulfilled by This item concern e following application(s): eID. esuming procedure is a two-step one, subsequently uthenticated as required by FIA_UAU.1/PACE using the eID- 267 FMT_MTD.1/eID-PIN_Unblock Management of TSF data – Unblocking/Chang Dependencies T_SMF.1 Specification of m FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 The TSF shall restrict the ability to FMT_MTD.1.1 unblock and change 208 the blocked eID-PIN 209 to 1. the RP_Card holder, 2. the Authentication Terminal (ATT) with the Terminal Authorisation Level for eID-PIN management. 210 This item concerns the following application(s): eID. 205 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 206 [assignment: list of TSF data] ify, delete, clear, [assignment: other operations]] ntified roles] 207 [assignment: the authorised identified roles] 208 [selection: change_default, query, mod 209 [assignment: list of TSF data] 210 [assignment: the authorised ide Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 103 of 133 268 Application note 86: The unblocking procedure must be implemented according to [12], sec. 3.5.1, 3.5.2 and is relevant for the status as required by FIA_AFL.1/eID-PIN_Blocking. It can be triggered by either (i) the RP_Card holder being authenticated as required by FIA_UAU.1/PACE using the eID-PUK as the shared password or (ii) the ATT (FIA_UAU.1/Rightful_Terminal) Dependencies: FMT_SMF.1 F proved a Terminal Authorisation Level being sufficient for eID-PIN management (FDP_ACF.1/TRM). 269 FMT_MTD.1/eID-PIN_Activate Management of TSF data – Activating/Deactivating eID-PIN Hierarchical to: No other components. Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 MT_MTD.1.1 The TSF shall restrict the ability to activate and deactivate 211 the eID-PIN 212 to the Authentication Terminal (ATT) with the Terminal Authorisation Level for eID-PIN management. 213 This item concerns the following application(s): eID, eSign. 270 Application note 87: The activating/deactivating procedures must be implemented according to [12], sec. 3.5.2. It can be triggered by the ATT (FIA_UAU.1/Rightful_Terminal) proved a Terminal Authorisation Level being sufficient for eID-PIN management (FDP_ACF.1/TRM). No other components. Dependencies: FMT_MTD.1 Management of TSF data: fulfilled by 1/CVCA_IN FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE ll ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol and the 271 FMT_MTD.3 Secure TSF data Hierarchical to: FMT_MTD. I, FMT_MTD.3.1 The TSF sha Terminal Access Control SFP.214 Refinement: The certificate chain is valid if and only if [selection: change_default, query, modify, delete, clear, [assignment: other operations]] [assignment: list of TSF data] [assignment: the authorised identified roles] [assignment: list of TSF data] 211 212 213 214 Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 104 of 133 Bundesamt für Sicherheit in der Informationstechnik (1) the digital sign l Certificate been verified as correct using the public key of the Document Verifier Certificate and the expiration date of the CT is not before the Current Date of the TOE, tal signature of the Document Verifier Certificate (CDV) has been verified as correct using the public key in the Certificate of the Country Verifying Certification V ion te of the CDV is not before the Current Date TOE, ig fic e of the Country Verifying Certification CVCA) has been verified as correct using the public key of the Country rt no to the TOE and the expiration date of the CVCA before the Current Date of the TOE. al ) contained in the CT in a valid certificate chain is a he erenc ertificate Holder rtificates of a valid certificate chain is a secure valu vel215 of a successfully authenticated Service Provide l). This item concerns the following application(s 272 Application note 88: The Terminal Authentication is used as required by (i) F _T AU for GAP or (ii) FIA_UAU.1/ICAO-EAC and FIA_UAU.5/ICAO-EAC for AIP. The Terminal Authorisation Level215 derived from the CCVCA, C s T co 273 The current PP also includes all SFRs of the ICA Formally, they only concern the ePassport application. For the functional class FMT, there are the following components: ature of the Termina (CT) has (2) the digi Authority (CC of the CA) and the expirat da (3) the digital s Authori nature of the Certi at ty (C Verifying Ce C is not ification Authority k wn The static termin public key (PKPCD secure value for t The intersection of the C authentication ref e data of a rightful terminal. Authorisations contained in the ce e for Terminal Authorisation Le r (represented by a rightful termina ): ePassport, eID, eSign. IA_UAU.1/Rightful erminal and FIA_U .5 DV and CT is used a SF-data for the access ntrol required by FDP_ACF.1/TRM. O-EAC PP [6]. SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FMT_SMF.1/ICAO- EAC FMT_SMF.1 - FMT_SMR.1/ICAO- EAC FMT_SMR.1 - FMT_LIM.1/ICAO- FMT_LIM.1 - EAC FMT_LIM.2/ICAO- FMT_LIM.2 - EAC 215 this d T orisation Leve an additionally be restricted by RP_Card holder at the inal, s. [12], sec. 2.3. It is based on Certificate Holder Authorization Template (CHAT), see [12], C.1.5. A C from the certificate chain of the terminal and the RP icti al. Thi e effective authorisation level, see [12], sec. 2.3 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3 und B.11.1 of [12]). certificate-calculate term erminal Auth l c HAT is calculated _Card holder’s restr as an AND-operation ng input at the termin s final CHAT reflects th Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 105 of 133 SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FMT_MTD.1/INI_EN A_ICAO-EAC INI_ENA FMT_MTD.1/ - FMT_MTD.1/INI_DI _ICA S O-EAC INI_DIS FMT_MTD.1/ - FMT_MTD.1/CVCA_I NI_ICAO-EAC I FMT_MTD.1/CVCA_IN - FMT_MTD.1/CVCA_ FMT_MTD.1/CVCA_UP - UPD_ICAO-EAC D FMT_MTD.1/DATE_I FMT_MTD.1/DATE - CAO-EAC FMT_MTD.1/KEY_W RITE_ICAO-EAC FMT_MTD.1/PA_UPD For BAC (EIS-AIP-BAC), the Document Basic Access Keys are derived from the value of the MRZ for the concrete instantiation of the TOE, cf. [12], H.1. Therefore, the Document Basic Access ote 83 above. Keys are considered as a part of personalisation data. See also the Application n FMT_MTD.1/CAPK_I CAO-EAC FMT_MTD.1/SK_PICC - FMT_MTD.1/KEY_R FMT_MTD.1/KEY_REA FMT_MTD.1/KEY_READ shall be e concept of Personalization Agent Keys from [6] is covered in the current PP using an ATT proven a sufficient Terminal Authorisation Level, see the plication note 62 above. EAD_ICAO-EAC D understood in such a way that it also covers the Document Basic Access Keys inherited from [6]. Th by Ap FMT_MTD.3/ICAO- FMT_MTD.3 - EAC 274 The current PP also includes all SFRs of the PA ass PP [7]. Formally, they only concern the e n. r the functional class FMT, there are the following components: CE-P Passport applicatio Fo SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FMT_SMF.1/PACE- Pass FMT_SMF.1 - FMT_SMR.1/PACE- Pass FMT_SMR.1 - Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 106 of 133 Bundesamt für Sicherheit in der Informationstechnik SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FMT_LIM.1/PACE- Pass FMT_LIM.1 - FMT_LIM.2/PACE- Pass FMT_LIM.2 - FMT_MTD.1/INI_EN FMT_MTD.1/INI_ENA - A_PACE-Pass FMT_MTD.1/INI_DIS _PACE-Pass FMT_MTD.1/INI_DIS - FMT_MTD.1/PA_UP D_PACE-Pass FMT_MTD.1/PA_UPD - 275 The current PP also includes all SFRs of the SSCD PP [8]. These items are applicable, if the eSign application is operational. Formally, they only concern the eSign application. For the T, ther nts: functional class FM e are the following compone SFR identifier from [8] Equivalent to / covered by item in the current PP Comments FMT_SMR.1/SSCD FMT_SMR.1 R.Sigy is represented by the RP_Card holder, R.Admin – by the Personalisation Agent, see also Table 4 above. FMT_SMF.1/SSCD - - FMT_MOF.1/SSCD - - FMT_MSA.1/Admin_ SSCD - - FMT_MSA.1/Signator y_SSCD - - FMT_MSA.2/SSCD - - FMT_MSA.3/SSCD - - FMT_MSA.4/SSCD - - FMT_MTD.1/Admin_ SSCD - - FMT_MTD.1/Signator - eSign-PIN can be unblocked using the card-global eID-PUK and may also be unblocked using an eSign-specific y_SSCD Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 107 of 133 SFR identifier from [8] Equivalent to / covered by item in the current PP Comments eSign-PUK, if any. 6.1.8 Class FPT Protection of the Security Functio 276 The TOE shall preven d forced illicit information leakage for the User Data and TSF-data. The securit dresses the inherent leakage. With respect to the forced leakag mbination with the security functional requirements ‘Failure with preservation of secure state (FPT_FLS.1)’ and ‘TSF testing (F P.3)’ on the other. The S IM.2)’ and ‘Resistance ncies. FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of (SK ns t inherent an y functional requirement FPT_EMSEC.1 ad e they have to be considered in co PT_TST.1)’ on the one hand and ‘Resistance to physical attack (FPT_PH FRs ‘Limited capabilities (FMT_LIM.1)’, ‘Limited availability (FMT_L to physical attack (FPT_PHP.3)’ together with the design measures to be described within the SAR ‘Security architecture description’ (ADV_ARC.1) prevent bypassing, deactivation and manipulation of the security features or misuse of the TOE security functionality. 277 FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components. Dependencies: No depende [assignment: specified limits] enabling access to 1. the Chip Authentication Private Key PICC), 2. n is operational), the eID-PIN, eID-PUK, eSign-PIN (RAD; if the eSig 3. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc), ate key ephem-SK 4. the ephemeral priv PICC-PACE, ] 5. [assignment: list of types of TSF data and 6. the private Restricted Identification key SKID, 7. the private signature key of the RP_Card holder (SCD; if the eSign is operational), 8. [assignment: list of types of user data]. FPT_EMSEC.1.2 The TSF shall ensure any users 216 are unable to us interface e the following it contacts RP_Card’s contactless interface and circu 217 to gain access to 1. the Chip Authentication Private Key (SKPICC), 216 [as sers] 217 [assignment: type of connection] signment: type of u Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 108 of 133 Bundesamt für Sicherheit in der Informationstechnik 2 -PUK, eSign-PIN (RAD; if the eSign is operational), . the eID-PIN, eID 3. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc), . 4 the ephemeral private key ephem-SKPICC-PACE, . [assignment: list of types of TSF data] 5 a 6 tification key SK nd . the private Restricted Iden ID, 7. the private signature key of the RP_Card holder (SCD; if the eSign is operational), 8. [assignment: list of types of user data]. rt card contactless interface, but may have also (not used by the terminal, but maybe by an attacker) sensitive contacts according to ISO/IEC 7816-2 as well. Examples of measurable phenomena 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. 279 T urit nts address the protection against forced illicit inform 280 F Hierarchical to: Dependencies: No dependencies. wing types of failures This item concerns the following application(s): ePassport, eID, eSign. 278 Application note 89: 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 RP_Card’s chip has to provide a sma he following sec y functional requireme ation leakage including physical manipulation. PT_FLS.1 Failure with preservation of secure state No other components. FPT_FLS.1.1 The TSF shall preserve a secure state when the follo occur: 1. Exposure to operating conditions causing a TOE malfunction, 2. Failure detected by TSF according to FPT_TST.1, 3. [assignment: list of types of failures in the TSF]. This item concerns the following application(s): ePassport, eID, eSign. 281 FPT_TST.1 TSF testing nents. Hierarchical to: No other compo Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 109 of 133 Dependencies: No dependencies. FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during nor ser, at the condition mal operation uest of the authorised u s [assignment: conditions under which self test should occur]] to demonstrate the correct operation of the TSF , at the req 218. l provide authorised users with the capability to verify the integrity of the TSF data FPT_TST.1.2 The TSF shal 219. hall provide authorised users with the capability to verify the integrity of stored TSF executable code FPT_TST.1.3 The TSF s 220. item concerns the following application(s): ePassport, eID, eSign. 282 Application note 90: If rd’s chip uses state of the art smart card technology, it will run so elf 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 283 F esistance to physical attack mponents. ndencies: No dependencies. all resist phys al manipulation and physical probing This the RP_Ca me s the secure state according to FPT_FLS.1 in the phase ‘operational use’, e.g. to check a calculation with a private key by the reverse calculation with the corresponding public key as a countermeasure against Differential Failure Analysis. PT_PHP.3 R Hierarchical to: Depe No other co FPT_PHP.3.1 The TSF sh ic 221 to the TSF 222 by responding automatically such that the SFRs are always enforced. This item concerns the following application(s): ePassport, eID, eSign. 284 Application note 91: The TOE will implement appropriate measures to continuously counter suming that there might be an attack at any time and (ii) countermeasures are provided at any time. physical 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 attacks is required ensuring that the TSP could not be violated at any time. Hence, ‘automatic response’ means here (i) as 218 [se pa TSF] 219 [selection: [assignment: parts of TSF], TSF data] 220 [se : pa TSF] 221 [assignment: physical tampering scenarios] 222 [assignment: list of TSF devices/elements] lection: [assignment: rts of TSF], the lection: [assignment rts of TSF], Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 110 of 133 Bundesamt für Sicherheit in der Informationstechnik 285 T cludes all SFRs of the ICAO-EAC PP lly, they only concern the ePassport application. For the functional class FPT, there are the following components: he current PP also in [6]. Forma SFR identifier from [6] Equivalent to / covered by item in the current PP Comments FPT_EMSEC.1/ICAO- FPT_EMSEC.1 - EAC FPT_FLS.1/ICAO- EAC FPT_FLS.1 - FPT_TST.1/ICAO- FPT_TST.1 - EAC FPT_PHP.3/ICAO- FPT_PHP.3 - EAC 286 rmally, they only concern the g components: The current PP also includes all SFRs of the PACE-Pass PP [7]. Fo ePassport application. For the functional class FPT, there are the followin SFR identifier from [7] Equivalent to / covered by item in the current PP Comments FPT_EMSEC.1/PACE- FPT_EMSEC.1 - Pass FPT_FLS.1/PACE- FPT_FLS.1 - Pass FPT_TST.1/PACE- Pass FPT_TST.1 - FPT_PHP.3/PACE- Pass FPT_PHP.3 - 287 The current PP also includes all SFRs of the SSCD [ Th it a p bl f t e p ation l. F al onl concern the eSign a lica on. r the f , the are e fo wi com onen s: PP 8]. ese ems re a plica e, i he Sign application is o er a orm ly, they y pp ti Fo unctional class FPT re th llo ng p t SFR identifier from [8] Equivalent to / ere y cov d b item i c nt P n the urre P Comments FPT_EMSEC.1/SSCD F _EMSEC.1 PT - FPT_FLS.1/SSCD F _FL 1 PT S. - Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 111 of 133 SFR identifier from [8] Equivalent to / covered by item in the current PP Comments FPT_PHP.1/SSCD FPT_PHP.3 - FPT_PHP.3/SSCD FPT_PHP.3 - FPT_TST.1/SSCD FPT_TST.1 - 6.2 suran e R quirements for the TOE 288 T equirements for the evaluation of the TOE, i dev lopm nt a d op ratin e hoose as the predefined assurance package EAL4 augmented by the following co VS.2 uffi enc easures), y for g m N.5 (Advanced methodical vulnerabilit anal sis). 6.3 Require ent Ra on e 6.3.1 ctiona Req ire nts at ale 289 T ble pro ides an overview for security function ts c vera als giving an evidence for sufficiency an ec of the SFRs chosen Security As c e he assurance r ts e e n e g nvironment are to c mponents: - ALC_D (S ci y of security m - ATE_DPT.2 (Testing: securit en cin odules) and - AVA_VA y y Security m s ti al Security Fun l u me R ion he following ta v al requiremen o ge o d n essity . OT.Ident ation ific OT.Personalisation OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.SCD/SVD_Gen [8] 223 OT.Sigy_SigF [8] 223 FCS_CKM.1/DH_PACE x x x FCS_CKM.1/DH_CA x x x x FCS_CKM.2/DH x x x FCS_CKM.4 x x x FCS_COP.1/SHA x x x x FCS_COP.1/SIG_VER x x x FCS_COP.1/AES x FCS_COP.1/CMAC x x x 223 th applicable, if the eSign application is operational. is item is Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 112 of 133 Bundesamt für Sicherheit in der Informationstechnik OT.Identification OT.Personalisation OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.SCD/SVD_Gen [8] 223 OT.Sigy_SigF [8] 223 FCS_RND.1 x x x x FIA_AFL.1/eID-PIN_Su spending x x x x FIA_AFL.1/eID-PIN_Bl ocking x x x x x FIA_AFL.1/PACE x FIA_API.1/CA x x x x FIA_UID.1/PACE x x x FIA_UID.1/Rightful_Ter m nal x x x x i FIA_UAU.1/PACE x x x FIA_UAU.1/Rightful_Te rminal x x x x FIA_UAU.1/SSCD x x 223 FIA_UAU.4 x x x FIA_UAU.5 x x x FIA_UAU.6 x x x FDP_ACC.1/TRM x x x FDP_ACF.1/TRM x x x FDP_RIP.1 x x x x x FTP_ITC.1/PACE x FTP_ITC.1/CA x x x x FAU_SAS.1 x x FMT_SMF.1 x x x x x FMT_SMR.1 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_IN I x x x FMT_MTD.1/CVCA_U PD x x x FMT_MTD.1/DATE x x x FMT_MTD.1/PA_UPD x x x x x FMT_MTD.1/SK_PICC x x x x FMT_MTD.1/KEY_RE AD x x x x FMT_MTD.1/eID-PIN_ Resume x x x x FMT_MTD.1/eID-PIN_ Unblock x x x x Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 113 of 133 OT.Identification OT.Personalisation OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.SCD/SVD_Gen [8] 223 OT.Sigy_SigF [8] 223 FMT_MTD.1/eID-PIN_ Activate x x x x FMT_MTD.3 x x x FPT_EMSEC.1 x FPT_FLS.1 x x FPT_TST.1 x x FPT_PHP.3 x x x Table 24: Coverage of Security Objectives for the TOE by SFR 290 A detailed justif at o requi the security objectives is given below. 291 The security objective OT.Identification addresses the storage of Initialisation and Pre Personalisation Data in its non-volatile memory, whereby they also include the IC Identification Data uniquely identifying the TOE’s chip. This will be ensured by TSF according to SFR FAU_SAS.1. The SFR FMT_MTD.1/INI_ENA allows only the Manufacturer to write Initialisation and Pre- personalisation Data (including the Personalisation Agent key). The SFR FMT_MTD.1/INI_DIS requires the Personalisation Agent to disable access to Initialisation and Pre-personalisation Data in the life cycle phase ‘operational use’. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 292 The security objective OT.Personalisation aim th User- and the TSF-data into the TOE (it also includes installing/activating of the eSign application). This property is covered by FDP_ACC.1/TRM and FDP_ACF.1/TRM requiring, ic i n red for suitability of the security functional requirements to achieve - s that only Personalisation Agent can write e amongst other, an appropriate authorisation level of a rightful terminal. This authorisation level can be achieved g and management of eID-PIN by the terminal identification/authentication as required by the SFR FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal224. Since only an ATT can reach the necessary authorisation level, usin (FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking, FMT_MTD.1/eID-PIN_Resume, FMT_MTD.1/eID-PIN_Unblock, FMT_MTD.1/eID-PIN_Activate) also support achievement of this objective. FDP_RIP.1 requires erasing the temporal values of eID-PIN, eID-PUK. The justification for the SFRs FAU_SAS.1, FMT_MTD.1/INI_ENA and FMT_MTD.1/INI_DIS arises from the justification for OT.Identification above with respect to the Pre-personalisation 224 which, in turn, are supported by the related FCS-components. The author dispensed here with listing of these supporting FCS-components for the sake of clearness. See the next item OT.Data_Integrity for further detail. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 114 of 133 Bundesamt für Sicherheit in der Informationstechnik Data. FMT_MTD.1/PA_UPD covers the related property of OT.Personalisation (writing/updating SOC and SOD and, in generally, personalisation data). The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 293 The security objective OT.Data_Integrity aims that the TOE always ensures integrity of the User- and TSF-data stored and, after the Terminal- and the Chip Authentication, of these data exchanged (physical manipulation and unauthorised Physical manipulation is addressed by FPT_PHP.3. Unauthorised m ing of the stored and FDP_ACF.1/TRM. A concrete authorisation level is achieved by the terminal identification/authentication as required by the SFRs FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal (is supported by FCS_COP.1/SIG_VER). The TA protocol uses the result of the PACE authentication (FIA_UID.1/PACE, FIA_UAU.1/PACE) being, in turn, supported by FCS_CKM.1/D and management of eID-PIN (FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID- modifying). odify data is addressed, in the first line, by FDP_ACC.1/TRM H_PACE. Since PACE can use eID-PIN as the shared secret, using PIN_Blocking, FMT_MTD.1/eID-PIN_Resume, FMT_MTD.1/eID-PIN_Unblock, .4 represent some required specific properties of the requires to make this key unreadable for re P_ITC.1/CA using FCS_COP.1/CMAC. A prerequisite possessing the Chip Authentication Private K y s so that its value remains confidential. FDP_RIP.1 FMT_MTD.1/PA_UPD requires that SOC containing, amongst other, signature over the PKPICC FMT_MTD.1/eID-PIN_Activate) also support achievement of this objective. FDP_RIP.1 requires erasing the temporal values of eID-PIN, eID-PUK. FIA_UAU.4, FIA_UAU.5 and FCS_CKM protocols used. To allow a verification of the certificate chain as required in FMT_MTD.3, the CVCA’s public key and certificate as well as the current date are written or update by authorised identified role as required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. Unauthorised modifying of the exchanged data is addressed, in the first line, by FTP_ITC.1/CA using FCS_COP.1/CMAC. A prerequisite for establishing this trusted channel is a successful Chip Authentication FIA_API.1/CA using FCS_CKM.1/DH_CA and FCS_CKM.2/DH and possessing the special properties FIA_UAU.5, FIA_UAU.6. The CA provides an evidence of possessing the Chip Authentication Private Key (SKPICC). FMT_MTD.1/SK_PICC governs creating/loading SKPICC, FMT_MTD.1/KEY_READ a user, so that its value remains confidential. FDP_RIP.1 requires erasing the values of SKPICC and session keys (he : for KMAC). FMT_MTD.1/PA_UPD requires that SOC containing, amongst other, signature over the PKPICC and used for the Passive Authentication is allowed to be modified by the Personalisation Agent only and, hence, is to consider as trustworthily. The SFRs FCS_COP.1/SHA and FCS_RND.1 represent the general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 294 The security objective OT.Data_Authenticity aims ensuring authenticity of the User- and TSF- data (after the Terminal- and the Chip Authentication) by enabling its verification at the terminal- side and by an active verification by the TOE itself. This objective is mainly achieved by FT for establishing this trusted channel is a successful Chip Authentication FIA_API.1/CA using FCS_CKM.1/DH_CA and FCS_CKM.2/DH and possessing the special properties FIA_UAU.5, FIA_UAU.6. The CA provides an evidence of e (SKPICC). FMT_MTD.1/SK_PICC governs creating/loading SKPICC, FMT_MTD.1/KEY_READ requires to make thi key unreadable for a user, requires erasing the values of SKPICC and session keys (here: for KMAC). and used for the Passive Authentication is allowed to be modified by the Personalisation Agent only and, hence, is to consider as trustworthily. A prerequisite for successful CA is an accomplished TA as required by Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 115 of 133 FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Term FCS_COP.1/SIG_VER). The TA p (FIA_UID.1/PACE, FIA_UAU.1/PACE) being, in turn, supported by FCS_CKM.1/DH_PACE. Since PACE can use eID-PIN as the shared secret, us PIN (FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking, FMT_MTD.1/eID-PIN_Resume, FMT_MTD.1/eID-PIN_Unblock, FMT_MTD.1/eID-PIN_Activate) also support achievement of this objective. FDP_RIP.1 requires erasing the temporal values of eID-PIN, eID-PUK. FIA_UAU.4, FIA_UAU.5 and FCS_CKM.4 represent some required specific properties of the protocols used. inal (is supported by rotocol uses the result of the PACE authentication ing and management of eID- To allow a verification of the certificate chain as required in FMT_MTD.3, the CVCA’s public CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. t the TOE always s ainly achieved by FDP_ACC.1/TRM and FCS_COP.1/SIG_VER). The TA protocol uses the result of the PACE authentication (FIA_UID.1/PACE, FIA_UAU.1/PACE) being, in turn, FMT_MTD.1/eID-PIN_Unblock, FIA_UAU.4, FIA_UAU.5 and FCS_CKM.4 represent some required specific properties of the d in FMT_MTD.3, the CVCA’ itten or update by authorised identified role as for establishing this trusted channel is a successful provides an evidence of possessing the Chip Authentication Private Key (SK ). FMT_MTD.1/SK_PICC governs creating/loading FMT_MTD.1/PA_UPD requires that SO containing, amongst other, signature over the PK 296 The security objective OT.Tracing aims that the TOE prevents gathering TOE tracing data by means of unambiguous identifying the RP_Card remotely through establishing or listening to a communication via the contactless interface of the TOE without a priori knowledge of the correct key and certificate as well as the current date are written or update by authorised identified role as required by FMT_MTD.1/ The SFRs FCS_COP.1/SHA and FCS_RND.1 represent the general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 295 The security objective OT.Data_Confidentiality aims tha ensure confidentiality of the User- and TSF-data stored and, after the Terminal- and the Chip Authentication, of these data exchanged. This objective for the data stored is m FDP_ACF.1/TRM. A concrete authorisation level is achieved by the terminal identification/authentication as required by the SFRs FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal (is supported by supported by FCS_CKM.1/DH_PACE. Since PACE can use eID-PIN as the shared secret, using and management of eID-PIN (FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking, FMT_MTD.1/eID-PIN_Resume, FMT_MTD.1/eID-PIN_Activate) also support achievement of this objective. FDP_RIP.1 requires erasing the temporal values of eID-PIN, eID-PUK. protocols used. To allow a verification of the certificate chain as require s public key and certificate as well as the current date are wr required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. This objective for the data exchanged is mainly achieved by FTP_ITC.1/CA using FCS_COP.1/AES. A prerequisite Chip Authentication FIA_API.1/CA using FCS_CKM.1/DH_CA and FCS_CKM.2/DH and possessing the special properties FIA_UAU.5, FIA_UAU.6. The CA PICC SKPICC, FMT_MTD.1/KEY_READ requires to make this key unreadable for a user, so that its value remains confidential. FDP_RIP.1 requires erasing the values of SKPICC and session keys (here: for KEnc). C PICC and used for the Passive Authentication is allowed to be modified by the Personalisation Agent only and, hence, is to consider as trustworthily. The SFRs FCS_COP.1/SHA and FCS_RND.1 represent the general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 116 of 133 Bundesamt für Sicherheit in der Informationstechnik values of shared passwords (CAN, MRZ, eID-PIN, eID-PUK). This objective is achieved as follows: (i) while establishing PACE communication with CAN, MRZ or eID-PUK (non-blocking authentication / authorisation data) – by FIA_AFL.1/PACE; (ii) while establishing PACE communication using eID-PIN (blocking authentication data) – by n and for establishing CA communication (is of of aims enabling verification of the authenticity of the PICC PICC T_MTD.1/KEY_READ requires to needed. ongst other, signature over the PKPICC e modified by the Personalisation Agent only and, hence, is to consider as trustworthily. ims protection against disclosure of confidential User- or/and TSF-data stored on / processed by the TOE. een events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines, correct operation of the TOE by preventing its on outside the normal operating conditions. operation of the TOE and tests of authorised users to verify the integrity of the TSF-data and the embedded software (TSF code) as well as by FPT_FLS.1 requiring entering a secure state of the TOE in FIA_AFL.1/eID-PIN_Blocking; (iii) for listening to PACE communicatio importance for the current PP, if SOC and PKPICC are card-individual) – FTP_ITC.1/PACE; (iv) for listening to CA communication (readable and writable user data: document details data, biographic data, biometric reference data; eSign-PIN) – FTP_ITC.1/CA. 297 The security objective OT.Chip_Auth_Pro TOE as a whole device. This objective is mainly achieved by FIA_API.1/CA using FCS_CKM.1/DH_CA. The CA provides an evidence of possessing the Chip Authentication Private Key (SK ). FMT_MTD.1/SK_PICC governs creating/loading SK , FM make this key unreadable for a user, so that its value remains confidential. FDP_RIP.1 requires erasing the values of SKPICC and session keys (here: for CMAC). The authentication token TPICC is calculated using FCS_COP.1/CMAC. The SFRs FCS_COP.1/SHA and FCS_RND.1 represent the general support for cryptographic operations FMT_MTD.1/PA_UPD requires that SOC containing, am and used for the Passive Authentication is allowed to b 298 The security objective OT.Prot_Abuse_Func aims preventing TOE’s functions being not intended to be used in the operational phase from manipulating and disclosing the User- and TSF- data. This objective is achieved by FMT_LIM.1 and FMT_LIM.2 preventing misuse of test and other functionality of the TOE having not to be used in the TOE’s operational life cycle phase. 299 The security objective OT.Prot_Inf_Leak a This objective is achieved - by FPT_EMSEC.1 for measurement and analysis of the shape and amplitude of signals or the time betw - by FPT_FLS.1 and FPT_TST.1 for forcing a malfunction of the TOE, and - by FPT_PHP.3 for a physical manipulation of the TOE. 300 The security objective OT.Prot_Phys-Tamper aims protection of the confidentiality and integrity of the User- and TSF-data as well as embedded software stored in the TOE. This objective is completely covered by FPT_PHP.3 in an obvious way. 301 The security objective OT.Prot_Malfunction aims ensuring a operati This objective is covered by FPT_TST.1 requiring self tests to demonstrate the correct case of detected failure or operating conditions possibly causing a malfunction. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 117 of 133 302 The rationale related to the security objectives taken over from [6], [7] and [8]225 are exactly the same as given for the respective items of the security policies definitions in sec. 6.3.1 of [6], sec. 6 c. 11.1 of [8], respectively. 6.3.2 SFR’s Dependencies e chosen functional components are analysed, and non-dissolved dep approp 304 The dependency analy thin the description of each SFR in sec. 6.1 above. All depend ts definition in chap. ther fulfilled ulfilment is justified. 305 T for SF ncies related to the se onal requirements taken over from [6], [7] and [8 the same as given for e items of the security policy definitions in sec. 6.3.2 of [6 ] and sec. 11.2 of [8 respectively. 6.3.3 Security Assurance Requirements Rationale 306 The current assurance pa chosen based on the pre-defined assurance package EAL4. This package permi er to gain maximum as positive security engineering based on good co velopment 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 retrofit to an existing product line in an economically feasible way. EAL4 is applicable in those circumsta developers or users moderate to high level of rity in conventional commodity TOEs and are prepared to incur additional security specific engineering costs. higher assurance of the security of the RP_Card’s development and manufacturing, especially for the secure handling of sensitive re-defined EAL4 package due to requiring the functional testing of SFR-enforcing modules. A_VAN.5 provides a higher assurance than the pre-defined EAL4 package, namely requiring a vulnerability analysis to assess the resistance to penetration a ‘A re 310 The set of assurance requirements being part of EAL4 fulfils all dependencies a priori. .3.1 of [7] and se Rationale for 303 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 th endencies are riately explained. sis has directly been made wi encies being expected by CC part 2 and by extended componen 5 are ei or their non-f he rationale R’s depende curity functi ] are exactly the respectiv ], sec. 6.3.2 of [7 ], ckage was ts a develop surance from mmercial de nces where require a independently assured secu 307 The selection of the component ALC_DVS.2 provides a material. 308 The selection of the component ATE_DPT.2 provides a higher assurance than the p 309 The selection of the component AV ttacks performed by an attacker possessing a high attack potential (see also Table 4, entry ttacker’). This decision represents a part of the conscious security policy for the RP_Card quired by the RP_Card Issuer and reflected by the current PP. . OT.SCD/SVD_Gen, OT.Sigy_SigF a 225 incl nd FIA_UAU.1/SSCD. The component FIA_UAU.1/SSCD is re- defined in the current PP in such a way that, additionally to [8], establishing a trusted channel (F thi SFR in TP_ITC.1/CA) between CGA resp. HID and the TOE is allowed before user authentication. Establishing s trusted channel does nor represent any weakening FIA_UAU.1/SSCD compared with the respective [8]. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 118 of 133 Bundesamt für Sicherheit in der Informationstechnik 311 T – ALC_DVS.2, AL4 assurance package: he augmentation of EAL4 chosen comprises the following assurance components: – ATE_DPT.2 and – AVA_VAN.5. 312 For these additional assurance component, all dependencies are met or exceeded in the E Component Dependencies required by CC Part 3 or ASE_ECD Dependency fulfilled by TOE security assurance requirements (only additional to EAL4) ALC_DVS.2 no dependencies - ADV_ARC.1 ADV_ARC.1 ADV_TDS.3 ADV_TDS.3 ATE_DPT.2 ATE_FUN.1 ATE_FUN.1 ADV_ARC.1 ADV_ARC.1 ADV_FSP.4 ADV_FSP.4 ADV_TDS.3 ADV_TDS.3 ADV_IMP.1 ADV_IMP.1 AGD_OPE.1 AGD_OPE.1 AGD_PRE.1 AGD_PRE.1 AVA_VAN.5 ATE_DPT.1 ATE_DPT.2 Table 25: SAR Dependencies 6.3.4 Security Requirements – Internal Consistency 313 The following part of the security requirements rationale shows that the set of security requirements for the TOE consisting of the security functional requirements (SFRs) and the security assurance requirements (SARs) together forms an internally consistent whole. 314 The analysis of the TOE´s security requirements with regard to their mutual supportiveness and internal consistency demonstrates: The dependency analysis in section 6.3.2 ‘Rationale for SFR’s Dependencies’ for the security functional requirements shows that the basis for internal consistency between all defined functional requirements is satisfied. All dependencies between the chosen functional components are analysed and non-satisfied dependencies are appropriately explained. All subjects and objects addressed by more than one SFR in sec. 6.1 are also treated in a consistent way: the SFRs impacting them do not require any contradictory property and behaviour of these ‘shared’ items. The assurance package EAL4 is a pre-defined set of internally consistent assurance requirements. The dependency analysis for the sensitive assurance components in section 6.3.3 Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 119 of 133 ‘Security Assurance Requirements internally consistent as all (additional Rationale’ shows that the assurance requirements are ) dependencies are satisfied and no inconsistency appears. sistency between functional and assurance requirements could only arise, if there are functional-assurance dependencies being not met: an opportunity shown not to arise in sections 6.3.2 nale for SFR’s Dependencies’ and urity Assurance Requirements erm o no inconsi 315 Incon ‘Ratio nale’. 6.3.3 ‘Sec on 6.3.3 ‘S Ratio Furth Rationale’, the ch there are ore, as also discussed in secti ecurity Assurance Requirements sen assurance components are adequate for the functionality of the TOE. So, stencies between the goals of these two groups of security requirements. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 120 of 133 Bundesamt für Sicherheit in der Informationstechnik 7 Glossary and Acronyms Glossary Term Definition Accurate Terminal Certificate A Terminal Certificate is accurate, if the issuing Document Verifier is trusted by the RP_Card’s chip to produce Terminal Certificates with the correct certificate effective date, see [12], sec. 2.2.5. Advanced Electronic Signature Electronic signature according to [15] which meets the following requirements: - uniquely linked to the signatory; - capable of identifying the signatory; - created using means that the signatory can maintain under his sole control and - linked to the data to which it relates in such a manner that any subsequent change of the data is detectable. Advanced Inspection Procedure (with PACE) s on al ally be used by EIS-AIP-PACE A specific order of authentication steps between ePassport and a terminal a required by [12], sec. G.3, namely (i) PACE, (ii) Chip Authenticati (version 1), (iii) Passive Authentication with SOD and (iv). Termin Authentication (version 1). AIP can gener and EIS-AIP-BAC. Agreement propriate d, but not as a legal notion. This term is used in the current PP in order to reflect an ap relationship between the parties involve Application note Optional informative part of the PP containing sensitive supporting information that is considered relevant or useful for the construction, evaluation or use of the TOE. Audit records Write-only-once non-volatile memory area of the RP_Card’s chip to store the Initialisation Data and Pre-personalisation Data. Authentication terminal (ATT) A technical system being operated and used either by a governmental organisation (Official Domestic Document Verifier) or by any other, also commercial organisation and (i) verifying the RP_Card presenter as the RP_Card holder (using secret eID-PIN), (ii) updating a subset of the data of the eID application and (iii) activating the eSign application. An Authentication Terminal is a PCT additionally supporting the Chip Authentication (incl. passive authentication) and the Terminal Authentication protocols in the context of GAP and is authorised by the RP_Card Issuer through the Document Verifier of receiving branch (by issuing terminal certificates) to access a subset of the data stored on the RP_Card. See also par. 23 above and [12], chap. 3.2 and C.4. For the eSign application, it is equivalent to CGA as defined in [8]. Authenticity d in Ability to confirm that the RP_Card itself and the data elements store were issued by the RP_Card Issuer Basic Access Control (BAC) by means of secure messaging with Document Basic Access Keys (see there) based on MRZ information as key seed and access condition to data Security mechanism defined in [9] by which means the MRTD’s chip proves and an inspection system (with BAC) protects their communication Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 121 of 133 Term Definition stored on MRTD’s chip according to LDS. Basic Inspection System with Basic Access Control protocol (BIS-BAC) printed MRZ data for reading the less-sensitive e A technical system being used by an official organisation226 and operated by a governmental organisation (i.e. an Official Domestic or Foreign Document Verifier) and verifying correspondence between the stored and printed MRZ. BIS-BAC implements the terminal’s part of the Basic Access Control protocol and authenticates itself to the RP_Card using the Document Basic Access Keys drawn form data (RP_Card document details data and biographical data) stored on th RP_Card (ePassport application only). See also Application note 4, [12], chap. G.1 and H; also [9]. Basic Inspection System with PACE rated by a Document ocol and is authorised by the RP_Card Issuer through protocol (BIS-PACE) A technical system being used by an inspecting authority and ope governmental organisation (i.e. an Official Domestic or Foreign Verifier) and verifying the RP_Card presenter as the RP_Card holder (for ePassport: by comparing the real biometrical data (face) of the ePass presenter with the stored biometrical data (DG2) of the RP_Card holder). BIS-PACE is a PCT additionally supporting/applying the Passive Authentication prot the Document Verifier of receiving state to read a subset of data stored in the ePassport application on the RP_Card. BIS-PACE in the context of [12] (and of the current PP) is similar, but not equivalent to the Basic Inspection System (BIS) as defined in [5]. See also [12], sec. 3.2.1, G.1 and G.2. Biographical data the (biodata) The personalised details of the RP_Card holder appearing as text in visual and machine readable zones of and electronically stored in the RP_Card. The biographical data are less-sensitive data. Biometric refere data nce Data stored for biometric authentication of the RP_Card holder in the RP_Card as (i) digital portrait and (ii) optional biometric reference data. Card Acc Number (CAN) ess logies), see [12], A short password that is printed or displayed on the document. The CAN is a non-blocking password. The CAN may be static (printed on the Residence Permit Card), semi-static (e.g. printed on a label on the Residence Permit Card) or dynamic (randomly chosen by the electronic RP_Card and displayed by it using e.g. ePaper, OLED or similar techno sec. 3.3 Card Security Object (SOC) nt Signer urity An RFC 3852 CMS Signed Data Structure signed by the Docume (DS). It is stored in the RP_Card (EF.CardSecurity, see [12], table A.1 and sec. A.1.2) and carries the hash values of different Data Groups as defined in [12], Appendix A. It shall also carry the Document Signer Certificate (CDS), [12], A.1.2. Please note that [12] uses the same notation SOC for Card and Chip Sec Objects. Card and Chip Security Objects may differ with respect to the contained Chip Authentication Public Key (PKPICC): If, for privacy reasons, multiple RP_Cards share the same Chip Authentication Public Keys (i.e. generation keys), the Card Security Object shall contain generation PKPICC 226 an inspecting authority; concretely, by a control officer Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 122 of 133 Bundesamt für Sicherheit in der Informationstechnik Term Definition and Chip Security Object – chip-individual PKPICC., cf. [12], sec. A.1.2. Certificate chain n Authority Verifying Certification Authority Certificate y it contains Hierarchical sequence of Terminal Certificate (lowest level), Document Verifier Certificate and Country Verifying Certificatio Certificates (highest level), where the certificate of a lower lever is signed with the private key corresponding to the public key in the certificate of the next higher level. The Country is signed with the private key corresponding to the public ke (self-signed certificate). Certification Provider (CSP) Service An organisation issuing certificates and providing other services related to electronic signatures. There can be ‘common’ and ‘qualified’ CSP: A ‘qualified’ Certification Service Provider can also issue qualified certificates. A CSP is the Certification Service Provider in the sense of [8]. Chip Security t Signer Object (SOC) An RFC 3852 CMS Signed Data Structure signed by the Documen (DS). It is stored in the RP_Card (EF.ChipSecurity, see [12], table A.1 and sec. A.1.2) and carries the hash values of different Data Groups as defined in [12], Appendix A. It shall also carry the Document Signer Certificate (CDS), [12], A.1.2. Please note that [12] uses the same notation SOC for Card and Chip Security Objects. Card and Chip Security Objects may differ with respect to the contained Chip Authentication Public Key (PKPICC): If, for privacy reasons, multiple RP_Cards share the same Chip Authentication Public Keys (i.e. eneration keys), th g e Card Security Object shall contain generation PKPICC and Chip Security Object – chip-individual PKPICC., cf. [12], sec. A.1.2. Counterfeit An unauthorised copy or reproduction of a genuine security document made by whatever means. [9] Country Signing ing Certification Authority Public Key stored in CertA Certificate (CCSCA) Certificate of the Country Sign (KPuCSCA) issued by Country Signing Certification Authority and the rightful terminals. Country Signing Certification Authority (CSCA) ng the policy of the RP_Card Issuer with respect to The rds and for An organisation enforci confirming correctness of user and TSF data stored in the RP_Card. CSCA represents the country specific root of the PKI for the RP_Ca creates the Document Signer Certificates within this PKI. The CSCA also issues the self-signed CSCA Certificate (CCSCA) having to be distributed by strictly secure diplomatic means, see. [9], 5.1.1. The Country Signing Certification Authority issuing certificates Document Signers (cf. [9]) and the domestic CVCA may be integrated into a single entity, e.g. a Country CertA. However, even in this case, separate key pairs must be used for different roles, see [12], sec. 2.2.1. Country Verifying Certification Authority (CVCA) Updates of the public key of the CVCA are distributed in form of CVCA Link-Certificates, see [12], chap. 2.2.1. The Country Signing Certification Authority (CSCA) issuing certificates for An organisation enforcing the privacy policy of the RP_Card Issuer with respect to protection of user data stored in the RP_Card (at a trial of a terminal to get an access to these data). The CVCA represents the country specific root of the PKI for the rightful terminals (EIS-AIP-BAC, EIS-GAP, ATT, SGT) and creates the Document Verifier Certificates within this PKI. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 123 of 133 Term Definition Document Signers (cf. [9]) and the domestic CVCA may be integrated into a single entity, e.g. a Country CertA. However, even in this case, separate key pairs must be used for different roles, see [12], sec. 2.2.1. Current date d in a valid CVCA Link The most recent certificate effective date containe Certificate, a DV Certificate or an Accurate Terminal Certificate known to the TOE, see [12], sec. 2.2.5. CV Certificate Card Verifiable Certificate according to [12], appendix C. CVCA link ertification Certificate Certificate of the new public key of the Country Verifying C 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 expiration date of the certificate for the old key. Digital Signature Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient; see [23]. Document B Access Keys asic Pair of symmetric (two-key) Triple-DES keys used for secure messaging with encryption (key KBENC) and message authentication (key KBMAC) of data transmitted between the TOE and an inspection system using BAC [9]. They are derived from the MRZ and used within BAC to authenticate an entity able to read the printed MRZ of the passport book; see [12], H.1. Document Details Data Data printed on and electronically stored in the RP_Card representing the document details like document type, issuing state, document number, date of issue, date of expiry, issuing authority. The document details data are less-sensitive data. Document Security Object (SOD) y Data. It is stored in the A RFC 3369 CMS Signed Data Structure, signed by the Document Signer (DS). Carries the hash values of the LDS Data Groups: A hash for each Data Group in use shall be stored in the Securit ePassport application (EF.SOD) of the RP_Card. It may carry the Document Signer Certificate (CDS); see [9]. Document Signer (DS) An organisation enforcing the policy of the CSCA and signing the Card/Chip and Document Security Objects stored on the RP_Card for passive authentication. A Document Signer is authorised by the national CSCA issuing the Document Signer Certificate (CDS), see [12], chap. 1.1 and [9]. This role is usually delegated to a Personalisation Agent. Document Verifier (DV) An organisation enforcing the policies of the CVCA and of a Service Provider (governmental or commercial organisation) and managing terminals belonging together (e.g. terminals operated by a State’s border police), by – inter alia – issuing Terminal Certificates. A Document Verifier policy of the domestic CVCA being run by the RP_Card Issuer; a foreign is therefore a CertA, authorised by at least the national CVCA to issue certificates for national terminals, see [12], chap. 2.2.2. There can be Domestic and Foreign DV: A domestic DV is acting under the DV is acting under a policy of the respective foreign CVCA (in this case 227 the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current PP in order to reflect an appropriate relationship between the parties involved. ey CVCA. 228 Existing of such an agreement may be technically reflected by means of issuing a CCVCA-F for the Public K of the foreign CVCA signed by the domestic Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 124 of 133 Bundesamt für Sicherheit in der Informationstechnik Term Definition there shall be an appropriate agreement between the RP_Card Issuer und a foreign CVCA ensuring enforcing the RP_Card Issuer’s privacy policy). 227,228 Eavesdropper RP_Card and the A threat agent reading the communication between the Service Provider to gain the data on the RP_Card. eID application A part of the TOE containing the non-executable, related user data and the data needed for authentication; this application is intended to be used fo accessing official and commercial services, which require access to the user data stored in the context of this application; see [12], sec. 3.1.2. r Electronic Signature with other Data in electronic form that is attached to or logically associated electronic data and that serves as a method of authentication; see [15]. Enrolment the tes The process of collecting biometric samples from a person and subsequent preparation and storage of biometric reference templa representing that person's identity; see [9]. ePassport cl. application A part of the TOE containing the non-executable, related user data (in biometric) as well as the data needed for authentication (incl. MRZ); this application is intended to be used by authorities, amongst other as a machine readable travel document (MRTD). See [12], sec. 3.1.1. eSign application s te A part of the TOE containing the non-executable data needed for generating qualified electronic signatures on behalf of the RP_Card holder as well as for authentication; this application is intended to be used in the context of official and commercial services, where a qualified electronic signature of the RP_Card holder is required. The eSign application is optional: it mean that it can optionally be activated229 on the RP_Card by a Certification Service Provider (or on his behalf) using the ATT with an appropria effective authorisation level. See [12], sec. 3.1.3. Extended Access Control tional iometric reference data and (iii) protects the confidentiality and integrity of aging. Security mechanism identified in [9] by which means the MRTD’s chip (i) verifies the authentication of the inspection systems authorised to read the optional biometric reference data, (ii) controls the access to the op b the optional biometric reference data during their transmission to the inspection system by secure mess Extended Inspection System using AIP with BAC (EIS-AIP- BAC) isat n (i.e. an Official Domestic or Foreign Document t e RP_Card presenter as the RP_Card holder (for c Inspection System (BIS) in the sense of [5] ion protocols in the context of AIP A technical system being used by an inspecting authority and operated by a governmental organ io Verifier) and verifying h ePassport: by comparing the real biometrical data (face, fingerprint or iris) of the RP_Card presenter with the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-AIP-BAC is a Basi additionally supporting/applying Chip Authentication (incl. passive authentication) and Terminal Authenticat and is authorised by the RP_Card Issuer through the Document Verifier of receiving state to read a subset of data stored on the RP_Card. EIS-AIP-BAC in the context of [12] (and of the current PP) is equivalent to 22 d’ means (i) ge lly store there t 9 ‚activate optiona nerate and store in the eSign application one or more signature key pairs and (ii) he related certificates Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 125 of 133 Term Definition the Extended Inspection System (EIS) as defined in [6]. Extended Inspection System using AIP with PACE (EIS- AIP-PACE) erprint or iris) by the RP_Card Issuer A technical system being used by an inspecting authority and operated by a governmental organisation (i.e. an Official Domestic or Foreign Document Verifier) and verifying the RP_Card presenter as the RP_Card holder (for ePassport: by comparing the real biometrical data (face, fing of the RP_Card presenter with the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-AIP-PACE is a PCT additionally supporting/applying Chip Authentication (incl. passive authentication) and Terminal Authentication protocols in the context of AIP and is authorised through the Document Verifier of receiving state to read a subset of data stored on the RP_Card. EIS-AIP-PACE in the context of [12] is similar, but not equivalent to the Extended Inspection System (EIS) as defined in [6]. Extended Inspection System using GAP (EIS-GAP) _Card presenter as the RP_Card holder (for plying Chip Authentication ic and Extended g to [12], sec. 3.1.1. A technical system being used by an inspecting authority and operated by a governmental organisation (i.e. an Official Domestic or Foreign Document Verifier) and verifying the RP ePassport: by comparing the real biometrical data (face, fingerprint or iris) of the RP_Card presenter with the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-GAP is a PCT additionally supporting/ap (incl. passive authentication) and Terminal Authentication protocols in the context of GAP and is authorised by the RP_Card Issuer through the Document Verifier of receiving state to read a subset of data stored on the RP_Card. EIS-GAP in the context of [12] (and of the current PP) is similar, but not equivalent to the Extended Inspection System (EIS) as defined in [6]. The specification [12], sec. 3.2 differ between Bas Inspection Systems, whereby - the BIS can only perform Standard Inspection Procedure according to [12], sec. G.2 and - the EIS can perform (i) Advanced Inspection Procedure according to [12], sec. G.3 or (ii) General Authentication Procedure accordin All roles and authorisation levels as described in C.4 of [12] exclusively refer to EIS. Forgery Fraudulent alteration of any part of the genuine document, e.g. changes to the biographical data or portrait; see [9]. General Authentication 12], sec. 3.4, namely (i) PACE, (ii) Terminal Authentication Procedure A specific order of authentication steps between an RP_Card and a terminal as required by [ (version 2), (iii) Passive Authentication with SOC and (iv) Chip Authentication (version 2) (and an additional Passive Authentication with SOD, see [12], sec. 3.1.1). GAP is used by EIS-GAP, ATT and SGT. Global Interoperability rocess data The capability of inspection systems (either manual or automated) in different States throughout the world to exchange data, to p received from systems in other States, and to utilise that data in inspection operations in their respective States. Global interoperability is a major Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 126 of 133 Bundesamt für Sicherheit in der Informationstechnik Term Definition objective of the standardised specifications for placement of both eye- readable and machine readable data in all MRTDs; see [9]. IC Dedicated Software Software developed and injected into the chip hardware by the IC manufacturer. Such software might support special functionality of the IC hardware and be used, amongst other, for implementing delivery procedures between different players. The usage of parts of the IC Dedicated Software might be restricted to certain life cycle phases. IC Embedd Software ed Software embedded in an IC and not being designed by the IC developer. The IC Embedded Software is designed in the design life cycle phase and embedded into the IC in the manufacturing life cycle phase of the TOE. Impostor A person who applies for and obtains a document by assuming a false name and identity, or a person who alters his or her physical appearance to represent himself or herself as another person for the purpose of using that person’s document; see [9]. Improperly vel r visa; (c) someone else’s travel document or visa; or (d) no documented person A person who travels, or attempts to travel with: (a) an expired tra document or an invalid visa; (b) a counterfeit, forged or altered travel document o travel document or visa, if required; see [9]. Initialisation Data d manufacturer and injected into the non- rcuits manufacturer. These data are, for IC identification as RP_Card material Any data defined by the RP_Car volatile memory by the Integrated Ci instance, used for traceability and for (IC identification data). Inspection RP_Card presented to it by fying its authenticity as the RP_Card holder. The act of an inspection authority examining an an RP_Card presenter and veri See also [9]. Inspection system PACE for this PP. see EIS-GAP, EIS-AIP-BAC and BIS- see also EIS-AIP-PACE and BIS-BAC for general information Integrated circuit (IC) emory ard’s chip is an integrated circuit. Electronic component(s) designed to perform processing and/or m functions. The RP_C Integrity Ability to confirm the RP_Card and its data elements stored upon have not been altered from that created by the RP_Card Issuer. Issuing Organisation ation authorised to issue an official travel document (e.g. the United passer); see [9]. Organis Nations Organisation, issuer of the Laissez- Issuing State The country issuing the MRTD; see [9]. Logical Data Structure (LDS) The collection of groupings of Data Elements stored in the optional capacity expansion technology [9]. The capacity expansion technology used is the MRTD’s chip. Machine reada travel documen (MRTD) ble t Official document issued by a state or organisation 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; see [9]. Machine readable zone (MRZ) ealable secret that is derived from the 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; see [9]. The MRZ-Password is a restricted-rev Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 127 of 133 Term Definition machine readable zone and may be used for both PACE and BAC. Machine-verifiable biometrics feature ument in a form A unique physical personal identification feature (e.g. an iris pattern, fingerprint or facial characteristics) stored on a travel doc that can be read and verified by machine; see [9]. Malicious equipment A technical device being expected, but not possessing a valid, certified key pair for its authentication; validity of its certificate is not verifiable up to the respective root CertA (CVCA for a terminal and CSCA for an RP_Card). Manufacturer Generic term for the IC Manufacturer producing integrated circuit and the RP_Card Manufacturer completing the IC to the RP_Card. The Manufacturer is the default user of the TOE during the manufacturing life cycle phase. The TOE itself does not distinguish between the IC Manufacturer and RP_Card Manufacturer using this role Manufacturer. Metadata of a CV Certificate cate Profile Identifier, (optional). Data within the certificate body (excepting Public Key) as described in [12], sec. C.1.3. The metadata of a CV certificate comprise the following elements: - Certifi - Certificate Authority Reference, - Certificate Holder Reference, - Certificate Holder Authorisation Template, - Certificate Effective Date, - Certificate Expiration Date, - Certificate Extensions PACE Terminal (PCT) A technical system verifying correspondence between the password stored in the RP_Card and the related value presented to the terminal by the See [12], chap. 3.3, 4.2, table 1.2 and G.2. RP_Card presenter. PCT implements the terminal’s part of the PACE protocol and authenticates itself to the RP_Card using a shared password (CAN, eID-PIN, eID-PUK or MRZ). Passive authentication Security mechanism implementing (i) verification of the digital signature of the Card/Chip or Document Security Object and (ii) comparing the hash values of the read data fields with the hash values contained in the Card/Chip or Document Security Object. See [12], sec. 1.1. Password Authenticated (PACE) mmunication establishment protocol defined in [12], sec. 4.2. The PACE Protocol is a password authenticated Diffie-Hellman key agreement the sword π). Based on this authentication, PACE also Connection Establishment A co protocol providing implicit password-based authentication of communication partners (e.g. smart card and the terminal connected): i.e. PACE provides a verification, whether the communication partners share the same value of a pas provides a secure communication, whereby confidentiality and authenticity of data transferred within this communication channel are maintained. Personal Identification Number (PIN) A short secret password being only known to the RP_Card holder. PIN is a blocking password, see [12], sec. 3.3. Personalisation The process by which the Personalisation Data are stored in and unambiguously, inseparably associated with the RP_Card. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 128 of 133 Bundesamt für Sicherheit in der Informationstechnik Term Definition Personalisation Agent ntity of the RP_Card holder for the biographic data in [12], (iv) writing the An organisation acting on behalf of the RP_Card Issuer to personalise the RP_Card for the RP_Card holder by some or all of the following activities: (i) establishing the ide the RP_Card, (ii) enrolling the biometric reference data of the RP_Card holder, (iii) writing a subset of these data on the physical Residence Permit Card (optical personalisation) and storing them in the RP_Card (electronic personalisation) for the RP_Card holder as defined in document details data, (v) writing the initial TSF data, (vi) signing the Card/Chip Security Object and the Document Security Object (ePassport) defined in [9] (in the role of DS). Please note that the role ‘Personalisation Agent’ may be distributed among several institutions according to the operational policy of the RP_Card Issuer. Generating signature key pair(s) is not in the scope of the tasks of this role. Personalisation Data memory of the TOE by the Personalisation Agent in the life A set of data incl. (i) individual-related data (biographic and biometric data, signature key pair(s) for the eSign application, if installed) of the RP_Card holder, (ii) dedicated document details data and (iii) dedicated initial TSF data (incl. the Card/Chip Security Object, if installed, and the Document Security Object). Personalisation data are gathered and then written into the non-volatile cycle phase card issuing. PIN Unblock Key (PUK) A long secret password being only known to the RP_Card holder. The PUK is a non-blocking password, see [12], sec. 3.3. Pre-personalisation Data ceability of the non-personalised RP_Card and/or to Any data that is injected into the non-volatile memory of the TOE by the Manufacturer for tra secure shipment within or between the life cycle phases manufacturing and card issuing. Pre-personalised RP_Card’s chip RP_Card’s chip equipped with a unique identifier and a unique asymmetric Authentication Key Pair of the chip. Qualified Electronic Signature ertified in a qualified certificate; see [15], Art. 5 (1) and Advanced electronic signature according to [15] that has been created with an SSCD by a key c [8]. Receiving State The Country to which the RP_Card holder is applying for entry; see [9]. Reference data Data enrolled for a known identity and used by the verifier to check the verification data provided by an entity to prove this identity in an authentication attempt. Remote terminal device directly communicating with the TOE and using the A remote technical infrastructure between them (Internet, a local RF-terminal) merely as a message carrier. Only after Chip Authentication when a secure end-to- end connection between the TOE and remote terminal is established, the TOE grants access to the data of the eID application, see [12], sec. 3.4.1. Residence Permit Card (physical and electronic) An optically and electronically readable document in form of a paper/plastic cover and an integrated smart card. The Residence Permit Card is used in order to verify that identity claimed by the Residence Permit Card presenter is commensurate with the identity of the Residence Permit Card holder stored on/in the card. Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 129 of 133 Term Definition Restricted Identification er nal sector (pseudo-anonymisation) and supporting Restricted Identification aims providing a temporary RP_Card identifi being specific for a termi revocation features (sec. 2.3, 4.1, 4.5 of [12]). The security status of RP_Card is not affected by Restricted Identification. RF-terminal according A device being able to establish communication with an RF-chip to ISO/IEC 14443 Rightful equipment (rightful terminal or rightful Card) , EIS-AIP-BAC and BIS-PACE (see Inspection System) or ATT or for a terminal is CVCA and for a Card – CSCA. A technical device being expected and possessing a valid, certified key pair for its authentication, whereby the validity of the related certificate is verifiable up to the respective root CertA. A rightful terminal can be either EIS-GAP SGT. A terminal as well as a Card can represent the rightful equipment, whereby the root CertA RP_Card (electronic) The contactless smart card integrated into the plastic, optical readable cover and providing the following applications: ePassport, eID and eSign (optionally) RP_Card holder A person for whom the RP_Card Issuer has personalised the RP_Card. RP_Card Issuer ) horised to issue an electronic Residence Permit Card to the (issuing authority Organisation aut RP_Card holder RP_Card presenter A person presenting the RP_Card to a terminal and claiming the identity of the RP_Card holder. Secondary image A repeat image of the holder’s portrait reproduced elsewhere um in the doc ent by whatever means; see [9]. Secure messa combined mode ode ging in Secure messaging using encryption and message authentication c according to ISO/IEC 7816-4 Service Provider be minals An official or commercial organisation providing services which can used by the RP_Card holder. Service Provider uses rightful ter managed by a DV. Signature terminal (SGT) CT additionally supporting the Chip the ccess a subset of the data stored on the P_Card. is equivalent – as a A technical system used for generation of electronic signatures. A Signature Terminal is a P Authentication (incl. passive authentication) and the Terminal Authentication protocols in the context of GAP and is authorised by RP_Card Issuer through the Document Verifier of receiving branch (by issuing terminal certificates) to a R See also par. 23 above and [12], chap. 3.2 and C.4. It general term – to SCA and HID as defined in [8]. Skimming Imitation of a rightful terminal to read the RP_Card or parts of it via the contactless communication channel of the TOE without knowledge of the printed MRZ, CAN, eID-PIN or eID-PUK data. Standard Inspection Procedure ed by BIS-PACE and BIS-BAC. A specific order of authentication steps between an RP_Card (ePassport only) and a terminal as required by [12], sec. G.2, namely (i) PACE and (ii) Passive Authentication with SOD. SIP can generally be us Terminal A terminal is any technical system communicating with the TOE through the contactless interface. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 130 of 133 Bundesamt für Sicherheit in der Informationstechnik Term Definition The role ‘Terminal’ is the default role for any terminal being recognised by the TOE as neither PCT nor BIS-PACE nor EIS-AIP-BAC nor EIS-GAP nor ATT nor SGT (‘Terminal’ is us he RP_Card presenter). ed by t Terminal risation Level risations defined by the rtificate and Country Authority which shall be all valid for the Current at terminal by RP_Card holder using Autho Intersection of the Certificate Holder Autho Terminal Certificate, the Document Verifier Ce Verifying Certification Date. It can additionally be restricted CHAT. TOE tracing data red by inconspicuous (for the RP_Card holder) recognising Technical information about the current and previous locations of the RP_Card gathe the RP_Card Travel document official document of identity issued by a state or ay be used by the rightful holder for international A passport or other organisation which m travel; see [9]. TSF data Data created by and for the TOE that might affect the operation of the TOE (CC part 1 [1]). Unpersonalised RP_Card RP_Card material prepared to produce a personalised RP_Card containing an initialised and pre-personalised RP_Card’s chip. User Data d in the context of the d in [12] and ticated l E is considered here e signature key within the eSign application; from this private signature key of the RP_Card holder is also d as ‘user data’). ta: user that does not affect the operation of the ation stored in TOE resources that can be ance with the SFRs and upon which the part 2 [2]). All data (being not authentication data) store applications of the RP_Card as define (i) being allowed to be read out or written solely by an authen 2], sec. 3.2) respectively terminal (in the sense of [1 (ii) being allowed to be used solely by an authenticated terminal (in the sense of [12], sec. 3.2) (the private Restricted Identification key; since the Restricted Identification according to [12], sec. 4.5 represents just a functionality of the RP_Card, the key materia needed for this functionality and stored in the TO as ‘user data’) respectively (iii) being allowed to be used solely by the authenticated RP_Card holder (the privat point of view, the considere CC give the following generic definitions for user da Data created by and for the TSF (CC part 1 [1]). Inform operated upon by users in accord TSF places no special meaning (CC Verification data an authentication attempt to prove their ifier. The verifier checks whether the verification data data known for the claimed identity. Data provided by an entity in identity to the ver match the reference Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 131 of 133 Acronyms Acronym Term AIP Advanced Inspection Procedure, [12], sec. 3.1.1 ATT Authentication Terminal as defined in [12], sec. 3.2 BAC Basic Access Control BIS Basic Inspection System BIS-BAC em with BAC (equivalent to Basic Inspection System Basic Inspection Syst as used in [5]) BIS-PACE Basic Inspection System with PACE (see [12], sec. 3.1.1, 3.2.1) CA Chip Authentication CAN Card Access Number CC Common Criteria CertA Certification Authority (the author dispensed with the usual abbreviation ‘CA’ in order to avoid a collision with ‘Chip Authentication’) CGA Certificate generation application, please refer to [8]. In the current context, it is represented by ATT for the eSign application. CHAT Certificate Holder Authorization Template DTBS Data to be signed, please refer to [8] DTBS/R Data to be signed or its unique representation, please refer to [8] EAC Extended Access Control EIS-AIP-BAC Extended Inspection System with BAC (equivalent to EIS as used in [6]) EIS-AIP-PACE Extended Inspection System with PACE (see [12], sec. 3.1.1, 3.2.1) EIS-GAP Extended Inspection System using GAP (see [12], sec. 3.1.1, 3.2.1) GAP General Authentication Procedure (see [12], sec. 3.4) HID Human Interface Device, please refer to [8]. It is equivalent to SGT in the current context. MRZ Machine readable zone n.a. Not applicable OSP Organisational security policy PACE Password Authenticated Connection Establishment PCD Proximity Coupling Device PCT PACE-authenticated terminal PICC Proximity Integrated Circuit Chip PIN Personal Identification Number PP Protection Profile PUK PIN Unblock Key RAD Reference Authentication Data, please refer to [8] RF Radio Frequency SAR Security assurance requirements SCA Signature creation application, please refer to [8]. It is equivalent to SGT in the current context. Version 1.00 13th August 2010 , Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 page 132 of 133 Bundesamt für Sicherheit in der Informationstechnik Acronym Term SCD Signature Creation Data, please refer to [8]; the term ‘private signature key within the eSign application’ is synonym within the current PP. SFR Security functional requirement SGT Signature Terminal as defined in [12], sec. 3.2 SIP Standard Inspection Procedure, see [12], sec. 3.1.1 SV Signature Verification Data, please refer to [8] D TA Terminal Authentication TO Target of Evaluation E TSF TOE security functionality TS TOE Security Policy (defined by the current document) P VAD Verification Authentication Data, please refer to [8] Common Criteria Protection Profile Version 1.00 13th August 2010 , Electronic Residence Permit Card (RP_Card PP) BSI-CC-PP-0069 Bundesamt für Sicherheit in der Informationstechnik page 133 of 133 8 Bibliography Common Criteria [1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; CCMB-2009-07-001, Version 3.1, Revision 3, July 2009 [2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components; CCMB-2009-07-002, Version 3.1, Revision 3, July 2009 n Criteria for Information Technology Security Evaluation, Part 3: Security Assurance ents; CCMB-2009-07-003, Version 3.1, Revision 3, July 2009 Protect dure n, dable Travel Documents – Part 3: Machine Readable Official Travel Documents, volume 2, ICAO, 3rd edition, 2008. Technical Guidelines and Directives [11] Technical Guideline TR-03110 Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), TR-03110, version 1.11, 21.02.2008, Bundesamt für Sicherheit in der Informationstechnik (BSI) [12] Technical Guideline TR-03110 Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE) and Restricted Identification (RI), TR-03110, version 2.03, 24.03.2010, Bundesamt für Sicherheit in der Informationstechnik (BSI)230 [3] Commo Requirem [4] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; CCMB-2009-07-004, Version 3.1, Revision 3, July 2009 ion Profiles [5] Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Basic Access Control, BSI-CC-PP-0055-2009, version 1.10, 25th March 2009 [6] Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Extended Access Control, BSI-CC-PP-0056-2009, version 1.10, 25th March 2009 [7] Common Criteria Protection Profile Electronic Passport using Standard Inspection Proce with PACE, BSI-CC-PP-0068-2010, version 0.92, 30th April 2010 [8] Protection Profiles for Secure Signature Creation Device – Part 2: Device with key generatio EN 14169-1:2009, ver. 1.03, 2009-12, BSI-CC-PP-0059-2009 ICAO [9] ICAO Doc 9303-1, Specifications for electronically enabled passports with biometric identification capabilities. In Machine Readable Travel Documents – Part 1: Machine Readable Passport, volume 2, ICAO, 6th edition, 2006 [10] ICAO Doc 9303-3, Specifications for electronically enabled official travel documents with biometric identification capabilities. In Machine Rea 230 please note that there may be an errata sheet published on www.bsi.bund.de (Publikationen -> Technische Richtlinien -> Technische Richtlinie Advanced Security Mechanisms for Machine Readable Travel Documents (BSI TR-03110)). Version 1.00, 13th August 2010 Common Criteria Protection Profile BSI-CC-PP-0069 Electronic Residence Permit Card (RP_Card PP) page 134 of 133 Bundesamt für Sicherheit in der Informationstechnik [13] Technische Richtlinie TR-03116-2, eCard-Projekte der Bundesregierung, Teil 2 – Hoheitliche Ausweisdokumente, Stand 2010, Bundesamt für Sicherheit in der Informationstechnik (BSI)F 231 [14] Technical Guideline TR-03111 Elliptic Curve Cryptography, TR-03111, version 1.11, 17.04.2009, Bundesamt für Sicherheit in der Informationstechnik (BSI) [15] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999 on a Community framework for electronic signatures [16] EU – Residence permit Specification, Annex to Commission Decision C(2009) 3770, version 1.0 Cryptography [17] Übersicht über geeignete Algorithmen: Bekanntmachung zur Elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung, Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahn, 17.11.2008, Veröffentlicht am 27.01.2009 im Bundesanzeiger Nr. 13, S. 346 [18] Federal Information Processing Standards Publication 197, ADVANCED ENCRYPTION STANDARD (AES), U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, November 26, 2001 [19] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories Technical Note, Version 1.4, Revised November 1, 1993 [20] Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800-38B, National Institute of Standards and Technology, May 2005 [21] Secure hash standard (and Change Notice to include SHA-224), FIPS PUB 180-2, National Institute of Standards and Technology, 2002 Other Sources [22] ISO 14443, Identification cards – Contactless integrated circuit(s) cards – Proximity cards, 2000 [23] ISO 7498-2 (1989): ‘Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture’ 231 please note that this Technical Guideline may annually be updated, see HUwww.bsi.bund.deUH (Publikationen -> Technische Richtlinien -> Technische Richtlinie fuer die eCard-Projekte der Bundesregierung (BSI TR-03116)).