Dokumentenkennung: CD.TCOS.ASE Dateiname: ASE TCOS Identity Card 1.0.2 (IFX).docx Stand: 12.07.2012 Version: 1.0.2 Hardware Basis: SLE78CLX1440P Autor: Ernst-G. Giessmann Geltungsbereich: TeleSec Entwicklungsgruppe Vertraulichkeitsstufe: Öffentlich     T-Systems International GmbH, 2012 Weitergabe sowie Vervielfältigung dieser Dokumentation, Verwer- tung und Mitteilung ihres Inhalts sind nicht gestattet, soweit nicht ausdrücklich zugestanden. Zuwiderhandlungen verpflichten zum Schadensersatz. Alle Rechte für den Fall der Patenterteilung oder der Gebrauchsmuster-Eintragung vorbehalten. Specification of the Security Target TCOS Identity Card Version 1.0 Release 2/SLE78CLX1440P Version: 1.0.2/20120712 Security Target TCOS eID_Card/SLE78CLX1440P 2/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 History Version Date Remark 1.0.2 2012-07-12 Final Version Security Target TCOS eID_Card/SLE78CLX1440P 3/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Contents 1 ST Introduction....................................................................................................................... 5 1.1 ST Reference ........................................................................................................................... 5 1.2 TOE Reference......................................................................................................................... 5 1.3 TOE Overview .......................................................................................................................... 5 1.4 TOE Description ....................................................................................................................... 7 1.4.1 TOE Definition ..................................................................................................................... 7 1.4.2 TOE security features for operational use........................................................................... 8 1.4.3 Non-TOE hardware/software/firmware................................................................................ 8 1.4.4 Life Cycle Phases Mapping................................................................................................. 9 1.4.5 TOE Boundaries................................................................................................................ 12 2 Conformance Claim.............................................................................................................. 13 2.1 CC Conformance Claims........................................................................................................ 13 2.2 PP Claims............................................................................................................................... 13 2.3 Package Claims...................................................................................................................... 13 2.4 Conformance Rationale.......................................................................................................... 13 3 Security Problem Definition ................................................................................................ 15 3.1 Introduction............................................................................................................................. 15 3.2 Threats ................................................................................................................................... 20 3.3 Organizational Security Policies............................................................................................. 23 3.4 Assumptions........................................................................................................................... 26 4 Security Objectives .............................................................................................................. 28 4.1 Security Objectives for the TOE............................................................................................. 28 4.2 Security Objectives for the Operational Environment ............................................................ 31 4.3 Security Objective Rationale .................................................................................................. 36 5 Extended Components Definition....................................................................................... 39 5.1 FAU_SAS Audit data storage................................................................................................. 39 5.2 FCS_RND Generation of random numbers ........................................................................... 39 5.3 FIA_API Authentication Proof of Identity................................................................................ 40 5.4 FMT_LIM Limited capabilities and availability........................................................................ 41 5.5 FPT_EMSEC TOE Emanation ............................................................................................... 42 6 Security Requirements ........................................................................................................ 43 6.1 Security Functional Requirements for the TOE...................................................................... 43 6.1.1 Overview............................................................................................................................ 43 6.1.2 Class FCS Cryptographic Support .................................................................................... 46 6.1.3 Class FIA Identification and Authentication....................................................................... 54 6.1.4 Class FDP User Data Protection....................................................................................... 63 6.1.5 Class FTP Trusted Path/Channels.................................................................................... 70 6.1.6 Class FAU Security Audit.................................................................................................. 72 6.1.7 Class FMT Security Management..................................................................................... 73 6.1.8 Class FPT Protection of the Security Functions................................................................ 85 Security Target TCOS eID_Card/SLE78CLX1440P 4/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 6.2 Security Assurance Requirements for the TOE ..................................................................... 89 6.3 Security Requirements Rationale........................................................................................... 89 6.3.1 Security Functional Requirements Rationale.................................................................... 89 6.3.2 Rationale for SFR’s Dependencies ................................................................................... 95 6.3.3 Security Assurance Requirements Rationale.................................................................... 98 6.3.4 Security Requirements – Internal Consistency ................................................................. 99 7 TOE Summary Specification ............................................................................................. 100 7.1 Access control to the User Data stored in the TOE ............................................................. 100 7.2 Secure data exchange ......................................................................................................... 100 7.3 Identification and authentication of users and components ................................................. 101 7.4 Audit ..................................................................................................................................... 101 7.5 Generation of the eSign Signature Key Pair ........................................................................ 102 7.6 Creation of Digital Signatures............................................................................................... 102 7.7 Management of and access to TSF and TSF-data .............................................................. 102 7.8 Reliability of the TOE security functionality.......................................................................... 103 7.9 TOE SFR Statements........................................................................................................... 103 7.10 Statement of Compatibility ................................................................................................... 109 7.10.1 Relevance of Hardware TSFs ......................................................................................... 109 7.10.2 Compatibility: TOE Security Environment....................................................................... 109 7.10.3 Conclusion....................................................................................................................... 118 7.11 Assurance Measures............................................................................................................ 118 Appendix Glossary and Acronyms.................................................................................................. 120 References.......................................................................................................................................... 127 Security Target TCOS eID_Card/SLE78CLX1440P 5/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 1 ST Introduction 1 This section provides document management and overview information that are required a potential user of the TOE to determine, whether the TOE fulfils her requirements. 1.1 ST Reference 2 Title: Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 TOE: TCOS Identity Card Version 1.0 Release 2/SLE78CLX1440P Sponsor: T-Systems International GmbH Editor(s): Ernst-G. Giessmann, T-Systems TeleSec CC Version: 3.1 (Revision 3) Assurance Level: EAL4 augmented. General Status: Final Version Version Number: 1.0.2 Date: 2012-07-12 Certification ID: BSI-DSZ-CC-0818 Keywords: Electronic Identity Card, ID_Card, ePassport, eID, eSign, MRTD, PACE, EAC 3 Whereas the TCOS Passport Version 1 series refers to contactless integrated circuit chip of machine readable travel documents implementing the ICAO application “Basic Access Control” only, the chips of Version 2 of the Passport series can provide additio- nally the Extended Access Control according to ICAO document [ICAOPKI]. The diffe- rent TCOS Passport Version 2.0 Release 2 implementations cover machine readable travel documents with “Basic Access Control” only and with “Extended Access Control”. They will be distinguished as “Release 2 BAC” and “Release 2 EAC” products. 4 The TCOS ID-Cards are also products of TCOS but their version numbers are not rela- ted to these TCOS Passport Versions. They do not support “Basic Access Control” but “Extended Access Control” for the ePassport application. 1.2 TOE Reference 5 The Security Target refers to the Product “TCOS Identity Card Version 1.0 Release 2” (TOE) of T-Systems for CC evaluation. 1.3 TOE Overview 6 The Target of Evaluation (TOE) addressed by the current Security Target is the elec- tronic Identity Card (ID_Card) representing a contactless smart card programmed accor- Security Target TCOS eID_Card/SLE78CLX1440P 6/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 ding to the Technical Guideline TR-03110, Version 2.02 [EACTR]. For CC evaluation the following applications of corresponding product will be considered1: the Passport Application (ePassport) containing the related user data (incl. biometric data) as well as the data needed for authenti- cation (incl. MRZ) as specified in [EACTR, 3.1.1].; with this application the TOE is intended to be used as a machine readable travel document (MRTD); the eID-Application as specified in [EACTR, 3.1.2] including the related user data and the 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 eSign Application as specified in [EACTR, 3.1.3] containing data needed for generating advanced or qualified electronic signatures on behalf of the ID_Card Holder as well as for user authenti- cation; this application is intended to be used in the context of official and commercial services, where an advanced or qualified electronic signature of the ID_Card Holder is required. The eSign application is optional: it means that it can optionally be activated on the ID_Card by a Certifica- tion Service Provider Issuer (or on his behalf) authorized by the ID_Card Issuer. It can be set to “operational” or “non- operational” by the ID_Card Holder. 7 The ePassport Application as well as the eID-Application must be accessed through the contact-less interface of the TOE according to [EACTR]. For the eSign Application the interface is not specified in the SSCD PP ([SSCDPP]) and it is out of scope of the Technical Guideline TR-03110 (cf. [EACTR, B.7]). 8 For the ePassport application, the ID_Card Holder can control the access to his user data by conscious presenting his ID_Card to the authorities (CAN or MRZ authentication as specified in [EACTR, 3.3]). 9 For the eID-application, the ID_Card Holder can control the access to his user data by inputting his secret PIN (eID-PIN) or by conscious presenting his ID_Card to the authorities (eID-PIN or CAN user authentication as specified in [EACTR, 3.3]. 10 For the eSign application, the ID_Card Holder can control the access to the digital signa- ture functionality by conscious presenting his ID_Card to a Service Provider and using his secret Verification Authentication Data (eSign-PIN, i.e. eSign-VAD as specified in [SSCDPP, 3.2.3.5]). 11 Application Note 1: Using a secret PIN represents a manifestation of declaration of intent bound to this secret PIN. In order to reflect this fact, the eID-and the eSign applications shall organzationally 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. For security reasons this will not be enforced by the TOE. 1 The ID_Card support also e.g. the Restricted Identification (RI) described in [EACTR]. Because this functionality is outside the scope of the Protection Profile ([IDCARDPP, p.25]) it is not described here and not part of the evaluation. Security Target TCOS eID_Card/SLE78CLX1440P 7/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 12 The cryptographic algorithms used by the TOE are defined outside the TOE in the Public Key Infrastructure. The security parameters of these algorithms must be selected by the ID_Card_Issuer according to the Organisational Security Policies [IDCARDPP]. The TOE supports the standardized domain parameters mentioned in [ECARDTR, section 1.3.2] and the NIST P-256 curve mentioned in [EACTR2.10, part 3, annex A.2.1.1]. 13 The ID_Card is integrated into a plastic, optically readable part of the Identity Card, This is not part of the TOE. 14 In some context the hardware base may be relevant, and, if so, the TOE will be identified in more detail as the the "TCOS Identity Card Version 1.0 Release 1/SLE78CLX1440P", otherwise the notion "TCOS Identity Card Version 1.0 Release 2" will be used, indicating that this context applies to any realization regardless which hardware base is used. The SLE78CLX1440P chip is selected from the M7820 family. Note that the Chip Identifier Byte is not used in the TOE identification because it has no impact on the evaluation. 15 The TOE follows the composite evaluation aspects ([AIS36]). The Security Target of the underlying platform ([HWST]) claims conformance to Smartcard IC Platform Protection Profile ([PP0035]). 16 This composite ST is based on the ST of the underlying platform ([HWST]). The com- patibility of the Life Cycle Model of the Protection Profile [IDCARDPP] and the Life Cycle Model required by [PP0035] will be shown in 1.4.1. 1.4 TOE Description 1.4.1 TOE Definition 17 The TOE comprises of • the circuitry of the contactless chip including all IC Dedicated Software being active in the Operational Phase of the TOE (the integrated circuit, IC), • the IC Embedded Software (operating system) • the ePassport, the eID-and, optionally2 the eSign applications and • the associated guidance documentation 18 The components of the TOE are therefore the hardware (IC), the operating system TCOS (OS) and the dedicated files for the ePassport, the eID-and the eSign application in a file system. A detailed description of the parts of TOE will be given in other documents. 19 Since contactless interface parts (e.g. antenna) may have impact on specific aspects of vulnerability assessment and, thus, be security relevant, these parts are considered in this ST as part of the TOE. The decision upon this was made by the certification body in charge. Further details are considered in the ALC documentation. 2 activated or not yet activated on the ID_Card Security Target TCOS eID_Card/SLE78CLX1440P 8/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 1.4.2 TOE security features for operational use 20 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 security functionality of the ID_Card under control of the ID_Card holder, • Verifying authenticity and integrity as well as securing confidentiality of user data in the communication channel between the TOE and the service provider connected, • Creation of digital signatures, if the eSign application is operational, • Averting of inconspicuous tracing of the ID_Card, • Self-protection of the TOE security functionality and the data stored inside. 1.4.3 Non-TOE hardware/software/firmware 21 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 [ISO14443]. 22 From the logical point of view, the TOE is able to distinguish between the following terminal types, which, hence, shall be available (see [EACTR], sec. 3.2): Inspection system: an official terminal that is always operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier), Authentication terminal: a terminal that may be operated by a governmental orga- nization (Official Domestic Document Verifier) or by any other organization (Non-Official / Foreign Document Veri- fier), and Signature terminal: a terminal used by ID_Card holder for generation of digital signatures. 23 The TOE requires terminal of each type to authenticate itself before access according to effective terminal authorization is granted. To authenticate a terminal either as an in- spection system or authentication terminal or signature terminal, General Authentication Procedure3 must be used. 24 The TOE will not support Basic Access Control (BAC), see [EACTR], sec. 1.1, 3.1.1 and Appendix G, because the file system of the TOE does not contain the BAC keys after Initialization and the security features of the TOE do not allow to create them later on. 25 The authorization level of an authenticated terminal shall be determined by the effective terminal authorization calculated from the certificate chain presented by this terminal to the TOE. All necessary certificates of the related public key infrastructure – Country Verifying Certification Authority (CVCA) Link Certificates, Document Verifiers Certificates 3 i.e. executing the protocol sequence PACE, Terminal Authentication, Passive Authentication and hip Authentication according to [EACTR], sec. 4.2, 4.3 and 4.4 Security Target TCOS eID_Card/SLE78CLX1440P 9/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 and Terminal Certificates – shall be available in a card verifiable format as specified in [EACTR, Appendix C.1 and sec. 2.2.3.]. 26 The following table gives an overview which types of terminals shall be supported for which single application of the TOE, see [11], sec. 3.1 – 3.4 (please note that the effective ability of a terminal depends on its terminal authorization level finally derived from the presented certificate chain as stated above): Inspection System (official terminal) Authentication Terminal (official or commercial terminal) Signature Terminal ePassport Operations: reading all Data Groups User Authentication: CAN, MRZ for PACE In this context the termi- nal is equivalent to an EIS [EACPP3.1] No operations No Operations eID Operations: reading all Data Groups User Authentication: CAN for PACE Operations: writing a subset of Data Groups, reading all or a subset of Data Groups User Authentication: eID-PIN, eID-PUK or CAN for PACE No Operations eSign No Operations Operations: activating eSign application User Authentication: eID-PIN, eID-PUK or CAN for PACE In this context the termi- nal is equivalent the CGA in [SSCDPP] and implements the corres- ponding HID. Operations: generating digital signatures User Authentication: CAN for PACE followed by eSign-PIN through the HID In this context the termi- nal is equivalent to the SGA in [SSCDPP] and may implement the cor- responding HID 1.4.4 Life Cycle Phases Mapping 27 Following the protection profile PP0035 [PP0035, sec. 1.2.3] the life cycle phases of a TCOS eID_Card device can be divided into the following seven phases: Phase 1: IC Embedded Software Development Phase 2: IC Development Phase 3: IC Manufacturing Security Target TCOS eID_Card/SLE78CLX1440P 10/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Phase 4: IC Packaging Phase 5: Composite Product Integration Phase 6: Personalization Phase 7: Operational Use 28 According to the PP [IDCARDPP] the TOE life cycle is described in terms of the four life cycle phases. Life cycle phase 1 “Development” 29 The TOE is developed in phase 1. The IC developer (i.e. the Platform Developer accor- ding to [AIS36]) develops the integrated circuit, the IC Dedicated Software and the gui- dance documentation associated with these TOE components. 30 The software developer (i.e. the Application Developer according to [AIS36]) uses the guidance documentation for the integrated circuit and the guidance documentation for relevant parts of the IC Dedicated Software and develops the IC Embedded Software (operating system), the dedicated applications and the guidance documentation associated with these TOE components. 31 The manufacturing documentation of the IC including the IC Dedicated Software and the Embedded Software in the non-volatile non-programmable memories (ROM) is securely delivered to the IC manufacturer. The IC Embedded Software in the non-volatile programmable memories (EEPROM), the eID_Card application and the guidance documentation is securely delivered to the eID_Card manufacturer. 32 This life cycle phase 1 covers Phase 1 and Phase 2 of [PP0035]. Life cycle phase 2 “Manufacturing” 33 In a first step the TOE integrated circuit is produced containing the TOE’s Dedicated Software and the parts of the Embedded Software in the non-volatile memories (ROM and EEPROM). The IC manufacturer writes the IC Identification Data onto the chip to control the IC as eID_Card material during the IC manufacturing and the delivery pro- cess to the eID_Card manufacturer. The IC is securely delivered from the IC manufac- turer to the eID_Card manufacturer (note that both of these roles may be assigned to different entities). 34 The inlay holding the chip as well as the antenna and the plastic with optical readable part, (holding the e.g. the printed MRZ) are necessary to represent a complete Identity Card, nevertheless they are not inevitable for the secure operation of the TOE. 35 The eID_Card manufacturer (i) add the parts of the IC Embedded Software in the non-volatile programmable memories (for instance EEPROM) if necessary, (ii) creates the ePassport, the eID-and the eSign application, and (iii) equips TOE’s chip with Pre-personalization Data and (iv) packs the IC with hardware for the contactless interface in the eID_Card. 36 The pre-personalized eID_Card together with the IC Identifier is securely delivered from the eID_Card manufacturer to the Personalization Agent. The eID_Card manufacturer also provides the relevant parts of the guidance documentation to the Personalization Agent. Security Target TCOS eID_Card/SLE78CLX1440P 11/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 37 This life cycle phase 2 corresponds to Phase 3 and Phase 4 of [PP0035] and may include for flexibility reasons Phase 5 and some production processes from Phase 6 as well. Depending on the requirements of the following Personalization life cycle phase 3 some restrictions for the file system may also be fixed already in this phase. Despite of that they all could be made also during Personalization, i.e. they are not changing the TOE itself, such an approach of delivering the TOE with different configurations is useful for issuing states or organizations. The mentioned restrictions never change the struc- ture of the file system, but affect only the pre-allocation of maximal available memory and the a priori appearance of elementary files (EFs) for data groups to be allocated and filled up during Personalization. Note that any other file parameter including the access rules can not be changed. 38 The eSign application is also already fixed in the file system; the applicable later on procedure activates it only and makes Signature Creation Data available as required by the eSign application. Based on the Administrator Guidance [TCOSADM] the activating CSP develops a corresponding User Guidance for the eSign Application, which is delive- red to the eID_Card holder by the CSP. Note that the TOE has no contact interface. The eSign Application can be used through the contactless interface only. 39 For the TOE one pre-configured version (FSV01) of the file system applies. A detailed description of the sub-phases and the file system pre-configurations, including the assigned maximal available memory sizes can be found in the Administrator Guidance [TCOSADM]. 40 The product is finished after initialization, after testing the OS and creation of the dedicated file system with security attributes and ready made for the import of User Data. This corresponds to the end of the life cycle phase 2 of the Protection Profile [EACPP3.1]. The TOE may also be pre-configured during manufacturing which leads to different configurations for delivering. A more detailed description of the production pro- cesses in Phases 5 and 6 of PP0035 [PP0035] is given in the Administrator Guidance document [TCOSADM]. Note that the physical interface (i.e. the antenna) is out of the scope of the PP0035. Therefore it is not considered in the life cycle phases mapping. Life cycle phase 3 “Issuing” 41 The personalization of the eID_Card includes (i) the survey of the eID_Card holder biographical data, (ii) the enrolment of the eID_Card holder biometric reference data (i.e. the digitized portraits and the optional biometric reference data), (iii) the printing of the visual readable data onto the plastic cover of the physical eID_Card, (iv) the writing of TOE User Data and TSF Data into the logical eID_Card and (v) configuration of the TSF if necessary (not applicable for the TOE). 42 The step (iv) is performed by the Personalization Agent. 43 The personalized eID_Card (together with appropriate guidance for TOE use if necessa- ry) is handed over to the eID_Card holder for operational use. 44 This life cycle phase corresponds to the remaining initialization and personalization pro- cesses not covered yet from Phase 6 of the [PP0035]. 45 Application Note 2: Note that from hardware point of view the life cycle phase “Issuing” is already an operational use of the composite product and no more a personalization of the hardware. The hardware’s “Personalization” (cf. [HWST]) ends with the initialization Security Target TCOS eID_Card/SLE78CLX1440P 12/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 and pre-personalization of the TOE and should not be confused with the Personalization described in the Administrator Guidance [TCOSADM]. Life cycle phase 4 “Operational Use” 46 The TOE is used as eID_Card’s chip by the eID_Card holder and the terminals in the “Operational Use” phase. 47 This life cycle phase corresponds to the Phase 7 of the [PP0035]. 48 If the eSign application is not activated during Personalization, and only an authorized terminal (the User S.Admin according [SSCDPP]) can execute the eSign key pair gene- ration. The qualified certificate will be assigned to the ID_Card holder identified by the authorized terminal. Therefore no further Personalization procedure is required in Phase 7 (Operational Use). 49 The security environment for the TOE and the ST of the underlying platform match, the Phases up to 6 are covered by a controlled environment as required in [HWCR, p. 41]. In Phase 7 (Operational Use) no restrictions apply. 1.4.5 TOE Boundaries 1.4.5.1 TOE Physical Boundaries 50 Smart card as used in this ST means an integrated circuit containing a microprocessor, (CPU), a coprocessor for special (cryptographic) operations, a random number gene- rator, volatile and non-volatile memory, and associated software, packaged and em- bedded in a carrier. The integrated circuit is a single chip incorporating CPU and me- mory which include RAM, ROM, and EEPROM. 51 The chip is embedded in a module which provides the capability for standardized con- nection to systems separate from the chip through contactless interface in accordance with ISO standards. 52 The physical constituents of the TOE are the operating system, the data in elementary files of the dedicated files of the ePassport, eID and the eSign application (EEPROM), and temporary data used during execution of procedures associated to that dedicated file. 1.4.5.2 TOE Logical Boundaries 53 All card accepting devices (Host Applications) will communicate through the I/O interface of the operating system by sending and receiving octet strings. The logical boundaries of the TOE are given by the complete set of commands of the TCOS operating system for access, reading, writing, updating or erasing data. 54 The input to the TOE is transmitted over the physical interface as an octet string that has the structure of Command Application Protocol Data Unit (CAPDU). 55 The output octet string from the TOE has the structure of a Response Application Protocol Data Unit (RAPDU). 56 The Application Protocol Data Units or TCOS commands that can be used in the opera- ting systems are described in more detail in another document. Security Target TCOS eID_Card/SLE78CLX1440P 13/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 2 Conformance Claim 2.1 CC Conformance Claims 57 This Security Target claims conformance to Common Criteria for Information Technology Security Evaluation [CC], Part 1: Introduction and General Model; CCMB-2009-07-001, Version 3.1, Revision 3, July 2009, Part 2: Security Functional Components; CCMB-2009-07-002, Version 3.1, Revision 3, July 2009, Part 3: Security Assurance Requirements; CCMB-2009-07-003, Version 3.1, Revision 3, July 2009 58 as follows: Part 2 extended, Part 3 conformant. 59 The Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; CCMB-2009-07-004, Version 3.1, Revision 3, July 2009, [CC] has to be taken into account. The evaluation follows the Common Evaluation Methodology (CEM) with current final interpretations. 2.2 PP Claims 60 This ST claims strict conformance to the CC Protection Profile Electronic Identity Card (ID_Card PP), Version 1.03, BSI-PP-0061, 2009-12-15 [IDCARDPP]. 61 As required by the CC Protection Profile Electronic Identity Card (ID_Card PP) the strict conformance to this PP includes the strict conformance to the CC Protection Profile Secure Signature Creation Device – Part 2: Device with key generation, Version 1.03, BSI-PP-0059 [SSCDPP]. Therefore the Security Requirements of the latter will be considered in this ST too. 2.3 Package Claims 62 The evaluation of the TOE is a composite evaluation and uses the results of the CC evaluation provided by [HWCR]. The IC hardware platform and its primary embedded software are evaluated at level EAL 5. 63 The evaluation assurance level of the TOE is EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 as defined in [CC]. 2.4 Conformance Rationale 64 The ST claims strict conformance to the protection profile SSCD Core PP [SSCDPP] as required there in sec. 6.4. The part of the security policy for the ePassport application of Security Target TCOS eID_Card/SLE78CLX1440P 14/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 the TOE is contextually in a tight connection with the ICAO EAC PP [EACPP3.1]. Due to this fact, it is sensible to distinguish between separated sets of {TOE type, SPD state- ment, security objectives statement, security requirements statement} for each applica- tion residing in the TOE: ePassport, eID-and eSign, respectively, unless the items are identical or hierarchical as in the case of the SARs. 65 The TOE type stated in [SSCDPP], 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’. 66 This TOE type is obviously commensurate with the current TOE type in the part being provided by the eSign application as stated above. 67 The Security Problem Definition (SPD) of the PP ([IDCARDPP]) contains the security problem definition of the PP [SSCDPP]. The current SPD includes the same threats, organizational security policies and assumptions as for the TOE in [SSCDPP] and com- prehends several additional items as stated in chap. 3 below. 68 Strict conformance presumes that assumptions of the PP ([IDCARDPP]) shall be identical to the assumptions of each PP to which the conformance is being claimed. In this context, the current assumptions block for the eSign application is identical to the assumptions from [SSCDPP]. 69 The Security Objectives Statement for the TOE in the PP ([IDCARDPP]) includes all the security objectives for the TOE of the PP [SSCDPP] and comprehends several addi- tional items as stated in chap. 4.1 below. The Security Objectives Statement for the TOE’s operational environment in the PP ([IDCARDPP]) includes all security objectives for the operational environment of the PP [SSCDPP] and comprehends several addi- tional items as stated in chap. 4.2 below. In this context, the current block of environ- mental objectives for the eSign application is identical to the equivalent objectives from [SSCDPP]. 70 The Security Requirements Statement for the TOE in the current ST includes all the SFRs for the TOE of the PP [SSCDPP] and comprehends several additional items as stated in chap. 6.1 below. The SAR statement for the TOE in the current ST includes all the SARs for the TOE of the PP [SSCDPP] as stated in chap. 6.2 below. The current assurance package contains the assurance component ALC_DVS.2 and ATE_DPT.2 being hierarchical to ALC_DVS.1 and ATE_DPT.1 as required by [SSCDPP]. Strict conformance allows that the security requirements for the TOE may be hierarchically stronger than those items of each PP to which the conformance is being claimed. Security Target TCOS eID_Card/SLE78CLX1440P 15/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 3 Security Problem Definition 71 The ST covers three different applications – ePassport, eID- and eSign –, therefore the SPD statement of the TOE, as well as the Security Objectives and the Security Require- ments for the TOE in the following chapters are traced to the corresponding applications. 3.1 Introduction Assets 72 The primary assets to be protected by the TOE as long as they are in scope of the TOE are (please refer to the Appendix Glossary 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 ID_Card as defined in [EACTR] and (i) being allowed to be read out or written solely by an authenticated terminal (in the sense of [EACTR], sec. 3.2) respectively (ii) being allowed to be used solely by an authenticated terminal (in the sense of [EACTR], sec. 3.2) (the private Restricted Identification key4 ) respectively (iii) being allowed to be used solely by the authenticated ID_Card holder (the private signature key within the eSign application). This asset covers ‘User Data on the MRTD’s chip’ and ‘Logical MRTD_Card sensitive User Data’ in [EACPP3.1] as well as ‘SCD’ and ‘DTBS-representation’ in [SSCDPP]. Confidentiality5 Integrity Authenticity 2 user data transferred between the TOE and the service provider connected6 All data (being not authentication data) being transferred in the context of the applications of the ID_Card as defined in [EACPP3.1] between the TOE and an authenticated terminal (in the sense of [EACPP3.1, sec. 3.2]. User data can be received and sent. This asset covers ‘DTBS’ in [SSCDPP]. Confidentiality5 Integrity Authenticity 3 ID_Card tracing data Technical information about the current and previous locations of the ID_Card gathered by inconspicuous (for the ID_Card holder) recogniz- Unavailability7 4 Since the Restricted Identification according to [EACTR], sec. 4.5 represents just a functionality of the ID_Card, the key material needed for this functionality and stored in the TOE is treated here as User Data in the sense of the CC. 5 Though not each data element stored on the TOE represents a secret, the specification [EACPP3.1] anyway requires securing their confidentiality: only terminals authenticated according to [EACPP3.1, sec. 4.4] can get access to the user data stored. 6 For the ePassport application, the service provider is always an authority represented by a local RF-terminal 7 represents a prerequisite for anonymity of the ID_Card holder Security Target TCOS eID_Card/SLE78CLX1440P 16/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Object No. Asset Definition Generic security property to be maintained by the current security policy ing the TOE knowing neither CAN nor MRZ nor eID-PIN nor eID-PUK. TOE tracing data can be provided / gathered. Table 1: Primary assets 73 Application Note 3: Please note that user data being referred in the table above include, amongst other, individual-related (personal) data of the ID_Card holder which also include his sensitive (biometrical) data. Hence, the general security policy defined by the PP [IDCARDPP] also secures these specific ID_Card holder’s data as specified in the table above. 74 All these primary assets represent User Data in the sense of the CC. 75 The secondary assets also having to be protected by the TOE in order to achieve a sufficient protection of the primary assets are: 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 authorized subjects Property of the TOE to restrict access to TSF and TSF-data stored in the TOE to authorized subjects only. Availability 5 Genuineness of the TOE Property of the TOE to be authentic in order to provide the claimed security functionality in a proper way. This asset also covers ‘Authenticity of the MRTD’s chip’ in [EACPP3.1]. Availability 6 TOE immanent secret cryptographic keys Secret cryptographic material used by the TOE in order to enforce its security functionality8 . Confidentiality Integrity 7 TOE immanent non- secret cryptographic keys Non-secret cryptographic material used by the TOE in order to enforce its security functionality. This asset covers ‘SVD’ in [SSCDPP]. Integrity Authenticity 8 Secret ID_Card holder authentication data Secret authentication information for the ID_Card holder being used for verification of the authentication attempts as authorized ID_Card holder: • eID-PIN and eID-PUK stored in the ID_Card as well as • eSign-PIN (and eSign-PUK, if any9 ) (i) stored in the ID_Card10 and (ii) transferred to it11 Confidentiality Integrity 9 ID_Card communication establishment authorization data Restricted-revealable12 authorization information for a human user being used for verification of the authorization attempts as authorized user (CAN for ePassport, eID, eSign; MRZ for ePassport). These data are stored in the TOE and are not to convey to it. Confidentiality12 Integrity 8 please note that the private signature key within the eSign application (SCD) belongs to the object No. 1 ‘user data stored’ above. 9 eSign-PIN and eSign-PUK are local secrets being valid only within the eSign application 10 is commensurate with RAD in [SSCDPP] 11 is commensurate with VAD in [SSCDPP] 12 The ID_Card holder may reveal, if necessary, verification values of the CAN and MRZ to an autho- rized person or device who definitely act according to respective regulations and are trustworthy. Security Target TCOS eID_Card/SLE78CLX1440P 17/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Table 2: Secondary assets 76 Application Note 4: ID_Card holder authentication and ID_Card communication estab- lishment authorization data are represented by two different entities: (i) reference infor- mation being persistently stored in the TOE and (ii) verification information being provi- ded as input for the TOE by a human user as an authentication/authorization attempt. The TOE shall secure the reference information as well as — together with the terminal connected13 — the verification information in the TOE–Terminal channel, if it has to be transferred to the TOE. Please note that CAN, MRZ, eID-PIN and eID-PUK are not to convey to the TOE. 77 The secondary assets represent TSF and TSF-data in the sense of the CC. Subjects and external entities 78 This ST considers the following subjects: External Entity Subject Role Definition 1 1 ID_Card holder A person for whom the ID_Card Issuer has personalized the ID_Card14 . This subject is commensurate with ‘MRTD_Card Holder’ in [EACPP3.1] and ‘S.Signatory’ in [SSCDPP]. Please note that an ID_Card holder can also be an attacker (s. below). 2 – ID_Card presenter A person presenting the ID_Card to a terminal15 and claiming the identity of the ID_Card holder. This subject is commensurate with ‘Traveller’ in [EACPP3.1] and ‘S.User’ in [SSCDPP]. Please note that an ID_Card holder can also be an attacker (s. below). 3 – Service Provider (SP) An official or commercial organization providing services which can be used by the ID_Card holder. Service Provider uses the rightful terminals managed by a DV. 4 2 Terminal 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 EIS nor ATT nor SGT (‘Terminal’ is used by the ID_Card presenter). This subject is commensurate with ‘Terminal’ in [EACPP3.1] 5 3 PACE Terminal (PCT) A technical system verifying correspondence between the password stored in the ID_Card and the related value presented to the terminal by the ID_Card presenter. PCT implements the terminal’s part of the PACE protocol and authenticates itself to the ID_Card using a shared password (CAN, eID- PIN, eID-PUK or MRZ). The PCT is not allowed reading User Data (see sec. 4.2.2 in [EACTR]). See also [EACTR, chap. 3.3, 4.2, table 1.2 and G.2] 6 4 Inspection system (EIS) A technical system being used by an authority16 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying the ID_Card presenter as the ID_Card holder (for ePassport: by comparing the real biometrical data of the ID_Card presenter with the stored biometrical data of the ID_Card holder). An Inspection System is a PCT additionally supporting the Chip Authenti- 13 the input device of the terminal 14 i.e. this person is uniquely associated with a concrete electronic ID Card 15 in the sense of [EACTR] 16 concretely, by a control officer Security Target TCOS eID_Card/SLE78CLX1440P 18/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 External Entity Subject Role Definition cation (incl. passive authentication) and the Terminal Authentication protocols and is authorized by the ID_Card Issuer through the Document Verifier of the receiving State (by issuing terminal certificates) to read a subset of the data stored on the ID_Card. The Inspection System in the context of [EACTR] and of [IDCARDPP]) is commensurate with the Extended Inspection System (EIS) as defined in [EACPP3.1]. See also [EACTR, chap. 3.2 and C.4]. 7 5 Authentication Terminal (ATT) A technical system being operated and used either by a governmental organization (Official Domestic Document Verifier) or by any other, also commercial organization and (i) verifying the ID_Card presenter as the ID_Card holder (using the secret eID-PIN17 ), (ii) updating a subset of data of the eID-application and (iii) installing the eSign application. An Authentication Terminal is a PCT additionally supporting the Chip Authentication (incl. passive authentication) and the Terminal Authentica- tion protocols and is authorized by the ID_Card Issuer through the Docu- ment Verifier of the receiving branch (by issuing terminal certificates) to access a subset of the data stored on the ID_Card. See also [EACTR, chap. 3.2 and C.4]. 8 6 Signature Terminal (SGT) A technical system being approved by a Certification Service Provider and used for generation of digital signatures. A Signature Terminal is a PCT additionally supporting the Chip Authenti- cation (incl. passive authentication) and the Terminal Authentication protocols and is authorized by the ID_Card Issuer through the Document Verifier of the receiving branch (by issuing terminal certificates) to access a subset of the data stored on the ID_Card. See also [EACTR, chap. 3.2 and C.4]. 9 7 Document Verifier (DV) An organization enforcing the policies of the CVCA and of a Service Provider (governmental or commercial organization) and managing the 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 Certification Authority, authorized by at least the national CVCA to issue certificates for national terminals, see [EACTR], 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 ID_Card Issuer; a foreign DV is acting under a policy of the respective foreign CVCA (in this case there shall be an appropriate agreement18 between the ID_Card Issuer und a foreign CVCA ensuring enforcing the ID_Card Issuer’s privacy policy19 ). This subject is commensurate with ‘Document Verifier’ in [EACPP3.1]. 10 8 Country Verifying Certification Authority (CVCA) An organization enforcing the privacy policy of the ID_Card Issuer with respect to protection of user data stored in the ID_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, ATT, SGT) and creates the Document Verifier Certificates within this PKI. Updates of the public key of the CVCA are distributed in form of CVCA Link- Certificates, see [EACTR], chap. 2.2.1. The Country Signing Certification Authority (CSCA) issuing certificates for Document Signers (cf. [EACTR]) and the domestic CVCA may be integrated into a single entity, e.g. a Country Certification Authority. However, even in this case, separate key pairs must be used for different roles, see [EACTR], sec. 2.2.1. This subject is commensurate with ‘Country Verifying Certification 17 the secret eID-PUK can be used for unblocking the eID-PIN and resetting the retry counter re- lated. 18 the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the [IDCARDPP] in order to reflect an appropriate relationship between the parties involved. 19 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. Security Target TCOS eID_Card/SLE78CLX1440P 19/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 External Entity Subject Role Definition Authority’ in [EACPP3.1]. 11 – Document Signer (DS) An organization enforcing the policy of the CSCA and signing the Card Security Object stored on the ID_Card for passive authentication. A Document Signer is authorized by the national CSCA issuing the Document Signer Certificate (CDS), see [EACTR]. This role is usually delegated to a Personalization Agent. 12 – Country Signing Certification Authority (CSCA) An organization enforcing the policy of the ID_Card Issuer with respect to confirming correctness of user and TSF data stored in the ID_Card. The CSCA represents the country specific root of the PKI for the ID_Cards and 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. [EACTR], 5.1.1. The Country Signing CertA issuing certificates for Document Signers (cf. [EACTR]) and the domestic CVCA may be integrated into a single entity, e.g. a Country Certification Authority. However, even in this case, separa- te key pairs must be used for different roles, see [EACTR], sec. 2.2.1. 13 – Certification Service Provider (CSP) An organization issuing certificates and providing other services related to electronic signatures. There can be Common and Qualified CSP: A Qualified Certification Service Provider issues qualified certificates. A CSP is the Certification Service Provider in the sense of [SSCDPP]. This subject is commensurate with ‘S.Admin’ in [SSCDPP]. 14 9 Personalization Agent An organization acting on behalf of the ID_Card Issuer to personalize the ID_Card for the ID_Card holder by some or all of the following activities: (i) establishing the identity of the ID_Card holder for the biographic data in the ID_Card20 , (ii) enrolling the biometric reference data of the ID_Card holder21, (iii) writing a subset of these data on the physical Identification Card (optical personalization) and storing them in the ID_Card (electronic personalization) for the ID_Card holder as defined in EACTR], (iv) writing the document details data, (v) writing the initial TSF data, (vi) signing the Card Security Object defined in [EACTR] (in the role of DS). Please note that the role ‘Personalization Agent’ may be distributed among several institutions according to the operational policy of the ID_Card Issuer. Ge- nerating signature key pair(s) is not in the scope of the tasks of this role. This subject is commensurate with ‘Personalization agent’ in [EACPP3.1] and ‘Administrator’ in [SSCDPP]. 15 10 Manufacturer Generic term for the IC Manufacturer producing integrated circuit and the ID_Card Manufacturer completing the IC to the ID_Card. The Manufac- turer is the default user of the TOE during the manufacturing life phase. The TOE itself does not distinguish between the IC Manufacturer and ID_Card Manufacturer using this role Manufacturer. This subject is commensurate with ‘Manufacturer’ in [EACPP3.1]. 16 11 Attacker A threat agent (a person or a process acting on his behalf) trying to undermine the security policy defined by the [IDCARDPP], 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 subject role recognized by the TOE including the entities mentioned in footnote 12 on page 16 to which the CAN or MRZ may be revealed. This subject is commensurate with ‘Attacker’ in [EACPP3.1] and ‘S.Offcard’ in [SSCDPP]. Table 3: Subjects 79 Since the file system of the TOE does not support BAC, the Basic Inspection System (BIS) cannot be recognized by the TOE, see above. 20 relevant for the ePassport, the eID and the eSign applications 21 relevant for the ePassport application Security Target TCOS eID_Card/SLE78CLX1440P 20/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 3.2 Threats 80 This section describes the threats to be averted by the TOE independently or in collaboration with its IT environment. These threats result from the assets protected by the TOE and the method of TOE’s use in the operational environment. 81 The following threats are defined in the current ST (they are derived from the ICAO-BAC PP [BACPP3.1] and ICAO-EAC PP [EACPP3.1]): T.Skimming Skimming ID_Card/Capturing Card–Terminal Communication 82 An attacker imitates an inspection system, an authentication or a signature terminal in order to get access to the user data stored on or transferred between the TOE and the service provider connected via the contactless interface of the TOE. The attacker cannot read and does not know the correct value of the shared password (CAN, MRZ, eID-PIN, eID-PUK or MRZ) in advance. This item concerns the following application(s): ePassport, eID, eSign. 83 Application Note 5: This threat also covers the item T.Read_Sensitive_Data in the ICAO- EAC PP [EACPP3.1]: Sensitive biometric reference data stored on the ID_Card are part of the asset user data stored on the TOE. Knowledge of the Document Basic Access Keys is here not applicable, because the TOE does not support the BAC protocol and, therefore, the Document Basic Access Keys are not existent for the TOE. 84 Application Note 6: MRZ is printed and CAN is printed or stuck on the Identification Card. Please note that neither CAN nor MRZ effectively represent secrets, but are re- stricted-revealable, cf. OE.ID_Card-Holder. T.Eavesdropping Eavesdropping on the communication between the TOE and a rightful terminal 85 An attacker is listening to the communication between the ID_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, eSign. 86 Application Note 7: A product supporting BAC cannot avert this threat in the context of the security policy defined in the [IDCARDPP]. T.ID_CARD_Tracing Tracing ID_Card 87 An attacker tries to gather TOE tracing data (i.e. to trace the movement of the ID_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. 88 Application Note 8: A product supporting BAC cannot avert this threat in the context of the security policy defined in the [IDCARDPP]. T.Forgery Forgery of Data Security Target TCOS eID_Card/SLE78CLX1440P 21/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 89 An attacker fraudulently alters the User Data or/and TSF-data stored on the ID_Card or/and exchanged between the TOE and the Service Provider connected in order to outsmart the authenticated terminal (EIS, ATT or SGT) by means of the changed ID_Card holder’s related reference data (like biographic or biometric data or SCD/SVD). The attacker does it in such a way that the Service Provider (represented by the terminal connected) perceives these modified data as authentic one. This item concerns the following application(s): ePassport, eID, eSign. This threat partially covers T.SVD_Forgery (only stored, but not being sent to the CGA SVD) from [SSCDPP]. T.Counterfeit Counterfeiting ID_Card 90 An attacker produces an unauthorized copy or reproduction of a genuine ID_Card to be used as part of a counterfeit Identification Card: He may generate a new data set or extract completely or partially the data from a genuine ID_Card and copy them on another functionally appropriate chip to imitate this genuine ID_Card. This violates the authenticity of the ID_Card being used either for authentication of an ID_Card presenter as the ID_Card holder or for authentication of the ID_Card as a genuine secure signature creation device. This item concerns the following application(s): ePassport, eID, eSign. T.Abuse-Func Abuse of Functionality 91 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 initialization and the personalization in the operational phase after delivery to the ID_Card holder. This item concerns the following application(s): ePassport, eID, eSign. This threat covers T.SigF_Misuse from [SSCDPP]. 92 Application Note 9: Details of the relevant attack scenarios depend, for instance, on the capabilities of the test features provided by the IC Dedicated Test Software being not specified here. T.Information_Leakage Information Leakage from ID_Card 93 An attacker may exploit information leaking from the TOE during its usage in order to disclose confidential User Data or/and TSF-data. The information leakage may be inherent in the normal operation or caused by the attacker. This item concerns the following application(s): ePassport, eID, eSign. 94 Application Note 10: 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 the Differential Electromagnetic Analysis (DEMA) and the Differential Power Analysis (DPA). Moreover the attacker may try actively to enforce information leakage by fault injection (e.g. Differential Fault Analysis). Security Target TCOS eID_Card/SLE78CLX1440P 22/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 T.Phys-Tamper Physical Tampering 95 An attacker may perform physical probing of the ID_Card in order (i) to disclose the TSF-data, or (ii) to disclose/reconstruct the TOE’s Embedded Software. 96 An attacker may physically modify the ID_Card in order to modify (i) its security functionality (hardware and software part, as well), (ii) the User Data or the TSF-data stored on the ID_Card. 97 This item concerns the following application(s): ePassport, eID, eSign. 98 This threat covers T.Hack_Phys from [SSCDPP]. 99 Application Note 11: The physical tampering may be focused directly on the disclosure or 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 ID_Card) or indirectly by preparation of the TOE to following attack methods by modification of security features (e.g. to enable information leakage through power analysis). Physical tampering requires direct interaction with the ID_Card’s internals. Techniques commonly employed in IC failure analysis and IC reverse engineering efforts may be used. Before that, the hardware security mechanisms and layout characteristics need to be identified. Determination of software design including treatment of the user data and the 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. T.Malfunction Malfunction due to Environmental Stress 100 An attacker may cause a malfunction the ID_Card’s hardware and Embedded Software by applying environmental stress in order to (i) deactivate or modify security features or functionality of the TOE’ hardware or to (ii) circumvent, deactivate or modify security functions of the TOE’s Embedded Software. This may be achieved e.g. by operating the ID_Card outside the normal operating conditions, exploiting errors in the ID_Card’s Embedded Software or misusing administrative functions. To exploit these vulnerabilities an attacker needs information about the functional operation. This item concerns the following application(s): ePassport, eID, eSign. 101 Application Note 12: A malfunction of 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 T.Phys-Tamper) assuming a detailed knowledge about the TOE’s internals. 102 The PP ([IDCARDPP]) also includes all threats of the SSCD PP [SSCDPP]. If the eSign application is operational then all these items are applicable. For the sake of complete- ness the threats are listed below. More details can be found in the SSCD PP [SSCDPP]. Threat identifier Comments T.SCD_Divulg concerns the following application(s): – eSign T.SCD_Derive concerns the following application(s): – eSign T.Hack_Phys is covered by T.Phys-Tamper concerns the following application(s): – ePassport – eID Security Target TCOS eID_Card/SLE78CLX1440P 23/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Threat identifier Comments – eSign T.SVD_Forgery is covered by T.Forgery concerns the following application(s): – eSign T.SigF_Misuse is covered by T.Abuse-Func concerns the following application(s): – ePassport – eID – eSign T.DTBS_Forgery concerns the following application(s): – eSign T.Sig_Forgery concerns the following application(s): – eSign 3.3 Organizational Security Policies 103 The TOE and/or its environment shall comply with the following Organizational Security Policies (OSP) as security rules, procedures, practices, or guidelines imposed by an organization upon its operations. P.Pre-Operational Pre-operational handling of the ID_Card 1. The ID_Card Issuer issues ID_Cards and approves terminals complying with all applicable laws and regulations. 2. The ID_Card Issuer guarantees the correctness of the user data (amongst other of those, concerning the ID_Card holder) and of the TSF-data permanently stored in the TOE22. 3. The ID_Card Issuer uses only such TOE’s technical components (IC) which enable traceability of the ID_Cards in their manufacturing and issuing life phases, i.e. before they are in the operational phase. 4. If the ID_Card Issuer authorizes a Personalization Agent to personalize the ID_Card for the ID_Card holder, the ID_Card Issuer has to ensure that the Personalization Agent acts in accordance with the ID_Card Issuer’s policy. 104 This item concerns the following application(s): ePassport, eID, eSign. P.ID_Card_PKI PKI for Chip and Passive Authentication23 (issuing branch) 105 Application Note 13: The description below states responsibilities of the 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 certificates belonging to the PKI are securely distributed / made available to their final destination, e.g. by using directory services. 1. The ID_Card Issuer shall establish a public key infrastructure for the passive authenti- cation, i.e. for digital signature creation and verification for the ID_Card. For this aim he runs a Country Signing Certification Authority (CSCA). The ID_Card Issuer shall 22 cf. Table 1 and Table 2 above 23 Passive authentication is considered to be part of the Chip Authentication protocol. Security Target TCOS eID_Card/SLE78CLX1440P 24/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 distribute the Country Signing CertA Certificate (CCSCA) and the Document Signer Certificates (CDS) to the CVCA (who forwards them finally to the rightful terminals). 2. The CSCA shall securely generate, store and use the Country Signing CertA Key pair. The CSCA shall keep the Country Signing CertA Private Key secret and issue a self- signed Country Signing CertA Certificate (CCSCA) having to be distributed to the ID_Card Issuer by strictly secure means, see [ICAO9303-1], 5.1.1. The CSCA shall create the Document Signer Certificates for the Document Signer Public Keys (CDS) and distribute them to the ID_Card Issuer, see [ICAO9303-1, 5.1.1]. 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 sign- ing the Card Security Objects of the ID_Cards and (v) manage the Chip Authentication Key Pairs {SKPICC, PKPICC} used for the chip authentication as defined in [EACTR], sec. 4.3. 106 This item concerns the following application(s): ePassport, eID, eSign. P.Terminal_PKI PKI for Terminal Authentication (receiving branch) 107 Application Note 14: The description below states responsibilities of the 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 certificates belonging to the PKI are securely distributed / made available to their final destination, e.g. by using directory services. 1. The ID_Card Issuer shall establish a public key infrastructure for the card verifiable certificates used for terminal authentication. For this aim, the ID_Card Issuer shall run a domestic Country Verifying Certification Authority (domestic CVCA) and may use already existing foreign CVCAs24. The ID_Card Issuer shall make the CVCA Link Certificate available to the CSCA (who shall finally distribute it to its ID_Cards). 2. A CVCA shall securely generate, store and use the CVCA key pair. A CVCA shall securely generate, store and use the CVCA key pair. A CVCA shall keep the CVCA Private Key secret and issue a self-signed CVCA Certificate (CCVCA) having to be made available to the ID_Card Issuer by strictly secure means as well as to the respective Document Verifiers. A CVCA shall create the Document Verifier Certificates for the Document Verifier Public Keys (CDV) and distribute them back to the respective Document Verifier Verifiers25. 3. A Document Verifier shall (i) generate the Document Verifier Key Pair, (ii) hand over the Document Verifier Public Key to the CVCA for certification, (iii) keep the Document Verifier Private Key secret and (iv) securely use the Document Verifier Private Key for signing the Terminal Certificates (CT) of the terminals being managed by him. The 24 In this case there shall be an appropriate agreement between the ID_Card Issuer und a foreign CVCA ensuring enforcing the ID_Card Issuer’s privacy policy. Existence of such an agreement may be technically reflected by means of issuing a CCVCA-F for the Public Key of the foreign CVCA signed by the domestic CVCA. 25 A CVCA shall also manage a Revocation Sector Key Pair {SKRevocation, PKRevocation} [EACTR], sec. 2.3 and 4.5. Security Target TCOS eID_Card/SLE78CLX1440P 25/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Document Verifier shall make CT, CDV and CCVCA available to the respective Service Providers (who puts them in his terminals)26. 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 Private Keys (SKPCD) secret, (iv) securely use the Terminal Authentication Private Keys for the terminal authentication as defined in [EACTR], sec. 4.4 and (v) install CT, CDV and CCVCA in the rightful terminals operated by him. 108 This item concerns the following application(s): ePassport, eID, eSign. P.Trustworthy_PKI Trustworthiness of PKI 1. The CSCA shall ensure that it issues its certificates exclusively to the rightful orga- nizations (DS) and DS shall ensure that they sign exclusively correct Card Security Objects having to be stored on the ID_Cards. 2. CVCAs shall ensure that they issue their certificates exclusively to the rightful orga- nizations (DV) and DV shall ensure that they issue their certificates exclusively to the rightful equipment (terminals)27. 3. CSPs shall ensure that they issue their certificates exclusively for the rightful data (public signature key of the ID_Card holder)28. 109 This item concerns the following application(s): ePassport, eID, eSign. P.Terminal Abilities and trustworthiness of rightful terminals 1. The rightful terminals (inspection system, authentication terminal and signature termi- nal shall be used by Service Providers and by ID_Card holders as defined in [EACTR], sec. 3.2. 2. They shall implement and use the terminal parts of the PACE protocol [EACTR], sec. 4.2, of the Terminal Authentication protocol [EACTR], sec. 4.4, of the Passive Authentication [EACTR], sec. 3.4 and of the Chip Authentication protocol [EACTR], sec. 4.329 and use them in this order30. A rightful terminal shall use randomly and (al- most) uniformly selected nonces, if required by the protocols (for generating ephemer- al keys for Diffie-Hellmann). 3. Rightful terminals shall store the related credentials needed for the terminal authentication (terminal authentication key 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 the authorization mask (CHAT) for access to the data stored on the ID_Card) in order to enable and to perform the terminal authentication as defined in [EACTR], sec. 4.4. 26 A DV shall also manage a Revocation Sector Key Pair {SKSectorNN, PKSectorNN} [EACTR], sec. 2.3 and 4.5. 27 This rule is relevant for T.Skimming 28 This property is affine to P.CSP_QCert from [SSCDPP]. 29 The Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol with- in [IDCARDPP] 30 This order is only commensurate with the branch rightmost in Fig. 3.1, sec. 3.1.1 of [EACTR]. Other branches of this figure are not covered by the security policy of [IDCARDPP]. Security Target TCOS eID_Card/SLE78CLX1440P 26/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 4. They shall also store the Country Signing Public Key and the Document Signer Public Key (in form of CCSCA and CDS) in order to enable and to perform Passive Authen- tication (determination of authenticity of PKPICC, [EACTR], sec. 4.3.1.2). 5. A rightful terminal must not send assets (e.g. eSign-PIN, DTBS) to the TOE within the PACE session, but first having successfully performed the Chip Authentication after the Terminal Authentication31. 6. A rightful terminal and its environment must ensure confidentiality and integrity of respective data handled by it (e.g. confidentiality of PINs/PUKs, integrity of PKI certificates and DTBS, etc.), where it is necessary for a secure operation of the TOE according to the current PP. 110 This item concerns the following application(s): ePassport, eID, eSign. 111 The PP ([IDCARDPP]) also includes all OSPs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 112 For the sake of completeness the OSPs are listed below. More details can be found in the SSCD PP [SSCDPP]. OSP identifier Comments P.CSP_QCert concerns the following application(s): – eSign P.QSign concerns the following application(s): – eSign P.Sigy_SSCD concerns the following application(s): – eSign P.Sig_Non-Repud concerns the following application(s): – eSign Table 4: OSPs taken over from [SSCDPP] 3.4 Assumptions 113 The assumptions describe the security aspects of the environment in which the TOE will be used or is intended to be used. 114 The current ST includes all assumptions of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 115 For the sake of completeness the assumptions are listed below. More details can be found in the SSCD PP [SSCDPP]. Assumption identifier Comments A.CGA concerns the following application(s): – eSign A.SCA concerns the following application(s): – eSign Table 5: Assumptions taken over from [SSCDPP] 31 This rule is relevant for T.Skimming Security Target TCOS eID_Card/SLE78CLX1440P 27/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 116 The Assumptions on security aspects of the environment derived from the hardware platform PP [PP0035] and the hardware platform ST [HWST] are considered in detail later in section 7.10.2 of the current ST. 117 The PP ([IDCARDPP]) does not include any additional assumptions. Security Target TCOS eID_Card/SLE78CLX1440P 28/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 4 Security Objectives 118 This chapter describes the security objectives for the TOE and the security objectives for the TOE environment. 4.1 Security Objectives for the TOE 119 The following TOE security objectives address the protection provided by the TOE independent of the TOE environment. OT.Data_Integrity Integrity of Data 120 The TOE must ensure integrity of the User Data and the TSF-data32 stored on it by protecting these data against unauthorized modification (physical manipulation and unauthorized modifying). The TOE must ensure integrity of the User Data and the TSF-data32 during their exchange between the TOE and the Service Provider connected (and represented by either EIS or ATT or SGT) after the Terminal- and the Chip Authentication. This item concerns the following application(s): ePassport, eID, eSign. OT.Data_Authenticity Authenticity of Data 121 The TOE must ensure authenticity of the User Data and the TSF-data33 stored on it by enabling verification of their authenticity at the terminal-side34. The TOE must ensure authenticity of the User Data and the TSF-data33 during their exchange between the TOE and the Service Provider connected (and represented be either EIS or ATT or SGT) after 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)35. This item concerns the following application(s): ePassport, eID, eSign. OT.Data_Confidentiality Confidentiality of Data 122 The TOE must ensure the confidentiality of the User Data and the TSF-data36 by granting read access only to authorized rightful terminal (EIS, ATT, SGT) according to the terminal authorization level (CHAT) presented by the terminal connected. The TOE must ensure the confidentiality of the User Data and the TSF-data36 during their exchange between the TOE and the Service Provider connected (and represented be either EIS or ATT or SGT) after the Terminal- and the Chip Authentication. This item concerns the following application(s): ePassport, eID, eSign. 32 where appropriate, see Table 2 above 33 where appropriate, see Table 2 above 34 verification of SOC 35 Secure messaging after the chip authentication, see also [EACTR], sec. 4.4.2 36 where appropriate, see Table 2 above Security Target TCOS eID_Card/SLE78CLX1440P 29/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 OT.ID_Card_Tracing Tracing ID_Card 123 The TOE must prevent gathering TOE tracing data by means of unambiguous identifying the ID_Card remotely through establishing or listening to a communication via the contactless 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 following application(s): ePassport, eID, eSign. OT.Chip_Auth_Proof Proof of ID_Card authenticity 124 The TOE must enable the terminal connected to verify the authenticity of the ID_Card as a whole device as issued by the ID_Card Issuer (issuing PKI branch of the ID_Card Issuer) by means of Passive and Chip Authentication as defined in [EACTR], sec. 4.3. This item concerns the following application(s): ePassport, eID, eSign. 125 Application Note 15: The OT.Chip_Auth_Proof implies the ID_Card’s chip to have a secret to prove its authenticity by knowledge, i.e. a Chip Authentication Private Key as TSF-data. The terminal shall have the reference data to verify the authentication attempt of ID_Card’s chip, i.e. a certificate for the respective Chip Authentication Public Key (PKPICC) fitting to the Chip Authentication Private Key (SKPICC). This certificate is provided by (i) the Chip Authentication Public Key stored on the TOE and (ii) the hash value of this PKPICC in the Card Security Object (SOC) signed by the Document Signer. OT.Prot_Abuse-Func Protection against Abuse of Functionality 126 The TOE must prevent that functions of the TOE, which may not be used in TOE ope- rational phase, can be abused in order (i) to manipulate or to disclose the User Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored in the TOE, (iii) to manipulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. This item concerns the following application(s): ePassport, eID, eSign. OT.Prot_Inf_Leak Protection against Information Leakage 127 The TOE must provide protection against disclosure of confidential User Data or/and TSF-data stored and/or processed by the ID_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 128 This item concerns the following application(s): ePassport, eID, eSign. 129 Application Note 16: This objective pertains to measurements with subsequent complex signal processing due to normal operation of the TOE or operations enforced by an attacker. OT.Prot_Phys-Tamper Protection against Physical Tampering 130 The TOE must provide protection of the confidentiality and integrity of the User Data, the TSF-data and the ID_Card’s Embedded Software by means of Security Target TCOS eID_Card/SLE78CLX1440P 30/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 • measuring through galvanic contacts representing a direct physical probing on the chip’s surface except on pads being bonded (using standard tools for measuring voltage and current) or • measuring not using galvanic contacts, but other types of physical interaction between electrical charges (using tools used in solid-state physics research and IC failure analysis), • manipulation of the hardware and its security functionality, as well as • controlled manipulation of memory contents (User Data, TSF-data) with a prior • reverse-engineering to understand the design and its properties and functionality 131 This item concerns the following application(s): ePassport, eID, eSign. OT.Prot_Malfunction Protection against Malfunctions 132 The TOE must ensure its correct operation. The TOE must prevent its operation outside the normal operating conditions where reliability and secure operation has not been proven or 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. This item concerns the following application(s): ePassport, eID, eSign. 133 The following TOE security objectives address the aspects of identified threats to be countered involving the TOE’s environment. OT.Identification Identification of the TOE 134 The TOE must provide means to store Initialization37 and Pre-Personalization Data in its non-volatile memory. The Initialization Data must provide a unique identification of the IC during the manufacturing and the card issuing life phases of the ID_Card. This item concerns the following application(s): ePassport, eID, eSign. OT.Personalization Personalization of ID_Card 135 The TOE must ensure that the user data (amongst other those concerning the ID_Card holder38) and the TSF-data permanently stored in the TOE can be written by authorized Personalization Agents only. The Card Security Object can be updated by authorized Personalization Agents (in the role of DS), if the related data have been modified. The optional eSign application can additionally be activated on the TOE on behalf of the CSP taking responsibility for this eSign application, if the ID_Card holder had applied for this. This item concerns the following application(s): ePassport, eID, eSign. 37 amongst other, IC Identification data 38 biographical and biometrical data as well as the SCD, if the eSign is operational Security Target TCOS eID_Card/SLE78CLX1440P 31/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 136 The PP ([IDCARDPP]) also includes all security objectives for the TOE of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 137 For the sake of completeness the objectives are listed below. More details can be found in the SSCD PP [SSCDPP]. Objective identifier Comments OT.Lifecycle_Security concerns the following application(s): – eSign OT.SCD/SVD_Gen concerns the following application(s): – eSign OT.SCD_Unique concerns the following application(s): – eSign OT.SCD_SVD_Corresp concerns the following application(s): – eSign OT.SCD_Secrecy concerns the following application(s): – eSign OT.Sig_Secure concerns the following application(s): – eSign OT.Sigy_SigF concerns the following application(s): – eSign OT.DTBS_Integrity_TOE concerns the following application(s): – eSign OT.EMSEC_Design concerns the following application(s): – eSign OT.Tamper_ID concerns the following application(s): – eSign OT.Tamper_Resistance concerns the following application(s): – eSign Table 6: TOE objectives taken over from [SSCDPP] 4.2 Security Objectives for the Operational Environment I. ID_Card Issuer as the general responsible 138 The ID_Card Issuer as the general responsible for the global security policy related will implement the following security objectives of the TOE environment: OE.Legislative_Compliance 139 The ID_Card Issuer must issue ID_Cards and approve using the terminals complying with all applicable laws and regulations. This item concerns the following application(s): ePassport, eID. II. ID_Card Issuer and CSCA: ID_Card’s PKI (issuing) branch 140 The ID_Card Issuer and the related CSCA will implement the following security objectives for the TOE environment: OE.Passive_Auth_Sign Authentication of ID_Card by Signature Security Target TCOS eID_Card/SLE78CLX1440P 32/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 141 The ID_Card Issuer has to establish the necessary public key infrastructure as follows: The CSCA acting on behalf and according to the policy of the ID_Card Issuer must (i) generate a cryptographic 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 Document Signer Certificates (CDS) available to the ID_Card Issuer, who makes them available to his own (domestic) CVCA as well as to the foreign CVCAs under agreement39. Hereby authenticity and integrity of these certificates are being maintained. A Document Signer acting in accordance with the CSCA policy must (i) generate a cryptographic 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 Security Objects of genuine ID_Cards in a secure operational environment only. The digital signature in the Card Security Object relates to all security information objects according to [EACTR], Appendix A. The CSCA must issue its certificates exclusively to the rightful organizations (DS) and DS must sign exclusively correct Card Security Objects having to be stored on the ID_Cards. This item concerns the following application(s): ePassport, eID. This item also covers OE.CGA_SSCD and partially OE.SVD_Auth from Table 7 below for the eSign application. OE.Chip_Auth_Key Chip Authentication Key 142 A Document Signer acting in accordance with the CSCA policy has to (i) generate the ID_Card’s Chip Authentication Key Pair {SKPICC, PKPICC} used for the chip authentication as defined in [EACTR], sec. 4.3, (ii) sign and store the Chip Authentication Public Key in the Chip Authentication Public Key Info (Appendix A of [EACTR]) and (iii) support Service Providers to verify the authenticity of the ID_Card’s chips used for genuine ID_Cards by certification of the Chip Authentication Public Key by means of the Card Security Object. A Document Signer has also to manage Restricted Identification Key Pairs {SKID, PKID} [EACTR, sec. 2.3 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. This item concerns the following application(s): ePassport, eID. This item also covers OE.CGA_SSCD and partially OE.SVD_Auth from Table 7 below for the eSign application. OE.Personalization Personalization of ID_Card 143 The ID_Card Issuer must ensure that the Personalization Agents acting on his behalf (i) establish the correct identity of the ID_Card holder and create the biographical data for the ID_Card40, (ii) enroll the biometric reference data of the ID_Card holder41, (iii) write a subset of these data on the physical Identification Card (optical personalization) and store them in the ID_Card (electronic personalization) for the ID_Card holder as defined in [EACTR], (iv) write the document details data, (v) write the initial TSF data, (vi) sign the Card Security Object defined in [ICAO9303-1] (in the role of a DS). This item concerns the following application(s): ePassport, eID. 39 CVCAs represent the roots of the receiving branch, see below 40 relevant for the ePassport, the eID and the eSign applications 41 relevant for the ePassport application Security Target TCOS eID_Card/SLE78CLX1440P 33/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 This item also partially covers OE.CGA_QCert from Table 7 below for the eSign application. III. ID_Card Issuer and CVCA: Terminal’s PKI (receiving) branch 144 The ID_Card Issuer and the related domestic CVCA as well as the foreign CVCAs under agreement (with the ID_Card Issuer Card Issuer)42 will implement the following security objectives of the TOE environment: OE.Terminal_Authentication Authentication of rightful terminals 145 The ID_Card Issuer has to establish the necessary public key infrastructure as follows: The domestic CVCA acting on behalf and according to the policy of the ID_Card Issuer as well as each foreign CVCA acting under agreement with the ID_Card Issuer and according to its policy must (i) generate a cryptographic 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 ID_Card Issuer, (who makes it available to his own CSCA43) as well as to the respective Document Verifiers, (iv) distribute Document Verifier Certificates (CDV) back to the respective Document Verifiers. Hereby authenticity and integrity of these certificates are being maintained. A CVCA has also to manage a Revocation Sector Key Pair {SKRevocation, PKRevocation} [EACTR, sec. 2.3 and 4.5]. A Document Verifier acting in accordance with the respective CVCA policy must (i) generate a cryptographic secure Document Verifying Key Pair, (ii) ensure the secrecy of the Document Verifying Private Key, (iii) hand over the Document Verifier Public Key to the respective CVCA for certification, (iv) sign the Terminal Certificates (CT) of the terminals being managed 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 authorization level of pertained terminals for differentiated data access on the ID_Card. A DV has also to manage Sector’s Static Key Pairs {SKSectorNN, PKSectorNN} [EACTR, sec. 2.3 and 4.5]. A Service Provider participating in this PKI (and, hence, acting in accordance with the policy of the related DV) must (i) generate the Terminal Authentication Key Pairs {SKPCD, PKPCD}, (ii) ensure the secrecy of the Terminal Authentication Private Keys, (iii) hand over the Terminal Authentication Public Keys {PKPCD} to the DV for certification, (iv) securely use the Terminal Authentication Private Keys for the terminal authentication as defined in [EACTR], sec. 4.4 and (v) install CT, CDV and CCVCA in the rightful terminals operated by him. CVCAs must issue their certificates exclusively to the rightful organizations (DV) and DV must issue their certificates exclusively to the rightful equipment (terminals)44. This item concerns the following application(s): ePassport, eID. This item also partially covers OE.SVD_Auth from Table 7 below for the eSign applica- tion. OE.Terminal Terminal operating 42 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. 43 CSCA represents the root of the issuing branch, see above. 44 This rule is relevant for T.Skimming Security Target TCOS eID_Card/SLE78CLX1440P 34/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 146 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 (inspection systems, authentication or signature terminals) as defined in [EACTR], sec. 3.2. 2. Their terminals implement and use the terminal parts of the PACE protocol [EACTR], sec. 4.2, of the Terminal Authentication protocol [EACTR], sec. 4.4, of the Passive Authentication [EACTR], sec. 3.4 (by verification of the signature of the Card Security Object) and of the Chip Authentication protocol [EACTR], sec. 4.345 and use them in this order46. A rightful terminal uses randomly and (almost) uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellmann). 3. Their terminals securely store the related credentials needed for the terminal authentication (terminal authentication key 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 the authorization mask for access to the data stored on the ID_Card) in order to enable and to perform the terminal authentication as defined in [EACTR, sec. 4.4]. 4. Their terminals securely store the Country Signing Public Key and the Document Signer Public Key (in form of CCSCA and CDS) in order to enable and to perform Passive Authentication of the ID_Card (determination of authenticity of PKPICC, [EACTR, sec. 4.3.1.2]). 5. Their terminals must not send assets (e.g. eSign-PIN, DTBS) to the TOE within the PACE session, but first having successfully performed the Chip Authentication after the Terminal Authentication47. 6. Their terminals and its environment must ensure confidentiality and integrity of respective data handled by it (e.g. confidentiality of PINs/PUKs, integrity of PKI certificates and DTBS, etc.), where it is necessary for a secure operation of the TOE according to the current PP. 147 This item concerns the following application(s): ePassport, eID. This item also partially covers OE.CGA_SVD, OE.HID_VAD, OE.SCA_DTBS, OE.SVD_ Auth, OE.DTBS_Intend from Table 7 below for the eSign application. 45 The Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol with- in the [IDCARDPP] 46 This order is only commensurate with the branch rightmost in Fig. 3.1 [EACTR, sec. 3.1.1]. Other branches of this figure are not covered by the security policy of [IDCARDPP]. 47 This rule is relevant for T.Skimming. Security Target TCOS eID_Card/SLE78CLX1440P 35/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 IV. ID_Card Holder Obligations OE.ID_Card-Holder ID_Card Holder Obligations 148 The ID_Card Holder has to keep his or her verification values of eID-PIN and eID-PUK secret. The ID_Card Holder may reveal, if necessary, his or her verification values of CAN and MRZ to an authorized person or device who definitely act according to respective regulations and are trustworthy. This item concerns the following application(s): ePassport, eID. This item also partially covers OE.Signatory from table below for the eSign application. 149 The PP ([IDCARDPP]) also includes all security objectives for the TOE’s environment of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 150 For the sake of completeness the security objectives for the TOE’s environment are listed below. More details can be found in the SSCD PP [SSCDPP]. Objective identifier Comments OE.SVD_Auth concerns the following application(s): – eSign OE.CGA_QCert enforces the property #3 (CSP duties) of P.Trustworthy_PKI concerns the following application(s): – eSign OE.DTBS_Intend concerns the following application(s): – eSign OE.Signatory concerns the following application(s): – eSign OE.SSCD_Prov_Service concerns the following application(s): – eSign This environmental objective shall be achieved in such a way that (i) the CSP checks by means of the CGA, whether the device presented by the applicant for the (qualified) certificate examples holds unique identification as SSCD and is able to prove this identity; (ii) CGA detects alteration of the SVD imported from the TOE and verifies the correspondence between the SCD in the SSCD of the signatory and the SVD in the (qualified) certificate. OE.HID_VAD concerns the following application(s): – eSign This environmental objective shall be achieved in such a way that HID provides the human interface for user authentication and HID ensures confidentiality of the VAD as needed by the authentication method employed including export to the TOE by means of a trusted channel. OE.DTBS_Protect concerns the following application(s): – eSign This environmental shall be achieved in such a way that SCA provides a trusted channel to the TOE for the protection of the integrity of the DTBS to ensure that the DTBS representation cannot be altered undetected in transit between the SCA and the TOE. Table 7: TOE’s environment objectives taken over from [SSCDPP] Security Target TCOS eID_Card/SLE78CLX1440P 36/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 4.3 Security Objective Rationale 151 The following table provides an overview for security objectives coverage (TOE and its environment). 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. OT.Identification OT.Personalization OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.ID_Card_Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OE.Personalization OE.Passive_Auth_Sign OE.Chip_Auth_Key OE.Terminal_Authentication OE.Terminal OE.ID_Card-Holder OE.Legislative_Compliance OE.CGA_QCert ([SSCDPP]) T.Skimming x x x x x x T.Eavesdropping x T.ID_Card_Tracing x x T.Forgery x x x x x x x T.Counterfeit 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.ID_Card_PKI x x P.Terminal_PKI x P.Trustworthy_PKI x x x Table 8:Security Objective Rationale 152 A detailed justification required for suitability of the security objectives to coup with the security problem definition is given below. 153 The threat T.Skimming addresses accessing the User Data (stored on the TOE or transferred 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 authentication (its property ‘CVCAs must issue their certificates exclusively to the rightful organizations (DV) and DV must issue their certificates exclusively to the rightful equipment (terminals)’). The objective OE.Terminal sets a prerequisite up that no assets will be transferred between the TOE and the Service Provider before the Chip Authentication has successfully been accomplished (in its property ‘Their (Service Provider’s – remark given by the author of the PP) terminals Security Target TCOS eID_Card/SLE78CLX1440P 37/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 must not send assets (e.g. eSign-PIN, DTBS) to the TOE within the PACE session, but first having successfully performed the chip authentication’). The objective OE.ID_Card- Holder ensures that a PACE session can only be established either by the ID_Card holder itself or by an authorized person or device, and, hence, cannot be captured by an attacker. 154 The threat T.Eavesdropping addresses listening to the communication between the TOE and a rightful terminal in order to gain the User Data transferred there. This threat is countered by the security objective OT.Data_Confidentiality through the Chip Authentication. 155 The threat T.ID_Card_Tracing addresses gathering TOE tracing data identifying it remotely by establishing or listening to a communication 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 threat is directly countered by security objectives OT.ID_Card_Tracing (no gathering TOE tracing data) and OE.ID_Card-Holder (the attacker does not a priori know the correct values of the shared passwords). 156 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.Personalization requires the TOE to limit the write access for the ID_Card to the trustworthy Personalization Agent (cf. OE.Personalization). 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_In- tegrity 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 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. 157 The threat T.Counterfeit addresses the attack of unauthorized copy or reproduction of the genuine ID_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 ID_Card. 158 The threat T.Abuse-Func addresses attacks of misusing TOE’s functionality to mani- pulate 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 ensu- res that the usage of functions having not to be used in the operational phase is effectively prevented. 159 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. 160 The OSP P.Pre-Operational is enforced by the following security objectives: 161 OT.Identification is affine to the OSP’s property ‘traceability before the operational phase’; Security Target TCOS eID_Card/SLE78CLX1440P 38/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 162 OT.Personalization and OE.Personalization together enforce the OSP’s properties ‘correctness of the User- and the TSF-data stored’ and ‘authorization of Personalization Agents’; 163 OE.Legislative_Compliance is affine to the OSP’s property ‘compliance with laws and regulations’. 164 The OSP P.Terminal is obviously enforced by the objective OE.Terminal, whereby the one-to-one mapping between the related properties is applicable. 165 The OSP P.ID_Card_PKI is enforced by establishing the issuing PKI branch as aimed by the objectives OE.Passive_Auth_Sign (for the Card Security Object) and OE.Chip_\ Auth_Key (for managing the ID_Card’s Chip Authentication Key Pairs). 166 The OSP P.Terminal_PKI is enforced by establishing the receiving PKI branch as aimed by the objective OE.Terminal_Authentication. 167 The OSP P.Trustworthy_PKI is enforced by OE.Passive_Auth_Sign (for CSCA, issuing PKI branch), by OE.Terminal_Authentication (for CVCA, receiving PKI branch) and by OE.CGA_QCert (see [SSCDPP]). 168 The rationale related to the security objectives taken over from [SSCDPP] are exactly the same as given for the respective items of the security policy definitions in sec. 4.3 of [SSCDPP]. 169 The following Security Objectives for the Hardware Platform are based on [PP0035]: O.Leak-Inherent (Protection against Inherent Information Leakage) O.Phys-Probing (Protection against Physical Probing) O.Malfunction (Protection against Malfunctions) O.Phys-Manipulation (Protection against Physical Manipulation) O.Leak-Forced (Protection against Forced Information Leakage) O.Abuse-Func (Protection against Abuse of Functionality) O.Identification (TOE Identification) 170 They are all relevant and do not contradict Security Objectives of the TOE. They can be mapped to corresponding objectives of the TOE. 171 The remaining objective O.RND is covered by Security Objectives OT.Data_Integrity, and OT.Data_Confidentiality. These Security Objectives of the TOE address the integrity and confidentiality of transmitted data, based on the protocols of Terminal and Chip Authentication, depending on a high cryptographic quality of random number generation. Therefore this objective is supported by Security Objectives of the TOE. 172 The detailed analysis of Security Objectives derived from the hardware platform ST [HWST] and the environment of the Hardware Platform is made separately in chapter 7.10 (Statement of Compatibility). Security Target TCOS eID_Card/SLE78CLX1440P 39/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 5 Extended Components Definition 173 This protection profile uses components defined as extensions to CC part 2. All these extended components are drawn from Definitions of chapter 5 of [IDCARDPP]. 5.1 FAU_SAS Audit data storage 174 The family “Audit data storage (FAU_SAS)” is specified as follows. Family behavior This family defines functional requirements for the storage of audit data. Component leveling FAU_SAS.1 Requires the TOE to provide the possibility to store audit data. Management: FAU_SAS.1 There are no management activities foreseen. Audit: FAU_SAS.1 There are no actions defined to be auditable. FAU_SAS.1 Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide [assignment: authorized users] with the capa- bility to store [assignment: list of audit information] in the audit records. 5.2 FCS_RND Generation of random numbers 175 The family “Generation of random numbers (FCS_RND)” is specified as follows. Family behavior This family defines quality requirements for the generation of random numbers which are intended to be used for cryptographic purposes. Component leveling: FCS_RND Generation of random numbers 1 FAU_SAS Audit data storage 1 Security Target TCOS eID_Card/SLE78CLX1440P 40/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FCS_RND.1 Generation of random numbers requires that random numbers meet a defined quality metric. Management: FCS_RND.1 There are no management activities foreseen. Audit: FCS_RND.1 There are no actions defined to be auditable. FCS_RND.1 Quality metric for random numbers Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet [assignment: a defined quality metric]. 5.3 FIA_API Authentication Proof of Identity 176 The family “Authentication Proof of Identity (FIA_API)” is specified as follows. Family behavior 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. Component levelling: FIA_API.1 Authentication Proof of Identity. Management: FIA_API.1 The following actions could be considered for the management functions in FMT: Management of authentication information used to prove the 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. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to prove the identity of the [assignment: authorized user or role]. FIA_API Authentication Proof of Identity 1 Security Target TCOS eID_Card/SLE78CLX1440P 41/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 5.4 FMT_LIM Limited capabilities and availability 177 The family “Limited capabilities and availability (FMT_LIM)” is specified as follows. Family behaviour This family defines requirements that limit the capabilities and availability of functions in a combined manner. Note, that FDP_ACF restricts the access to functions whereas the Limited capability of this family requires the functions themselves to be designed in a specific manner. Component leveling: FMT_LIM.1 Limited capabilities require that the TSF is built to provide only the capabilities (perform action, gather information) which are necessary for its genuine purpose. 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 lifecycle. Management: FMT_LIM.1, FMT_LIM.2 There are no management activities foreseen. Audit: FMT_LIM.1, FMT_LIM.2 There are no actions defined to be auditable. The TOE Functional Requirement “Limited capabilities (FMT_LIM.1)” is specified as follows. FMT_LIM.1 Limited capabilities Hierarchical to: No other components. FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced [assignment: Limited capability and availability policy]. Dependencies: FMT_LIM.2 Limited availability. The TOE Functional Requirement “Limited availability (FMT_LIM.2)” is specified as follows. FMT_LIM.2 Limited availability FMT_LIM Limited capabilities and availability 1 2 Security Target TCOS eID_Card/SLE78CLX1440P 42/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Hierarchical to: No other components. 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 [assignment: Limited capability and availability policy]. Dependencies: FMT_LIM.1 Limited capabilities. 5.5 FPT_EMSEC TOE Emanation The family “TOE Emanation (FPT_EMSEC)” is specified as follows. Family behavior This family defines requirements to mitigate intelligible emanations. Component leveling: 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 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. 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]. FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. Dependencies: No other components. FPT_EMSEC TOE emanation 1 Security Target TCOS eID_Card/SLE78CLX1440P 43/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 6 Security Requirements 178 This part of the PP defines the detailed security requirements that shall be satisfied by the TOE. The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE. 179 The CC allows several operations to be performed on functional requirements; refinement, selection, assignment, and iteration are defined in section 8.1 of Part 1 of the Common Criteria [CC]. Each of these operations is used in this ST. 180 The refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinements of security requirements are denoted in such a way that added words are in bold text and removed are crossed out. 181 The selection operation is used to select one or more options provided by the CC in stating a requirement. Selections having been made by the PP author are denoted as underlined text. Selections made by the ST author appear slanted and underlined. 182 The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignments having been made by the PP author are denoted by showing as underlined text. Assignments made by the ST author appear slanted and underlined. 183 The iteration operation is used when a component is repeated with varying operations. Iteration is denoted by showing a slash “/”, and the iteration indicator after the component identifier. For the sake of a better readability, the iteration operation may also be applied to some single components (being not repeated) in order to indicate belonging of such SFRs to same functional cluster. In such a case, the iteration operation is applied to only one single component. 184 In order to distinguish between the SFRs taken over from the SSCD PP [SSCDPP] and other SFRs having the same denotation, these SFRs are iterated by ‘/SSCD’ or ‘/XXX_SSCD’. 6.1 Security Functional Requirements for the TOE 6.1.1 Overview 185 In order to give an overview of the security functional requirements mentioned in 1.4.2 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 in the following sections to them. Security Functional Groups Security Functional Requirements concerned Access control to the User Data stored in the TOE – {FDP_ACC.1/TRM, FDP_ACF.1/TRM} Supported by: – FIA_UAU.1/Rightful_Terminal: Terminal Authentication (EIS, ATT, SGT) – {FDP_ACC.1/Signature-creation_SFP_SSCD, FDP_ACF.1/Signature- Security Target TCOS eID_Card/SLE78CLX1440P 44/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Security Functional Groups Security Functional Requirements concerned creation_SFP_SSCD} Secure data exchange between the ID_Card and the Service Provider connected – FTP_ITC.1/CA: trusted channel Supported by: – FCS_COP.1/AES: encryption/decryption – FCS_COP.1/CMAC: MAC generation/verification – FIA_API.1/CA: Chip Identification/Authentication – FIA_UAU.1/Rightful_Terminal: Terminal Authentication (EIS, ATT, SGT) Identification and authentication of users and components – FIA_UID.1/PACE: PACE Identification (PCT) – FIA_UID.1/Rightful_Terminal: Terminal Identification (EIS, ATT, SGT) – FIA_UAU.1/PACE: PACE Authentication (PCT) – FIA_UAU.1/Rightful_Terminal: Terminal Authentication (EIS, ATT, SGT) – FIA_API.1/CA: Chip Identification/Authentication – FIA_UAU.4: single-use of authentication data – FIA_UAU.5: multiple authentication mechanisms – FIA_UAU.6: Re-authentication of Terminal – FIA_AFL.1/eID-PIN_Suspending – 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 unsuccessful authentication attempts for establishing PACE communication using non-blocking authentication and authorisation data – FIA_UID.1/SSCD: Identification of ID_Card holder as Signatory (eSign-PIN) – FIA_UIA.1/SSCD: Authentication of ID_Card holder as Signatory (eSign-PIN) – FIA_AFL.1/SSCD: Blocking of the Signatory’s RAD (eSign-PIN) Supported by: – FCS_CKM.1/DH_PACE: PACE authentication (PCT) – FCS_COP.1/SIG_VER: Terminal Authentication (EIS, ATT, SGT) – FCS_CKM.1/DH_CA: Chip Authentication – FCS_CKM.2/DH: Diffie-Hellmann key distribution within PACE and Chip authentication – FCS_CKM.4: session keys destruction (authentication expiration) – FCS_COP.1/SHA: Keys derivation – FCS_RND.1: random numbers generation – FTP_ITC.1/PACE: preventing tracing while establishing Chip Authentication – FMT_SMR.1: security roles definition. Audit – FAU_SAS.1: Audit storage Supported by: – FMT_MTD.1/INI_ENA: Writing Initialization and Pre-personalization – FMT_MTD.1/INI_DIS: Disabling access to Initialization and Pre-personalization Data in the operational phase Generation of the Signature Key Pair for the eSign application – 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 Digital Signatures by the eSign application – FCS_COP.1/SSCD Management of and access to TSF and TSF-data – The entire class FMT Security Target TCOS eID_Card/SLE78CLX1440P 45/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Security Functional Groups Security Functional Requirements concerned Supported by: – the entire class FIA: user identification/authentication – FCS_CKM.1.1/CA_PICC für CA key generation Accuracy of the TOE security functionality / Self-protection – The entire class FPT – FDP_RIP.1: enforced memory/storage cleaning – FDP_SDI.2/Persistent_SSCD – FDP_SDI.2/DTBS_SSCD Supported by: – the entire class FMT. Table 9: Security functional groups vs. SFRs 186 The following table provides an overview of the keys and certificates used: Name Data Receiving PKI branch Country Verifying Certification Authority Private Key (SKCVCA) The Country Verifying Certification Authority (CVCA) holds a private key (SKCVCA) used for signing the Document Verifier Certificates. Country Verifying Certification Authority Public Key (PKCVCA) The TOE stores the Country Verifying Certification Authority Public Key (PKCVCA) as part of the TSF data to verify the Document Verifier Certificates. Country Verifying Certification Authority Certificate (CCVCA) The Country Verifying Certification Authority Certificate may be a self-signed certificate or a link certificate (cf. [EACTR] and Glossary). It contains (i) the Country Verifying Certification Authority Public 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) The Document Verifier Certificate CDV is issued by the Country Verifying Certification Authority. It contains (i) the Document Verifier Public Key (PKDV) as authentication reference data (ii) identification as domestic or foreign Document Verifier, the coded access control rights of the Document Verifier, the Certificate Effective Date and the Certificate Expiration Date as security attributes. Terminal Certificate (CT) The Terminal Certificate (CT) is issued by the Document Verifier. It contains (i) the Terminal Public Key (PKT) as authentication reference data, (ii) the coded access control rights of the terminal (EIS, 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 Country Signing Certification Authority of the ID_Card issuer signs the Document Signer Public Key Certificate (CDS) with the Country Signing Certification Authority Private Key (SKCSCA) and the signature will be verified by receiving terminal with the Country Signing Certification Authority Public Key (PKCSCA). The CSCA also issues the self-signed Country Signing CertA Certificate (CCSCA) having to be distributed by strictly secure diplomatic means, see. [ICAO9303-1], 5.1.1. Document Signer Key Pairs and Certificates The Document Signer Certificate CDS is issued by the Country 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 Security Object (SOC) of the ID_Card with the Document 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) PKPICC is stored in an EF on the ID_Card and used by the terminal for Chip Authentication. Its authenticity is verified by terminal in the context of the Passive Authentication (verification of SOC). Chip Authentication Private Key (SKPICC) The Chip Authentication Key Pair (SKPICC, PKPICC) is used for Key Agreement Protocol: Diffie-Hellman (DH) according to RFC 2631 or Elliptic Curve Diffie-Hellman (ECDH, ECKA key agreement algorithm) according to [ECCTR, sec. A.2]. Security Target TCOS eID_Card/SLE78CLX1440P 46/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Name Data SKPICC is used by the TOE to authenticate itself as authentic ID_Card. Session keys PACE Session Keys (PACE- KMAC, PACE-KEnc) Secure messaging AES keys for message authentication (CMAC-mode) and for message encryption (CBC-mode) agreed between the TOE and a terminal (PCT) as result of the PACE Protocol, see [EACTR], sec. A.3, F.2.3. Chip Authentication Session Keys (CA-KMAC, CA-KEnc) Secure messaging AES keys for message authentication (CMAC-mode) and for message encryption (CBC-mode) agreed between the TOE and a terminal (EIS, ATT, SGT) as result of the Chip Authentication Protocol, see [EACTR], sec. A.4, F.2.3. Restricted Identification Keys Restricted Identification Key Pair {SKID, PKID} Static Diffie-Hellman key pair, whereby the related private key SKID is stored in the TOE and used for generation of the sector-specific chip-identifier Sector ID I (pseudo- anonymization), see [EACTR, sec. 4.1.2, 4.1.3.1, 4.5.1]. This key represents user data within the current security policy. The belonging public key PKID is used for a revocation request and should not be stored in the TOE, see [EACTR, sec. 4.1.2, 4.1.3.1, 4.5.3]. Signature keys Signature Creation Key Pair (SCD/SVD) Signature Creation Data (SCD) is represented by a private cryptographic key being used by the ID_Card holder (signatory) to create an electronic signature. Signature Verification Data (SVD) is represented by a public cryptographic key corresponding with SCD and being used for the purpose of verifying an electronic signature. Properties of this key pair shall fulfil the relevant requirements stated in [ALGO] in order to be compliant with the German Signature Act. Table 10: Keys and Certificates 6.1.2 Class FCS Cryptographic Support 6.1.2.1 Cryptographic key generation (FCS_CKM.1) 187 The following iterations are caused by different cryptographic key generation algorithms to be implemented and keys to be generated by the TOE. 188 FCS_CKM.1/DH_PACE Cryptographic key generation – Diffie-Hellman Keys for PACE Hierarchical to: 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_CKM.4 FCS_CKM.1.1/ DH_PACE The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to [ECCTR]48 and specified cryptographic key sizes 128, 192 and 256 bit49 that meet the following: [EACTR], Appendix A.350. 48 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 49 [assignment: cryptographic key sizes] Security Target TCOS eID_Card/SLE78CLX1440P 47/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 Systems International GmbH, 2010 This item concerns the following application(s): ePassport, eID, eSign. 189 Application Note 17: The TOE generates a shared secret value with the terminal during the PACE Protocol, see [EACTR, sec. 4.2 and A.3]. The shared secret value is used to derive the AES session keys for message encryption and message authentication (PACE-KMAC, PACE-KEnc) according to [EACTR, F.2.3] for the TSF required by FCS_\ COP.1/AES and FCS_COP.1/CMAC. Note that a specified key size defines also the hash function used for key derivation. 190 Application Note 18: The TOE supports the following standardized elliptic curve domain parameters (cf. [EACTR, A.2.1.1]) for key generation: ID Name Size Reference 9 brainpoolP192r1 192 [RFC5639, 3.2] 11 brainpoolP224r1 224 [RFC5639, 3.3] 12 NIST P-256 (secp256r1) 256 [FIPS186, D.1.2.3] 13 brainpoolP256r1 256 [RFC5639, 3.4] 14 brainpoolP320r1 320 [RFC5639, 3.5] 16 brainpoolP384r1 384 [RFC5639, 3.6] 17 brainpoolP512r1 512 [RFC5639, 3.7] 191 FCS_CKM.1/DH_CA Cryptographic key generation – Diffie-Hellman Keys for Chip Authentication Hierarchical to: 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_CKM.4 FCS_CKM.1.1/ DH_CA The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to [ECCTR]51 and specified cryptographic key sizes 128, 192 and 256 bit52 that meet the following: [EACTR] Annex A.453. This item concerns the following application(s): ePassport, eID, eSign. 192 Application Note 19: The TOE generates a shared secret value with the terminal during the CA Protocol, see [EACTR], sec. 4.3 and A.4. 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 [EACTR], F.2.3 for the TSF required by FCS_COP.1/ AES and FCS_COP.1/CMAC. Note that a specified key size defines also the hash func- tion used for key derivation. 50 [assignment: list of standards] 51 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 52 [assignment: cryptographic key sizes] 53 [assignment: list of standards] Security Target TCOS eID_Card/SLE78CLX1440P 48/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 193 Application Note 20: The TOE supports the following standardized elliptic curve domain parameters (cf. [EACTR, A.2.1.1]) for key generation: ID Name Size Reference 9 brainpoolP192r1 192 [RFC5639, 3.2] 11 brainpoolP224r1 224 [RFC5639, 3.3] 12 NIST P-256 (secp256r1) 256 [FIPS186, D.1.2.3] 13 brainpoolP256r1 256 [RFC5639, 3.4] 14 brainpoolP320r1 320 [RFC5639, 3.5] 16 brainpoolP384r1 384 [RFC5639, 3.6] 17 brainpoolP512r1 512 [RFC5639, 3.7] 194 FCS_CKM.1/CA_PICC Cryptographic key generation – Chip Authentication Key Pair Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation]: fulfilled by FCS_COP.1/AES and FCS_COP.1/CMAC FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_CKM.1.1/ CA_PICC The TSF shall generate an ECDSA key cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDSA key generation compliant to [ECCTR]54 and specified cryptographic key sizes 224, 256, 320, 384 and 512 bit length group order55 that meet the following: [EACTR]56. This item concerns the following application(s): ePassport, eID, eSign. 195 Application Note 21: The Chip Authentication Key Pair Generation operation is only avai- lable during Personalization Phase (Phase 3) (cf. FMT_MTD.1/SK_PICC) and not in Phase 4 “Operational Use”. 196 Application Note 22: This SFR for Chip Authentication Key Pair Generation operation is added according to the recommendation of the Protection Profile [IDCARDPP, Application note 68]. 197 FCS_CKM.2/DH Cryptographic key distribution – Diffie-Hellman Hierarchical to: No other components. 54 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 55 [assignment: cryptographic key sizes] 56 [assignment: list of standards] Security Target TCOS eID_Card/SLE78CLX1440P 49/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 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 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_CKM.2.1/DH The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method as specified in the list below57 that meets the following: 1. PACE: as specified in [EACTR, sec. 4.2 and A.3]; 2. CA: as specified in [EACTR, sec. 4.3 (version2) and A.4]58. This item concerns the following application(s): ePassport, eID, eSign. 198 FCS_CKM.4 Cryptographic key destruction Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: fulfilled by FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method physical deletion by overwriting the memory data with zeros, random numbers or the new key59 that meets the following: none60. This item concerns the following application(s): ePassport, eID, eSign. 199 Application Note 23: This SFR applies to the Session Keys, i.e. the TOE shall destroy the PACE Session Keys (i) after detection of an error in a received command by verification of the MAC, and (ii) after successful run of the Chip Authentication Protocol. The TOE shall destroy the CA Session Keys after detection of an error in a received command by verification of the MAC. The TOE shall clear the memory area of any session keys before starting the communication with the terminal in a new after-reset- session as required by FDP_RIP.1. This SFR applies also to the Chip Authentication Key SKPICC, if generated by the Perso- nalization Agent and the Signature Key SCD. The TOE will overwrite the assigned to the key memory data with the new key. 6.1.2.2 Cryptographic operation (FCS_COP.1) 200 The following iterations are caused by different cryptographic algorithms to be implemented by the TOE. 57 [assignment: cryptographic key distribution method] 58 [assignment: list of standards] 59 [assignment: cryptographic key destruction method] 60 [assignment: list of standards] Security Target TCOS eID_Card/SLE78CLX1440P 50/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 201 FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: not fulfilled, but justi- fied: A hash function does not use any cryptographic key; hence, neither a respective key import nor key generation can be expected here. FCS_CKM.4 Cryptographic key destruction: not fulfilled, but justi- fied: A hash function does not use any cryptographic key; hence, a respective key destruction cannot be expected here. FCS_COP.1.1/ SHA The TSF shall perform hashing61 in accordance with a specified cryptographic algorithm SHA-1 and SHA-256 62 and cryptographic key sizes none63 that meet the following: FIPS 180-2 64. This item concerns the following application(s): ePassport, eID, eSign. 202 Application Note 24: For hashing an ephemeral public key for DH (PACE65 and CA66), the hash function SHA-1 will be used ([EACTR], table A.2), but this is not relevant for the TOE. The TOE implements hash functions either SHA-1 or SHA-224 or SHA-256 for the Terminal Authentication Protocol (cf. [EACTR], tables A.9 and A.10). Within the normative Appendix F of [EACTR, sec.F.2.3.1] ‘Key Derivation’ states that for deriving 128-bit AES keys the hash function SHA-1, whereas for deriving 192-bit and 256-bit AES keys SHA-256 shall be used. 203 FCS_COP.1/SIG_VER Cryptographic operation – Signature verification Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: not fulfilled, but justi- fied: The root key PKCVCA used for verifying CDV is stored in the TOE during its personalisation (in the card issuing life phase). Since importing the respective certificates (CT, CDV) does not require any special security measures except those required by the current SFR (cf. FMT_MTD.3 below), the PP ([IDCARDPP]) does not contain any dedicated requirement like FDP_ITC.2 for the import function. 61 [assignment: list of cryptographic operations] 62 [assignment: cryptographic algorithm] 63 [assignment: cryptographic key sizes] 64 [assignment: list of standards] 65 IDPICC = H(ephem-PKPICC-PACE) in [EACTR], sec. 4.4 66 H(ephem-PKPCD-TA) in [EACTR], sec. 4.3.1.2 Security Target TCOS eID_Card/SLE78CLX1440P 51/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FCS_CKM.4 Cryptographic key destruction: not fulfilled, but justi- fied: 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/ SIG_VER The TSF shall perform digital signature verification67 in accordance with a specified cryptographic algorithm ECDSA with plain signature format 68 and cryptographic key sizes 192, 224, 256 and 320 bit length group order 69 that meet the following: [EACTR]70. This item concerns the following application(s): ePassport, eID, eSign. 204 Application Note 25: The ECDSA with plain signature format is selected for the signature algorithm implemented by the TOE for the Terminal Authentication Protocol (cf. [EACTR], Appendix A.6.4 and D.3.3 for details). The signature verification is used to verify the card verifiable certificates and the authentication attempt of the terminal generated a digital signature for the TOE challenge, see [EACTR], sec. 4.4. The respective static public keys are imported within the respective certificates (CT, CDV) during the TA and are extracted by the TOE using PKCVCA as the root key stored in the TOE during its personalization (see P.Terminal_PKI). 205 FCS_COP.1/AES Cryptographic operation – Encryption/Decryption AES Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: fulfilled by FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4 FCS_COP.1.1/ AES The TSF shall perform secure messaging – encryption and decryp- tion71 in accordance with a specified cryptographic algorithm AES in CBC mode72 and cryptographic key sizes 128, 192 and 256 bit73 that meet the following: FIPS 197 [FIPS197] and [EACTR] Appendix F.2.274. This item concerns the following application(s): ePassport, eID, eSign. 206 Application Note 26: This SFR requires the TOE to implement the cryptographic primitive AES for secure messaging with encryption of the transmitted data. The related session keys are agreed between the TOE and the terminal as part of either PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KEnc) or the Chip Authentication Pro- 67 [assignment: list of cryptographic operations] 68 [assignment: cryptographic algorithm] 69 [assignment: cryptographic key sizes] 70 [assignment: list of standards] 71 [assignment: list of cryptographic operations] 72 [assignment: cryptographic algorithm] 73 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] 74 [assignment: list of standards] Security Target TCOS eID_Card/SLE78CLX1440P 52/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 tocol according to the FCS_CKM.1/DH_CA (CA-KEnc). Note that in accordance with [EACTR] Appendix F.2.2 the (two-key) Triple-DES could be used in CBC mode for secure messaging. Due to the fact that (two-key) Triple-DES is not recommendend anymore by the BSI, Triple-DES is not applicable within the PP (cf. [IDCARDPP]). 207 FCS_COP.1/CMAC Cryptographic operation – CMAC Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] ]; fulfilled by FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4 Cryptographic key destruction: ]; fulfilled by FCS_CKM.4. FCS_COP.1.1/ CMAC The TSF shall perform secure messaging – message authentica- tion code75 in accordance with a specified cryptographic algorithm CMAC76 and cryptographic key sizes 128, 192 or 256 bit77 that meet the following: [SP800-38B] and [EACTR] Appendix F.2.278. This item concerns the following application(s): ePassport, eID, eSign. 208 Application Note 27: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with message authentication code over the transmitted data. The related session keys are agreed between the TOE and the terminal as part of either PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KMAC) or the Chip Authentication Protocol according to the FCS_CKM.1/DH_CA (CA-KMAC). Note that in accordance with [EACTR] Appendix F.2.2 DES could be used in Retail mode for secure messaging. Due to the fact that Retail-MAC is not recommendend anymore by the BSI, this algorithm is not applicable within the PP (cf. [IDCARDPP]). 6.1.2.3 Random Number Generation (FCS_RND.1) 209 FCS_RND.1 Quality metric for random numbers Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet the functionality class P2 with SOF “high” according to [AIS31]79. This item concerns the following application(s): ePassport, eID, eSign. 75 [assignment: list of cryptographic operations] 76 [assignment: cryptographic algorithm] 77 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] bit 78 [assignment: list of standards] 79 [assignment: a defined quality metric] Security Target TCOS eID_Card/SLE78CLX1440P 53/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 210 Application Note 28: This SFR requires the TOE to generate random numbers (random nonce) used for the authentication protocols (PACE, CA and TA) as required by FIA_UAU.4. 211 The PP ([IDCARDPP]) also includes all SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. For the functional class FCS there are the following components: SFR identifier Comments FCS_CKM.1/SSCD concerns the following application(s): – eSign FCS_CKM.4/SSCD This SFR is covered by FCS_CKM.4. concerns the following application(s): – eSign FCS_COP.1/SSCD concerns the following application(s): – eSign 212 FCS_CKM.1/SSCD Cryptographic key generation Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation]: fulfilled by FCS_COP.1/SSCD FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4/SSCD FCS_CKM.1.1/ SSCD The TSF shall generate an SCD/SVD pair cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDSA key generation compliant to [ECCTR]80 and specified cryptographic key sizes 224, 256, 320, 384 and 512 bit length group order 81 that meet the following: [EACTR]82. 213 Application Note 29: The SCD/SVD Key Pair Generation requires authentication as Certification Service Provider (CSP) and is not available to other subjects (cf. FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD. 214 FCS_COP.1/SSCD Cryptographic operation – Digital Signature Generation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: fulfilled by FCS_CKM.1/SSCD 80 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 81 [assignment: cryptographic key sizes] 82 [assignment: list of standards] Security Target TCOS eID_Card/SLE78CLX1440P 54/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FCS_CKM.4 Cryptographic key destruction]: fulfilled by FCS_CKM.4/SSCD. FCS_COP.1.1/ SSCD The TSF shall perform digital signature generation83 in accordance with a specified cryptographic algorithm ECDSA compliant to [ECCTR]84 and cryptographic key sizes 224, 256, 320, 384 and 512 bit length group order85 that meet the following: [ECCTR]86. 6.1.3 Class FIA Identification and Authentication 215 Application Note 30: The Table 11 provides an overview of the authentication mechanisms used. Name SFR for the TOE Comments PACE protocol FIA_UAU.1/PACE FIA_UAU.5 FIA_AFL.1/eID-PIN_Suspending FIA_AFL.1/eID-PIN_Blocking FIA_AFL.1/PACE as required by FCS_CKM.1/DH_PACE Terminal Authentication Protocol FIA_UAU.1/Rightful_Terminal FIA_UAU.5 as required by FCS_COP.1/SIG_VER Chip Authentication Protocol FIA_API.1/CA, FIA_UAU.5, FIA_UAU.6 as required by FCS_CKM.1/DH_CA eSign-PIN FIA_UAU.1/SSCD - Table 11: Overview of authentication SFRs 216 FIA_AFL.1/eID-PIN_Suspending Authentication failure handling – Suspending 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 an administrator configurable positive integer sad within the range 1 ≤ sad ≤ 6 according to [TCOSADM] 87 unsuccessful authentication attempts occur related to consecutive failed authentication attempts using eID-PIN as the shared password for PACE88. 83 [assignment: list of cryptographic operations] 84 [assignment: cryptographic algorithm] 85 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] bit 86 [assignment: list of standards] 87 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 88 [assignment: list of authentication events] Security Target TCOS eID_Card/SLE78CLX1440P 55/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met89, the TSF shall suspend the reference value of eID- PIN according to [EACTR], sec. 3.3.290. This item concerns the following application(s): eID, eSign. 217 According to [EACTR], sec. 3.3.2, at least the current value 1 of the retry counter for eID-PIN shall be a suspending value, i.e. if this value is reached the eID-PIN must be suspended. Nevertheless the administrator may select a different suspending value and a corresponding initial value. The assignment must be according with requirements given in [TCOSADM]. 218 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 an administrator configurable positive integer bad within the range 1 ≤ bad ≤ 3 according [TCOSADM]91 unsuccessful authentication attempts occur related to consecutive failed authentication attempts using suspended eID-PIN as the shared password for PACE92. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met93, the TSF shall block the reference value of eID-PIN according to [EACTR], sec. 3.3.294. This item concerns the following application(s): eID. 219 Application Note 31: According to [EACTR], sec. 3.3.2, the eID-PIN must be in the suspending state if the current value of the retry counter RC is 1, the blocking current value of the retry counter for eID-PIN shall be RC = 0. Nevertheless the administrator may configure the TOE such that it suspends already the eID-PIN if the retry counter reaches the value bad. The assignment shall be consistent with the implemented authen- tication mechanism and resistant against attacks with high attack potential. No more then bad + sad ≤ 9 overall tries of the eID-PIN are allowed. 220 FIA_AFL.1/PACE Authentication failure handling – PACE authenti- cation using non-blocking authentication/autho- rization data Hierarchical to: No other components. 89 [selection: met, surpassed] 90 [assignment: list of actions] 91 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 92 [assignment: list of authentication events] 93 [selection: met, surpassed] 94 [assignment: list of actions] Security Target TCOS eID_Card/SLE78CLX1440P 56/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE FIA_AFL.1.1 The TSF shall detect when 195 unsuccessful authentication attempts occurs related to authentication attempts using CAN, MRZ, eID-PUK as shared passwords for PACE96. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met97, the TSF shall require the restart of the PACE pro- tocol98. This item concerns the following application(s): ePassport, eID, eSign. 221 Application Note 32: The assignment operation reflects the fact that according the implementation the authentication procedure consumes a defined minimal amount of time. Because MRZ and eID-PUK possesses enough entropy for this reaction time (cf. Administrator Guidance [TCOSADM]), this is sufficient even to prevent a brute force attack with attack potential beyond high (to recover a random 10 digit number would require already about 300 years). Since the CAN does not represent a secret, because it may be revealed already to external entities (cf. footnote 12 on p. 17), there is no need to consider a brute force attack against the CAN. The waiting time after restart of the PACE protocol is sufficient to prevent the skimming of the TOE even for a random 6 digit CAN value. 222 FIA_API.1/CA Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide the Chip Authentication Protocol according to [EACTR], sec. 4.3, Version 2 99 to prove the identity of the TOE100. This item concerns the following application(s): ePassport, eID, eSign. 223 Application Note 33: The Chip Authentication shall be triggered by the rightful terminal immediately after the successful Terminal Authentication (as required FIA_UAU.1/ Right- ful_Terminal) using, amongst other, H(ephem-PKPCD-TA) from the accomplished TA. The terminal verifies genuineness of the ID_Card by verifying the authentication token TPICC calculated by the ID_Card using ephem-PKPCD-TA and CA-KMAC, (and, hence, finally making evident possessing the Chip Authentication Key (SKPICC)). The Passive Authentication making evident authenticity of the PKPICC by verifying the Card Security Object (SOC) up to CSCA shall be triggered by the rightful terminal immediately after the successful Terminal Authentication before the Chip Authentica- tion101 and is considered to be part of the CA Protocol (see also P.Terminal). Please note that this SFR does not require authentication of any TOE’s user, but 95 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 96 [assignment: list of authentication events] 97 [selection: met, surpassed] 98 [assignment: list of actions]. 99 [assignment: authentication mechanism] 100 [assignment: authorized user or role] 101 cf. [EACTR], sec. 3.4 Security Target TCOS eID_Card/SLE78CLX1440P 57/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 providing evidence enabling an external entity (the terminal connected) to prove the TOE’s identity. If the Chip Authentication was successfully performed, Secure Messaging is restarted using the derived session keys (CA-KMAC, CA-KEnc), cf. FTP_ITC.1/CA. Otherwise, Se- cure Messaging is continued using the previously established session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE. 224 FIA_UID.1/PACE Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1 The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE Protocol according to [EACTR], sec. 4.2102 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. 225 Application Note 34: The user identified after a successfully performed PACE protocol is a PACE terminal (PCT). In case eID-PIN or eID-PUK were used for PACE, it is the ID_Card holder using PCT. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted-revealable; i.e. in case CAN or MRZ were used for PACE, it is either the ID_Card holder itself or an authorized other person or device. 226 FIA_UID.1/Rightful_Terminal Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1 The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE protocol according to [EACTR, sec. 4.2], 3. carrying out the Terminal Authentication Protocol according to [EACTR], sec. 4.4, Version 2103 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. 102 [assignment: list of TSF-mediated actions] 103 [assignment: list of TSF-mediated actions] Security Target TCOS eID_Card/SLE78CLX1440P 58/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 227 Application Note 35: The user identified after a successfully performed TA protocol is a rightful terminal, i.e. either EIS or ATT or SGT. 228 Application Note 36: In the life phase ‘Manufacturing’ the Manufacturer is the only user role known to the TOE which writes the Initialization Data and/or Pre-personalization Data in the audit records of the IC. Please note that a Personalization Agent acts on behalf of the ID_Card Issuer under his and CSCA and DS policies. Hence, they define authentication procedure(s) for Perso- nalization Agents. The TOE must functionally support these authentication procedures being subject to evaluation within the assurance components ALC_DEL.1 and AGD_PRE.1. The TOE assumes the user role ‘Personalization Agent’, when a terminal (e.g. ATT) proves the respective Terminal Authorization Level. 229 FIA_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/ PACE The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE Protocol104 according to [EACTR, sec. 4.2]105 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/ PACE The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. This item concerns the following application(s): ePassport, eID, eSign. 230 Application Note 37: The user authenticated after a successfully performed PACE proto- col is a PACE terminal (PCT). In case eID-PIN or eID-PUK were used for PACE, it is the ID_Card holder using PCT. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted-revealable; i.e. in case CAN or MRZ were used for PACE, it is either the ID_Card holder itself or an authorized other person or device. If PACE was successfully performed, Secure Messaging is started using the derived session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE. 231 FIA_UAU.1/Rightful_Terminal Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/Right- ful_Terminal. FIA_UAU.1.1/ The TSF shall allow 104 ID_Card identifies themselves within the PACE protocol by selection of the authentication key ephem-PKPICC-PACE 105 [assignment: list of TSF-mediated actions] Security Target TCOS eID_Card/SLE78CLX1440P 59/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Rightful_Terminal 1. establishing a communication channel, 2. carrying out the PACE protocol according to [EACTR], sec. 4.2, 3. carrying out the Terminal Authentication Protocol106 according to [EACTR], sec. 4.4, Version 2 107 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/ Rightful_Terminal 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. 232 Application Note 38: The user authenticated after a successfully performed TA protocol is a Service Provider represented by a rightful terminal, i.e. either EIS 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, H(ephem-PKPCD-TA) from the accomplished TA. Please note that the Passive Authentication is considered to be part of the CA protocol within the PP [IDCARDPP]. 233 FIA_UAU.4 Single-use authentication mechanisms - Single- use authentication of the Terminals by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to 1. PACE Protocol according to[EACTR], sec. 4.2, 2. Terminal Authentication Protocol according to [EACTR], sec. 4.4, Version 2108. This item concerns the following application(s): ePassport, eID, eSign. 234 Application Note 39: For the PACE protocol, the TOE randomly selects a nonce s of 128 bits length length being (almost) uniformly distributed. This is supported by the hardware providing a physical random generator of class P2 ([AIS31]. According to the PP [IDCARDPP] and the TR-03116-2 [ECARDTR] the TOE supports the key derivation function based on AES; see [EACTR], sec. A.3.3 and F.2.1). For the TA protocol, TOE randomly selects a nonce rPICC of 64 bits length, see [EACTR], sec. B.3 and B.11.6. 235 FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1 The TSF shall provide the General Authentication Procedure as the 106 ID_Card identifies themselves within the TA protocol by using the identifier IDPICC = H(ephem- PKPICC-PACE). 107 [assignment: list of TSF-mediated actions] 108 [assignment: identified authentication mechanism(s)] Security Target TCOS eID_Card/SLE78CLX1440P 60/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 sequence 1. PACE Protocol according to [EACTR], sec. 4.2, 2. Terminal Authentication Protocol according to [EACTR], sec. 4.4, Version 2, 3. Chip Authentication Protocol according to [EACTR], sec. 4.3, Version 2, and 4. Secure messaging in encrypt-then-authenticate mode according to [EACTR], Appendix F109 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 key110 being successfully verifiable up to CVCA and (ii) the terminal uses the PICC identifier111 calculated during and the secure messaging established by the current PACE authentication. 2. Having successfully run the Chip Authentication Protocol the TOE accepts only received commands with correct message authentication code sent by means of secure messaging with the key agreed with the terminal by means of the Chip Authentication Protocol112. This item concerns the following application(s): ePassport, eID, eSign. 236 Application Note 40: Please note that Chip Authentication Protocol does not authenticate any TOE’s user, but provides evidence enabling an external entity (the terminal connected) to prove the TOE’s identity. 237 Application Note 41: The commands GET CHALLENGE and MSE:SET will be accepted even if they sent outside the SM channel. But in this case the channel will be closed and therefore all other commands with mandatory access control will not be accepted any- more. 238 FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. 109 [assignment: list of multiple authentication mechanisms] 110 PKPCD 111 IDPICC = H(ephem-PKPICC-PACE) 112 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target TCOS eID_Card/SLE78CLX1440P 61/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authen- tication Protocol shall be verified as being sent by the rightful termi- nal113. This item concerns the following application(s): ePassport, eID, eSign. 239 Application Note 42: The PACE and the Chip Authentication Protocols as specified in [EACTR] start secure messaging used for all commands exchanged after successful PACE authentication and CA. The TOE checks each command by secure messaging in encrypt-then-authenticate mode based on CMAC, whether it was sent by the success- fully authenticated terminal (see FCS_COP.1/CMAC for further details). The TOE does not execute any command with incorrect message authentication code. Therefore the TOE re-authenticates the terminal connected, if a secure messaging error occurred, and accepts only those commands received from the initially authenticated terminal. For the Terminal Authentication, the current secure messaging session is bounded on H(ephem- PKPCD-TA). 240 The PP ([IDCARDPP]) also includes all SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. For the functional class FIA there are the following components: 241 FIA_UAU.1/SSCD Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/SSCD, cf. [SSCDPP] FIA_UAU.1.1/ SSCD The TSF shall allow 1. self test according to FPT_TST.1, 2. identification of the user by means of TSF required by FIA_UID.1/SSCD in [SSCDPP] 3. establishing a trusted channel between CGA and the TOE by means of TSF required by FTP_ITC.1/CA114, 4. establishing a trusted channel between HID and the TOE by means of TSF required by FTP_ITC.1/CA115, 5. none116 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/ SSCD The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 113 [assignment: list of conditions under which re-authentication is required] 114 the authenticated terminal is ATT, cf. FIA_UAU.1/Rightful_Terminal 115 the authenticated terminal is SGT, cf. FIA_UAU.1/Rightful_Terminal; the trusted channel by FTP_ITC.1/CA implements a trusted path between HID and the TOE. 116 [assignment: list of (additional) TSF-mediated actions] Security Target TCOS eID_Card/SLE78CLX1440P 62/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 This item concerns the following application(s): ePassport, eID, eSign. SFR identifier Comments FIA_UID.1/SSCD This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. concerns the following application(s): – eSign FIA_AFL.1/SSCD This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. concerns the following application(s): – eSign 242 FIA_UID.1/SSCD Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/SSCD The TSF shall allow 1. self test according to FPT_TST.1, 2. none 117 on behalf of the user to be performed before the user is identified. FIA_UID.1.2/SSCD The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 243 FIA_AFL.1/SSCD Authentication failure handling Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/SSCD FIA_AFL.1.1/SSCD The TSF shall detect when an administrator configurable positive integer sigad within the range 1 ≤ sigad ≤ 9 according to [TCOSADM]118 unsuccessful authentication attempts occur re- lated to consecutive failed authentication attempts119. FIA_AFL.1.2/SSCD When the defined number of unsuccessful authentication at- tempts has been met120, the TSF shall block RAD121. 117 [assignment: list of additional TSF-mediated actions] 118 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 119 [assignment: list of authentication events] 120 [selection: met, surpassed] 121 [assignment: list of actions] Security Target TCOS eID_Card/SLE78CLX1440P 63/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 6.1.4 Class FDP User Data Protection 244 FDP_ACC.1/TRM Subset access control – Terminal Access Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by FDF_ACF.1/TRM FDP_ACC.1.1/TRM The TSF shall enforce the Terminal Access Control SFP 122 on terminals gaining write, read, modification and usage access to the User Data stored in the ID_Card 123. This item concerns the following application(s): ePassport, eID, eSign. 245 FDP_ACF.1/TRM Security attribute based access control – Terminal Access Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/TRM FMT_MSA.3 Static attribute initialization: not fulfilled, but justified: The access control TSF according to FDP_ACF.1/TRM uses security attributes having been defined during the personali- zation and fixed over the whole life time of the TOE. No man- agement of these security attributes (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary here. FDP_ACF.1.1/TRM The TSF shall enforce the Terminal Access Control SFP124 to objects based on the following: 1. Subjects: a. Terminal, b. PACE Terminal (PCT), c. Rightful Terminal (EIS, ATT, SGT); 2. Objects: User Data stored in the TOE; 3. Security attributes: a. Authentication status of terminals, b. Terminal Authorization Level, c. CA authentication status, d. Authentication status of the ID_Card holder as Signatory (if the eSign is operational) 125. 122 [assignment: access control SFP] 123 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 124 [assignment: access control SFP] 125 [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] Security Target TCOS eID_Card/SLE78CLX1440P 64/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 1. a successfully authenticated Extended Inspection System (EIS) is allowed to read User Data according to [EACTR], sec. C.4.1.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 Data as well as to generate signature key pair(s) within the eSign application (SCD/SVD Generation126) according to [EACTR], sec. C.4.1.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) for generating digital signatures according to [EACTR], sec. C.4.1.3 after a successful CA as required by FIA_API.1/CA and a successful authentication of the ID_Card holder as Signatory as required by FIA_UAU.1/SSCD127. FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none128. FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. Any terminal (including PCT) being not authenticated as a rightful terminal (i.e. as either EIS or ATT or SGT) is not allowed to read, to write, to modify, to use any User Data stored on the ID_Card. 2. Nobody is allowed to read ‘TOE immanent secret cryptographic keys’ stored on the ID_Card. 3. Nobody is allowed to read ‘secret ID_Card holder authentication data’ stored on the ID_Card. 4. Nobody is allowed to read the private Restricted Identification (SKID) key stored on the ID_Card. 5. Nobody is allowed to read the private signature key(s) within within the eSign application (SCD; if the eSign application is operational129. This item concerns the following application(s): ePassport, eID, eSign. 246 Application Note 43: The relative certificate holder (Service Provider) authorization is encoded in the Card Verifiable Certificate of the terminals being operated by the Service Provider. The TOE verifies the certificate chain established by the Country Verifying Certification Authority, the Document Verifier Certificate and the Terminal Certificate (cf. 126 as required by FCS_CKM.1/SSCD 127 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 128 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 129 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS eID_Card/SLE78CLX1440P 65/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FMT_MTD.3). The Terminal Authorization Level is the intersection of the Certificate Holder Authorization in the certificates of the Country Verifying Certification Authority, the Document Verifier Certificate and the Terminal Certificate in a valid certificate chain. It is technically based on Certificate Holder Authorization Template (CHAT), see [EACTR], C.1.5. A CHAT is calculated as an AND-operation from the certificate chain of the terminal and the ID_Card holder’s restricting input at the terminal. This final CHAT reflects the effective authorization level, see [EACTR], C.4.2 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3 und B.11.1 of [EACTR]). 247 Application note 44: Please note that the General Authentication Procedure as required by FIA_UAU.5 is mandatory for all the applications residing on the TOE, see [EACTR], sec. 3.4; cf. also table E.1. Concerning table 1.2 of [EACTR], the IDCARDPP supports only ‘EAC version 2’, whereby EAC shall be mandatory for all user data (DG1 – DG16) of the ePassport. Please note that the Card Security Object (SOC) does not belong to the user data, but to the TSF data. The Card Security Object can be read out by the PCT, see [EACTR], A.1.2 and table A.1 for EF.CardSecurity. 248 Application Note 45: Please note that this functional requirement also covers the ability to activate the eSign application using the ATT with an appropriate Terminal Authoriza- tion Level, see [EACTR], sec. C.4.1.2 and acting on behalf of the CSP and upon an application by the ID_Card holder. 249 Application note 46: Please note that the control on the user data transmitted between the TOE and the rightful terminal is addressed by FTP_ITC.1/CA. 250 FDP_RIP.1 Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the de-allocation of the resource from130 the following objects: 1. the Chip Authentication Private Key (SKPICC), 2. the secret ID_Card holder authentication data eID-PIN, eID- PUK, eSign-PIN (RAD, if eSign application is operational), 3. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc) 4. the private Restricted Identification key SKID, 5. the private signature key of the ID_Card holder (SCD; if the eSign application is operational) 6. none131. This item concerns the following application(s): ePassport, eID, eSign. 251 Application Note 47: The functional family FDP_RIP possesses such a general character, so that is applicable not only to user data (as assumed by the class FDP), but also to TSF-data; in this respect it is similar to the functional family FPT_EMSEC. 130 [selection: allocation of the resource to, de-allocation of the resource from] 131 [assignment: list of objects] Security Target TCOS eID_Card/SLE78CLX1440P 66/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 252 Application Note 48: Please note that FDP_RIP.1 also contributes to achievement of OT.Sigy_SigF (eSign-PIN) and OT.SCD_Secrecy (SCD) from [SSCDPP]. 253 The PP ([IDCARDPP]) also includes all SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. For the functional class FDP there are the following components: SFR identifier Comments FDP_ACC.1/SCD/SVD_Generation_SFP_ SSCD concerns the following application(s): – eSign FDP_ACF.1/SCD/SVD_Generation_SFP_ SSCD concerns the following application(s): – eSign FDP_ACC.1/SVD_Transfer_SFP_SSCD concerns the following application(s): – eSign FDP_ACF.1/SVD_Transfer_SFP_SSCD concerns the following application(s): – eSign FDP_ACC.1/Signature-creation_SFP_SSCD concerns the following application(s): – eSign FDP_ACF.1/Signature-creation_SFP_SSCD concerns the following application(s): – eSign FDP_RIP.1/SSCD This item is covered by FDP_RIP.1 concerns the following application(s): – eSign FDP_SDI.2/Persistent_SSCD concerns the following application(s): – eSign FDP_SDI.2/DTBS_SSCD concerns the following application(s): – eSign 254 The following security attributes and related status for the subjects and objects defined in the SSCD PP [SSCDPP] are applicable, if the eSign application is operational: Subject / Object Security attribute type Values of the attribute S.User Role R.Admin, R.Sigy S.User SCD / SVD Management authorized, not authorized SCD SCD Operational no, yes SCD SCD Identifier arbitrary value 255 Application Note 49: The SCD Identifier allows the environment to identify the SCD and to link it with the appropriate SVD. This link is established during SCD/SVD Generation initiated by R.Admin and can not be changed later. The default value of the security attri- bute SCD Identifier is “NULL” (not assigned/not linked), i.e. the management function mentioned in no. 4 of FMT_SMF.1.1 is in fact an assignment and not really a change. 256 FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD. Security Target TCOS eID_Card/SLE78CLX1440P 67/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FDP_ACC.1.1/SCD/ SVD_Generation_ SFP_SSCD The TSF shall enforce the SCD/SVD Generation SFP132 on 1. subjects: S.User 2. objects: SCD, SVD 3. operations: generation of SCD/SVD pair133. 257 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD, FMT_MSA.3 Static attribute initialization: control: fulfilled by FMT_MSA.3/SSCD FDP_ACF.1.1/SCD/ SVD_Generation_ SFP_ SSCD The TSF shall enforce the SCD/SVD_Generation_SFP134 to objects based on the following: the user S.User is associated with the security attribute “SCD/SVD Management“135. FDP_ACF.1.2/SCD/ SVD_Generation_ SFP_ SSCD The TSF shall enforce the following rules to determine if an op- eration among controlled subjects and controlled objects is al- lowed: S.User with the security attribute “SCD/SVD Management” set to “authorized” is allowed to generate SCD/SVD pair136. FDP_ACF.1.3/SCD/ SVD_Generation_ SFP_ SSCD The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none137. FDP_ACF.1.4/SCD/ SVD_Generation_ SFP_ SSCD The TSF shall explicitly deny access of subjects to objects The TSF shall explicitly deny access of subjects to objects based on the following additional rules: S.User with the security attribute “SCD/SVD management” set to “not authorized” is not allowed to generate SCD/SVD pair138. 258 FDP_ACC.1/SVD_Transfer_SFP_SSCD Subset access control Hierarchical to: No other components. 132 [assignment: access control SFP] 133 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 134 [assignment: access control SFP] 135 [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] 136 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 137 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 138 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS eID_Card/SLE78CLX1440P 68/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by FDP_ACF.1/SVD_Transfer_SFP_SSCD FDP_ACC.1.1/SVD _Transfer_SFP_ SSCD The TSF shall enforce the SVD_Transfer_SFP139 on 1. subjects: S.User, 2. objects: SVD, 3. operations: export140. 259 FDP_ACF.1/SVD_Transfer_SFP_SSCD Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACF.1/SVD_ Transfer_SFP_SSCD, FMT_MSA.3 Static attribute initialization: fulfilled by FMT_MSA.3/SSCD FDP_ACF.1.1/ SVD_Transfer_SFP The TSF shall enforce the SVD_Transfer_SFP141 to objects based on the following: 1. the S.User is associated with the security attribute Role, 2. the SVD142. FDP_ACF.1.2/ SVD_Transfer_ SFP The TSF shall enforce the following rules to determine if an op- eration among controlled subjects and controlled objects is al- lowed: R.Admin 143 is allowed to export SVD144. FDP_ACF.1.3/ SVD_Transfer_ SFP The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none145. FDP_ACF.1.4/ SVD_Transfer_ SFP The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none146. 260 FDP_ACC.1/Signature_Creation_SFP_SSCDSubset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by FDP_ACC.1/Signature_Creation_SFP_SSCD 139 [assignment: access control SFP] 140 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 141 [assignment: access control SFP] 142 [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] 143 [selection: R.Admin, R.Sigy ] 144 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 145 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 146 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS eID_Card/SLE78CLX1440P 69/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FDP_ACC.1.1/ Signature-creation_ SFP_SSCD The TSF shall enforce the Signature-creation_SFP147 on 1. subjects: S.User, 2. objects: DTBS/R, SCD, 3. operations: signature-creation148. 261 FDP_ACF.1/ Signature_Creation_SFP_SSCD Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/Signature_Creation_SFP_SSCD, FMT_MSA.3 Static attribute initialization: fulfilled by FMT_MSA.3/SSCD FDP_ACF.1.1/ Signature-creation_ SFP_SSCD The TSF shall enforce the Signature-creation_SFP149 to objects based on the following: 1. the user S.User is associated with the security attribute “Role” and 2. the SCD with the security attribute “SCD Operational”150. FDP_ACF.1.2/ Sig- nature-creation_ SFP_SSCD The TSF shall enforce the following rules to determine if an op- eration among controlled subjects and controlled objects is al- lowed: R.Sigy is allowed to create digital signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “yes 151. FDP_ACF.1.3/ Sig- nature-creation_ SFP_SSCD The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none152. FDP_ACF.1.4/ Sig- nature-creation_ SFP_SSCD The TSF shall explicitly deny access of subjects to objects based on the following additional rules: S.User is not allowed to create digital signatures for DTBS/R with SCD which security attribute “SCD operational” is set to “no”153. 262 FDP_SDI.2/Persistent_SSCD Stored data integrity monitoring and action 147 [assignment: access control SFP] 148 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 149 [assignment: access control SFP] 150 [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] 151 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 152 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 153 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS eID_Card/SLE78CLX1440P 70/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Hierarchical to: FDP_SDI.1 Stored data integrity monitoring Dependencies: No dependencies FDP_SDI.2.1/ Per- sistent_SSCD The TSF shall monitor user data stored in containers controlled by the TSF for integrity error154 on all objects, based on the fol- lowing attributes: integrity checked stored data155. FDP_SDI.2.2/ Per- sistent_SSCD Upon detection of a data integrity error, the TSF shall 1. prohibit the use of the altered data 2. inform the S.Sigy about integrity error156. 263 FDP_SDI.2/DTBS_SSCD Stored data integrity monitoring and ction Hierarchical to: FDP_SDI.1 Stored data integrity monitoring Dependencies: No dependencies FDP_SDI.2.1/ DTBS_SSCD The TSF shall monitor user data stored in containers controlled by the TSF for integrity error157 on all objects, based on the fol- lowing attributes: integrity checked stored DTBS158. FDP_SDI.2.2/ DTBS_SSCD Upon detection of a data integrity error, the TSF shall 1. prohibit the use of the altered data 2. inform the S.Sigy about integrity error159. 6.1.5 Class FTP Trusted Path/Channels 264 FTP_ITC.1/PACE Inter-TSF trusted channel after PACE 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 PCT160 to initiate communication via the trusted channel. 154 [assignment: integrity errors] 155 [assignment: user data attributes] 156 [assignment: action to be taken] 157 [assignment: integrity errors] 158 [assignment: user data attributes] 159 [assignment: action to be taken] 160 [selection: the TSF, another trusted IT product] Security Target TCOS eID_Card/SLE78CLX1440P 71/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 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 PACE161. This item concerns the following application(s): ePassport, eID, eSign. 265 Application note 50: 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 PACE secure messaging session is immediately superseded by a CA secure messaging session after successful Chip Authentication as required by FTP_ITC.1/CA. 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. 266 FTP_ITC.1/CA Inter-TSF trusted channel Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted IT product rightful terminal (EIS, ATT, SGT) after Chip Authentication 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/CA The TSF shall permit another trusted IT product the rightful terminal (EIS, ATT, SGT)162 to initiate communication via the trusted channel. FTP_ITC.1.3/CA The TSF shall initiate enforce communication via the trusted channel for any data exchange between the TOE and the Service Provider represented by the rightful terminal after Chip Authentication163. This item concerns the following application(s): ePassport, eID, eSign. 267 Application Note 51: The trusted channel is established after successful performing the PACE protocol (FIA_UAU.1/PACE), the TA protocol (FIA_UAU.1/Rightful_Terminal) and the CA protocol (FIA_API.1/CA). If the Chip Authentication was successfully performed, Secure Messaging is restarted immediately using the derived session keys {CA-KMAC, 161 [assignment: list of functions for which a trusted channel is required] 162 [selection: the TSF, another trusted IT product] 163 [assignment: list of functions for which a trusted channel is required] Security Target TCOS eID_Card/SLE78CLX1440P 72/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 CA-KEnc}164: this secure messaging enforces the required properties of the operational trusted channel; the cryptographic primitives being used for the secure messaging are as required by FCS_COP.1/AES and FCS_COP.1/CMAC. 268 Application Note 52: Please note that the communication channel being established between the ID_Card and the PACE Terminal also uses secure messaging (with {PACE- KMAC, PACE-KEnc}) being itself enough strong for the current security policy. Neverthe- less, the PP ([IDCARDPP]) does not cover the PACE trusted channel due to the circum- stance that short, non-blocking authorization data CAN and MRZ can be used for star- ting (and also hijacking) a PACE-session, so that the establishing phase of the PACE trusted channel is not sufficiently strong for the current security policy (please refer to T.Skimming). The PACE secure messaging session is immediately superseded by the CA secure messaging session after successful Chip Authentication as required by FTP_ITC.1/CA. 269 Application Note 53: Please note that the control on user data stored in the TOE is addressed by FDP_ACF.1/TRM. 270 Application note 54: The requirement FTP_ITC.1/CA also covers a secure transport of (i) SVD165 from the TOE to CGA166 as well as of (ii) VAD167 from HID168 and of (iii) DTBS169 from SCA 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 feature concerning the eSign application comparing to [SSCDPP]. 6.1.6 Class FAU Security Audit 271 FAU_SAS.1 Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide the Manufacturer170 with the capability to store the Initialization and Pre-Personalization Data 171 in the audit records. This item concerns the following application(s): ePassport, eID, eSign. 272 Application Note 55: The Manufacturer role is the default user identity assumed by the TOE in the life phase ‘manufacturing’. The IC manufacturer and the ID_Card manufac- 164 otherwise, Secure Messaging is continued using the previously established session keys (PACE- KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE 165 integrity is to secure 166 the authenticated terminal is ATT with bits 7 (install qualified certificate) or/and 6 (install certificate) set to 1, cf. [EACTR], sec. C.4.1.2. 167 confidentiality is to secure 168 the authenticated terminal is SGT 169 integrity is to secure 170 [assignment: authorized users] 171 [assignment: list of audit information] Security Target TCOS eID_Card/SLE78CLX1440P 73/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 turer in the Manufacturer role write the Initialization and/or Pre-personalization Data as TSF-data into the TOE. The audit records are usually write-only-once data of the ID_Card (see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also be such audit records which cannot be read out, but directly used by the TOE. 6.1.7 Class FMT Security Management 273 Application Note 56: The SFR FMT_SMF.1 and FMT_SMR.1 provide basic requirements to the management of the TSF data. 274 FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 1. Initialization, 2. Personalization, 3. Configuration, 4. Resume and unblock the eID-PIN172, 5. Activate and deactivate the eID-PIN173. This item concerns the following application(s): ePassport, eID, eSign. 275 FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/PACE, FIA_UID.1/Rightful_Terminal. 172 unblocking eSign-PIN is managed by FMT_SMF.1/SSCD 173 [assignment: list of management functions to be provided by the TSF] Security Target TCOS eID_Card/SLE78CLX1440P 74/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FMT_SMR.1.1 The TSF shall maintain the roles 1. Manufacturer, 2. Personalization Agent, 3. Country Verifying Certification Authority, 4. Document Verifier, 5. Terminal, 6. PACE Terminal (PCT), 7. (Extended) Inspection System (EIS), 8. Authentication Terminal (ATT), 9. Signature Terminal (SGT), 10. ID_Card holder174 . FMT_SMR.1.2 The TSF shall be able to associate users with roles. This item concerns the following application(s): ePassport, eID, eSign. 276 Application Note 57: For the explanation on the role Manufacturer please refer to the Application Note 55; on the role Personalization Agent – to the Application Note 36. The role Terminal is the default role for any terminal being recognized by the TOE as neither PCT nor EIS nor ATT nor SGT (‘Terminal’ is used by the ID_Card presenter). The). The roles CVCA, DV, EIS, ATT175 and SGT are recognized by analyzing the current Terminal Certificate CT, cf. [EACTR, C.4] (FIA_UID.1/ Rightful_Terminal). The TOE recognizes the ID_Card holder by using PCT upon input eID-PIN or eID-PUK (FIA_UID.1/PACE) as well as – in the context of the eSign application – by using SGT upon input VAD (eSign-PIN) governed by FIA_UAU.1/SSCD . 277 Application Note 58: The SFR FMT_LIM.1 and FMT_LIM.2 address the management of the TSF and TSF data to prevent misuse of test features of the TOE over the life cycle phases. 278 FMT_LIM.1 Limited capabilities Hierarchical to: No other components. Dependencies: 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 in conjunction with ‘Limited availability (FMT_LIM.2)’ 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 174 [assignment: the authorized identified roles] 175 ATT plays a special role ‘CGA’ for the eSign application, if bits 7 (install qualified certificate) or/and 6 (install certificate) are set to 1 within the effective terminal authorisation level, cf. .[EACTR], sec. C.4.1.2; an ATT with such an terminal authorisation level is authorized by the related CSP to act as CGA on its behalf. Security Target TCOS eID_Card/SLE78CLX1440P 75/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 4. substantial information about construction of TSF to be gathered which may enable other attacks176. This item concerns the following application(s): ePassport, eID, eSign. 279 FMT_LIM.2 Limited availability 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 attacks177. This item concerns the following application(s): ePassport, eID, eSign. 280 FMT_MTD.1/INI_ENA Management of TSF data – Writing Initialization and Pre-personalization Data Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/ INI_ENA The TSF shall restrict the ability to write178 the Initialization Data and Pre-personalization Data179 to the Manufacturer180. This item concerns the following application(s): ePassport, eID, eSign. 281 FMT_MTD.1/INI_DIS Management of TSF data – Reading and Using Initialization and Pre-personalization Data Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 176 [assignment: Limited capability and availability policy] 177 [assignment: Limited capability and availability policy] 178 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 179 [assignment: list of TSF data] 180 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 76/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FMT_MTD.1.1/ INI_DIS The TSF shall restrict the ability to read out and to use181 the Initialization Data182 to the Personalization Agent183. This item concerns the following application(s): ePassport, eID, eSign. 282 Application Note 59: The TOE may restrict the ability to write the Initialization Data and the Pre-personalization Data by (i) allowing writing these data only once and (ii) blocking the role Manufacturer at the end of the manufacturing phase. The Manufacturer may write the Initialization Data (as required by FAU_SAS.1) including, but being not limited to a unique identification of the IC being used to trace the IC in the life phases ‘manufacturing’ and ‘issuing’, but being not needed and may be misused in the ‘operational use’. Therefore, the read and use access shall be blocked in the ‘operational use’ by the Personalization Agent, when he switches the TOE from the life phase ‘issuing’ to the life phase ‘operational use’. Please also refer to the Application Note 36. 283 FMT_MTD.1/CVCA_INI Management of TSF data – Initialization of CVCA Certificate and Current Date Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1, FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1. FMT_MTD.1.1/ CVCA_INI The TSF shall restrict the ability to write184 the 1. initial Country Verifying Certification Authority Public Key (PKCVCA), 2. metadata of the initial Country Verifying Certification Authority Certificate (CCVCA), as required in [EACTR, sec. A.6.2.3] 3. initial Current Date 4. none185 to the Personalization Agent186. This item concerns the following application(s): ePassport, eID, eSign. 284 Application Note 60: The initial Country Verifying Certification Authority Public Key is written by the Personalization Agent in the issuing phase (cf. [EACTR], sec. 2.2.4). The initial Country Verifying Certification Authority Public Keys (and their updates later on) are used to verify the Country Verifying Certification Authority Link-Certificates. The 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 the Terminal Authorization Level. Please note that only a subset of the metadata must be 181 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 182 [assignment: list of TSF data] 183 [assignment: the authorized identified roles] 184 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 185 [assignment: list of TSF data] 186 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 77/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 stored in the TOE, see [EACTR, sec. A.6.2.3]; storing of further certificate’s content is optional. In fact it is not the initial CVCA Certificate, which is necessary for verification, but the public key included therein, and the self-signature gives no additional security. Therefore the TOE will expect the initial CVCA Certificate to be written by the Personali- zation Agent without the self-signature (cf. [TCOSADM]). 285 FMT_MTD.1/CVCA_UPD Management of TSF data – Country Verifying Certification Authority Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/ CVCA_UPD The TSF shall restrict the ability to update187 the 1. Country Verifying Certification Authority Public Key (PKCVCA), 2. metadata of the Country Verifying Certification Authority Certificate (CCVCA) as required in [EACTR, sec. A.6.2.3] 3. none188 to Country Verifying Certification Authority189. This item concerns the following application(s): ePassport, eID, eSign. 286 Application Note 61: The Country Verifying Certification Authority updates its asymmetric key pair and distributes the public key and the related metadata by means of the CVCA Link-Certificates (cf. [EACTR], 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. [EACTR], sec. 2.2.3 and 2.2.4). 287 FMT_MTD.1/DATE Management of TSF data – Current date Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/ DATE The TSF shall restrict the ability to modify190 the Current Date191 to 1. Country Verifying Certification Authority, 2. Document Verifier, 3. Rightful Terminal (EIS, ATT or SGT) possessing an Accurate Terminal Certificate192. 187 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 188 [assignment: list of TSF data] 189 [assignment: the authorized identified roles] 190 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 191 [assignment: list of TSF data] 192 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 78/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 This item concerns the following application(s): ePassport, eID, eSign. 288 Application Note 62: The authorized roles are identified in their certificates (cf. [EACTR], sec. 2.2.4 and C.4) and authorized by validation of the certificate chain up to CVCA (cf. FMT_MTD.3). The authorized role of the terminal is part of the Certificate Holder Authorization in the card verifiable certificate provided by the terminal for the identification and the Terminal Authentication (cf. [EACTR], A.6 for details). 289 FMT_MTD.1/PA_UPD Management of TSF data – Personalization Agent Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/ PA_UPD The TSF shall restrict the ability to write193 the Card Security Object (SOC)194 to the Personalization Agent195. This item concerns the following application(s): ePassport, eID, eSign. 290 Application Note 63: Please refer to the Application Note 36. 291 FMT_MTD.1/SK_PICC Management of TSF data – Chip Authentication Private Key Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/ SK_PICC The TSF shall restrict the ability to load or create196 the Chip Authentication Private Key (SKPICC)197 to Personalization Agent 198. This item concerns the following application(s): ePassport, eID, eSign. 292 Application Note 64: The component FMT_MTD.1/SK_PICC is refined by (i) selecting other operations and (ii) defining a selection for the operations “create” and “load”. The verb “load” means here that the Chip Authentication Private Key is generated securely outside the TOE and written into the TOE memory. This is the default operation. The verb “create” means here that the Chip Authentication Private Key is generated by the TOE itself during Personalization. This operation is no more available after Personali- zation. 193 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 194 [assignment: list of TSF data] 195 [assignment: the authorized identified roles] 196 [selection: create, load]/[selection: change_default, query, modify, delete, clear, [assignment: other operations]] 197 [assignment: list of TSF data] 198 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 79/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 293 FMT_MTD.1/KEY_READ Management of TSF data – Private Key Read Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/ KEY_READ The TSF shall restrict the ability to read199 the Chip Authentication Private Key (SKPICC)200 to none201. This item concerns the following application(s): ePassport, eID, eSign. 294 FMT_MTD.1/eID-PIN_Resume Management of TSF data – Resuming eID- PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/ eID-PIN_Resume The TSF shall restrict the ability to resume202 the suspended eID- PIN203 to the ID_Card holder204. This item concerns the following application(s): eID. 295 Application Note 65: The resuming procedure is a two-step one subsequently using PACE with CAN and PACE with eID-PIN. It must be implemented according to [EACTR], sec. 3.5.1 and is relevant for the status as required by FIA_AFL.1/eID-PIN_Suspending. The ID_Card holder is authenticated as required by FIA_UAU.1/PACE using the eID-PIN as the shared password. 296 FMT_MTD.1/eID-PIN_Unblock Management of TSF data – Unblocking eID-PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/ eID-PIN_Unblock The TSF shall restrict the ability to unblock and change205 the blocked eID-PIN206 to 1. the ID_Card holder, 2. the Authentication Terminal (ATT) with the Terminal Authorization Level for eID-PIN management207. 199 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 200 [assignment: list of TSF data] 201 [assignment: the authorized identified roles] 202 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 203 [assignment: list of TSF data] 204 [assignment: the authorized identified roles] 205 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] Security Target TCOS eID_Card/SLE78CLX1440P 80/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 This item concerns the following application(s): eID. 297 Application Note 66: The unblocking procedure must be implemented according to [EACTR], sec. 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 ID_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) proved the Terminal Authorization Level being sufficient for eID-PIN management (FDP_ACF.1/TRM). 298 FMT_MTD.1/eID-PIN_Activate Management of TSF data – Activating/Deactivating eID-PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/ eID-PIN_Activate The TSF shall restrict the ability to activate and deactivate208 the eID-PIN209 to the Authentication Terminal (ATT) with the Terminal Authorization Level for eID-PIN management210. This item concerns the following application(s): eID, eSign. 299 Application Note 67: The activating/deactivating procedures must be implemented according to [EACTR, sec. 3.5.2]. It can be triggered by the ATT (FIA_UAU.1/Rightful_Terminal) that proved a Terminal Authorization Level being sufficient for eID-PIN management (FDP_ACF.1/TRM). 300 FMT_MTD.3 Secure TSF data Hierarchical to: No other components. Dependencies: FMT_MTD.1 Management of TSF data: fulfilled by FMT_MTD.1/ CVCA_INI, FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE FMT_MTD.3.1 The TSF shall ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol and the Terminal Access Control SFP211. Refinement: The certificate chain is valid if and only if (1) the digital signature of the Terminal Certificate (CT) has 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, 206 [assignment: list of TSF data] 207 [assignment: the authorized identified roles] 208 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 209 [assignment: list of TSF data] 210 [assignment: the authorized identified roles] 211 [assignment: list of TSF data] Security Target TCOS eID_Card/SLE78CLX1440P 81/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 (2) the digital signature of the Document Verifier Certificate (CDV) has been verified as correct using the public key in the Certificate of the Country Verifying Certification Authority (CCVCA) and the expiration date of the CDV is not before the Current Date of the TOE, (3) the digital signature of the Certificate of the Country Verifying Certification Authority (CCVCA) has been verified as correct using the public key of the Country Verifying Certification Authority known to the TOE and the expiration date of the CCVCA is not before the Current Date of the TOE. The static terminal public key (PKPCD) contained in the CT in a valid certificate chain is a secure value for the authentication reference data of a rightful terminal. The intersection of the Certificate Holder Authorizations contained in the cer- tificates of a valid certificate chain is a secure value for Terminal Authorization Level212 of a successful authenticated Service Provider (represented by a rightful terminal). This item concerns the following application(s): ePassport, eID, eSign. 301 Application Note 68: The Terminal Authentication is used as required by FIA_UAU.1/ Rightful_Terminal and FIA_UAU.5. The Terminal Authorization Level derived from the CCVCA, CDV and CT is used as TSF data for access control required by FDP_ACF.1/TRM. 302 The PP ([IDCARDPP]) also includes all SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. For the functional class FMT there are the following components: SFR identifier Comments FMT_SMR.1/SSCD concerns the following application(s): – eSign FMT_SMF.1/SSCD concerns the following application(s): – eSign FMT_MOF.1/SSCD concerns the following application(s): – eSign FMT_MSA.1/Admin_SSCD concerns the following application(s): – eSign FMT_MSA.1/Signatory_SSCD concerns the following application(s): – eSign FMT_MSA.2/SSCD concerns the following application(s): – eSign FMT_MSA.3/SSCD concerns the following application(s): – eSign FMT_MSA.4/SSCD concerns the following application(s): – eSign FMT_MTD.1/Admin_SSCD concerns the following application(s): 212 This certificate-calculated Terminal Authorisation Level can additionally be restricted by ID_Card holder at the terminal, s. [EACTR], sec. C.4.2. It is based on Certificate Holder Authorization Tem- plate (CHAT), see [EACTR], C.1.5. A CHAT is calculated as an AND-operation from the certificate chain of the terminal and the ID_Card holder’s restricting input at the terminal. This final CHAT re- flects the effective authorisation level, see [EACTR], C.4.2 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3 und B.11.1 of [EACTR]). Security Target TCOS eID_Card/SLE78CLX1440P 82/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 SFR identifier Comments – eSign FMT_MTD.1/Signatory_SSCD concerns the following application(s): – eSign eSign-PIN can be unblocked using the card-global eID- PUK. Although the PP allows using an additional eSign-specific eSign-PUK this is not implemented in the TOE. 303 FMT_SMR.1/SSCD Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/SSCD. FMT_SMR.1.1/ SSCD The TSF shall maintain the roles R.Admin and R.Sigy213 . FMT_SMR.1.2/ SSCD The TSF shall be able to associate users with roles. 304 FMT_SMF.1/SSCD Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies FMT_SMF.1.1/ SSCD The TSF shall be capable of performing the following management functions: 1. Creation and modification of RAD, 2. Enabling the signature-creation function, 3. Modification of the security attribute SCD/SVD management, SCD operational, 4. Change the default value of the security attribute SCD Iden- tifier, 5. none214 . 305 FMT_MOF.1/SSCD Management of security functions behaviour Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCD. FMT_MOF.1.1/ The TSF shall restrict the ability to enable215 the functions signa- 213 [assignment: the authorized identified roles] 214 [assignment: list of management functions to be provided by the TSF]/[assignment: list of other security management functions to be provided by the TSF] Security Target TCOS eID_Card/SLE78CLX1440P 83/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 SSCD ture-creation function216 to R.Sigy217. 306 FMT_MSA.1/Admin_SSCD Management of security attributes Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by FDP_ACC.1/ SCD/SVD_Generation_SFP_SSCD, FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD, FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCD FMT_MSA.1.1/ Admin_SSCD The TSF shall enforce the SCD/SVD_Generation_SFP218 to restrict the ability to modify219 the security attributes SCD/SVD manage- ment220 to R.Admin221. 307 FMT_MSA.1/Signatory_SSCD Management of security attributes Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by FDP_ACC.1/ Signature_Creation_SFP_SSCD FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCD FMT_MSA.1.1/ Signatory_SSCD The TSF shall enforce the Signature-creation_SFP222 to restrict the ability to modify223 the security attributes SCD operational224 to R.Sigy225. 308 FMT_MSA.2/SSCD Secure security attributes Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by 215 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 216 [assignment: list of functions] 217 [assignment: the authorized identified roles] 218 [assignment: access control SFP(s), information flow control SFP(s)] 219 [selection: change_default, query, modify, delete, [assignment: other operations]] 220 [assignment: list of security attributes] 221 [assignment: the authorized identified roles] 222 [assignment: access control SFP(s), information flow control SFP(s)] 223 [selection: change_default, query, modify, delete, [assignment: other operations]] 224 [assignment: list of security attributes] 225 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 84/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD, FDP_ACC.1/Signature_Creation_SFP_SSCD FMT_MSA.1 Management of security attributes: fulfilled by FMT_MSA.1/Admin_SSCD, FMT_MSA.1/Signatory_SSCD FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD FMT_MSA.2.1/ SSCD The TSF shall ensure that only secure values are accepted for SCD/SVD Management and SCD operational226. 309 Application Note 69: The security attribute for SCD/SVD Management ist set to “yes” for the user S.Admin and to “no” for the user S.Sigy. On the other hand the security attribute for setting the SCD operational is set to “no” for the user S.Admin and to “yes” for the user S.Sigy. 310 FMT_MSA.3/SSCD Static attribute initialization Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes: fulfilled by FMT_MSA.1/Admin_SSCD, FMT_MSA.1/Signatory_SSCD. FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD FMT_MSA.3.1/ SSCD The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_ Transfer_SFP and Signature-creation_SFP227 to provide restricti- ve228 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/ SSCD The TSF shall allow the R.Admin229 to specify alternative initial values to override the default values when an object or informa- tion is created. 311 FMT_MSA.4/SSCD Security attribute value inheritance Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD, FDP_ACC.1/Signature_Creation_SFP_SSCD FMT_MSA.4.1/ SSCD The TSF shall use the following rules to set the value of security attributes: 1. If S.Admin successfully generates an SCD/SVD pair without 226 [selection: list of security attributes] 227 [assignment: access control SFP, information flow control SFP] 228 [selection choose one of: restrictive, permissive, [assignment: other property]] 229 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 85/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 S.Sigy being authenticated the security attribute “SCD opera- tional of the SCD” shall be set to “no” as a single operation. 2. If S.Sigy successfully generates an SCD/SVD pair the security attribute “SCD operational of the SCD” shall be set to “yes” as a single operation230. 312 Application Note 70: Because the TOE does not support SCD/SVD generation by the Signatory alone, the rule (2) is not relevant here. 313 FMT_MTD.1/Admin_SSCD Management of TSF data Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCD FMT_MTD.1.1/ Admin_SSCD The TSF shall restrict the ability to create231 the RAD232 to R.Admin233. 314 FMT_MTD.1/Signatory_SSCD Management of TSF data Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/SSCD FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCD FMT_MTD.1.1/ Signatory_SSCD The TSF shall restrict the ability to modify234 the RAD235 to R.Sigy236. 6.1.8 Class FPT Protection of the Security Functions 315 The TOE shall prevent inherent and forced illicit information leakage for User Data and TSF-data. The security functional requirement FPT_EMSEC.1 addresses the inherent leakage. With respect to the forced leakage they have to be considered in combination with the security functional requirements “Failure with preservation of secure state (FPT_FLS.1)” and “TSF testing (FPT_TST.1)” on the one hand and “Resistance to physi- cal attack (FPT_PHP.3)” on the other. The SFRs “Limited capabilities (FMT_LIM.1)”, 230 [assignment: rules for setting the values of security attributes] 231 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 232 [assignment: list of TSF data] 233 [assignment: the authorized identified roles] 234 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 235 [assignment: list of TSF data] 236 [assignment: the authorized identified roles] Security Target TCOS eID_Card/SLE78CLX1440P 86/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 “Limited availability (FMT_LIM.2)” and “Resistance to physical attack (FPT_PHP.3)” to- gether with the SAR “Security architecture description” (ADV_ARC.1) prevent bypassing, deactivation and manipulation of the security features or misuse of TOE functions. 316 FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMSEC.1.1 The TOE shall not emit power variations, timing variations during command execution 237 in excess of non-useful information 238 enabling access to 1. the Chip Authentication Private Key (SKPICC), 2. the eID-PIN, eID-PUK, eSign-PIN (RAD; if the eSign is operational)239 3. none240 and 4. the private Restricted Identification key SKID, 5. the private signature key of the ID_Card holder (SCD; if the eSign is operational)241. 6. none242 FPT_EMSEC.1.2 The TSF shall ensure any users243 are unable to use the following interface ID_Card’s contactless interface and circuit contacts244 to gain access to 1. the Chip Authentication Private Key (SKPICC), 2. the eID-PIN, eID-PUK, eSign-PIN (RAD; if the eSign is operational)245 3. none246 and 4. the private Restricted Identification key SKID, 5. the private signature key of the ID_Card holder (SCD; if the eSign is operational)247. 6. none248. 237 [assignment: types of emissions] 238 [assignment: specified limits] 239 [assignment: list of types of TSF data] 240 [assignment: list of types of (further) TSF data] 241 [assignment: list of types of user data] 242 [assignment: list of types of (further) user data] 243 [assignment: type of users] 244 [assignment: type of connection] 245 [assignment: list of types of TSF data] 246 [assignment: list of types of (further) TSF data] 247 [assignment: list of types of user data] 248 [assignment: list of types of (further) user data] Security Target TCOS eID_Card/SLE78CLX1440P 87/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 This item concerns the following application(s): ePassport, eID, eSign. 317 Application Note 71: The TOE prevents 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 ope- ration 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 influen- ced by the technology employed to implement the smart card. The ID_Card’s chip has to provide a smart card contactless interface, but may have also (not used by the terminal, but maybe by an attacker) sensitive contacts according to ISO/IEC 7816-2 as well. 318 FPT_FLS.1 Failure with preservation of secure state Hierarchical to: No other components. Dependencies: No dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: 1. Exposure to operating conditions causing a TOE malfunction, 2. Failure detected by TSF according to FPT_TST.1 3. none 249. This item concerns the following application(s): ePassport, eID, eSign. 319 FPT_TST.1 TSF testing Hierarchical to: No other components. Dependencies: No dependencies FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up, periodically during normal operation250 to demonstrate the correct operation of the TSF251. FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of TSF data252. FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of stored TSF executable code253. This item concerns the following application(s): ePassport, eID, eSign. 320 Application Note 72: The ID_Card’s chip uses state of the art smart card technology, therefore it will run the some self tests at the request of an authorized user and some self tests automatically (cf. [HWST]). E.g. a self test for the verification of the integrity of 249 [assignment: list of types of failures in the TSF] 250 [selection: during initial start-up, periodically during normal operation, at the request of the autho- rized user, at the conditions [assignment: conditions under which self test should occur]] 251 [selection: [assignment: parts of TSF], the TSF] 252 [selection: [assignment: parts of TSF], TSF data] 253 [selection: [assignment: parts of TSF], TSF] Security Target TCOS eID_Card/SLE78CLX1440P 88/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 stored TSF executable code required by FPT_TST.1.3 is executed during initial start-up by the user Manufacturer in the life phase ‘Manufacturing’. Other self tests automatically run to detect failures and to preserve the secure state according to FPT_FLS.1 in the phase ‘operational use’, e.g. to check a calculation of a integrity check value as soon as data is accessed. 321 FPT_PHP.3 Resistance to physical attack Hierarchical to: No other components. Dependencies: No dependencies FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing254 to the TSF255 by responding automatically such that the SFRs are always enforced. This item concerns the following application(s): ePassport, eID, eSign. 322 Application Note 73: The TO E will implement appropriate measures to continuously counter 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) assuming that there might be an attack at any time and (ii) countermeasures are provided at any time. 323 The PP ([IDCARDPP]) also includes all SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. For the functional class FPT there are the following components: SFR identifier Comments FPT_EMSEC.1/SSCD This SFR is covered by FPT_EMSEC.1 above. concerns the following application(s): – eSign FPT_FLS.1/SSCD This SFR is covered by FPT_FLS.1 above. concerns the following application(s): – eSign FPT_PHP.1/SSCD concerns the following application(s): – eSign FPT_PHP.3/SSCD This SFR is commensurate with FPT_PHP.3 above. concerns the following application(s): – eSign FPT_TST.1/SSCD This SFR is equivalent FPT_TST.1 above. concerns the following application(s): – eSign 324 FPT_PHP.1/SSCD Passive detection of physical attack Hierarchical to: No other components. 254 [assignment: physical tampering scenarios] 255 [assignment: list of TSF devices/elements] Security Target TCOS eID_Card/SLE78CLX1440P 89/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Dependencies: No dependencies. FPT_PHP.1.1/ SSCD The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. FPT_PHP.1.2/ SSCD The TSF shall provide the capability to determine whether physical tampering with the TSF’s devices or TSF’s elements has occurred. 6.2 Security Assurance Requirements for the TOE 325 The assurance requirements for the evaluation of the TOE, its development and operating environment are to choose as the predefined assurance package EAL4 augmented by the following components: ▪ ALC_DVS.2 (Sufficiency of security measures), ▪ ATE_DPT.2 (Testing: security enforcing modules) and ▪ AVA_VAN.5 (Advanced methodical vulnerability analysis). 6.3 Security Requirements Rationale 6.3.1 Security Functional Requirements Rationale 326 The following table provides an overview for security functional requirements coverage. OT.Identification OT.Personalization OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.ID_Card_Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.SCD/SVD_Gen OT.Sigy_SigF FCS_CKM.1/DH_PACE x x x FCS_CKM.1/DH_CA x x x x FCS_CKM.1/CA_PICC x x x x FCS_CKM.2/DH x 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 FCS_RND.1 x x x x FIA_AFL.1/eID-PIN_Suspending x x x x FIA_AFL.1/eID-PIN_Blocking x x x x x FIA_AFL.1/PACE x Security Target TCOS eID_Card/SLE78CLX1440P 90/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 OT.Identification OT.Personalization OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.ID_Card_Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.SCD/SVD_Gen OT.Sigy_SigF FIA_API.1/CA x x x x FIA_UID.1/PACE x x x FIA_UID.1/Rightful_Terminal x x x x FIA_UAU.1/PACE x x x FIA_UAU.1/Rightful_Terminal x x x x FIA_UAU.1/SSCD x x 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_INI x x x FMT_MTD.1/CVCA_UPD 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_READ x x x x FMT_MTD.1/eID-PIN_Resume x x x x FMT_MTD.1/eID-PIN_Unblock x x x x 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 Security Target TCOS eID_Card/SLE78CLX1440P 91/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 OT.Identification OT.Personalization OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.ID_Card_Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfuntion OT.SCD/SVD_Gen OT.Sigy_SigF FPT_PHP.3 x x x Table 12: Coverage of Security Objectives for the TOE by SFR 327 For the coverage of security objectives derived from the SSCD Protection Profile by SFR this ST refers to [SSCDPP]. The rationale related to the security functional requirements from [SSCDPP] are exactly the same as given for the respective items of the security policy definitions in sec. 11.1 of [SSCDPP] and they are not conflicting to the coverage given in the Table 12 above. 328 A detailed justification required for suitability of the security functional requirements to achieve the security objectives is given below. 329 The security objective OT.Identification addresses the storage of Initialization and Pre- Personalization 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 Initialization and Pre-personalization Data (including the Personalization Agent key). The SFR FMT_MTD.1/INI_DIS requires the Personalization Agent to disable access to Initialization and Pre-personalization Data in the life phase ‘operational use’. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 330 The security objective OT.Personalization aims that only Personalization Agent can write the 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, amongst other, an appropriate authorization level of a rightful terminal. This authorization level can be achieved by the terminal identification/authentication as required by the SFR FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal256. Since only an ATT can reach the necessary authorization level, 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_Unblock, FMT_MTD.1/eID-PIN_Activate) also support achieve- ment 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- personalization Data. FMT_MTD.1/PA_UPD covers the related property of OT.Personalization (updating SOC). The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 256 which, in turn, are supported by the related FCS-components. The author of the PP dispensed here with listing of these supporting FCS-components for the sake of clearness. See the next item OT.Data_Integrity for further detail. Security Target TCOS eID_Card/SLE78CLX1440P 92/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 331 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 unathorized modifying). Physical manipulation is addressed by FPT_PHP.3. Unathorized modifying of the stored data is addressed, in the first line, by FDP_ACC.1/TRM and FDP_ACF.1/TRM. A concrete authorization 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/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_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. 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 authorized identified role as required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. Unathorized 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 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, which is generated conformant to [EACTR] as required by FCS_CKM.1/CA_PICC if the Chip Authentication Private Key is created, 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 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 Perso- nalization Agent only and, hence, is to consider as trustworthily. The SFRs FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 332 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 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 and FCS_CKM.1/ CA_PICC governs creating/loading 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 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 Personalization Agent only and, hence, is to consider as trustworthily. Security Target TCOS eID_Card/SLE78CLX1440P 93/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 A prerequisite for successful CA is an accomplished TA as required by 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/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_Unblock, FMT_MTD.1/eID-PIN_Activate) also support achieve- ment 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. 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 authorized identified role as required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. The SFRs FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 333 The security objective OT.Data_Confidentiality aims that the TOE always ensures 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 mainly achieved by FDP_ACC.1/TRM and FDP_\ ACF.1/TRM. A concrete authorization level is achieved by the terminal identification/ authentication as required by the SFRs FIA_UID.1/Rightful_Terminal, FIA_UAU.1/ Right- ful_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/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_Unblock, FMT_MTD.1/ eID-PIN_Activate) also support achievement of this objective. FDP_RIP.1 requires era- sing 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. 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 authorized identified role as 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 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 evi- dence of possessing the Chip Authentication Private Key (SKPICC). FMT_MTD.1/SK_\ PICC and FCS_CKM.1/CA_PICC governs creating/ loading 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). 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 Personalization Agent only and, hence, is to consider as trustworthily. The SFRs FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for Security Target TCOS eID_Card/SLE78CLX1440P 94/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related. 334 The security objective OT.ID_Card_Tracing aims that the TOE prevents gathering TOE tracing data by means of unambiguous identifying the ID_Card remotely through establishing or listening to a communication via the contactless interface of the TOE without a priori knowledge of the correct 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/authorization data) – by FIA_AFL.1/ PACE; (ii) while establishing PACE communication using eID-PIN (blocking authentication data) – by FIA_AFL.1/eID-PIN_Blocking; (iii) for listening to PACE communication and for establishing CA communication (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. 335 The security objective OT.Chip_Auth_Proof aims enabling verification of the authenticity of the 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 (SKPICC). FMT_MTD.1/SK_PICC and FCS_CKM.1/CA_PICC governs creating/loading 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 CMAC). The authentication token TPICC is calculated using FCS_COP.1/CMAC. The SFRs FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for cryptographic operations needed. 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 Personalization Agent only and, hence, is to consider as trustworthily. 336 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 phase. 337 The security objective OT.Prot_Inf_Leak aims protection against disclosure of confidential User- or/and TSF-data stored on / processed by the TOE. 338 This objective is achieved • by FPT_EMSEC.1 for 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 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. 339 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. 340 The security objective OT.Prot_Malfunction aims ensuring a correct operation of the TOE by preventing its operation outside the normal operating conditions. Security Target TCOS eID_Card/SLE78CLX1440P 95/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 This objective is covered by FPT_TST.1 requiring self tests to demonstrate the correct operation of the TOE and tests of authorized 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 case of detected failure or operating conditions possibly causing a malfunction. 6.3.2 Rationale for SFR’s Dependencies 341 The dependency analysis for the security functional requirements shows that the basis for mutual support and internal consistency between all defined functional requirements is satisfied. All dependencies between the chosen functional components are analysed, and non-dissolved dependencies are appropriately explained. 342 The table below shows the dependencies between the SFR of the TOE. No. SFR-component from the PP Dependencies assumed Fulfilled by SFR 1 FCS_CKM.1/DH_PACE FCS_CKM.2 or FCS_COP.1 FCS_CKM.4 FCS_CKM.2/DH FCS_CKM.4 2 FCS_CKM.1/DH_CA FCS_CKM.2 or FCS_COP.1 FCS_CKM.4 FCS_CKM.2/DH FCS_CKM.4 3 FCS_CKM.1/CA_PICC FCS_CKM.2 or FCS_COP.1 FCS_CKM.4 FCS_COP.1/AES, FCS_COP.1/CMAC FCS_CKM.4 4 FCS_CKM.2/DH [FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4 5 FCS_CKM.4 FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA 6 FCS_COP.1/SHA FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 justification see page 50 FCS_CKM.4 7 FCS_COP.1/SIG_VER FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 justification see page 50 FCS_CKM.4 8 FCS_COP.1/AES FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4 9 FCS_COP.1/CMAC FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA FCS_CKM.4 10 FCS_RND.1 No dependencies n.a. 11 FIA_AFL.1/eID-PIN_Suspending FIA_UAU.1 FIA_UAU.1/PACE 12 FIA_AFL.1/eID-PIN_Blocking FIA_UAU.1 FIA_UAU.1/PACE 13 FIA_AFL.1/PACE FIA_UAU.1 FIA_UAU.1/PACE 14 FIA_API.1/CA No dependencies n.a. 15 FIA_UID.1/PACE No dependencies n.a. Security Target TCOS eID_Card/SLE78CLX1440P 96/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 No. SFR-component from the PP Dependencies assumed Fulfilled by SFR 16 FIA_UID.1/Rightful_Terminal No dependencies n.a. 17 FIA_UAU.1/PACE FIA_UID.1 FIA_UID.1/PACE 18 FIA_UAU.1/Rightful_Terminal FIA_UID.1 FIA_UID.1/Rightful_Terminal 19 FIA_UAU.4 No dependencies n.a. 20 FIA_UAU.5 No dependencies n.a. 21 FIA_UAU.6 No dependencies n.a. 22 FDP_ACC.1/TRM FDP_ACF.1 FDP_ACF.1/TRM 23 FDP_ACF.1/TRM FDP_ACC.1 FMT_MSA.3 FDP_ACC.1/TRM justification see page 63 24 FDP_RIP.1 No dependencies n.a. 25 FTP_ITC.1/PACE No dependencies n.a. 26 FTP_ITC.1/CA No dependencies n.a. 27 FAU_SAS.1 No dependencies n.a. 28 FMT_SMF.1 No dependencies n.a. 29 FMT_SMR.1 FIA_UID.1 FIA_UID.1/PACE, FIA_UID.1/Rightful_Terminal see also Application Note 57 30 FMT_LIM.1 FMT_LIM.2 FMT_LIM.2 31 FMT_LIM.2 FMT_LIM.1 FMT_LIM.1 32 FMT_MTD.1/INI_ENA FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 33 FMT_MTD.1/INI_DIS FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 34 FMT_MTD.1/CVCA_INI FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 35 FMT_MTD.1/CVCA_UPD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 36 FMT_MTD.1/DATE FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 37 FMT_MTD.1/PA_UPD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 38 FMT_MTD.1/SK_PICC FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 39 FMT_MTD.1/KEY_READ FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 40 FMT_MTD.1/eID-PIN_Resume FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 41 FMT_MTD.1/eID-PIN_Unblock FMT_SMF.1 FMT_SMF.1 Security Target TCOS eID_Card/SLE78CLX1440P 97/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 No. SFR-component from the PP Dependencies assumed Fulfilled by SFR FMT_SMR.1 FMT_SMR.1 42 FMT_MTD.1/eID-PIN_Activate FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 43 FMT_MTD.3 FMT_MTD.1 FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE 44 FPT_EMSEC.1 No dependencies n.a. 45 FPT_FLS.1 No dependencies n.a. 46 FPT_TST.1 No dependencies n.a. 47 FPT_PHP.3 No dependencies n.a. Table 13: Dependencies between the SFRs 343 For the Justification of non-satisfied dependencies see the description of the corresponding SFRs in the chapter 6. The dependency analysis shows that all dependencies being expected by CC part 2 and by extended components definition (chapter 5) are either fulfilled or their non-fulfillment is justified. 344 The rationale for SFR’s dependencies related to the security functional requirements taken over from [SSCDPP] are exactly the same as given for the respective items of the security policy definitions in sec. 6.2 loc. cit. 345 The table below shows the dependencies between the SFR of the TOE derived from the [SSCDPP]. SFRs which are equivalent to those from the [IDCARDPP] are not duplicated. No. SFR-component from the PP Dependencies assumed Fulfilled by SFR 48 FCS_CKM.1/SSCD [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_COP.1/SSCD FCS_CKM.4 49 FCS_COP.1/SSCD [FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_COP.1/SSCD FCS_CKM.4 50 FDP_ACC.1/SCD/SVD_Genera- tion_SFP_SSCD FDP_ACF.1 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD 51 FDP_ACC.1/Signature_Crea- tion_SFP_SSCD FDP_ACF.1 FDP_ACF.1/Signature_Creation_SFP_SSCD 52 FDP_ACC.1/SVD_Transfer_SFP _SSCD FDP_ACF.1 FDP_ACF.1/SVD_Transfer_SFP_SSCD 53 FDP_ACF.1/SCD/SVD_Genera- tion_SFP_SSCD FDP_ACC.1 FMT_MSA.3 FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD FMT_MSA.3/SSCD 54 FDP_ACF.1/Signature_Crea- tion_SFP_SSCD FDP_ACF.1 FMT_MSA.3 FDP_ACC.1/Signature_Creation_SFP_SSCD FMT_MSA.3/SSCD 55 FDP_ACF.1/SVD_Transfer_SFP _SSCD FDP_ACF.1 FMT_MSA.3 FDP_ACC.1/SVD_Transfer_SFP_SSCD FMT_MSA.3/SSCD 56 FDP_SDI.2/Persistent_SSCD No dependencies n.a. Security Target TCOS eID_Card/SLE78CLX1440P 98/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 No. SFR-component from the PP Dependencies assumed Fulfilled by SFR 57 FDP_SDI.2/DTBS_SSCD No dependencies n.a. 58 FIA_AFL.1/SSCD FIA_UAU.1 FIA_UAU.1/SSCD 59 FIA_UAU.1/SSCD FIA_UID.1 FIA_UID.1/SSCD 60 FIA_UID.1/SSCD No dependencies n.a. 61 FMT_MOF.1/SSCD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1/SSCD FMT_SMR.1/SSCD 62 FMT_MSA.1/Admin_SSCD [FDP_ACC.1 or FDP_IFC.1] FMT_SMR.1 FMT_SMF.1 FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD FMT_SMR.1/SSCD FMT_SMF.1/SSCD 63 FMT_MSA.1/Signatory_SSCD [FDP_ACC.1 or FDP_IFC.1] FMT_SMR.1 FMT_SMF.1 FDP_ACC.1/Signature_Creation_SFP_SSCD FMT_SMR.1/SSCD FMT_SMF.1/SSCD 64 FMT_MSA.2/SSCD FMT_MSA.1 FMT_SMR.1 FMT_MSA.1/Admin_SSCD, FMT_MSA.1/Signatory_SSCD FMT_SMR.1/SSCD 65 FMT_MSA.3/SSCD FMT_MSA.1 FMT_SMR.1 FMT_MSA.1/Admin_SSCD, FMT_MSA.1/Signatory_SSCD FMT_SMR.1/SSCD 66 FMT_MSA.4/SSCD [FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD FDP_ACC.1/Signature_Creation_SFP_SSCD 67 FMT_MTD.1/Admin_SSCD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1/SSCD FMT_SMR.1/SSCD 68 FMT_MTD.1/Signatory_SSCD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1/SSCD FMT_SMR.1/SSCD 69 FMT_SMF.1/SSCD No dependencies n.a. 70 FMT_SMR.1/SSCD FIA_UID.1 FIA_UID.1/SSCD 71 FPT_PHP.1/SSCD No dependencies n.a. Table 14: Dependencies between the SFRs required by [SSCDPP] 346 The dependency analysis shows that all dependencies being expected by CC part 2 and by extended components definition (chapter 5) are fulfilled. 6.3.3 Security Assurance Requirements Rationale 347 The current assurance package was chosen based on the pre-defined assurance package EAL4. This package permits a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resou- rces. 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 circumstances where develo- pers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security specific engineering costs. Security Target TCOS eID_Card/SLE78CLX1440P 99/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 348 The selection of the component ALC_DVS.2 provides a higher assurance of the security of the ID_Card’s development and manufacturing, especially for the secure handling of sensitive material. 349 The selection of the component ATE_DPT.2 provides a higher assurance than the pre- defined EAL4 package due to requiring the functional testing of SFR-enforcing modules. 350 The selection of the component AVA_VAN.5 provides a higher assurance than the pre- defined EAL4 package, namely requiring a vulnerability analysis to assess the resistan- ce to penetration attacks performed by an attacker possessing a high attack potential (see also Table 3, entry ‘Attacker’). This decision represents a part of the conscious security policy for the ID_Card required by the ID_Card Issuer and reflected by the [IDCARDPP]. 351 The set of assurance requirements being part of EAL4 fulfils all dependencies a priori. 352 The augmentation of EAL4 chosen comprises the following assurance components ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. For these additional assurance components, all dependencies are met or exceeded in the EAL4 assurance package (cf. [IDCARDPP, Table 15]). 6.3.4 Security Requirements – Internal Consistency 353 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 form an internally consistent whole. 354 The analysis of the TOE’s security requirements with regard to their mutual support 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 analyzed 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 behavior 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 Security Assurance Requirements Rationale shows that the assurance requirements are internally consistent as all (additional) dependencies are satisfied and no inconsistency appears. 355 Inconsistency between functional and assurance requirements could only arise, if there are functional-assurance dependencies being not met, a possibility having been shown not to arise in sections 6.3.2 Rationale for SFR’s Dependencies and 6.3.3 Security Assurance Requirements Rationale. Furthermore, as also discussed in section 6.3.3 Security Assurance Requirements Rationale, the chosen assurance components are adequate for the functionality of the TOE. So, there are no inconsistencies between the goals of these two groups of security requirements. Security Target TCOS eID_Card/SLE78CLX1440P 100/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 7 TOE Summary Specification 356 This section presents an overview of the security functionalities implemented by the TOE and the assurance measures applied to ensure their correct implementation. 357 According to the SFRs the TOE provides the following functionalities • Access control to the User Data stored in the TOE • Secure data exchange between the ID_Card and the Service Provider connected • Identification and authentication of users and components • Audit • Generation of the Signature Key Pair for the eSign application • Creation of Digital Signatures by the eSign application • Management of and access to TSF and TSF-data • Accuracy of the TOE security functionality / Self-protection 358 They are already mentioned in section 6.1.1 and represent the functional description of the feature overview in section 1.4.2. The TOE Summary Specification will be given in more detail in the following sections. Further technical information how the security func- tions actually implement the TOE security functional requirements, which TOE modules realize which functions is contained in the Security architecture Description (ADV_ARC), the Functional Specification (ADV_FSP) and the TOE Design Specification (ADV_TDS). 7.1 Access control to the User Data stored in the TOE 359 The access to User Data is restricted according to the SFRs FDP_ACC.1/TRM and FDP_ACF.1/TRM. Different types of Terminal (PCT, EIS, ATT and SGT) are assigned dedicated access rights after successful authentication protocol (cf. section 7.3) supported by FIA_UAU.1/PACE and FIA_UAU.1/Rightful_Terminal. For the eSign appli- cation the access to the signature creation data is additionally controlled by FDP_ACC.1/ Signature-creation_SFP_SSCD and FDP_ACF.1/Signature-creation_SFP_SSCD. The access control provided by this security function includes also the integrity check required by FDP_SDI.2/Persistent_SSCD for the stored signature key (SCD). 7.2 Secure data exchange 360 The secure data exchange in a trusted channel is required by FTP_ITC.1/PACE and FTP_ITC.1/CA. It is supported by fulfilling FCS_COP.1/AES giving confidentiality by data encryption/decryption and FCS_COP.1/CMAC providing integrity. The quality and the authenticity of the key used based on the successful execution of the PACE protocol, Terminal Authentication and the Chip Authentication governed by FIA_API.1/CA: Chip Identification/Authentication, and FIA_UAU.1/Rightful_Terminal: Terminal Authentication (EIS, ATT, SGT). Note that despite of the password used in PACE may be weak nevertheless the trusted channel is protected by strong keys. This security function Security Target TCOS eID_Card/SLE78CLX1440P 101/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 provides also the integrity check required by FDP_SDI.2/DTBS_SSCD for the transmitted DTBS. 7.3 Identification and authentication of users and components 361 The identification and authentication protocol is decribed in the [EACTR], where the reliability and the security of the corresponding steps is considered and recognized as appropriate. Identification and authentication is provided for users (FIA_UID.1/PACE, FIA_UAU.1/PACE, FIA_UID.1/SSCD, FIA_UIA.1/SSCD) and external entities like terminals of different types (FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Termi- nal). During the terminal authentication protocol a certificate is used, this is supported by FCS_COP.1/SIG_VER. 362 The TOE itself must also be authenticated, which is supported by FIA_API.1/CA. The Requirements laid down in FIA_UAU.4, FIA_UAU.5 and FIA_UAU.6 concerns the protocol data, prevents re-use and how the security state, e.g. a specified role (FMT_\ SMR.1) of an identified and authenticated user or device is achieved and maintained. 363 To prevent brute-force attacks the eID-PIN reference data will be suspended after con- secutive failed authentication attempts, and will be blocked if a defined number of failed attempts is passed (FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking). Suspended reference data requires always the successful CAN authentication before any PIN authentication can be applied. 364 To prevent skimming attacks on non-blocking reference data, i. e. the CAN, MRZ and eID-PUK, the TOE blocks the authentication procedure after detecting any failed authen- tication attempt. Because the MRZ and the eID-PUK carry enough entropy this is even sufficient for a brute force attack which is not necessary for the CAN, because the latter is restricted revealable. 365 The identification and authentication of the ID_Card holder as Signatory, i.e. the inten- tion of the User to create an electronic signature, requires the sucessful verification of a different eSign-PIN, which is usually a single one but may be also one of two. It is also a blocking if a dedicated number of consecutive failed attempts is passed (FIA_AFL.1/ SSCD). 366 The security and the reliability of the identification and authentification is supported by the correct key agreement (FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA, FCS_CKM.2/ DH, FCS_COP.1/SHA) and the quality of random numbers (FCS_RND.1) used by the ID_Card and the terminal. As the authentication state is left, the session keys can not be used anymore (FCS_CKM.4). 7.4 Audit 367 The Manufacturer shall control the TOE production and must also file audit records (FAU_SAS.1). This is supported by FMT_MTD.1/INI_ENA (writing initialization and pre- personalization data) and is diabled for the Operational Phase (FMT_MTD.1/INI_DIS) by the Personalization Agent. Security Target TCOS eID_Card/SLE78CLX1440P 102/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 7.5 Generation of the eSign Signature Key Pair 368 The eSign Signature Key Pair is generated by the TOE (FCS_CKM.1/SSCD), such that the private key (SCD) does never appear outside the TOE and is destroyed if a new key is generated (FCS_CKM.4/SSCD). 369 The use of the SCD under access control (section 7.1), which is supported by FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD, and FDP_ACF.1/SCD/SVD_Genera- tion_SFP_SSCD. 370 The execution of the generation of a Signature Key Pair is accessible for the User S.Admin only, the initial Reference Authentication Data (RAD) is created (FMT_MTD.1/ Admin) but can never be used for signature creation. Only the User S.Sigy is able to change the RAD to an operational state (FMT_MSA.1/Signatory_SSCD, FMT_MSA.2/ SSCD). 371 The Signature Key Pair generation requires a secure channel to the User S.Admin, who receives through that channel also the Signature Verification Data (SVD). This is suppor- ted by FDP_ACC.1/SVD_Transfer_SFP_SSCD, FDP_ACF.1/SVD_Transfer_\SFP_\ SSCD. 7.6 Creation of Digital Signatures 372 The creation of electronic signatures must fulfill the strong requirements of the Signature Law in Germany and the yearly issued by the Bundesnetzagentur List of Algorithms and Parameters ([ALGO]). The parameters for FCS_COP.1/SSCD are chosen in such a way that they fulfill these requirements also in the near future. Nevertheless the User S.Sigy is advised to follow the publications of the Bundesnetzagentur for the current status, otherwise the electronic signature may loose its status as qualified electronic signature. 7.7 Management of and access to TSF and TSF-data 373 The management and the access to the TOE security functions and the TSF data is controlled by the entire functionality class FMT. During Initialization, Personalization and in the Operational Phase of the Life Cycle Phases the Operation System of the TOE provides the management functions for identified roles (FMT_SMF.1, FMT_SMR.1, FMT_SMF.1/SSCD, FMT_SMR.1/SSCD) and maintain all the access rules over the life cycle of the TOE and even before the production of the TOE is finished during Initialization and Prepersonalization (FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). The during initialization necessary test features are no more availabe after TOE delivery (FMT_LIM.1, FMT_LIM.2). 374 After delivery the TOE is personalized (FMT_MTD.1/PA_UPD), the initial CVCA data is stored (FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE) together with the Chip Authentication Private Key (FMT_MTD.1/SK_PICC), which can only be used internally but never accessed else (FMT_MTD.1/KEY_READ). The Chip Authen- tication Private Key can be loaded on the TOE during Personalization (FMT_MTD.1/ SK_PICC) or generated (FCS_CKM.1/CA_PICC), following the same requirements as for ECDH ephemeral key agreement. 375 The eID-PIN can be resumed (FMT_MTD.1.1/eID-PIN-Resume) by the ID_Card holder after executing successfully the PACE protocol with the CAN and the e-ID-PIN itself. A blocked eID-PIN can be unblocked (FMT_MTD.1.1/eID-PIN-Unblock) by the ID_Card Security Target TCOS eID_Card/SLE78CLX1440P 103/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 holder or a Authentication Terminal with a corresponding authorization level. This is under access control (FDP_ACF.1/TRM) and supported by the certificate chain veri- fication (FMT_MTD.3). 376 The eID-PIN can be activated and also deactivated (FMT_MTD.1.1/eID-PIN-Activate) by an Authentication Terminal with an authorization level sufficient for eID-PIN manage- ment. This is under access control (FDP_ACF.1/TRM) and supported by the certificate chain verification (FMT_MTD.3). 377 The eSign functionality is separately supervised by the operation system. All the access rules and the memory assignment is done during initialization phase and can not be changed later on, independent of the operational status of the application. The Administrator (Service Provider) can generate the SCD/SVD key pair (FMT_MSA.1/ Admin_SSCD, FMT_MSA.3/SSCD, FMT_MSA.4/SSCD) and create the initial reference data objects (FMT_MSA.2/SSCD, FMT_MTD.1/Admin_SSCD). 378 Only the identified by the eID application User is able to set the SCD operational (FMT_ MSA.2/SSCD, FMT_MSA.4/SSCD, FMT_MSA.1/Signatory_SSCD) and generate elec- tronic signatures (FMT_MOF.1/SSCD, FMT_MTD.1/Signatory_SSCD). 7.8 Reliability of the TOE security functionality 379 The operating system of the TOE protects the security functionality of the TOE as soon as it it installed during Initialization Phase. The TOE will not emit physical or logical data information on security User Data outside the secure channels controlled by the opera- ting system (FPT_EMSEC.1). 380 The TOE will resist physical manipulation and probing (FPT_PHP.1/SSCD, FPT_PHP.3) and enter a secure state in case an failure occur (FPT_FLS.1). This functionality is supported also by the hardware, which was approved in a separate evaluation process. 381 The TOE will permantly run tests to maintain the correct operation of the TOE security functions and the achieved security level (FPT_TST.1, FDP_SDI.2/Persistent_SSCD, FDP_SDI.2/DTBS_SSCD). 382 The TOE operating system controls the assignment of memory to the User Data in the file system and ensures that no information is available upon de-allocation of a resource. The access rules to the assigned memory remain the same even if the data is no more operational (FDP_RIP.1). 383 This functionality is supported by the entire class FMT. 7.9 TOE SFR Statements 384 For the sake of completeness the TOE Summary Specification of the previous sections is re-ordered once again. All the TOE SFR statements are listed and it is described how they are fulfilled by the TOE. If appropriate requirements are handled together to avoid unneccessary text duplication. 385 FCS_CKM.1/DH_PACE: The EC Diffie-Hellman Session Key Derivation Algorithm uses a Challenge-Response-Protocol for the derivation of the session keys. The correctness of the keys is verified implicitly by the correct realization of the secure messaging exchange. Security Target TCOS eID_Card/SLE78CLX1440P 104/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 386 FCS_CKM.1/DH_CA: The EC Diffie-Hellman Session Key Derivation Algorithm uses a Challenge-Response-Protocol for the derivation of the session keys. The correctness of the keys is verified implicitly by the correct realization of the secure messaging ex- change. 387 FCS_CKM.1/CA_PICC: The Chip Authentication Key Pair is usually loaded during Per- sonalization. Beside this it can also be created by the TOE in this life cycle phase, but this is no more possible after the Personalization is finished. 388 FCS_CKM.2/DH: The keys used in the Diffie-Hellman key agreement are distributed by the means specified in the PACE protocol, which is proven to be secure and the standardized Chip Authentication protocol known to be a secure Challenge-Response- Protocol 389 FCS_CKM.4: Each session key is used only by the authenticated user and is destroyed if the authentication fails or is restarted again. Additionally in case of loss of power the keys are also erased, because they are not stored permanently. 390 FCS_COP.1/SHA The hash function is used for key deriviation. The recently discovered collision attacks are not relevant for this application. 391 FCS_COP.1/SIG_VER uses the initial public key Country Verifying Certification Authority and the public keys in certificates provided by the terminals as TSF data for the Terminal Authentication Protocol and the Access Control. Their validity verified according to FMT_MDT.3 and their security attributes are managed by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE. There is no need to import user data or manage their security attributes. 392 FCS_COP.1/AES The AES algorithm is a generally recognized as secure encryption algorithm. No exploitable weakness is known, and the security level is higher than 100 bit, which is accepted as appropriate in the future. 393 FCS_COP.1/CMAC The CMAC algorithm is a generally recognized as secure message authentication algorithm. This mode of operation fixes security deficiencies of the used before CBC-MAC. 394 FCS_RND.1: The randomness of values for challenges or ephemeral or permanent keys will be guaranteed by the underlying hardware TSF. To achieve the SOF “high” the generated data must have sufficient entropy. This is fulfilled automatically if the random number generator is certified as P2 according [AIS31]. 395 FCS_CKM.1/SSCD: The eSign key pair generation algorithm is compliant to the Technical Specification [ECCTR]. The available parameters can be chosen such that they are suitable for the near and the long future. 396 FCS_COP.1/SSCD: The cryptographic operation is implemented with care based on the knowledge and experience of T-Systems such that no leakage of secure user data can occur. 397 FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking and FIA_AFL.1/PACE implement well-known user authentication data handling. The feature of PIN suspending twarts the unwanted inconspicuous blocking. It is provided by the TOE based on the approved methods of ISO 7816 [ISO7816]. The ranges for the suspending value sad and the blocking value bad are defined in Administrator Guidance [TCOSADM]. They depend on the length and the alphabet chosen for these PINs. The handling of non-blocking authentication data depends on its entropy. Whereas MRZ with random serial numbers and eID_PUK with at least 10 digits provide sufficient randomness, the CAN handling Security Target TCOS eID_Card/SLE78CLX1440P 105/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 must be considered separately. Taken into account that the CAN does not represent a secret the PACE session restart is sufficient to protect unsuspicious tracing on the CAN. 398 FIA_API.1/CA: The chip authentication implementation based on the description of the protocol in [EACTR] provides a proof of the authenticity of the chip, which is proven to prevent the Challenge Semantics attack. The private Chip Authentication is either leaded or created during personalization phase and can only be used after terminal authen- tication and never read out. 399 FIA_UID.1/PACE, FIA_UID.1/Rightful_Terminal FIA_UAU.1/PACE, FIA_UAU.1/Rightful_ Terminal, FIA_UAU.1/PACE, FIA_UAU.1/Rightful_Terminal, FIA_UAU.4: The access rules allow establishing a communication channel before the user is authenticated. After successful authentication of the Terminal based on PACE or Terminal Authentication Protocol a security status is maintained. Based on that status the access rules apply that allow or disallow the execution of commands and the access to security data controlled controlled by the Operating System of the TOE. The PACE protocol is proven to be secure. 400 FIA_UAU.5: The authentication of the Manufacturer, a Personalization Agent and a Terminal is controlled by the Access Rules laid down in the Operating System in a very early stage of the life cycle. Even if the file system is not available, the Initialization Data can only be written by a successfully authenticated user (in a Manufacturer’s role). The authentication attempts as Personalization Agent can be based on Symmetric Authen- tication Mechanism with the Personalization Agent Key and the Terminal Authentication Protocol with Personalization Agent Keys. The high entropy of the Symmetric Keys used herein guarantees the reliability of these authentications. After run of the Terminal Authentication and the Chip Authentication Protocol the TOE accepts only commands with a correct message authentication code sent by means of Secure Messaging with key agreed with the terminal by means of the Chip Authenti- cation Mechanism. The security proof of the protocol defined in [EACTR] guarantees the correctness and the reliability of the authentications. 401 FIA_UAU.6 The TOE guarantees based on the inherent MAC verification in the secure messaging mechanism that the re-authentication of the user or component (Personali- zation Agent, Terminal) is possible for every command after successful authentication. 402 FIA_UAU.1/SSCD: The Administrator (S.Admin) is authenticated by the Terminal Access Control. The successfully executed Terminal Authentication based on a certificate with a relative authorization “Install (qualified) certificate” according to [EACTR, Table C.4] authenticates the Administrator (CSP). The Signatory is authenticated based on the PACE Protocol and the sucessful ePIN verification, which is protected by the secure channel established before. 403 FIA_UID.1/SSCD: If the SCD/SVD is not generated yet, the default user will be identified as Administrator. If the SCD is set to “operational” then the default user is the Signatory. If the SCD is terminated (set to “not operational”) the default user will be again the Administrator (CSP). This behavior is determined by the access rules of the file system. 404 FIA_AFL.1/SSCD: Any failed authentication attempt will be detected by the TSF, and the consecutive authentication failures will be accumulated. Depending of the structure of the RAD the number sigad must be chosen from a specified in the Administrator Guidan- ce range. The structure of RAD should be homogenous (nearly equally distributed) for the application of the table and the file system of the signature application must support these restrictions. The User will be informed that the security of the authentication depends on the quality of the selected VAD/RAD. The file system of the TOE may be Security Target TCOS eID_Card/SLE78CLX1440P 106/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 configured such that the RAD is set up of two pieces of data including the eSign-PIN each with its own retry counter. There is no local eSign-PUK foreseen, but the global eID-PUK can be used for resetting the signature authentication retry counter. A more detailed analysis covering that case is given in the Administrator Guidance ([TCOSADM]). 405 FDP_ACC.1/TRM The Terminal Access Control SFP access rules are fixed in the Ope- rating System of the TOE; it can not be changed nor bypassed. 406 FDP_ACF.1/TRM The access control rules of FDP_ACF.1 uses security attributes which are defined during the personalization and are fixed over the whole life time of the TOE. 407 FDP_RIP.1: The TOE operating system controls the assignment of memory to the User Data in the file system and ensures that no information is available upon de-allocation of a resource. The access rules to the assigned memory remain the same even if the data is no more operational (FDP_RIP.1). 408 FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD: The execution of the generation of a Signature Key Pair is accessible for the User S.Admin only. The initial Reference Authentication Data (RAD) is created but can never be used for signature creation. 409 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD: Access control rules of FDP_ACF.1 uses security attributes which are defined during the personalization and are fixed over the whole life time of the TOE. 410 FDP_ACC.1/SVD_Transfer_SFP_SSCD: The Signature Key Pair generation requires a secure channel to the User S.Admin, who receives through that channel also the Sig- nature Verification Data (SVD), that will be used to issue a corresponding qualified certificate to the identified ID_Card holder. 411 FDP_ACF.1/SVD_Transfer_SFP_SSCD: The access control rules of FDP_ACF.1 uses security attributes which are defined during the personalization and are fixed over the whole life time of the TOE. 412 FDP_ACC.1/Signature_Creation_SFP_SSCD The use of the SCD is avaliable for the authenticated user only and is under access control (section 7.1). For authentication the entered VAD must coincide with the stored RAD. 413 FDP_ACF.1/ Signature_Creation_SFP_SSCD: The access control rules of FDP_ACF.1 uses security attributes which are defined during the personalization and are fixed over the whole life time of the TOE. 414 FDP_SDI.2/Persistent_SSCD, FDP_SDI.2/DTBS_SSCD: The stored User Data and the entered DTBS Data will be checked by the operating system for integrity errors, so any change will be detected. The user will be informed by the corresponding status code, that an error occurred. During opeartions the integrity check will be provided by the hardware. 415 FTP_ITC.1/PACE: The TOE provides a secured communication channel based on the approved algorithms of Secure Messaging if the PACE protocol with the selected authentication data. 416 FTP_ITC.1/CA: The TOE provides a secured communication channel based on the approved algorithms of Secure Messaging if the terminal has been authenticated as a rightful. 417 FAU_SAS.1: The IC Identification Data can be read by the successfully authenticated Manufacturer, which allows the Manufacturer to store this data in audit records. After Personalization the read access to IC Identification Data is disabled. Security Target TCOS eID_Card/SLE78CLX1440P 107/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 418 FMT_SMF.1, FMT_SMR.1: Maintaining the different roles and TSFs of the TOE using dedicated access rules can not be changed or disabled in the Operating System. The assignment of a specific role is supported by a successful authentication and the follo- wing-up Secure Messaging. The embedded software (i.e. the operating system) enfor- ces the application of the access rules before any function is allowed to proceed. 419 FMT_LIM.1, FMT_LIM.2: Limitations of capabilities or availability are enforced by the Operating System of the TOE controlling the integrity of the stored access rules and the used functions. After Initialization all data testing-specific commands and actions are disabled. It is not possible to override these controls and restore them for use. 420 FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS: Initialization Data is used for audit log of a pre-personalized TOE. It is stored in the TOE, but the acces to this information is disabled as soon as the TOE is personalized. 421 FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE: The intial Per- sonalization data from the Issuing Branch is 422 FMT_MTD.1/PA_UPD, FMT_MTD.1/SK_PICC: Only the User authenticated as Perso- nalization Agent is able to update the Personalization Data and to create/load the private chip authentication key. These objects are under access control that is fixed in the file system and can never be changed in the operational phase. 423 FMT_MTD.1/KEY_READ: The private chip authentication key is object under access control that is fixed in the file system and can never be changed in the operational phase. 424 FMT_MTD.1/eID-PIN_Resume: Resuming a suspended eID-PIN requires the knowledge of the CAN and additionally the knowledge of the eID-PIN itself. The corresponding numbers of consecutive failed attempts can be selected from a defined in the Admi- nistrator Guidance interval, which is restricted by the security evaluation. 425 FMT_MTD.1/eID-PIN_Unblock: The eID-PIN can be unblock and re-initialized only by an Authentication Terminal that is granted a special authorization level. 426 FMT_MTD.1/eID-PIN_Activate: The eID-PIN can be activated and deactivated only by an Authentication Terminal that is granted a special authorization level. 427 FMT_MTD.3 The Operating System of the TOE accepts only valid certificates; this includes the existence of a valid certificate chain up to the trust anchor (CVCA key) of the TOE. 428 FMT_SMR.1/SSCD, FMT_SMF.1/SSCD: Maintaining the different roles and TSFs of the TOE using dedicated access rules can not be changed or disabled in the Operating System. The assignment of a specific role is supported by a successful authentication and the following-up Secure Messaging. The embedded software (i.e. the operating system) enforces the application of the access rules before any function is allowed to proceed. 429 FMT_MOF.1/SSCD: The User S.Admin creates the initial RAD, but can not set it to operational state. Only the Card_holder can access the initial RAD, change it and set it to the operational state. 430 FMT_MSA.1/Admin_SSCD, FMT_MSA.2/SSCD: The management of security attributes (FMT_MSA.1 and FMT_MSA.2) is under Access Control (section 7.1) that is fixed in the file system and can never be changed in the personalization and operational phases. The attribute “authorized” for SCD/SVD Management is assigned only to the Administrator S.Admin (CSP) and this attribute can not be modified in the operational Security Target TCOS eID_Card/SLE78CLX1440P 108/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 phase. During Personalization the attribute can only be set to “not authorized” for S.Admin in the operational phase but can never set to “authorized” for S.User. If in the operational phase the S.Admin is not authorized for SCD/SVD Management then the eSign application can not be activated later. 431 FMT_MSA.1/Signatory_SSCD, FMT_MSA.2/SSCD: The management of security attributes (FMT_MSA.1 and FMT_MSA.2) is under Access Control (section 7.1) that is fixed in the file system and can never be changed in the operational phase. The attribute “operational” for SCD can be set or removed (set to “not operational”) only by the Signatory S.Sigy. 432 FMT_MSA.3/SSCD: In the file system the initial values for the security attributes “authorized” for SCD/SVD Management and “operational” for SCD are set restrictive according to the corresponding SFPs. The Signatory S.Sigy is not allowed to generate .the SCD/SVD pair and the CSP (S.Admin) can never set the SCD “operational”. 433 FMT_MSA.4/SSCD: Because the TOE does not support SCD/SVD generation by the Signatory, and because S.Admin and S.Sigy are different entities, there is no single operation that generates SCD/SVD pair and sets at the same time the SCD “operatio- nal”. 434 FMT_MTD.1/Admin_SSCD: The initial RAD (reference authentication data) is generated by the CSP (S.Admin). This special RAD value (PIN in transport mode) can never be used for creating digital signatures. 435 FMT_MTD.1/Signatory_SSCD: Only the Signatory, authenticated as the ID_Card holder can modify the initial RAD (PIN in transport mode). After the initial RAD value is changed by the Signatory, the SCD can be set to “operational”. 436 FPT_EMSEC.1: The Operating System of the TOE monitors the regular execution of commands, and if variations occur with test failures or integrity mismatch the commu- nication is closed. The strict care of uniformity and non-overloading single components is implemented in the Operating System and will be described detailed in ADV and AVA documentation. This implies the leakage of information about the Personalization Agent Authentication Key and the Chip Authentication Key. 437 FPT_FLS.1: The Operating System of the TOE guarantees that the TOE preserves a secure state if a test failure or integrity check mismatch occur 438 FPT_TST.1: The self tests of the underlying hardware and additional test maintained by the TOE provide the means for demonstrating that the TSF operation is correct and that the data is not manipulated. 439 FPT_PHP.3: The Operating System of the TOE monitors the regular execution of commands, and if variations occur with test failures or integrity mismatch the commu- nication will be closed immediately. 440 FPT_PHP.1/SSCD: The Operating System monitors the regular execution of commands and follows the information given by the hardware security functions. If physical tam- pering is detected by the hardware the communication will be closed immediately and the TOE enters a secure state. Security Target TCOS eID_Card/SLE78CLX1440P 109/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 7.10Statement of Compatibility 441 This is the statement of compatibility between this Composite Security Target and the Security Target Chip of the underlying hardware [HWST]. 7.10.1 Relevance of Hardware TSFs 442 The TOE is equipped with following Security Features to meet the security functional requirements: Relevant: • SF_DPM Device Phase Management • SF_PS Protection against Snooping • SF_PMA Protection against Modification Attacks • SF_PLA Protection against Logical Attacks • SF_CS Cryptographic Support Cryptographic support includes 3DES (not relevant), AES, RSA (not relevant), EC (not relevant), SHA-2 (SHA-256 and SHA512 – both not relevant), TRNG (relevant) and PRNG (not relevant). 7.10.2 Compatibility: TOE Security Environment Assumptions 443 The following list shows that assumptions neither of the TOE nor of the hardware have any conflicts between each other. They are either not relevant for this Security Target or are covered by appropriate Security Objectives. Assumptions of the Composite ST: None Assumptions of the SSCD PP ([SSCDPP]): A.CGA is covered by the Security Objectives for the TOE Environment OE.CGA_QCert and OE.SVD_Auth required by the [SSCDPP]. A.SCA is covered by the Security Objectives for the TOE Environment OE.DTBS_Intend required by the [SSCDPP]. 444 The identified here Objectives are related to OE.Passive_Auth_Sign and OE.Perso- nalization, that ensure the establishment of the correct identity of the eID_Card holder before the eSign application is activated. Note that authentic SVD for a certificate may be created already during Personalization as long as the corresponding secret key remains unknown and unusable until the eID_Card holder engage a CSP to make it available after certificate creation. Security Target TCOS eID_Card/SLE78CLX1440P 110/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Assumptions of the Hardware PP ([PP0035]): 445 A.Process-Sec-IC (Protection during Packaging, Finishing and Personalization) is relevant until the Personalization of the hardware (TOE Initialization) The assumption A.Process-Sec-IC covers the secure handling of the SC from the de- livery by the hardware manufacturer to the developer until the completion of the TOE. This assumption is regarded as being relevant, but not significant, because the con- tent of this assumption is examined during the examination of the assurance families ALC_DEL and ALC_DVS. This assumption is no more required for Composite TOE and is therefore not included into this Composite ST. 446 A.Plat-Appl (Usage of Hardware Platform) is relevant during TOE development The assumption A.Plat-Appl assumes that the Smartcard Embedded Software se- curely uses the hardware, taking into account the hardware user guidance and the hardware evaluation. This assumption is regarded as being relevant, but not signifi- cant, because the content of this assumption is examined during the examination of the assurance family ADV_COMP. That corresponds to the achievement of the secu- rity objectives e.g. OT.EMSEC-Design, OT.Tamper-ID and OT.Tamper-Resistance in the TOE end usage. This assumption is not required for Composite TOE and is there- fore not included into this Composite-ST. 447 A.Resp-Appl (Treatment of User Data ) This assumption is covered by the hardware’s objective for the environment OE.Resp-Appl which is related to TOE’s Life Cycle Phase 1 “Development”. It is sup- ported by the Security Objectives OT.Data_Integrity, OT.Data_Authenticity, OT.Da- ta_Confidentiality and TOE’s Environment Objective OE.Chip_\ Auth_Key. Assumptions of the specific hardware platform ([HWST]): A.Key-Function (Usage of Key-dependent Functions) Key-dependent functions (if any) shall be implemented in the Smartcard Embedded Software in a way that they are not susceptible to leakage attacks (as described un- der T.Leak-Inherent and T.Leak-Forced). This assumption is covered by the Hard- ware‘s objectives OE.Resp-Appl and OE.Plat-Appl for the environment and applies to Life Cycle Phase 1 “Development”. Threats 448 The Threats of the TOE and the hardware can be mapped or are not relevant. They show no conflict between each other. Threats of the Composite ST: • T.Skimming no conflict • T.Eavesdropping no conflict • T.ID_Card_Tracing no conflict Security Target TCOS eID_Card/SLE78CLX1440P 111/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 • T.Forgery covers T.RND of the Smardcard IC PP [PP0035] • T.Counterfeit no conflict • T.Abuse-Func matches the corresponding threat of the of the Smardcard IC PP [PP0035] • T.Information_Leakage matches T.Leak-Inherent and T.Leak-Forced of the Smardcard IC PP [PP0035] • T.Phys-Tamper matches T.Phys-Probing and T.Phys-Manipulation of the Smardcard IC PP [PP0035] • T.Malfunction matches corresponding threat of the Smardcard IC PP [PP0035] Threats of the hardware ST ([PP0035]): • T.Leak-Inherent matches T.Information_Leakage of the Composite ST • T.Phys-Probing matches T.Phys-Tamper of the Composite ST • T.Malfunction matches corresponding threat of the Composite ST • T.Phys-Manipulation matches T.Phys-Tamper of the Composite ST • T.Leak-Forced matches T.Information_Leakage of the Composite ST • T.Abuse-Func matches corresponding threat of the Composite ST • T.RND is covered by T.Information_Leakage and T.Forgery of the Composite ST and T.SCD_Divulg of the SSCD PP [SSCDPP] This threat (Deficiency of Random Numbers) is covered by T.Information_Leakage and T.Forgery because the Random Number Generator is used by the TOE for key generation and User Data protection. In case the key data is disclosed the confidentiality and integrity protection fails (for the actual session or Chip authentication). The same applies for SCD Generation if the eSign Application be- comes operational. Threats of the hardware ST ([HWST]): T.Mem-Access (Memory Access Violation) Parts of the Smartcard Embedded Software may cause security violations by accidentally or deliberately access- ing restricted data (which may include code) or privilege levels. Any restrictions are defined by the security policy of the specific application context and must be implemen- ted by the Smartcard Embedded Software. This threat is related to TOE’s Life Cycle Phase 1 “Development”. It is covered by the threat T.Abuse_Func of the TOE. Threats of the of the SSCD PP ([SSCDPP]): Security Target TCOS eID_Card/SLE78CLX1440P 112/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 449 The general mapping given in the table on p. 102 is considered now in more details. • T.SCD_Divulg is covered by T.Information_Leakage and T.Forgery of the Composite ST • T.SCD_Derive is covered by T.Information_Leakage • T.Hack_Phys matches T.Phys-Tamper of the Composite ST • T.SVD_Forgery is covered by T.Forgery of the Composite ST • T.SigF_Misuse is covered by T.Malfunction and T.Abuse-Func of the Composite ST • T.DTBS_Forgery is covered by T. Forgery of the Composite ST • T.Sig_Forgery is covered by T.Malfunction and T.Abuse-Func of the Composite ST Organizational Security Policies 450 The Organizational Security Policies of the TOE and the hardware have no conflicts between each other. They are shown in the following list. Organizational Security Policies of the Composite ST of the TOE: • P.Pre-Operational covers P.Process-TOE of the hardware ST • P.Terminal no conflict • P.ID_Card_PKI no conflict • P.Terminal_PKI no conflict • P.Trustworthy_PKI no conflict Organizational Security Policies of the Hardware ST: • P.Add-Functions (Additional Specific Security Functionality) no conflict The TOE’ hardware provides the following specific securi- ty functionality to the Smartcard Embedded Software: Ad- vanced Encryption Standard, Triple Data Encryption Stan- dard (not relevant), Rivest-Shamir-Adleman Cryptography (not relevant), Elliptic Curve Cryptography (not relevant), Secure Hash Algorithm SHA-2. • P.Process-TOE ([PP0035]) is covered by P.Pre-Operational of the Composite ST Organizational Security Policies of the of the SSCD PP ([SSCDPP]): • P.CSP_QCert no conflict • P.QSign no conflict • P.Sigy_SSCD no conflict • P.Sig_Non-Repud no conflict Security Target TCOS eID_Card/SLE78CLX1440P 113/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Security Objectives 451 The Security Objectives of the TOE and the hardware can be mapped or are not relevant. They show no conflict between each other. Security Objectives for the Composite ST of the TOE: • OT.Data_Integrity covers O.Add_Functions (AES) of the [HWST] • OT.Data_Authenticity covers O.Add_Functions (AES) of the [HWST] • OT.Data_Confidentiality covers O.Add_Functions (AES) of the [HWST] • OT.ID_Card_Tracing no conflict • OT.Chip_Auth_Proof no conflict • OT.Prot_Abuse-Func covers O.Prot_ Abuse-Func from [PP0035] • OT.Prot_Inf_Leak covers O.Leak-Inherent and O.Leak-Forced from [PP0035] • OT.Prot_Phys-Tamper covers O.Phys-Probing and O.Phys-Manipulation from [PP0035] • OT.Prot_Malfuntion matches O.Prot_Malfuntion from [PP0035] • OT.Identification matches O.Identification from [PP0035] • OT.Personalization no conflict Security Objectives for the hardware ([PP0035] and [HWST]): • O.Leak-Inherent (Protection against Inherent Information Leakage) is covered by OT.Prot_Inf_Leak • O.Phys-Probing (Protection against Physical Probing) is mapped to OT.Prot_Phys-Tamper • O.Malfunction (Protection against Malfunctions) is covered by the corresponding objective OT.Malfunction • O.Phys-Manipulation (Protection against Physical Manipulation) is mapped to OT.Prot_Phys-Tamper • O.Leak-Forced (Protection against Forced Information Leakage) is covered by OT.Prot_Inf_Leak • O.Abuse-Func (Protection against Abuse of Functionality) is covered by the corresponding objective OT. Abuse-Func • O.Identification (Hardware Identification) covered by OT.Identification, which is relevant for the pre-operational phases • O.RND (Random Numbers) is covered by Security Objectives OT.Data_Inte- grity, and OT.Data_Confidentiality. The objectives of the TOE address the integrity and confi- dentiality of transmitted data, based on the protocols of Terminal and Chip Authentication, depending on a high cryptographic quality of random number generation. • O.Add-Functions (Additional Specific Security Functionality) Security Target TCOS eID_Card/SLE78CLX1440P 114/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 The hardware TOE must provide the following specific security functionality to the Smartcard Embedded Soft- ware: Advanced Encryption Standard (AES), which is mapped OT.Data_Integrity, OT.Data_Authenticity and OT.Data_Confidentiality. The security functionality of Triple Data Encryption Standard), Rivest-Shamir-Adleman algorithm, Elliptic Curve Cryptography and Secure Hash Algorithm is not used and therefore not relevant. • O.MEM_ACCESS is mapped to T.MEM_ACCESS This objective for the hardware supports the correct ope- ration of the TOE providing control on restricted data or privilege levels. Security Objectives for the eSign application ([SSCDPP]): • OT.Lifecycle_Security is covered by OT.Data_Integrity, OT.Data_Authenticity, and OT.Data_Confidentiality. The explicit mentioned in [SSCDPP] functionality of SCD destruction is supported by FCS_CKM.4 • OT.SCD/SVD_Gen is mapped to OT.Data_Authenticity, only a authorized user can invoke the SCD/SVD Generation • OT.SCD_Unique is mapped to O.RND of the hardware ST and to OT.Data_ Authenticity and OT.Data_Confidentiality of the Composite ST • OT.SCD_SVD_Corresp no conflicts The proof of correspondence between an SCD stored in the TOE and an SVD is implicit in the security mecha- nisms applied by the CGA. • OT.SCD_Secrecy is covered by OT.Data_Confidentiality, OT.Prot_Inf_Leak and OT.Phys_Tamper. • OT.Sig_Secure The use of robust technology is covered by OE.Legisla- tive_Compliance, e.g. by the support of the signature algorithm specification ([ALGO]). • OT.Sigy_SigF is covered by OT.Data_Authenticity • OT.DTBS_Integrity_TOE is covered by OT.Data_Integrity • OT.EMSEC_Design is covered by OT.Prot_Inf_Leak and OT.Phys_Tamper • OT.Tamper_ID is covered by OT.Phys_Tamper • OT.Tamper_Resistance is covered by OT.Phys_Tamper • OE.CGA_QCert is mapped to OE.Legislative_Compliance, OE.Termi- nal_Authentication and OE.Terminal, only rightful CSPs are allowed to issue qualified certificates • OE.SVD_Auth is covered by OT.Data_Integrity and is mapped to OE.Le- gislative_Compliance, OE.Terminal_Authentication and OE.Terminal for the environment Security Target TCOS eID_Card/SLE78CLX1440P 115/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 • OE.SSCD_Prov_Service is covered by objective for the ID_Card issuer: OE.Legislative_Compliance • OE.HID_VAD is covered by OT.Data_Integrity, OT.Data_Confidentiality and OE.Terminal_Authentication and OE.Terminal for the environment • OE.DTBS_Intend is covered by OE.ID_Card-Holder • OE.DTBS_Protect is covered by OE.ID_Card-Holder and OE.Terminal • OE.Signatory is covered by OE.ID_Card-Holder The obligation for a CSP activating an eSign application is to supply the ID_card holder as Signatory with the necessary User Guidance documentation according P.CSP_QCert. The TCOS Adminstrator Guidance ([TCOSADM]) provides further details what shall be included in the eSign User Guidance. Security Requirements 452 The relevant Security Requirements of the TOE and the hardware can be mapped or are not relevant. They show no conflict between each other. Security Requirements of the Composite ST of the TOE: • FCS_CKM.1/DH_PACE not relevant • FCS_CKM.1/DH_CA not relevant • FCS_CKM.1/CA_PICC not relevant • FCS_CKM.2/DH not relevant • FCS_CKM.4 no conflicts • FCS_COP.1/SHA not relevant • FCS_COP.1/SIG_VER not relevant • FCS_COP.1/AES matches FCS_COP.1/AES of [HWST] • FCS_COP.1/CMAC no conflicts • FCS_RND.1 matches FCS_RNG.1 of [HWST] • FIA_AFL.1/eID-PIN_Suspending no conflicts • FIA_AFL.1/eID-PIN_Blocking no conflicts • FIA_API.1/CA no conflicts • FIA_UID.1/PACE no conflicts • FIA_UID.1/Rightful_Terminal no conflicts • FIA_UAU.1/PACE no conflicts • FIA_UAU.1/Rightful_Terminal no conflicts • FIA_UAU.4 no conflicts • FIA_UAU.5 no conflicts • FIA_UAU.6 no conflicts • FDP_ACC.1/TRM not relevant • FDP_ACF.1/TRM not relevant • FDP_RIP.1 no conflicts Security Target TCOS eID_Card/SLE78CLX1440P 116/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 • FTP_ITC.1/CA not relevant • FAU_SAS.1 is supported by FAU_SAS.1 of [HWST], which is related to early manufacturing phases • FMT_SMF.1 no conflicts, partially supported by FMT_SMF1 of [HWST] (Initialization) • FMT_SMR.1 not relevant • FMT_LIM.1 matches FMT_LIM.1 of [HWST] • FMT_LIM.2 matches FMT_LIM.2 of [HWST] • FMT_MTD.1/INI_ENA not relevant • FMT_MTD.1/INI_DIS not relevant • FMT_MTD.1/CVCA_INI not relevant • FMT_MTD.1/CVCA_UPD not relevant • FMT_MTD.1/DATE not relevant • FMT_MTD.1/PA_UPD not relevant • FMT_MTD.1/SK_PICC not relevant • FMT_MTD.1/KEY_READ not relevant • FMT_MTD.1/eID-PIN_Resume not relevant • FMT_MTD.1/eID-PIN_Unblock not relevant • FMT_MTD.1/eID-PIN_Activate not relevant • FMT_MTD.3 not relevant • FPT_EMSEC.1 is supported by the Security Feature SF_PS of the hardware ([HWST]) and the AVA_VAN.5 evaluation • FPT_FLS.1 matches FPT_FLS.1 of [HWST] • FPT_TST.1 no conflicts • FPT_PHP.3 matches FPT_PHP.3 of [HWST] The following additional SFRs are derived from the SSCDPP. Except of FPT_PHP.1/SSCD they are all not relevant for the hardware. • FCS_CKM.1/SSCD not relevant • FCS_COP.1/SSCD not relevant • FDP_ACC.1/ SCD/SVD_Generation_SFP_SSCD not relevant • FDP_ACC.1/ SVD_Transfer_SFP_SSCD not relevant • FDP_ACC.1/Signature-Creation_SFP not relevant • FDP_AFC.1/ SCD/SVD_Generation_SFP_SSCD not relevant • FDP_AFC.1/ SVD_Transfer_SFP_SSCD not relevant • FDP_AFC.1/Signature-creation_SFP_SSCD not relevant • FDP_SDI.2/Persistent_SSCD not relevant • FDP_SDI.2/DTBS_SSCD not relevant • FIA_AFL.1/SSCD not relevant • FIA_UAU.1/SSCD not relevant • FIA_UID.1/SSCD not relevant • FMT_MOF.1/SSCD not relevant • FMT_MSA.1/Admin_SSCD not relevant • FMT_MSA.1/Signatory_SSCD not relevant Security Target TCOS eID_Card/SLE78CLX1440P 117/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 • FMT_MSA.2/SSCD not relevant • FMT_MSA.3/SSCD not relevant • FMT_MSA.4/SSCD not relevant • FMT_MTD.1/Admin_SSCD not relevant • FMT_MTD.1/Signatory_SSCD not relevant • FMT_SMR.1/SSCD not relevant • FMT_SMF.1/SSCD not relevant • FPT_PHP.1/SSCD is supported by the Security Feature SF_PS and SF_PMA of the hardware ([HWST]) and the AVA_VAN.5 evaluation Security Requirements of the hardware • FAU_SAS.1 covered by FAU SAS.1 of the Composite ST • FCS_COP.1/AES covered by FCS_COP.1/AES of the Composite ST • FCS_COP.1/DES not relevant, DES is not used in the OS, the same applies to FCS_COP.1/RSA, FCS_COP.1/ECDSA, FCS_COP.1/ECDH, FCS_COP.1/SHA which are not used • FCS_RNG.1 (Quality metric for random numbers) matches FCS_RND.1 of the Composite ST • FDP_ACC.1 (Subset access control) is not relevant for the TOE, but for the implementation of the OS, therefore it is covered by ADV_IMP.1 (Implementation representation of the TSF) • FDP_ACF.1 (Security attribute based access control) is not relevant for the TOE, but for the implementation of the OS, therefore it is covered by ADV_IMP.1 (Implementation representation of the TSF • FDP_ITT.1 (Basic internal transfer protection) is covered by FPT_EMSEC.1 of the Composite ST • FDP_IFC.1 (Subset information flow control) is covered by FPT_EMSEC.1 of the Composite ST • FMT_SMF.1 (Specification of Management Functions) is covered by FMT_SMF.1 of the Composite ST • FMT_LIM.1 (Limited capabilities) is covered by FMT_LIM.1 of Composite ST • FMT_LIM.2 (Limited availability) is covered by FMT_LIM.2 of Composite ST • FMT_MSA.1 (Management of security attributes) no conflicts • FMT_MSA.3 (Static attribute initialization) no conflicts • FPT_FLS.1 (Failure with preservation of secure state) matches FPT_FLS.1 of the Composite ST • FPT_ITT.1 (Basic internal TSF data transfer protection) is covered by FPT_EMSEC.1 of the Composite ST • FPT_PHP.3 (Resistance to physical attack) is covered by FPT_FLS.1 and FPT_PHP.3 of the Composite ST • FDP_SDI.1, FDP_SDI.2, FRU_FLT.2, FPT_TST.2 concern the hardware oper- ation, no conflicts to SFRs of the TOE Security Target TCOS eID_Card/SLE78CLX1440P 118/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Assurance Requirements 453 The level of assurance of the TOE is EAL 4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 454 The chosen level of assurance of the hardware is EAL 5 augmented with ALC_DVS.2 and AVA_VAN.5 455 This shows that the Assurance Requirements of the TOE matches the Assurance Requirements of the hardware. 7.10.3 Conclusion 456 No contradictions between the Security Targets of the TOE and the underlying hardware can be found. 7.11Assurance Measures 457 The documentation is produced compliant to the Common Criteria Version 3.1. The follo- wing documents provide the necessary information to fulfill the assurance requirements listed in section 6.2. Development ADV_ARC.1 Security Architecture Description TCOS eID_Card ADV_FSP.4 Functional Specification TCOS eID_Card ADV_IMP.1 Implementation of the TSF TCOS eID_Card ADV_TDS.3 Modular Design of TCOS eID_Card Guidance documents AGD_OPE.1 User Guidance TCOS eID_Card AGD_PRE.1 Administrator Guidance TCOS eID_Card Life-cycle support ALC_CMC.4, ALC_CMS.4 Documentation for Configuration Management ALC_DEL.1 Documentation for Delivery and Operation ALC_LCD.1 Life Cycle Model Documentation TCOS eID_Card ALC_TAT.1, ALC_DVS.2 Development Tools and Development Security for TCOS eID_Card Tests ATE_COV.2, ATE_DPT.2 Test Documentation for TCOS eID_Card ATE_FUN.1 Test Documentation of the Functional Testing Vulnerability assessment AVA_VAN.5 Independent Vulnerability Analysis TCOS eID_Card 458 The developer team uses a configuration management system that supports the generation of the TOE. The configuration management system is well documented and identifies all different configuration items. The configuration management tracks the im- plementation representation, design documentation, test documentation, user documen- tation, administrator documentation, and security flaws. The security of the configuration management is described in detail in a separate document. Security Target TCOS eID_Card/SLE78CLX1440P 119/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 459 The delivery process of the TOE is well defined and follows strict procedures. Several measures prevent the modification of the TOE based on the developer’s master copy and the user's version. The Administrator and the User are provided with necessary documentation for initialization and start-up of the TOE. 460 The implementation is based on an informal high-level and low-level design of the com- ponents of the TOE. The description is sufficient to generate the TOE without other de- sign requirements. 461 The tools used in the development environment are appropriate to protect the confiden- tiality and integrity of the TOE design and implementation. The development is controlled by a life-cycle model of the TOE. The development tools are well-defined and use semi- formal methods, i.e. a security model. 462 The development department is equipped with organizational and personnel means that are necessary to develop the TOE. The testing and the vulnerability analysis require technical and theoretical know-how available at T-Systems Enterprise Services GmbH. 463 As the evaluation is identified as a composite evaluation based on the CC evaluation of the hardware, the assurance measures related to the hardware (IC) will be provided by documents of the IC manufacturer. Security Target TCOS eID_Card/SLE78CLX1440P 120/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Appendix Glossary and Acronyms 464 This is the unchanged chapter from [IDCARDPP], more detailed information can be found there, too. Glossary Term Definition Accurate Terminal Certifi- cate A Terminal Certificate is accurate, if the issuing Document Verifier is trusted by the ID_Card’s chip to produce Terminal Certificates with the correct certificate effective date, see also [EACTR], sec. 2.2.5]. Advanced Electronic Signature according to the Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on “a Community framework for electronic signatures” a digital signature qualifies as an electronic signature, if it is: - 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. Agreement This term is used in order to reflect an appropriate relationship between the parties involved, but not as a legal notion. 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 ID_Card’s chip to store the Initialization Data and Pre-personalization Data. Authentication terminal (ATT) A technical system being operated and used either by a governmental organization (Official Domestic Document Verifier) or by any other, also commercial organization and (i) verifying the ID_Card presenter as the ID_Card holder (using the secret eID-PIN257 ), (ii) updating a subset of data of the eID application and (iii) activating the eSign application. See also [EACTR], chap. 3.2 and C.4. Authenticity Ability to confirm that the ID_Card itself and the data elements stored in were issued by the ID_Card Issuer Basic Access Control Security mechanism defined in [BACPP3.1] by which means the MRTD’s chip proves and the inspection system protects their communication by means of secure messaging with Document Basic Access Keys (see there) based on MRZ information as key seed and access condition to data stored on MRTD’s chip according to LDS. Basic Inspection System (BIS) A technical system being used by an authority258 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying correspondence between the stored and printed MRZ. BIS implements the terminal’s part of the Basic Access Control protocol and authenticates itself to the ID_Card using the Document Basic Access Keys drawn form printed MRZ data for reading the less-sensitive data (ID_Card document details data and biographical data) stored on the ID_Card (ePassport application only). See also [EACTR], chap. G.1 and H; also [ICAO9303-1]. Biographical data (biodata) The personalized details of the ID_Card holder appearing as text in the visual and machine readable zones of and electronically stored in the ID_Card. The biographical data are less- sensitive data. Biometric reference data Data stored for biometric authentication of the ID_Card holder in the ID_Card as (i) digital portrait and (ii) optional biometric reference data. Card Access Number (CAN) 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 Identification Card), semi-static (e.g. printed 257 the secret eID-PUK can be used for unblocking the eID-PIN and resetting the retry counter related 258 concretely, by a control officer Security Target TCOS eID_Card/SLE78CLX1440P 121/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Term Definition on a label on the Identification Card) or dynamic (randomly chosen by the electronic ID_Card and displayed by it using e.g. ePaper, OLED or similar technologies), see [EACTR], sec. 3.3 Card Security Object (SOC) A RFC 3369 CMS Signed Data Structure signed by the Document Signer (DS). It is stored in the ID_Card (EF.CardSecurity, see [EACTR], Table A.1 and sec. A.1.2) and carries the hash values of different Data Groups as defined in [EACTR], Appendix A. It shall also carry the Document Signer Certificate (CDS) [EACTR], A.1.2. Certificate chain Hierarchical sequence of Terminal Certificate (lowest level), Document Verifier Certificate and Country Verifying Certification Authority 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 Verifying Certification Authority Certificate is signed with the private key corresponding to the public key it contains (self-signed certificate). Certification Service Provider (CSP) An organization issuing certificates or providing other services related to electronic signatures. There can be CSP, who cannot issue qualified certicates (usually named ‘common’) or Qualified CSP, who issues qualified certificates. A CSP is the Certification Service Provider in the sense of [SSCDPP]. Counterfeit An unauthorized copy or reproduction of a genuine security document made by whatever means [ICAO9303-1]. Country Signing CertA Certificate (CCSCA) Certificate of the Country Signing Certification Authority Public Key (KPuCSCA) issued by Country Signing Certification Authority and stored in the rightful terminals. Country Signing Certification Authority (CSCA) An organization enforcing the policy of the ID_Card Issuer with respect to confirming correctness of user and TSF data stored in the ID_Card. The CSCA represents the country specific root of the PKI for the ID_Cards and creates the Document Signer Certificates within this PKI. The CSCA also issues the self-signed Country Signing CertA Certificate (CCSCA) having to be distributed by strictly secure diplomatic means, see [ICAO9303-1], 5.1.1. The Country Signing CertA issuing certificates for Document Signers (cf. [ICAO9303-1]) 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 [EACTR], sec. 2.2.1 Country Verifying Certification Authority (CVCA) An organization enforcing the privacy policy of the ID_Card Issuer with respect to protection of user data stored in the ID_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, ATT, SGT) and creates the Document Verifier Certificates within this PKI. The updates of the public key of the CVCA are distributed in form of CVCA Link-Certificates, see [EACTR], chap. 2.2.1. The CSCA issuing certificates for Document Signers (cf. [ICAO9303-1]) 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 [EACTR], sec. 2.2.1 CV Certificate Card Verifiable Certificate according to [EACTR], appendix C. Current date The maximum of the effective dates of valid CVCA, DV and domestic Inspection System certificates known to the TOE. It is used the validate card verifiable certificates. CVCA link Certificate Certificate of the new public key of the Country Verifying Certification Authority signed with the old public key of the Country Verifying Certification Authority where the certificate effective date for the new key is before the certificate expiration date of the certificate for the old key. Document Details Data Data printed on and electronically stored in the ID_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) A RFC3369 CMS Signed Data Structure, signed by the Document Signer (DS). Carries the hash values of the LDS Data Groups. It is stored in the ePassport application of the ID_Card. It may carry the Document Signer Certificate (CDS); see [ICAO9303-1] Document Signer (DS) An organization enforcing the policy of the CSCA and signing the ID_Card Security Object stored on the ID_Card for passive authentication. A Document Signer is authorized by the national CSCA issuing the Document Signer Certificate (CDS), see [EACTR], chap. 1.1 and [ICAO9303-1]. This role is usually delegated to the Personalization Agent. Document Verifier (DV) An organization (certification authority) enforcing the policies of the CVCA and of a service provider (governmental or commercial organization) and managing the 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, authorized by at least the national CVCA Security Target TCOS eID_Card/SLE78CLX1440P 122/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Term Definition to issue certificates for national terminals, see [EACTR], 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 ID_Card Issuer; a foreign DV is acting under a policy of the respective foreign CVCA (in this case there shall be an appropriate agreement between the ID_Card Issuer und a foreign CVCA ensuring enforcing the ID_Card Issuer’s privacy policy259 ). Eavesdropper A threat agent reading the communication between the ID_Card and the Service Provider to gain the data on the ID_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 for accessing official and commercial services, which require access to the user data stored in the context of this application. See [EACTR], sec. 3.1.2 Enrolment The process of collecting biometric samples from a person and the subsequent preparation and storage of biometric reference templates representing that person's identity. [ICAO9303-1] ePassport application A part of the TOE containing the non-executable, related user data (incl. 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 [EACTR], sec. 3.1.1. eSign application A part of the TOE containing the non-executable data needed for generating advanced or qualified electronic signatures on behalf of the ID_Card Holder as well as for authentication; this application is intended to be used in the context of official and commercial services, where an advanced or qualified digital signature of the ID_Card Holder is required. The eSign application is optional: it means that it can optionally be activated260 on the ID_Card by a Certification Service (or on his behalf) using the ATT with an appropriate authorization level. See [EACTR], sec. 3.1.3. Extended Access Control Security mechanism identified in [ICAO9303-1] by which means the MRTD’s chip (i) verifies the authentication of the inspection systems authorized to read the optional biometric reference data, (ii) controls the access to the optional biometric reference data and (iii) protects the confidentiality and integrity of the optional biometric reference data during their transmission to the inspection system by secure messaging. Extended Inspection System (EIS) See Inspection system Forgery Fraudulent alteration of any part of the genuine document, e.g. changes to the biographical data or portrait. [ICAO9303-1] Global Interoperability The capability of inspection systems (either manual or automated) in different States throughout the world to exchange data, to process data received from systems in other States, and to utilize that data in inspection operations in their respective States. Global interoperability is a major objective of the standardized specifications for placement of both eye-readable and machine readable data in all MRTDs. [ICAO9303-1] 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 phases. IC Embedded Software Software embedded in an IC and not being designed by the IC developer. The IC Embedded Software is designed in the design life phase and embedded into the IC in the manufacturing life phase of the TOE. ID_Card (electronic) The contactless smart card integrated into the plastic, optical readable cover and providing the following applications: ePassport, eID and eSign (optionally) ID_Card holder The rightful/legitimated holder of the electronic ID Card for whom the issuing authority personalized the ID Card. ID_Card Issuer (issuing authority) Organization authorized to issue an electronic Identity Card to the ID_Card holder 259 Existing of such an agreement may be technically reflected by means of issuing a CCVCA-F for the Public Key of the foreign CVCA signed by the domestic CVCA. 260 ‘activated’ means (i) generate and store in the eSign application one or more signature key pairs and (ii) optionally store there the related certificates Security Target TCOS eID_Card/SLE78CLX1440P 123/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Term Definition ID_Card presenter A person presenting the ID_Card to a terminal and claiming the identity of the ID_Card holder. Identity Card (physical and electronic) An optically and electronically readable document in form of a paper/plastic cover and an integrated smart card. The Identity Card is used in order to verify that identity claimed by the Identity Card presenter is commensurate with the identity of the Identity Card holder stored on/in the card. 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. [ICAO9303-1] Improperly documented person A person who travels, or attempts to travel with: (a) an expired travel document or an invalid visa; (b) a counterfeit, forged or altered travel document or visa; (c) someone else’s travel document or visa; or (d) no travel document or visa, if required. [ICAO9303-1] Initialisation Data Any data defined by the ID_Card manufacturer and injected into the non-volatile memory by the Integrated Circuits manufacturer. These data are, for instance, used for traceability and for IC identification as IC_Card material (IC identification data). Inspection The act of an authority examining an ID_Card presented to it by an ID_Card presenter and verifying its authenticity as the ID_Card holder. See also [ICAO9303-1]. Inspection system (EIS) A technical system being used by an authority261 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying the ID_Card presenter as the ID_Card holder (for ePassport: by comparing the real biometrical data of the ID_Card presenter with the stored biometrical data of the ID_Card holder). The specification [EACTR], sec. 3.2 (and C.4) knows only one type of the inspection system, namely according to the result of the terminal authentication in the context of the Extended Access Control. It means that the Inspection System in the context of [EACTR], (and of the PP IDCARDPP) is commensurate with the Extended Inspection System (EIS) as defined in [EACPP3.1]262 . Integrated circuit (IC) Electronic component(s) designed to perform processing and/or memory functions. The ID_Card’s chip is an integrated circuit. Integrity Ability to confirm the ID_Card and its data elements stored upon have not been altered from that created by the ID_Card Issuer. Issuing Organization Organization authorized to issue an official travel document (e.g. the United Nations Organization, issuer of the Laissez-passer). [ICAO9303-1] Issuing State The Country issuing the MRTD. [ICAO9303-1] Logical Data Structure (LDS) The collection of groupings of Data Elements stored in the optional capacity expansion technology [ICAO9303-1]. The capacity expansion technology used is the MRTD’s chip. Machine readable travel document (MRTD) Official document issued by a State or Organization 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. [ICAO9303-1] Machine readable zone (MRZ) Fixed dimensional area located on the front of the MRTD or MRP Data Page or, in the case of the TD1, the back of the MRTD, containing mandatory and optional data for machine reading using OCR methods. [ICAO9303-1] The MRZ-Password is a secret key that is derived from the machine readable zone and may be used for both PACE and BAC. Machine-verifiable biometrics feature A unique physical personal identification feature (e.g. an iris pattern, fingerprint or facial characteristics) stored on a travel document in a form that can be read and verified by machine. [ICAO9303-1] Malicious equipment A technical device does 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 ID_Card). Manufacturer The generic term for the IC Manufacturer producing the integrated circuit and the ID_Card 261 concretely, by a control officer 262 please note that an Extended Inspection System also covers the General Inspection Systems (GIS) in the sense of [EACPP3.1] Security Target TCOS eID_Card/SLE78CLX1440P 124/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Term Definition Manufacturer completing the IC to the ID_Card. The Manufacturer is the default user of the TOE during the manufacturing life phase. The TOE itself does not distinguish between the IC Manufacturer and ID_Card Manufacturer using this role Manufacturer. Metadata of a CV Certificate Data within the certificate body (excepting Public Key) as described in [EACTR], sec. C.1.3. The metadata of a CV certificate comprise the following elements: - Certificate Profile Identifier, - Certificate Authority Reference, - Certificate Holder Reference, - Certificate Holder Authorisation Template, - Certificate Effective Date, - Certificate Expiration Date, - Certificate Extensions (optional). PACE Terminal (PCT) A technical system verifying correspondence between the stored password and the related value presented to the terminal. PCT implements the terminal’s part of the PACE protocol and authenticates itself to the ID_Card using a shared password (CAN, eID-PIN, eID-PUK or MRZ). The PCT is not allowed reading User Data (see sec. 4.2.2 in [EACTR]). See [EACTR], chap. 3.3, 4.2, table 1.2 and G.2. Passive authentication Security mechanism implementing (i) verification of the digital signature of the Card (Document) Security Object and (ii) comparing the hash values of the read data fields with the hash values contained in the Card (Document) Security Object. See [EACTR], sec. 1.1. Password Authenticated Connection Establishment (PACE) A communication establishment protocol defined in [EACTR], sec. 4.2. The PACE Protocol is a password authenticated Diffie-Hellman key agreement protocol providing implicit password- based authentication of the 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 password π). Based on this authentication, PACE also 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 ID_Card holder. PIN is a blocking password, see [EACTR], sec. 3.3 Personalization The process by which the individual-related data (biographic and biometric data, signature key pair(s) for the eSign application) of the ID_Card holder are stored in and unambiguously, inseparably associated with the ID_Card. Personalization Agent An organization acting on behalf of the ID_Card Issuer to personalize the ID_Card for the ID_Card holder by some or all of the following activities: (i) establishing the identity of the ID_Card holder for the biographic data in the ID_Card263 , (ii) enrolling the biometric reference data of the ID_Card holder264 , (iii) writing a subset of these data on the physical Identification Card (optical personalization) and storing them in the ID_Card (electronic personalization) for the ID_Card holder as defined in [EACTR], (iv) writing the document details data, (v) writing the initial TSF data, (vi) signing the Card Security Object defined in [ICAO9303-1] (in the role of DS). A Personalization Agent acts, amongst other, as the Document Signer (item (vi) of his tasks). Generating signature key pair(s) is not in the scope of the tasks of this role, but the Personali- zation Agent may support a CSP actions providing Personalization Data to the CSP. PIN Unblock Key (PUK) A long secret password being only known to the ID_Card holder. The PUK is a non-blocking password, see [EACTR], sec. 3.3 Pre-personalization Data Any data that is injected into the non-volatile memory of the TOE by the Manufacturer for traceability of the non-personalized ID_Card and/or to secure shipment within or between the life cycle phases manufacturing and card issuing. Pre-personalized ID_Card’s chip ID_Card’s chip equipped with a unique identifier and a unique asymmetric Authentication Key Pair of the chip. Receiving State The Country to which the ID_Card holder is applying for entry. [ICAO9303-1] 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. 263 relevant for the ePassport, the eID and the eSign applications 264 relevant for the ePassport application Security Target TCOS eID_Card/SLE78CLX1440P 125/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Term Definition Remote terminal A remote device directly communicating with the TOE and using the 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 [EACTR], sec. 3.4.1 Restricted Identification Restricted Identification aims providing a temporary ID_Card identifier being specific for a terminal sector (pseudo-anonymization) and supporting revocation features (sec. 2.3, 4.1.2, 4.5 of [EACTR]. The security status of ID_Card is not affected by Restricted Identification. Rightful equipment (rightful terminal or rightful ID_Card) A technical device 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 or ATT or SGT. A terminal as well as an ID_Card can represent the rightful equipment, whereby the root CertA for a terminal is CVCA and for an ID_Card – CSCA. Secondary image A repeat image of the holder’s portrait reproduced elsewhere in the document by whatever means. [ICAO9303-1] Secure messaging in combined mode Secure messaging using encryption and message authentication code according to ISO/IEC 7816-4 Service Provider An official or commercial organization providing services which can be used by the ID_Card holder. Service Provider uses the rightful terminals managed by a DV. Signature terminal (SGT) A technical system being used for generation of digital signatures. See [EACTR], chap. 3.2 and C.4. It is equivalent – as a general term – to SCA and HID as defined in [SSCDPP]. Skimming Imitation of a rightful terminal to read the ID_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. Terminal A technical system communicating with the TOE through the contactless interface. The role ‘Terminal’ is the default role for any terminal being recognized by the TOE as neither PCT nor EIS nor ATT nor SGT (‘Terminal’ is used by the ID_Card presenter). Terminal Authorization Level Intersection of the Certificate Holder Authorizations defined by the Terminal Certificate, the Document Verifier Certificate and Country Verifying Certification Authority which shall be all valid for the Current Date. TOE tracing data Technical information about the current and previous locations of the ID_Card gathered by inconspicuous (for the ID_Card holder) recognizing the ID_Card Travel document A passport or other official document of identity issued by a State or Organization which may be used by the rightful holder for international travel [ICAO9303-1]. TSF data Data created by and for the TOE that might affect the operation of the TOE (CC part 1 [CC]). Unpersonalized ID_Card ID_Card material prepared to produce a personalized ID_Card containing an initialized and pre-personalized ID_Card’s chip. User Data All data (being not authentication data) stored in the context of the applications of the ID_Card as defined in [EACTR] and 1. being allowed to be read out or written solely by an authenticated terminal (in the sense of [EACTR], sec. 3.2) respectively 2. being allowed to be used solely by an authenticated terminal (in the sense of [EACTR, sec. 3.2]) (the private Restricted Identification key; since the Restricted Identification according to [EACTR, sec. 4.5] represents just a functionality of the ID_Card, the key material needed for this functionality and stored in the TOE is considered here as ‘user data’) re- spectively 3. being allowed to be used solely by the authenticated ID_Card holder (the private signature key within the eSign application); from this point of view, the private signature key of the ID_Card holder is also considered as ‘user data’. CC give the following generic definitions for user data: Data created by and for the user that does not affect the operation of the TSF (CC part 1 [CC]). Information stored in TOE resources that can be operated upon by users in accordance with the SFRs and upon which the TSF places no special meaning (CC part 2 [CC]). Verification data Data provided by an entity in an authentication attempt to prove their identity to the verifier. The verifier checks whether the verification data match the reference data known for the claimed identity. Security Target TCOS eID_Card/SLE78CLX1440P 126/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Acronyms Acronym Term ATT Authentication Terminal as defined in [EACTR], sec. 3.2 BAC Basic Access Control BIS Basic Inspection System CA Chip Authentication CAN Card Access Number CC Common Criteria CertA Certification Authority (the PP author decided not to use the usual abbreviation ‘CA’ in order to avoid a collision with ‘Chip Authentication’) DTBS Data to be signed, please refer to [SSCDPP] EAC Extended Access Control EIS Extended Inspection System (equivalent to the Inspection Systems as defined in [EACTR], sec. 3.2) MRZ Machine readable zone n.a. Not applicable OSP Organizational 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 [SSCDPP] RF Radio Frequency SAR Security assurance requirements SCA Signature creation application, please refer to [SSCDPP]. It is equivalent to SGT in the current context. SCD Signature Creation Data, please refer to [SSCDPP]; the term ‘private signature key within the eSign application’ is synonym. SGT Signature Terminal as defined in [EACTR], sec. 3.2 SVD Signature Verification Data, please refer to [SSCDPP] TA Terminal Authentication TOE Target of Evaluation TSF TOE security functions TSP TOE Security Policy (defined by the current document) VAD Verification Authentication Data, please refer to [SSCDPP] Security Target TCOS eID_Card/SLE78CLX1440P 127/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 References [AIS31] Bundesamt für Sicherheit in der Informationstechnik, Anwendungshinweise und Interpre- tationen zum Schema (AIS), AIS 31, Version 1 vom 25.09.2001, Bundesamt für Sicherheit in der Informationstechnik (BSI) [AIS36] Bundesamt für Sicherheit in der Informationstechnik, Anwendungshinweise und Interpre- tationen zum Schema (AIS), AIS 36, Version 2 vom 12.11.2007, Bundesamt für Sicherheit in der Informationstechnik (BSI) [ALGO] Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signatur- verordnung (Übersicht über geeignete Algorithmen), Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen, 30.12.2011, Veröffentlicht am 18.01.2012 im Bundesanzeiger Nr. 10, S. 243 [BACPP3.1] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Basic Access Control, Version 1.10, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0055-2009, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2009-03-25 [CC] Common Criteria for Information Technology Security Evaluation, Version 3.1, Part 1: Introduction and General Model; Version 3.1, July 2009, CCMB-2009-07-001, Part 2: Security Functional Requirements; Version 3.1, July 2009, CCMB-2009-07-002, Part 3: Security Assurance Requirements; Version 3.1, July 2009, CCMB-2009-07-003 Common Methodology for Information Technology Security Evaluation, Evaluation Metho- dology, Version 3.1, Revision 3, July 2009, CCMB-2009-07-004 [EACPP3.1] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Exten- ded Access Control, Version 1.10, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0056-2009, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2009-03-25 [EACTR] Technical Guideline TR-03110: Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), Password Authenticated Connec- tion Establishment (PACE), and Restricted Identification (RI), Version 2.02, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2009-11-09 [EACTR2.10] Technical Guideline TR-03110: Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), Password Authenticated Connec- tion Establishment (PACE), and Restricted Identification (RI), Version 2.10, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2010-10-14 [ECARDTR] Technische Richtlinie TR-03116-2 für die eCard-Projekte der Bundesregierung Teil 2 – Security Target TCOS eID_Card/SLE78CLX1440P 128/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 Hoheitliche Ausweisdokumente, Stand 2011, Bundesamt für Sicherheit in der Informa- tionstechnik (BSI), 2011-08-24 [ECCTR] Technical Guideline TR-03111: Elliptic Curve Cryptography, Version 2.0, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2012-06-28 [FIPS180] Federal Information Processing Standards Publication FIPS PUB 180-4, Specifications for the Secure Hash Standard (SHS), March 2012 [FIPS186] Federal Information Processing Standards Publication FIPS PUB 186-3, Digital Signature Standard (DSS), June 2009 [FIPS197] Federal Information Processing Standards Publication 197, Advanced Encryption Stan- dard (AES), U.S. Department of Commerce/National Institute of Standards and Techno- logy, 2001-11-26 [HWCR] Certification Report of the underlying hardware platform BSI-DSZ-CC-0813-2012 for Infineon smart card IC (Security Controller) M7820 A11, Bun- desamt für Sicherheit in der Informationstechnik (BSI), 2012-06 [HWST] Security Target of the underlying hardware platform Security Target M7820 A11, Version 1.5, Infineon Technologies AG, Chipcard and Securi- ty, Evaluation Documentation, 2012-05 [ICAO9303-1] 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 [IDCARDPP] CC Protection Profile: Electronic Identity Card (ID_Card PP), Version 1.03, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP- 0061-2009, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2009-12-15 [ISO7816] ISO 7816-4:2005, Identification cards – Integrated circuit(s) cards with contacts, Part 4: Organization, security and commands for interchange, ISO, 2008-10-03 [ISO14443] ISO 14443, Identification cards – Contactless integrated circuit(s) cards – Proximity cards, 2000 [PP0035] Security IC Platform Protection Profile, Version 1.0, Registered and Certified by Bundes- amt für Sicherheit in der Informationstechnik under BSI-CC-PP-0035-2007, 2007-06-15 [RFC5639] M. Lochter, J. Merkle, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, RFC 5639, IETF, 2010-03 Security Target TCOS eID_Card/SLE78CLX1440P 129/129 Specification of the Security Target TCOS Identity Card Version 1.0 Release 2 Version: 1.0.2 Stand: 2012-07-12 T-Systems International GmbH, 2010 [SP800-38B] Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentica- tion, NIST Special Publication 800-38B, National Institute of Standards and Technology, May 2005 [SSCDPP] Protection Profiles for Secure Signature Creation Device – Part 2: Device with Key Gene- ration, EN 14169-1:2009, ver. 1.03, CEN/TC 224, Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0059-2009, 2009-12-11 [TCOSADM] Administrator Handbuch TCOS Identity Card Version 1.0 Release 2, T-Systems Interna- tional GmbH, 2012-07