Dokumentenkennung: CD.TCOS.ASE Dateiname: 729 TCOS Residence Permit Card Version 1.0 Release 1.doc Stand: 16.08.2011 Version: 1.0.1 Hardware Basis: SLE78CLX1440P Autor: Ernst-G. Giessmann Geltungsbereich: TeleSec Entwicklungsgruppe Vertraulichkeitsstufe: Öffentlich     T-Systems International GmbH, 2011 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 Residence Permit Card Version 1.0 Release 1/SLE78CLX1440P Version: 1.0.1/20110816 Security Target TCOS Residence Permit Card/SLE78CLX1440P 2/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 History Version Date Remark 1.0.1 2011-08-16 Final Document Security Target TCOS Residence Permit Card/SLE78CLX1440P 3/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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............................................................................................... 11 1.4.5 TOE Boundaries................................................................................................................ 13 2 Conformance Claim.............................................................................................................. 15 2.1 CC Conformance Claims........................................................................................................ 15 2.2 PP Claims............................................................................................................................... 15 2.3 Package Claims...................................................................................................................... 16 2.4 Conformance Rationale.......................................................................................................... 16 3 Security Problem Definition ................................................................................................ 17 3.1 Introduction............................................................................................................................. 17 3.2 Threats ................................................................................................................................... 23 3.3 Organizational Security Policies............................................................................................. 27 3.4 Assumptions........................................................................................................................... 31 4 Security Objectives .............................................................................................................. 34 4.1 Security Objectives for the TOE............................................................................................. 34 4.2 Security Objectives for the Operational Environment ............................................................ 38 4.3 Security Objective Rationale .................................................................................................. 43 5 Extended Components Definition....................................................................................... 45 5.1 FAU_SAS Audit data storage................................................................................................. 45 5.2 FCS_RND Generation of random numbers ........................................................................... 45 5.3 FIA_API Authentication Proof of Identity................................................................................ 46 5.4 FIA_APO Authentication Proof of Origin ................................................................................ 47 5.5 FMT_LIM Limited capabilities and availability........................................................................ 47 5.6 FPT_EMSEC TOE Emanation ............................................................................................... 48 6 Security Requirements ........................................................................................................ 50 6.1 Security Functional Requirements for the TOE...................................................................... 51 6.1.1 Overview............................................................................................................................ 51 6.1.2 Class FCS Cryptographic Support .................................................................................... 54 6.1.3 Class FIA Identification and Authentication....................................................................... 63 6.1.4 Class FDP User Data Protection....................................................................................... 76 6.1.5 Class FTP Trusted Path/Channels.................................................................................... 84 6.1.6 Class FAU Security Audit.................................................................................................. 86 6.1.7 Class FMT Security Management..................................................................................... 87 Security Target TCOS Residence Permit Card/SLE78CLX1440P 4/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 6.1.8 Class FPT Protection of the Security Functions.............................................................. 100 6.2 Security Assurance Requirements for the TOE ................................................................... 104 6.3 Security Requirements Rationale......................................................................................... 104 6.3.1 Security Functional Requirements Rationale.................................................................. 104 6.3.2 Rationale for SFR’s Dependencies ................................................................................. 113 6.3.3 Security Assurance Requirements Rationale.................................................................. 117 6.3.4 Security Requirements – Internal Consistency ............................................................... 118 7 TOE Summary Specification ............................................................................................. 119 7.1 Access control to the User Data stored in the TOE ............................................................. 119 7.2 Secure data exchange ......................................................................................................... 119 7.3 Identification and authentication of users and components ................................................. 120 7.4 Audit ..................................................................................................................................... 120 7.5 Generation of the eSign Signature Key Pair ........................................................................ 121 7.6 Creation of Digital Signatures............................................................................................... 121 7.7 Management of and access to TSF and TSF-data .............................................................. 121 7.8 Reliability of the TOE security functionality.......................................................................... 122 7.9 TOE SFR Statements........................................................................................................... 122 7.10 Statement of Compatibility ................................................................................................... 129 7.10.1 Relevance of Hardware TSFs ......................................................................................... 129 7.10.2 Compatibility: TOE Security Environment....................................................................... 129 7.10.3 Conclusion....................................................................................................................... 137 7.11 Assurance Measures............................................................................................................ 137 Appendix Glossary and Acronyms.................................................................................................. 139 References.......................................................................................................................................... 146 Security Target TCOS Residence Permit Card/SLE78CLX1440P 5/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 Residence Permit Card Version 1.0 Release 1/SLE78CLX1440P TOE: TCOS Residence Permit Card Version 1.0 Release 1/SLE78CLX1440P Sponsor: T-Systems International GmbH Editor(s): Ernst-G. Giessmann, T-Systems International GmbH,TeleSec CC Version: 3.1 (Revision 3) Assurance Level: EAL4 augmented. General Status: Final Document Version Number: 1.0.1 Date: 2011-08-16 Certification ID: BSI-DSZ-CC-729 Keywords: Residence Permit Card, eID, eSign, ePass, MRTD, PACE, EAC 3 The TOE is a ready for Personalization contact-less chip with an initialized filesystem according to [RPCARDPP] based like the TCOS Identity Cards on the Operation System TCOS developed at T-Systems International GmbH. 1.2 TOE Reference 4 The Security Target refers to the Product “TCOS Residence Permit Card Version 1.0 Release 1” (TOE) of T-Systems International GmbH for CC evaluation. 1.3 TOE Overview 5 The Target of Evaluation (TOE) addressed by the current Security Target is the elec- tronic Residence Permit Card (RP_Card) representing a contactless smart card programmed according1 to the Technical Guideline TR-03110 ([EACTR]) and being compliant to EU – Residence Permit Specification [EURPS]. For CC evaluation the follo- wing applications of corresponding product will be considered: 1 Note that the TOE fulfills the stronger requirements of the Version 2.05 of the Technical Guideline TR-03110, whereas the Protection Profile is based on the Version 2.03 ([EACTR2.03]) only. Security Target TCOS Residence Permit Card/SLE78CLX1440P 6/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 the Passport Application2 (ePassport) containing the related user data3 (incl. biometric data) as well as the data needed for authenti- cation (incl. MRZ); this application the TOE is intended to be used by authorities, amongst other as a machine readable travel document (MRTD); the eID-Application4 including the related user data5 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 Application6 containing data needed for generating qualified electronic signatures on behalf of the RP_Card holder as well as for user authentication; this application is intended to be used in the context of official and commercial services, where a qualified electronic signature of the RP_Card holder is re- quired. The eSign application is optional: it means that it can optionally be activated on the RP_Card by a Certifica- tion Service Provider Issuer (or on his behalf) authorized by the RP_Card Issuer. 6 According to the Technical Guideline TR-03110 (cf. [EACTR, 3.1.1]) the ePassport App- lication supports Passive Authentication, Password Authenticated Connection Establish- ment (PACE) with CAN and MRZ as part of the Standard and General Inspection Proce- dure, Terminal and Chip Authentication Version 2 as required in the General Inspection Procedure and also Basic Access Control (BAC), which is considered in this ST only as part of Extended Access Control (EAC) with Chip and Terminal Authentication Version 1. 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 RP_Card holder can control the access to his user data by conscious presenting his RP_Card to authorities7 (CAN or MRZ authentication as specified in [EACTR, 3.3]). 9 For the eID-application, the RP_Card holder can control the access to his user data by inputting his secret PIN (eID-PIN) or by conscious presenting his RP_Card to the authorities8. 10 For the eSign application, the RP_Card holder can control the access to the digital sig- nature functionality by conscious presenting his RP_Card to a Service Provider and using his secret Verification Authentication Data for this application: eSign-PIN9. 2 as specified in [EACTR, sec. 3.1.1], see also [ICAO9303-1] 3 according to [EACTR, sec. 3.1.1, sec. 3.1.1]; see also Glossary below for definitions 4 as specified in [EACTR, sec. 3.1.2] 5 according to [EACTR, sec. 3.1.2] 6 as specified in [EACTR, sec. 3.1.3] 7 CAN or MRZ user authentication, see [EACTR, sec. 3.3] 8 eID-PIN or CAN user authentication, see [EACTR, sec. 3.3] Security Target TCOS Residence Permit Card/SLE78CLX1440P 7/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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, since qualified electronic signatures will be gene- rated by the eSign application. For security reasons this will not be enforced by the TOE. 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 RP_Card issuer according to the Organizational Security Policies [RPCARDPP]. The TOE supports the standardized domain parameters mentioned in [ECARDTR, section 1.3.2] and the NIST P-256 curve mentioned in [EACTR, A.2.1.1] including the corres- ponding hash functions. PACE and hence the General Inspection Procedure require the use of AES, whereas due to compatibility reasons the Advanced Inspection Procedure with BAC may be used with 3DES (cf. [EACTR, A.2.3.1 and A.2.4.1]). This depends on the Initialization of the TOE. A more detailed description in given in the Administrator Guidance [TCOSADM] 13 The RP_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 may be relevant, and if so, the TOE will be identified in more detail as "TCOS Residence Permit Card Version 1.0 Release 1/SLE78CLX1440P", otherwise the notion "TCOS Residence Permit Card Version 1.0 Release 1" 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 compa- tibility of the Life Cycle Model of the Protection Profile [RPCARDPP] 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, optionally10 the eSign applications and • the associated guidance documentation 9 CAN and eSign-PIN (VAD as specified in [SSCDPP, 3.2.3.5]).), user authentication, see [EACTR, sec. 3.3] 10 activated or not yet activated on the RP_Card Security Target TCOS Residence Permit Card/SLE78CLX1440P 8/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 docu- ments. 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. 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 RP_Card under control of the RP_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 RP_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 ISO Stan- dard ISO14443. 22 From the logical point of view, the TOE is able to distinguish between the following termi- nal 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 RP_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, the related Inspection or Authentication Procedures must be used. Security Target TCOS Residence Permit Card/SLE78CLX1440P 9/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 24 The TOE supports the usage of EIS-GAP11, BIS-PACE12 (due to compliance with [PACEPassPP], see sec. PP Claims) and EIS-AIP-BAC13 (due to compliance with [EURPS] and, hence, with [EACPP3.1], see sec. PP Claims) types of inspection systems as well as of authentication and signature terminals unconditionally using General Au- thentication Procedure (GAP). GAP offers the most functionality according to [EACTR] and the most extended protection of assets in the sense of the PP ([RPCARDPP]). 25 Using other types of inspection systems (e.g. BIS-BAC14) is out of the scope of the PP ([RPCARDPP]). Nevertheless the contained therein conformance claims require the TOE to fulfill the BAC PP [BACPP3.1]. These requirements are out of the scope of the current ST. 26 Since the inherent security properties of BAC protocol cannot withstand some attack scenarios with a high attack potential, the related threats are considered not to be allied with using EIS-AIP-BAC. Organizations being responsible for the operation of inspection systems (CVCAs and DVs) shall be aware of this context. 27 A [EACTR]-compliant terminal shall always start a communication session using PACE. If successfully, it shall then try to proceed with terminal and chip authentications as required by GAP in [EACTR]. The terminal will be authorized (depending on its certifi- cate) as the EIS-GAP in the sense of [EACTR]. If the trial with PACE and GAP failed, the [EACTR]-compliant terminal may try to establish a communication session using other valid options as described above. 28 After the General Authentication Procedure has successfully been performed, the au- thenticated terminal can request for a sector-specific chip-identifier (Restricted Identifi- cation, see [EACTR, sec. 2.1.5, 2.4, 4.5]). Restricted Identification aims providing a tem- porary RP_Card identifier being specific for a terminal sector (pseudo-anonymization) and supporting revocation features ([EACTR, sec. 2.4, 4.1.1.1]). The security status of RP_Card is not affected by Restricted Identification. 29 Concerning terminals for the eSign application, the parallels with the terminals as defi- ned in [SSCDPP] are as follows: the Authentication Terminal in the context of [EACTR] (and of the current ST) is CGA in [SSCDPP]; the Signature Terminal in the context of [EACTR] represents a combination of SCA and HID in [SSCDPP]. 30 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 Veri- fying Certification Authority (CVCA) Link Certificates, Document Verifiers Certificates and Terminal Certificates – shall be available in a card verifiable format as specified in [EACTR, Appendix C.1 and sec. 2.2.3.]. 31 The following table gives an overview which types of terminals shall be supported for which single application of the TOE, see [ICAO9303-1, sec. 3.1 – 3.4] (please note that 11 EIS-GAP means General Authentication Procedure (GAP), i.e. PACE, terminal authentication (version 2), passive authentication with SOC and chip authentication (version 2) with an Extended Inspection System (EIS) 12 BIS-PACE means Standard Inspection Procedure (SIP) with PACE, i.e. PACE and passive au- thentication with SOD with a Basic Inspection System (BIS) 13 EIS-AIP-BAC means Advanced Inspection Procedure (AIP) with BAC, i.e. BAC, chip authentica- tion, passive authentication with SOD and terminal authentication (version 1) with an Extended In- spection System (EIS) 14 BIS-BAC means BAC and passive authentication with SOD with an Basic Inspection System (BIS) Security Target TCOS Residence Permit Card/SLE78CLX1440P 10/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 the effective ability of a terminal depends on its terminal authorization level finally deri- ved from the presented certificate chain as stated above). Basic Inspec- tion System using SIP with PACE (BIS- PACE, official terminal) Extended In- spection System using AIP with BAC (EIS-AIP-BAC, official terminal) Extended In- spection System using GAP (EIS-GAP, official terminal) Authentication Terminal (official or commercial terminal) Signature Terminal ePassport Operations: reading all Data Groups except DG3 and DG4 User Interaction: CAN or MRZ for PACE Operations: reading only DG3 and DG4 and optional DG5 – DG13 User Interaction: MRZ for BAC Operations: reading all Data Groups (incl. biometric ones) User Interaction: CAN or MRZ for PACE No operations No Operations eID No operations No operations Operations: reading all Data Groups User Interaction: CAN for PACE Operations: writing a subset of Data Groups, reading all or a subset of Data Groups User Interaction: eID- PIN, eID-PUK or CAN for PACE No Operations eSign No Operations No Operations No Operations Operations: activating eSign application User Interaction: eID-PIN, eID- PUK or CAN for PACE In this context the terminal is equivalent the CGA in [SSCDPP] and implements the corresponding HID. Operations: generating digi- tal signatures15 User Interaction: CAN for PACE, theneSign-PIN through the HID to access the signature function In this context the terminal is equivalent to the SCA in [SSCDPP] and may implement the correspon- ding HID 15 the TOE generates digital signature values, which support qualified electronic signatures Security Target TCOS Residence Permit Card/SLE78CLX1440P 11/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 1.4.4 Life Cycle Phases Mapping 32 Following the protection profile PP0035 [PP0035, sec. 1.2.3] the life cycle phases of a TCOS RP_Card device can be divided into the following seven phases: Phase 1: IC Embedded Software Development Phase 2: IC Development Phase 3: IC Manufacturing Phase 4: IC Packaging Phase 5: Composite Product Integration Phase 6: Personalization Phase 7: Operational Use 33 According to the PP [RPCARDPP] the TOE life cycle is described in terms of the four life cycle phases. Life cycle phase 1 “Development” 34 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. 35 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 asso- ciated with these TOE components. 36 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 pro- grammable memories (EEPROM), the RP_Card application and the guidance docu- mentation is securely delivered to the RP_Card manufacturer. 37 This life cycle phase 1 covers Phase 1 and Phase 2 of [PP0035]. Life cycle phase 2 “Manufacturing” 38 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 RP_Card material during the IC manufacturing and the delivery process to the RP_Card manufacturer. The IC is securely delivered from the IC manufacturer to the RP_Card manufacturer (note that both of these roles may be assigned to different entities). 39 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. 40 The RP_Card manufacturer (i) add the parts of the IC Embedded Software in the non-volatile programmable memories (for instance EEPROM) if necessary, Security Target TCOS Residence Permit Card/SLE78CLX1440P 12/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 (ii) creates the ePassport, the eID and the eSign application, (iii) equips TOE’s chip with Pre-personalization Data and (iv) packs the IC with hardware for the contactless interface in the RP_Card. 41 The pre-personalized RP_Card together with the IC Identifier is securely delivered from the RP_Card manufacturer to the Personalization Agent. The RP_Card manufacturer also provides the relevant parts of the guidance documentation to the Personalization Agent. 42 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. 43 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 RP_Card holder by the CSP. Note that the TOE has no contact interface. The eSign Application can be used through the contactless interface only. 44 For the TOE one pre-configured version (FSV81) of the file system applies. A detailed description of the sub-phases and the file system pre-configurations, including the assig- ned maximal available memory sizes can be found in the Administrator Guidance [TCOSADM]. 45 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” 46 The personalization of the RP_Card includes (i) the survey of the RP_Card holder biographical data, (ii) the enrolment of the RP_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 RP_Card, (iv) the writing of TOE User Data and TSF Data into the logical RP_Card and (v) configuration of the TSF if necessary (not applicable for the TOE). Security Target TCOS Residence Permit Card/SLE78CLX1440P 13/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 47 The step (iv) is performed by the Personalization Agent. 48 The personalized RP_Card (together with appropriate guidance for TOE use if necessa- ry) is handed over to the RP_Card holder for operational use. 49 This life cycle phase corresponds to the remaining initialization and personalization pro- cesses not covered yet from Phase 6 of the [PP0035]. 50 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 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” 51 The TOE is used as RP_Card’s chip by the RP_Card holder and the terminals in the “Operational Use” phase. 52 This life cycle phase corresponds to the Phase 7 of the [PP0035]. 53 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 RP_Card holder identified by the authorized terminal. Therefore no further Personalization procedure is required in Phase 7 (Operational Use). 54 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 55 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. 56 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. 57 The physical constituents of the TOE are the operating system, the data in elementary files of the dedicated file of the ICAO application (EEPROM), and temporary data used during execution of procedures associated to that dedicated file. 1.4.5.2 TOE Logical Boundaries 58 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. Security Target TCOS Residence Permit Card/SLE78CLX1440P 14/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 59 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). 60 The output octet string from the TOE has the structure of a Response Application Protocol Data Unit (RAPDU). 61 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 Residence Permit Card/SLE78CLX1440P 15/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 2 Conformance Claim 2.1 CC Conformance Claims 62 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 63 as follows: Part 2 extended, Part 3 conformant. 64 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 65 This ST claims strict conformance to ‘Common Criteria Protection Profile Electronic Residence Permit Card (RP_Card PP) [RPCARDPP]. This includes the following conformance claims. 66 This ST claims strict conformance to ‘Common Criteria Protection Profile Machine Readable Travel Document with „ICAO Application", Extended Access Control, BSI-CC- PP-0056-2009, version 1.10, 25th March 2009’ [EACPP3.1]. 67 The conformance claim above covers the part of the security policy for the ePassport application of the TOE corresponding to the security policy defined in [EACPP3.1]. This conformance claim is a requirement of [EURPS, sec. 6.3] and, in such a way, enforces support of the EIS-AIP-BAC type of inspection system by the TOE. 68 This ST claims strict conformance to ‘Common Criteria Protection Profile Electronic Passport using Standard Inspection Procedure with PACE, BSI-CC-PP-0068-2010, version 0.92, 30th April 2010’ [PACEPassPP]. 69 The conformance claim above covers the part of the security policy for the ePassport application of the TOE corresponding to the security policy defined in [PACEPassPP]. This conformance claim enforces support of the BIS-PACE type of inspection system by the TOE. 70 This ST claims strict conformance to the CC Protection Profile Secure Signature Creation Device – Part 2: Device with key generation, Version 1.03, BSI-CC-PP-0059- 2009 [SSCDPP]. Security Target TCOS Residence Permit Card/SLE78CLX1440P 16/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 71 The last conformance claim covers the part of the security policy for the eSign application of the TOE corresponding to the security policy defined in [SSCDPP] and, hence, is applicable, if the eSign application is operational. In addition to [SSCDPP], the current ST specifies authentication and communication protocols (GAP) having to be used for the eSign application of the TOE. These protocols contribute to securing SVD- export, DTBS-import and VAD-import functionality. 72 The eSign application of the TOE is intended to support qualified electronic signatures. The main specific property distinguishing qualified electronic signatures from others is that they base on qualified certificates and are created by secure signature creation devices (SSCD) as the TOE represents. Since the current TOE (its part the eSign appli- cation) shall be used as SSCD due to the PP conformance claim above, the only specific difference remained is using qualified certificates for qualified signatures. Whether a certificate is qualified or not is a pure organizational issue from the point of view of the TOE which does not impact the TOE functionality. Therefore, the PP conformance claim above covers not only qualified signatures, but can also do this for advanced signatures under an appropriate interpretation of the organizational security policies P.CSP_QCert and P.QSign in [SSCDPP]. 2.3 Package Claims 73 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. 74 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 75 The ST claims strict conformance to the following protection profiles as required there: ICAO-EAC PP (sec. 2.5 in [EACPP3.1]), PACE-Pass PP (sec. 2.5 in [PACEPassPP]) and SSCD Core PP (sec. 6.4 in [SSCDPP]). Due to this fact, the Protection Profile ([RPCARDPP]) distinguishs between separated sets of {TOE type, SPD statement, security objectives statement, security requirements statement} for each application resi- ding in the TOE: ePassport, eID and eSign. In the Protection Profile ([RPCARDPP]) the rationale is given that TOE type, SPD statement, security objectives statement and se- curity requirements statement for each PP are commensurate and the the SFR and SAR statements in the RP_Card Protection Profile ([RPCARDPP]) includes those from the other PPs. Security Target TCOS Residence Permit Card/SLE78CLX1440P 17/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 3 Security Problem Definition 76 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 77 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 RP_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 key16 ) respectively (iii) being allowed to be used solely by the authenticated RP_Card holder (the private signature key within the eSign application). This asset covers ‘User Data on the MRTD’s chip’ and ‘Logical MRTD sensitive User Data’ in [EACPP3.1], ‘user data stored on the TOE’ (object #1) in [PACEPassPP] as well as ‘SCD’ and ‘DTBS/R’ in [SSCDPP]. Confidentiality17 Integrity Authenticity 2 user data transferred between the TOE and the service provider connected18 All data (being not authentication data) being transferred in the context of the applications of the RP_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 ‘User Data transferred between the TOE and the service provider connected (i.e. an authority represented by Basic Inspection Sys- tem with PACE)’ (object #2) in [PACEPassPP] and ‘DTBS’ in [SSCDPP]. Confidentiality17 Integrity Authenticity 16 Since the Restricted Identification according to [EACTR, sec. 4.5] represents just a functionality of the RP_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. 17 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. 18 For the ePassport application, the service provider is always an authority represented by a local RF-terminal Security Target TCOS Residence Permit Card/SLE78CLX1440P 18/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Object No. Asset Definition Generic security property to be maintained by the current security policy 3 RP_Card tracing data Technical information about the current and previ- ous locations of the RP_Card gathered by incon- spicuous (for the RP_Card holder) recognizing the TOE knowing neither CAN nor MRZ nor eID-PIN nor eID-PUK. TOE tracing data can be provided / gathered. This asset covers ‘ePass tracing data’ (object #3) in [PACEPassPP]. Unavailability19 Table 1: Primary assets 78 Application Note 3: Please note that user data being referred in the table above include, amongst other, individual-related (personal) data of the RP_Card holder which also include his sensitive (biometrical) data. Hence, the general security policy defined by the PP [RPCARDPP] also secures these specific RP_Card holder’s data as specified in the table above. 79 All these primary assets represent User Data in the sense of the CC. 80 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. This asset covers the equivalent object #4 in [PACEPassPP]. 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 covers the equivalent object #5 and ‘Authenticity of the MRTD’s chip’ in [EACPP3.1]. Availability 6 TOE immanent secret cryptographic keys Permanently or temporarily stored secret cryptographic material used by the TOE in order to enforce its security functionality20 . This asset covers the equivalent object #6 in [PACEPassPP]. Confidentiality Integrity 7 TOE immanent non- secret cryptographic keys Permanently or temporarily stored non-secret cryptographic (public) keys and other non-secret material (Card/Chip and Document Security Objects SOC and SOD, respectively, containing digital signatures) used by the TOE in order to enforce its security functionality. This asset covers the respective object #7 in [PACEPassPP] and ‘SVD’ in [SSCDPP]. Integrity Authenticity 8 Secret RP_Card holder authentication data Secret authentication information for the RP_Card holder being used for verification of the authentication attempts as authorized RP_Card holder: Confidentiality Integrity 19 represents a prerequisite for anonymity of the RP_Card holder 20 please note that the private signature key within the eSign application (SCD) belongs to the object No. 1 ‘user data stored’ above. Security Target TCOS Residence Permit Card/SLE78CLX1440P 19/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Object No. Asset Definition Property to be maintained by the current security policy • eID-PIN and eID-PUK stored in the RP_Card as well as • eSign-PIN (and eSign-PUK, if any21 ) (i) stored in the RP_Card22 and (ii) transferred to it23 9 RP_Card communication establishment authorization data Restricted-revealable24 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. This asset covers the respective object #8 in [PACEPassPP]. Confidentiality24 Integrity Table 2: Secondary assets 81 Application Note 4: RP_Card holder authentication and RP_Card communication estab- lishment authorization data are representted 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 connected25 — 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. 82 The secondary assets represent TSF and TSF-data in the sense of the CC. Subjects and external entities 83 This ST considers the following subjects: External Entity Subject Role Definition 1 1 RP_Card holder A person for whom the RP_Card issuer has personalized the RP_Card26 . This entity is commensurate with ‘MRTD Holder’ in [EACPP3.1], ‘ePass holder’ (subject #1) in [PACEPassPP] and ‘S.Signatory’ in [SSCDPP]. Please note that an RP_Card holder can also be an attacker (s. below). 2 – RP_Card presenter A person presenting the RP_Card to a terminal27 and claiming the identity of the RP_Card holder. This subject is commensurate with ‘Traveller’ in [EACPP3.1] and ‘S.User’ in [SSCDPP]. Please note that an RP_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 RP_Card holder. Service Provider uses the rightful terminals 21 eSign-PIN and eSign-PUK are local secrets being valid only within the eSign application 22 is commensurate with RAD in [SSCDPP] 23 is commensurate with VAD in [SSCDPP] 24 The RP_Card holder may reveal, if necessary, verification values of the CAN and MRZ to an au- thorized person or device who definitely act according to respective regulations and are trustwor- thy. 25 the input device of the terminal 26 i.e. this person is uniquely associated with a concrete electronic RP Card 27 in the sense of [EACTR] Security Target TCOS Residence Permit Card/SLE78CLX1440P 20/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 External Entity Subject Role Definition managed by a DV. This external entity is commensurate with the respective external entity #3 in [PACEPassPP]. 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 recognized by the TOE as neither PCT nor BIS-PACE nor EIS-AIP-BAC nor EIS-GAP nor ATT nor SGT (‘Terminal’ is used by the RP_Card presenter). This entity is commensurate with ‘Terminal’ in [EACPP3.1] and the re- spective external entity #4 in [PACEPassPP]. 5 3 PACE Terminal (PCT) A technical system verifying correspondence between the password stored in the RP_Card and the related value presented to the terminal by the RP_Card presenter. PCT implements the terminal’s part of the PACE protocol and authenti- cates itself to the RP_Card using a shared password (CAN, eID-PIN, eID-PUK or MRZ). This entity is commensurate with the respective external entity #5 in [PACEPassPP]. See also [EACTR, chap. 3.3, 4.2, table 1.2 and G.2] 6 4 Basic Inspection System with PACE (BIS-PACE) A technical system being used by an authority28 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying the RP_Card presenter as the RP_Card holder (for ePassport: by comparing the real biometrical data of the RP_Card presenter with the stored biometrical data of the RP_Card holder). BIS-PACE is a PCT additionally supporting/applying the Passive Authentication protocol and is authorised29 by the RP_Card Issuer through the Document Verifier of receiving state to read a subset of data stored in the ePassport application on the RP_Card. BIS-PACE in the context of [EACTR] (and of the RP Card PP) is similar, but not equivalent to the Basic Inspection System (BIS) as defined in [BACPP3.1]. This entity is commensurate with the respective external entity #6 in [PACEPassPP]. See also [EACPP3.1, chap. 3.2.1, G.1 and G.2]. 7 5 Extended Inspection System using AIP with BAC (EIS-AIP-BAC) A technical system being used by an inspecting authority30 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying the RP_Card presenter as the RP_Card holder (for ePassport: by comparing the real biometrical data (face, fin- gerprint or iris) of the RP_Card presenter with the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-AIP-BAC is a Basic Inspection System (BIS) in the sense of [BACPP3.1] additionally supporting/applying Chip Authentication (incl. passive authentication and Terminal Authentication protocols in the con- text of AIP and is authorized31 by the RP_Card Issuer through the Docu- ment Verifier of receiving state to read a subset of data stored on the RP_Card. EIS-AIP-BAC in the context of [EACTR] (and of the RP Card PP) is equi- valent to the Extended Inspection System (EIS) as defined in [EACPP3.1]. See also [EACTR, chap. 3.2 and C.4]. 8 1 Extended Inspection System using GAP (EIS-GAP) A technical system being used by an inspecting authority32 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying the RP_Card presenter as the RP_Card 28 concretely, by a control officer 29 by organizational measures 30 concretely, by a control officer 31 by issuing terminal certificates 32 concretely, by a control officer Security Target TCOS Residence Permit Card/SLE78CLX1440P 21/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 External Entity Subject Role Definition holder (for ePassport: by comparing the real biometrical data (face, fin- gerprint or iris) of the RP_Card presenter with the stored biometrical data (DG2 – DG4) of the RP_Card holder). EIS-GAP is a PCT additionally supporting/applying Chip Authentication (incl. passive authentication) and Terminal Authentication protocols in the context of GAP and is authorized33 by the RP_Card Issuer through the Document Verifier of receiving state to read a subset of data stored on the RP_Card. EIS-GAP in the context of [EACTR] (and of the RP Card PP) is similar, but not equivalent to the Extended Inspection System (EIS) as defined in [EACPP3.1]. See also [EACTR], chap. 3.2 and C.4. 9 2 Authentication Termi- nal (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 RP_Card presenter as the RP_Card holder (using secret eID-PIN34) , (ii) updating a subset of the data of the eID application and (iii) activating the eSign application. An Authentication Terminal is a PCT additionally supporting the Chip Authentication (incl. passive authentication) and the Terminal Authentica- tion protocols in the context of GAP and is authorized by the RP_Card Issuer through the Document Verifier of receiving branch (by issuing terminal certificates) to access a subset of the data stored on the RP_Card. See also [EACTR], chap. 3.2 and C.4. 10 3 Signature Terminal (SGT) A technical system 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 in the context of GAP and is authorized by the RP_Card Issuer through the Document Verifier of receiving branch (by issuing terminal certificates) to access a subset of the data stored on the RP_Card. See also [EACTR], chap. 3.2 and C.4. 11 4 Document Verifier (DV) An organization enforcing the policies of the CVCA and of a Service Provider (governmental or commercial organization) and managing termi- nals 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 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 RP_Card Issuer; a foreign DV is acting under a policy of the respective foreign CVCA (in this case there shall be an appropriate agreement35 between the RP_Card Issuer und a foreign CVCA ensuring enforcing the RP_Card Issuer’s privacy policy36 ). This entity is commensurate with ‘Document Verifier’ in [EACPP3.1] and with the respective external entity #7 in [PACEPassPP]. 12 5 Country Verifying Certification Authority (CVCA) An organization enforcing the privacy policy of the RP_Card Issuer with respect to protection of user data stored in the RP_Card (at a trial of a terminal to get an access to these data). The CVCA represents the coun- try specific root of the PKI for the rightful terminals (EIS-AIP-BAC, EIS- GAP, ATT, SGT) and creates the Document Verifier Certificates within this PKI. Updates of the public key of the CVCA are distributed in form of CVCA Link-Certificates, see [EACTR], chap. 2.2.1. 33 by issuing terminal certificates 34 secret eID-PUK can be used for unblocking the eID-PIN as well as the eSign-PIN and resetting the related retry counters. 35 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. 36 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 Residence Permit Card/SLE78CLX1440P 22/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 External Entity Subject Role Definition The Country Signing Certification Authority (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. This entity is commensurate with ‘Country Verifying Certification Authority’ in [EACPP3.1] and with the respective external entity #8 in [PACEPassPP]. 13 – Document Signer (DS) An organization enforcing the policy of the CSCA and signing the Card/Chip and Document Security Objects stored on the RP_Card for passive authentication. A Document Signer is authorized by the national CSCA issuing the Docu- ment Signer Certificate (CDS), see [EACTR], chap. 1.1 and [ICAO9303-1]. This role is usually delegated to a Personalization Agent. This entity is commensurate with the respective external entity #9 in [PACEPassPP]. 14 – Country Signing Certi- fication Authority (CSCA) An organization enforcing the policy of the RP_Card Issuer with respect to confirming correctness of user and TSF data stored in the RP_Card. The CSCA represents the country specific root of the PKI for the RP_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. [ICAO9303-1], 5.1.1. The Country Signing Certification Authority issuing certificates for Docu- ment Signers (cf. [ICAO9303-1]) and the domestic CVCA may be inte- grated 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. This entity is commensurate with the respective external entity #10 in [PACEPassPP]. 15 – 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 can also issue qualified certifi- cates. A CSP is the Certification Service Provider in the sense of [SSCDPP]. 16 6 Personalization Agent An organization acting on behalf of the RP_Card Issuer to personalize the RP_Card for the RP_Card holder by some or all of the following activities: (i) establishing the identity of the RP_Card holder for the biographic data in the RP_Card37, (ii) enrolling the biometric reference data of the RP_Card holder38, (iii) writing a subset of these data on the physical Residence Permit Card (optical personalization) and storing them in the RP_Card (electronic personalization) for the RP_Card holder as defined in [EACTR], (iv) writing the document details data, (v) writing the initial TSF data, (vi) signing the Card/Chip Security Object and the Document Security Object (ePassport) defined in [ICAO9303-1] (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 RP_Card Issuer. Generating signature key pair(s) is not in the scope of the tasks of this role. This entity is commensurate with ‘Personalization agent’ in [EACPP3.1], the respective external entity #11 in [PACEPassPP] and ‘Administrator’ in [SSCDPP]. 17 7 Manufacturer Generic term for the IC Manufacturer producing integrated circuit and the RP_Card Manufacturer completing the IC to the RP_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 RP_Card Manufacturer using this role Manufacturer. 37 relevant for the ePassport, the eID and the eSign applications 38 relevant for the ePassport application Security Target TCOS Residence Permit Card/SLE78CLX1440P 23/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 External Entity Subject Role Definition This entity is commensurate with ‘Manufacturer’ in [EACPP3.1], and the respective external entity #12 in [PACEPassPP]. 18 – Attacker A threat agent (a person or a process acting on his behalf) trying to un- dermine the security policy defined by the current ST, especially to chan- ge 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 recognised by the TOE. This entity is commensurate with ‘Attacker’ in [EACPP3.1], the respective external entity #13 in [PACEPassPP] and ‘Attacker’ in [SSCDPP]. Table 3: Subjects and external entities39 84 Since the file system of the TOE does not support BAC, the Basic Inspection System (BIS) cannot be recognized by the TOE, see above. 3.2 Threats 85 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. 86 The following threats are adopted in the current ST (they initially derived from the ICAO- BAC PP [BACPP3.1], ICAO-EAC PP [EACPP3.1], and from the ID_Card [IDCARDPP]): T.Skimming Skimming RP_Card/Capturing Card–Terminal Communication 87 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. 88 Application Note 5: A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this ST. When using EIS-AIP-BAC, this threat is confined to only selected data groups (DG3, DG4) within the ePassport application. 89 Application Note 6: MRZ is printed and CAN is printed or stuck on the Residence Permit Card. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted-revealable, cf. OE.Card-Holder. 39 This table defines external entities and subjects in the sense of [CC]. Subjects can be recognised by the TOE independent of their nature (human or technical user). As result of an appropriate identification and authentication process, the TOE creates – for each of the respective external en- tity – an ‘image’ inside and ‘works’ then with this TOE internal image (also called subject in [CC]). From this point of view, the TOE itself does not differ between ‘subjects’ and ‘external entities’. There is no dedicated subject with the role ‘attacker’ within the current security policy, whereby an attacker might ‘capture’ any subject role recognised by the TOE. Security Target TCOS Residence Permit Card/SLE78CLX1440P 24/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 T.Eavesdropping Eavesdropping on the communication between the TOE and a rightful terminal 90 An attacker is listening to the communication between the RP_Card and a rightful termi- nal 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. 91 Application Note 7: A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this ST. When using EIS-AIP-BAC, this threat is confined to only selected data groups (DG3, DG4) within the ePassport application. T.Tracing Tracing RP_Card 92 An attacker tries to gather TOE tracing data (i.e. to trace the movement of the RP_Card) unambiguously identifying it remotely by establishing or listening to a communication via the contactless interface of the TOE. The attacker cannot read and does not know the correct values of shared passwords (CAN, MRZ, eID-PIN, eID-PUK) in advance. This item concerns the following application(s): ePassport, eID, eSign. 93 Application Note 8: A product using BAC (whatever the type of the inspection system is: BIS-BAC or EIS-AIP-BAC) cannot avert this threat in the context of the security policy defined in the PP and used in this ST. Hence, this threat is considered not to be allied with using EIS-AIP-BAC. T.Counterfeit Counterfeiting RP_Card 94 An attacker produces an unauthorized copy or reproduction of a genuine RP_Card to be used as part of a counterfeit Residence Permit Card: He may generate a new data set or extract completely or partially the data from a genuine RP_Card and copy them on an- other functionally appropriate chip to imitate this genuine RP_Card. This violates the au- thenticity of the RP_Card being used either for authentication of an RP_Card presenter as the RP_Card holder or for authentication of the RP_Card as a genuine secure signa- ture creation device. This item concerns the following application(s): ePassport, eID, eSign. T.Forgery Forgery of Data 95 An attacker fraudulently alters the User Data or/and TSF-data stored on the RP_Card or/and exchanged between the TOE and the service provider connected in order to outsmart either the authenticated terminal (BIS-PACE, EIS-AIP-BAC, EIS-GAP, ATT or SGT) by the means of changed RP_Card holder’s related reference data (like biographic or biometric data or SCD/SVD) or the TOE by altering data being sent to the TOE (like DTBS/R). The attacker does it in such a way that the Service Provider (represented by the terminal connected) or the TOE perceives these modified data as authentic one. This item concerns the following application(s): ePassport, eID, eSign. This threat partially covers T.SVD_Forgery (only stored, but not being sent to the CGA SVD) from [SSCDPP]. T.Abuse-Func Abuse of Functionality 96 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, Security Target TCOS Residence Permit Card/SLE78CLX1440P 25/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 deactivate or modify) soft-coded security functionality of the TOE. This threat addresses also the misuse of the functions for the initialization and the personalization in the operational phase after delivery to the RP_Card holder. This item concerns the following application(s): ePassport, eID, eSign. This threat covers T.SigF_Misuse from [SSCDPP]. 97 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 RP_Card 98 An attacker may exploit information leaking from the TOE during its usage in order to disclose confidential User Data or/and TSF-data stored on the RP_Card or/and exchan- ed between the TOE and the service provider connected. 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. 99 Application Note 10: Leakage may occur through emanations, variations in power con- sumption, 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 measure- ments (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 Electro- magnetic 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). T.Phys-Tamper Physical Tampering 100 An attacker may perform physical probing of the RP_Card in order (i) to disclose the TSF-data, or (ii) to disclose/reconstruct the TOE’s Embedded Software. An attacker may physically modify the RP_Card in order to modify (i) its security functionality (hardware and software part, as well), (ii) the User Data or the TSF-data stored on the RP_Card. This item concerns the following application(s): ePassport, eID, eSign. 101 This threat covers T.Hack_Phys from [SSCDPP]. 102 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 RP_Card) or indirectly by pre- paration 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 RP_Card’s internals. Techniques commonly employed in IC failure analysis and IC reverse engineering efforts may be used. Before that, the hard- ware security mechanisms and layout characteristics need to be identified. Determina- tion 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 Security Target TCOS Residence Permit Card/SLE78CLX1440P 26/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 103 An attacker may cause a malfunction the RP_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 RP_Card outside the normal operating conditions, exploiting errors in the RP_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. 104 Application Note 12: A malfunction of the TOE may also be caused using a direct inter- action 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. 105 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST al- so considers all threats of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application. Threat identifier Equivalent to / covered by item in the ([RPCARDPP]) Comments T.Read_Sensitive_Data T.Skimming The threat T.Read_Sensitive_Data is covered by T.Skimming, because sensitive biometric reference data (DG3, DG4) stored on the RP_Card are part of the asset user data stored on the TOE. T.Counterfeit T.Counterfeit T.Forgery T.Forgery T.Abuse-Func T.Abuse-Func T.Information_Leakage T.Information_Leakage T.Phys-Tamper T.Phys-Tamper T.Malfunction T.Malfunction All these threats have the similar definitions and address the same assets. Therefore a distinction between these threats is not necessary. 106 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST al- so considers all threats of the PACE-Pass PP [PACEPassPP]. Formally, they only concern the ePassport application. Threat identifier Equivalent to / covered by item in the ([RPCARDPP]) Comments T.Skimming T.Skimming T.Eavesdropping T.Eavesdropping T.Tracing T.Tracing T.Forgery T.Forgery T.Abuse-Func T.Abuse-Func T.Information_Leakage T.Information_Leakage T.Phys-Tamper T.Phys-Tamper All these threats have the similar definitions and address the same assets. Therefore a distinction between these threats is not necessary. Security Target TCOS Residence Permit Card/SLE78CLX1440P 27/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 107 Due to identical definitions and the same names they are not repeated here. 108 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST also considers all threats of the SSCD PP [SSCDPP]. If the eSign application is opera- tional then all these items are applicable. Formally, they only concern the eSign applica- tion. For the sake of completeness the threats are listed below. More details can be found in the SSCD PP [SSCDPP]. Threat identifier Equivalent to / covered by item in the ([RPCARDPP]) Comments T.SCD_Divulg – – T.SCD_Derive – – T.Hack_Phys T.Phys-Tamper – T.SVD_Forgery T.Forgery T.Eavesdropping T.Forgery covers SVD stored; T.Eavesdropping covers SVD being sent to the CGA T.SigF_Misuse T.Abuse-Func T.Abuse-Func covers T.SigF_Misuse T.DTBS_Forgery T.Skimming T.Forgery T.Skimming covers a rightful SCA T.Forgery covers DTBS/R being sent to the TOE. T.Sig_Forgery – – 109 Application note 13: If in the table above no comments are given, the threats from the SSCD PP [SSCDPP] are adopted exactly as decribed in this ST. For covered items we use in the following explicitly only the items of the RP_Card PP. 3.3 Organizational Security Policies 110 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 RP_Card 1. The RP_Card issuer issues RP_Cards and approves terminals complying with all applicable laws and regulations. 2. The RP_Card issuer guarantees the correctness of the user data (amongst other of those, concerning the RP_Card holder) and of the TSF-data permanently stored in the TOE40. 3. The RP_Card issuer uses only such TOE’s technical components (IC) which enable traceability of the RP_Cards in their manufacturing and issuing life phases, i.e. before they are in the operational phase. 4. If the RP_Card issuer authorizes a Personalization Agent to personalize the RP_Card for the RP_Card holder, the RP_Card issuer has to ensure that the Personalization Agent acts in accordance with the RP_Card issuer’s policy. 111 This item concerns the following application(s): ePassport, eID, eSign. 40 cf. Table 1 and Table 2 above Security Target TCOS Residence Permit Card/SLE78CLX1440P 28/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 P.Card_PKI PKI for Chip and Passive Authentication41 (issuing branch) 112 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 RP_Card issuer shall establish a public key infrastructure for the passive authen- tication, i.e. for digital signature creation and verification for the RP_Card. For this aim he runs a Country Signing Certification Authority (CSCA). The RP_Card issuer shall 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 RP_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 RP_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/Chip Security Objects of the RP_Cards and (v) manage the Chip Authen- tication Key Pairs {SKPICC, PKPICC} used for the chip authentication as defined in the technical specification [EACTR], sec. 4.3. This item concerns the following application(s): ePassport, eID, eSign. P.Terminal_PKI PKI for Terminal Authentication (receiving branch) 113 Application Note 15: 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 RP_Card issuer shall establish a public key infrastructure for the card verifiable certificates used for terminal authentication. For this aim, the RP_Card issuer shall run a domestic Country Verifying Certification Authority (domestic CVCA) and may use already existing foreign CVCAs42. The RP_Card issuer shall make the CVCA Link Certificate available to the CSCA (who shall finally distribute it to its RP_Cards). 2. A CVCA shall securely generate, store and 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 RP_Card issuer by strictly secure means as well as to the respective Document Verifiers. A CVCA shall create the Document Verifier Certificates 41 Passive authentication is considered to be part of the Chip Authentication protocol. 42 In this case there shall be an appropriate agreement between the RP_Card Issuer und a foreign CVCA ensuring enforcing the RP_Card Issuer’s privacy policy. Existence of such an agreement may be technically reflected by means of issuing a CCVCA-F for the Public Key of the foreign CVCA signed by the domestic CVCA. Security Target TCOS Residence Permit Card/SLE78CLX1440P 29/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 for the Document Verifier Public Keys (CDV) and distribute them back to the respective Document Verifier Verifiers43. 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 Document Verifier shall make CT, CDV and CCVCA available to the respective Service Providers (who puts them in his terminals)44. 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. 114 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 organiza- tions (DS) and DS shall ensure that they sign exclusively correct Card/Chip and Document Security Objects having to be stored on the RP_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)45. 3. CSPs shall ensure that they issue their certificates exclusively for the rightful data (public signature key of the RP_Card holder)46. This item concerns the following application(s): ePassport, eID, eSign. P.Terminal Abilities and trustworthiness of rightful terminals 1. Rightful terminals (BIS-PACE, EIS-AIP-BAC, EIS-GAP, authentication terminal and signature terminal, cf. the table on p. 10) shall be used by Service Providers and by RP_Card holders as defined in [EACTR, sec. 3.2]. 2. They shall implement either the terminal parts of the PACE protocol [EACTR, sec. 4.2] (for BIS-PACE, EIS-GAP) or the terminal parts of the BAC protocol [EACTR, sec. H] (for EIS-AIP-BAC), of the Terminal Authentication protocol [EACTR, sec. 4.4], of the Passive Authentication with SOC [EACTR, sec. 3.4], of the Chip Authentication pro- tocol [EACTR, sec. 4.3] and of the Passive Authentication with SOD [EACTR, sec. 1.1] and use them – dependent on the type of terminal – in the order as required by [EACTR, sec. 3.1.1 and 3.1.2] A rightful terminal shall use randomly and (almost) uni- formly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellman). 43 A CVCA shall also manage a Revocation Sector Key Pair {SKRevocation, PKRevocation} [EACTR], sec. 2.3 and 4.5. 44 A DV shall also manage a Revocation Sector Key Pair {SKSectorNN, PKSectorNN} [EACTR, sec. 2.3 and 4.5]. 45 This rule is relevant for T.Skimming 46 This property is affine to P.CSP_QCert from [SSCDPP]. Security Target TCOS Residence Permit Card/SLE78CLX1440P 30/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 3. Rightful terminals shall store the related credentials needed for the terminal authenti- cation (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 RP_Card) in order to enable and to perform the terminal authentication as defined in [EACTR], sec. 4.4. 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 with SOC determination of the authenticity of PKPICC, [EACTR, sec. 4.3.1.2], and SOD (determination of the authenticity of the data groups stored in the ePassport, [EACTR, sec. 1.1]. 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 Authentication47. 6. A rightful terminal and its environment shall ensure confidentiality and integrity of re- spective data handled by it (e.g. confidentiality of PINs/PUKs, CAN and MRZ, integrity of PKI certificates and DTBS, etc.), where it is necessary for a secure operation of the TOE according to the current ST. This item concerns the following application(s): ePassport, eID, eSign. 115 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST also includes all OSPs of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application. OSP identifier from the PP Equivalent to / covered by OSP in this ST Comments P.BAC-PP see paragraph 25 (p. 9) and the Application No- te 8 of the RP_Card PP ([RPCARDPP]) Fulfillment of the Basic Access Control Protection Profile is a matter of a different evalution, which is independent from the current ST. Because the TOE is already evaluated and certified in accordance with [BACPP3.1] (see [BACCR]) and BAC is outside the scope of the current ST this OSP will not be considered in the following. P.Sensitive_Data P.Terminal_PKI T.Eavesdropping P.Terminal_PKI covers ‘The issuing State or Organization authorizes the Document Verifiers of the receiving States to manage the authorization of inspection systems within the limits defined by the Document Verifier Certificate.’ T.Eavesdropping covers ‘The MRTD’s chip shall protect the confidentiality and integrity of the sensitive private personal data even during transmission to the Extended Inspection System after Chip Authentication.’ P.Manufact P.Pre-Operational Because P.Manufact is covered by P.Pre-Operatio- nal, only the latter is considered in the following. P.Personalization P.Pre-Operational Because P.Personalization is covered by P.Pre-Ope- rational, only the latter is considered in the following. Table 4: OSPs taken over from [EACPP3.1] 47 This rule is relevant for T.Skimming Security Target TCOS Residence Permit Card/SLE78CLX1440P 31/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 116 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST also includes all OSPs of the PACE-Pass PP [PACEPassPP]. Formally, they only con- cern the ePassport application. Due to identical definition and same name it is not neccessary to consider them separately and therefore they are not repeated here. 117 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST also includes all OSPs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. Formally, they only concern the eSign application. For the sake of completeness the OSPs are listed below. More details can be found in the SSCD PP [SSCDPP]. OSP identifier from the PP Equivalent to / covered by OSP in this ST Comments P.CSP_QCert P.Trustworthy_PKI (partially) P.Trustworthy_PKI covers rightful SVDs within related certificates. Additionally, CSP has to use a trustworthy CGA, to put correct names of the signatories into its certifica- tes and to ensure that the use of the TOE as SSCD is evident with signatures through the certificate or other publicly available information. Despite of that P.CSP_QCert is partially covered by P.Trustworthy_PKI, it will be considered in the following. P.QSign P.Sigy_SSCD P.Sig_Non-Repud The TOE complies with these OSPs. For the coverage refer to [SSCDPP]. Table 5: Table 6: OSPs taken over from [SSCDPP] 3.4 Assumptions 118 The assumptions describe the security aspects of the environment in which the TOE will be used or is intended to be used. 119 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST takes over all assumptions of the ICAO-EAC PP [EACPP3.1]. Formally, they only con- cern the ePassport application. Assumption identifier covered by in this ST Comments (see also [EACPP3.1] for better comparability) A.MRTD_Manufact ALC_DVS.2 A.MRTD_Delivery ALC_DEL.1 see Application Note 16 below A.Pers_Agent P.Pre-Operational P.Card_PKI P.Pre-Operational covers ensuring the correctness of the logical MRTD with respect to the MRTD holder P.Card_PKI covers ensuring the correctness of keys and certificates stored on the MRTD’s chip and signing the Document Security Object (SOD). A.Insp_Sys P.Terminal_PKI P.Terminal P.Terminal_PKI covers availability of keys and certifi- cates stored in the inspection system P.Terminal covers supporting necessary authentica- Security Target TCOS Residence Permit Card/SLE78CLX1440P 32/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Assumption identifier covered by in this ST Comments (see also [EACPP3.1] for better comparability) tion protocols according to [EACTR]. A.Signature_PKI P.Card_PKI Because A.Signature_PKI is fulfilled due to compli- ance to P.Card_PKI, only the latter is considered in the following. A.Auth_PKI P.Terminal_PKI Because A.Auth_PKI is fulfilled due to compliance to P.Terminal_PKI, only the latter is considered in the following. Table 7: Assumptions taken over from [EACPP3.1] 120 Application note 16: Assumptions A.MRTD_Manufact and A.MRTD_Delivery from [EACPP3.1] address manufacturing, testing and delivery aspects. Fulfillment of such assumptions is a necessary condition for a ‘pass’ judgement by applying the chosen assurance components ALC_DVS.2 and ALC_DEL.1, respectively. It means that if the respective assurance components ALC_DVS.2 and ALC_DEL.1 have positively been judged, the fulfilment of these assumptions is ‘automatically’ ensured: the manufacturer is required and responsible for applying all the related procedures with respect to the TOE. Therefore, the assumptions A.MRTD_Manufact and A.MRTD_Delivery are impli- citly included by the RP_CARD PP ([RPCARDPP]) by choosing the assurance compo- nents ALC_DVS.2 and ALC_DEL.1. The remaining assumptions from [EACPP3.1] A.Pers_Agent, A.Insp_Sys, A.Signature_PKI and A.Auth_PKI are completely covered by the respective items (OSPs) defined in the RP_CARD PP. Hence we will explicitly use the items of this PP ([RPCARDPP]). 121 Since there are no assumptions in the PACE-Pass PP [PACEPassPP], there is nothing to be considered in this ST. 122 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST takes over all assumptions of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 123 For the sake of completeness the assumptions are listed below. More details can be found in the SSCD PP [SSCDPP]. Assumption identifier Covered by in this ST Comments (see also [SSCDPP] for better comparability) A.CGA - This item concerns not only qualified, but also non-qualified certificates and will be considered in this ST. A.SCA P.Terminal (partially) P.Terminal covers using trustworthy SCAs. Additionally, the SCA shall generate and send the DTBS/R to the TOE. Despite of that this assumption is partially covered, it will be considered in this ST. Table 8: Assumptions taken over from [SSCDPP] Security Target TCOS Residence Permit Card/SLE78CLX1440P 33/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 124 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. 125 The PP ([RPCARDPP]) does not include any additional assumptions. Hence there are explicitly only two assumptions A.CGA and A.SCA being exclusively applicable to the eSign application of the TOE. Security Target TCOS Residence Permit Card/SLE78CLX1440P 34/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 4 Security Objectives 126 This chapter describes the security objectives for the TOE and the security objectives for the TOE environment. 4.1 Security Objectives for the TOE 127 The following TOE security objectives address the protection provided by the TOE independent of the TOE environment. OT.Data_Integrity Integrity of Data 128 The TOE must ensure integrity of the User Data and the TSF-data48 stored on it by pro- tecting these data against unauthorized modification (physical manipulation and unauthorized modifying). The TOE must ensure integrity of the User Data and the TSF-data48 during their exchan- ge between the TOE and the Service Provider connected (and represented by either BIS-PACE, EIS-AIP-BAC, EIS-GAP or ATT or SGT) after the PACE Authentication as well as the Terminal- and the Chip Authentication. This item concerns the following application(s): ePassport, eID, eSign. 129 Application Note 17: A product using BIS-BAC cannot achieve this objective either for stored or being transmitted data in the context of the security policy defined in the ST. When using EIS-AIP-BAC, this objective is confined to only selected data groups (DG3, DG4) within the ePassport application. OT.Data_Authenticity Authenticity of Data 130 The TOE must ensure authenticity of the User Data and the TSF-data49 stored on it by enabling verification of their authenticity at the terminal-side50. The TOE must ensure authenticity of the User Data and the TSF-data49 during their exchange between the TOE and the Service Provider connected (and represented be either BIS-PACE, EIS-AIP-BAC, EIS-GAP or ATT or SGT) after the PACE Authentication as well as the Terminal- and the Chip Authentication. 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 terminal) and by an active verification by the TOE itself (at receiving by the TOE)51. This item concerns the following application(s): ePassport, eID, eSign. 131 Application Note 18: A product using BIS-BAC cannot achieve this objective either for stored or being transmitted data in the context of the security policy defined in the ST. When using EIS-AIP-BAC, this objective is confined to only selected data groups (DG3, DG4) within the ePassport application. 48 where appropriate, see Table 2 above 49 where appropriate, see Table 2 above 50 verification of SOC 51 Secure messaging after the chip authentication, see also [EACTR, sec. 4.4.2] Security Target TCOS Residence Permit Card/SLE78CLX1440P 35/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 OT.Data_Confidentiality Confidentiality of Data 132 The TOE must ensure the confidentiality of the User Data and the TSF-data52 by gran- ting read access only to authorized rightful terminals (BIS-PACE, EIS-AIP-BAC, EIS- GAP, ATT, SGT) according to the effective terminal authorization level (CHAT)53 presen- ted by the terminal connected54. The TOE must ensure confidentiality of the User Data and the TSF-data52 during their exchange between the TOE and the Service Provider connected (and represented be either BIS-PACE, EIS-AIP-BAC, EIS-GAP or ATT or SGT) after the PACE Authentication as well as the Terminal- and the Chip Authentication. This item concerns the following application(s): ePassport, eID, eSign. 133 Application Note 19: A product using BIS-BAC cannot achieve this objective in the con- text of the security policy defined in this ST. When using EIS-AIP-BAC, this objective is confined to only selected data groups (DG3, DG4)by granting read access only to autho- rized rightful terminal (EIS, ATT, SGT) according to the terminal authorization level (CHAT) presented by the terminal connected. OT.Tracing Tracing RP_Card 134 The TOE must prevent gathering TOE tracing data by means of unambiguous identifying the RP_Card remotely through establishing or listening to a communication via the con- tactless interface of the TOE without knowledge of the correct values of shared pass- words (CAN, MRZ, eID-PIN, eID-PUK) in advance. This item concerns the following application(s): ePassport, eID, eSign. 135 Application Note 20: A product using BAC (whatever the type of the inspection system is: BIS-BAC or EIS-AIP-BAC) cannot achieve this objective in the context of the security policy defined in the ST. Hence, this objective is considered not to be allied with using EIS-AIP-BAC. OT.Chip_Auth_Proof Proof of RP_Card authenticity 136 The TOE must enable the terminal connected to verify the authenticity of the RP_Card as a whole device as issued by the RP_Card issuer (issuing PKI branch of the RP_Card issuer) by means of Passive (using SOC) and Chip Authentication as defined in [EACTR], sec. 4.3. This item concerns the following application(s): ePassport, eID, eSign. 137 Application Note 21: The OT.Chip_Auth_Proof implies the RP_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 52 where appropriate, see Table 2 above 53 CHAT is not applicable to BIS (here: BIS-PACE). For BIS-PACE, table 1.2 in sec. 1.1 of [EACTR] (column PACE) shall be applied. 54 The authorisation of the terminal connected (CHAT) is drawn from the terminal certificate chain used for the successful terminal authentication as defined in [EACTR], sec. 4.4 and shall be a non-strict subset of the authorisation defined in the Terminal Certificate (CT), the Document Veri- fier Certificate (CDV) and the CCVCA in the certificate chain up to the Country Verifying Certification Authority of the RP_Card Issuer (receiving PKI branch of the RP_Card Issuer). The effective ter- minal authorisation can additionally be restricted by the RP_Card holder by a respective input at the terminal. Security Target TCOS Residence Permit Card/SLE78CLX1440P 36/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 of RP_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/Chip Security Object (SOC) signed by the Document Signer. 138 Application Note 22: Since the Standard Inspection Procedure does not support any unique-secret-based authentication of the chip (no Chip Authentication), a product using Basic Inspection System (whatever the used protocol is: BAC or PACE) cannot achieve this objective in the context of the security policy defined in the ST. Hence, this objective is considered not to be allied with using BIS-PACE. OT.Prot_Abuse-Func Protection against Abuse of Functionality 139 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 140 The TOE must provide protection against disclosure of confidential User Data or/and TSF-data stored and/or processed by the RP_Card • by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines, • by forcing a malfunction of the TOE and/or • by a physical manipulation of the TOE This item concerns the following application(s): ePassport, eID, eSign. 141 Application Note 23: 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 142 The TOE must provide protection of the confidentiality and integrity of the User Data, the TSF-data and the RP_Card’s Embedded Software by means of • measuring through galvanic contacts representing a direct physical probing on the chip’s surface except on pads being bonded (using standard tools for mea- suring 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 Security Target TCOS Residence Permit Card/SLE78CLX1440P 37/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 • reverse-engineering to understand the design and its properties and functionality 143 This item concerns the following application(s): ePassport, eID, eSign. OT.Prot_Malfunction Protection against Malfunctions 144 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 pro- ven or tested. This is to prevent functional errors in the TOE. The environmental condi- tions may include external energy (esp. electromagnetic) fields, voltage (on any con- tacts), clock frequency or temperature. This item concerns the following application(s): ePassport, eID, eSign. 145 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 146 The TOE must provide means to store Initialization55 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 RP_Card. This item concerns the following application(s): ePassport, eID, eSign. OT.Personalization Personalization of RP_Card 147 The TOE must ensure that the user data (amongst other those concerning the RP_Card holder56) and the TSF-data permanently stored in the TOE can be written by authorized Personalization Agents only. The Card/Chip and Document Security Objects 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 RP_Card holder had applied for this. This item concerns the following application(s): ePassport, eID, eSign. 148 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST al- so includes all security objectives for the TOE of the ICAO-EAC PP [EACPP3.1] and the PACE-Pass PP [PACEPassPP]. Formally they only concern the ePassport application. . Due to identical definition and the similar naming57 it is not neccessary to consider them separately and therefore they are not repeated here.. 55 amongst other, IC Identification data 56 biographical and biometrical data as well as the SCD, if the eSign is operational 57 The three minor deviations in the names are only formally and therefore not relevant: OT.AC_Pers is covered by OT.Personalization, OT.Data_Int by OT.Data_Integrity and OT.Sens_Data_Conf by OT.Data_Confidentiality. Security Target TCOS Residence Permit Card/SLE78CLX1440P 38/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 149 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST al- so includes all security objectives for the TOE of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 150 For the sake of completeness the objectives are listed below. More details can be found in the SSCD PP [SSCDPP]. Objective identifier from[SSCDPP] covered by in this ST Comments OT.Lifecycle_Security OT.SCD/SVD_Gen OT.SCD_Unique OT.SCD_SVD_Corresp Because these objectives from the SSCD PP ([SSCDPP]) are not covered by objectives of this ST they remain in force in the following. OT.SCD_Secrecy OT.Data_Confidentiality (partially) OT.Data_Confidentiality covers the confiden- tiality of the SCD at storage. Despite of that OT.SCD_Secrecy is partially covered by OT.Data_Confidentiality, it will be considered in the following for generation, signing and destruction of the SCD. OT.Sig_Secure OT.Sigy_SigF Because these objectives from the SSCD PP ([SSCDPP]) are not covered by objectives of this ST they remain in force in the following. OT.DTBS_Integrity_TOE OT.Data_Integrity OT.EMSEC_Design OT.Prot_Inf_Leak OT.Tamper_ID OT.Prot_Phys-Tamper OT.Prot_Malfunction OT.Tamper_Resistance OT.Prot_Phys-Tamper Because these objectives from the SSCD PP ([SSCDPP]) are covered by the listed objec- tives of this ST they will not be considered in the following. Table 9: TOE objectives taken over from [SSCDPP] 4.2 Security Objectives for the Operational Environment I. RP_Card issuer as the general responsible 151 The RP_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 152 The RP_Card issuer must issue RP_Cards and approve using the terminals complying with all applicable laws and regulations. This item concerns the following application(s): ePassport, eID. II. RP_Card issuer and CSCA: RP_Card’s PKI (issuing) branch 153 The RP_Card issuer and the related CSCA will implement the following security objectives for the TOE environment: Security Target TCOS Residence Permit Card/SLE78CLX1440P 39/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 OE.Passive_Auth_Sign Authentication of RP_Card by Signature 154 The RP_Card issuer has to establish the necessary public key infrastructure as follows: The CSCA acting on behalf and according to the policy of the RP_Card issuer must (i) generate a 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 RP_Card issuer, who makes them available to his own (domestic) CVCA as well as to the foreign CVCAs under agreement58. Hereby authen- ticity 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 Docu- ment Signer Private Key, (iii) hand over the Document Signer Public Key to the CSCA for certification, (iv) sign Card/Chip and Document Security Objects of genuine RP_Cards in a secure operational environment only. The digital signature in the Card/ Chip Security Object relates to all security information objects according to [EACTR], Appendix A. The CSCA must issue its certificates exclusively to the rightful organizations (DS) and DS must sign exclusively correct Card/Chip Security Objects having to be stored on the RP_Cards. This item concerns the following application(s): ePassport, eID. This item also covers OE.CGA_SSCD and partially OE.SVD_Auth from Table 10 below for the eSign application. OE.Chip_Auth_Key Chip Authentication Key 155 A Document Signer acting in accordance with the CSCA policy has to (i) generate the RP_Card’s Chip Authentication Key Pair {SKPICC, PKPICC} used for the chip authentication as defined in [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 Ser- vice Providers to verify the authenticity of the RP_Card’s chips used for genuine RP_Cards by certification of the Chip Authentication Public Key by means of the Card/ Chip Security Object. A Document Signer has also to manage Restricted Identification Key Pairs {SKID, PKID} [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 10 below for the eSign application. OE.Personalization Personalization of RP_Card 156 The RP_Card issuer must ensure that the Personalization Agents acting on his behalf (i) establish the correct identity of the RP_Card holder and create the biographical data for the RP_Card59, (ii) enroll the biometric reference data of the RP_Card holder60, (iii) write a subset of these data on the physical Identification Card (optical personalization) and store them in the RP_Card (electronic personalization) for the RP_Card holder as defi- ned in [EACTR], (iv) write the document details data, (v) write the initial TSF data, (vi) 58 CVCAs represent the roots of the receiving branch, see below 59 relevant for the ePassport, the eID and the eSign applications 60 relevant for the ePassport application Security Target TCOS Residence Permit Card/SLE78CLX1440P 40/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 sign the Card/Chip Security and Document Objects defined in [ICAO9303-1] (in the role of a DS). This item concerns the following application(s): ePassport, eID. This item also partially covers OE.CGA_QCert from Table 10 below for the eSign appli- cation. III. RP_Card issuer and CVCA: Terminal’s PKI (receiving) branch 157 The RP_Card issuer and the related domestic CVCA as well as the foreign CVCAs under agreement (with the RP_Card issuer Card Issuer)61 will implement the following security objectives of the TOE environment: OE.Terminal_Authentication Authentication of rightful terminals 158 The RP_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 RP_Card issuer as well as each foreign CVCA acting under agreement with the RP_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 RP_Card issuer, (who makes it available to his own CSCA62) 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 Sec- tor Key Pair {SKRevocation, PKRevocation} [EACTR, sec. 2.3 and 4.5]. A Document Verifier acting in accordance with the respective CVCA policy must (i) gene- rate 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 termi- nals for differentiated data access on the RP_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) se- curely 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)63. This item concerns the following application(s): ePassport, eID. This item also partially covers OE.SVD_Auth from Table 10 below for the eSign applica- tion. 61 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. 62 CSCA represents the root of the issuing branch, see above. 63 This rule is relevant for T.Skimming Security Target TCOS Residence Permit Card/SLE78CLX1440P 41/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 OE.Terminal Terminal operating 159 The Service Providers participating in the current PKI (and, hence, acting in accordance with the policy of the related DV) must operate their terminals as follows: 1. They use their terminals (BIS-PACE, EIS-AIP-BAC, EIS-GAP, authentication or signature terminals) as defined in [EACTR, sec. 3.2]. 2. Their terminals implement the terminal parts of the PACE protocol [EACTR, sec. 4.2] (for BIS-PACE, EIS-GAP), or the terminal parts of the BAC protocol [EACTR, sec. H] (for EIS-AIPBAC), of the Terminal Authentication protocol [EACTR, sec. 4.4], of the Passive Authentication with SOC [EACTR, sec. 3.4] (by verification of the signature of the Card/Chip Security Object) and of the Chip Authentication protocol [EACTR], sec. 4.364 and and of the Passive Authentication with SOD [EACTR, sec. 1.1] and use them – dependent on the type of terminal – in the order65 as required by [EACTR, sec. 3.1.1 and 3.1.2]. A rightful terminal uses randomly and (almost) uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellman).uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie- Hellman). 3. Their terminals securely store the related credentials needed for the terminal authenti- cation (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 RP_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 Sig- ner Public Key (in form of CCSCA and CDS) in order to enable and to perform Passive Authentication with SOC of the RP_Card (determination of authenticity of PKPICC, [EACTR, sec. 4.3.1.2]) and SOD (determination of authenticity of the data groups stored in the ePassport application [EACTR, sec. 1.1]). 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 Authentication66. 6. Their terminals and its environment must ensure confidentiality and integrity of respec- tive data handled by it (e.g. confidentiality of PINs/PUKs, CAN and MRZ, integrity of PKI certificates and DTBS, etc.), where it is necessary for a secure operation of the TOE according to the current ST. This item concerns the following application(s): ePassport, eID. This item also partially covers OE.SVD_Auth, OE.HID_VAD, OE.DTBS_Intend from Table 10 below for the eSign application. IV. RP_Card holder Obligations OE.Card-Holder RP_Card holder Obligations 64 The Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol within the [RPCARDPP] 65 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 [RPCARDPP]. 66 This rule is relevant for T.Skimming. Security Target TCOS Residence Permit Card/SLE78CLX1440P 42/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 160 The RP_Card holder has to keep his or her verification values of eID-PIN and eID-PUK secret. The RP_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 respec- tive 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. 161 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST al- so includes all security objectives for the TOE’s environment from the ICAO-EAC PP [EACPP3.1] and the PACE-Pass PP [PACEPassPP]. Formally they only concern the ePassport application. Due to the rationale given in the PP ([RPCARDPP]) all these objectives are implicitly covered by the objectives in the RP_Card PP ([RPCARDPP]). Hence they will not repeated in this ST. 162 Due to the strict conformance claims of the Protection Profile ([RPCARDPP]) this ST al- so includes all the security objectives for the TOE’s environment of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. 163 For the sake of completeness the security objectives for the TOE’s environment are lis- ted below. More details can be found in the SSCD PP [SSCDPP]. Objective identifier from [SSCDPP] Equivalent to or covered by item in the ST Comments OE.SVD_Auth OE.Passive_Auth_Sign (partially) OE.Terminal (partially) OE.Passive_Auth_Sign and OE.Terminal cover ensuring the integrity of the SVD exported by the TOE to the CGA. Additionally, the CGA shall verify the corresondence between the SCD in the SSCD of the signatory and the SVD exported, cf. OE.SSCD_Prov_Service. OE.CGA_QCert OE.Personalisation (partially) OE.Personalisation covers the correct identity of the Signatory (RP_Card holder). Additionally, CGA shall include the SVD matching the SCD stored in the TOE and the advanced signature of the CSP in its certificates. This item also ensures the property #3 (CSP duties) of P.Trustworthy_PKI OE.SSCD_Prov_\ Service OT.Chip_Auth_Proof Because the objective OE.SSCD_Prov_Service is covered by OT.Chip_Auth_Proof it will not be considered in the following. OE.HID_VAD OE.Terminal Because the objective OE.HID_VAD is covered by OE.Termi- nal it will not be considered in the following. OE.DTBS_Intend OE.Terminal (partially) OE.Terminal covers enabling verification of the integrity of the DTBS/R by the TOE. Additionally, SCA shall (i) generate the DTBS/R of the data which the signatory intends to sign, (ii) send the DTBS/R to the TOE and (iii) attach the signature produced by the TOE to the data. OE.DTBS_Protect OT.Data_Integrity The TOE's objective OT.Data_Integrity supports the objective OE.DTBS_Protect. OE.Signatory OE.Card-Holder (partially) OE.Card-Holder covers keeping her Signatory VAD confidential. Additionally, Signatory has to check that the SCD stored in the SSCD received from SSCD provisioning service is in non- operational state. Table 10: TOE’s environment objectives taken over from [SSCDPP] Security Target TCOS Residence Permit Card/SLE78CLX1440P 43/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 4.3 Security Objective Rationale 164 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 objec- tives. 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.Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction OE.Personalization OE.Passive_Auth_Sign OE.Chip_Auth_Key OE.Terminal_Authentication OE.Terminal OE.Card-Holder OE.Legislative_Compliance OE.CGA_QCert ([SSCDPP]) T.Skimming x x x x x x T.Eavesdropping x T.Tracing x x T.Counterfeit x x x T.Forgery x x x x x x x T.Abuse-Func x T.Information_Leakage x T.Phys-Tamper x T.Malfunction x P.Pre-Operational x x x x P.Terminal x P.Card_PKI x x P.Terminal_PKI x P.Trustworthy_PKI x x x Table 11:Security Objective Rationale 165 A detailed justification required for suitability of the security objectives to coup with the security problem definition is given in the RP_Card PP ([RPCARDPP]), ICAO-EAC PP [EACPP3.1], PACE-Pass PP [PACEPassPP] and SSCD PP [SSCDPP]. Hence it will not be repeated here. 166 For the Composite Evaluation the following Security Objectives for the Hardware Plat- form are relevant too. They are listed here for the sake of completeness only. The de- tailed analysis of the Security Objectives derived from the hardware platform ST [HWST] and the environment of the Hardware Platform is made separately in a the chapter 7.10 (Statement of Compatibility). 167 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) Security Target TCOS Residence Permit Card/SLE78CLX1440P 44/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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) 168 They all will be shown being relevant and not contradicting the Security Objectives of the TOE. They will be mapped to corresponding objectives of the TOE. 169 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. Security Target TCOS Residence Permit Card/SLE78CLX1440P 45/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 5 Extended Components Definition 170 This protection profile uses components defined as extensions to CC part 2. All these extended components are drawn from Definitions of chapter 5 of [RPCARDPP]. 5.1 FAU_SAS Audit data storage 171 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 172 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 Residence Permit Card/SLE78CLX1440P 46/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 173 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 Residence Permit Card/SLE78CLX1440P 47/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 5.4 FIA_APO Authentication Proof of Origin 174 The family “Authentication Proof of Origin (FIA_APO)” is specified as follows. Family behavior This family defines functions provided by the TOE to prove its origin and to be verified by an external entity in the TOE IT environment. Component levelling: FIA_APO.1 Authentication Proof of Origin. Management: FIA_APO.1 The following actions could be considered for the management func- tions in FMT: Management of authentication information used to prove the claimed origin. Audit: FIA_APO.1 There are no actions defined to be auditable. FIA_APO.1 Authentication Proof of Origin Hierarchical to: No other components. Dependencies: No dependencies. FIA_APO.1.1 The TSF shall provide a [assignment: authentication mechanism] to prove the origin of the [assignment: authorized user or role]. 5.5 FMT_LIM Limited capabilities and availability 175 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 Limited capabilities and availability 1 2 FIA_APO Authentication Proof of Origin 1 Security Target TCOS Residence Permit Card/SLE78CLX1440P 48/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 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.6 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: Security Target TCOS Residence Permit Card/SLE78CLX1440P 49/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 Residence Permit Card/SLE78CLX1440P 50/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 6 Security Requirements 176 This part of the ST 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. 177 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. 178 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. 179 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. 180 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. 181 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. 182 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’. Security Target TCOS Residence Permit Card/SLE78CLX1440P 51/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 6.1 Security Functional Requirements for the TOE 6.1.1 Overview 183 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 RP_CARD PP ([RPCARDPP]) defined the security functional groups and allocated the functional re- quirements 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 (BIS-PACE, EIS-GAP, ATT, SGT) – FIA_UAU.1/ICAO-EAC: Terminal Authentication (EIS-AIP-BAC) – {FDP_ACC.1/Signature-creation_SFP_SSCD, FDP_ACF.1/Signature- creation_SFP_SSCD} Secure data exchange between the RP_Card and the Service Provider connected – FTP_ITC.1/CA: trusted channel for EIS-AIP-BAC, EIS-GAP, ATT, SGT – FTP_ITC.1/PACE: trusted channel for BIS-PACE Supported by: a) for GAP: – FCS_COP.1/AES: encryption/decryption – FCS_COP.1/CMAC: MAC generation/verification – FIA_API.1/CA: Chip Identification/Authentication (version 2) – FIA_UAU.1/Rightful_Terminal: Terminal Authentication (BIS-PACE, EIS-GAP, ATT, SGT) b) for AIP: – FCS_COP.1/SYM_ICAO-EAC: encryption/decryption – FCS_COP.1/MAC_ICAO-EAC: MAC generation/verification – FIA_API.1/ICAO-EAC: Chip Identification/Authentication (version 1) – FIA_UAU.1/ICAO-EAC: Terminal Authentication (EIS-AIP-BAC) Identification and authentication of users and components – FIA_UID.1/PACE: PACE Identification (PCT equiv. BIS-PACE) – FIA_UID.1/Rightful_Terminal: Terminal Identification (EIS-GAP, ATT, SGT) – FIA_UID.1/ICAO-EAC: Terminal Identification (EIS-AIP-BAC) – FIA_UAU.1/PACE: PACE Authentication (PCT equiv. BIS-PACE) – FIA_UAU.1/Rightful_Terminal: Terminal Authentication (EIS-GAP, ATT, SGT) – FIA_API.1/CA: Chip Identification / Authentication for GAP (version 2) – FIA_UAU.1/ICAO-EAC: Terminal Authentication (EIS-AIP-BAC) – FIA_API.1/ICAO-EAC: Chip Identification/Authentication for AIP (version 1) – FIA_APO.1/PA_PACE-Pass: Passive Authentication using SOD with previous PACE based on FIA_UAU.1/PACE (BIS-PACE) – 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 RP_Card holder as Signatory (eSign-PIN) – FIA_UIA.1/SSCD: Authentication of RP_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-AIP-BAC, EIS-GAP, ATT, Security Target TCOS Residence Permit Card/SLE78CLX1440P 52/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Security Functional Groups Security Functional Requirements concerned SGT) – FCS_CKM.1/DH_CA: Chip Authentication – FCS_CKM.2/DH: Diffie-Hellmann key distribution within PACE and Chip Authentica- tion – 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 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 12: Security functional groups vs. SFRs 184 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 certifi- cate 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 ref- erence 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 (PKPCD) as authentication reference data, (ii) the coded access control rights of the terminal (EIS-AIP-BAC, EIS-GAP, ATT, SGT), the Certificate Effective Date and the Certificate Expiration Date as security attributes. Security Target TCOS Residence Permit Card/SLE78CLX1440P 53/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Name Data Issuing PKI branch Country Signing Certification Authority Key Pair and Certificate Country Signing Certification Authority of the RP_Card issuer signs the Document Signer Public Key Certificate (CDS) with the Country Signing Certification Authority Pri- vate 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 refer- ence data. The Document Signer acting under the policy of the CSCA signs the Card/ Chip Security Object (SOC) of the RP_Card and the Document Security Object (SOD) of the ePassport application 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 RP_Card and used by the terminal for Chip Authenti- cation. Its authenticity is verified by terminal in the context of the Passive Authen- tication (verification of SOC). Chip Authentication Private Key (SKPICC) The Chip Authentication Key Pair (SKPICC, PKPICC) is used for Key Agreement Pro- tocol: Diffie-Hellman (DH) according to RFC 2631 or Elliptic Curve Diffie-Hellman (ECDH, ECKA key agreement algorithm) according to [ECCTR, sec. A.2]. SKPICC is used by the TOE to authenticate itself as authentic RP_Card. Session keys PACE Session Keys (PACE- KMAC, PACE-KEnc) Secure messaging AES keys for message authentication (CMAC-mode) and for mes- sage encryption (CBC-mode) agreed between the TOE and a terminal (PCT) as result of the PACE Protocol, see [EACTR], sec. A.3, F.2.2, A.2.3.2. Chip Authentication Session Keys (CA-KMAC, CA-KEnc) Secure messaging AES keys for message authentication (CMAC-mode) and for mes- sage encryption (CBC-mode) agreed between the TOE and terminal (EIS-AIP-BAC, EIS-GAP, ATT, SGT) as result of the Chip Authentication Protocol, see [EACTR], sec. A.4, F.2.2, A.2.3.2.. Ephemeral keys PACE authentication ephemeral key pair (ephem-SKPICC-PACE, ephem-PKPICC-PACE) PACE authentication ephemeral key pair (ephem-SKPICC-PACE, ephem-PKPICC- PACE) 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-ano- nymization), 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]. For Restricted Identification please also refer to Paragraph 28 on p.5 Signature keys Signature Creation Key Pair (SCD/SVD) Signature Creation Data (SCD) is represented by a private cryptographic key being used by the RP_Card holder (signatory) to create an electronic signature. This key represents user data. Signature Verification Data (SVD) is represented by a public cryptographic key cor- responding 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 13: Keys and Certificates Security Target TCOS Residence Permit Card/SLE78CLX1440P 54/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 6.1.2 Class FCS Cryptographic Support 185 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]67 and specified cryptographic key sizes 192, 224, 256, 320, 384 and 512 bit length group order68 that meet the following: [EACTR], Appendix A.369. This item concerns the following application(s): ePassport, eID, eSign. 186 Application Note 24: 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.2 and A.2.3.2 for the TSF required by FCS_COP.1/AES and FCS_COP.1/CMAC. 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_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]70 and specified cryptographic key sizes 192, 224, 256, 67 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 68 [assignment: cryptographic key sizes] 69 [assignment: list of standards] 70 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] Security Target TCOS Residence Permit Card/SLE78CLX1440P 55/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 320, 384 and 512 bit length group order71 that meet the following: [EACTR] Annex A.472. This item concerns the following application(s): ePassport, eID, eSign. 189 Application Note 25: 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.2 and A.2.3.2 for the TSF required by FCS_COP.1/AES and FCS_COP.1/CMAC. 190 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]73 and specified cryptographic key sizes 224, 256, 320, 384 and 512 bit length group order74 that meet the following: [EACTR]75. This item concerns the following application(s): ePassport, eID, eSign. 191 Application Note 26: 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”. 192 Application Note 27: This SFR for Chip Authentication Key Pair Generation operation is added according to the recommendation of the Protection Profile [RPCARDPP, Applica- tion note 68]. 193 FCS_CKM.2/DH Cryptographic key distribution – Diffie-Hellman 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 71 [assignment: cryptographic key sizes] 72 [assignment: list of standards] 73 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 74 [assignment: cryptographic key sizes] 75 [assignment: list of standards] Security Target TCOS Residence Permit Card/SLE78CLX1440P 56/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 below76 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 (version 2 for GAP) and A.4]77. This item concerns the following application(s): ePassport, eID, eSign. 194 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 key78 that meets the following: none79. This item concerns the following application(s): ePassport, eID, eSign. 195 Application Note 28: 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 destroys the CA Session Keys after detection of an error in a received command by verification of the MAC. The TOE clears 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. 196 FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation Hierarchical to: No other components. 76 [assignment: cryptographic key distribution method] 77 [assignment: list of standards] 78 [assignment: cryptographic key destruction method] 79 [assignment: list of standards] Security Target TCOS Residence Permit Card/SLE78CLX1440P 57/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 hashing80 in accordance with a specified cryptographic algorithm SHA-1, SHA-224 and SHA-25681 and cryptographic key sizes none82 that meet the following: FIPS 180-2 83. This item concerns the following application(s): ePassport, eID, eSign. 197 Application Note 29: For hashing an ephemeral public key for DH (PACE84 and CA85), 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 norma- tive 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. 198 The following iterations are caused by different cryptographic algorithms to be imple- mented by the TOE. 199 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: 80 [assignment: list of cryptographic operations] 81 [assignment: cryptographic algorithm] 82 [assignment: cryptographic key sizes] 83 [assignment: list of standards] 84 IDPICC = H(ephem-PKPICC-PACE) in [EACTR, sec. 4.4] 85 H(ephem-PKPCD-TA) in [EACTR, sec. 4.3.1.2] Security Target TCOS Residence Permit Card/SLE78CLX1440P 58/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 The root key PKCVCA used for verifying CDV is stored in the TOE during its personalization (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 ([RPCARDPP]) does not contain any dedicated requirement like FDP_ITC.2 for the import function. 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 verification86 in accordance with a specified cryptographic algorithm ECDSA with plain signature format 87 and cryptographic key sizes 192, 224, 256, 320, 384 and 512 bit length group order 88 that meet the following: [EACTR]89. This item concerns the following application(s): ePassport, eID, eSign. 200 Application Note 30: 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.3, A.6.4 and D.3 for details). The signature verification is used to verify the card verifiable certificates and the authentication attempt of the terminal gene- rated 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). 201 Application Note 31: An ECDSA signature should use a hash function with a correspon- ding security level. The TOE supports SHA-224, SHA-256, SHA-384 and SHA-512 with the standardized domain parameters mentioned in [ECARDTR, section 1.3.2] and the NIST P-256 curve mentioned in [EACTR, A.2.1.1]. 202 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 86 [assignment: list of cryptographic operations] 87 [assignment: cryptographic algorithm] 88 [assignment: cryptographic key sizes] 89 [assignment: list of standards] Security Target TCOS Residence Permit Card/SLE78CLX1440P 59/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 FCS_COP.1.1/ AES The TSF shall perform secure messaging – encryption and decryp- tion90 in accordance with a specified cryptographic algorithm AES in CBC mode91 and cryptographic key sizes 128, 192 and 256 bit92 that meet the following: FIPS 197 [FIPS197] and [EACTR] Appendix F.2.293. This item concerns the following application(s): ePassport, eID, eSign. 203 FCS_COP.1/SYM_ICAO-EAC Cryptographic operation – Encryption/Decryption DES Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]: 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/ SYM_ICAO-EAC The TSF shall perform secure messaging – encryption and decryp- tion94 in accordance with a specified cryptographic algorithm TDEA in CBC mode 95 and cryptographic key sizes 112 bit 96 that meet the following: FIPS 46-3 [FIPS46]97. This item concerns the following application(s): ePassport. 204 Application Note 32: These SFRs require the TOE to implement the cryptographic primi- tive AES for secure messaging with encryption of transmitted data. The related session keys are agreed between the TOE and the terminal as part of either the PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KEnc) or the Chip Authentication Pro- tocol according to the FCS_CKM.1/DH_CA (CA-KEnc). Note that in accordance with [EACTR, Appendix F.2.1 and A.2.3.1] the (two-key) Triple-DES could be used in CBC mode for secure messaging. It is also a valid option in the ICAO-EAC PP [EACPP3.1] (see FCS_COP.1/SYM_ICAO-EAC). Due to the fact that the (two-key) Triple-DES is not recommended any more by the BSI, Triple-DES is applicable only to using EIS-AIP-BAC for reason of compliance with [EACPP3.1] and is also covered by [EACPP3.1]. For all other terminal types being in the scope of the ST, Triple-DES in any mode is not applica- ble within this ST (cf. [RPCARDPP]). 90 [assignment: list of cryptographic operations] 91 [assignment: cryptographic algorithm] 92 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] 93 [assignment: list of standards] 94 [assignment: list of cryptographic operations] 95 [assignment: cryptographic algorithm] 96 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] 97 [assignment: list of standards] Security Target TCOS Residence Permit Card/SLE78CLX1440P 60/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 205 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 code98 in accordance with a specified cryptographic algorithm CMAC99 and cryptographic key sizes 128, 192 or 256 bit100 that meet the following: [SP800-38B] and [EACTR, Appendix F.2.2]101. This item concerns the following application(s): ePassport, eID, eSign. 206 FCS_COP.1/MAC_ICAO-EAC Cryptographic operation – Retail MAC Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] ]; 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/ MAC_ICAO-EAC The TSF shall perform secure messaging – message authentica- tion code102 in accordance with a specified cryptographic algorithm Retail-MAC 103 and cryptographic key sizes 112 bit104 that meet the following: ISO 9797 (MAC algorithm 3, block cipher DES, Sequence Message Counter, padding mode 2) [ISO9797]105. This item concerns the following application(s): ePassport. 207 Application Note 33: These SFRs require the TOE to implement the cryptographic primi- tive for secure messaging with message authentication code over transmitted data. The related session keys are agreed between the TOE and the terminal as part of either the PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KMAC) or the Chip 98 [assignment: list of cryptographic operations] 99 [assignment: cryptographic algorithm] 100 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] bit 101 [assignment: list of standards] 102 [assignment: list of cryptographic operations] 103 [assignment: cryptographic algorithm] 104 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] bit 105 [assignment: list of standards] Security Target TCOS Residence Permit Card/SLE78CLX1440P 61/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Authentication Protocol according to the FCS_CKM.1/DH_CA (CA-KMAC). Note that in accordance with [EACTR] Appendix F.2.1 and A.2.3.1 the (two-key) Triple-DES could be used in Retail mode for secure messaging. It is also a valid option in the ICAO-EAC PP [EACPP3.1] (see FCS_COP.1/MAC_ICAO-EAC). Due to the fact that the Retail-MAC is not recommended any more by the BSI, this algorithm is applicable only to using EIS- AIP-BAC for reason of compliance with [EACPP3.1] and is also covered by [EACPP3.1]. For all other terminal types being in the scope of the ST this algorithm is not applicable within this ST (cf. [RPCARDPP]). 208 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 quality requirements for a P2 generator according to [AIS31]106. This item concerns the following application(s): ePassport, eID, eSign. 209 Application Note 34: 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. 210 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application. For the functional class FCS, there are the following components: FCS_CKM.1/ICAO-EAC, FCS_CKM.4/ICAO-EAC, FCS_COP.1/SHA_\ ICAO-EAC, FCS_COP.1/SYM_ICAO-EAC, FCS_COP.1/MAC_ICAO-EAC, FCS_COP.1/ SIG_VER_ICAO-EAC, FCS_RND.1/ICAO-EAC. 211 This ST also includes all SFRs of the PACE-Pass PP [PACEPassPP]. Formally, they only concern the ePassport application. For the functional class FCS, there are the follo- wing components: FCS_CKM.1/DH_PACE_PACE-Pass, FCS_CKM.2/DH_PACE-Pass, FCS_CKM.4/PACE-Pass, FCS_COP.1/AES_PACE-Pass, FCS_COP.1/MAC_PACE- Pass, FCS_RND.1/PACE-Pass. 212 The PP ([RPCARDPP]) demonstrates how the imported requirements are covered by its own requirements. Hence it is not repeated here. Additionally the use of Triple-DES and Retail-MAC is allowed (cf. Application Notes 32 and 33 on p. 58f) 213 This ST also includes all SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. Formally, they only concern the eSign application. For the functional class FCS there are the following components: FCS_CKM.1/SSCD, FCS_CKM.4/SSCD, FCS_COP.1/SSCD. 106 [assignment: a defined quality metric] Security Target TCOS Residence Permit Card/SLE78CLX1440P 62/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 214 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]107 and specified cryptographic key sizes 224, 256, 320, 384 and 512 bit length group order 108 that meet the following: [EACTR]109. 215 Application Note 35: The SCD/SVD Key Pair Generation requires authentication as Cer- tification Service Provider (CSP) and is not available to other subjects (cf. FDP_ACC.1/ SCD/SVD_Generation_SFP_SSCD. 216 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 FCS_CKM.4 Cryptographic key destruction]: fulfilled by FCS_CKM.4/SSCD. FCS_COP.1.1/ SSCD The TSF shall perform digital signature generation110 in accordance with a specified cryptographic algorithm ECDSA compliant to [ECCTR]111 and cryptographic key sizes 224, 256, 320, 384 and 512 bit length group order112 that meet the following: [ECCTR]113. 107 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [ECCTR]] 108 [assignment: cryptographic key sizes] 109 [assignment: list of standards] 110 [assignment: list of cryptographic operations] 111 [assignment: cryptographic algorithm] 112 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] bit 113 [assignment: list of standards] Security Target TCOS Residence Permit Card/SLE78CLX1440P 63/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 6.1.3 Class FIA Identification and Authentication 217 Application Note 36: The following Table 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 version 2 (for GAP) FIA_UAU.1/Rightful_Terminal, FIA_UAU.5 as required by FCS_COP.1/SIG_VER Chip Authentication Protocol version 2 (for GAP) FIA_API.1/CA, FIA_UAU.5, FIA_UAU.6 as required by FCS_CKM.1/DH_CA Terminal Authentication Protocol version 1 (for AIP) FIA_UAU.1/ICAO-EAC, FIA_UAU.5/ICAO-EAC inherited from [EACPP3.1] Chip Authentication Protocol version 1 (for AIP) FIA_API.1/ICAO-EAC, FIA_UAU.5/ICAO-EAC, FIA_UAU.6/ICAO-EAC inherited from [EACPP3.1] Passive Authentication using SOD FIA_APO.1/PA_PACE-Pass inherited from [PACEPassPP] eSign-PIN FIA_UAU.1/SSCD inherited from [SSCDPP] Table 14: Overview of authentication SFRs 218 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] 114 unsuccessful authentication attempts occur related to consecutive failed authentication attempts using eID-PIN as the shared password for PACE115. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met116, the TSF shall suspend the reference value of eID-PIN according to [EACTR], sec. 3.3.2117. This item concerns the following application(s): eID, eSign. 114 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 115 [assignment: list of authentication events] 116 [selection: met, surpassed] 117 [assignment: list of actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 64/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 219 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]. 220 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]118 unsuccessful authentication attempts occur related to consecutive failed authentication attempts using suspended eID-PIN as the shared password for PACE119. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met120, the TSF shall block the reference value of eID-PIN according to [EACTR], sec. 3.3.2121. This item concerns the following application(s): eID. 221 Application Note 37: 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 than bad + sad ≤ 9 overall tries of the eID-PIN are allowed. 222 FIA_AFL.1/PACE Authentication failure handling – PACE authenti- cation using non-blocking authentication/autho- rization data 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 1122 unsuccessful authentication attempts occurs related to authentication attempts using CAN, MRZ, eID-PUK as shared passwords for PACE123. 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 Residence Permit Card/SLE78CLX1440P 65/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met124, the TSF shall shall require the restart of the PACE protocol125. This item concerns the following application(s): ePassport, eID, eSign. 223 Application Note 38: 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 restarting PACE is sufficient to prevent the skimming of the TOE even for a random 6 digit CAN value. 224 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 (for GAP)126 to prove the identity of the TOE127. This item concerns the following application(s): ePassport, eID, eSign. 225 Application Note 39: 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 RP_Card by verifying the authentication token TPICC calculated by the RP_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/Chip Security Object (SOC) up to CSCA shall be triggered by the rightful terminal immediately after the successful Terminal Authentication before the Chip Authentica- tion128 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 provi- ding evidence enabling an external entity (the terminal connected) to prove the TOE’s identity. 122 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 123 [assignment: list of authentication events] 124 [selection: met ,surpassed] 125 [assignment: list of actions]. 126 [assignment: authentication mechanism] 127 [assignment: authorized user or role] 128 cf. [EACTR, sec. 3.4] Security Target TCOS Residence Permit Card/SLE78CLX1440P 66/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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. Please note that the Chip Authentication Protocol according to [EACTR], sec. 4.3, ver- sion 1 (for AIP) is covered by [EACPP3.1] (see FIA_API.1 there). 226 FIA_APO.1/PA_PACE-Pass Authentication Proof of Origin Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide the Passive Authentication according to [EACTR], sec. 1.1129 to prove the origin of the ePassport130. This item concerns the following application(s): ePassport. 227 Application Note 40: This SFR is taken over from the ePass_PACE PP ([EACPP3.1]), where it concerns the Passive Authentication of an electronic Passport (ePass). In the RP_Card the Passive Authentication is provided by the ePassport application of the TOE. Due to the identical naming of both applications the FIA_API.1 SFR can be adop- ted in this ST without changes. The Passive Athentication making evident the authenticity/origin of data stored in the ePassport application by verifying the Document Security Object (SOD) up to CSCA shall be triggered by the PCT immediately after the selection of ePassport. Please note that this SFR does not require authentication of any TOE’s user, but providing evidence enabling an external entity (the terminal connected) to prove the origin of ePassport application. Independent of the result of Passive Authentication, secure messaging is continued using the previously established session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE. 228 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.2131 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 befo- re allowing any other TSF-mediated actions on behalf of that user. 129 [assignment: authentication mechanism] 130 [assignment: authorized user or role] 131 [assignment: list of TSF-mediated actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 67/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 This item concerns the following application(s): ePassport, eID, eSign. 229 Application Note 41: 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 RP_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 RP_Card holder itself or an authorized other person or device. 230 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 2 (for GAP)132. 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. 231 Application Note 42: The user identified after a successfully performed TA protocol is a rightful terminal, i.e. for GAP: either EIS-GAP or ATT or SGT. Please note that the Terminal Authentication Protocol according to [EACTR], sec. 4.4, version 1 (for AIP) is covered by [EACPP3.1] (see FIA_UID.1 there). In this case, the user identified after a successfully performed TA protocol is also a rightful terminal, namely an EIS-AIP-BAC. 232 Application Note 43: 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 RP_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 like e.g. a ‘privileged terminal’, cf. [EACTR, sec. C.4.3, Table C.4]. 132 [assignment: list of TSF-mediated actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 68/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 233 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 Protocol133 according to [EACTR, sec. 4.2]134 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. 234 Application Note 44: 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 RP_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 RP_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. 235 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/ Rightful_Terminal 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 Protocol135 according to [EACTR], sec. 4.4, Version 2 (for GAP) 136 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 133 RP_Card identifies themselves within the PACE protocol by selection of the authentication key ephem-PKPICC-PACE 134 [assignment: list of TSF-mediated actions] 135 RP_Card identifies themselves within the TA protocol by using the identifier IDPICC = H(ephem- PKPICC-PACE). 136 [assignment: list of TSF-mediated actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 69/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 user. This item concerns the following application(s): ePassport, eID, eSign. 236 Application Note 45: The user authenticated after a successfully performed TA protocol is a Service Provider represented by a rightful terminal, i.e. for GAP: either EIS-GAP or ATT or SGT. The authenticated terminal will immediately perform the Chip Authentica- tion (version 2) as required by FIA_API.1/CA using, amongst other, the terminal's com- pressed ephemeral public key Comp(ephem-PKPCD-TA) from the accomplished TA. Please note that the Passive Authentication using SOC is considered to be part of the CA protocol in the interpretation of the PP [RPCARDPP]. 237 Please note that the Terminal Authentication Protocol according to [EACTR], sec. 4.4, version 1 (for AIP) is covered by [EACPP3.1] (see FIA_UAU.1 there). In this case, the user authenticated after a successfully performed TA protocol is also a Service Provider, concretely, an inspection system using EIS-AIP-BAC. 238 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 2 (for GAP)137. This item concerns the following application(s): ePassport, eID, eSign. 239 Application Note 46: For the PACE protocol, the TOE randomly selects a nonce s of 128 bits length length being (almost) uniformly distributed (the PP [RPCARDPP] 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. Please note that the Terminal Authentication Protocol according to [EACTR], sec. 4.4, version 1 (for AIP) is covered by [EACPP3.1] (see FIA_UAU.4 there). 240 FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. 137 [assignment: identified authentication mechanism(s)] Security Target TCOS Residence Permit Card/SLE78CLX1440P 70/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 FIA_UAU.5.1 The TSF shall provide the General Authentication Procedure as the 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 F138 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 key139 being successfully verifiable up to CVCA and (ii) the terminal uses the PICC identifier140 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 Protocol141. This item concerns the following application(s): ePassport, eID, eSign. 241 Application Note 47: Please note that Chip Authentication Protocol does not authenticate any TOE’s user, but provides evidence enabling an external entity (the terminal connec- ted) to prove the TOE’s identity. Please note that the Chip Authentication Protocol according to [EACTR, sec. 4.3], ver- sion 1 (for AIP) is covered in this context by [EACPP3.1] (see FIA_UAU.5 there). 242 Application Note 48: 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. 243 FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. 138 [assignment: list of multiple authentication mechanisms] 139 PKPCD 140 IDPICC = H(ephem-PKPICC-PACE) 141 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target TCOS Residence Permit Card/SLE78CLX1440P 71/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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- nal142. This item concerns the following application(s): ePassport, eID, eSign. 244 Application Note 49: 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 the ephemeral key Comp(ephem-PKPCD-TA). 245 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application and only the EIS-AIP-BAC terminal. For the functional class FIA, there are the following components: FIA_API.1/ICAO-EAC, FIA_UID.1/ICAO- EAC, FIA_UAU.1/ICAO-EAC, FIA_UAU.4/ICAO-EAC, FIA_UAU.5/ICAO-EAC and FIA_\ UAU.6/ICAO-EAC. According to the RP_Card PP the SFR FIA_UAU.6/ICAO-EAC is covered by other Security Requirements of this ST, therefore it will no be duplicated here. 246 FIA_API.1/ICAO-EAC 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 [EACTR1.11]143 to prove the identity of the TOE144. This item concerns the following application(s): ePassport. 247 Application Note 50: In [EACTR, sec. 4.3] the Chip Authentication Mechanism as speci- fied in [EACTR1.11] is called Chip Authentication Version 1. The terminal verifies by means of secure messaging whether the MRTD’s chip was able or not to run his pro- tocol properly using its Chip Authentication Private Key corresponding to the Chip Authentication Key (EF.DG14). 142 [assignment: list of conditions under which re-authentication is required] 143 [assignment: authentication mechanism] 144 [assignment: authorized user or role] Security Target TCOS Residence Permit Card/SLE78CLX1440P 72/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 248 FIA_UID.1/ICAO-EAC Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/ICAO- EAC The TSF shall allow 1. establishing a communication channel, 2. to read the Initialization Data if it is not disabled by TSF ac- cording to FMT_MTD.1/INI_DIS, 3. carrying out the Chip Authentication Protocol according to [EACTR1.11]145. on behalf of the user to be performed before the user is identified. FIA_UID.1.2/ICAO- EAC 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. 249 Application Note 51: To distinguish the Chip and the Terminal Authentication Mecha- nisms as specified in [EACTR1.11] from the more general protocols with the same deno- tation defined in [EACTR, sec. 4.3] a corresponding refinement was made for the SFRs included from the ICAO-EAC PP [EACPP3.1]. 250 FIA_UAU.1/ICAO-EAC Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/ICAO-EAC. FIA_UAU.1.1/ ICAO-EAC The TSF shall allow 1. establishing a communication channel, 2. to read the Initialization Data if it is not disabled by TSF accord- ing to FMT_MTD.1/INI_DIS, 3. to identify themselves by selection of the authentication key, 4. carrying out the Chip Authentication Protocol according to [EACTR1.11] 146 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/ ICAO-EAC 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. 145 [assignment: list of TSF-mediated actions] 146 [assignment: list of TSF-mediated actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 73/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 251 FIA_UAU.4/ICAO-EAC 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/ ICAO-EAC The TSF shall prevent reuse of authentication data related to147 1. Terminal Authentication Protocol Protocol according to [EACTR1.11], 2. Authentication Mechanism based on AES148. This item concerns the following application(s): ePassport. 252 FIA_UAU.5/ICAO-EAC Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/ ICAO-EAC The TSF shall provide 1. Terminal Authentication Protocol according according to [EACTR1.11], 2. Secure messaging in MAC-ENC mode 3. Symmetric Authentication Mechanism based on AES149 to support user authentication150. FIA_UAU.5.2/ ICAO-EAC The TSF shall authenticate any user’s claimed identity according to the following rules: 1. The TOE accepts the authentication attempt as Personalization Agent by the the Symmetric Authentication Mechanism with Personalization Agent Key, the Terminal Authentication Proto- col with Personalization Agent Keys151. 2. After run of the Chip Authentication Protocol the TOE accepts only received commands with correct message authentication code sent by means of secure messaging with key agreed with the terminal by means of the Chip Authentication Mechanism. 3. The TOE accepts the authentication attempt by means of the Terminal Authentication Protocol only if the terminal uses the public key presented during the Chip Authentication Protocol and the secure messaging established by the Chip Authenti- cation Mechanism152. This item concerns the following application(s): ePassport. 147 [assignment: identified authentication mechanism(s)] 148 [selection: Triple-DES, AES or other approved algorithms ] 149 [selection: Triple-DES, AES or other approved algorithms ] 150 [assignment: list of multiple authentication mechanisms] 151 [selection: the Symmetric Authentication Mechanism with Personalization Agent Key, the Terminal Authentication Protocol with Personalization Agent Keys] 152 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target TCOS Residence Permit Card/SLE78CLX1440P 74/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 253 Application Note 52: The included from the ICAO-EAC PP requirements FIA_UID.1/ ICAO-EAC, FIA_UAU.1/ICAO-EAC, FIA_UAU.4/ICAO-EAC, FIA_UAU.5/ICAO-EAC and FIA_API.1/ICAO-EAC are restricted to the application of an EIS-AIP-BAC terminal, which is the only type of a General Inspection System (GIS in the sense of [EACPP3.1]) supporting Advanced Inspection Procedure version 1 with TDES considered in this ST. They are included in this ST only due to compatibility reasons and are not applicable to other authentication protocols. 254 This ST also includes all SFRs of the ePass_PACE PP [PACEPassPP]. Formally, they only concern the ePassport application. For the functional class FIA, there are the follo- wing components: FIA_AFL.1/PACE_PACE-Pass, FIA_APO.1/PA_PACE-Pass, FIA_\ UID.1/PACE_PACE-Pass, FIA_UAU.1/PACE_PACE-Pass, FIA_UAU.4/PACE-Pass, FIA_\ UAU.5/PACE-Pass, FIA_UAU.6/PACE-Pass. 255 The PP ([RPCARDPP]) demonstrates how the imported requirements are related, equivalent or covered by its corresponding own requirements. Hence it is not repeated here. Note that CA and TA protocols Version 1 are covered by these requirements. 256 This ST 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: 257 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/CA153, 4. establishing a trusted channel between HID and the TOE by means of TSF required by FTP_ITC.1/CA154, 5. none155 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. 153 the authenticated terminal is ATT, cf. FIA_UAU.1/Rightful_Terminal 154 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. 155 [assignment: list of (additional) TSF-mediated actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 75/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 This item concerns the following application(s): ePassport, eID, eSign. SFR identifier Equivalent to / covered by item in the ST Comments FIA_UID.1/SSCD – This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. FIA_AFL.1/SSCD – This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. 258 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 156 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. 259 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]157 unsuccessful authentication attempts occur re- lated to consecutive failed authentication attempts158. FIA_AFL.1.2/SSCD When the defined number of unsuccessful authentication at- tempts has been met159, the TSF shall block RAD160. 156 [assignment: list of additional TSF-mediated actions] 157 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 158 [assignment: list of authentication events] 159 [selection: met, surpassed] 160 [assignment: list of actions] Security Target TCOS Residence Permit Card/SLE78CLX1440P 76/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 6.1.4 Class FDP User Data Protection 260 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 161 on terminals gaining write, read, modification and usage access to the User Data stored in the RP_Card 162. This item concerns the following application(s): ePassport, eID, eSign. 261 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 SFP163 to objects based on the following: 1. Subjects: a. Terminal, b. PACE Terminal (PCT eqiv BIS-PACE), c. Rightful Terminal (EIS-AIP-BAC, EIS-GAP, ATT, SGT); 2. Objects: User Data stored in the TOE; 3. Security attributes: a. Authentication status of terminals, b. Terminal Authorization Level, c. CA authentication status, d. Authentication status of the RP_Card holder as Signatory (if the eSign is operational)164. 161 [assignment: access control SFP] 162 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 163 [assignment: access control SFP] Security Target TCOS Residence Permit Card/SLE78CLX1440P 77/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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-GAP) 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 Generation165) 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 RP_Card holder as Signatory as required by FIA_UAU.1/SSCD166. FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: 1. A successfully authenticated EIS-AIP-BAC is allowed to read User Data (only DG3 and DG4) according to [EACTR], sec. 1.1 (ICAO/EAC version 1), G.3 and C.4.1 after a successful TA as required by FIA_UAU.1/ICAO-EAC (this rule is inherited from [PACEPassPP]). 2. A BIS-PACE (PCT) is allowed to read User Data (except DG3167 and DG4168) according to [EACTR], sec. 1.1 and G.2 after a successful PACE authentication as required by FIA_UAU.1/PACE_PACE-Pass (this rule is inherited from [PACEPassPP])169. FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. Any terminal being not authenticated as a rightful terminal (i.e. as either BIS-PACE or EIS-AIP-BAC or EIS-GAP or ATT or SGT) is not allowed to read, to write, to modify, to use any User Data stored on the RP_Card. 2. Nobody is allowed to read ‘TOE immanent secret cryptographic keys’ stored on the RP_Card. 164 [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] 165 as required by FCS_CKM.1/SSCD 166 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 167 biometric: finger 168 biometric: iris 169 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] Security Target TCOS Residence Permit Card/SLE78CLX1440P 78/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 3. Nobody is allowed to read ‘secret RP_Card holder authentication data’ stored on the RP_Card. 4. Nobody is allowed to read the private Restricted Identification (SKID) key stored on the RP_Card. 5. Nobody is allowed to read the private signature key(s) within within the eSign application (SCD; if the eSign application is operational170. This item concerns the following application(s): ePassport, eID, eSign. 262 Application Note 53: 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. 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 RP_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]). 263 Application note 54: Please note that the Card/Chip Security Object (SOC) does not belong to the user data, but to the TSF data. Read access to the Card/Chip Security Object is ruled by [EACTR, A.1.2, Table A.1] for EF.CardSecurity/EF.ChipSecurity, respectively. Also the Document Security Object (SOD) stored in EF.SOD (see [ICAO9303-1], sec. A.10.4) does not belong to the user data, but to the TSF data. The Document Security Object can be read out by the PCT as well as after accomplishing the BAC procedure, see [EACTR, G.1]. The Card/Chip Security Object can be read out by the PCT, see [EACTR], A.1.2 and table A.1 for EF.CardSecurity. 264 Application Note 55: 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 RP_Card holder. 265 Application note 56: Please note that the control on the user data transmitted between the TOE and the rightful terminal is addressed by FTP_ITC.1/CA. 266 FDP_RIP.1 Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. 170 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS Residence Permit Card/SLE78CLX1440P 79/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 from171 the following objects: 1. the Chip Authentication Private Key (SKPICC), 2. the secret RP_Card holder authentication data eID-PIN, eID- PUK, eSign-PIN (RAD, if eSign application is operational), (when their temporarily stored values are not to use any more), 3. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc) (by closing related communication session), 4. the ephemeral private key ephem-SKPICC-PACE (by having generated a DH shared secret K172), 5. the private Restricted Identification key SKID, (when its tempo- rarily stored value is not to use any more), 6. the private signature key of the RP_Card holder (SCD; if the eSign application is operational) (when its temporarily stored value is not to use any more), 7. none173. This item concerns the following application(s): ePassport, eID, eSign. 267 Application Note 57: 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. 268 Application Note 58: Please note that FDP_RIP.1 also contributes to achievement of OT.Sigy_SigF (eSign-PIN) and OT.SCD_Secrecy (SCD) from [SSCDPP]. 269 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application. For the functional class FDP, there are the following components: FDP_ACC.1/ICAO-EAC, FDP_ACF.1/ICAO-EAC, FDP_UCT.1/ICAO-EAC, FDP_UIT.1/ICAO-EAC. 270 This ST also includes all SFRs of the PACE-Pass PP [PACEPassPP]. Formally, they only concern the ePassport application. For the functional class FDP, there are the following components: FDP_ACC.1/TRM_PACE-Pass, FDP_ACF.1/TRM_PACE-Pass, FDP_RIP.1/PACE-Pass,. 271 The PP ([RPCARDPP]) demonstrates how the imported requirements are related, equi- valent or covered by its corresponding own requirements. Hence it is not repeated here. 272 This ST 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 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD FDP_ACC.1/SVD_Transfer_SFP_SSCD 171 [selection: allocation of the resource to, de-allocation of the resource from] 172 according to [EACTR], sec. 4.2.1, #3.b 173 [assignment: list of objects] Security Target TCOS Residence Permit Card/SLE78CLX1440P 80/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 SFR identifier Comments FDP_ACF.1/SVD_Transfer_SFP_SSCD FDP_ACC.1/Signature-creation_SFP_SSCD FDP_ACF.1/Signature-creation_SFP_SSCD FDP_RIP.1/SSCD FDP_RIP.1 contributes to achievement of OT.Sigy_SigF (eSign-PIN) and OT.SCD_Secrecy (SCD) FDP_SDI.2/Persistent_SSCD FDP_SDI.2/DTBS_SSCD 273 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 274 Application Note 59: 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. 275 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. FDP_ACC.1.1/SCD/ SVD_Generation_ SFP_SSCD The TSF shall enforce the SCD/SVD Generation SFP174 on 1. subjects: S.User 2. objects: SCD, SVD 3. operations: generation of SCD/SVD pair175. 276 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD Security attribute based access control Hierarchical to: No other components. 174 [assignment: access control SFP] 175 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target TCOS Residence Permit Card/SLE78CLX1440P 81/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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_SFP176 to objects based on the following: the user S.User is associated with the security attribute “SCD/SVD Management“177. 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 pair178. 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: none179. 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 pair180. 277 FDP_ACC.1/SVD_Transfer_SFP_SSCD Subset access control Hierarchical to: No other components. 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_SFP181 on 1. subjects: S.User, 2. objects: SVD, 3. operations: export182. 176 [assignment: access control SFP] 177 [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] 178 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 179 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 180 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 181 [assignment: access control SFP] 182 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target TCOS Residence Permit Card/SLE78CLX1440P 82/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 278 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_SFP183 to objects ba- sed on the following: 1. the S.User is associated with the security attribute Role, 2. the SVD184. 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 185 is allowed to export SVD186. FDP_ACF.1.3/ SVD_Transfer_SFP The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none187. FDP_ACF.1.4/ SVD_Transfer_SFP The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none188. 279 FDP_ACC.1/Signature_Creation_SFP_SSCD Subset 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 FDP_ACC.1.1/Sig- nature-creation_ SFP_SSCD The TSF shall enforce the Signature-creation_SFP189 on 1. subjects: S.User, 2. objects: DTBS/R, SCD, 3. operations: signature-creation190. 183 [assignment: access control SFP] 184 [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] 185 [selection: R.Admin, R.Sigy ] 186 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 187 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 188 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 189 [assignment: access control SFP] 190 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target TCOS Residence Permit Card/SLE78CLX1440P 83/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 280 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/Sig- nature-creation_ SFP_SSCD The TSF shall enforce the Signature-creation_SFP191 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”192. 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 193. 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: none194. 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”195. 281 FDP_SDI.2/Persistent_SSCD Stored data integrity monitoring and action 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 error196 on all objects, based on the fol- lowing attributes: integrity checked stored data197. 191 [assignment: access control SFP] 192 [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] 193 [assignment: rules governing access among controlled subjects and controlled objects using con- trolled operations on controlled objects] 194 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to ob- jects] 195 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS Residence Permit Card/SLE78CLX1440P 84/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 error198. 282 FDP_SDI.2/DTBS_SSCD Stored data integrity monitoring and action 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 error199 on all objects, based on the fol- lowing attributes: integrity checked stored DTBS200. 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 error201. 6.1.5 Class FTP Trusted Path/Channels 283 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 PCT202 to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate enforce communication via the trusted channel for any data exchange between the TOE and the PCT after PACE203. 196 [assignment: integrity errors] 197 [assignment: user data attributes] 198 [assignment: action to be taken] 199 [assignment: integrity errors] 200 [assignment: user data attributes] 201 [assignment: action to be taken] 202 [selection: the TSF, another trusted IT product] 203 [assignment: list of functions for which a trusted channel is required] Security Target TCOS Residence Permit Card/SLE78CLX1440P 85/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 This item concerns the following application(s): ePassport, eID, eSign. 284 Application note 60: 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 Authen- tication; the cryptographic primitives being used for the secure messaging are as requi- red by FCS_COP.1/AES and FCS_COP.1/CMAC. The PACE secure messaging session is immediately superseded by a CA secure mes- saging 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. 285 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)204 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 Authentication205. This item concerns the following application(s): ePassport, eID, eSign. 286 Application Note 61: The trusted channel is established after successful performing the PACE protocol (FIA_UAU.1/PACE), the TA protocol (FIA_UAU.1/Rightful_Terminal for GAP or FIA_UAU.1/ICAO-EAC for AIP) and the CA protocol (FIA_API.1/CA for GAP or FIA_API.1/ICAO-EAC for AIP). If the Chip Authentication was successfully performed, secure messaging is immediately restarted using the derived session keys (CA-KMAC, CA-KEnc)206: this secure messaging enforces the required properties of operational trus- ted channel; the cryptographic primitives being used for the secure messaging are as required by (i) FCS_COP.1/AES and FCS_COP.1/CMAC for GAP or (ii) FCS_COP.1/ SYM_ICAO-EAC and FCS_COP.1/MAC_ICAO-EAC for AIP being compliant with the ICAO EAC PP [EACPP3.1]. 204 [selection: the TSF, another trusted IT product] 205 [assignment: list of functions for which a trusted channel is required] 206 otherwise, secure messaging is continued using the previously established session keys (PACE- KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE Security Target TCOS Residence Permit Card/SLE78CLX1440P 86/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 287 Application Note 62: Please note that the control on user data stored in the TOE is ad- dressed by FDP_ACF.1/TRM. 288 Application note 63: The requirement FTP_ITC.1/CA also covers a secure transport of (i) SVD207 from the TOE to CGA208 as well as of (ii) VAD209 from HID210 and of (iii) DTBS211 from SCA to the TOE. It also covers TOE’s capability to generate and to pro- vide 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 com- paring to [SSCDPP]. 289 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. For the functional class FTP, there are no components there. 290 This ST also includes all SFRs of the PACE-Pass PP [PACEPassPP]. Formally, they only concern the ePassport application. For the functional class FTP there is only one component FTP_ITC.1/PACE_PACE-Pass covered by FTP_ITC.1/PACE from the PP ([RPCARDPP]). 291 This ST also includes all SFRs of the SSCD PP [SSCDPP]. For the functional class FTP, there are no components there. 6.1.6 Class FAU Security Audit 292 FAU_SAS.1 Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide the Manufacturer212 with the capability to store the Initialization and Pre-Personalization Data 213 in the audit records. This item concerns the following application(s): ePassport, eID, eSign. 293 Application Note 64: The Manufacturer role is the default user identity assumed by the TOE in the life phase ‘manufacturing’. The IC manufacturer and the RP_Card manufac- 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 RP_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. 207 integrity is to secure 208 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] 209 confidentiality is to secure 210 the authenticated terminal is SGT 211 integrity is to secure 212 [assignment: authorized users] 213 [assignment: list of audit information] Security Target TCOS Residence Permit Card/SLE78CLX1440P 87/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 294 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. For the functional class FAU, there is only one component FAU_SAS.1/ICAO-EAC covered by FAU_SAS.1 from the PP ([RPCARDPP]). 295 This ST also includes all SFRs of the PACE-Pass PP [PACEPassPP]. For the functional class FAU, there is only one component FAU_SAS.1/PACE-Pass covered by FAU_\ SAS.1 from the PP ([RPCARDPP]). 296 This ST also includes all SFRs of the SSCD PP [SSCDPP]. For the functional class FAU there are no components there. 6.1.7 Class FMT Security Management 297 Application Note 65: The SFR FMT_SMF.1 and FMT_SMR.1 provide basic requirements to the management of the TSF data. 298 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-PIN214, 5. Activate and deactivate the eID-PIN215. This item concerns the following application(s): ePassport, eID, eSign. 299 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. 214 unblocking eSign-PIN is managed by FMT_SMF.1/SSCD 215 [assignment: list of management functions to be provided by the TSF] Security Target TCOS Residence Permit Card/SLE78CLX1440P 88/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 equiv. BIS-PACE), 7. Extended Inspection System using AIP with BAC(EIS-AIP- BAC), 8. Extended Inspection System using GAP (EIS-GAP), 9. Authentication Terminal (ATT), 10. Signature Terminal (SGT), 11. RP_Card holder216 . FMT_SMR.1.2 The TSF shall be able to associate users with roles. This item concerns the following application(s): ePassport, eID, eSign. 300 Application Note 66: For the explanation on the role Manufacturer please refer to the Application Note 64; on the role Personalization Agent – to the Application Note 43. 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 RP_Card presenter). The). The roles CVCA, DV, EIS, ATT217 and SGT are recognized by analyzing the current Terminal Certificate CT, cf. [EACTR, C.4] (FIA_UID.1/Rightful_Terminal GAP or FIA_UAU.1/ ICAO-EAC for AIP). The TOE recognizes the RP_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 appli- cation – by using SGT upon input VAD (eSign-PIN) governed by FIA_UAU.1/SSCD . 301 Application Note 67: 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. 302 FMT_LIM.1 Limited capabilities Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2. 216 [assignment: the authorized identified roles] 217 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 a terminal authorization level is authorized by the related CSP to act as CGA on its behalf. Security Target TCOS Residence Permit Card/SLE78CLX1440P 89/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 4. substantial information about construction of TSF to be gathered which may enable other attacks218. This item concerns the following application(s): ePassport, eID, eSign. 303 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 attacks219. This item concerns the following application(s): ePassport, eID, eSign. 304 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 write220 the Initialization Data and Pre-personalization Data221 to the Manufacturer222. This item concerns the following application(s): ePassport, eID, eSign. 218 [assignment: Limited capability and availability policy] 219 [assignment: Limited capability and availability policy] 220 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 221 [assignment: list of TSF data] 222 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 90/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 305 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 FMT_MTD.1.1/ INI_DIS The TSF shall restrict the ability to read out and to use223 the Initialization Data224 to the Personalization Agent225. This item concerns the following application(s): ePassport, eID, eSign. 306 Application Note 68: 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 ‘manu- facturing’ 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 43. 307 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 write226 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. none227 to the Personalization Agent228. 223 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 224 [assignment: list of TSF data] 225 [assignment: the authorized identified roles] 226 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 227 [assignment: list of TSF data] 228 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 91/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 This item concerns the following application(s): ePassport, eID, eSign. 308 Application Note 69: 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 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]). 309 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 update229 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. none230 to Country Verifying Certification Authority231. This item concerns the following application(s): ePassport, eID, eSign. 310 Application Note 70: 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). 311 FMT_MTD.1/DATE Management of TSF data – Current date Hierarchical to: No other components. 229 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 230 [assignment: list of TSF data] 231 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 92/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 modify232 the Current Date233 to 1. Country Verifying Certification Authority, 2. Document Verifier, 3. Rightful Terminal (EIS, ATT or SGT) possessing an Accurate Terminal Certificate234. This item concerns the following application(s): ePassport, eID, eSign. 312 Application Note 71: 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 Authori- zation in the card verifiable certificate provided by the terminal for the identification and the Terminal Authentication (cf. [EACTR], A.6.2.3, B.11.1, C.1.3, C.1.5, D.2 for details). 313 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/P A_UPD The TSF shall restrict the ability to write235 the Card/Chip Security Object (SOC) and the Document Security Object (SOD)236 to the Personalization Agent237. This item concerns the following application(s): ePassport, eID, eSign. 314 Application Note 72: By writing SOC and SOD into the TOE, the Personalization Agent confirms (on behalf of DS) the correctness and genuineness of all the personalization data related. The latter consist of user data and TSF data, as well. Due to this fact and to the scope of the SFR FMT_MTD.1 (management of TSF-data), the entire set of the per- sonalization data is formally not addressed above. Nevertheless, FMT_MTD.1/PA_UPD shall be understood in the following way: ‘The TSF shall restrict the ability to write the personalization data to the Personalization Agent.’ On the role ‘Personalization Agent’ please refer to the Application Note 43. 232 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 233 [assignment: list of TSF data] 234 [assignment: the authorized identified roles] 235 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 236 [assignment: list of TSF data] 237 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 93/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 315 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 create238 the Chip Authentication Private Key (SKPICC)239 to Personalization Agent 240. This item concerns the following application(s): ePassport, eID, eSign. 316 Application Note 73: 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. 317 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 read241 the Chip Authentication Private Key (SKPICC)242 to none243. This item concerns the following application(s): ePassport, eID, eSign. 318 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. 238 [selection: create, load]/[selection: change_default, query, modify, delete, clear, [assignment: other operations]] 239 [assignment: list of TSF data] 240 [assignment: the authorized identified roles] 241 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 242 [assignment: list of TSF data] 243 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 94/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 FMT_MTD.1.1/ eID-PIN_Resume The TSF shall restrict the ability to resume244 the suspended eID- PIN245 to the RP_Card holder246. This item concerns the following application(s): eID. 319 Application Note 74: 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 RP_Card holder is authenticated as required by FIA_UAU.1/PACE using the eID- PIN as the shared password. 320 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 change247 the blocked eID-PIN248 to 1. the RP_Card holder, 2. the Authentication Terminal (ATT) with the Terminal Authorization Level for eID-PIN management249. This item concerns the following application(s): eID. 321 Application Note 75: 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 RP_Card holder being authenticated as required by FIA_UAU.1/PACE using the eID-PUK as the shared password or (ii) the ATT (FIA_UAU.1/Rightful_Terminal) proved the Terminal Authorization Level being sufficient for eID-PIN management (FDP_ACF.1/TRM). 322 FMT_MTD.1/eID-PIN_Activate Management of TSF data – Activating/Deactivating eID-PIN Hierarchical to: No other components. 244 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 245 [assignment: list of TSF data] 246 [assignment: the authorized identified roles] 247 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 248 [assignment: list of TSF data] 249 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 95/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 deactivate250 the eID-PIN251 to the Authentication Terminal (ATT) with the Terminal Authorization Level for eID-PIN management252. This item concerns the following application(s): eID, eSign. 323 Application Note 76: The activating/deactivating procedures must be implemented accor- ding to [EACTR, sec. 3.5.2]. It can be triggered by the ATT (FIA_UAU.1/Rightful_Termi- nal) that proved a Terminal Authorization Level being sufficient for eID-PIN management (FDP_ACF.1/TRM). 324 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 SFP253. 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, (2) the digital signature of the Document Verifier Certificate (CDV) has been veri- fied as correct using the public key in the Certificate of the Country Veri- fying 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 expi- ration 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 termi- nal. 250 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 251 [assignment: list of TSF data] 252 [assignment: the authorized identified roles] 253 [assignment: list of TSF data] Security Target TCOS Residence Permit Card/SLE78CLX1440P 96/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 The intersection of the Certificate Holder Authorizations contained in the cer- tificates of a valid certificate chain is a secure value for Terminal Authorization Level254 of a successful authenticated Service Provider (represented by a right- ful terminal). This item concerns the following application(s): ePassport, eID, eSign. 325 Application Note 77: 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. 326 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application. For the functional class FMT, there are the following components: FMT_SMF.1/ICAO-EAC, FMT_SMR.1/ICAO-EAC, FMT_LIM.1/ICAO-EAC, FMT_LIM.2/ICAO-EAC, FMT_MTD.1/INI_ENA_ICAO-EAC, FMT_MTD.1/INI_DIS_ICAO- EAC, FMT_MTD.1/CVCA_INI_ICAO-EAC, FMT_MTD.1/CVCA_UPD_ICAO-EAC, FMT_\ MTD.1/DATE_ICAO-EAC, FMT_MTD.1/KEY_WRITE_ICAO-EAC, FMT_MTD.1/CAPK_\ ICAO-EAC, FMT_MTD.1/KEY_READ_ICAO-EAC, FMT_MTD.3/ICAO. Note that for BAC (EIS-AIP-BAC), the Document Basic Access Keys are derived from the value of the MRZ for the concrete instantiation of the TOE. Therefore, the Document Basic Access Keys are considered as a part of personalization data. FMT_MTD.1/KEY_READ covers the Document Basic Access Keys inherited from the ICAO-EAC PP. The concept of Perso- nalization Agent Keys is covered by using an ATT proven a sufficient Terminal Authori- zation Level. 327 This ST also includes all SFRs of the PACE-Pass PP [PACEPassPP]. Formally, they only concern the ePassport application. For the functional class FMT there are the fol- lowing components: FMT_SMF.1/PACE-Pass, FMT_SMR.1/PACE-Pass, FMT_LIM.1/ PACE-Pass, FMT_LIM.2/PACE-Pass, FMT_MTD.1/INI_ENA_PACE-Pass, FMT_MTD.1/ INI_DIS_PACE-Pass, FMT_MTD.1/PA_UPD_PACE-Pass. 328 The PP ([RPCARDPP]) demonstrates how the imported requirements are equivalent to or covered by its own requirements. Hence it is not repeated here. Additionally the use of Triple-DES and Retail-MAC is allowed (cf. Application Notes 32 and 33 on p. 58f) 329 This ST 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 follo- wing components: SFR identifier Comments FMT_SMR.1/SSCD R.Sigy is represented by the RP_Card holder, and R.Admin by the Personalization Agent, therefore it is covered by FMT_SMR.1 FMT_SMF.1/SSCD – FMT_MOF.1/SSCD – 254 This certificate-calculated Terminal Authorisation Level can additionally be restricted by RP_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 RP_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 Residence Permit Card/SLE78CLX1440P 97/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 SFR identifier Comments FMT_MSA.1/Admin_SSCD – FMT_MSA.1/Signatory_SSCD – FMT_MSA.2/SSCD – FMT_MSA.3/SSCD – FMT_MSA.4/SSCD – FMT_MTD.1/Admin_SSCD – FMT_MTD.1/Signatory_SSCD 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. 330 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 Identi- fier, 5. none255 . 331 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 FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCD. FMT_MOF.1.1/ SSCD The TSF shall restrict the ability to enable256 the functions signa- ture-creation function257 to R.Sigy258. 332 FMT_MSA.1/Admin_SSCD Management of security attributes 255 [assignment: list of management functions to be provided by the TSF]/[assignment: list of other security management functions to be provided by the TSF] 256 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 257 [assignment: list of functions] 258 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 98/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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, 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_SFP259 to restrict the ability to modify260 the security attributes SCD/SVD manage- ment261 to R.Admin262. 333 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 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_SFP263 to restrict the ability to modify264 the security attributes SCD operational265 to R.Sigy266. 334 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 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 259 [assignment: access control SFP(s), information flow control SFP(s)] 260 [selection: change_default, query, modify, delete, [assignment: other operations]] 261 [assignment: list of security attributes] 262 [assignment: the authorized identified roles] 263 [assignment: access control SFP(s), information flow control SFP(s)] 264 [selection: change_default, query, modify, delete, [assignment: other operations]] 265 [assignment: list of security attributes] 266 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 99/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 FMT_MSA.2.1/ SSCD The TSF shall ensure that only secure values are accepted for SCD/SVD Management and SCD operational267. 335 Application Note 78: 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. 336 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 FMT_MSA.3.1/ SSCD The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_ Transfer_SFP and Signature-creation_SFP268 to provide restricti- ve269 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/ SSCD The TSF shall allow the R.Admin270 to specify alternative initial values to override the default values when an object or informa- tion is created. 337 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 S.Sigy being authenticated the security attribute “SCD operatio- nal” 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 267 [selection: list of security attributes] 268 [assignment: access control SFP, information flow control SFP] 269 [selection choose one of: restrictive, permissive, [assignment: other property]] 270 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 100/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 single operation271. 338 Application Note 79: Because the TOE does not support SCD/SVD generation by the Signatory alone, the rule (2) is not relevant here. 339 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 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 create272 the RAD273 to R.Admin274. 340 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 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 modify275 the RAD276 to R.Sigy277. 6.1.8 Class FPT Protection of the Security Functions 341 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)”, “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. 271 [assignment: rules for setting the values of security attributes] 272 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 273 [assignment: list of TSF data] 274 [assignment: the authorized identified roles] 275 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 276 [assignment: list of TSF data] 277 [assignment: the authorized identified roles] Security Target TCOS Residence Permit Card/SLE78CLX1440P 101/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 342 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 278 in excess of non-useful information 279 ena- bling access to 1. the Chip Authentication Private Key (SKPICC), 2. the eID-PIN, eID-PUK, eSign-PIN (RAD; if the eSign is opera- tional)280 3. none281 and 4. the private Restricted Identification key SKID, 5. the private signature key of the RP_Card holder (SCD; if the eSign is operational)282. 6. none283 FPT_EMSEC.1.2 The TSF shall ensure any users284 are unable to use the following interface RP_Card’s contactless interface and circuit contacts285 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), 3. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc), 4. the ephemeral private key ephem-SKPICC-PACE286 5. none287 and 6. the private Restricted Identification key SKID, 7. the private signature key of the RP_Card holder (SCD; if the eSign is operational)288. 8. none289. This item concerns the following application(s): ePassport, eID, eSign. 343 Application Note 80: The TOE prevents attacks against the listed secret data where the attack is based on external observable physical phenomena of the TOE. Such attacks 278 [assignment: types of emissions] 279 [assignment: specified limits] 280 [assignment: list of types of TSF data] 281 [assignment: list of types of (further) TSF data] 282 [assignment: list of types of user data] 283 [assignment: list of types of (further) user data] 284 [assignment: type of users] 285 [assignment: type of connection] 286 [assignment: list of types of TSF data] 287 [assignment: list of types of (further) TSF data] 288 [assignment: list of types of user data] 289 [assignment: list of types of (further) user data] Security Target TCOS Residence Permit Card/SLE78CLX1440P 102/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 RP_Card’s chip has to provide a smart card contactless interface, but may have also (not used by the ter- minal, but maybe by an attacker) sensitive contacts according to ISO/IEC 7816-2 as well. 344 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 290. This item concerns the following application(s): ePassport, eID, eSign. 345 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 operation291 to demonstrate the correct operation of the TSF292. FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of TSF data293. FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of stored TSF executable code294. This item concerns the following application(s): ePassport, eID, eSign. 346 Application Note 81: The RP_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 stored TSF executable code required by FPT_TST.1.3 is executed during initial start-up 290 [assignment: list of types of failures in the TSF] 291 [selection: during initial start-up, periodically during normal operation, at the request of the author- ized user, at the conditions [assignment: conditions under which self test should occur]] 292 [selection: [assignment: parts of TSF], the TSF] 293 [selection: [assignment: parts of TSF], TSF data] 294 [selection: [assignment: parts of TSF], TSF] Security Target TCOS Residence Permit Card/SLE78CLX1440P 103/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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. 347 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 probing295 to the TSF296 by responding automatically such that the SFRs are always enforced. This item concerns the following application(s): ePassport, eID, eSign. 348 Application Note 82: The TOE 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. 349 This ST also includes all SFRs of the ICAO-EAC PP [EACPP3.1]. Formally, they only concern the ePassport application. For the functional class FPT, there are the following components: FPT_EMSEC.1/ICAO-EAC, FPT_FLS.1/ICAO-EAC, FPT_TST.1/ICAO- EAC, FPT_PHP.3/ICAO-EAC. 350 This ST also includes all SFRs of the PACE-Pass PP [PACEPassPP]. Formally, they on- ly concern the ePassport application. For the functional class FPT there are the following components: FPT_EMSEC.1/PACE-Pass, FPT_FLS.1/PACE-Pass, FPT_TST.1/PACE- Pass, FPT_PHP.3/PACE-Pass. 351 The PP ([RPCARDPP]) demonstrates how the imported requirements are equivalent to or are covered by its own requirements. Hence it is not repeated here. 352 This ST 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 fol- lowing 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 295 [assignment: physical tampering scenarios] 296 [assignment: list of TSF devices/elements] Security Target TCOS Residence Permit Card/SLE78CLX1440P 104/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 SFR identifier Comments 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 353 FPT_PHP.1/SSCD Passive detection of physical attack Hierarchical to: No other components. 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 354 The assurance requirements for the evaluation of the TOE, its development and ope- rating environment are to choose as the predefined assurance package EAL4 augmen- ted 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 355 The following table provides an overview for security functional requirements coverage. It replicates the corresponding table 24 of the Protection Profile [RPCARDPP]. The mis- sing columns are moved to the next table related to the SSCD PP [SSCDPP]. Security Target TCOS Residence Permit Card/SLE78CLX1440P 105/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 OT.Identification OT.Personalization OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction 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 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/SYM_ICAO-EAC x x x x FCS_COP.1/CMAC x x x FCS_COP.1/MAC_ICAO-EAC x 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 FIA_API.1/CA x x x x FIA_API.1/ICAO-EAC x FIA_APO.1/PA_PACE-Pass x x FIA_UID.1/PACE x x x FIA_UID.1/Rightful_Terminal x x x x FIA_UID.1/ICAO-EAC x x x FIA_UAU.1/PACE x x x FIA_UAU.1/Rightful_Terminal x x x x FIA_UAU.1/ICAO-EAC x x x FIA_UAU.4 x x x FIA_UAU.4/ICAO-EAC x x x FIA_UAU.5 x x x FIA_UAU.5/ICAO-EAC 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 Security Target TCOS Residence Permit Card/SLE78CLX1440P 106/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 OT.Identification OT.Personalization OT.Data_Integrity OT.Data_Authenticity OT.Data_Confidentiality OT.Tracing OT.Chip_Auth_Proof OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Phys-Tamper OT.Prot_Malfunction 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 FPT_PHP.3 x x x Table 15: Coverage of Security Objectives for the TOE by SFR 356 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 above. For convienence the table of mappings is given below. Note that according to Table 9 the objectives OT.DTBS_Integrity_TOE, OT.EMSEC_Design, OT.Prot_Phys-Tamper, OT.Prot_Malfunction and OT.Tamper_Resistance identified in the SSCD PP are replaced by the corresponding ST objectives OT.Data_integrity, OT.Prot_Inf_Leak, OT.Tamper_ID and OT.Prot_Phys-Tamper. Security Target TCOS Residence Permit Card/SLE78CLX1440P 107/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 OT.Lifecycle_Security OT.SCD/SVD_Gen OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.Sigy_SigF OT.Data_integrity (OT.DTBS_Integrity_TOE) OT.Prot_Inf_Leak (OT.EMSEC_Design) OT.Tamper_ID (OT.Prot_Phys-Tamper and OT.Prot_Malfunction OT.Prot_Phys-Tamper (OT.Tamper_Resistance) FCS_CKM.1/SSCD x x x x FCS_CKM.4 x x FCS_COP.1/SSCD x x FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD x x FDP_ACC.1/SVD_Transfer_SFP_SSCD x FDP_ACC.1/Signature-creation_SFP_SSCD x x FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD x x FDP_ACF.1/SVD_Transfer_SFP_SSCD x FDP_ACF.1/Signature-creation_SFP_SSCD x x FDP_RIP.1 x x FDP_SDI.2/Persistent_SSCD x x x FDP_SDI.2/DTBS_SSCD x x FIA_AFL.1/SSCD x FIA_UAU.1/SSCD x x FIA_UID.1/SSCD x x FMT_MOF.1/SSCD x x FMT_MSA.1/Admin_SSCD x x FMT_MSA.1/Signatory_SSCD x x FMT_MSA.2/SSCD x x x FMT_MSA.3/SSCD x x x FMT_MSA.4/SSCD x x x FMT_MTD.1/Admin_SSCD x x FMT_MTD.1/Signatory_SSCD x x FMT_SMR.1 x x FMT_SMF.1/SSCD x x FPT_EMSEC.1 x x FPT_FLS.1 x FPT_PHP.1/SSCD x FPT_PHP.3 x x FPT_TST.1 x x x Table 16: Coverage of Security Objectives for the TOE by SFR Security Target TCOS Residence Permit Card/SLE78CLX1440P 108/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 357 A detailed justification required for suitability of the security functional requirements to achieve the security objectives is given in the PP ([RPCARDPP]) and repeated below. 358 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. 359 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_Terminal297. 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. 360 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. Unauthorized 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_Termi- nal, FIA_UAU.1/Rightful_Terminal (is supported by FCS_COP.1/SIG_VER). The TA pro- tocol 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_APO.1/ PA_PACE-Pass requires performing Passive Authentication using SOD for enabling the verification of the integrity of User Data stored on the TOE. FIA_UAU.4, FIA_UAU.5 and FCS_CKM.4 represent some required specific properties of the protocols used. This also applies to FIA_UAU.4/ICAO-EAC, FIA_UAU.5/ICAO-EAC, FCS_CKM.4 and the Advanced Inspection Procedure for EIS-AIP-BAC terminals. 297 These Requirements are supported by the related FCS-components. The author of the PP dis- pensed 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 Residence Permit Card/SLE78CLX1440P 109/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 or FCS_COP.1/SYM_ICAO-EAC and FCS_COP.1/ MAC_ICAO-EAC related to secure messaging for a EIS-AIP-BAC terminal. A prerequi- site for establishing the 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 and for EIS-AIP-BAC terminals the corresponding FIA_API.1/ICAO-EAC, FIA_UAU.5/ICAO-EAC. The CA provides an evidence of possessing the Chip Authen- tication 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 requi- res 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. 361 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 verifica- tion 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 or FCS_\ COP.1/SYM_ICAO-EAC and FCS_COP.1/MAC_ICAO-EAC related to secure messa- ging for a EIS-AIP-BAC terminal. A prerequisite for establishing the 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 ses- sion keys (here: for KMAC). FIA_APO.1/PA_PACE-Pass requires performing Passive Authentication using SOD for enabling the verification of the authenticity of User Data stored on the TOE. 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. 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. This also applies to FIA_UAU.4/ICAO-EAC, FIA_UAU.5/ICAO-EAC, FCS_CKM.4 and the Advanced Inspection Procedure for EIS-AIP-BAC terminals. Security Target TCOS Residence Permit Card/SLE78CLX1440P 110/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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. 362 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. This also applies to FIA_UAU.4/ICAO-EAC, FIA_UAU.5/ICAO-EAC, FCS_CKM.4 and the Advanced Inspection Procedure for EIS-AIP-BAC terminals. 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 or FCS_COP.1/SYM_ICAO-EAC and FCS_COP.1/MAC_ICAO-EAC related to secure messaging for a EIS-AIP-BAC terminal. A prerequisite for establishing the 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 (including the corresponding iterations for EIS-AIP-BAC terminals). 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 ses- sion 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 Per- sonalization 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. 363 The security objective OT.Tracing aims that the TOE prevents gathering TOE tracing data by means of unambiguous identifying the RP_Card remotely through establishing or listening to a communication via the contactless interface of the TOE without a priori knowledge of the correct 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 authentica- Security Target TCOS Residence Permit Card/SLE78CLX1440P 111/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 tion 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) – by 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) – by FTP_ITC.1/CA. 364 The security objective OT.Chip_Auth_Proof aims enabling verification of the authenti- city 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 ope- rations 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 Perso- nalization Agent only and, hence, is to consider as trustworthily. 365 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. 366 The security objective OT.Prot_Inf_Leak aims protection against disclosure of confiden- tial User- or/and TSF-data stored on / processed by the TOE. 367 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. 368 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. 369 The security objective OT.Prot_Malfunction aims ensuring a correct operation of the TOE by preventing its operation outside the normal operating conditions. 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. 370 The TOE Security Requirements sufficiency given in Chapter 11.1.2 of the SSCD PP shows that the objectives from that PP are supported by the SFRs from the TOE. 371 OT.Lifecycle_Security (Lifecycle security) is provided by the SFR for SCD/SVD generation FCS_CKM.1/SSCD, SCD usage FCS_COP.1/SSCD and SCD destruction FCS_CKM.4 ensure cryptographically secure lifecycle of the SCD. The SCD/SVD Security Target TCOS Residence Permit Card/SLE78CLX1440P 112/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 generation is controlled by TSF according to FDP_ACC.1/SCD/SVD_Generation_\ SFP_SSCD and FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD. The SVD transfer for certificate generation is controlled by TSF according to FDP_ACC.1/SVD_Transfer_\ SFP_SSCD and FDP_ACF.1/SVD_Transfer_SFP_SSCD. The SCD usage is ensured by access control FDP_ACC.1/Signature-creation_SFP_SSCD, FDP_AFC.1/Signature-cre- ation_SFP_SSCD which is based on the security attribute secure TSF management according to FMT_MOF.1/SSCD, FMT_MSA.1/Admin_SSCD, FMT_MSA.1/ Signatory_\ SSCD, FMT_MSA.2/SSCD, FMT_MSA.3/SSCD, FMT_MSA.4/SSCD, FMT_MTD.1/ Admin_SSCD, FMT_MTD.1/Signatory_SSCD, FMT_SMF.1/SSCD and FMT_SMR.1. The test functions FPT_TST.1/SSCD provides failure detection throughout the lifecycle. 372 OT.SCD/SVD_Gen (SCD/SVD generation) addresses that generation of a SCD/SVD pair requires proper user authentication. The TSF specified by FIA_UID.1/SSCD and FIA_UAU.1/SSCD provide user identification and user authentication prior to enabling access to authorized functions. The SFR FDP_ACC.1/SCD/SVD_Generation_SFP_\ SSCD and FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD provide access control for the SCD/SVD generation. The security attributes of the authenticated user are provided by FMT_MSA.1/Admin_SSCD, FMT_MSA.2/SSCD, and FMT_MSA.3/SSCD for static attribute initialisation. The SFR FMT_MSA.4/SSCD defines rules for inheritance of the security attribute “SCD operational” of the SCD. 373 OT.SCD_Unique (Uniqueness of the signature-creation data) implements the require- ment of practically unique SCD as laid down in [ALGO], which is provided by the cryptographic algorithms specified by FCS_CKM.1/SSCD. 374 OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) addresses that the SVD corresponds to the SCD implemented by the TOE. This is provided by the algo- rithms specified by FCS_CKM.1/SSCD to generate corresponding SVD/SCD pairs. The security functions specified by FDP_SDI.2/Persistent_SSCD ensure that the keys are not modified, so to retain the correspondence. Moreover, the SCD Identifier allows the environment to identify the SCD and to link it with the appropriate SVD. The mana- gement functions identified by FMT_SMF.1/SSCD and by FMT_MSA.4/SSCD allow R.Admin to modify the default value of the security attribute SCD Identifier. 375 OT.SCD_Secrecy (Secrecy of signature-creation data) is provided by the security func- tions specified by the following SFR. FCS_CKM.1/SSCD ensures the use of secure cryp- tographic algorithms for SCD/SVD generation. Cryptographic quality of SCD/SVD pair shall prevent disclosure of SCD by cryptographic attacks using the publicly known SVD. The security functions specified by FDP_RIP.1 and FCS_CKM.4 ensure that residual information on SCD is destroyed after the SCD has been use for signature creation and that destruction of SCD leaves no residual information. The security functions specified by FDP_SDI.2/Persistent_SSCD ensure that no critical data is modified which could alter the efficiency of the security functions or leak informa- tion of the SCD. FPT_TST.1 tests the working conditions of the TOE and FPT_FLS.1 guarantees a secure state when integrity is violated and thus assures that the specified security functions are operational. An example where compromising error conditions are countered by FPT_FLS.1 is fault injection for differential fault analysis (DFA). SFR FPT_EMSEC.1 and FPT_PHP.3 require additional security features of the TOE to ensure the confidentiality of the SCD- 376 OT.Sig_Secure (Cryptographic security of the digital signature) is provided by the cryp- tographic algorithms specified by FCS_COP.1/SSCD, which ensures the cryptographic robustness of the signature algorithms. FDP_SDI.2/Persistent_SSCD corresponds to the integrity of the SCD implemented by the TOE and FPT_TST.1 ensure self-tests ensuring correct signature-creation. Security Target TCOS Residence Permit Card/SLE78CLX1440P 113/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 377 OT.Sigy_SigF (Signature creation function for the legitimate signatory only) is provided by an SFR for identification authentication and access control. FIA_UAU.1/SSCD and FIA_UID.1/SSCD ensure that no signature generation function can be invoked before the signatory is identified and authenticated. The security functions specified by FMT_MTD.1/Admin_SSCD and FMT_MTD.1/Signatory_SSCD manage the authentica- tion function. SFR FIA_AFL.1/SSCD provides protection against a number of attacks, such as cryptographic extraction of residual information, or brute force attacks against authentication. The security function specified by FDP_SDI.2/DTBS_SSCD ensures the integrity of stored DTBS and FDP_RIP.1 prevents misuse of any resources containing the SCD after de-allocation (e.g. after the signature-creation process). 378 The security functions specified by FDP_ACC.1/Signature-creation_SFP_SSCD and FDP_ACF.1/Signature-creation_SFP_SSCD provide access control based on the secu- rity attributes managed according to the SFR FMT_MTD.1/Signatory_SSCD, FMT_\ MSA.2/SSCD, FMT_MSA.3/SSCD and FMT_MSA.4/SSCD. The SFR FMT_SMF.1/ SSCD and FMT_SMR.1 list these management functions and the roles. These ensure that the signature process is restricted to the signatory. FMT_MOF.1/SSCD restricts the ability to enable the signature-creation function to the signatory. FMT_MSA.1/Signato- ry_SSCD restricts the ability to modify the security attributes SCD operational to the signatory. 379 OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) ensures that the DTBS/R is not altered by the TOE. The integrity functions specified by FDP_SDI.2/DTBS_SSCD require that the DTBS/R has not been altered by the TOE. 380 OT.EMSEC_Design (Provide physical emanations security) covers that no intelligible in- formation is emanated. This is provided by FPT_EMSEC.1.1. 381 OT.Tamper_ID (Tamper detection) is provided by FPT_PHP.1/SSCD by the means of passive detection of physical attacks. 382 OT.Tamper_Resistance (Tamper resistance) is provided by FPT_PHP.3 to resist physical attacks. 6.3.2 Rationale for SFR’s Dependencies 383 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. 384 The table below shows the dependencies between the SFR of the TOE. No. SFR-component from the ST 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.1/DH_PACE, FCS_CKM.1/DH_CA Security Target TCOS Residence Permit Card/SLE78CLX1440P 114/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 No. SFR-component from the ST Dependencies assumed Fulfilled by SFR FCS_CKM.4 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 57 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 58 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/SYM_ICAO-EAC FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 FCS_CKM.1/DH_CA FCS_CKM.4 10 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 11 FCS_COP.1/MAC_ICAO-EAC FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 FCS_CKM.1/DH_CA FCS_CKM.4 12 FCS_RND.1 No dependencies n.a. 13 FIA_AFL.1/eID- PIN_Suspending FIA_UAU.1 FIA_UAU.1/PACE 14 FIA_AFL.1/eID-PIN_Blocking FIA_UAU.1 FIA_UAU.1/PACE 15 FIA_AFL.1/PACE FIA_UAU.1 FIA_UAU.1/PACE 16 FIA_API.1/CA No dependencies n.a. 17 FIA_API.1/ICAO-EAC No dependencies n.a. 18 FIA_APO.1/PA_PACE-Pass No dependencies n.a. 19 FIA_UID.1/PACE No dependencies n.a. 20 FIA_UID.1/Rightful_Terminal No dependencies n.a. 21 FIA_UID.1/ICAO-EAC No dependencies n.a. 22 FIA_UAU.1/PACE FIA_UID.1 FIA_UID.1/PACE 23 FIA_UAU.1/Rightful_Terminal FIA_UID.1 FIA_UID.1/Rightful_Terminal 24 FIA_UAU.1/ICAO-EAC FIA_UID.1 FIA_UID.1/ICAO-EAC 25 FIA_UAU.4 No dependencies n.a. 26 FIA_UAU.4/ICAO-EAC No dependencies n.a. 27 FIA_UAU.5 No dependencies n.a. 28 FIA_UAU.5/ICAO-EAC No dependencies n.a. 29 FIA_UAU.6 No dependencies n.a. 30 FDP_ACC.1/TRM FDP_ACF.1 FDP_ACF.1/TRM 31 FDP_ACF.1/TRM FDP_ACC.1 FDP_ACC.1/TRM Security Target TCOS Residence Permit Card/SLE78CLX1440P 115/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 No. SFR-component from the ST Dependencies assumed Fulfilled by SFR FMT_MSA.3 justification see page 76 32 FDP_RIP.1 No dependencies n.a. 33 FTP_ITC.1/PACE No dependencies n.a. 34 FTP_ITC.1/CA No dependencies n.a. 35 FAU_SAS.1 No dependencies n.a. 36 FMT_SMF.1 No dependencies n.a. 37 FMT_SMR.1 FIA_UID.1 FIA_UID.1/PACE, FIA_UID.1/Rightful_Terminal see also Application Note 66 38 FMT_LIM.1 FMT_LIM.2 FMT_LIM.2 39 FMT_LIM.2 FMT_LIM.1 FMT_LIM.1 40 FMT_MTD.1/INI_ENA FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 41 FMT_MTD.1/INI_DIS FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 42 FMT_MTD.1/CVCA_INI FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 43 FMT_MTD.1/CVCA_UPD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 44 FMT_MTD.1/DATE FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 45 FMT_MTD.1/PA_UPD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 46 FMT_MTD.1/SK_PICC FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 47 FMT_MTD.1/KEY_READ FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 48 FMT_MTD.1/eID-PIN_Resume FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 49 FMT_MTD.1/eID-PIN_Unblock FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 50 FMT_MTD.1/eID-PIN_Activate FMT_SMF.1 FMT_SMR.1 FMT_SMF.1 FMT_SMR.1 51 FMT_MTD.3 FMT_MTD.1 FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE 52 FPT_EMSEC.1 No dependencies n.a. 53 FPT_FLS.1 No dependencies n.a. 54 FPT_TST.1 No dependencies n.a. 55 FPT_PHP.3 No dependencies n.a. Security Target TCOS Residence Permit Card/SLE78CLX1440P 116/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Table 17: Dependencies between the SFRs 385 For the Justification of non-satisfied dependencies see the description of the correspon- ding 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. 386 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. 387 The table below shows the dependencies between the SFR of the TOE derived from the [SSCDPP]. SFRs which are equivalent to those from the [RPCARDPP] are not duplica- ted. No. SFR-component from the ST Dependencies assumed Fulfilled by SFR 56 FCS_CKM.1/SSCD [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 FCS_COP.1/SSCD FCS_CKM.4 57 FCS_COP.1/SSCD [FDP_ITC.1or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.4 FCS_CKM.1/SSCD FCS_CKM.4 58 FDP_ACC.1/SCD/SVD_Genera- tion_SFP_SSCD FDP_ACF.1 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD 59 FDP_ACC.1/Signature_Crea- tion_SFP_SSCD FDP_ACF.1 FDP_ACF.1/Signature_Creation_SFP_SSCD 60 FDP_ACC.1/SVD_Transfer_SFP _SSCD FDP_ACF.1 FDP_ACF.1/SVD_Transfer_SFP_SSCD 61 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 62 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 63 FDP_ACF.1/SVD_Transfer_SFP _SSCD FDP_ACF.1 FMT_MSA.3 FDP_ACC.1/SVD_Transfer_SFP_SSCD FMT_MSA.3/SSCD 64 FDP_SDI.2/Persistent_SSCD No dependencies n.a. 65 FDP_SDI.2/DTBS_SSCD No dependencies n.a. 66 FIA_AFL.1/SSCD FIA_UAU.1 FIA_UAU.1/SSCD 67 FIA_UAU.1/SSCD FIA_UID.1 FIA_UID.1/SSCD 68 FIA_UID.1/SSCD No dependencies n.a. 69 FMT_MOF.1/SSCD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1/SSCD FMT_SMR.1 70 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 FMT_SMF.1/SSCD 71 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 FMT_SMF.1/SSCD Security Target TCOS Residence Permit Card/SLE78CLX1440P 117/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 No. SFR-component from the ST Dependencies assumed Fulfilled by SFR 72 FMT_MSA.2/SSCD FMT_MSA.1 FMT_SMR.1 FMT_MSA.1/Admin_SSCD, FMT_MSA.1/Signatory_SSCD FMT_SMR.1 73 FMT_MSA.3/SSCD FMT_MSA.1 FMT_SMR.1 FMT_MSA.1/Admin_SSCD, FMT_MSA.1/Signatory_SSCD FMT_SMR.1 74 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 75 FMT_MTD.1/Admin_SSCD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1/SSCD FMT_SMR.1 76 FMT_MTD.1/Signatory_SSCD FMT_SMF.1 FMT_SMR.1 FMT_SMF.1/SSCD FMT_SMR.1 77 FMT_SMF.1/SSCD No dependencies n.a. 78 FMT_SMR.1 FIA_UID.1 FIA_UID.1/SSCD 79 FPT_PHP.1/SSCD No dependencies n.a. Table 18: Dependencies between the SFRs required by [SSCDPP] 388 The dependency analysis given in the SSCD PP [[SSCDPP] shows that all dependen- cies being expected by CC part 2 and by extended components definition (chapter 5) are fulfilled. 6.3.3 Security Assurance Requirements Rationale 389 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. 390 The selection of the component ALC_DVS.2 provides a higher assurance of the security of the RP_Card’s development and manufacturing, especially for the secure handling of sensitive material. 391 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. 392 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 RP_Card required by the RP_Card issuer and reflected by the [RPCARDPP]. 393 The set of assurance requirements being part of EAL4 fulfils all dependencies a priori. Security Target TCOS Residence Permit Card/SLE78CLX1440P 118/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 394 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. [RPCARDPP, Table 15]). 6.3.4 Security Requirements – Internal Consistency 395 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. 396 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. 397 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 Residence Permit Card/SLE78CLX1440P 119/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 7 TOE Summary Specification 398 This section presents an overview of the security functionalities implemented by the TOE and the assurance measures applied to ensure their correct implementation. 399 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 RP_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 400 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 401 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) suppor- ted by FIA_UAU.1/PACE and FIA_UAU.1/Rightful_Terminal. For the eSign application 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 requi- red by FDP_SDI.2/Persistent_SSCD for the stored signature key (SCD). 7.2 Secure data exchange 402 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 and FCS_COP.1/SYM_\ ICAO-EAC for a EIS-AIP-BAC terminal giving confidentiality by data encryption/ decryp- tion and FCS_COP.1/CMAC or FCS_COP.1/MAC_ICAO-EAC for a EIS-AIP-BAC termi- nal 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 provides also the integrity check required by FDP_SDI.2/DTBS_SSCD for the transmitted DTBS. Security Target TCOS Residence Permit Card/SLE78CLX1440P 120/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 7.3 Identification and authentication of users and components 403 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 ter- minals of different types (FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal). During the terminal authentication protocol a certificate is used, this is supported by FCS_COP.1/SIG_VER. 404 The TOE itself must also be authenticated, which is supported by FIA_API.1/CA. The ePassport application can be authenticated by Passive Authentication supported by FIA_APO.1/PA_PACE-Pass. The Requirements laid down in FIA_UAU.4, FIA_UAU.5 and FIA_UAU.6 (and the corresponding iterations for EIS-AIP-EAC terminals supporting version 1 algorithms) 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. 405 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. 406 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. 407 The identification and authentication of the RP_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). 408 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 RP_Card and the terminal. As the authentication state is left, the session keys can not be used anymore (FCS_CKM.4). 7.4 Audit 409 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 Residence Permit Card/SLE78CLX1440P 121/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 7.5 Generation of the eSign Signature Key Pair 410 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). 411 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. 412 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). 413 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 414 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 415 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) 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 initializa- tion necessary test features are no more availabe after TOE delivery (FMT_LIM.1, FMT_LIM.2). 416 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. 417 CAN, MRZ or eID-PUK represent non-blocking authentication data, which is used to establish a secure channel. No additional access rights are granted after sucessfully executed PACE protocol. To avert the inconspicuous skimming of the TOE, the initial Security Target TCOS Residence Permit Card/SLE78CLX1440P 122/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 PACE protocol must be restarted if any failure has been detected (FIA_AFL.1/PACE). Due to the reaction time a brute force attack would require days even for the short valued CAN. Therefore increasing the reaction time ist not necessary. 418 The eID-PIN can be resumed (FMT_MTD.1.1/eID-PIN-Resume) by the RP_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 RP_Card 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). 419 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). 420 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). 421 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 422 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). 423 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. 424 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). 425 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). 426 This functionality is supported by the entire class FMT. 7.9 TOE SFR Statements 427 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. Security Target TCOS Residence Permit Card/SLE78CLX1440P 123/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 428 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. 429 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. 430 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. 431 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 432 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. 433 FCS_COP.1/SHA The hash function is used for key deriviation. The recently discovered collision attacks are not relevant for this application. 434 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. 435 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. 436 FCS_COP.1/SYM_ICAO-EAC The Triple DES is not classified as secure as the AES due to the smaller key length. Taking in account the fact that this algorithm is used only in the case of backward compatibility for EIS-AIP-BAC terminals and that the security level is higher that 100 bit the TDEA can be used until the EIS-AIP-BAC terminals are phased out (see also Application Note 53 of [RPCARDPP]). 437 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. 438 FCS_COP.1/MAC_ICAO-EAC The Retail-MAC is used for secure messaging and is restricted to data from DG3 and DG4 for EIS-AIP-BAC terminals only. Due to the low data exchange the Retail MAC remains secure for this application (see also Application Note 54 of [RPCARDPP]). 439 FCS_RND.1 The randomness of values for challenges or ephemeral or permanent keys be guaranteed by the underlying hardware TSF. To achieve the SOF “high” the genera- ted data must have sufficient entropy. This is fulfilled automatically if the random number generator is certified as P2 according [AIS31]. Security Target TCOS Residence Permit Card/SLE78CLX1440P 124/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 440 FCS_CKM.1/SSCD: The eSign key pair generation algorithm is compliant to the Techni- cal Specification [ECCTR]. The available parameters can be chosen such that they are suitable for the near and the long future. 441 FCS_COP.1/SSCD: The cryptographic operation is implemented with care based on the knowledge and experience of T-Systems International GmbH such that no leakage of secure user data can occur. 442 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. If any authentication failure for the non-blocking authentication data (CAN, MRZ, eID-PUK) has been detectected during the PACE protocol, the TSF blocks the protocol and require a restart of the PACE. Because MRZ and eID-PUK carry enough entropy the minimal reaction time is sufficient to pre- vent a brute force attack with attack potential beyound high. Even for the case the CAN is used, this reaction time prevents the tracing of the card, since a brute force attack requires some days of permanent access to the TOE. 443 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 authentica- tion and never read out. 444 FIA_APO.1/PA_PACE-Pass: The Passive Authentication making evident the authen- ticity/origin of data stored in the ePassport application by verifying the Document Secu- rity Object (SOD) up to CSCA. Note that this SFR does not require authentication of any TOE’s user, but providing evidence enabling an external entity (the terminal connected) to prove the origin of ePassport application. Independent of the result of Passive Authen- tication, secure messaging is continued using the previously established session keys. 445 FIA_UID.1/PACE, FIA_UID.1/Rightful_Terminal, FIA_UAU.1/PACE, FIA_UAU.1/Right- ful_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. 446 FIA_UAU.5, FIA_UAU.5/ICAO-EAC: The authentication of the Manufacturer, a Perso- nalization Agent and a Terminal is controlled by the Access Rules laid down in the Ope- rating System in a very early stage of the life cycle. Even if the file system is not avai- lable, 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 Authentication 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. Security Target TCOS Residence Permit Card/SLE78CLX1440P 125/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 447 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. 448 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] au- thenticates 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. 449 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. 450 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 Gui- dance 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 authen- tication depends on the quality of the selected VAD/RAD. The file system of the TOE may be 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]). 451 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. 452 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. 453 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). 454 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. 455 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. 456 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 RP_Card holder. 457 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. Security Target TCOS Residence Permit Card/SLE78CLX1440P 126/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 458 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. 459 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. 460 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 correspondig status code, that an error occurred. During opeartions the integrity check will be provided by the hardware. 461 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 au- thentication data. 462 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. 463 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. 464 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. 465 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. 466 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. 467 FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD, FMT_MTD.1/DATE: The intial Per- sonalization data from the Issuing Branch is 468 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. 469 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. 470 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. Security Target TCOS Residence Permit Card/SLE78CLX1440P 127/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 471 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. 472 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. 473 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. 474 FMT_SMR.1, 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) en- forces the application of the access rules before any function is allowed to proceed. 475 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. 476 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 Admi- nistrator S.Admin (CSP) and this attribute can not be modified in the operational 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. 477 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. 478 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”. 479 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”. 480 FMT_MTD.1/Admin_SSCD: During SCD/SVD generation the initial RAD (reference au- thentication data) is generated by the CSP (S.Admin). This special RAD value (Trans- port-PIN) can never be used for creating digital signatures. 481 FMT_MTD.1/Signatory_SSCD: Only the Signatory, authenticated as the RP_Card holder can modify the initial RAD (Transport-PIN). After the Transport-PIN value is changed by the Signatory, the SCD is set to “operational”. 482 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 Security Target TCOS Residence Permit Card/SLE78CLX1440P 128/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 documentation. This implies the leakage of information about the Personalization Agent Authentication Key and the Chip Authentication Key. 483 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 484 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. 485 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. 486 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 Residence Permit Card/SLE78CLX1440P 129/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 7.10 Statement of Compatibility 487 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 488 The TOE is equipped with following Security Features to meet the security functional requirements: Relevant: • 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, AES, RSA (not relevant), EC (not relevant), SHA-2 (SHA-256 and SHA512 – both not relevant), TRNG (relevant). Not relevant: SF_DPM Device Phase Management 7.10.2 Compatibility: TOE Security Environment Assumptions 489 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]. 490 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 RP_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 re- Security Target TCOS Residence Permit Card/SLE78CLX1440P 130/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 mains unknown and unusable until the RP_Card holder engage a CSP to make it avail- able after certificate creation. Assumptions of the Hardware PP ([PP0035]): A.Process-Sec-IC (Protection during Packaging, Finishing and Personalization) is not relevant, because the Personalization of the hardware is finished after Initialization Phase. A.Plat-Appl (Usage of Hardware Platform) not relevant 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 supported by the Se- curity 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 under T.Leak-Inherent and T.Leak-Forced). This assumption is covered by the Hardware‘s objective OE.Resp-Appl for the environment and applies to Life Cycle Phase 1 “De- velopment”. Threats 491 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.RP_Card_Tracing no conflict • 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] Security Target TCOS Residence Permit Card/SLE78CLX1440P 131/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 • 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.DTBS_Forgery and T.Sig_For- gery 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 and signature generation if the eSign Application becomes 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]): • T.SCD_Divulg is related to signature creation data only and is not contradicting the threats of the Composite ST • T.SCD_Derive is related to signature creation data only and is not contradicting the threats of the Composite ST • T.Hack_Phys matches T.Phys-Tamper of the Composite ST • T.SVD_Forgery is covered by T.Forgery and T.Eavesdropping of the Composite ST Security Target TCOS Residence Permit Card/SLE78CLX1440P 132/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 • T.SigF_Misuse is covered by T.Abuse-Func of the Composite ST • T.DTBS_Forgery is covered by T.Skimming and T. Forgery of the Composite ST • T.Sig_Forgery is related to signature creation data only and is not contradicting the threats of the Composite ST Organizational Security Policies 492 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.RP_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 Objectives 493 The Security Objectives of the TOE and the hardware can be mapped or are not relevant. They show no conflict between each other. Security Target TCOS Residence Permit Card/SLE78CLX1440P 133/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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.Tracing no conflict • OT.Chip_Auth_Proof no conflict • OT.Prot_Abuse-Func covers O.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_Malfunction matches O.Malfunction 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.Prot_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) • The hardware TOE must provide the following specific security functionality to the Smartcard Embedded Software: 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 Cryptog- Security Target TCOS Residence Permit Card/SLE78CLX1440P 134/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 raphy and Secure Hash Algorithm is not used and there- fore 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 • OE.SSCD_Prov_Service is covered by objective for the RP_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.Card-Holder Security Target TCOS Residence Permit Card/SLE78CLX1440P 135/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 • OE.DTBS_Protect is covered by OE.Card-Holder and OE.Terminal • OE.Signatory is covered by OE.Card-Holder The obligation for a CSP activating an eSign application is to supply the RP_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 494 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/SYM_ICAO-EAC matches FCS_COP.1/DES 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 • FTP_ITC.1/CA not relevant • FAU_SAS.1 matches FAU_SAS.1 of [HWST] • FMT_SMF.1 no conflicts • FMT_SMR.1 not relevant • FMT_LIM.1 matches FMT_LIM.1 of [HWST] Security Target TCOS Residence Permit Card/SLE78CLX1440P 136/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 • 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] 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 covered by FCS_COP.1/SYM_ICAO-EAC • FCS_COP.1/RSA, FCS_COP.1/ECDSA, FCS_COP.1/ECDH, FCS_COP.1/SHA not relevant, these algorithms 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 Security Target TCOS Residence Permit Card/SLE78CLX1440P 137/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 • 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 op- eration, no conflicts to SFRs of the TOE Assurance Requirements 495 The level of assurance of the TOE is EAL 4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 496 The chosen level of assurance of the hardware is EAL 5 augmented with ALC_DVS.2 and AVA_VAN.5 497 This shows that the Assurance Requirements of the TOE matches the Assurance Requirements of the hardware. 7.10.3 Conclusion 498 No contradictions between the Security Targets of the TOE and the underlying hardware can be found. 7.11 Assurance Measures 499 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 RP_Card ADV_FSP.4 Functional Specification TCOS RP_Card ADV_IMP.1 Implementation of the TSF TCOS RP_Card ADV_TDS.3 Modular Design of TCOS RP_Card Guidance documents AGD_OPE.1 User Guidance TCOS RP_Card AGD_PRE.1 Administrator Guidance TCOS RP_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 RP_Card ALC_TAT.1, ALC_DVS.2 Development Tools and Development Security for TCOS RP_Card Tests ATE_COV.2, ATE_DPT.2 Test Documentation for TCOS RP_Card Security Target TCOS Residence Permit Card/SLE78CLX1440P 138/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 ATE_FUN.1 Test Documentation of the Functional Testing Vulnerability assessment AVA_VAN.5 Independent Vulnerability Analysis TCOS RP_Card 500 The developer team uses a configuration management system that supports the genera- tion of the TOE. The configuration management system is well documented and identi- fies all different configuration items. The configuration management tracks the imple- mentation 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. 501 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. 502 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. 503 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. 504 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 International GmbH. 505 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 Residence Permit Card/SLE78CLX1440P 139/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Appendix Glossary and Acronyms 506 This is the unchanged chapter from [RPCARDPP], 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 RP_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 an ST or PP containing sensitive supporting information that is considered relevant or useful for the construction, evaluation or use of the TOE. Audit records Write-only-once non-volatile memory area of the RP_Card’s chip to store the 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 RP_Card presenter as the RP_Card holder (using the secret eID-PIN298 ), (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 RP_Card itself and the data elements stored in were issued by the RP_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 authority299 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 RP_Card using the Document Basic Access Keys drawn form printed MRZ data for reading the less-sensitive data (RP_Card document details data and biographical data) stored on the RP_Card (ePassport application only). See also [EACTR], chap. G.1 and H; also [ICAO9303-1]. Biographical data (biodata) The personalized details of the RP_Card holder appearing as text in the visual and machine readable zones of and electronically stored in the RP_Card. The biographical data are less- sensitive data. Biometric reference data Data stored for biometric authentication of the RP_Card holder in the RP_Card as (i) digital portrait and (ii) optional biometric reference data. Card 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 on a label on the Identification Card) or dynamic (randomly chosen by the electronic RP_Card 298 the secret eID-PUK can be used for unblocking the eID-PIN and resetting the retry counter related 299 concretely, by a control officer Security Target TCOS Residence Permit Card/SLE78CLX1440P 140/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Term Definition 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 RP_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 RP_Card issuer with respect to confirming correctness of user and TSF data stored in the RP_Card. The CSCA represents the country specific root of the PKI for the RP_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 RP_Card issuer with respect to protection of user data stored in the RP_Card (at a trial of a terminal to get an access to these data). The CVCA represents the country specific root of the PKI for the rightful terminals (EIS, 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 RP_Card representing the document details like document type, issuing state, document number, date of issue, date of expiry, issuing authority. The document details data are less-sensitive data. Document Security Object (SOD) A RFC3369 CMS Signed Data Structure, signed by the Document Signer (DS). Carries the hash values of the LDS Data Groups: A hash for each Data Group in use shall be stored in the Security Data. It is stored in the ePassport application of the RP_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 RP_Card/Chip and Docu- ment Security Objects stored on the RP_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 to issue certificates for national terminals, see [EACTR], chap. 2.2.2. Security Target TCOS Residence Permit Card/SLE78CLX1440P 141/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Term Definition There can be Domestic and Foreign DV: A domestic DV is acting under the policy of the domestic CVCA being run by the RP_Card 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 RP_Card issuer und a foreign CVCA ensuring enforcing the RP_Card issuer’s privacy policy300 ). Eavesdropper A threat agent reading the communication between the RP_Card and the Service Provider to gain the data on the RP_Card. eID application A part of the TOE containing the non-executable, related user data and the data needed for authentication; this application is intended to be used 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 RP_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 RP_Card holder is required. The eSign application is optional: it means that it can optionally be activated301 on the RP_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. RP_Card (electronic) The contactless smart card integrated into the plastic, optical readable cover and providing the following applications: ePassport, eID and eSign (optionally) RP_Card holder The rightful/legitimated holder of the electronic ID Card for whom the issuing authority personalized the ID Card. RP_Card issuer (issuing authority) Organization authorized to issue an electronic Identity Card to the RP_Card holder RP_Card presenter A person presenting the RP_Card to a terminal and claiming the identity of the RP_Card 300 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. 301 ‘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 Residence Permit Card/SLE78CLX1440P 142/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Term Definition 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] Initialization Data Any data defined by the RP_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 RP_Card presented to it by an RP_Card presenter and verifying its authenticity as the RP_Card holder. See also [ICAO9303-1]. Inspection system (EIS) A technical system being used by an authority302 and operated by a governmental organization (i.e. an Official Domestic or Foreign Document Verifier) and verifying the RP_Card presenter as the RP_Card holder (for ePassport: by comparing the real biometrical data of the RP_Card presenter with the stored biometrical data of the RP_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 RPCARDPP) is commensurate with the Extended Inspection System (EIS) as defined in [EACPP3.1]303 . Integrated circuit (IC) Electronic component(s) designed to perform processing and/or memory functions. The RP_Card’s chip is an integrated circuit. Integrity Ability to confirm the RP_Card and its data elements stored upon have not been altered from that created by the RP_Card issuer. Issuing 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 RP_Card). Manufacturer The generic term for the IC Manufacturer producing the integrated circuit and the RP_Card Manufacturer completing the IC to the RP_Card. The Manufacturer is the default user of the 302 concretely, by a control officer 303 please note that an Extended Inspection System also covers the General Inspection Systems (GIS) in the sense of [EACPP3.1] Security Target TCOS Residence Permit Card/SLE78CLX1440P 143/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Term Definition TOE during the manufacturing life phase. The TOE itself does not distinguish between the IC Manufacturer and RP_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 RP_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 RP_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 RP_Card holder are stored in and unambiguously, inseparably associated with the RP_Card. Personalization Agent An organization acting on behalf of the RP_Card issuer to personalize the RP_Card for the RP_Card holder by some or all of the following activities: (i) establishing the identity of the RP_Card holder for the biographic data in the RP_Card304 , (ii) enrolling the biometric reference data of the RP_Card holder305 , (iii) writing a subset of these data on the physical Identification Card (optical personalization) and storing them in the RP_Card (electronic personalization) for the RP_Card holder as defined in [EACTR], (iv) writing the document details data, (v) writing the initial TSF data, (vi) signing the Card/Chip Security Object and the Document Security Object (ePassport) 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 CSP actions providing Personalization Data to the CSP. PIN Unblock Key (PUK) A long secret password being only known to the RP_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 RP_Card and/or to secure shipment within or between the life cycle phases manufacturing and card issuing. Pre-personalized RP_Card’s chip RP_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 RP_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. 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 304 relevant for the ePassport, the eID and the eSign applications 305 relevant for the ePassport application Security Target TCOS Residence Permit Card/SLE78CLX1440P 144/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 Term Definition 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 RP_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 RP_Card is not affected by Restricted Identification. Rightful equipment (rightful terminal or rightful RP_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 RP_Card can represent the rightful equipment, whereby the root CertA for a terminal is CVCA and for an RP_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 RP_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 RP_Card or parts of it via the contactless communication channel of the TOE without knowledge of the printed MRZ CAN, eID-PIN or eID-PUK data. 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 RP_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 RP_Card gathered by inconspicuous (for the RP_Card holder) recognizing the RP_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 RP_Card RP_Card material prepared to produce a personalized RP_Card containing an initialized and pre-personalized RP_Card’s chip. User Data All data (being not authentication data) stored in the context of the applications of the RP_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 RP_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 RP_Card holder (the private signature key within the eSign application); from this point of view, the private signature key of the RP_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 Residence Permit Card/SLE78CLX1440P 145/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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’, hence this is adopted here) 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 Residence Permit Card/SLE78CLX1440P 146/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 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 Eisenbahn, 06.01.2010, Veröffentlicht am 04.02.2010 im Bundesanzeiger Nr. 19, S. 426 [BACPP3.1] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Basic Access Control, Version 1.10, BSI-PP-0055, Bundesamt für Sicherheit in der Informa- tionstechnik (BSI), 2009-03-29 [BACCR] Certification Report of the TCOS Residence Permit Card (BAC) BSI-DSZ-CC-0733-2011: TCOS Residence Permit Card (BAC) Version 1.0 Release 1/ SLE78CLX1440P, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2011 [BACST] Security Target TCOS Residence Permit Card (BAC) Specification of the Security Target TCOS Residence Permit Card (BAC) Version 1.0 Re- lease 1/SLE78CLX1440P, Version 1.0.1/20110816, T-Systems International GmbH, 2011 [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, July 2009, CCMB-2009-07-004 [EACPP2.3] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Exten- ded Access Control, Version 1.2, BSI-PP-0026, 2006-09-07 [EACPP3.1] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Exten- ded Access Control, Version 1.10, BSI-PP-0056, Bundesamt für Sicherheit in der Informa- tionstechnik (BSI), 2009-03-25 [EACTR1.11] Technical Guideline TR-03110: Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), Version 1.11, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2008-02-21 Security Target TCOS Residence Permit Card/SLE78CLX1440P 147/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 [EACTR2.03] 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.03, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2010-03-24 [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.05, 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 – Hoheitliche Ausweisdokumente, Stand 2011, Bundesamt für Sicherheit in der Informa- tionstechnik (BSI), 2011 [ECCTR] Technical Guideline TR-03111: Elliptic Curve Cryptography, Version 1.11, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2009-04-17 [EURPS] EU – Residence permit Specification, Annex II.a to Commission Decision C(2008), version 1.0, 20.08.2008 [FIPS46] Federal Information Processing Standards Publication FIPS PUB 46-3, Data Encryption Standard (DES), July 1977, Reaffirmed October 1999 [FIPS180] Federal Information Processing Standards Publication FIPS PUB 180-2, Specifications for the Secure Hash Standard (SHS), February 2004 [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-0728-2011 for Infineon Technologies Smart Card IC (Security Controller) M7820 A11, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2011-05-05 [HWST] Security Target of the underlying hardware platform Security Target M7820 A11, Version 0.6, Infineon Technologies AG, Chipcard and Secu- rity, Evaluation Documentation, 2011-04-15 [ICAO9303-1] ICAO Doc 9303-1, Specifications for electronically enabled passports with biometric iden- tification capabilities. In Machine Readable Travel Documents – Part 1: Machine Read- able 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 Security Target TCOS Residence Permit Card/SLE78CLX1440P 148/148 Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1 Version: 1.0.1 Stand: 2011-08-16 T-Systems International GmbH, 2011 [PACEPassPP] CC Protection Profile: Electronic Passport using Standard Inspection Procedure with PACE, BSI-CC-PP-0068, Version 0.92, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0068-2010, 2010-04-30 [RPCARDPP] CC Protection Profile: Electronic Residence Permit Card (RP_Card PP), Version 1.00, BSI-PP-0069, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2010-08-13 [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 [ISO9797] ISO 9797-1:1999, Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher, ISO, 2005-01-04 [ISO14443] ISO 14443, Identification cards – Contactless integrated circuit(s) cards – Proximity cards, 2000 [ISO15946] ISO 15946, Information technology – Security techniques – Cryptographic techniques based on elliptic curves, 2002 [PP0035] Smartcard IC Platform Protection Profile, Version 1.0, 15.06.2007, Registered and Certi- fied by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0035-2007 [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] TCOS Residence Permit Card Version 1.0 Release 1, Administrator's Guidance Version 1.0, T-Systems International GmbH, 2011-06-21